APNIC 22
Policy SIG - Session One
Thursday 7 September 2006
09:00 - 10:30


KENNY HUANG: OK. Good morning, everyone. Welcome to the Policy SIG. My name is Kenny Huang, the chair of the Policy SIG. Also the co-chairs are Toshiyuki Hosaka-san and another co-chair is Eugene Li.

Today, we have eight policy proposals so let me just show the order of the agenda.

OK, you can see the agenda on the screen and also, if you have a computer, you can link to the APNIC website and you can see today's agenda.

Today is quite a long meeting because it's starting from 9:00 - right now it's 9:05 - up to this afternoon 3:30. So I'll start by reviewing the agenda items.

The first one is review of action items and I will present this part. The second one is 'IP policy update - comparative status in all RIR regions', presented by Save from APNIC. The third one, proposal 037 - 'Deprecation of e-mail updates for APNIC registry and Whois data' - presented by Terry Manderson from APNIC. Proposal 38 - 'Modified lame DNS policy proposal' - presented by Terry Manderson from APNIC. Proposal 039 - 'A proposal to improve reachability of new IANA blocks' - presented by Tomoya Yoshida-san from OCN. So that will be the first section of the topics.

The second section starting from 11:00, if we are on schedule. The first one is proposal 035 - 'IPv6 portable assignment for multihoming' - presented by Katsuyasu Toyama-san from NTT. Proposal 034 - 'IPv6 portable assignment for end-user organisations' - presented by Jordi Palet Martinez from Consulintel. Proposal 036 - 'Proposal to allow end sites to receive IPv6 allocations' - also presented by Jordi. So that's the second session of the Policy SIG.

The afternoon session starting from 2:00 to 3:30 starting from proposal 033 - 'End site allocation policy for IPv6' - presented by Geoff Huston and Randy Bush from APNIC and IIJ. Proposal 041 - 'IPv6 assignment size to critical infrastructure' - presented by Save from APNIC. And next one will be 'Large space IPv4 trial usage program for future IPv6 development activities update volume 11', presented by Takashi Nakamura-san from IPv6 Promotion Council of Japan. The last one is 'Experimental assignment for four-byte AS numbers' presented by Maemura-san from JPNIC.

So that's today's agenda items.

OK, starting from the first one, open action items. Welcome to the Policy SIG. Basically I would like to introduce the Policy SIG. The charter is to develop policies and procedures which relate to the management and use of Internet address resources by APNIC, NIRs, and ISPs within the Asia Pacific region. The chairs are Kenny Huang - myself - and co-chaired by Toshiyuki Hosaka-san and co-chair Eugene Li, so each one of us will chair one session.

For policy documentation, current policies, you can check on the apnic.net/policy from the website. And regarding policy proposals, you can go to apnic.net/policy/proposals to see policy proposals. In this meeting, APNIC 22nd meeting, we have eight policy proposals. That really breaks the historical records. And submission to mailing list was by 7 August.

Facilitating the process - policy development facilitation through APNIC's Secretariat is the first contact. So SIG chairs will check suitability. Also discussion in appropriate mailing list. Discussion in upcoming SIG and annual member meetings. If you want to have a policy change, you can first discuss with peers and also submit a proposal using the form. OK, just remember, you don't need to be a member to participate and the Secretariat is happy to assist if needed. You can find the form on the following website, apnic.net/cgi-bin/policy_proposal.pl.

So awareness of current policy discussion - you can also find it from apnic.net/mailing-lists/sig-policy, subscribe to post comments to the list. Also welcome to attend APNIC meetings. You can also access via remote participation. And you can read the minutes and meeting report. They're always online and available. OK, you can also seek Secretariat assistance.

OK, there are some housekeeping stuff. For speakers, please speak slowly and clearly. Most the people here, their first language is not English. So please speak slowly and clearly. The session is being webcasted. So you can also go to the website to see what's going on on the Policy SIG. Remote participation is also possible. And you can also from the link go to Jabber chat and join the discussion. Lots of open participation for anyone who wants to voice your comments, please use the mic to speak. The discussion by consensus - it's not a vote. So we don't vote on the proposal. We're seeking consensus from the proposals. So we can approach common agreement and compromise. So that's critical, but we didn't try to veto anyone's voice. We try to seek an appropriate way to compromise a proposal to get everybody's consensus first.

OK, starting from open action items, that's from policy SIG. Proposal 21-001 - "Chair to move the discussion of the HD-ratio for IPv4 networks proposal (prop-020-v001) to the mailing list for a further month to seek consensus and make a decision.

Proposal 21-002 - "Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal establishing a transition timeline for assigning 4-byte AS numbers (prop-032-v002)

SAVE VOCEA: Save from APNIC Secretariat. I'll speak to that. Just an update on this proposal - it's currently being discussed in the APNIC Secretariat with the technical team and also the other RIRs to implement this process.

KENNY HUANG: OK. Right. Thank you.

That's the extra open action item from Database SIG because we don't have Database SIG this time. So I'm helping the chair, Database SIG chair to announce an open action item.

Database-21-001 - "Database SIG chair to post an item to the database mailing list giving the status of proposal prop-019-v001 'a proposal for Whois database query' and asking for community input on whether to close the proposal or continue with it."

SANJAYA: Sanjaya from APNIC. I believe we have decided to close that because there is no response in the mailing list and the author is not responding to the queries.

KENNY HUANG: OK. Right. So this one is already in the database mailing list.

SANJAYA: Yes. So this is closed.

KENNY HUANG: It's closed. OK. Thank you.

OK, another two open action items from DNS SIG. Again, we don't have DNS SIG this time so that's two open actions from DNS SIG. You want to comment?

SANJAYA: On the first item, it has been reported to APNIC 21. So this is done previously. And for item number two, Save, remind me, what is this.

SAVE VOCEA: This is also done, Sanjaya.

SANJAYA: OK. Thank you.

KENNY HUANG: So these two open actions is done? OK?

OK. There are no other open action items.

OK, I'll move to the first presentation, from Save. It's 'IP policy update - comparative status in all RIR regions'.

SAVE VOCEA: Good morning, all. This presentation will provide an overview of APNIC policy implementation updates and share some of the policy discussions and status among the Regional Internet Registries.

Just to provide an overview, as I mentioned, to discuss the implement update - the status among the other RIRs.

Now, under the APNIC policy framework, the Secretariat is supposed to report back on the implementation status of policy proposals that have been endorsed through the process. After the APNIC 21 meeting, the 4-byte AS number policy proposal was endorsed by the APNIC Executive Council. One of the key dates is that by 1 January 2007, the Secretariat should be able to assign 4-byte AS numbers to requesters. As I mentioned earlier in the action item points, the RIRs are currently coordinating to be ready for this process.

One of the policy proposals that was globally coordinated was the IANA policy for allocation of IPv6 blocks to the RIRs. It has been discussed widely and adopted in all the RIR regions. This was discussed also at the ASO level. They have submitted their report to the ICANN for ratification. So they are waiting for the ICANN's position on this.

The amendment of IPv6 HD-ratio from 0.8 to 0.94 for subsequent allocations, in APNIC this policy has been adopted. But the Secretariat is awaiting adoption from the other RIRs. I should note here that at the ARIN region, they have implemented this policy.

Now, to look now at the discussions and status among the other RIRs, I'm focusing mainly around what's been discussed in the open policy meetings and also through the mailing lists.

From the discussion in IPv4, as you can see, in any mailing list, there've not been many issues raised lately but, as we heard yesterday, there was focus on IPv4 exhaustion. So there's a lot of research done in this area. The debogon activity and resource recovery has been also an activity that's happening within APNIC and you'll hear tomorrow from Son Tran, our Resource Services Manager, who will talk about these activities as well. There was no consensus reached on 'applying HD-ratio to IPv4'. As we've heard, the chair posted this to the mailing list. No responses from anybody in APNIC. There was really no support for this proposal within the RIPE and LACNIC region as well. Looking at the AfriNIC region, they have adopted end-user IPv4 portable assignments policy and a policy for temporary address assignments. Now, just recently in the RIPE region, they have proposed to document that a /24 should be the minimum portable assignment size for multihoming. So this proposal will be discussed in the next upcoming meeting.

Looking at the IPv6 space, IPv6 for critical infrastructure policy is currently under discussion today as one of my proposals. We've got a /32 maximum assignment per operator proposed in APNIC. I should mention that AfriNIC also has a /48 minimum default assignment under discussion. There is a proposal discussion on v6 portable assignments for end-user organisations. As you'll hear, the motivation really was to have multihoming for the networks within the region. This has been discussed widely in all the other RIRs and, as I said, ARIN adopted to assign the minimum /48 size. You'll hear later that there's two proposals to be discussed today.

Also, IPv6 Address Allocation and Assignment Policy I has been in discussion in the RIPE region as well in APNIC. Very similar proposals have been put forward by Jordi. One of the criteria's is he wanted to remove a plan for 200 /48 end sites and this has been implemented in the AfriNIC and LACNIC region.

Now, on the amendment of IPv6 assignment and utilisation requirement, there is a part of this proposal on the assignment size which will be discussed today by Randy and Geoff. As I said, it's 0.94 HD-ratio. APNIC is waiting on the other RIRs. And lastly the micro-allocation for internal infrastructure proposals. This policy proposals is currently under discussion in the ARIN region. On their opinion million mailing list it's been busy in the last few weeks discussing this policy. This is the end of my very short presentation and I just want today alert you to all the other policy pages that the other RIRs contain ands you can see in APNIC, we've developed a policy page. The other RIRs do this as well. They contribute to this and you'll hear their reports tomorrow as well. So thank you for that.

Questions?

KENNY HUANG: Any questions or comments?

OK, thank you, Save.

So next one is deprecation of e-mail update for APNIC registry and Whois data presented by Terry Manderson from APNIC.

TERRY MANDERSON: Good morning.

This proposal is for the Secretariat to phase out e-mail updates of registry and Whois data in favour of using more suitable methods for such updates.

So what's our motivation to do this? There are three main reasons that are driving this proposal. Firstly, improving security. Security is every IT professional's concern. And more so when we're dealing with resources that are important to you.

So to consider a well-worn security acronym, CIA - confidentiality, integrity and availability - Confidentiality - ensuring that disclosure of information is only to authorise people and limiting access to those who are not authorised. In the case of e-mail updates, can you be 100% sure that your update isn't being read in transit? From the minute you send it to the minute that we receive it and we send you a reply? I don't think you can.

Integrity - primarily source integrity, knowing that the data actually comes from the person or entity that we believe should send it and not from an impostor. Can we be sure of this in e-mail? By some password or e-mail address perhaps? Clearly not. E-mail is known not to be a strong source integrity mechanism.

Availability refers to, unsurprisingly, the availability of information resource, an information system that is not available when you need it or at least when you want it to be there, as least as bad as having none at all. Here we're really concerned with the general delivery problems of e-mail - e-mail fails, e-mails gets filtered, mail servers are laboured with spam. I'll talk about spam shortly. But I don't believe we can make availability guarantees with e-mail.

Secondly, UCE - spam and viruses. They're a blackspot on the Internet. No-one has a complete solution and as a result we're all implementing mitigation techniques. That is fine but two facets of this concern me. APNIC is expending significant resources on attempting to keep the e-mail update system operational under the load of spam and virus e-mails. Sadly, I think we're losing. The more important one of concern is that autodbm e-mails that we send back to members are being rejected by members due to their spam mitigation techniques. Clearly we have a broken feedback cycle.

And lastly, APNIC is evolving. We're focusing more on customer service levels, and as we should. This means that what we provide to you as registry services are also evolving, growing in function, becoming more mature and with that your expectations as members are also growing. Your concerns of privacy have grown. You're concerns about having easy-to-use systems have grown. APNIC needs to address your concerns. Simply we don't believe that it is a viable exercise to create e-mail-based registry systems that can operate successfully under these conditions and meet your service expectations.

So what might registry updates look like without e-mail? We already have our very successful MyAPNIC web portal. So what we can do is extend its functionality with built-in security out to command line and automatable interfaces encompassing confidentiality, integrity and availability. We should also note that both the command line and directly automatable interfaces for our membership are a new service. This new service delivery will allow membership to take more control of the way they deal with APNIC data systems. Until now, most members automated through an amassing e-mail system which really doesn't lend itself to a feedback cycle. A mechanism to update your data with immediate feedback has never before existed - never before existed at APNIC.

What I'm going to do is put myself in the hands of the demonstration gods and present a quick view of a new test environment for updating DNS objects to APNIC via our suggested mechanism. This mechanism is based on XML via rest over https or what we call web services for short. This system is now available for member testing and the only prerequisite is an APNIC certificate. You can test with our tools which can be downloaded from that site, or, if you're so inclined, you can write your own. If any time if you have any questions, please direct them to our helpdesk, who will be more than happy to assist or, if you'd like to catch me during APNIC 22, I would also be happy to help.

Let me just end this for a second... is that viewable? Can people see that?

PAUL WILSON: It's very small.

TERRY MANDERSON: Small?

(Pause)

Is that OK?

OK, what I'm going to do is demonstrate with 29.12.202 in-addr.arpa. This is one of the APNIC Secretariat's own reverse DNS delegations. The test environment lives at rdns.apnic.net. So let's query that to see what is actually in the DNS. Sorry? Oh, I made a typo. There it is.

But what does the registry information look like? We've got the DNS delegation information there. So let's fetch some information and Fetch is one of the tools from the ftp site so right now, this is heading off to the RDNS server and it's returned a well-formed structure that represents what is actually in the registry including such things in the schema as modified dates and version numbers. So let's change something.

And I'll just scroll to the bottom of this screen. I actually can't see the bottom of the screen. My apologies. So let's just output this to a file - apologies to people who are not UNIX people in the audience. And let's edit this file. And there you can see the XML structure. You can see that we have cumin.apnic.net as a nameserver, tinnie.apnic.net as a nameserver and ARIN as a nameserver.

I'll leave ARIN there because ARIN are nice folk. Let's remove this nameserver here and then we simply update this file to the service. Let's keep in mind that what I am doing is updating registry data using my certificate via an encrypted transaction.

Until now, APNIC commits to publishing DNS update in approximately two hours. Reasons for that are perhaps history or maybe myth but by modern standards we would probably consider that a little slow. Let's see if it's updated. This is where I pray for the gods to be really nice to me. It's there. Because I've been working with this system for some time I can say that the time it took for me to submit the object and the time for it to be visible in DNS was about a minute. So two hours down to one minute.

Let me go back to my slide pack.

So, benefits - encrypted transaction. So we've got confidentiality. Integrity of source through certificate authorisation. Data integrity and consistency are served by using XML. Service consistency is elevated by having an immediate feedback and availability confirmation. APNIC customer focused by providing a command line, an automatable interface that is just easy to use.

How will we get there? Well, two months after EC endorsement, we put out some tools and a test environment. I actually think we're pretty much there. Four months - domain objects would be deprecated from the e-mail process. Eight months - inetnum, inet6num and autnum and 12 months after EC endorsement, we take care of the remaining objects.

So, in summary, this proposal is seeking consensus from the community to phase out e-mail updates of registry and Whois data in favour of more suitable methods

Questions? Comments?

SAMANTHA DICKINSON: I have two comments from the Jabber chat room. One question from Tim Jones was, "Why can't we just leave the status quo? Those who are highly concerned about security can use MyAPNIC. Those who have invested in infrastructure built around e-mail updates can continue to use it. There is a cost associated with keeping the system running to APNIC, that is granted, but why shift that cost to others to get them to modify their systems?"

TERRY MANDERSON: Yes, there's going to be a cost to members to reimplement some of their systems. The benefits are going to be security. It's going to be automatable security. I don't believe that APNIC can have an insecure system, a system that doesn't provide security concerns, doesn't provide privacy concerns running. I believe we need to be more responsible than to leave such a system running.

And I believe we need to approach a new system with security concerns in mind. For the last three days, we've heard from various people who have been doing security for a very long time saying, "Why aren't we doing security? Why aren't we, as IT professionals, doing security? Why aren't we, as network operators, addressing security concerns through the entire network, through the entire organisation? " I believe we need to, as APNIC, help that along.

SAMANTHA DICKINSON: I have another question from Jabber, this time from Christie. She says she's coming from the point of view of a large organisation, so they have lots of updates to do. "If we change the updates through XML, will we be able to do automated updates to the price Whois database. At the moment, they are changing by e-mail them changing from public to private Whois via APNIC. This is slow. This we could update the private Whois on rest, it would-be fantastic."

TERRY MANDERSON: In response to Christie, the answer is yes. Is our full intention to update both Whois and the private objects.

ALEC PETERSON: I'm Alec Peterson. I'm on the ARIN Advisory Council. I think this sounds great. While I'm standing here talking to you, somebody steals my laptop and walks out of here. How do I go and tell somebody that I can't - that my certificate is no longer valid?

TERRY MANDERSON: You call APNIC. Tell us your certificate is invalid. We'll revoke your certificate.

RANDY BUSH: Randy Bush, IIJ.

The Internet is not a guaranteed service. E-mail is not a guaranteed service. The web is not a guaranteed service. They're all weak. They all have their problems. Secure e-mail is just as securable as any of the other services. Scare tactics that e-mail is vulnerable just don't fly. It is interesting to note that none of the other regions have raised this issue seriously. OK? It is not a service problem.

Removing this removes two things - it removes service to the people we will not hear from today because they cannot afford the plane flight and do not have continuous TCP connectivity. And it will remove the service to those who use the fact that e-mail is exceedingly asynchronous and have manual and automated processes that count on that. Signed, encrypted e-mail is perfectly reasonable security if you use the same certs you're talking about using if you want or you can use BGP.

You will get the same amount of spam no matter what, you're going to have to filter it. LF-null is still LF-null. I just don't see the big deal here.

KENNY HUANG: Thank you, Randy.

Before moving to the next question, can I please - all speakers please state your name and your affiliation and your intent to support or not support the proposal, because it's a policy proposal. For any people on site or online, please try to use the mic as loudly as possible and the roaming mics are available. So please raise your hand to request a mic. Thank you. You can have a question.

SAMANTHA DICKINSON: I have another comment from the Jabber chat. I haven't had time to e-mail back to say whether or not she supports it. It's Christie again saying she's particularly passionate about this policy as they're spending heaps of money putting in an automated system based on e-mail updates. She would like it to be up to members to decide whether they want to use the secure system or continue with e-mail updates.

TERRY MANDERSON: Noted.

KENNY HUANG: Any more questions?

SHIN YAMASAKI: I'd like to propose a working group to discuss this system in general. By the way, I'm for your proposal. I support the proposal.

TERRY MANDERSON: Shin, that's a good suggestion. Would you be willing to chair the working group?

SHIN YAMASAKI: If no-one else will take the opportunity, yes, I can.

KENNY HUANG: Any more comments?

AHMAD ALKAZIMY: I would like to know if this would be for all our members or only for the NIR.

TERRY MANDERSON: The decision would effect both the NIR and the member.

So NIRs themselves would certainly need to consider the mechanisms they use for the APNIC data registry system.



SHIN YAMASAKI: As far as I understood, APNIC will prepare some convergence tool for NIR to support current transfer mechanism to synchronise data between NIRs and APNIC. Is that correct?

TERRY MANDERSON: That's correct.

MA YAN: This is Ma Yan from APNIC. I'm an EC member of APNIC. My question is when more members join APNIC, then some of the members will introduce all those operations. So if we introduce new policies, new proposals, we should consider producing training materials, to let people know what is the new one and what is the advantage over the old ones.

TERRY MANDERSON: Thank you.

KENNY HUANG: OK. Because it's a policy proposal, if there is no other comments or input, I just discussed with Terry because right now we have two situations. The first one we can look for a proposal itself to seeking for consensus. And the next one is looking for what was proposed to fork a working group for further study and to see how things are going. I will go one by one.

For anyone who is in favour, least please raise your hands. Higher.

(Pause)

For anyone who is not in favour of this proposal, please raise your hands.

(Pause)

OK.

Can I have some input from Randy Bush - do you have comments regarding to this proposal?

RANDY BUSH: Was my comment not sufficiently long already?

KENNY HUANG: OK. For the agenda we just proposed to have a working group, who, anyone, is in favour to form a working group to further study. Please raise your hand higher.

(Pause)

OK. Thank you.

ALEC PETERSON: This is Alec Peterson again. I just have an observation, really.

RANDY BUSH: What's your employee affiliation?

ALEC PETERSON: Message Systems.

RANDY BUSH: Thank you.

ALEC PETERSON: You're welcome. I believe these two topics - deprecating e-mail and this synchronous updates system, I think including coupling them in the proposal is contributing to some of the ambivalence you're seeing from the community. So it's just a thought.

KENNY HUANG: OK, for anyone who is not in favour to form the working group, please raise your hand higher.

(Pause)

OK, right, thank you.

We have two situations. On the first one, we'll continue with the proposal. The proposal has been approved by the Policy SIG, it goes to the AMM mailing list for APNIC and the second one to form the working group to further study. It seems less objection for doing it this way and can I discuss with my co-chair first?

OK, I would like to suggest on the proposal regarding the first one and we can still to be discussed in the mailing list but for second one, many people request to form a working group to investigate these kind of studies and so we have consensus to the second proposal so we can form a working group and to further study. For first proposal, we can still keep discussion in the mailing list. OK, right. Thank you.

TERRY MANDERSON: Thank you.

APPLAUSE

KENNY HUANG: We need volunteer to chair the working group.

(Shin Yamasaki volunteers)

Thank you.

TERRY MANDERSON: Thank you very much, Shin.

While I'm still up here, I'll move on to the second item.

Proposal 38 - to amend the APNIC lame DNS reverse delegation policy.

This is a little less exciting but important nonetheless. The proposal is to make an editorial update to the definition of lameness for the APNIC lame delegation policy.

The motivation for this is that we really want to update the definition of lame for both best practice and RIR consistency. The editorial update also clarifies the function of the policy. It should be noted that this really isn't a new policy. This is in fact updating an old policy, an active policy, which is our pre-existing lame policy.

So what's the difference between the two policies? Um, the old one checks for a valid answer for the SOA. And, sorry, does not check SOA contents such as serial numbers and things like that. The new one requests a valid answer for an SOA will it also checks to see if the authority bit, or the AA bit, is set. Similarly the SOA contents are not checked.

So what's the lame definition? Using a UDP query, a valid delegation is that the delegated nameserver provides a valid answer for the SOA record of the domain. The returned answer is authoritative, what that is the AA bit is set. Failure of any of those checks is lame. Note we still don't check SOA data consistency. So serials just do their own thing.

Benefits - firstly, APNIC becomes consistent with best practice and also we take a step closer to being consistent with the other RIRs' definition of what is a lame delegation. Secondly, the editorial change allows us to implement a friendlier procedure for dealing with lame delegations. I'm sure those of you who have received lame delegation notifications from APNIC would appreciate that. Lastly, this change has no effect on the membership. The members have already delegated their domains appropriately. They've delegated to an authoritative nameservers. The membership already knows which way is up. This change in policy simply confirms that. Implementation - obviously, this is an editorial change, so implementation is simple, minimum impact.

Two weeks after EC endorsement, we would update the operational procedure on the APNIC website and apply changes to the DNS lame checking software.

So, in summary, we're seeking consensus from the community to update the definition of lameness for the APNIC lame delegation policy.

KENNY HUANG: OK. Thank you. Any comments? I'll just remind you to please state your name and your affiliation and your intent to support or not support the proposal. Thank you.

Online comments? No. OK.

OK, we don't have any extra comments for this proposal. OK. I'd like to seeking for consensus for anyone who is in favour of this proposal, please raise your hands.

(Pause)

OK. Thank you.

For anyone who is not in favour of this proposal, please raise your hand.

(Pause)

OK, right, thank you. So I conclude, the consensus is reached and the proposal has reached consensus in the policy SIG. Thank you, Terry.

The next speaker is Tomoya Yoshida-san who will present a proposal to improve reachability of new IANA Blocks.

TOMOYA YOSHIDA: The motivation is that making some rules which include the current situation of the RIR and ISPs, the RIR members, they also making more relationships between RIRs and ISPs. This is the current problem. So ISPs see that almost all new IANA allocations are unreachable and unable to use immediately after allocations.

At almost all ISPs in Japan we discussed these issues at the last meeting. Almost all are facing the same trouble every time delivering communication to Japanese high speed. This is a problem. Also, the information is not globally coordinated. So you know that debogonising project, this is the web site, so implementation in RIRs, so we know that APNIC and RIPE and NCCC and AfriNIC are already starting the debogonising pilot project. But I don't know exactly about ARIN and LACNIC exactly. They are prepared to start the debogonising project, but this is not a coordinated, but each registries.

And currently, there is no room for debogonising prefixes. So it is up to each registries. Then we cannot compare our study for reachability of those prefixes.

You can see that the example of the RIPE, APNIC and AfriNIC. So in the RIPE, the most recent prefix, there is two debogonising prefixes, one is /21 and one is /16. APNIC, five prefixes in each /8. In AfriNIC, they announce that only the minimum of the regions. So you can see that each registry, there is no normal rule.

For IPv6, you know there is no IPv6. For recent allocation from new blocks, the reachability is very worse. You can see that this IPv6 assignment, but each is worse. So we need for IPv6 debogonising prefix. Today I have four proposals.

One is the proposal making a rule of debogonising prefixes for IPv4 among RIRs. Two choices, one is RIR announce /24 to /16 in the same /16. So RIR does not announce each prefix, but we want to know the reachability for each prefix. So I propose that in the same 16 and the every length the same as 16 prefix.

This is my idea, just my idea. In the first one is not decided the length of prefixes, but coordinate the multiple length of prefixes among RIRs. This is my one proposal, one of them. One advantage is will be able to compare each region on the same scale and it will be easy to check or confirm what prefix are the debogonising prefixes. Again, prefixes not the same with the RIRs.

The second is the proposal to provide the same service for IPv6 allocations. I don't have any good ideas which prefix length is the better to announce the prefix, but from I propose to just provide the service.

Third one is a proposal RIRs to establish a site for ISPs to confirm reachability, enable automatic notification from RIRs to ISPs by registering ISPs. You can see that here is the ISP-A network with APNIC, so firstly ISP register, the same address to APNIC web site. So this is the database ISP-A number.

Firstly, the ISP registered to the require web site administration. IANA allocate to RIRs, APNIC allocate 121 /8 to APNIC. APNIC announce some prefix of the debogon, the prefix is 12654. Then, the platform to the ISP-A network. If we don't receive the ping result, APNIC can know that transfer was reachable or unreachable. APNIC send the result of traceroute to ISP-A automatically by e-mail. So this is my idea.

When, another new IANA allocation to registry, if we have the automatic system, so it is very nice to check the reachability from RIR, ISPs using the debogonising prefixes. You know on our web site, so very similar system. We have already.

If you choose the prefix and the others, if you put the address route, we can check the traceroute of the ping, but it is not an automatic system. I want this system will be the automatic system. This is my idea. But this is very similar system.

So again, proposal RIRs establish automatic ICMP/traceroute, I propose an additional traceroute. But ISP is not acceptable. We can check the traceroute. It is nice information for ISPs. Detail of the implementation will be left up to APNIC.

The last one is the proposal service by all RIRs and the share those information with all RIRs. So between APNIC and AfriNIC on the web site. Information is scattered. So we need same web site and the same framework. We can check the destination of the prefix among every RIRs. This is my fourth proposal.

APNIC announce the prefix and traceroute to Japan or to Europe. So we need global coordinated route.

Again, this is my point. Making a route for IPv4, and implement for IPv6 as well IPv4 and sharing the information for all other users RIRs. Any comments, suggestions?

TERRY MANDERSON: From an operational point of view, you make the assumption that APNIC can advertise any prefix at any time. APNIC, like any organisation, is still a participant in the Internet so we are still bound by the rules that ISPs provide. Those rules include things like filters. And so I think you should be aware that it is actually a nontrivial task to randomly change filter states with ISPs.

Do you think that the benefits from this policy proposal outweigh the cost of implementation?

TOMOYA YOSHIDA: Every ISP people facing this problem. If say the world, some site, we can reach, not reach.

TERRY MANDERSON: Every ISP...

TOMOYA YOSHIDA: More than eight ISPs, every ISP is face the trouble when we announce the new routes.

TERRY MANDERSON: Your research covered eight ISPs in Japan?

TOMOYA YOSHIDA: Yes.

SPEAKER FROM THE FLOOR: It is very serious for everyone. I strongly support it.

RANDY BUSH: Randy Bush, first thing is we have a paper publication process in this area so I can't say too much. Sorry. Many sites have this problem.

Few sites face the problem. That is the problem for all of us.

Research shows that most of the bad filtering is near the edge where they don't read policy, they don't update their routers, etc.

I don't think this, this is, you and I working in an environment where people pay more attention. That's not where the problems are. Where the problems are, I think you have to go knocking on the door and say, "You have this problem. Here is a pointer to a web page on how to fix it. Until you do that - policy and research don't get us very far."

I think it's a perfectly fine proposal, I don't think it fits your purpose.

SANJAYA: In general, I would like to do this. It is a service that I think is worth doing. But I would like to just point out what the concern is, we have actually tried this before, tried to request our upstream that we want to advertise this for debogonising process. We couldn't, there is too many red tapes to be able to do, it is too big. Because we are bound by our upstreams restrictions. My suggestion is we also have other points of presence, basically in Japan and Hong Kong and the US. I was wondering if you could help us have the ability to advertise to from Japan, if you can help us do that.

TOMOYA YOSHIDA: My idea is announcing from each region, for APNIC prefix to announce it from APNIC in Australia, but currently the RIPE and AfriNIC prefix would be announced from Europe. Is it correct?

IZUMI OKUTANI: Can you just explain in Japanese. That he understood the point.

TOMOYA YOSHIDA: My suggestion is that we can announce the prefix, from Japan, but my idea is announcing from the APNIC region and RIPE region they announce from the RIPE NCC.

SANJAYA: I understand that. We are willing to announce it from the APNIC network, but from the Japan node.

TOMYOA YOSHIDA: My proposal is checking for the system, just not in deal. From where is better.

SANJAYA: Fine, just to let you know it is not that easy. I know RIPE can do that because they are sub-allocated in an environment they can advertise quite easily, not the case with APNIC.

TOMOYA YOSHIDA: One question, all regions of RIPE to the web site.

SANJAYA: We could, RIPE has been helping us with that.

TOMOYA YOSHIDA: I don't suggest each.

SANJAYA: Right, then I'm happy to support this proposal.

FILIZ YILMAZ: I would like to give some feedback on the experience when have with the projects. Even after we identify some of the AS number that, filtering of the new prefix, we contact, we don't seem to get much result, not given the response to us.

RICHARD JIMMERSON: Hi, this is Richard Jimmerson from ARIN, I'm just coming up to the mike. Something might be obvious, if you are asking for something to be put into policy in the APNIC region and you are suggesting that APNIC do operational coordination with the other RIRs, that is one thing, but if the intent is for it to be policy across the regions, just point out the obvious thing that this would have to be bedded in each affected region.

TOMOYA YOSHIDA: Do I need to go to the meeting?

RICHARD JIMMERSON: Do you need to go to the ARIN meeting? In order to make the policy? In the region you would be able to submit a policy, it would not mean you have to go to the meeting, no.

KENNY HUANG: Before we go to the next question, you welcome to make any secretary proposal to the chairs, if you wish.

FILIZ YILMAZ: It's more or less saying in the RIPE region, I didn't specifically make a comment because the system was there at the moment, the web site is there and we are already having or coordinating with APNIC on the new prefixes uses for APNIC region, so I guess that part is sorted. But if you have questions or details about the system, please come and talk to me. I'll be around.

TOMOYA YOSHIDA: Think about my third idea? I think this is not...

FILIZ YILMAZ: Obviously, this is my personal opinion, but I would say the system is there. With one click you more or less see how your reachability is. However, the output, as you know, is not telling you what to do. You still need to go through your peers and find out where the problem is. There still lies a bit of effort there. You can't, I believe you can't automate the process, 100% anyway. You need to sort out that with those ISPs, those operators. I don't know if I'm mistaken here, maybe Terry will help me. But the tool is telling you where it stops. This is where the problem is and if you don't know your peers, you have to contact each of them. Because you don't know which route went where.

TOMOYA YOSHIDA: My idea is if we put them into the situation, into the one site, we can, how can I say, we can think which is, which ISP block, we can know if we put into the, like the organisation.

FILIZ YILMAZ: Alright, like, having APNIC block, having some other block over there in the site too? That is your automation?

FILIZ YILMAZ: I was just commenting on the your previous slide where you had, yeah, image of implementation, if I'm understanding it incorrectly, tell me, if you automate this, I understand we have an e-mail address for you or whatever, and APNIC starts announcing your block, they immediately send you the output, is?

TOMOYA YOSHIDA: Announce the prefix, if ISP is traceroute, the final thing is that ISP have an update. So ISP can now receive. Information for both ISPAs and the other networks. If we share the information, which site is the filter. So we can...

FILIZ YILMAZ: Okay, I understand that. My comment is even if it is automated with the output you get, you will still need to contact all those carriers. That you will need to do anyway.

TERRY MANDERSON: There seems to be some confusion as to the definition and intent of this policy proposal. Maybe as a recommendation you might like to consider sending this to the mailing list for review and for clarification.

KENNY HUANG: Any more comment? Okay,

TOSHIYUKI HOSAKA: This is not a question to the speaker but some clarification of question to APNIC or RIPE, whenever, do you have a plan to offer a different project for IPv6 addresses?

FILIZ YILMAZ: I can't give you the exact date, but it is an ultimate nice goal on our side.

KENNY HUANG: One more question, actually, your proposal have covered four subproposals - do you want to seek consent as a bundle, or one by one?

TOMOYA YOSHIDA: I want you to, first, all covered all processes to involve this situation, this proposal. After that you talking in each one.

KENNY HUANG: Okay. So first of all of you are clear with the proposal, want to have a two-stage consensus-seeking process. The first stage we seeking consensus to the proposal as a whole.

TOSHIYUKI HOSAKA: Yoshida-san wants to know if you support the proposal itself, the debogon proposal itself, and then he would like to see how many of you can support the, each, each part of his proposal one by one.

KENNY HUANG: Okay. So, first, is any of you in favour of debogonised project, initially, if you are in favour of this project, please raise your hand.

Thank you. If any of you who are not in favour of debogonised project, please raid your hand.

Okay, regarding to the first suggestion item, we can form a debogonised. We have consensus for the first part.

For the second part, we need to go to each component one by one. Sorry... move to the last slide.

Right. Okay. That's part of the proposal, the first component, making the rule for IPv6, sorry, IPv4. For anyone who is in favour for the first component, making the rule for IPv4, please raise your hand.

Okay, thank you. For any of you who is not in favour of making the rule for IPv4 please raise your hand. Okay, I didn't see a consensus for the first component. Okay, now move to the second component. Implement IPv4 as well as IPV6. For any in favour for the second component, please raise your hand.

Okay. Thank you. For any of you who is not in favour of implementing IPv6 and IPv4, raise your hand. We have consensus for the second component for IPv6 as well as IPv4. Who is in favour of the third component, please raise your hand.

We should change the order. Go to three first. For third component, proposal RIRs to establish automatic ICMP traceroute check and notification to ISPs. In favour, please raise your hand.

Thank you. For any of you who is not in favour of this proposal, please raise your hand. Okay, thank you. So we have consensus for the third component.

For the last component, propose the service by all RIRs and share those information among all RIRs - for those in favour, raise your hand.

Okay, thank you. For any of you who is not in favour of this proposal, this component, please raise your hand.

Okay, thank you, again we have consensus for the last component. Okay, thank you Yoshida-san. We can take a break. We come back at - we still come back at 11, thank you for your participation, thank you.

SAVE VOCEA: A housekeeping matter, please take a free mouse from the front desk.

APNIC 22
Policy SIG - Session Two
Thursday 7 September 2006
11:00 - 12:30



TOSHIYUKI HOSAKA: OK. It's time to begin with the second session of the Policy SIG. Hello, everyone. Welcome back to the Policy SIG. My name is Toshiyuki Hosaka, one of the co-chairs of the Policy SIG. This second session of the Policy SIG, we are going to discuss the IPv6 allocation policy, especially on the IPv6 portable assignment policy. As you may be aware, we have two similar proposals of the IPv6 portable assignment for multihoming networks. So I would like to do like this - first, I would like to ask Mr Toyama to present his slides and right after that I will ask Mr Palet to show his slides and make his presentation. And after that, I'd like to hear whether you support the IPv6 portable assignment policy or not, if the answer is yes, we will discuss all the details of the conditions.

So, the first presentation is from Mr Toyama. His proposal is prop-03 a - "IPv6 portable assignment for multihoming."

KATSUYASU TOYAMA: Thank you, chairman. Good morning. My name is Katsuyasu Toyama from NTT and today I'd like to talk about policy proposal about IPv6 portable assignment for multihoming. The primary goal of our proposal is to allow end sites to be assigned to the IPv6 portable address only if the end sites are multihomed. So first I would like to explain about the current problem, next propose a policy on portable assignment for multihoming. Finally I would like to compare our proposal to other proposals.

The first - the current problem. These days, the Internet has become an infrastructure for our lives, for our businesses. And various services and communications are done over the Internet. So you can buy an airline ticket on the Internet and you can access your banking account on the Internet. And your company business uses VPN over the Internet for exchanging business information with other business partners. So these end site organisations, these companies, which provide the services or applications over the Internet heavily rely on the Internet connectivity. So the Internet connectivity is very critical to them.

The current APNIC policy, however, does not allow IPv6 portable assignments to any end sites. This means end site organisations which really needs redundancy for their Internet connectivity cannot be multihomed in IPv6 just as they do in IPv4 for using a portable address and TCP.

So we would like to insist that APNIC policy should allow IPv6 portable assignment to multihomed end sites.

And there has been a long discussion about who needs IPv6 portable and who should have it. And currently, only big ISPs can have the portable address. So no end site can have a portable address. And some end sites want the portable address for permanent purposes, which enables them to switch the upstream provider easily. But we think the redundant approximately sis for multihoming has a priority over such permanent access. And, as I explained, the redundant connectivity these days is very important and critical to some kind of company. And there is no technical solution for multihoming. So end sites which will be multihomed - should have the portable address. So our target is this one. And we would like to include the permanent policies.

And no other appropriate way for multihoming? Of course, the shim6 is discussed at IETF. This is one of the technical solutions for multihoming and it enables each host of the end site to use a set of provider-assigned IP address prefixes and switch between them. But, shim6 is not a perfect replacement of the current method using portable address and BGP. And the shim6 working group is working very hard but still the specification is being discussed and is not fixed yet. This means that implementation of the shim6 will not be available in a few years, I think.

So the current best solution is APNIC should modify to allow end sites to be assigned IPv6 portable addresses, only if the end sites are multihomed or plan to be multihomed.

OK, next I will explain the proposed policy. The key point of this proposal is described on this slide. The portable assignment only for multihoming organisations is the first one. And companies whose size is not too big or too small, not only big, but small, but some companies need a redundancy for connectivity. So I would like to recommend that regardless of the size of organisations, or such companies, to be multihomed and have a portable address.

And the second - for saving address consumption, we recommend the assignment size should be a /48 and of course a shorter prefix if the end site can justify it.

And from the operational perspective, the address block of the assigned portables should be separated from those of allocated portables. This makes it easy to operate.

If the situation is left as it is - I mean that there is no portable assignments to any end sites. It will be unavoidable that multihoming in IPv6 will increase using punching holes. And punching holes is not legitimate and also the punching holes are troublesome. For instance, it can be used to intentionally reroute traffic to providers that have no duty to carry them.

So we think it is more constructive to allow routable assignments, which is managed by the policy than to increase punching holes in practice. This means that, if assigned portable address space is separate from the allocated portable, then it becomes easier to filter punching holes in allocated portable address space. And also, if better multihoming method comes up in the future, we can enforce them to move to the new multihoming method until a flag day.

So this is the proposed policy the IPv6 portable assignment - assignment target is end sites which are multihomed or plan to be multihomed, regardless of their size. The criteria - the end site which is assigned IPv6 portable address must be multihomed using the assigned portable address space in three months. If the portable address is not used for multihoming after three months, the address should be reclaimed and the end site which is assigned the portable address will pay an APNIC fee for the space. And the portable address space - the portable assignment should be made from a specified block separate from the address space used for portable allocations. And the portable assignment size should be a /48 or shorter if the end site can justify it.

So finally I would like to compare with other proposals, especially to show this proposal.

From our view, the difference between ours and Jordi's are a few. The first one, the big one, is assignment size. Our policy recommends a /48 but Jordi's is a /32 and Jordi's proposal says the policy is temporary, but our policy does not describe such a thing. And target and criteria - this is just a little confusing point - we are focusing only on multihoming end site but Jordi's proposal, especially in the introduction section, it describes not only a multihoming end site but some end sites which requires administrative or technical reasons. And our proposal also describes that after a certain period, checking that the address space is used or not. So this table is compared Jordi's and ours and also compared with ARIN's. So please look at this slide.

And in summary, we propose that the APNIC policy should be modified to allow end sites to be assigned IPv6 portable address only if the end sites are multihomed or plan to be multihomed. Thank you very much. Any questions?

TOSHIYUKI HOSAKA: Thank you. Before we take any comments or questions from the floor, I will ask Jordi to make his presentation and after that I will open the floor.

JORDI PALET: OK. I hope a lot of people has already read the proposal. I am going to try to be a little bit short.

A summary of the proposal - this is intended as a solution for organisations that need portable blocks, commonly named as PI in other regions. Either for multihoming or for other reasons such as can be avoid voiding renumbering when changing an ISP.

Why the policy is temporary - basically, I stated this already in several mailing lists. I think it's even worse having provided portable blocks in other regions such as ARIN, where has been already been accepted and not in the rest of the regions, because the provider independent...

In order to make it, let's say, stable in terms of what the people has in mind using those prefixes, I am proposing not, let's say, a very strict fixed deadline but three years after an alternative technical accepted solution by the community is available.

This gives the people the view of we have a temporary policy but the temporarily will only start counting three years after we really have a technical solution. If we never reach a consensus about the technical solution, ten the policy lasts forever. I really think we will have technical solutions but we don't have today an idea about when they will be commonly accepted and available. When this policy expires, then the assignments can be reclaimed or maybe some of the LIRs that got those assignments will at that time qualify for keeping it. That means also they will have in mind an idea that they don't at that time need to renumber or the technical solution makes renumbering easy or whatever.

This is also somehow an answer to one of the reasons that the people is stating especially in North America to say we are not deploying IPv6 because we don't have portable blocks. I don't really think that's correct and while we will see that in a few months - because now that the policy has been accepted in North America, we will see if there is a boom of demand for portable blocks - I don't really think that's the case. We will see.

Qualifications for this type of assignment must not be an LIR, must qualify for an IPv4 assignment, even if it's not actually holding this IPv4 block. Why is that? Because we can have the situation of people that is wanting it do or provide IPv6 services and not necessarily IPv4 services so we should not tie the decision of assigning them IPv6 if they already have or not IPv4.

The rationale, again, is the lack of IPv6 portable blocks is considered sometimes as a deployment barrier. I don't really trust that but that's what some people is saying. Organisations using provider independent are not allowed to make further assignments, so if they get the block, they are not really going to use it for, let's say, customers...this policy also allows a fair situation with other regions. My idea is the cost is global so we should have a similar policy or similar options in all the regions to be fair. And it's also fair to newcomers so we don't make difference with people which may be already online today and maybe not in the future and they can have difference which having the support for multihoming or not.

Against - well, the same problem as any portable block. It means routing table growth. But that's also one of the reasons why I'm trying to make it temporary instead of something that will stay forever.

Assignment size - a /32 or larger if justified. Why a /32? Because it's the regular routing filter practice and it allows also if they become later an LIR without renumbering. Against - and some people could say a /32 is a waste of space as this is temporary, it's not really the case.

Subsequent assignments - again, if justified and whenever possible from an adjacent block to keep the aggregation.

I keep the idea of using a super block in the sense of having all these prefixes continuous so, if necessary in the future, we decide it's time to deprecate this policy or whatever, we make easier for LIRs to filter them. I basically already explained that the expiry for the assignments - the idea is once there is a valid technical and deployable solution accepted by the community, then three years - we can decide any other figure but I think three years is more than enough to keep the people, let's say, safe. And, again, if then they qualify to become an LIR, they could opt to keep, for example, the prefix to avoid renumbering.

What it means at the end - it means that probably these three, four years of expiry means we will have, in total, if we take three or four years to have a solution, six, seven, eight years of time and usually that's much more time to maintain a cycle in any network so it should not be a real problem.

And just last slide to finish - a comparison between what we have today, the provider policy and the provider independent. The size is the same, a /32 minimum. Whatever is justified as the maximum. The qualifying criteria is to be an LIR or not to be an LIR. Not to be an end site or be an end site. Plan to assign 200 /48s. Here the plan is they should not assign to other entities. Plan to aggregate and in the case of provider independent, they can not deaggregate. Here there is an administrative question that I don't know too much how it works in the case of APNIC, but basically what I am suggesting is these organisations should have also some kind of contractual relation with APNIC. This is because in some regions, it doesn't work the same, so I left that to APNIC itself to be defined.

I am not willing to provide these blocks for free and make a difference, an unfair situation with the LIRs. So, again, it means the fees need to be defined. Maybe the same as in the LIR case or something equivalent or maybe something more expensive. I don't really know.

Downstream assignments, in the case of today's policy, they are required. In provider independent, in my proposal, they are not and, again, the three years' expiry after we have a valid, accepted technical solution. That's it.

TOSHIYUKI HOSAKA: Thank you, Jordi.

So both proposals are to propose IPv6 portable assignments, so at first, I would like to focus on whether we can support the IPv6 portable Assignment policy or whether we need it. If you have any comments or questions, please approach to the mic.

KAZU YAMAMOTO: Kazu Yamamoto, IIJ, I have one question to Toyama-san. First of all, I am in a neutral position for portable assignments, but I have one question to be asked. In your proposal, you are limited to assign portable addresses only to multihomed sites, right? So I'm curious what's happening when, you know, multihomed sites quit multihoming. Do the, you know, if one site gets a portable address because they are multihoming and then quit multihoming, should the site return that address.

KATSUYASU TOYAMA: Yeah, I hope so. Multihoming is very - I think the multihoming is critical - yeah, condition for portable assignments. So, you know, I think it should be reclaimed if they are not using - not multihoming.

RANDY BUSH: Randy Bush, IIJ. What happens when a site to which we give address today leaves the Internet? Same question. Same answer. Yes, we think they should do something. Do they do it? No, they never do it. That's life. Right?

KATSUYASU TOYAMA: Yeah. I think, I agree with the current situation. But, if possible, if we can use some kind of routing registry, some kind of thing, I think it can be blocked if they are not multihoming, if they finish to use this.

KAZU YAMAMOTO: And just one comment for Toyama-san. You are comparing your proposal with Shim. But you need to compare with a lot of other technology ideas. For example, multi-prefix approach, and lots of programs with different approaches. You should explain so the audience understands the problem, I guess. And another approach is proposed by an organisation in Japan. That proposal, one larger ISP provides a bunch of prefixes so a site have only one prefix and there is no address selection program so we need to compare such approach. And so I like, you know, Jordi's proposal. We should define the three years limit and try to prepare some technology and then, after three years, we should reconsider, you know, portable addresses is suitable or can we accept that other technology. Just a comment.

Thank you very much.

TOSHIYUKI HOSAKA: Kazu-san, thank you for your comment. Before going into detail, we would like to focus on your support for the IPv6 portable assignment itself.

Randy?

RANDY BUSH: Randy Bush, IIJ.

We do not have any better routing in v6 than we have in v4. There is no reasonable plan, work or ideas on how to fix it. Thinking that it will be fixed in less than five to ten years is a fantasy. This is horribly embarrassing, but it's the reality we face as engineers. Therefore, I believe we are going to have to make operational compromises to accommodate v6 life in a v4 routing universe.

I think Toyama-san proposes a pragmatic solution to the worst problem, which is the legitimate engineering use by multihomed sites. The rest is projections and marketing and none of them have come through for v6 yet and I'm not optimistic for the future. We have a very particular engineering problem to solve and I believe Toyama-san's proposal addresses that.

And I understand the others on an operational and engineering basis, not on a people-want-and-people-think basis, then I can understand this.

TOSHIYUKI HOSAKA: Thank you, Randy.

Any other?

PHILIP SMITH: Philip Smith, Cisco.

So, looking at the two proposals, if I rewind to many of the general tutorials that I gave, workshops that I gave, trying to teach people how to do multihoming, it's generally an order of magnitude easier for anybody to multihome if they have their own address space. So therefore I'm actually highly supportive of anything that gives a multihoming organisation their own address block.

This is what I preach in IPv4 land and what I tend to encourage service providers to do is to get their own address space through registry membership and so forth and, if this is required for other organisations that need to multihome, so be it.

And so I would extend that into IPv6 also. So I'm supportive of Toyama-san's proposal also because it solves, as Randy said, a current engineering problem with the current technology that we have. And I really do understand where Jordi is coming from with his proposal but what really worries me is this temporary nature. I mean I like at the 6Bone with its temporary 3FFE space. I mean there are still 3FFE prefixes running around in the Internet today.

I look at in the past - in the past 15 years that I've been involved in the Internet, there's a lot of temporary things that have become pretty much permanent because we haven't figured out how to solve the temporary solution that was proposed then. So that's what makes me really worried about Jordi's proposal. So given a choice, I prefer the first one over the second one.

JORDI PALET: Philip, do you have any opinion about the size of the prefix?

PHILIP SMITH: I don't, actually, because it's one entry in the routing table. And, OK, I mean we can go away down a rat hole here but people talk about sizes. It's one entry in the routing table. I'm really worried about the size of the routing table.

JORDI PALET: I think it's a question of regular filtering practices at the end. I mean, I understand your concern about the temporarily of the policy and I wanted to make it temporary because, even if I don't put temporary, we can at any time change the policy. I mean at the end of the policy, temporary. But I prefer to be - since the beginning, honest and say, "This is what we want. We don't want this forever if we can avoid it." I mean it's just a question of wording. At the end, all the policies are temporary because we can change at any time.

PHILIP SMITH: I really appreciate that you're making it temporary. I want to know the mechanism of rewinding the temporary. Who is going to walk into this ISP or that enterprise and say, "This is temporary. You have no business using it any more. Stop." Who is going to be the global policeman who is going to do this? It's going to end up being you and me and everybody else who tries to keep the Internet working and I don't want to do this. I mean I tried to do this as part of the routing table size thing in '99/2000, when we were worried about the size and you should see the abuse I got then. I don't want to do it again.

JORDI PALET: In theory we have reclaiming systems and policies. If they don't work. We should not have them. That's a different question. It's probably not related to this proposal. I'm using the tools we have there.

TOSHIYUKI HOSAKA: Sorry for the interruption. We are going into the detail of the proposal. Before proceeding with that, I would like to see how many of you can support the idea that APNIC should, you know, should have a policy of IPv6 portable assignment. Can I ask a show of hands of you?

OK, those of you who support that APNIC should have a portable assignment policy, please raise your hand.

Thank you very much.

Those who do not support APNIC should have an IPv6 portable assignment policy, please raise your hand.

(Pause)

No?

It seems that this is the consensus. We should have a v6 assignment policy in any way.

OK, then. We should talk about the conditions of the IPv6 portable assignment policy. Do you have any comments?

RANDY BUSH: Jordi, we're in a region that has an enormous piece of IPv4 space temporary assigned for two years to a v6 experiment that is now in its sixth year. So you can excuse my scepticism about things which are temporary.

I think Toyama-san's proposal is a conservative engineering proposal that is the minimal thing necessary to solving the immediate problem. I did not vote on the vote you just asked for because I don't unconditionally believe in private address space - pardon me, portable address space - I believe in it used in certain ways only and so I think just - I don't want to open the door but I would note that that is a conservative and real proposal addressing and current and real problem.

And it's not that Jordi doesn't have my sympathy. It's just I'm more conservative.

JORDI PALET: One of the main differences I think between the proposals in addition to the temporary is the size of the prefix. Let me try to explain why I believe we should use a /32.

First, I don't really think it's a waste of space considering the space that we have in IPv6. But the most important thing is I see today situations where people like even APNIC has a /32. They announce usually two blocks, two /33s and one day it can reach APNIC, one day, the following day, it cannot, because the operators in general are filtering on the /32 or smaller bundling. I have the same situation with critical infrastructures that have a /48 in some regions and in many cases, you cannot reach the critical infrastructure so what is the meaning of having a critical infrastructure allocation if you cannot reach it. That is the reason I believe it's really important if the regular routing practice is filtering on the /32 boundary, we should keep that way, especially because it's not really a waste of space, which will be the against that reason. That's my main motivation for going to a /32.

PHILIP SMITH: Philip Smith, Cisco.

I just want to really support what Jordi had said there from the point of view of running into this filtering problem. The people out there in the v6 world have decided 32 is some magic number and multihoming is some magic solution and you should only be doing /32 end of story.

Again, see the e-mails that I get saying, "How dare Cisco announce three or four /35s." So what? Big deal. My answer is, "Please tell me how to multihome. Because the only way to do it is the way we did it in v4 land." So I'm just worried about the problem of using a /32 to bypass people's bad filters and I think we should spend more time trying to educate people that a /32 filtering is the wrong thing to do because we end up with IPv4 space called IPv6. If you look about in the IPv4 case, /24 is an unwritten filter but if you announce a /25 or a /26 or a /27, you've got no guarantee of any connectivity anywhere at all. If you look at APNIC's IPv4 multihoming, there's a /24 you can get, how do you multihome with that? It's not at all obvious.

So, you know, I suppose I'm in the middle of the road with Jordi's proposal because I know what he's trying to solve but I'm just worried about it. I'm really worried about it and I think, you know, given the choice, I really do want us to go and see Toyama-san's solution. Because it will give us a better interim solution, I think.

Can I just add a second? With the temporary assignment, I think, if we're going to go that way, we should define a process for APNIC to get that temporary assignment back. Because I haven't seen APNIC or any registry go to any organisation and say, "You should not be using this. Pull it back." I can only see lawyers getting involved here. If lawyers get involved, it gets expensive for APNIC and somebody has to pay. Now, APNIC doesn't have magic money. It's the membership, you, the membership, who have to pay these legal fees. If you want your membership fees to go skyrocketing, well, go for it. But, you know, as we've seen - we'll talk about it later, but as we've seen with some of the discussion, members are already concerned about the size of the fees. Do you want the fees to go higher because of the legal bills?



JORDI PALET: I agree with your point, Philip. The question is it's not a rule that we should filter on a /32. It has been picked up for an aggregation question. In fact, there is some work in IETF looking into a recommendation in that direction, but the point is we need to be pragmatic and to be pragmatic is why we want a multihoming solution that will work sometimes. It's easy. Mean, you cannot enforce the operators to don't filter on a /48. So you really want a solution that it's a practical solution. It works. You cannot use a /48 and I'm sure we will see this problem when some people start getting blocks for mailing for this. I'm sure some of these organisations will get the block for multihoming and will not be reachable. So what's the point then to get it?

IZUMI OKUTANI: Izumi Okutani from JPNIC. My point would be quite similar to what Philip has mentioned. The question I have is that we already have a policy that allows the different assignment from the allocation size in IPv4 and also in terms of critical infrastructure. It's a /32 in our region. With any other region it's a /48. I'm not too sure why this size has to be /32 for PI assignments for the sake of routing.

And personally I don't have a very strong preference over which size to assign but it seems to be going into a reverse direction of what Geoff and Randy is proposing in a separate proposal to think of an efficient utilisation of address space for IPv6. And it might be OK to assign this size at this moment because we have plenty of address space. But then, like, you know, when it gets to the point where we have to think about efficient utilisation even in IPv6, we might start thinking that /32 would be too big and it would be too late to recover those assignments. That's one point.

I personally don't agree much about those organisations can be an LIR later if they wish to be because it seems that the target is different. So we should separate the two. That's my point. Thanks.

JORDI PALET: But the point was if they qualify at that point. I mean, I am not stating since the beginning they should become. If they qualify, that's something that, even if I don't say in the policy, it would be there. I am just, again, trying to be honest and saying it very clear since the beginning. OK?

Regarding the critical infrastructures, I believe LACNIC is also doing this. Both the critical infrastructure being assigned in LACNIC are a /32. That's the same reason. We had the same discussion. I didn't participate in the discussion. It was three or four years ago in LACNIC. The final decision was to say a /32 or smaller and in the en, the reallocations are being done in a /32. I have the situation with some critical infrastructures that use a /48 and one day you can reach them and on the following day not. It's a very pragmatical question, that's it. And we cannot enforce the operators to change their filtering. They do whatever they want.

TONY HAIN: Tony Hain. Philip raised a point here. The /48 option in one proposal is probably too long and it's quite likely that a /32 is too short. If Cisco is actually in a position where we're announcing longer than /32s to multiple places around the world to solve the way we need to do traffic with multihoming, that says absolutely a /48 is not acceptable. Even if we could live within a /48, an organisation has the same problem. It needs to be able to announce longer than whatever they were allocated. We have to be talking something shorter than a /48. I don't know that /32 is necessarily a default answer. Right? We should be able to allow for /44s are whatever in between. And that should be a decision at the time of each allocation. Right? We're not required to go straight to a /32.

Yes, there are filtering issues but I think Philip is also right - we should be leaning back on the service provider to say, "Fix the policy." /32 is probably the wrong thing to do. We've got blocks where /32 makes sense and we've got blocks where somewhere between /32 and /48 makes sense. Do the right thing.

JORDI PALET: That's the way LACNIC did with this policy for critical infrastructures - /32 or whatever is convenient. Today they are allocating /32s. That would be a good interim position. I also believe that using /35 today is safe because the original allocations were /35. So a lot of people still keep allowing /35 blocks. That's the reason why.

TONY HAIN: I understand that. Right. That's what's going on right now. But that's not absolute requirement. Another organisation might need just /44 and just happen to be that that makes sense.

The point is there are multiple things being done and having one default answer for everybody is probably the wrong choice, particularly if the default answer is /48. /32 is probably too much.

PHILIP SMITH: Philip Smith, Cisco. It's probably more for the mailing list. If somebody has more space and multihoming, that doesn't work because they can't get /35s routed and they go and ask for a /16 because the /24 doesn't route.

That's the sort of analogy it sounds like to me and I'm wondering - would it be possible maybe - I don't know how you would do it - but maybe APNIC can evaluate the address space requirements as part of the multihoming needs? So rather than just a /32, maybe a /48 or maybe /46, /47, /45 or something that's sufficient to meet reasonable needs for the next few years. I don't know. This is just a thought.

TOSHIYUKI HOSAKA: Any other comments? Anything related to the prefix size?

Toyama-san, would you like to respond to regarding the size of the assignment - /48 or /32?

KATSUYASU TOYAMA: I think that we should be conservative about address consumption. And I propose that the separation of the allocated portables and assigned portables and I think that operator can filter each other for allocated portables for a /32 and assigned portables, /48. I think it's available. So I prefer the /48 for multihoming end sites.

TOSHIYUKI HOSAKA: Any other comments or questions?

I will like to see whether you can support either of the proposals made by Toyama-san or made by Jordi.

So I would like to see your show of hands. Those of you who support the proposal, 035, proposed by Mr Toyama, please raise your hand.

Thank you.

Those who support the proposal 034 proposed by Jordi, please raise your hand.

Thank you.

So it seems the rough consensus was reached to the proposal 035 by Toyama-san.

So we still have remaining portion of the policy process. We have a comment period at AMM and also in the mailing list. So if you have any comments or questions, please post it. Thank you Jordi. Thank you Toyama-san. Thank you.

So the next proposal is also from Jordi and that's proposal 036 - proposal to allow end sites to receive IPv6 allocations.

JORDI PALET: OK, this proposal is intend as a solution for a number of discussion that we got in different regions regarding existing IPv6 policies and changes that already have been taken by some of the regions.

Somehow, it's also an alternative solution to some of the proposals for portable assignments.

The main question here is that we can have small ISPs, actually not that small, even medium ISPs, which may not have 200 customers. That's part of the problem.

The other one is that we can have some organisations that need to make internal assignments, as they may have a number of sites, even their own layer-2 infrastructure, even not just necessarily a big number of sites, but just a small number of them. And they want to avoid future renumbering if they change their upstream provider or become multihomed.

A very, very simple example which we have seen many cases, at least in other regions, I am sure here there have been other cases also is universities, which may have several campuses, several faculties, and even they may not have the service from their upstream providers, but they may have service via tunnels from other providers. So this is a very clear situation. Today this university cannot get IPv6. That's a real situation. And if you have an ISP with only ten very big customers, it cannot provide IPv6 service. It doesn't seem reasonable. It doesn't seem fair to me.

What is the situation in other RIRs? Well, the same proposal has been submitted in the rest of the regions. And, in fact, some of them don't have already the 200 customers restriction. And have some kind of text that allows the hostmaster to consider any submission which is a reasonable number of sites to be connected.

So what I am basically propose something to change a little bit the definition of end sites to be broadened to include a wider range of end users. Basically including end use there's have a legal relationship with a service provider. So that's, for example, the case of the universities. The university is probably a single legal entity and the operator, the network operations centre behaves as the ISP for all the campuses, buildings, faculties, whatever.

Also, I am proposing then a change in the text of the initial allocation criteria to allow end sites to apply for an allocation, expand the criteria of the type of sites an organisation can provide IPv6 connectivity to include sites within its own organisations or sites at related organisations. And, of course, the most important thing - remove the need to have a plan to make 200 /48 assignments in two years. Probably say something else, a reasonable number of assignments.

There is one more data which is the active policy, which is APNIC-089 - flag that policy as "interim". I believe that this should be removed. Today is not any more an interim proposal. We have been already allocating IPv6 for years and I think it's clear enough that what we have is not any more interim.

There is a last part which is today when you assign to a single organisation multiple /48s, you need to document up front about that. I think this is an LIR decision and this is already impacting on their own prefix utilisation and we'll need to justify that when coming back for a new allocation for APNIC. There is no reason to upfront justify it. Of course, this will also somehow reduce some of the extra unnecessary work for the APNIC staff.

So if I make a comparison between the existing policy and the modifications, we have the change in the end side definition to be broadened to include users related to the organisation itself, maybe legally or by other means. The qualifying criteria - to remove not an end site and to remove the plan to assign 200 /48s. The policy status - to remove the 'interim' and not required any more to document when several /48s are being allocated. And that's it.

TOSHIYUKI HOSAKA: Thank you, Jordi. Is there any questions or comments?

No?

Can I make some clarification questions, Jordi?

Do you submit this proposal to other RIR regions?

JORDI PALET: Yes.

TOSHIYUKI HOSAKA: All of the RIR regions?

JORDI PALET: Yes. Except ARIN. It's not exactly the same proposal because in some regions they already removed the need for the 200 /48s. But basically the direction of the proposal is looking into the same goals.

TOSHIYUKI HOSAKA: Mm-hm. OK.

Can I make one more questions on this?

Personally it seems to me that your proposal gives almost everybody who needs IPv6 address because you remove the 200 condition and you remove the LIR condition. You know, your proposal gives allocation to end sites, not only the LIRs.

JORDI PALET: To end sites that need to reallocate to their own organisations or legally related. An end-user will not get from this policy - maybe we need to touch up the text to clarify it, but an end-user will not get from this policy an allocation obviously.

TOSHIYUKI HOSAKA: An end-user will not get -

JORDI PALET: A home user, small company or something like that. It's not the goal of the proposal.

TOSHIYUKI HOSAKA: OK. Thanks for your clarification.

RANDY BUSH: Randy Bush, IIJ. So that is the only restriction it does not remove? All other restrictions are removed.

SAVE VOCEA: Are you in support of this proposal?

RANDY BUSH: No.

JORDI PALET: So, Randy, then you believe that an ISP which has only ten big customers cannot provide an IPv6 customers need to be out of business? That's it. Or even if it has 199 customers? That's it? I mean, the magic 200 customers is as magic as like the /32 in the filtering or whatever. We need to be realistic. It was put there at the beginning because at that time it was really an interim proposal but today... it doesn't make sense.

RANDY BUSH: Stop talking about filters. Filters are noise. ISPs adjust their filters to reality. Filters and talking about planning allocation based on fantasies about filters is what is in the American idiom, a red herring - something designed to distract you from reality.

JORDI PALET: OK.

RANDY BUSH: End of discussion about filters. Please. OK?

Now, today, in v4, and for 20 years in v4, we've had the problem of small ISPs start with PA space. That's been life. It has worked. It's a compromise. All this is a compromise between what we would like if resources and routers and power was infinite and the reality we have to face. Because v6 routing is no different than v4 routing, we still face that compromise. I'm sorry. I would like for everything to be free and for cash to fall from the sky, but it doesn't.

JORDI PALET: Save, maybe have you the answer to this question. Do you know, more or less, from the APNIC members, how many of them probably have less than 200 ISPs? I don't know if it's an easy question or you never figure it out.

SAVE VOCEA: How many have less than 200 ISPs?

JORDI PALET: I am not talking about IPv4 or IPv6. I'm talking about in general what is the number of -

SON TRAN: That's a very tough question but, if you want to know the number of organisations that actually come to APNIC and request IPv6, we have had four only since 2000.

JORDI PALET: OK, so four have been rejected because they have less than 200?

SON TRAN: Something like that.

JORDI PALET: OK, so we can see that in two ways. We can see that as changing that in the policy, it will not be a big problem, we are not going to increase the number of allocations by is an explosive number. And in the other way around, it means it's fair to have four ISPs that want to provide service and cannot? That's the point.

PHILIP SMITH: Philip Smith, Cisco. I thought the policy says 'plan'. It doesn't say 'must have'. So I really, as I've said for several years, don't understand what the problem is.

JORDI PALET: Well, four have been rejected.

PHILIP SMITH: Because they didn't have customers. They were end sites. But the modification says 'be an LIR' so you're an ISP that's got customers. But I'm not aware of any ISP who's been rejected. I don't know any ISPs who don't have customers. So I still don't see what the problem is.

AKINORI MAEMURA: Akinori Maemura from Japan. Have one consistent idea which I apply to several proposals in this area. I am supporting Randy's idea - the filtering of the /32 is that, yes, I think that's a fantasy actually. Maybe ISPs for running a piece of the Internet background will filter if they need, then maybe the current practice will be, if this proposal reaches consensus, then they are - their practice will be filtering at the /48.

My consistent idea is that we need to conserve the IPv6 address space. That is proposed in Geoff and Randy's proposal, to allow LIRs to have a smaller assignment than a /48 and also multihoming PI proposal from Toyama-san, which allows a /48 assignment if - in case of the multihoming also that we have another proposal for the critical infrastructure allocation, assignment, which allows one single assignment to the critical infrastructure apparatus.

Then the sense of these proposals are just one for conserving the IPv6 address space. So I would like to support this idea and so I am not supporting your presentation this time. So that's my idea. Thank you.

TOSHIYUKI HOSAKA: Any other comments or questions?

If not, I would like to see your show of hands, whether you can support this proposal?

Those who support this proposal, please raise your hands.

(Pause)

OK, thank you.

Those who do not support this proposal, please raise your hands.

Thank you very much.

I'm afraid that the consensus was not reached on this proposal. And this proposal was the remaining portion of the policy process.

Thank you, Jordi.

JORDI PALET: Thanks.

TOSHIYUKI HOSAKA: So we have gone through all of the agenda in the second session but we still have 20 minutes before lunchtime. If possible, we would like to have an informational presentation planned in the third session. If either Nakamura-san or Maemura-san is ready for that presentation. Nakamura-san, are you ready? OK.

So the next presentation will be from Nakamura sap. The presentation title is 'Large space IPv4 trial usage program for future IPv6 deployment activities update volume 11'.

TAKASHI NAKAMURA: OK, I would like to briefly report on the large space IPv4 trial usage program for future IPv6 deployment. It's a long name.

My name is Takashi Nakamura from IPv6 Promotion Council of Japan.

This is report items today. We have to update the results of the regular hearing session, we conducted two months ago and another one is how is all participants doing right now. And a little bit more for consideration.

We're now in phase two. It started from top of this year and it will be to the end of 2008. And all participants needs to agree these three conditions - one is the trial will be end at end of 2008 and with no extension. Two - they need to set the goal, that goal that start IPv6 service within during the trial and three, they need to submit a schedule.

And this is the content of the hearing session. The current active participants were nationwide ADSL/VoIP service provider, nationwide FTTH service providers. Layer-3 connectivity and IP-Phone service provider and CDN providers and public - and WiFi access service provider. And this hearing session has eighth interview from the start of these trials. It's including phase one of this trial. And we conducted between the 28th of July and 3rd of August.

And this is the trial target of each participant. IPv6 native/dual connectivity service is one goal and IPv6 layer-three service. And city-wide IPv6 public wireless service and IPv6 CDN platform service.

And after - this is the result of interviewing all participants. I'd like to introduce better one first.

Most participants going well to realise their goals, it seems to be. For example, IP-Phone service has already provided on IPv6 in Japan. And nationwide ADSL/VoIP service provider continues IPv6 trial service. And IPv6 over IPv4 service deployment was completed.

And this is not necessarily bad but a little bit negative one. All participants are thinking it's too early to provide IPv6 service because they said it depends on the consumer's environment. That means most of applications still rely on IPv4 environment and most of users still demand IPv4. And this was a big point I think - they're expecting Windows VISTA.

So this is conclusion and consideration - we will guide participants to start - we will keep guide participants to start IPv6 service. We continuously check their activities and status to be in schedule. I think the next hearing session will next year - early next year. We are conducting these hearing sessions twice a year.

And, if it's not in schedule with - if it's not in schedule and it's impossible to provide IPv6, it seems impossible to provide IPv6 service before the end of 2008, we request them to renumber of address. And we report regularly twice a year about those.

So IPv6 Promotion Council will report this trial status to the APNIC Open Policy Meeting here continuously and it will be - I think we can see in next February.

So that's it for today's report. Thank you very much and I'm sorry for little bit of confusion at the starting of my slides.

Thank you very much.

TOSHIYUKI HOSAKA: Thank you, Nakamura-san. Are there any comments or questions from the floor?

TAKASHI NAKAMURA: OK.

TOSHIYUKI HOSAKA: No? Thank you.

So I would like to conclude the second session of the policy SIG.

I would like to note that we have still one more session in the afternoon starting from 2:00 after lunchtime. So please come back to the same room at 2:00 pm. Thank you for joining and enjoy your lunch.

Thank you.

(End of session)

APPLAUSE

SAVE VOCEA: Just a quick announcement on lunch. If you're wondering, lunch is provided next door. Thank you.

APNIC 22
Policy SIG - Session Three
Thursday 7 September 2006
14:00 - 15:30


EUGENE LI: OK, guys. Good afternoon. Are we ready?

Welcome back to the third part of this Policy SIG. I'm Eugene Li, the co-chair of this SIG.

Let's start with Randy's presentation. Randy please.

RANDY BUSH: Hello.

OK, this is proposal 33 on end site allocation policy for v6. This is presented by Geoff and myself. The idea is to relax current policy. The proposal is that currently the policy says 'forced use of a /48 for end site allocations'. This proposal is to change that to remove the 'forced' part. You may still do it, but you're not forced to only do /48s. What's proposed is that the allocation size is a decision process for the LIR or ISP. It's like v4. You get what we agree that you need. If you need a /48, you can get a /48, OK?

The problem with this is that it confuses the HD-ratio calculation. HD-ratio calculation is based on the allocation size. So, if we left that the same as it is now, you would be not able to calculate HD-ratios. It's just an arithmetic failure. So it says, since it requires a fixed prefix length for the calculation to work that for utilisation calculation, just for the calculation, we're hypothetically going to use a /56. Did that doesn't mean you allocate /56s. It says, when we put it in our slide rule, we use - pardon me, our calculator, we use /56s. OK?

What is the impact of this? To the end users, the people who are paying the bills, the size of an assignment is a local decision. The longest it can be, of course, is a /64, but if they need a /48, they get a /48. If they need a /46, they get a /46. If they need a /3 they...well, maybe not!

For the ISP and NIRs, they choose whether to change their policies and procedures. They may change them, they may not. That's their choice.

For APNIC, the allocations to the LIR or ISP will be based on a utilisation that makes believe the allocation unit was a /56. It's just how the calculation is done. OK?

And we have some examples. What would happen to convert to /56s? If it's /48 end sites, you know, the arithmetic here is pretty boring, so I won't take you through it. Izumi-san, I'm sorry. Izumi-san and I were going to do two presentations together, so she'll take over in a minute. OK? This essentially says what the multipliers will be to achieve the simple, stupid calculation. It's not saying what you will allocate, it's just the calculation.

So the threshold is calculated by the log of the equivalent /56s, div log that and that's what it comes out in terms of the - we've agreed on an HD-ratio of 0.94 and that's the number of /56s that's the equivalent. And, again, this is how - the way you might do it. And, if it's /49, there are 128 /56s. I mean, most of this proposal is just about fixing a stupid arithmetic problem. It's not changing what you do. OK?

So, for example, an ISP uses only /48 end site allocations. That means, to achieve the ratio, they do 24,000 of them. If they do only /56s, they need about 6 million /56 allocations to fill it up. And if they do /60s, they need 96 million of them. I'm sorry to bore you with the arithmetic.

If they mix - why am I getting feedback here? Pull this down? - if they mix them. And they have this many /48s and this many /52s and this many /56s, then that's the equivalent of /56s they would have and they will have achieved the 0.94 HD-ratio.

So, in summary, the size of allocation is a business and technical issue at the level of who's allocating. It's not forced by how we do some arithmetic. If you wish to continue only using /48s, only use /48s. Go for it. If you wish to use /51s, use /51s. But this provides you a way of calculating HD ratios that's consistent based on theoretical /56s. So when we go to calculate you're utilisation, we convert all the pieces, whatever they were, to the number of /56 equivalents and then do the HD-ratio.

Izumi-san.

EUGENE LI: Before I take comments, Izumi-san would like to give some feedback from the JP community.

IZUMI OKUTANI: Good afternoon. My name is Izumi Okutani from JPNIC and I work for a National Internet Registry in Japan, pretty much the JP version of what APNIC does. And since we have a very simple policy development process as in APNIC, we collected some of the comments within our community in Japan regarding this policy proposal.

And actually I think all the comments and concerns that have been expressed within Japan have already been covered by Randy's presentation. So I'm just going to go through them briefly just for the sake of, you know, getting the vibes of how our discussions were.

And, in my next few slides, I'm going to go on quite a bit about the concerns that have been expressed or the points that we want to confirm about but the general basic standpoint is that we support this proposal as long as we can confirm about three of the points. The first are to make sure that there won't be any negative impacts on the existing service that have already been provided by some of the ISPs and the degree of "decisions" left up to LIRs, which have already been pretty much clarified by Randy in his earlier presentation. And the third point is how to convert the registered /48s into /56. Again, this has already been clarified by Randy's presentation.

And so, I don't know if I should go into details about this. The first point is that people felt that there are some rooms for other interpretations by the definitions of "LIR's decision". Maybe if we just interpret it literally, yes, we can probably consider that it's totally left up to LIRs. But what some people are concerned about in Japan is that, um, the policy will be interpreted later, that, yes, it is left up to the choice of LIRs, as long as LIRs take efficient address utilisation into consideration. So they have to make sure that the address space is efficiently utilised. In other words, they don't really have a free choice of their own and they won't be able to take other factors, such as the impact on the service or existing networks into consideration. That's a concern that they have. But, if the choice is totally left up to LIRs, as Randy has suggested, we don't have a problem about that.

And the second point is that you might think that IPv6 network haven't really taken off but then there are a number of ISPs who have already started a commercial service in Japan and one - there is one special case where they already have over 1 million subscribers and if they won't be allowed to continue with the size that they're assigning in their service which is a /48, they will need to redesign their service and their network and they have already distributed the modems to their customers with a /48 already pre-configured. It's going to cost them like a few millions dollars lost. So they want to ensure that they can continue to assign the size that they already do in the existing service, which is a /48.

And the third is the question regarding the conversion of already registered /48s into /56 and since Randy already explained this, we're clear on this and I won't go into details about this.

And there was one question about why this issue is put on the table at this stage, where the situation surrounding IPv6 have not changed much from the time of the initial policy implementation. So if they felt that /48 is an adequate size at the time of the policy implementation, why have we suddenly started discussing that we need to change this, you know, policy, within the past one year or so? That was a question raised from the floor in Japan.

This point is pretty much repetitive so I won't go through this one.

There was a question about creating guidelines of a the boundary of the assignment, not necessarily to assignments of a particular size but if the choice is totally left up to LIRs between any bits then maybe they might assign a /55 or /59, not necessarily because they think this size is adequate but they just have no clue what size to assign. So it may be good to have some recommendations over, you know, assigning over octet boundaries or in accordance with reverse delegations, things like that. That was one suggestion made.

And in general, apart from all this, we are supportive of removing the /48 boundary as worded in the policy. We feel that /48 is too large for most residential users. And in terms of benefits for the service, it would help differentiate the service for ISPs. For example, /48 residential users - sorry, /56 for residential users and /48 for corporate customers. Things like that. So it would help them to, you know, create new services and it is also helpful in adjusting the time for subsequent allocations by assigning, you know, choosing the size that they think is appropriate.

And then we also requested for some show of hands at JPNIC Open Policy Meeting on three of the points. On the first point, about the idea of removing the /48 boundary. And people were generally very supportive of it, as long as the choice is completely left up to the LIRs. And on the second point on how they should choose the size of assignments, whether they should be given some choices, multiple choices, such as /64, /56, /48 and choose from those choices or the whole thing is totally left up to LIRs. And the opinions were quite explicit on which one is better. So we don't really have a strong preference over which way is better. And very few people supported to continue the current policy which is to assign based on /48.

And on the last point about changing the HD-ratio calculation base from /48 to /56, not many people supported the idea nor against it, simply because they were not really sure about the motivation of this change or how this would affect the existing already registered /48s.

So just to summarise, we support this proposal, as long as the choice is totally left up to the LIRs and no documentation or any justification also be required for assignments longer than /48. And on the second point about basing the HD-ratio on a /56, we can support this idea as long as the reason is clear and how these will be counted will be clear. And it's pretty much clarified by Randy's presentation except for the reason for changing from /48 to /56. That's all from me.

Just in case it's not very clear, we support the proposal because of what Randy has clarified in his earlier proposal because most of our concerns are clarified and I think there are quite a number of people from JP on the floor so if there is anything else you want to add, I think it would be good to directly comment to the floor.



Thank you.

EUGENE LI: Thanks, Izumi. Now we take some comments. Yes, Randy.

RANDY BUSH: Randy Bush, IIJ. A small Japanese ISP employing IPv6.

The question of the bit boundary, worried about doing it on four bits because of DNS - what's nice about that. There is a hack existing. We use it in v4. What's nice about that is the pain is where the benefit is. So natural physics will take care of it. In other words, the ISP who wants to delegate on a /57 is the one who will have the pain of the DNS axe. And so the pain is where the benefit is and if they want the pain, they will accept it.

IZUMI OKUTANI: Sure. I think the whole idea is maybe some people are not aware of the pain and simply just, you know, doing it, just by ignorance. So the idea is that maybe we should give -

RANDY BUSH: A little documentation might help.

IZUMI OKUTANI: Yes, exactly.

RANDY BUSH: The reason for becoming concerned about space utilisation in v6 is because there are a number of us who came to dealing with v6 a little bit lathe and we came with unfortunately being a little older than we might like to be and we can remember when we thought 32 bits was infinite and maybe we're trying to relearn the lesson the easy way instead of the hard way. So, you know, let's not harm people but let's not throw away what we don't need to throw away. I think Geoff would like to speak to the result of whether it's calculated on /56 or /48. It really makes no difference. It's just, to me, an arbitrary one has to be chosen and an arbitrary HD-ratio and then you do the math. It will come out slightly differently depending on what you've chosen but it's just stupid arithmetic.

EUGENE LI: Randy, could you please come here and sitting here. Somebody may ask you some questions.

RANDY BUSH: My ears work right here.

GEOFF HUSTON: Geoff Huston, APNIC. I'd just like to respond to one of your questions raised there, which was why change from a /48 to a /56 in terms of the calculation? And I suppose the first answer is it's just mathematics. You've got to choose some mathematics that the recipient can use and the registry can use to figure out when a block is full. Now, applying the 0.94 HD-ratio using a unit of /48s would mean that a normal minimal allocation to a /32 would be considered full once you'd done 33,689 /48s. If you use /56 as the unit rather than /48, you achieve the same HD-ratio out of a /32 with 24,154 /48 inside allocations. What it means is that actually by adopting a /56 as the unit of calculation rather than trying to get a 51% total utilisation rate out of a /32 if you are using /48 end sites, is you only need a 36% fill ratio using the same /48 end sites but calculating it out of /56s.

So what it says is that by choosing a /56 as the unit of calculation, there is a certain amount of implicit messaging going on within the community about the fact that /48s are a fixed point. Choose anything that works between you and your customers. A side effect is that, if you choose to use /48s, you get a slight break in the fill rate you need before you can consider the block fully utilised, which may be a good thing for some people. But over and all, behind all of this, between the address allocator and the address receiver, you simply need to have an agreed piece of mathematics that says, "The block is full." And realistically, what we're trying to do here is to avoid saying all end sites, big or little, must receive the same allocation. We're saying, "Do what's wise in your business. It's not our business to tell you what to do but here's the way that we can both agree when a block is full and you need more."

I'll respond to a second point and just elaborate further on why are we doing this in v6 anyway - what's the problem? The problem that we have noticed in v4 is that when you've only got a very, very small deployment, you can readily change allocation policies and only a small fraction of folk will get affected. When you deploy across a massive base and you try and change the ground rules, instantly everybody has a problem. The initial guidelines that we, the registries, used for the v6 allocation policies were actually drafted inside the IETF and, as I recall, and I may be wrong here, my memory is fading, RFC 3177 defined this and there was a piece of text in there that our experience has shown is woefully wrong. The text was, "Let's start with this and, if it proves too liberal, let's change it later."

And we have found so far in v4 that when you deploy an awful lot of address space and then you try and change the policies, it won't happen. We're trying to look at v6 not as a here-and-now problem but a problem that extends across us and our children and their children, decades rather than years. And we don't think in 50 years' time when there are billions of devices and a massive amount of deployment and a huge amount of burned-in infrastructure, you can change the fundamental addressing structure of v6. What we do now has to work for an awfully long time. The approach is to try and be just slightly more conservative than 3177 and try and avoid changing the engines on the aeroplane while it's in flight.

IZUMI OKUTANI: Those messages have been passed to the community. Japan has understood this. Thank you for the clarifications.

RANDY BUSH: If you're going to make me sit up here, you'd better ask a question.

JORDI PALET: Hi. Jordi Palet, Consulintel. I understand what the policy is trying to change, but I am also thinking in the consequences of the change. Actually, this policy comes from a previous one which was looking for these consequences and, even if the text now is different, at the end, I am feeling that what we are provoking somehow is that the ISPs move their mind from this recommended /48 to a supposed freedom to delegate to the customers whatever they want but I believe that the rest of will be - most of the time they will allocate a /56 and that means that, for those ISPs that allocate a /48, they will be at a disadvantage, because the maths are based on a /56. I am also believe that we should keep allocating to end-users a /48. So that's the main point of my rationale.

So I really think I will be more in the direction of keeping the existing text in the actual policy and not providing the path of the consequence of ultra-conservation, which I think is what we are going to do. Right now, according to Tony Hain's calculations, if I am not wrong, with the HD-ratio change, we will still be able to allocate a /48 for something like 480 years. I think that's much more than sufficient. Of course, we can be wrong but, even if we are wrong in 80% of our calculation, this gives us hundreds of years. I think it's better to keep the existing test and, of course, I am against this policy change.

RANDY BUSH: First, I do not believe you are correct saying that the calculation will be different and have different results for the ISPs that do /48s or /56s. The purpose of this is to come up with a calculation that works no matter what their allocation size is in a fair fashion. OK? So whether they allocate /46s or /92s or /48s or /56s, it will work, OK?

Whether we should fix /48 or /56 today is another matter. I think it's a matter of philosophy and I think you'll find generally that those of us who remember what happened when we had to go through CIDR and forget about Class As, Bs and Cs and are sitting here now looking at institutions that have class-Bs that have 40 devices, we just don't want to go there again. I think, as Geoff said, going from liberal to conservative is very hard. Going from mildly conservative to more liberal is very easy.

MOTOYUKI OHMORI: My name is Motoyuki Ohmori. I'm from Chikushi Jogakuen University. I have a simple question. LIR gives us downstream ISP 65 prefixes, how many routes does upstream ISP should - how many routes should upstream ISP... I'm sorry, how many routes should upstream ISP have in the routing table?

So I think the main purpose, one of the main purposes of the IPv6 is we're using the routing table information at the number of routing information, so I'm caring about if LIR gives ISP /56 prefix length into the ISP.

RANDY BUSH: I am also extremely concerned about the routing information. I do routers for a living. The number of entries that will go in the routing table will be proportional to the amount of multihoming going on not the size of the sites in terms of address space. So, if I am an ISP and I give some space to Save and some space to Philip and they are not multihomed, then I will still just be announcing the aggregate space. If Save is multihomed, I will be announcing the aggregate space and Save will be announcing his piece. And it is independent of the sizes of the allocations, which is what this proposal is discussing.

MOTOYUKI OHMORI: So you are talking about top-level domain routing?

RANDY BUSH: I'm talking about the global routing table.

MOTOYUKI OHMORI: I'm caring about the... how do I say... one LIR routing tables, for example iBGP.

RANDY BUSH: You should think about what Philip said in his tutorial.

MOTOYUKI OHMORI: My English is not very good.

RANDY BUSH: Your English is better than my Japanese.

MOTOYUKI OHMORI: Thanks you. So LIRs should manage the routing information which is related to the lower ISP, right?

RANDY BUSH: Inside the large ISP, there will be routing information to say what is given to each of the smaller users, ISPs, whatever they are. But those have routing information. How many routes the ISP will carry will be proportional to the number of customers, not to the size of address space of each customer. If I have two customers, Philip and Save, I will have two routes internally, no matter whether they have a /56, a /48 or a /3. I will still have one for each of them. The number of routes will be the same.

MOTOYUKI OHMORI: OK, thank you very much.

EUGENE LI: Since it's a policy proposal, we'll see whether we can reach the consensus or not.

For those who are in favour of this proposal, please raise your hands.

OK. Thanks.

For those who are not in favour, please raise your hands.

OK. I believe consensus has been reached.

Now we will continue to the next topic. Save from APNIC will give the presentation.

SAVE VOCEA: This is a proposal from the APNIC Secretariat on the IPv6 assignment size to critical infrastructure. The motivation here is to amend the text of the existing IPv6 policy document that is currently being used to evaluate critical infrastructure assignment sizes.

So when you look at the current problem...

I'm sorry, this is a slight problem. We'll just change laptops.

OK, I'll start again. This is a proposal from the Secretariat to amend the assignment size for critical infrastructure.

The motivation was to clarify the policy for IPv6 portable assignments for critical infrastructure networks. The current problem is that the policy statement says "the minimum assignment made under these terms is a /32", and when APNIC Secretariat receives requests from operators of critical infrastructure, they have used this minimum assignment size to mean they could receive greater than /32s if they were operating multiple POPs or servers providing secondary services. So this has been deemed that additional /32 assignment toss critical infrastructure operators are not conservative.

So when we look at the policies in the other RIRs - AfriNIC is currently discussing a minimum /48 size. ARIN has a /48 minimum assignment size per POP. In the LACNIC region, they have a minimum /48 and up to a /32 maximum per operator. And also in the RIPE NCC, we have a /32 maximum allocation to route server operators.



So the proposal is this: That we do editing of the current text so that it says that the maximum assignment made under these terms is /32 per operator. We hope that with this inside it will avoid the ambiguity and ease evaluation and, if we do get consensus, to implement this immediately after endorsement by the Executive Council.

EUGENE LI: Any comments or questions?

IZUMI OKUTANI: We received one comment from one of the critical infrastructure networks within Japan that they don't support this proposal because they want to be able to assign multiple prefixes for anycast DNS and things like that so, you know they're not going to be able to support those needs if you don't allow multiple assignments.

In terms of routing, they also wish to continue receiving /32s rather than a smaller assignment size. That's their comment and not my personal comment or anything. And as JPNIC, we also feel that there are needs to allow multiple assignments but maybe /32 is too large to allow for each anycast POPs so how about making the minimum size smaller? Like a /48 in other regions and make /32 the maximum?

SAVE VOCEA: We did have that suggestion to put in the initial policy proposal but when we put this proposal forward, we just put kind of the maximum assignment to be a /32 per operator so maybe Paul can talk more to that.

PAUL WILSON: I just thought - it's Paul Wilson from APNIC - I just thought it's worth clarifying that this issue was ambiguous in the existing policy and it did come up in the request process where some operators, possibly in Japan or China, had requested multiple allocations and put in assignments for not anycast but for secondary DNS. And the question was escalated to me as to whether or not the intention of the policy was for there to be an unlimited number of /32 assignments, i.e. one for every secondary that someone wanted to establish. And it was a judgment call at that time and I felt that it was not the intention of the policy in the first place to allow that situation and potentially maybe hundreds of /32s being allocated to an individual operator. So that's why this has come up and indeed, as Izumi said, you could certainly have a /32 as the maximum, which is not just - which is what's being proposed here but then, within that, the operator would have the ability to subdivide that into /48s or into larger prefixes, not necessarily into a /48 unit. So I just thought it was worth mentioning that.

Regarding anycast, we have actually asked whether any of these operators will - do have a plan or a possibility to employ anycast because that, of course, allows a single prefix to be used multiply, multiple times and if an operator wanted to a use a /32 on an anycast network, then they of course would be reassigning that /32 multiple times so they wouldn't be relying on multiple /32s but so far we didn't find any operator who is prepared to consider using IPv6 in an anycast manner in this time which is probably understandable given the state of the technology. Thanks.

RANDY BUSH: Randy Bush, IIJ. What critical infrastructure needs a /32? The entire United States? A /32 is a little large.

SAVE VOCEA: I think at the time the initial policy was made, we just assumed that the minimum assignment was /32 and then the operators thought that, if we wrote 'minimum' they would think there was a maximum. So we thought to avoid the ambiguity, we thought we'd put the maximum assignment would be a /32. But it's still large I think, yeah.

RANDY BUSH: It's enormous. You're talking about secondary DNS servers. They need a /64, right? And when you talk about giving somebody something so that they can chop it up for multiple secondaries, Paul, you know, maybe you can have at most, for any service, a dozen secondaries. And when you talk about taking a /32 and breaking it into /48s, you're talking about 16 million of them, which is slightly bigger than 12.

So, again, I think, we're in v6 fantasy arithmetic here.

PAUL WILSON: I won't comment on whether or not the /32 is too big or not, but I do remember that I think it was in Kitakyushu, when this policy was made, there was a lot of discussion that a /32 was bigger than was necessary and it was quite a detailed discussion. So it did seem, recalling the intent of the policy discussion, the final consensus, that there was enough feeling that a /32 wasn't a large size. They we definitely should not be allocating multiple /approximate 2s so a single operator. No whether or not a /32 is too big, we already had a consensus decision on that and the question I had to answer in between meetings, just during the last year, was whether or not we should do multiple /32s and my judgment was not.

RANDY BUSH: I'll support that.

EUGENE LI: Any other comments? No?

OK, now we need to look for consensus for this proposal. For those who are in favour of this proposal, please raise your hands.

OK, thanks.

For those who are not in favour of this proposal, please raise your hands.

OK. I believe consensus has been reached. Thanks, Save.

The last presentation of this policy will be the experimental assignment for four-byte AS numbers, presented by Maemura-san.

AKINORI MAEMURA: Good afternoon. My name is Akinori Maemura for JPNIC and also France Telecom and I'd like to present to you - this is just an informational presentation. I'd like to present you about my humble idea for four-byte AS number experiment.

Again, this is not a proposal, but just informational. And raising an idea for 4-byte AS number experiment for your discussion.

So background - draft-ietf-idr-as4bytes-12 which is titled 'BGP Support for Four-octet AS Number Space' is already proposed to be the standard. And this Internet draft defines the protocol extension with the four-byte AS number map for the BGP.

And also we have in the APNIC meeting in the previous APNIC meeting proposal 32 version 2, which is title '4-byte AS number policy proposal'. It's already reached to the concensus and EC already endorsed. And then so from the year 2007 January, those who quo like to have the 4-byte AS number can obtain a 4-byte AS number, again from January 2007.

I think there would be some problems with the 4-byte AS numbers, because the existing Autonomous System operators with the 16-bit AS number cannot use their own AS number to try that protocol extension.

And in that proposal in the APNIC meeting previously, just defining the new applicant can obtain one four-byte AS number. So a newcomer only can try before their service is cut off with the 4-byte AS number provision.

And also the tests in isolated test beds will not be enough to the normal operation of 4-byte AS numbers. Maybe, the whole live Internet needs a test before a 4-byte number's Autonomous System will have live traffic.

So I thought that this is a similar situation with the Class A Subnet Experiment which is defined in RFC 1797. This RFC defined the Class A subnet experiment allowing any AS operators to have a /24 Class A subnet advertised and used in the live Internet. With this experiment, operators could verify if their hosts, especially the host with old implementations, can handle a Class A subnet.

So my basic idea is the defining experimental 32-bit AS number to allow operators to try 32-bit AS number in the live Internet.

I'm sorry. I don't know where, but the slide show is not working so well.

So, again, defining experimental 32-bit A S numbers and then also defining the experimental IPv4 address block which is used with this experimental AS number. Then, because this is the experiment, we might need to define the experiment duration. So these experimental numbers will be effective only in a limited time duration.

So this is the whole shape of my idea. First, that defining the experimental numbers, for 32-bit - this is just modelled after the net 39 experiment which is defined in RFC 1797. So let's say the upper 16 bits we press 39 and then the lower 16 bit, one AS number operator can place their own existing AS number.

Then or in RFC 1797 there is the equipment for those who do not have their own AS number. So, from the 49,152 to the 65,535 will be able to be assigned to newcomers. This is the idea for 32-bit AS numbers. Them we need the IPv4 address and the IPv6 address for this experiment. So I'd like - I just think about reusing the net 39 for this experiment. So this is just almost the same with - as defined in RFC 1797.

So the IPv4 experimental block would be 39 and we will have the AS number for the Autonomous System operators. Then .0/24. And then also just the same as the AS number. The 4940052 is available for the newcomer.

And so regarding the IPv6 experimental block, I just use again 39 for just very similar numbers. So 2039:and the existing AS number::/32 would be really nice for the experimental block. Again, there is the same manner with the AS number on the IPv4 address block. The upper Quarter of the whole AS number space would be reserved for the newcomers.

Then defining the duration of the experiment. Let's say until December 2009. This is a bit long for the experiment but January 2010 is the timing for when the RIRs will stop distinguishing between the 16-bit numbers and the 32-bit AS numbers.

So I'd like to have your comments for my humble idea. Then this idea could be compiled as an Internet draft as RFC 1797 was taken. Thank you very much. Geoff, thank you.

GEOFF HUSTON: Geoff Huston, APNIC.

Um, it's not clear to me what you could test using this kind of experimental deployment that would be relevant to the actual problems that might be encountered when we do the 4-byte AS number deployment. Is different to net 39. And it's very, very different to the Class A experiment that was done around classless and class-ful routing. Because the problem potentially with the 4-byte AS number deployment is the boundary between 4-byte and 2-byte doesn't translate properly.

AKINORI MAEMURA: Exactly.

GEOFF HUSTON: How would you know? The reason how you would know that that boundary for some reason isn't working is in the 2-byte world you would start to see AS paths that are, a, very, very long, and b, have AS 0 in them. And in the 4-byte world, if you hadn't done the translation properly from 2-byte to 4-byte, you would see the 2-byte AS path appearing. A, it would be very, very short and, b, if you do a 2-byte translation, you would see AS 23456 all the time.

Now, you could do all of that testing in terms of transitions with one well-placed advertisement rather than having 40,000 AS-holders currently doing it. You usually only do it with one AS in the 4-byte world. You don't need to have Evan advertising to actually test that the transitional points are working properly. You need to have people listening that but they don't all need to shout. They don't all need to, if you will, generate these advertisements.

So I will submit to you humbly that the issues around testing the robustness in our Internet to cope with 32-bit AS numbers, is actually a set of conditions that you could test with just one 32-bit AS number and just one domain that actually tries to speak 4-byte AS numbers. You don't actually need to have everyone doing it because it won't tell you any more information than if you simply experiment carefully with just one.

So please be aware, I suppose, that the issues around 32-bit AS number deployment in BGP are quite different and the reassuring note that I'd like to say here and now once more - I said it last time when I put the proposal forward - is are all of you here today running 16-bit AS number BGP need to do absolutely nothing at all, ever, if you don't want to. Any of the rest of us who deploy 32-bit AS numbers need to deploy versions of BGP that can cope with that but all of the rest of you need to do absolutely nothing ever. It's not your problem. So that's why the testing issue is actually about the boundaries, not about the uniform deployment.

AKINORI MAEMURA: But I do think that the current AS number-holder, AS operator, needs testing for the 4-byte AS acceptance by the time who will actually use the 4-byte AS number.

GEOFF HUSTON: If you have an AS number right now and a routing system - and you do - and I have a 32-bit AS number, and I start advertising, you won't see it as a 32-bit AS number. You won't need to change anything. You won't need to touch your routers. But if someone behind you is 32-bit aware, what will actually happen is they will see my original 32-bit number. You will see the 16-bit equivalent - AS 23456. You actually don't have to do a thing. Your current BGP just works. And all of the update messages that flow through your BGP implementation, the only change is that my update messages will have an additional attribute which from your point of view is an opaque bunch of bits. But you handle that anyway. That's part of your BGP today. So you change nothing and just keeps on working.

AKINORI MAEMURA: I will need some more time to consider about that.

GEOFF HUSTON: It is all about the draft itself and the relatively lengthy description of the transition boundaries of new-to-old BGP and the entire intent and the way in which that transition has been structured - everything that you currently deploy today will transparently without even your knowledge move through 4-byte numbers as 4-byte, as opaque attributes and what you will see is the 2-byte equivalent. It will just work.

AKINORI MAEMURA: Thank you very much, Geoff.

GEOFF HUSTON: Thank you.

AKINORI MAEMURA: I will ask you for your time later.

Any other comments?

Then thank you very much.

EUGENE LI: OK. Thank you, Maemura-san.

Kenny and Toshi, do you have any announcements or comments you need to make here?

KENNY HUANG: OK. Just a reminder - the process of policy making process. Although we have several policy proposals this time but many of them already reach consensus in OPM. So the next process will be these proposals will be ratified by tomorrow's AMM. Ups so once this has been ratified by AMM we'll send it to the mailing list for the public comment period and so once there is no strong objection in the mail list, the proposal will become to be implement by APNIC in three months. That's the rest of the process. Just a reminder.

EUGENE LI: So we will end today's Policy SIG meeting and, again, thank you for all for the participation. We will see you next time.

APPLAUSE