______________________________________________________________________

                          DRAFT TRANSCRIPT

                        Policy SIG session 1
               
                    Wednesday 1 September 2004 
                              2.00pm
______________________________________________________________________


TAKASHI ARANO:

Let me start - welcome to the address policy SIG. We have a lot of
topics. From the original program - from the original program, I
changed the order a little bit. First of all, we will do the election
of the co-chair then the review of action items. We will deal with the
other items separately. Each speaker should take care of this order.
So the first session we will handle the five topics. The second
session the four topics. The last session tomorrow morning we will
deal with those last four topics. Does every speaker understand the
order? First of all we will do the election of the co-chair. One of
our people wants to step down - Yong Wan Ju - I want to thank him a
lot. Probably he will say something during this meeting. The three
nominees - the first person is Randy Bush, there. The second person is
Billy Cheon. The third person is Toshiyuki Hosaka. I would like every
person to make a short speech for self-introduction. Can you do that
first, Randy? 


RANDY BUSH:

My name is Randy Bush - no relation to George, absolutely not. I did
not vote for him. So I work for IIJ - Internet Japan - in Tokyo. I'm
chief scientist there. I'm an old Internet dog since the auger net
days engineering but I have done some policy. I was on the founding
board of directors of ARIN. Helped start ARIN. Been around here a
while. I even helped negotiate the ENS dispute resolution policy. Too
many lawyers. But most of my interests are engineering and operations.
I've been doing engineering around the net for a long while. I don't
know - in the ITF I was the operations director for six years or
something like that. And I actually touch routers on a daily basis.
That's why I thought I would volunteer for this because I think that
policy and engineering meet and influence each other strongly, so I
thought an operations person could contribute to policy.


TAKASHI ARANO:

Next Billy.


BILLY CHEON:

My name is Billy Cheon. For the last four years I have seen changes
and natural progress with APNIC community. I think I have learned a
lot. I try each time I think to contribute my experience and knowledge
to AP communicate. Excuse me. I won't fail you. Thank you.


TOSHIYUKI HOSAKA:

My name is Toshiyuki Hosaka. I have been working as a policy adviser
in Japan and on a research project. I have co-chaired the policy area
and IPv6 document together with Billy and another person from Japan.
Before I joined JPNIC I had worked for international Telecom Korea and
was responsible for certain areas there. I would like to contribute to
this policy forum if I could have your support.


TAKASHI ARANO:

Thank you, everyone. We have three very good nominees, but we have to
choose just one - so how can we do that? You have to raise your hand
for just one person. This is OK? Does everyone understand how to
choose one? Have you decided who you will vote for? Is this OK? I will
say the name and you will show hands for that person. First nominee is
Randy Bush - please raise your hand to support him. OK, thank you very
much. Next, Billy Cheon. Last nominee - please raise your hand for
Toshiyuki Hosaka. The result was 16 for Toshiyuki Hosaka, 8 for Randy,
6 for Billy. Hosaka San was elected as the new co-chair.
Congratulations. Hosaka San, could you give a brief talk as the new
co-chair and take a seat next to me.


TOSHIYUKI HOSAKA:

Thank you very much, everyone. It's an honour for me that I have
support from this community. I will try to do my best to contribute to
the forum in future. Thank you.


TAKASHI ARANO:

The next on the agenda action items - the first action item pol-16-008
- it is a proposal to resubmit revised version of IXP proposal dealing
with remaining proposal elements, such as fee waiver.


ANNE LORD:

I've tried to contact the proposer on a number of proposals, but he
hasn't responded to my proposals. He does not wish to pursue the
proposal perhaps.


TAKASHI ARANO:

If so we will cancel this action item. Do you agree?


GAURAB RAJ UPHADAYA:

To this proposal there were a couple of parts. The first proposal was
to waive the fees but something I proposed when we make an IPv4 for
assignment for critical infrastructure why not make IPv6 assignment at
the same time without the IX having to come back to APNIC for a second
round process to get IPv6 assignment. To rephrase it, when a critical
assignment pour IPv4 is made, can we also make a IPv6 assignment at
the same time? Is that clear enough?


ANNE LORD:

That actually wasn't part of this proposal at all. The part that was
rejected was the fee structure part. Bill was supposed to come back
and look at revising the fee structure and deciding what he wanted to
do with that part. So I respectfully suggest that this is actually -
perhaps you can confirm with Bill what he wants to do with this actual
proposal. If you wish to carry forward the proposal you've just
described we'll put it forward as a new policy proposal. It's much
cleaner. This is getting confusing.


GAURAB RAJ UPHADAYA:

I will speak to Bill.


ANNE LORD:

Yes, because he hasn't responded to my emails.


GAURAB RAJ UPHADAYA:

I'll do that. A short proposal to make IPv6 assignment for critical
infrastructure easier.


SPEAKER:

If they ask for it give them IPv6 but as a new policy proposal.


GAURAB RAJ UPHADAYA:

We'll put it in a new proposal.


TAKASHI ARANO:

So we withdraw this action item. The next item:

Pending approval at each remaining stage of the policy proposal
process, proposer to resubmit a modified version of the proposal to
the mailing list. The rewritten proposal will define multiple discrete
networks and consider the HD ratio for suballocating address books.


ANNE LORD:

I've been in touch with the proposer. The person who left has - I
suggest it remain open until I can confirm they have found another
person.


TAKASHI ARANO:

It will remain open. The next one is a pending proposal for each
remaining stage of the policy proposal process. Secretariat to
implement the proposal with the modification that there is an added
requirement for LIRs to plan to move some of their customers from IPv4
to IPv6 within two years.


ANNE LORD:

This has been completed.


TAKASHI ARANO:

Pending approval at each remaining stage of the policy proposal
process, APNIC secretariat to implement the proposal to permit
allocation of IPv6 address space to closed networks. That has been
done. The next thing:

APNIC secretariat to edit the IPv6 guidelines document, post to the
SIG policy mailing list for comments and to publish after the review
period. This is also finished. The next one:

The secretariat to implement the proposal to reduce the minimum
initial allocation size to /21 and to lower the criteria for an
initial allocation to demonstrate an immediate need for a /23 and use
of a /22 within one year. It's done. The next one:

Secretariat to implement the proposal to recover unused address space.


ANNE LORD:

It should remain open because it is in the process of being
implemented. It will be implemented in the middle of December. The
next one:

The secretariat to call for volunteers for a new working group to
review the current DSL/cable guidelines in the document "APNIC
guidelines for IPv4 allocation and assignment requests."


ANNE LORD:

We've made the call and there's only one volunteer - Phillip Smith.


TAKASHI ARANO:

Are you volunteering?


SPEAKER:

Yes.


TAKASHI ARANO:

Please identify yourself later. I need one guy from Taiwan and other
regions. That's it. That's all the actions. Is there any question
about those items? OK. Let's move to the next agenda item. The next is
dark IPv4 space proposed by Gordon Bader. The chair will be taken over
by Kenny Huang as the co-chair.


ANNE LORD:

Just bear with me while I make this phone call. Gordon, your
presentation is up on display here. I'm going to try to put you close
to the microphone. I think you can go ahead.


GORDON BADER:

Thank you very much. My name is Gordon Bader. This is a proposal to
prevent the routing of dark space. With respect to this proposal
scofflaws are currently utilising unallocated IP address space for a
variety of unsavoury activities - for originating and sending SPAM and
servicing SPAM and hosting web sites. Technology has had little impact
on this in the last 10 years. In fact, spamming has increased to
consume over 70 per cent of email traffic as reported by a number of
authorities. The Internet community has been attempting to cover this
through business, technology and policy - a combination of business,
technology and policy. APNIC currently contracts out IP space to the
users. APNIC also has the ability to rescind these IP space
allocations upon non-payment of fees. This is primarily the give and
take that APNIC currently has. I also understand that APNIC when it
discovers a misused or misapplication of its unallocated IP address
space or dark space does issue request to stop or to cease and desist.
However, this has no enforcement capability at all. If the recipient
of the desist request chooses not to or to wait till the next
maintenance cycle, a day, a week, a month, a quarter, then there is
very little that APNIC is basically able to do, from my understanding.

Essentially the routing of dark address space conveys an illegal
ownership of the IP address space, i.e. the scofflaws who are using
the dark address space are basically taking squatters' rights on this
space to conduct their business. Essentially they have set up their
own IP that is reportable to no-one. In addition, the routing tables
of legal carriers are being modified and updated to route to dark
space. The question is how are we as an Internet community going to
address this. Essentially servicing SPAM and resulting traffic from
SPAM is being viewed as a cost of doing business. Removing the routing
of dark address space, as I indicated before, can take days and weeks,
depending on the service provider currently providing the routing. It
has been reported that activity in this dark space is continuing and
there is a constant hum of activity. Therefore this is a continuing
problem. And with the other anti-SPAM activities, I presume and
predict that the activity is going to increase. The position with
respect to this - I'm on page 5 - in other regions is currently
unknown. However, SPAM continues to increase. The basic proposal is
fairly simple. It relies on the allocation of rights. Currently APNIC
is able to provide the allocation of IP address to this community and
it is able to rescind these rights. What this proposal is based upon
is the allocation of these rights with respect to the non-illegal use
of this dark space. Carriers and IPs would continue to route to and
service this dark address space will lose their own address space if
they continue, basically if they refuse to maintain or update the
routing table in a timely fashion, refuse to filter out dark space
when they find it, they take too long to maintain their routing table,
i.e. if a request comes in one day and it takes a week, a month, a
quarter on a continuing basis over and over again, and if they
continue to route and route and route to these dark address spaces
which is this instant and another instant, more instances, this is
essentially an Internet death penalty for the carrier. Do I propose
this lightly? No, I don't. This is basically cease and desist.
However, nothing else has worked to date. The problem in a business
sense in addition along with technology and policy. And I'm also
proposing that this only be applied in the most egregious cases.

Taking out a carrier should not be taken lightly. However, if that
carrier refuses to maintain the integrity of the routing table, not
servicing it in a good fashion, it should be. The benefits and
disadvantages on page 7. Hopefully the benefits will be a reduction in
SPAM traffic. This will reduce the amount of capital expenditure that
you have to output in order to service the growth in bandwidth that
we've seen. Hopefully this will result in a reduction in where
spammers and how they operate and where they hide and do their
business. The disadvantages are obviously the routing table will be
more difficult to maintain. That I understand. And I don't take that
lightly. We'll have to filter the routing table update - requests for
updates, for new routes, need to be balanced against and compared
against dark address space to make sure that the requests do not
reflect a hidden agenda, i.e. to route to these hidden addresses. Also
if this is adopted and applied it results in the possible loss of
ability for the business to perform. Implementation schedule - page 8.

Prior to the implementation of the proposal it has to be accepted by
the APNIC community. It must be accepted by RIR communities. And it
needs to be accepted by all other RIRs within the world. This has to
be a joint effort. No single region can implement this by itself. On
page 9 - in summary, it provides a set of penalties for routing of
dark address space. I understand that it's fairly drastic, but there
are no other ways. They are unable to fine such participants. Is there
any mechanism to enforce such fines anyway. If you continue to route
dark address space, you will lose your own address space. This creates
an Internet death penalty. I really don't see a way around it,
unfortunately. This is to be applied in only the most egregious cases
after several warnings and consultation. I think if it's ever done,
having been applied once, I would think that would certainly serve
notice and scofflaws would desist. I thank you for the time to make
this presentation.


KENNY HUANG:

Thank you, Gordon. Are there comments or questions about the proposal?
Please come to the Mike. Come Randy.


RANDY BUSH:

I don't know where to begin. Indeed, if it is done once, it will solve
the problem, because APNIC will be sued in court out of existence.
APNIC - I'm not aware that APNIC sends cease and desist orders if
somebody routes something they do not own?


GORDON BADER:

I'm having trouble hearing.

RANDY BUSH:

The question was addressed to APNIC. Does it send cease and desist
orders when someone uses dark address space?


ANNE LORD:

We have a host action procedure when somebody monitors the bogon
lists. That's a host master procedure. They contact some of the ISPs
and stop routing address space if it's unallocated. That's what the
host master is doing.


RANDY BUSH:

I think the RIRs have long had the position they can make suggestions,
provide facilities, et cetera, et cetera. It just doesn't fly. Also
you should note that some security experiments are conducted by
announcing dark space and seeing what arrives there. But basically
what you're trying to do is fix a problem with the SMTP protocol by
routing hacks and especially asking the RIRs to become the routing
police and seriously threaten and damage ISPs' business. Do that and
it's the end of the entire RIR structure as we know it. This may not
be a bad thing but I think the people in this room would think it's a
bad thing.


GORDON BADER:

My response is I absolutely agree with you wholeheartedly. Secondly,
you actually touched on exactly what I wanted to perform here. I
wanted to get the conversation started in terms of I certainly
understand that this is a very rash and drastic implementation. Number
2, but by sitting down and conferencing and talking about this, we
might be able to find something in between - not as rash. I do
understand that and this is by design that I am putting the onus of
this problem squarely on the carriers of the United States - without
the carriers and ISPs, obviously there is no Internet, because there
would be no routing, no communication structure. However, we have to
be vigilant in terms of how we structure and route and basically have
to guard against the hacks with respect to the routers. It's been
documented and I can go back and find some reports on this, but the
routers have become one of the central targets of the scofflaws of the
Internet. They can suck themselves up as their own ISPs with no
operating - I'm searching for a term, I'm sorry - with no operating
environment outside of what they wish to do. APNIC and ARIN and the
rest of the Internet structure has been set up to form policies that
we can all operate in. What I'm proposing - unfortunately it's drastic
and I would like to find some other means - less drastic - whereby
pressure can be applied in a native way to the carriers and to the
ISPs who do not conform to a realistic business policy. Unfortunately
in this world the bottom line is basically being able to perform
business at a profit. This is where this proposal is specifically
aimed, i.e., if you're unable to route, if you are routing and refuse
to maintain, update, clean your router and you're providing service
and "ownership" of dark address to the scofflaws of the Internet, then
you're providing a disservice to the entire Internet community. Thus I
am aiming this proposal at - please don't take this personally - your,
meaning the carriers and ISPs who do not clean up and maintain their
routers in a reasonable way.


GEOFF HUSTON:

I've been the author of the bogon list for some time. I sense two
major show-stopping problems. The first problem is the proposal
doesn't say originate - it says route. If you actually observe what's
been going on over the last few years, every ISP that carries a full
route set carries dark addresses. The proposal doesn't work. That
entire terminology as it is applied doesn't work. That's the wrong way
of going about it. Secondly, in looking at the bogon list over the
years there is a relatively steady population of folk who actually
originate - I use that word very deliberately - originate address
space where there is no clear record from an RIR. Most of those
reasons appear to be historical or some longstanding difference of
interpretation between the folk who are originating the address and
the relevant RIR. What most of us in a strict interpretation one would
consider dark actually involves areas that include AT & T, China Net,
US Department of Defence, to name but a few. The list of folk in this
position, for whatever reason, is quite large. The observation is that
you actually can't do this this way. Filtering and then trying to say,
"Yes, well I know that address is bad" is taking the wrong end of the
problem and doing it the wrong way. I was much more heartened by work
done by a number of folk about how to secure the interdomain routing
system by saying how do I put in a level of integrity and trust in the
routing. It's not by making the RIR a policeman in dark address space.
That's wrong. The work done in sBGP and soBGP points to a direction
that says what you want to do with securing the routing system is to
be able to have some trust on the original injection of trust into the
routing system, some trust that some prefix being injected is a real
one through certification chains and the entity doing the origination
has some trust that it's doing the right thing by relevant
certification chains. This thing is backed into the routing SIG in
APNIC in work done in the past in saying what's the RIR's role in
securing interdomain routing. The role is properly in my view looking
at areas of how you can certify originating information injected into
the routing chain. To my mind that's a more positive way of
approaching the issue of so-called dark address space. This kind of
approach, I think, simply leads to massive disruptive problems and I
would certainly advocate that this is not the right way to do it in
any way, shape or form.


GORDON BADER:

I agree with the gentleman wholeheartedly - in fact, in my "day job" -
and I'm only representing myself here - I do work for a defence
community. Within that environment we do have very heavy
authentication. Unfortunately with respect to the public Internet, the
authentication that is the basis for integrity and trust is fairly
weak and sometimes non-existent. I do agree that it would be very good
if we could come to a consistent policy in terms of integrity and
trust based on this standard set of identification and certification.
With IPv6 there is a 20-year time frame with it. I'm not sure - I
understand it's going to take 20 years and why it's going to take 20
years in various stages. However I don't know what the Internet is
actually going to look like in 20 years the way it's being consumed
with spam, scofflaws and so forth. Again, I'm taking this position
basically to induce additional discussion such as this.


KENNY HUANG:

Since this is a policy proposal we need to go through the process to
ensure the consensus view. Any of you who agree with the proposal,
please raise your hand.


RANDY BUSH:

Excuse me, don't we have a slightly different policy on how we do
policy?


KENNY HUANG:

This is the proposal proposed by an individual.


ANNE LORD:

Randy, was your question about the use of the word voting? We are
taking a show of hands to measure whether there is any consensus on
this proposal. We're not doing any formal voting - just to clarify.


SPEAKER:

This is my first time at this meeting. I have a question for the
person who made the proposal. Are there any statistics about the
number of spams arising from the dark IP addresses?

GORDON BADER:

That I'm not sure. I understand there is research going on in trying
to map the extent of the activity, the extent of the traffic. There
were a number of items I believe from a couple of researchers at
University of California, Santa Barbara, who looked at this, but I
have no specific information at my fingertips at this moment that
could shed additional light on that.


KENNY HUANG:

Last question.


IZUMI OKUTANI:

This is not a question, but a comment. I am from JPNIC. We can't
support this proposal for the reason Randy and Geoff already stated.
We definitely need to discuss it in our open policy meeting if we have
to implement this, because it really would affect our ISPs and some
NIR - we also have to check we don't have legal problems and things
like that, so it's very difficult for us to support this proposal.
That's just a comment.


KENNY HUANG:

We have had enough feedback from the audience. If anyone agrees with
the proposal please just show your hand. OK, thank you. So I can see
there's no consensus to the proposal so we just move to the next item.


GORDON BADER:

Thank you very much.


RANDY BUSH:

As a matter of process it works both ways. This does not deny the
proposal either. The proposal should go to the mailing list, et
cetera.


KENNY HUANG:

The proposal will go to the mailing list. We can discuss it online.
The next speaker will be Anne Lord on HD ratio for IPv4 allocations.


ANNE LORD:

Good afternoon. Can everyone hear me? Am I clear enough? This is a
proposal to use the HD ratio with IPv4 allocations. For those of you
who are familiar with the IPv6 policy you're perhaps familiar with the
HD ratio term. For those of you who are not perhaps the title is
meaningless. restated, This is a proposal about defining utilisation
thresholds for IPv4 allocations and by utilisation thresholds I mean
the point at which an LIR can come back to an NIR or to APNIC for a
subsequent allocation. I mean utilisation in this context, not talking
about individual host counts within addresses that have been assigned
or suballocated. I mean it in terms of how much address space within
your allocation have you made out to third parties or to your
infrastructure. I just wanted to clarify that at the beginning. So
this proposal has some history. It was actually presented one year ago
in Korea as an informational presentation. It would have been
presented as an actual proposal, but the deadline was missed for the
proposal. So it was presented as informational. There was general
feedback that it was well supported. There was some feedback that
there should be some consideration given to the other regions and what
they thought about it, so it has been considered at RIPE, ARIN and
LACNIC meetings. 

It was submitted as a proposal one month ago on the
SIG policy mailing list. It has a proposal tracking number - proposal
number 20. You can find the information at that URL. So what is the
proposal that we're making? As I said in the introduction it's about
defining the threshold for requesting a subsequent allocation from the
NIR or from APNIC. We've had in place for over 10 years and written
into this 80 per cent rule. When you're suballocated or assigned 80
per cent of the address space allocated to you you can come back to
APNIC for an additional address allocation. That 80 per cent was never
- well, it was chosen somewhat arbitrarily. It was chosen in the
context of a climate of concern about addressing and conservation of
address space. At that time that 80 per cent seemed a good fit in
terms of address utilisation. So this proposal is about replacing that
fixed 80 per cent utilisation with a variable percentage measure of
utilisation. The motivation is to apply a fairer and more equitable
measure of what utilisation means for holders of address space. That's
trying to introduce the idea. Currently in IPv4 there's a fixed 80 per
cent utilisation requirement. So when 80 per cent of your address
block has been suballocated to a customer or assigned, you can request
an additional address block from the registry. That 80 per cent is
applied universally across all holders of address allocation. In IPv6
we've accepted something different - we've accepted we can have a
variable percentage utilisation requirement. The larger the address
allocation, the lower the percentage utilisation you have to reach. So
that recognises that your ability to fully utilise a block is actually
related to the size of the block and the implied hierarchy that you
have with a larger block of address space. So what is the actual
problem that we're trying to solve? Well, we've had feedback at the
secretariat - quite strong feedback - from a number of economies,
including China, and also Indonesia, that larger LIRs have difficulty
it meeting the 80 per cent rule. There was a proposal at the last
meeting in a different way on this same subject. It was a proposal
about unifying account holders - to simplify account administration so
they could have a lower threshold of utilisation across their address
blocks. That was rejected. The larger LIRs have expressed difficulty
in meeting the 80 per cent rule. In IPv4 no allowance is made for this
hierarchy present in the larger address allocations - present in the
networks being administered by ISPs. We have this 'one size fits all'
approach - no matter who you are or what you are. That doesn't take
into account any of the effect you get with hierarchy and having to
manage your internal address space. So the basis of the proposal is
that there's a relationship between the size of a network and the
administrative complexity in actually managing the address space
that's been allocated. So to explain a bit more, there's a tendency
that when a network gets larger, the services and the offerings that
the ISP makes as the network gets larger get more diversified, more
complex. When you're small you might have only one or two services
that you concentrate on. When you're larger you diversify. Then you
have an administrative problem with partitioning the address space
that you have and portioning it out to particular services. So we tend
to be more efficient with less hierarchy. That's the basic argument of
this proposal. 

It's a rather flat structure that appears with the
smaller blocks. There's much less hierarchy. What arguably goes on -
again this tendency increases with larger ISPs. There's this internal
administrative hierarchy when you partition the address space
according to certain regions or according to your POPs and your
services. So in effect what you get is the policy doesn't actually
recognise that there's this overhead of administration and the larger
your address block, because of the more layers of hierarchy, the more
padding you need to put around your guesstimates about how many hosts
you'll have so you're making larger guesses around your allocations
and your suballocations. So basically the argument is that the deeper
the hierarchy, the lower the efficiency. As I said, this decreases as
the network becomes more hierarchical. If we take 80 per cent to even
three layers of hierarchy, 51.2 per cent overall. With a fixed
utilisation we assume 100 per cent efficiency at lower levels. We're
not recognising the inefficiency that goes on around those
hierarchies. The proportion of address padding increases with more
hierarchy. The address space you build in as a buffer around what you
think you'll be using - you have a larger amount of address space you
devote to one service. You don't know how many hosts will be in that.
You want to be able to add hosts as you increase your service or
expand your network. So the more hierarchy the more padding you need.

So this proposal makes use of a host-density ratio. As I said before,
it's in use with IPv6. We've accepted that that's a realistic way of
looking at address utilisation. It's been described in RFC 3194 and
it's calculated by taking the log of utilised host addresses over the
log of total addresses. That will give you a HD ratio value that
corresponds to a percentage utilisation. This is just a table which is
meant to show how we arrived at the figure of 0.96, which is in the
proposal. We took the current utilisation of 80 per cent and applied
that across an address range of /24 to /20. We assumed some levels of
hierarchy from 1 to 3 levels for the address prefixes and basically
calculated the HD ratio that corresponded to 80 per cent utilisation
for those given prefix ranges. So you get a range of HD value ratios.
That was from .96 to .973. We applied that through the layers of
hierarchy. There's a 1.5 and a 2.5 level in the - it's meant to
indicate a halfway. I have then taken those values of percentage
utilisation and plotted them against prefix values. The 0.96 basically
comes out like this - a gentle or gradual decrease in utilisation. So
the left-hand side for /24 you've got something like 73 per cent
utilisation going down gradually to about /12 with around 60 - 55 or
so. 

I also plotted the more conservative values - 0.972 and even more
conservative 0.98. So there are three different percentage values
depending on the value you choose. The green is the least conservative
at around 73 per cent utilisation for a /21. The blue line is about 80
per cent - which is what we're asking today. And even higher than
that, the orange line is about 86 per cent. That's where the 80 per
cent rule, the straight line, sits right now. So you can see that the
decrease in utilisation plotted for each of these HD ratio figures is
actually not too steep. So just to summarise. This proposal talks
about or tries to show that there is an overhead in managing
hierarchical address space and that this is a realistic measure of
what's practical in trying to manage address space. So it's a
realistic measure of utilisation. It recognised that larger networks
tend to have a greater diversity and a more network hierarchy. In
terms of implementation you'd be using a simple look-up table. There'd
be no need for APNIC members to do calculations because the
secretariat would develop tools to enable you to quite easily
recognise when you've reached your percentage utilisation requirement.

So there's no math involved for anybody worried about that aspect. And
it's argued that this is actually a fairer system which more
realistically reflects what's going on in networks today and amends
the penalties applied to those operating larger networks. The feedback
to us from certain economies has been quite strong from those
operating larger networks. On the mailing list we've had some
feedback. It was posted one month ago. The feedback has come pretty
much from JPNIC and JPNIC members. There was a comment that perhaps we
could just lower the utilisation threshold to say just 70 per cent
overall. In response to this I would say that this basically rejects
the argument that's been made saying there's a hierarchy that creates
this decreasing utilisation. So it's just as well this is not the case
- it's just flat and flat is OK. That would probably have the effect
of being possibly unnecessarily lenient with the smaller networks and
it may not accommodate the needs of those with larger networks.
Actually, to date at the secretariat I'm not aware of any feedback
from small members saying they're having problems meeting 80 per cent.
Some have said, "Well, the HD ratio is the wrong measure to use."
Well, we're using it for IPv6 currently. It's been accepted in that
environment. Then you have to ask:

If you agree with the argument that hierarchy imposes this overhead,
then you're saying we need to find the best fit to accommodate this
observation. The linear argument - which is the current 80 per cent -
doesn't accept the overhead of hierarchies. So a logarithmic scale
which is what the HD scale is based on is seen as appropriate. It's a
gradual decay - not a steep decay but a gradual one. I think the graph
I showed on the previous slide showed that. There has been some
concern about the impact to utilisation overall. One possible answer
to that is we can use a more conservative HD ratio value. There was
feedback also from JPNIC to say some members in the JPNIC community
have said they've had difficulty in reaching the 80 per cent
themselves. In that case, that's a rejection of the argument, I
suppose. Impact on NIRs - they will be expected to conduct an open
policy meeting with a view to adopting a consistent policy. The
timeframe for the NIRs would be at the discretion of the NIRs. There
is a 2-month period for comment after this discussion for feedback. It
has been considered in other regions. There was a similar proposal -
not identical - raised at an ARIN meeting. That was discussed but it
was abandoned as too complex. I suppose reading through the minutes of
the meeting also, another reason that was given is that the ARIN
members didn't see the value in adopting the HD ratio. It was
presented at a LACNIC meeting and a RIPE meeting by APNIC staff as
informational presentations. To date I don't think they've been taken
up as proposals by anyone within those communities. So that's all. I'd
be happy to take any questions that anyone's got.


RANDY BUSH:

Randy Bush, IIJ, the usual troublemaker. As an ISP man my need for
that boundary is time. It is enough time for me to make the
application, for you to approve it and give me some address space and
for me to deploy it. So it would seem to me intuitively that a smaller
ISP would be the lower percentage - the slope is the wrong direction,
because the smaller ISP only has a /20. So when they're hitting 80 per
cent they have two more customers they're in trouble. So they need a
quicker allocation and maybe therefore their percentage should be
lower and the giant ISP that has a /5, they've got address space
hiding in corners and if they did their home work they could apply in
plenty of time with a 90 per cent.


ANNE LORD:

In response that's not the feedback we've had from ISPs and customers.
But at the same time when you're a smaller ISP with a smaller
allocation the chances are very high that your request will be turned
around very quickly as opposed to when you've got a larger request, a
much more complex request. It inevitably takes more time to go through
and analyse. So I would say in reality what happens is those smaller
ISPs get their requests turned around in a quicker time frame. The
other thing about the part of the proposal and the basic argument, it
says that you actually have this hierarchy and our current policies
ignore that hierarchy. In the larger network that policy has an impact
on how you manage your address space. So it's imposing behaviour on
your network that you wouldn't otherwise want to do. I don't know if
that answers your question.


IZUMI OKUTANI:

The same problem was raised within our community. A former tuple to
accommodate sudden growth customers. No other comments were made on
the mailing list to support the point. I don't know if this was
representative of the situation in JP. I think I've expressed my
thoughts within JP on the mailing list. I want to ensure this proposal
will not give too much advantage to large ISPs. As long as that's
being proven that it's OK it's not going to give too many advantages,
then I think it's fair if they're having problems and requesting
subsequent allocations, then it should be implemented to support them.
But at least in the situation in Japan, none of the large ISPs express
they're having problems with their allocations so I wonder what the
difference in the situation is.


SPEAKER:

When address space runs out, if we take allocations into consideration
and do a new calculation, I wonder if it would be - it would make a
time bomb, you know - running out shorter or longer, those kinds of
impacts?


ANNE LORD:

I can give you a general answer. But I might ask Geoff who's the
master of predictions.


PAUL WILSON:

Geoff projects, he doesn't predict.


GEOFF HUSTON:

If you actually analyse most of the activity that's happened in the
past three years in the RIRs' delegation files remarkably few are
large - most are around the /20, /19. As I understand it, around that
area it's still approximately an 80 per cent fill rate. So the first
kind of answer to the question is if past behaviour continues into the
future, then this will not have a very big impact on consumption
rates, because very few addresses blocks are actually handed out that
are a large size. We do an awful lot of small transactions. So in that
respect I don't see it as being a big impost on v 4 from that
perspective. PAUL WILSON:

On the timing issue, I'd be happy if anyone wants to comment on timing
or difficulties that members of different sizes might have. I recall
quite a number of timing issues having been raised by the larger ISPs
for their much longer requests. It involves more work. I recall
complaints of that nature having been made. The timing issue is
probably separate. Perhaps we are addressing it now. I hope that will
help at both ends of the scale, not to mention the fact that the host
masters are doing a one-day turn around these days as well. So some of
the timing issues we've had are historic. Regarding whether this HD
ratio value makes it too small for larger ISPs, it is according to all
the work that's been done on the HD ratio still a high value for the
number of addresses that are involved. So in terms of the IPv6 HD
ratio it's a much lower value. In the case of IPv6 it's arguably a
concession to larger ISPs that still may not level the playing field
in terms of address management overhead. Once again this is based on
some feedback from larger ISPs and hopefully there would be some
others in addition to Randy who are able to speak for and against the
proposal from their own practice and experience. I encourage anyone
able to do that to step up to the microphone. Thank you.


LESLIE NOBILE:

I wanted to comment on the ARIN policy evaluation on this. The ARIN
community didn't think it was too complex. They thought why would we
want to fix something that wasn't broken. Several large ISPs commented
that the 80 per cent utilisation hadn't been a problem for them and it
worked across the board. Several smaller ISPs commented. It was a
matter of why change it when it's working well for the entire
community.


BILLY MH CHEON:

Large ISPs, if they assign other space to their infrastructure to meet
their condition for subsequent allocation, I don't think there would
be much point in changing.


ANNE LORD:

You're saying it's giving an advantage to the larger ISPs, but some of
them currently feel they are very disadvantaged by the existing
policy. That's the feedback we've had from some of them.


BERNARD:

What was the original object of having a threshold in the first place?


ANNE LORD:

The 80 per cent?


BERNARD:

Yes. What was the object? You already have a rigorous evaluation
process so obviously you were receiving too many requests that you
couldn't handle?


ANNE LORD:

It defines the point you can come back for additional allocation. The
idea behind 80 per cent was to give the ISP a buffer - we wouldn't say
to them come back when you use up all your address space.


BERNARD:

If it's 20 per cent you still have a requirement.


ANNE LORD:

You don't want people coming back to you when they've only used 20 per
cent of their address space? They haven't used it. The idea is to get
them to use the address space than just to hold large pools of the
address space. You want it to be in use. in the past we've given out a
lot of address space and it wasn't used. Now we want them to use them
up before they come back for more. And to set that limit relatively
high in the context of a concern about conservation.


RANDY BUSH:

Why the 80 per cent? It was a political compromise made by a very
small group. I don't think anybody else was there. Were you there? No.
And it was a compromise between the routing size which was then agreed
to be 19 and how quickly an ISP would need to come back. But to answer
your question, I think my experience is if I go to RIPE or ARIN - I
haven't gone to APNIC - if you had used nothing from your allocation
and you show that in three weeks you are going to need something twice
as big as you actually had today and you can really show it, you'll
get the space. That's why we pay host masters that have brains.


IZUMI OKUTANI:

How much need is there for large ISPs to - how many large ISPs are out
there which can't meet its current utilisation? I'm not expecting any
specific figures, but if the number is not so large and the requests
are not so constant, perhaps we can deal with it in the actual
operation, which is what we do in JPNIC. If they explain the reason
and they have good enough justification for that, we process the
request even if the utilisation is lower than 80 per cent. The number
is not so large, it's not therefore causing a large problem.


ANNE LORD:

I can't give you an answer to the number. But there was a proposal
from Norman Hoy. He basically proposed among individual account
holders that had seven or eight accounts with JPNIC, he proposed 50
per cent across the whole range but 80 per cent for each one. That is
an indication of the difficulty they were facing. They wanted to have
one pool - one account at APNIC. They suggested 50 per cent and it was
rejected basically. So there's a concrete example. Someone's brought
in a different form, the same sort of problem, to the APNIC meeting.
We've had this from ISPs in China as well. In many cases it probably
applies to ISPs in numerous locations. There's been feedback but I
can't give you an exact number.


IZUMI OKUTANI:

The reason I ask is there are cases you need to know the current
utilisation. But in some cases you could give too much address space
to large ISPs. I don't know what the good solution is. But I don't
want small ISPs to be disadvantaged through being too generous to
large ISPs.


ANNE LORD:

One possible solution is to raise the value.


KENNY HUANG:

The proposal has received feedback. I'd like to suggest we partition
the proposal into different elements and discuss each element one by
one. Can I go through the voting process. Is there agreement with the
use of HD ratio? Please raise your hand so we can see whether we use
the old methodology. If you agree with using HD ratio as the new
proposal, please raise your hand. If you disagree with the use of the
HD ratio please raise your hand. Just one.


TAKASHI ARANO:

We need more research. Actually, we don't have any opinion from the
big ISP, more the small ISP. I myself cannot decide whether it is good
or bad because there is no data, no analysis. Who is in trouble with
the 80 per cent utilisation? I don't know.

ANNE LORD:

We could attempt to ask the members within APNIC and try to post some
sort of result on the mailing list during the comment period. That's a
possibility.


KENNY HUANG:

Is that your proposal? That we have some research done?


ANNE LORD:

Are you saying that there's no consensus?


KENNY HUANG:

We only have six votes to agree with the proposal. I suggest if there
is a proposal to the mailing list. ANNE LORD:

We can try and do a small survey and post the results to the mailing
list during the comment period. There was obviously no consensus at
this point about the proposal.


TAKASHI ARANO:

About how many ISPs would take up the proposal and which kinds of
ISPs.


PAUL WILSON:

During the comment period it would be very difficult to conduct a
meaningful survey. There's a great deal of subjectivity in any ISP
staff members or host masters' view of how much trouble that they have
with the process. I think we would need to do some work on finding
objective - some more objective measures. I'm not sure what they are.
I won't even guess at them. But simply to ask who has trouble and who
doesn't I don't think would assist in adding value to the decision. So
if in the view of the chairs we have no consensus I guess it may be
back to some more thought about the survey if that's the view. I would
like to suggest, though, that you put that option to the audience here
as to whether or not we could call the vote again with the alternative
being clearly that there would be a survey. I say this because the
recent APNIC member survey which is being released in time for the
member meeting this week, one of the results was one of the highest
levels of dissatisfaction was the time taken to develop and implement
policies. It strikes me that we shouldn't be going back to this kind
of measure by default, just for lack of consensus, because if that is
necessarily going to be involving the staff, the APNIC staff, in a lot
of work, putting members to a lot of work, and extending the time
taken to make a decision, I think it may be worth just asking for a
consensus on that option, as against this specific option of accepting
or rejecting the proposal here and now. Thanks.


KENNY HUANG:

I would like to have a final vote. Do you agree with the proposal,
please raise your hand. Because the proposal may be supported by many
large ISPs, but I don't know. So if you agree with the proposal,
please raise your hand again. Those who disagree with the proposal,
please raise your hand. It would be difficult to judge as a consensus.


PAUL WILSON:

Please ask about the survey.


KENNY HUANG:

Yes, who wants a survey - please raise your hand. Who disagrees with
the option to provide a survey and also discuss it in a mailing list.
Please raise your hand.


RANDY BUSH:

Separate the mailing list. It is our process.


KENNY HUANG:

Please raise your hand - in a separate mailing list.


RANDY BUSH:

No.


ANNE LORD:

Basically the proposal you're trying to state now is those in favour
of conducting a survey and keeping the proposal open and those not in
favour of conducting a survey and therefore the proposal would close,
because there's no clear consensus. There were 14 in favour. So those
not in favour of doing a survey, that would mean the proposal would be
abandoned, because there was no clear consensus. Would you raise your
hands. So the majority, it seem, want to have a survey.


KENNY HUANG:

So the majority want to have a survey to see in more detail before
making the decision.


RANDY BUSH:

I'm going to be in trouble. I work for a big ISPs. You want a survey
to ask big ISPs whether they want it to be easier for them to get more
address space. I think I know the answer!


KENNY HUANG:

I think we're running out of time. I think we should take a break.
Just a quick announcement. Telecom Fiji is promoting a free raffle
draw. If you haven't already put in your business cards in the box,
please do so, if you want to be in the draw to win a prize.

(Afternoon tea break)


TOMOHIRO FUJISAKI:

Hello, everybody. I am Tomohiro Fujisaki. This proposal will make it
possible to expand IPv6 address space for existing IPv6 address
holders. I want this expansion to be possible without satisfying the
subsequent allocation requirements described in the current policy.
This proposal has been discussed at JPNIC. This is the background on
my proposal. Currently, new IPv6 addresses can simply be - larger
address space. This can become current common practice, on the other
hand, existing IPv6 address holders seems to be - this is because
existing IPv6 address holders applied for the address. They talk about
practice of IPv4's allocation policy. LIRs might believe that they
need this to justify all the other address requirements. Moreover,
under the past IPv6 address allocation policy LIR could only get
partially satisfied with address space. Later this site was expanded
to /32. But this is not based on the LIRs' demand. So summarising the
current problem. I think existing - this is particularly noticeable if
they start the IPv6 service now. Let me show you two examples. LIR-A
got an IPv6 address space two years ago. One year later they began
IPv6 trials. Now they have a plan to start IPv6 commercial service. At
this point, even - they even have to use /32 service, because they do
not satisfy subsequent allocation requirements. LIR can apply to
expand their address space, only the number of customers, it is the
current subsequent allocation requirement. Next, consider new IPv6
address applicant, LIR-B. This is the first application for LIR-B so
they can not apply larger address space with IPv4 infrastructure and
maybe they get enough address space for the service. So, I'd like to
propose we make it possible to expand IPv6 address space for existing
IPv6 address holders, without satisfying the subsequent allocation
requirements. The address size they get should be the same size as
they apply for as new IPv address applicants. And about
implementation. I'm not sure, but if it is possible to expand the
address space for existing IPv6 holders under the current practice I
think it's better to accept the request and announce it as soon as
possible and at the same time I think it should be documented clearly,
such as in the guidelines document. NIR is providing IPv6 address
allocation service, they should implement the same procedure. OK, and
line this proposal is based on real requirements or not. And yes, some
ISPs want to expand the other space if possible. Also, the previous
request of this kind, he said it will be necessary to clarify the
current policy. In conclusion, by making it possible to expand the
IPv6 address space for existing address holders, all LIRs can have
suitable address space for their service. If it is possible, that the
address size, existing address holders get should be the same size as
they apply as new applicants. Thank you very much. This is my
proposal. Ah, do you understand? It's a bit complicated.


KAZU YAMAMOTO:

Wearing ISP hat, I completely agree with your proposal, but I am
wondering if, for example, my company, IAJ has an initial assignment
allocation and after your proposal proceeded, they request much larger
space - address space, do we have to remember current address or not?
Because the initial allocation for /32 is done separately, in - we can
use another space initially but if allocation is down we have to
renumber. So I'd like to know the situation.


TOMOHIRO FUJISAKI:

It is very important point. I want - I think it is based on the
implementation, but I want this expanded numbers.


KAZU YAMAMOTO:

I think that is a good point. ISP want larger space but don't want to
remember.


TAKASHI ARANO:

As I understand, the requester will get the /9 - /29 adjacent to the
current address /32.


TOMOHIRO FUJISAKI:

Yes.


TAKASHI ARANO:

This is your proposal.


TOMOHIRO FUJISAKI:

If they want /29, as much space as /29, it needs some discussion.

KAZU YAMAMOTO:


The current address as /32 holder can expand to /29?


TAKASHI ARANO:

29. /29 plus different block.


TOMOHIRO FUJISAKI:

It depends on the ISPs and if they want to - want continuous block
maybe they have to renumber. But if they Ð


TAKASHI ARANO:

ISP has an option, can choose either the number - renumbering or two
block.


TOMOHIRO FUJISAKI:

Yes.


KAZU YAMAMOTO:

Thank you very much.


TAKASHI ARANO:

I want to ask one question to the secretariat - is this a current
practice? I mean, that if some requester requests this kind of request
- sorry, what do you handle with this kind of request?


SPEAKER:

Can you ask the question again?


TAKASHI ARANO:

In the current practice, how do you handle this kind of request? Is
there no example so far?


SPEAKER:

I just come in the room, sorry.


ANNE LORD:

The basic proposal, if anyone has a /35 address allocation and they
want to use IPv4 structure to justify an additional request has that -
has anyone made that request and how would we handle it?


SPEAKER:

There is one we did receive one of the requests last week and we
advised on the current proposal and we applying the IPv4
infrastructure to allocate IPv6 address space.


TAKASHI ARANO:

They already have /32 and want to expand their space even if they -
doesn't consume Ð


SPEAKER:

That's right. They have received that but haven't reached the ratio.
These policies in the last meeting that they can apply using the
additional IPv4 address, that's why we're using the current IPv4
address but allowing them to extend a prefix to a larger prefix.


RANDY BUSH:

I'm having trouble understanding what's broken - what does this fix?
If people can get a /32 now and they're not using it they don't get a
lot of sympathy from you when they ask for more, but if they need more
that's what we pay host masters, they will get more.


SPEAKER:

I expressed that before getting real start of the commercial service
they would like to design the whole nationwide network throughout
Japan for more larger size of the network. Since they found out /32
will be the little shorter than those larger scaled network
deportments, and the service deportment. That's why they expressed if
they can have a larger size at the very beginning that will be the
more efficient network design can be done.


RANDY BUSH:

More efficient network design? Efficient in what metric?


SPEAKER:

Less fragmented network. RANDY BUSH:

Um, for those of us who were here when we made these kind of decisions
in the IPv4 space and created /As, As which are /8s, et cetera, the
movie is familiar. Why don't we just give every ISP a /8 and there
will be 4,000 ISPs and they can design whatever they want and it's the
end.


SPEAKER 2:

Randy, it's a trade-off between the relevant aggregates and the
process. It's a matter of where do we actually draw the line. You're
arguing that people have to show they're using it and the larger
requesters are coming in saying, "I want to block this proportionally
large so I don't have to come back with a bunch of little blocks and
play the same fragmented scenario we've gotten into before." It's
trying to find that balance, right. The middle ground between too much
space that's wasteful and too small a space that ends up with a lot of
little pieces.


RANDY BUSH:

That's what we did when we went from, let's see, was it... 40s, 38 to
35, and from 35 to 32, and... what's interesting, when you hear this
morning's presentation, the actual use of IPv6 address blocks and Ð


TAKASHI ARANO:

Everyone should understand the proposal. I guess you misunderstand.
OK. He said it's simply unfair for the new address requester - compare
the new address requester versus the old address holder.


RANDY BUSH:

The old address holder gets a free expansion to 32 now.


TAKASHI ARANO:

One condition clarified - just the previous meeting as consideration
of the IPv4 address is different structure.


RANDY BUSH:

That's right. We have the consideration of the IPv4 structure, we have
automatic expansion to /32 so the old folk get the same as new folk et
cetera. But when you look at the actual statistics, there's very
little allocation. There are less than 600 assignments worldwide,
right. And there are 8,000 total /48s users and we're expanding what
we're giving when we're barely touching what we have today. And
prudent engineering might say - hey, let's see what's happening here
and that's why we pay host masters. If somebody actually needs it
today you can get it. You can get it.


TAKASHI ARANO:

You are against the current practice for new address requester, right?


RANDY BUSH:

No, I gave up on that. They can have the /32.


SPEAKER:

No, new requester having /24, that kind of stuff. More than 32.


TOMOHIRO FUJISAKI:

I mean, not - I want to Ð


SPEAKER:

They're just presenting before infrastructure then giving them /20 or
so. That's what we're arguing now.


TOMOHIRO FUJISAKI:

Not automatic expansion, but - I want the existing IPv6 address
holders to... sorry. I want existing IPv6 address holders, if they
want to expand their other space they apply again and they should
demonstrate, as new IP address applicants do, not automatic expansion,
but I want to apply the same criteria, the same justification to new
applicants and existing IPv6 address holders.


TAKASHI ARANO:

Do you understand that mutually? (Pause)


IZUMI:

Do you need further clarification? I'm from JPNIC. This is not
proposing a fundamental change to the current policy. All he's saying
is that in the current policy it allows the consideration of the
existing IPv4 policy, therefore at the moment people can, um, request
for allocations larger than /32 as long as they provide information
about the existing IPv4 infrastructure. However, for those people who
have requested for allocation before this policy was passed they
didn't know about this, so most people just simply requested for /32.
So there's inconsistency between those who have requested v6
allocation before this policy was passed. For those people who had to
request it for allocation before the policy was passed they should be
given allocation under the same condition, that's all he's saying. I
hope this clarifies his point.


RANDY BUSH:

But they're not using it.


GEOFF HUSTON:

Hopefully I can help here. If, for example, a company decided to do a
small trial of v6 and got an allocation of a /32 under the policy as
it stood, and then said, "right, I'm going to roll it across my
existing v4 infrastructure as dual stack," then - if I understand this
proposal correctly - they're saying well, give that intent and that
engineering to roll it across an existing IPv4 infrastructure are we
allowed to effectively count our v4 customers as a subsequent
allocation to the /32 on the basis this rollout is now based on the
existing v4 infrastructure we have already deployed and are now moving
to dual stack. That's what I understood I heard. Did I hear that
correctly? Is that a nod for a yes, is it?


TOMOHIRO FUJISAKI:

Yes.


PHILIP SMITH:

My question is, has anybody actually been denied the address space
they need by APNIC at all?


RANDY BUSH:

Ever?


PHILIP SMITH:

Has anybody come to APNIC and said APNIC told them you can't get
address space because our policy says you can't - has that ever
happened?


PAUL WILSON:

Could I answer that? There was a case where that situation was
possible by a literal interpretation of the policy, because, as we've
heard, the policy says that this use of IPv4 infrastructure to justify
a v6 allocation applies only to the first allocation. So we had a case
where an ISP had received some space before, then wanted to make use
of that policy to justify a certain allocation, obviously a larger
one, based on their large v4 infrastructure. I was asked at that time
to make an executive decision over that interpretation, because the
literal interpretation was that this would only apply to the first
allocation. Now, my belief was that that was not the intention of the
policy. So in fact, we granted that allocation, which is what Son Tran
was trying to explain before. We've before talking about this for
quite some time and I have a feeling we're going around in circles
somewhat but I hope that helps.


RANDY BUSH:

But that's Philip's point - that's why we pay host masters and that's
why we pay you, is because supposedly you have brains and you're not a
machine I put a quarter in and get an address block. Or... and so,
nobody has not gotten the space they need, ie - to get rid of the
double negative - everybody has gotten the space they need and can
justify. What does this fix?


PAUL WILSON:

I take your statement as a compliment, Randy, mainly because they're
so few and far between!


RANDY BUSH:

(Laughs)


PAUL WILSON:

The problem is the policy says something literally different from the
practice. I don't particularly want to have to be asked and to make an
exception every time this issue comes up again so if we fix the policy
then the practice can follow the policy. I believe one of the problems
here, it may be that in the case of some NIRs, they haven't
interpreted the policy more literally and did not make the exception I
was asked to make in one individual case. I'm not sure if that's the
specific issue, but the question is to fix the policy document to
reflect the policy and the intent of the policy. It's very simple,
really. Thanks.


TAKASHI ARANO:

Any comments, questions? OK, I will take a vote for this proposal. How
many of you in favour of this proposal, raise your hands. Can you
count... (Pause)


SPEAKER:


14 TAKASHI ARANO:

How many are you are not in favour? Raise your hands. OK, this should
be a consensus, and according to the - Paul's comments, we should fix
the policy document - after the two months have passed and this
proposal will be approved, could you work on that - how to correct
this proposal - contents. OK. Any comments? No. OK, thank you very
much.


TOMOHIRO FUJISAKI:

Thank you very much.

(APPLAUSE)


TAKASHI ARANO:

Next one is IPv6 address space management by Geoff Huston.


GEOFF HUSTON:

(pause while presentation is set up)

Good afternoon. I will speak more slowly this time. We don't seem to
be under as tight a time constraint which will hopefully relieve some
stress from some people. This is an informational presentation trying
to look at what would the world be like and what would the kinds of
allocations happen if we were dealing in v6 today rather than v4 and
had been for years. I've been trying to simulate what a v6 registry
would've looked like over the last few years using the raw data that
we've got from allocations coming from v4. Let me give some background
because what I am trying to do is to, rather than discuss numbers and
bits, actually try and look at allocation boundaries on the basis of
experience and data so that we can actually ground some of these
discussions about a /8, /12, /14 and so on and minimum allocations and
look at it from a more practical viewpoint and say if we had the same
level of uptake and demand as we're currently seeing in v4 and had
done for some years and we're operating in v6, what would a registry
look like, what sort of consumption would it happen, what sort of
allocations would happen down the line? To ground this a little bit,
here's this quick tutorial on where the current IPv6 address
architecture divides its bits. At the top there you have the 128 bits
divided in half. Because the IETF decided the lower bits were
irrelevant. We wiped them out and it's the upper 46 bits that are
important - the global routing bits. That was then divided into three
parts. 

Every customer, there's some sort of issue what a customer is -
let's just call it a customer, has 16 bits of local sub-netting, There
are 45 bits of an aggregate provider prefix and currently there are
top 3 bits of format and if you look at it only one of those possible
8 values has been assigned for global unicast. I think another two
others have been assigned for other purposes, five are currently in
reserve by the IETF. You have 45 bits in the middle to play with as an
aggregate provider prefix. However, we've done a little bit more
slicing here. On the third line the minimum allocation to an LIR or to
an ISP is a /32. In other words, 16 bits is what an ISP or an LIR gets
to play with as a minimum allocation. They may get more but that's the
minimum. The routing entry prefix of that entity would insert into the
routing table would be a / or 29 bits or possibly less. But that's the
size we're playing with. Let's look at those 29 bits again. Currently
RIRs receive allocations from IANA as a /23. That gives them nine bits
to play with in terms of their allocations to LIRs and ISPs. The rest
of it is used by IANA and divided up and allocated out. Currently the
allocation pull in is a /23, or nine bits to play with. Here's what it
looks like in general. You have the 64 bits at the end, the 16 bits of
customer sub-net, the 16 bits of a minimum LIR or ISP allocation then
29 bits which is kind of the global routing prefix we're working with
and three bits off the top which is the format prefix. What are we
doing? why do we have all these policies? Why doesn't everyone just
get a /34 and go home? In theory we've found addresses aren't much
value unless you route them. Routing isn't much value unless it works.

Certainly what we understand today is that we don't understand what a
billion entry routing table would look like but we have a vague
suspicion it wouldn't work. We have a vague suspicion a million might
work, it might not, in today's technology but under a million we're
probably OK. What this means when we're considering address
architectures for a technology we want to use for decades if not
centuries is we want to set up address architectures that have
relatively strong aggregation properties, because you might say that
Moore's Law from the continuation of silicon might let us do a billion
node routing mesh in some future - point in the future but we have no
idea what that routing protocol would look like. We are really unsure
irrespective of the amount of silicon that a massively large network
would work with existing technology. We have no idea what the new
routing technology might look like. We have to be conservative. That
conservative outlook in routing is expressed in a conservative outlook
in aggregation. We're trying to preserve aggregation as much as we can
and avoid fragmentation at the allocation levels. So, how do you try
and preserve aggregation? When you open up a window of allocation to
an LIR or an ISP you'd like to continue to service them so that when
they grow bigger their prefix simply gets, if you will, the size gets
bigger or the slash value gets smaller. You don't give them a /32 from
here one from there, and after ten years they have 10,000 /32 and
10,000 routing entries. You'd prefer them to have a /20 and a single
routing entity at the end of those. The profile of requests is
relevant because you want to be able to allocate from the same window
over a large period. We've chosen a host density metric that we've
commonly accepted as a 0.8 log-log ratio. I don't want to go into much
of the mechanics. Within the parameters of trying to look at how we do
aggregation the host density measurement is an important input. How we
assess when any old network has reached a level of utilisation that
says, "if you go further you're going to do contortions with
addressing and possibly NATs and other bad things for v6" we've chosen
a host density metric that says once you get to that metric you're
probably full. Open up your window further, increase your allocation
size, increase the A space in your routing entry and press on without
adding more routing entries. Also the allocation lifetime. When one
receives an allocation how long is it meant to last? How long should
the window be open. The other part is - what kinds of allocations make
practical sense in management and what are allocations that cause
heartache, pain and effort? In the reverse delegation space, the
IP6.arpa space, it is certainly a lot easier operationally, and easier
generally means cheaper and more efficient and simpler, to do
allocations on boundaries of nibbles. /8, /12, /16, /20, /246789 /23
is indeed an interesting number and a harder number to work with. Of
course, the last bit is what kind of address pool management does one
use inside the RIR to keep these windows open for as long as possible?
Those are the parameters under which I was looking to try and
understand what are we talking about in numbers over the last few
years if we've been doing v6 instead of v4 with the same level of
demand? Here's just a quick few illustrations of where we are and
what's possible, perhaps. Currently RIRs get allocations of /23, that
allows them to do at most 512 /32 allocations before they need another
one. If you're looking at aggregation, certainly that's a very limited
timeframe. My original point about having allocation windows open for
years to try and preserve the sustained longevity of the routing
system within the bounds of the technologies that we understand this
appears to be an extremely small allocation unit and certainly has
some issues in sustaining strong aggregatability at that point. The
two at the bottom are quite in the other way - you see by the amount
of blue there. A /12 allocation allows a pool of 20 bits or - sorry,
10 bits, approximately /32 allocations. If you went the next four bit
you'd have a /8 of up to 17 million /32 allocations. Those are the
parameters I'm looking at. What I'm trying to understand is what's the
size of a pool which an RIR could operate, which could sustain good
aggregation over an extended period? So what I did was simulate v6 and
v4. 

The RIRs publish their delegation actions. They publish them and
update them every day. They date their transactions by the day it
happened. So there's a model of what we did in the last few years, in
fact what we've done forever in IPv4. What I've I done is said let's
assume these are v6 transactions instead. And they're equivalent.
What's equivalent? What I've done is made an assumption - you could
argue but it but it's a starting point here of the discussion - of
saying in v4 it might well be that customer is a /32. You could argue
about it but that's where I've started from. In the IPv6 addressing
architecture as I understand it the customer is a /48. I've said look
at the number of /32s and equate the number of /48s sort of. When we
do an allocation in v4 we're seeing it's an 80% utilisation density.
In other words, an ISP says I'm going to deploy across this many
thousand customers, it's - well, that would be 80% of a v4 allocation
of this much, whereas in v6 we'd use an HD ratio of .8. There is a
minimum size in v4 of an allocation - currently a /21 around most
RIRs, equally there's a /32 in v6. The other thing that's a little bit
harder because the delegation files don't tell me this - a lot of the
allocations that happen in v4 are folk expanding their allocation
windows. I'm making a guess here, I've put it in as a variable in my
simulation - I've assumed that the number of new LIRs and ISPs that
have opened up in the last few years is around a rate of 20% of the
allocations, so the other 80% are expanses. The number of LIRs and
ISPs that open up as a consequence roughly equates to the data I see
of RIR membership. It's a variable and you could change it. The other
thing to understand - how long was the v4 allocation intended to last,
what's the existing policy and operating practice? It seems to vary
across the RIRs but I've made the assumption that it's a mean frame of
around 12 months expectation with some length extended tail. Again in
the model I've added a random factor that creates a distribution where
12 months is kind of the low order mean but it tails out a bit. So
there's an equivalence if you will, if you say well, if I had 5
million customers, and a v4, if you could justify that you'll get an
allocation of around a /9 if they were 5 million /32s. Using the HD
ratio of 0.8 and applying the same metrics as customer numbers into
v6. 

The equivalent allocation in v6 would a /20. That table gives you
the threshold equivalences where when I see a v4 allocation of a
certain size I can approximate a v6 registry allocation of v6 column
size, that roughly says it's the same customer count. I'm trying to
place some numbers. Assuming all that, I then drive a registry. I
start from 3 years ago, 2001, August, and look at the delegation that
is happening month by month. I've done it for each individual RIR. The
top line is LACNIC, the next line RIPE, the pink line is ARIN - I
thought ARIN was a rather pink registry - and the blue line was APNIC.
I've done a total of the lot down the bottom - the orange line. The
slide is a logarithmic vertical scale, /32, /28, and so on. The bottom
is in months. So, for example, most of the RIRs with the exception of
LACNIC, would consume a /20 within about half a year if v6 was the
same as v4 today. In other words f we've been dealing in v6, there
kind of simulations as we've probably chewed through a /20 in six
months. In 12 months you'd be halfway in, around about a /18. If
you're doing 4-bit boundaries you'd be on a /16. With most of the
registries a /16 would carry through for over 36 months. I don't think
v4 is the same as v6. When I look at the allocations that happen in v4
then look at things like host counts and all the folk behind NATs. who
is behind a NAT today? Hands up. I want to know. Normally most folk
raise their hands. You guys are in a weird world. What's the ratio of
NATs to real? Hard one to guess. I've just done a simulation that says
it's 2:1. Now you can make it 1:1, but I've just assumed 2:1. If we
were doing v6 the real customer count would be higher because there
would be no NATs. If I add in a NAT factor to that simulation what
happens is around the 12 to 18-month period, in other words 1.5 years
ago on a three-year time window, most of the RIRs, with the exception
of LACNIC would've chewed through a /16 and to service their
requirements of a period around 36 months would need to run out of a
/12 within those parameters and assumptions. It's trying to put some
figures on how fast does the network grow and has it grown over the
last three years. If those same customer numbers were driving v6 how
large would the allocation pool need to be to preserve strong
aggregation over extended period of time? Within the current
parameters of the IPv6 address architecture, within that assumption of
the kind of NAT densities that we're seeing today, which in some DSL
rollouts are up to a thousand to 1 and others are zero to one, in
other words there's no NATs in some cases and deep intensive use of
them in others. I've said 2:1, with those kind of parameters it's
around a /12. 

I'm still looking at aggregation and trying to
understand within those parameters how good is aggregation. The
current way we allocate IPv4 is sequential. When a new LIR or ISP
comes along we start at the next free address open up a window, give
them a minimum allocation to that window and keep that window open for
somewhere between 12 and 24 months. If they don't come again you
re-use it. But it's kind of starting at the left and working right or
starting the other way round - with v6 maybe we're just not so sure
about how big things will grow. So one of the other mechanisms that
has been proposed, discussed in Taiwan some time ago, and discussed in
other areas is a thing called sparse allocation, where instead of
doing it sequentially you try and make each allocation equidistant
from the others, so the first allocation you start at the first point
but the second one is in the middle of the space. It starts dividing
into quarters then 8s. So you're dotting your allocations all over the
place to try and preserve the distance - in other words trying to
preserve aggregation. As well as trying to keep these allocations
approximately equidistant you look at the rate of each LIR the's
growth and you make a selection based on maximising the time. You try
and pick the slowest growing window and subdivide that in half. Over a
36-month period you can start looking at this from a different
perspective. How much fragmentation happens if you are dealing from a
/12 across 36 months? When the block starts to fill, how do you
fragment? The existing IPv4 does start to fragment. Once you get to
50% you have 200 fragments going on. Once you get up to completely
full there's around 700 fragmentary allocations. I'd liked to have
blocked them together, it didn't happen. When you sparse allocation -
the pink line - you can depress that quite a bit. You can still get to
a 100% occupancy. But the large ones grow over that same period and
cluster the small ones. So that rather than fishing at 100% full with
700 fragments you're down around 200. If you do rate control as well
and pick the slowest growing you can halve that again to around 100.

It does show that in the large enough pool to work from over an
extended period of time you can do what we said we were going to do
with this entire process - make routing work for as long as it
possibly can. And stop the routing environment explode into thousands
of tiny - in fact millions of tiny fragments. So there are ways, if
the block is large enough and the period is long enough. From what I
can see from this simulation, within those parameters, carefully
qualified statement that I have made some assumptions here, a /20
block is smaller than the allocation window of some individual
allocations. You can't preserve strong allocation at that level. You
could take it to the next point at a /16 and using a framework where
you assume there have been no NATs in v4 and there were no NATs and
those customer counts are real that /16 would work. If we factor in
NATs in v4 then the equivalent model in v6 would exhaust in months.
The next Neville point, a /12, it would indicate a block space of
around a /12 would have a period of lifetime of at least 36 months
with minimal very minimal fragmentation over that period, if you use
rate managed sparse allocation. That was the results of the simulation
that I did. I'm interested in pushing the model up on the web so you
can play with the variables yourself, but time and space committing. I
just wanted to let you know about the parameters I've been looking at
to try and get away from the discussion about bits and numbers and
start looking at what's the rate of business we've been doing, how
does that affect what we're trying to do - which is strong aggregation
and what's the impacts of that in routing systems and then look at
what allocations make sense under that kind of environment. Thank you.
Questions.


SPEAKER:

Could you back up to your three-year graph. Just trying to figure out
if you had thought about a five-year - if we're picking a number here
and trying to look at maintaining aggregation over a longer period,
why stop at 3, why not pick something a little bit further out and how
much impact does that have?


GEOFF HUSTON:

I could probably speak until 6 o'clock and keep modelling it through.
The entire IPv4 space under that set of assumptions since 1983 across
all RIRs, the entire delegation file, is around a /11.2, assuming no
NATs. I haven't done the with-NAT assumptions built in.


SPEAKER:

A 20-year model fits in slightly smaller than a 12?


GEOFF HUSTON:

With no NATs, yes.


RANDY BUSH:

Done any sensitively analysis to your parameter guesses?


GEOFF HUSTON:

Yes. The sensitivity analysis is changing the new allocation rate,
doesn't make a lot of difference. Changing the HD ratio makes some.
Changing the fixed 16-bit sub-net, /48 into something more variable
makes a lot. So that there are parts of the current addressing
architecture that have significant impacts on this kind of outcome but
the basic work is - within the constraints of the IPv6 address
architecture as we know it.


RANDY BUSH:

What about some of the assumptions like IPv4 space and customers at
/32?


GEOFF HUSTON:

I've yet to understand the variations of those models of what
parameters that I change but it's useful piece of work to continue
investigating. Thank you.


TAKASHI ARANO:

Any other questions? I have one. You simulated other fragmentation by
a three method. Do you have any simulation about dead stock, caused by
the three methods.

GEOFF HUSTON:

When I say 100% full I mean 100%. In other words, there is no dead
stock at that 100% point. What I do in the simulation is when I get
close to 100% and someone wants a big block I keep on subdividing it
right the way down until it fits. So when I say there are 100
fragments I mean 100 fragments and no dead stock. This is full not
just a little bit full.


TAKASHI ARANO:

If you employed sparse allocation, do you think you can totally use up
the address space?


GEOFF HUSTON:

As you see on the graph behind you, even in the best managed sparse
allocation you will get some fragmentation right at the end but that
algorithm does make the slowest moving ISPs bunch up together and the
ones that are accelerating fast have their window open for the
longest. They keep on getting larger allocations and aggregation is
preserved under that. But the underlying assumption is the pool is big
enough over time that you can keep servicing them over time. And this
is this whole issue about if I'm dealing in a /23 coming as input
you'll get amazing fragmentation very quickly. And the outcomes of
this appear to be at least over a 36-month window, a /12 allows you
strong aggregation outcomes, right.


TAKASHI ARANO:

Eventually.


GEOFF HUSTON:

Yes. Thank you.


TAKASHI ARANO:

Any other questions? OK. Since this is an informational presentation,
so I will take no vote!

(APPLAUSE)


TAKASHI ARANO:

The next presentation is IANA IPv6 global allocation policy by Paul.


PAUL WILSON:

Good afternoon. This policy proposal is following the informational
proposal by Geoff because Geoff's results provide us with some input
for this particular proposal. Some of the justifications based on
Geoff's results. I'll be with you in a second. Pause while setting up
computer presentation) There's a first time for everything! (Pause)
Sorry about that. This is a policy proposal regarding IANA's proposal
for IPv6 allocations. It's one of the few policy proposals that needs
to go global before it can be implemented. It needs to be implemented
by the IANA. As such it needs to go through the ICANN, ASO and ICANN
global policy processes. This is the first time at which the proposal
has been presented, so it needs to go from - if it's accepted, it will
need to go to the other regions. We are in fact in need of this policy
proposal as I'll show. It will come up in the other regions
nevertheless but in order to decide on a global policy and to be able
to put that into the ASO and ICANN policy process we need to have a
consistent proposal approved in all of the regions. The background in
terms of the policy proposal - and the global policy status is that we
have in the IPv4 case, a policy for IANA's resource request procedures
which describes the policies for RIRs to obtain IPv4 address space
from the IANA. That went through the global process receiving
consensus, reaching consensus in all the RIR communities. The global
policy process is still under way. It's that proposal is pending ASO
and ICANN policy actions. The first of those will happen we hope this
week with a meeting of the address council. I won't go into the policy
processes that r there, but suffice to say that proposal was approved
in all the regions. We're operating with the IANA now on the basis of
that document, but there is no equivalent IANA RIR document as an
approved global policy for IPv6 although there even been several
documents and ideas circulated. For the current system we have with
the IANA is a system based on for IPv6 this is, a system based on an
interpretation of RFC 29, 28, which laid out the initial applications
for IPv6 space for RIRs. In that policy each of the RIRs receives a
/23 block at a time. Every time we need additional IPv6 address space
we go back to the IANA and receive a /23. In a couple of cases
recently large LIR or ISP requests have triggered special case
allocations of larger than /23 by IANA but the /23 is regarded as the
allocation unit. We're implementing a minimum allocation of /32. I
think fairly consistently the RIRs are reserving a /29 and allocating
- or reserving those blocks, those 29s, sequentially through the /23s.

That means we only have 64 requests possible within each of the IANA
allocations. If any of those requests grow beyond or need to grow
beyond their /29 allocation they're not going to be aggregated with
any subsequent allocation. So the current problem is that we've got a
system that's based on a couple of sources. An old RFC as well as the
IPv4-like allocation process without a globally agreed policy through
the RIR process. IANA to RIR allocations are quite small against a
reasonable allocation timeframe for those allocations, so we're
sacrificing aggregation, in other words I'd say it's a loaded
statement but I'd say we're creating an IPv6 swap by this current
ongoing allocation system. No-one by the way is defending the
currently system. The IANA, as much as we do, the IANA folk want to
change this and get something sensible happening. It's certainly not a
case of anyone trying to defend the current system. It's there because
of the reasons I've said. But as we know, we've observed long-term the
effects of fragmentation with IPv4 and of course, we're all here to
avoid any mistakes of the past that we possibly can. That means
maximising the potential for aggregation in IPv6 as soon as possible.

I'll note also here that the IPv6 allocation policy for RIRs to their
members, ISPs and LIRs, actually does emphasise aggregation more
strongly than conservation. That's in sections 3.4 and 3.5. I think
what is reflected there is the fact that IPv6 is a very large address
space, we don't have to be so concerned - this is what the policy
document says - about conservation - but particularly because it's a
very large space and as Geoff mentioned before it needs to last
decades, if not centuries. Who knows how we transition out of IPv6 to
the next version. But it needs to last for a long time. Hence the
long-term effect of fragmentation could really balloon out into
something very dramatic unless we're careful, as I say, to avoid the
mistakes which we have seen, which are proven with IPv4. So the
background of this proposal is we had another proposal which was
accepted or documented as RIPE 264 back in October 2002. It was that
proposal for a single sparse allocation mechanism globally. It was
taken around the RIR communities, it wasn't accepted by any of the
communities. 

There was apparently a consensus or a widespread stated
belief there was a need to continue the regional allocation system,
for a number of reasons. One of them was a perceived need to be able
to identify RIR blocks in this single allocation pool being
administered globally for the entire space. That proposal was not
accepted. There was a follow-up in July 2003, at least for us here the
document was published then. It was a fairly simple proposal
requesting larger IPv6 allocations from IANA. And the associated
practice of sparse allocations in the APNIC case. There was a general
consensus on some of the terms of this proposal, the proposal would
maintain regional allocations, to each of the RIRs individually. The
RIRs would be choosing their own allocation system according to their
own policies, which is one of the reservations about the single global
pool, it imposed a global allocation system on all the RIRs which may
not have suited them in every case. There was a consensus, I believe,
I'd like to ask the other RIRs to confirm this and report
comparatively on what's been going on there, in the other regions,
there was a consensus on larger allocations from. IANA between a /8
and a /12. I think that was not accepted widely for - it did not
continue on into the global RIR process because of - it was not a
comprehensive policy that would give the IANA the policies that it
needs, so that's where we stop. There's no new proposal. This is
intended, as I said, to be a global policy proposal or to contribute
to the development of a global policy proposal along these lines. I
think in the previous efforts I think RIR staff and hopefully the
meetings themselves have learned a fair bit about the time that this
can take. 

It can be a long process and in the case of this policy we
don't want it to be a long process. We're trying to keep it as
streamlined as possible, I think or at least from my side I believe
that's important such that we can keep this thing moving. So this
proposal is trying to be laid out in a logical fashion. Firstly with
the basic allocation principles. The first of those is the /12 is the
initial and the minimum allocation by the IANA to each RIR. That's
based not only on some of the previous consensus that we saw from
those previous proposals but also on much more comprehensive work
that's now been done by Geoff in terms of if we actually model the
consumption of IPv6 address space against what we've seen with IPv4
then what's really a workable size of address block. I think the -
making that judgment in the past has been quite difficult. It's sort
of a process of just guessing what sounds like a good number. What
we've seen from Geoff's result is /12 is a pretty reasonable amount of
address space. We do want a larger rather than smaller size of block,
simply for the reason of maximising aggregation. If we have a range of
block sizes of reasonable block sizes available to us, then being
conservative we would select the lowest one and we would expect IANA
to favour the smaller size of block but as I've said we have an
emphasis on aggregation over conservation, really are arguing - this
proposal is arguing for the larger end of that scale in order that
aggregation in the long-term is the opportunities are increased. The
other principle, the IANA will allocate sufficient address space for
36 months. 

With each allocation to the RIRs. That also is allowing
greater aggregation than we're currently able to achieve with IPv4.
The IPv4 allocation window, if you like, is 18 months. We've doubled
that as what appears to be a reasonable forecast into the future. A
fairly basic principle is the IANA allows each RIR to apply its own
allocation and reservation strategies. There is now several parts to
this policy proposal which are more or less clauses in the policy
document which has been written. One of those is that we - I proposed
in authoring this document in the first place, that we would like to
see a reservation for each RIR of a - a /6 was suggested, making it
easier to identify regional address space from a single block to
facilitate aggregation and the proposal named reserve /6. I would like
to withdraw that provision of the proposal, so I'm just explaining
here that the document that is published will not have the
reservations provision in there. It did seem that that raised some
doubts, question marks, I think there was some comments that it
appeared to be some kind of effort by RIRs to presubdivide the address
space, maybe pre-guess the possible future changes in management at
the IANA level, I'm not sure. But it seemed to not be a popular
provision of the policy. The next one is the initial allocation size.
This is fairly simple - that immediately the policy becomes active
IANA will simply allocate each RIR the first minimum allocation size
of the /12. 

That allows us to start as soon as possible on
aggregatable allocations. It leaves us with a small pool of existing
address space which I would suggest is better reserved or left to the
RIRs for their own devices, then maybe such cases as critical
infrastructure, assignments or other types of purposes to which that
address space is put. As I say again, the emphasis here is on
aggregation and the sooner we can have the freedom to allocate out of
larger blocks, the better. The other - the second sub-clause here is
is that each new RIR receives a /12, a minimum allocation on approval
by ICANN. That's just simply, if a new RIR comes along then it
receives that address block. Subsequent allocations. Eligibility
firstly, is that an RIR would be eligible to receive a subsequent
allocation when it has allocated or reserved at least 50% of its total
address pool. At the moment under IPv4 policy, we've got a requirement
to reach 80% of the total IPv4 address pool, before we come back to
the IANA for more space. Once again, the reason for relaxing this
criteria from 80% down to 50% is to increase opportunities for
aggregation. Again t might appear to be compromising conservation but
that's exactly what the policy proposal we've already accepted allows
us to do. 

To put it crudely - aggregation is more important than
conservation in terms of the balance that we're used to with IPv4. The
size of subsequent allocations. Previously, the original proposal as
posted is the size of the - RIR will be one bit shorter with each
additional allocation. That's based on the current v6 policy for
allocations to ISPs because we do exactly the same thing. We make an
address allocation, we shorten it. Rather than allocating separate
possibly non-contiguous blocks. that also is something that I have - I
wish to withdraw from the proposal. Primarily because it's only
feasible if the RIR reservation is available. Also, because that
regime would involve larger and larger additional allocations to the
RIRs which are arguably not needed under the result that's been
produced here. So a /12 is really a large address pool. It's just
finally large but it's a large address pool and to anticipate rapid
acceleration in the future where we need larger and larger blocks than
/12s is probably not necessary and possibly sending the wrong message
again in terms of RIRs, or APNIC's possible ambitions to collect more
address space than we could justify. Messages like that are messages
we want to avoid, obviously. The size of the subsequent allocation
therefore under this proposal is simply a multiple of the minimum
allocation size /12 and a multiple one or more, sufficient to ensure
the RIR address pool satisfies at least a 36-month requirement. This
is quite similar to the new IPv4 global policy. Where rather than /8
units - IPv4 we're suggest /12 units and allocating them as needed to
the RIRs. 

That leaves the administration of that pool to the IANA. It
doesn't pre-suggest or bind or require IANA to make reservations or to
manage it in any particular way. Other provisions. We have asked in
the current IPv4 global policy that from an administrative standpoint
the IANA should announce its allocations to the RIRs and update its
public records. Just to add a little to the justification of that -
well, we're asking for that provisioning in both the approved v4
global policy so it makes sense to put into the v6 policy as well and
it's just to do with the consistency and timing of announcements that
the RIR chooses to send to its community. We like to address the
impact on NIRs and any policy proposal here at APNIC. So, I feel that
there's no, under the current direct allocation scheme, no impact on
RIR, on the NIRs' fundamental administrative requirements. I'd be
interested in any comments about that from JPNIC and others. The
benefits on the other hand, are to allow the members of NIRs to
maximise their ability to receive aggregated blocks as is the same
benefit for all ISPs. The status of this proposal is that it was
posted - originally - on 4 August. It was announced out of interest of
- by the members of various communities, announced to local mailing
lists in the other RIR regions. Feedback:

Several of the comments that we've seen have been strongly in favour
of that. There were queries regarding the 36-month timeframe for
allocations, whether that was justified in comparison with the IPv4
policies and also with the v6 policy for comparison with ISPs. There
was some comparison regarding the large reservations and the doubling.
For those reasons in this presentation a couple of the provisions of
the proposal have been withdrawn. Status and the other RIR regions.
For ARIN there has been a policy proposed by one of the ARIN community
members. It's very similar. It has a /12 minimum initial allocation
size, allocations for 18 months, as against 36 in the case of this
proposal. The 50% utilisation requirement is there. It's slightly -
it's worded slightly differently. It may be - whether it's the same is
open to interpretation, I think. It suggests reservations of /6s, and
it does say quite usefully, I think that the IANA will process
requests according to the agreed administrative procedures again the -
between the NRO and IANA which is something that hasn't been - wasn't
explicitly stated - sort of implicit - in the v4 global policy. It
also says that these procedures get enacted within 30 days of approval
of the policy. In the LACNIC region, the ARIN proposal was forwarded.
Circulated and as LACNIC staff have reported - reported there are
members of the community preparing their own text to send to the
discussion list as a proposal. In the RIPE region, a proposal was
submitted which I believe is identical to the original proposal from
APNIC, from myself. 

The next steps in the global policy process. I did
mention this before, but just quickly, we have discussion in RIR
communities followed by consensus of those communities, hopefully. The
NRO forwards the policy proposal to the ASO. The ASO needs to review
the policy process to ensure that the global consensus way arrived at
through a mechanism that was open and transparent and in accordance
with policies. It will then - assuming that's the case - forward on to
the ICANN board for ratification after which it becomes implemented as
global policy. There is a few more steps involved with this to do with
forwarding of policies for public comments and so forth by ICANN. Once
it's implemented through that proposal all things going smoothly, we
would then have global policy in place that would apply. I'd just like
to summarise the main points of the presentation and of the proposal.
The initial and minimum allocation of IPv6 is a /12. The subsequent
allocations are simply - that is subsequent allocations from the IANA
to RIRs, are simply multiples of one or more /12 blocks. That is the
minimum allocation size. IANA allocations are made to provide the RIR
with at least 36-month total address pool based on current
consumption. The RIR receives subsequent allocation from IANA when 50%
of its address space is utilised, allocated or reserved. The IANA is
to process requests according to IANA and NRO agreed procedures which
I think is worth making explicit and that final comment for
consistency with the other policy document is that we would like to be
communicating with our communities in accordance with RIRs' policies
and timing and administrative procedures. And that's the end of the
presentation. So thank you very much. I hope there'll be some
discussion about that.


TAKASHI ARANO:

I propose three things to proceed this discussion.... extend the time
for 20 minutes, before the next session starts. That's the one thing.
The second thing is that we would like to divide this comprehensive
proposal into four sections. One is initial allocation, second one is
subsequent allocation, third one is reservation by IANA, fourthly IANA
announcement. Is that OK?


PAUL WILSON:

And the 36 months?


TAKASHI ARANO:

Should be included. I believe we had general consensus on the RIRs
should currently receive the larger allocation under /23. The size was
not decided. That was /8 to /12 or something like that. We would like
to start based on discussions should be based on this consensus. We
would like not to re-discuss this kind of larger allocation, is this
OK? If you have any questions about these basic things, please later
question. The first part is about initial allocation. Could you give
me slide. Just initial allocation, minimum allocation, should be /12,
right?


PAUL WILSON:

(Nods)


TAKASHI ARANO:

Any question or comments about just this initial allocation? The new
RIR can also receive /12. (Pause) Is there any question or comment
about the initial, just the initial allocation? OK. Can I take a vote?
(Pause) He wants to take a comments for everything. Do you have any
opinion, comments? Questions? Whatever? PAUL WILSON:

I just feel some of these issues are interlinked and in terms of
comments that some people might like to make it may be easier to
address more than one of these issues at a time.


RAUL ECHEKERRIA:

My name is Raul from LACNIC. I would like to say - the proposal was
partially in the LACNIC list in terms of - the proposal was announced
at the RIPE NCC community. One question is - this is supposed to be
the mirror of your proposal. That's a different - what you are
presenting now with subsequent allocations.


PAUL WILSON:

That's correct.


RAUL ECHEKERRIA:

The second one is I assumed that it was a mistake in your speech, but
you say that the IPv4 allocations received from IANA to LIRs are
basically the role of 80%. Currently we are using the policy that will
surely be approved very soon. And the difference of 80%. My question
is in relation with this comment, what is the justification for you to
change this rule and propose this in a percentage instead of in the
percentage of the use of addresses in the region.


PAUL WILSON:

For the benefit of everyone could you actually summarise, please,
Raul, what the v4 policy is, because I think it may not be familiar to
everyone.


RAUL ECHEKERRIA:

The RIR doesn't have enough addresses to serve the community for a
given time you can apply for additional allocations and you should
receive a total set of addresses, enough to serve your ratio for the
next 18 months.


PAUL WILSON:

You're quite right. I just felt it was worth summarising.


RAUL ECHEKERRIA:

I think the given time is six months.


PAUL WILSON:

That's something that is an alternative Ð


RAUL ECHEKERRIA:

The question is not exactly as the number of months that are included
in the policy. Is the change - currently the policy is based in the
projection of usage of addresses in - we are proposing to change it...
to a percentage of the RIR stock.


PAUL WILSON:

The justification of 50% is that it relates directly to the address
space that's on hold and the fact that you want to make - you want to
receive some - the RIRs should be able to receive more address space
before that address space is run down to the point at which
fragmentation is going to be more likely. The requirement of 50%
utilisation is a simple measure that doesn't relate to allocation
rates. It simply relates to the status of the pool that you have and
the - with respect to how much has been allocated and how much is
left. As for a comparison with the current policy, I guess my
explanation stands as it is. I won't comment on why it may be
different.


RAUL ECHEKERRIA:

I would not like to bore you, but I'm not questioning the 50%, the
number. This is not... what I'm asking is what the policy should be,
applying for additional allocations to IANA. It should be based on a
percentage instead of in the projection of usage.


PAUL WILSON:

I just tried to say that to base it on the percentage makes I believe
is a simpler policy, because it relates solely - all you need to do is
look at the address pool that exists, how much of it has been
utilised, how much of it remains and that gives you a very - an
instantaneous answer. What the alternative is is more complicated in
that you not only have to do that, you have to look at the current
rate that you're currently using, measure that against what's
remaining, and project forward and do a further calculation. So I
suppose simplicity was the reason that...


TONY HAIN:

It's probably a language problem in switching between slides here but
your further bullet seems to presume an instantaneous response because
you're gonna receive it as soon as you utilise 50%, but earlier I
think you said "You are eligible to request". So this slide in the
summary is probably the wrong language. It should be "Is eligible to
request" then when IANA actually finishes the process is when they
finish the process and that may be later than your 50% number, but
that's OK. You're trying to give yourself 50% as a starting point so
you have enough time to make sure you don't fragment by the time they
finish their work. I think that clarifies some of the previous
discussion a bit as to why you want to lower that.


PAUL WILSON:

I think I've probably just adjusted that wording and you're quite
right it's inconsistent with the other slide. The RIR may request or
is qualified for a sub- not that they receive it.


SPEAKER:

My question is regarding the application procedure. What if APNIC
passed a proposal as proposed here and what - where IANA, have their
right to ratify the proposal.


PAUL WILSON:

The proposal, if it's passed here, that is simply one step in a
possible global policy process. The global policy process will only
end when the same essentially the same policy is approved at each of
the RIRs. So we have a chance here to reject this and go back to the
drawing board in case of the APNIC case, to accept this exactly as it
is, and then if it happens that exactly the same policy was approved
every where else then we could move on to the next step. There's a
very reasonable chance, given that this is the first presentation of
this policy - it hasn't been aired at all in the other policy meetings
- it's quite possible to approve this then find it's not acceptable
elsewhere. Something slightly different is approved. I'd like to ask
our chair in calling for votes on this or consensus on this policy to
possibly bear in mind that there may be some adjustments or some
conflicting policy approved elsewhere and what exactly we should do
about that. I guess it's to do with the - how strictly we accept every
aspect of this policy and whether something else could be regarded as
being consistent with the decisions we make here.


TAKASHI ARANO:

You mean we play have some chance to view a draft document in the
future?


PAUL WILSON:

We would need to, if there's something different that's approved at
other regions.


TAKASHI ARANO:

In the case of IPv6 address policy, we did such way. We wrote some
concrete draft document and circulated that under each...


RAY PLZAK:

Paul, in your presentation - Ray Plzak from ARIN - you mention that
one of the big objections to the global sparse allocation policy was
the fact that people would not be able to readily identify the source
of the allocation. One of the things that the reservation, large
reservation would've done would've enabled that. It also would've
provided a little bit more in terms of... of a cohesive aggregation
back to a smaller prefix. I'm just making comments, I'm not advocating
one thing or the another - by removing that and leaving just the
minimum allocation size of /12, the accounting mechanism, 512 possible
/12s that could be handed out and therefore someone some place would
keep track of which /12 went to which regions for those people that
wanted them. Is that a correct interpretation? PAUL WILSON:

Yep. It's comparable with the current situation with IPv4 at the /8
level. Apparently that is - it is argued - I'm not commenting on
whether or not - on the merits of the argument - but it's argued that
under the current v4 system you can do that tracking. It's very
difficult in the case of historical address space but if a system like
this is implemented sooner rather than later we have many fewer
prefixes to track and quite a feasible number for anyone who wants to
do that.


SPEAKER:

It's also possible for IANA to implement a sparse allocation along the
lines of the v6 without it being hard coded into policy and be smart
about how they handle it. At the same time it's probably wise for RIRs
Not force IANA's hand here. You withdrawing is the right thing to do,
let IANA implement a smart mechanism that still allows some
aggregation of return.


IZUMI:

JPNIC supports this basic framework of the proposal. It's quite
difficult for us to judge whether a /12 is a good size or not. So as
long as this is the size that all the RIRs think that they would be
able to consume within the next three years, then I think that's a
good size. Is that the size that all the four RIRs think they would be
able to consume?


GEOFF HUSTON:

Let me reiterate what I had done in the work in simulating this. Over
the last 3 years LACNIC's level of allocations in v4 has been
significantly less than the other three registries. In that mode, in
that projection LACNIC would not fully consume a - in three years but
the other three RIRs in that model would probably reasonably consume
them. But the issue is not would a - it consumes a /12 but is a /16
too small which is the basic question. What's the right /4 boundary
across the entire system and what it appears from that data is that
the optimal common point of a per RIR allocation to consistently give
you strong aggregation capability is a /12. That's the out come from
that exercise.


IZUMI:

As long as we can confirm that the allocated blocks weren't used for
the next ten years then I think we can support this proposal and that
point has been clarified so thank you.


RAY PLZAK:

Just a general comment on the capability of an IR to consume a /12, if
it is going to be consumed in three years. The proposal is not that it
would be a /12 to take three years to use, it's a minimum allocation
size. Currently the minimum allocation size from IANA to the RIRs of
v4 is a /8. Routinely the RIRs will request v4 space from IANA in
multiples of 8s, so in that - a consumption figure. It doesn't say
that our supply is going to be a /8 in this case. Our supply is what
we need to meet the requirements. So the minimum allocation slice
before is /8. What's being proposed here minimum allocation size /12
for the reasons Geoff outlined is not the same as saying it's going to
take an RIR - that that equals 3 years supply for an RIR. Clearly I
can conceive where an RIR could ask for an allocation of two /12s
there is a given time to fulfil a requirement. So I think it's wrong
to try and couple those two together.


TAKASHI ARANO:

Any other comments?


DOUG BARTON:

Hi, Doug Barton, the general manager of IANA. I'd like to echo what
Ray said - it would be more correct perhaps to use the terminology
"Unit of allocation" rather than minimum allocation size as Ray
pointed out, regardless of the amount of space that's justified by the
RIR for an individual allocation, the unit of allocation is a /8. By
the same token a unit of allocation is being proposed here would be a
/12 and whatever the community comes up with in terms of a reasonable
number IANA is certainly going to abide by. I have a few general
comments that - keeping in the spirit of Paul's request. ICANN and
IANA in particular are very excited to see this issue is being
discussed in the policy forums at each of the RIRs. We're very
interested as Paul pointed out in seeing a global allocation policy
for IPv6 happen. We eagerly anticipate the community input on this
topic. I also wanted to agree with what Geoff Huston said in regards
to the importance of aggregation versus address preservation in
regards to v6 policy. Clearly we have a large pool of addresses to
work with and therefore we need to make hopefully more intelligent
decision about how to allocate them in the long-term than were perhaps
done in the v4 space. By that I certainly don't mean to denigrate any
of the decisions made by the people who do not have the benefit of our
20/20 hindsight however given that we do have some operational
experience in v4 and some knowledge about how things have been
allocated in that area, I think it would be very useful to apply that
knowledge to the current discussion. On that basis, I'm a little bit
concerned that the assumption of a /48 being the appropriate unit to
be given to - every end user is more or less unqualified in the
analysis that Geoff presented. He and I have had personal
conversations about that topic so I think we're in agreement that this
is an aspect of the analysis that really needs to be carefully
analysed. 

As he pointed out in answer to a question during his
presentation, when you change that individual factor then the
projections in terms of the amount of space that an RIR would need
over a 36-month period can change dramatically and with all the due
respect to those who have different opinions I'm not sure that giving
an individual home user tens of thousands of addresses for their uses
is a reasonable solution. However, I once again eagerly anticipate
community input on that topic. The next point that I'd like to make -
I'll try to be more brief - is that while I certainly respect each of
the RIRs' ability to apply a policy that meets the needs of their
numbers within their region, it would be useful, I think to hear more
input from the various RIRs about what type of policy they plan to
apply, because that is going to have an impact on the reasonableness
on the minimum or allocation unit size in the global policy. Last but
not least I'd like to make a brief comment about your last point - the
announcements. I realise that this has been a source of contention
with the RIRs and is certainly something I think we need to improve
the mechanism behind but I would like to make the observation that the
lists that IANA sends announcements to currently about allocations and
other pieces of information are all by request. This is something that
the community has asked us to do and something that I believe strongly
in response to that request that we should continue. However, I would
like to point out that I am open to discussion with the RIRs about the
mechanism of how that should happen and more importantly the timing of
how that should happen in order to preserve the operational
requirements the RIRs have in terms of being prepared to receive
queries about these requests prior to IANA announcing them. That's it.
Thank you.


TAKASHI ARANO:

Any other questions, comments?


GEOFF HUSTON:

Just one follow-up comments on part of this issue about what's
variable and what are constraints upon us. And how do you change
things. The fixed link sub-net ID field of 16 bits is certainly a
major factor in terms of how much space gets consumed in total. That's
very true. It's also part of a set of Internet standards on IPv6
addressing architecture. Once you start opening that up and saying at
what point and how does that get changed? Certainly I could concede
that in the current rate of change of IPv6 standards you could change
that faster than Geological time, that's certainly true but I'm not
sure you could change it as a much faster rate than that and certainly
looking at this policy there is some pragmatism about the constraints
we're currently allocating on and the standards on which those
allocations have been managed, versus what would happen if changed
some of those underlying IPv6 standards.


RANDY BUSH:

Are you sure the /48 boundary for site allocation is a standard?


GEOFF HUSTON:

I'm thinking proposed.


SPEAKER:

Even if you say proposed I believe that was part of what was being
changed in this last round. That was a policy decision. The /64 is
somewhat hardcoded. The rest of the discussion is outside the IETF.
The recommendations in some of the earlier documents specify the /48 -
at a reasonable from an architectural perspective-kind of answer, it's
not going to break the system if we allocate 48s to everything known
to mankind. But there is a business question that is often overlooked
and is clearly outside the scope of the IETF in - what's the right
business model and are you allocating - how much space and does it
make sense for ISPs to differentiate service levels by how much
address space they allocate?


RANDY BUSH:

Um, yes, I think the first point is there is no IETF standard
proposed, draft or anything else, Geoff, saying the /48 is the
boundary, that's a policy decision which was given back to the policy
community.


GEOFF HUSTON:

31.77 and 35.87, amongst others.


DOUG BARTON:

I apologise for opening up this can of worms and I realise it's a bit
of a religious issue. The other aspect of this I think is important is
even if we say /48 is a reasonable assignment to give a site then the
question is still open as to what's a site. If you're an ISP and you
have 10,000 customers and - you have 65,000 sub-nets you can use to
spread across your 10,000 customers, so the question of - does an
individual ISP get a /48 or does an individual home user get a /48 I
think it's a very valid one. And is what I intended as my part of the
thing to question, there's also as randy pointed out an open question
as to whether or not /48 is even the given policy issue that we should
be discussing. Anyway. Once again, sorry for opening the worms.


JORDI PALET:

I'm not sure whether - here there is the definition of a site - at
least 31.77 talks about general case except for very large
subscribers, home network subscribers, always-on, SOHO, small and
large enterprises so here there is not a confusion about what is a
site because it describes perfectly everything.


DOUG BARTON:

My question is... should be Ð


JORDI PALET:

My point is then if we start now changing that - I am not telling it's
correct or not, but that means we are going to hold the location
policy from IANA to the risk until that's fixed, because that could be
not very good. I guess it could create a delay of at least one year
probably. I don't think it could be done faster.


DOUG BARTON:

That's not what I'm proposing.


JORDI PALET:

No, but it's one of the possibilities to go back and say "OK, let's
change from a /48 to a / 56, or even a /60 for a home user is probably
more than enough and maybe then all this focus that Geoff prepared and
the policy is based on that will change, right? So... that's the
point. We want to delay that or we can work in parallel or work in an
assumption of something and - because maybe we allocate initial /12
then we go back to IETF and change this recommendation, what will
happen is the next allocations will not be again so big. But at least
the initial one could be reasonable to still keep /12.


PHILIP SMITH:

Do we want to carry on this question or carry on tomorrow?


TAKASHI ARANO:

I think that this kind of discussion of future IETF standard will
affect this policy, but under the current situation, we can decide
this kind of thing for now. this is the revised proposal.


PAUL WILSON:

It separates the framework from the specific parameters.


TAKASHI ARANO:

We have no time, so I would like to postpone this voting until
tomorrow morning. Is this OK? And please question these kinds of
things at night during - probably... OK. OK. Thank you very much for
everyone. Thanks, Paul. This is the end of today's session. Please get
together tomorrow at 9 o'clock. Thank you very much.


PAUL WILSON:

Do we have some announcements or reminders?


SPEAKER:

It's important if you are doing the social event - on the program it
says starts at 7 but to get to the secret venue you need to all gather
at the front foyer, the bus starts picking up from 6.45, but we can
leave at 7. You all need your tickets. If you haven't got one, please
see the secretariat office and they will issue tickets. Please bring
the tickets because someone will wait at the bus to collect them so
you can get in. Thanks.


TAKASHI ARANO:

What time does the next session start?


SPEAKER:

Now.


TAKASHI ARANO:

Thank you. (End of online session for Wednesday)