______________________________________________________________________ DRAFT TRANSCRIPT Policy SIG Thursday 2 March 2006 9.00am ______________________________________________________________________ KENNY HUANG: Good morning. Welcome to the Policy SIG. This will be the 13th Policy SIG meeting and, before we start, I would like to mention the housekeeping notes. The first one - please use the microphone. People asking questions, please use the microphone. There's a left one this way and one on the right-hand side. The session is broadcasted, so please use microphone. The morning tea, lunch and afternoon tea area will be in Level 2 foyer. The APRICOT closing event will be 7pm tonight in the ballroom. MyAPNIC and Policy flash demo all day at APNIC help desk. Help desk is available at break times. Also, we have onsite notice board. Please the onsite notice board on screen for participants to check regularly for last-minute change and new updates. That should be shown on the website. Sorry. Later, I'll show you on the website. And also, just pre-notice - APNIC 21 informal closing dinner will be tomorrow. People who complete ticket payment, please come to collect your ticket from the help desk today from 12:30 and tomorrow and also see more details from APNIC website. OK, thank you very much. OK, this is the updated agenda. The agenda order will be starting from 'Review of open action items' presented by Kenny Huang, myself. And also 'IAB report', presented from Leslie and also 'IP policy update - comparative status in all RIR regions' presented by Save from APNIC. Also we have one policy proposal - '4-byte AS number', presented by Geoff Huston from APNIC and also a presentation from Toshi-san - 'Ipv6 portable assignment for multihoming'. Also we have 'Large IPv4 address space usage trial for future IPv6' presented by Kosuke Ito. Also, we have 'Survey results in JP on IPv6 policy change', presented by Izumi from JPNIC. And the last one will be 'Issue with critical infrastructure assignment size' presented by Billy Cheon from KRNIC. OK, that's the order of today's agenda. So, OK, I want to go to the first agenda item. OK, first of all, welcome to the Policy SIG, again. For Policy SIG, the charter: "The charter of the policy SIG 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." And the chair is Kenny Huang, is myself, and also we have co-chair Toshi-san and Eugene Li, sitting on my left-hand side. For policy documents, you can download the documents. For current policies, go to www.apnic.net/docs and for drafts go to www.apnic.net/docs/drafts and for proposals go to www.apnic.net/policy/proposals. Just try to remind again of the policy development timeline. Starting from - we have four phases of policy development, starting from need and discussion, consensus and implement. And for needs, the members, APNIC members, can propose a proposal and after a comment period, four weeks before the meeting discussion and so, when we are in the stage of meeting discussion and after meeting discussion we try to seek consensus from the Policy SIG. If the consensus is reached, then the proposal will be reported to the Annual Member Meeting. Then, if the proposal reaches consensus again in the annual member meeting, they will be released to the mailing list for comment period. Once it reaches consensus again, it will be reported to EC and the EC will endorse the proposal. Finally, the proposal will be implemented in three months. That's the total time frame. Regarding to facilitating the process, policy development facilitation - APNIC Secretariat is the first contact and also SIG chairs check suitability and discussion in appropriate mailing list, discussion in upcoming SIG and annual member meeting. If you want to have a policy change, you can discussion with peers and submit a proposal using the form. You don't need to be a member to participate. The Secretariat is happy to assist if needed. You can download a policy change form from the following website (refers to slide) OK, your involvement - awareness of current policy discussion, you can check on the website. Subscribe to the post comments to the list and you can also attend APNIC meetings, access via remote participation and read minutes and meeting report. Also you can always seek for Secretariat assistance. I'll just repeat some housekeeping - for speakers, please speak slowly and clearly because most Asian-country people, their native language is not English, so please speak slowly. The session is being webcast. Remote participation is possible through the Jabber chat and open participation. Again, please use the mic to speak and, before you speak, please give your name and give your comments or questions. The discussion by consensus - here, try to mention again, not a voting. You can review the APNIC policy website and consensus means no substantial objection. So it's not voting. It's consensus seeking. So approach common agreement and compromise. So last one is open action items. We have three open action items in the APNIC 20 meeting. The first one is policy proposal - proposal 20-001 - action item is "Pending approval at each remaining stage of the policy development process, Secretariat to continue coordinating global acceptance of this policy." OK, so the Secretariat continues this job and Save, you want to comment? SAVE VOCEA: Save from APNIC Secretariat. The first action item is done and we're continuing global coordination. KENNY HUANG: OK, thank you. For the second, proposal 20-002, "Pending approval at each remaining stage of the policy development process, Secretariat to continue coordinating global acceptance of the HD-ratio component of this policy." SAVE VOCEA: This is also done. KENNY HUANG: Thank you. For the last, 20-003, "APNIC Secretariat to refer further discussion of the LIR survey to the mailing list." SAVE VOCEA: This is also done and I'll be reporting on this in my next presentation. KENNY HUANG: OK, right. Thank you for your response. Now we go to the first presentation presented by Leslie from chair of IAB. LESLIE DAIGLE: Good morning and thank you. So what I'd like to do this morning is to give a bit of an overview of the IAB and IETF themselves so you have some context for what's going on here and I'll also give a bit of an update of current work going on there that you might find of interest, particularly relevant to the, you know, to this meeting and/or the rest of your technical activities. So first of all, there is the IETF, which is a formal organisation in and of itself for defining technical standards. But often when one refers to 'the IETF' one is actually talking about a group of organisations that actually work together to take care of all the work that goes into creating and publishing and maintaining those standards. So I like to think of this as being a universe, a universe in constant motion and, at any given point, there is input being brought by technical individuals participating with their own expertise and not as representatives of organisations that contribute to working groups and other activities within the IETF. So, in terms of internal organisations, there is the IETF, which is directed by the Internet Engineering Steering Group, which organises the working groups and you can see that in the upper part of the picture there. That's the bulk of the work of engineering specification. And then there is the IAB, which has some responsibility for big-picture architecture and that is the group of which I am currently chair. So there is a close coordination between these two groups, obviously. The other component on the picture that I want to point out about the IAB - we also formally organise the Internet Research Task Force, which is another component of the overall picture of taking care of everything from research to engineering with some kind of an architectural overview. The output of the IETF is recording request for comment, formal publications, RFCs and those are managed by the RFC editor and the technical protocol parameters associated with IETF specifications are recorded at the IANA. So just a quick note about the IETF itself. Again, I said that it is composed of engineers from all over the world. Most of the work is done by e-mail and formally all participation is actually done by e-mail so you're certainly welcome, if you're not already participating, to engage in a particular working group or technical discussion and you will be a full and honest member of the IETF, participant in the IETF. Apart from that, the IETF does meet three times a year and typically we meet variously across the world, sometimes in Asia, sometimes in Europe and sometimes in North America. All the documents are published and publicly available and I've given two links for places for you to find more information. These slides are in the proceedings from this so you can certainly pull them down at your leisure. So just to give you a sense of the span of work that the IETF does, there are currently seven areas loosely organised around the different levels of the protocol stack from applications to Internet and routing. There are other, sort of, cross-areas like security and then the IETF general area for various policy-related - IETF policy-related - working groups. In March 2006 - well, in about three weeks - there will officially be a new area in the IETF for realtime applications in infrastructure. This is taking over a lot of the Voice over IP and media-related work that was split between the applications area and the transport area and bringing it all into a new area to manage its focus. So just a little bit more about the IAB itself. Again, some hopefully useful pointers - all of our meetings are minuted and you can see the minutes of past meetings at that rather long URL (refers to slide). And we keep track of all the documents that we publish ourselves as well as the documents that we're working on and we always welcome comments on our Internet drafts. I wanted to draw your attention to the technical focus that the IAB has had for the last year - a year running from March to March because that's more or less the cycle of appointees to the IAB and IESG and what not. So this year our three areas of focus have been IPv6, Internet architecture, surprisingly enough, and unwanted traffic. The Internet architecture focus, really, is just a question of trying to find ways and means of bringing useful discussion around Internet architecture as a whole. It's very easy in the IETF or the world to focus on piece problems that need to be solved and at times, local optimisation may be at odds with global optimisation. That's true in architecture as much as anything else. So for instance one of the things that we've done is establish a general architecture discussion list which is - I think it's architecture-discuss@IETF.org and you're welcome to subscribe and see the ongoing raging debates there. IPv6 may not be an obvious current topic in some regards but since the IETF party line is that IPv6 is the way to go - but one of the important things to recognise is that there are still open questions and issues beyond - there's still engineering and technical issues to resolve in order to have a smooth and ongoing deployment. I'm sure that's not news to you. So the kinds of things that the IAB is doing in these areas. We have a couple of ad hoc committees. An IAB ad hoc committee is a group that's formed by invitation of the IAB. We bring together various experts in a given topic. It's used in some sense to inform the discussions of the IAB. The committees themselves have no authority and no decision-making but they are a convenient organisation of people to discuss particular topics. So for instance the IPv6 ad hoc that I've mentioned here includes various people that you would be familiar with, including Geoff Huston, who, as part of the discussions out of this ad hoc group has put out a couple of Internet drafts that are going to RFC that are of interest to this area. One is a document about IPv6 special addresses, essentially what are the - how do you go about getting address allocation for specific experiments, etc, within the IETF. So that's attempting essentially to wrap some kind of a definition around what was a fairly grey area in IANA allocations of IPv6 space and trying to say, "Look, you know, these are the cases where legitimately it is for a technical experiment and is not at odds with the right and proper business of RIR functioning." There was also a document considering the HD-ratio itself. The HD-ratio came out of some technical discussions within the IETF and is documented there. The technical work of analysing it, etc, still goes on within the IETF and that can only inform the policy discussions that take place within the RIRs. So that's sort of an example of how the IETF and RIRs can and should play well together because there is sort of some joint responsibility here and so the IETF, for instance, does not in any way set policy but we hope to be able to pursue the technical activities that will help inform some of the policy choices. So I wanted also to mention that there is - on the IPv6 front, there is a multihoming BoF which is happening right now two doors down. And I apologise in advance - I'll be disappearing there just as soon as I finish giving you this update. It was originally scheduled at a different time but got moved to this morning so my apologies for the confusion there. OK, so, generally speaking, in terms of IETF interest, as I mentioned, IPv6 - the main work is finished but there are lots of different pieces that still need to be ironed out in order to make this successful and useful in the large. Also looking at mobility and a lot of work on signalling and quality of service and traffic engineering going on. I've listed some of the work that's going on there. All of these pieces coming together will play in building the future successful Internet and evolving the network to a future-generation network. Always interesting work going on in the security area. There is never enough security. We never feel secure. These are a few of the actual efforts that are current in the IETF if you want to track them down and get involved or see what is going on specifically in the working groups. The "Better than Nothing" security is one that I'm particularly fond of because it's in essence an attempt to look at - "Well, look, given that full-on security infrastructures are often difficult to ensure mathematically, deploy pragmatically, etc, what can we do that will be better than having no security at all?" So it's kind of a pragmatic look of where can we go with security. Continuing work on AAA and, sure, I think that's enough about that. Right, so, there is lots and lots of work going on in the IETF and it is rarely dull so here's some more of the fun that we're getting ourselves into (refers to slide). As I mentioned earlier, the realtime applications and infrastructure area is spinning up. Here is an example of some of the work that has been ongoing in the IETF but will now be organised under the RAI area - so all the AV stuff, instant messaging, Voice over IP as well as some of the geolocation and emergency preparedness work which is necessary to communications. And that's it. Are there any questions? PAUL WILSON: Thanks very much for the presentation and also for being here. Does the IETF have a view or a position on NGNs that you could share with us? LESLIE DAIGLE: How much longer do we have? PAUL WILSON: As much time as you like. LESLIE DAIGLE: You probably caught my oblique reference to that, to essentially an evolving network. I believe - the IETF being a collection of individuals, it is almost impossible to get an official view, stance, etc, except as what is published in RFCs, but I think it's worth pointing out there was a joint IETF/ITU workshop almost a year ago in May in Geneva where we sort of explored our view of the evolving network and the ITU's view of the evolving network, and our stance was fairly consistently that these are the base protocols and technologies upon which any future network is going to be based and the important thing is to evolve network technologies as opposed to leaping to a Next Generation. So some of the particular technologies that are important are exactly quality of service and signalling - what are the tools that network providers can use to build the services that they wish to offer going forward. OK. Thank you. KENNY HUANG: OK, thank you very much, Leslie. APPLAUSE KENNY HUANG: OK, the next presenter is Save. The topic is, 'IP policy update - comparative status in all RIR regions'. SAVE VOCEA: Good morning. My name is Save Vocea. I'm the Policy Development Manager at APNIC. This is a presentation we give at APNIC policy meetings as an update to share with the community what has been happening in APNIC in terms of policy development and also look at all the other Regional Internet Registry status. If you subscribe to the mailing list, you would have known that in November 2005, the APNIC EC endorsed the following policies. These policies are globally coordinated with the other RIRs. The IANA policy for allocation of IPv6 blocks to the RIRs. And also proposal 31, version 2, which deals with the increase of the HD-ratio from 0.8 to 0.94. The deprecation of the ip6.int reverse DNS service is also being coordinated with the other RIRs to have a succession date in June 2006. This is a snapshot of the current policy proposals and Kenny also mentioned the URL. One thing I'd like to point out is what is discussed in the previous policy meeting is the application of HD-ratio to IPv4. It's to apply the HD-ratio because there were concerns from the community. It was felt that some of the ISPs in the region had difficulty satisfying the 80% rule. I will bring up the slides later for discussion after my presentation so I won't talk much into it but in the other RIRs, the RIPE region is in the last call. But the discussions were abandoned in LACNIC and ARIN. As you will know, in today's Open Policy Meeting, there has been only one policy proposal and that's by Geoff Huston. He will talk to it after my presentation, so I will not talk much to it as well because I'll leave it to Geoff. But when it was discussed in the APNIC mailing list, there had been no comments from the APNIC community, so that's just what I'd like to share here. In the other RIRs, it's also undergoing the discussion phase and it will be presented in their respective Open Policy Meetings. I'd like to share now the status in the other RIRs in terms of all the IP resources in IPv4, v6, ASN numbers. As I've already mentioned earlier, about the application of HD-ratio to v4 allocations, I will discuss it again later, after this - at the end of my presentation. But, at the RIPE region, it's in its concluding phase and next week, I think, it's the final date. In the LACNIC region, there is discussion that's undergoing about the additional allocation to regional ISPs at 50% utilisation. They felt that some regional ISPs - it's hard for them to reach 80% and they had to allocate again to their members so they're thinking of having a policy to provide some allocation at 50%. There is an address space for anycast services under discussion at the RIPE and ARIN Region. And again, also in the ARIN region, they have adopted the address space for multiple discrete networks. This was abandoned in APNIC in the last APNIC meeting. ARIN has adopted a global addresses for private network interconnectivity and in the AfriNIC region, they are having new policies to the current policies which is the end-user assignment and also the temporary address assignments for experimental purposes and these are awaiting the board approval. When we look at the IPv6 status in other regions, as we mentioned in the HD-ratio to 0.94, it had been endorsed in the APNIC region, it's also adopted in the ARIN community and in the RIPE community, it's under discussion. There was no consensus by APNIC at the last APNIC meeting to adopt changing the end-users' address space from 0.4 it 0.56 but it's under discussion in the ARIN and RIPE region. Also mentioned earlier that the IPv6 blocks from IANA to RIRs is under discussion in all regions and had been endorsed in APNIC, ARIN and LACNIC. RIPE is discussing the address space for anycast services and this topic here, the PI assignments for endsite, which is portable assignments for a region, is being discussed by ARIN. It's one of the hot topics in the ppml mailing list and, as a matter of fact, they're having discussions in the IAB panel next door, as Leslie just mentioned. When we look at the ASNs, the 4-byte AS number is being discussed in all regions. And AfriNIC had made some changes to their ASN assignment criteria and it's under discussion. For the DNS, also, the deprecation of ip6.int reverse DNS service has been endorsed by APNIC EC and as it's being globally coordinated, the succession date for that is 6 June 2006. There is a DNSSEC reverse tree that's been implemented in the RIPE region. And that's where all the policy proposals, references are (refers to slide). Thank you. SANJAYA: The date is not 6th of June. It's 1st of June. SAVE VOCEA: Yes. Sorry. KENNY HUANG: OK, any questions or comments? OK, thank you, Save. SAVE VOCEA: As I mentioned earlier in my presentation, I wanted to put this up and seek facilitation from the SIG chairs and whatever actions can be taken from this Open Policy Meeting on the proposal on the application of HD-ratio to IPv4. It was first discussed in APNIC 18 and no clear decision was made. But APNIC Secretariat was requested to conduct a survey with all the LIRs and also got assistance from the NIRs. The survey was shared in APNIC 20 and what we said was that there was no proof of correlation between the problems, network size and complexity or the number of services and levels of hierarchy. Also, when it was put back to the mailing list after that last meeting, there was really no further support expressed. And, as I said, the last call - it's in its last call at the RIPE region. It had been abandoned in the LACNIC and ARIN region. So if you could just maybe seek the chair's facilitation in this for today. GERMAN VALDEZ: Just for a few comments about the policy of HD-ratio for IPv4. Following the discussions in the region that Save described and, from LACNIC perspective, and from some members in the region, we are following this with some concerns because the understanding and the comments made in LACNIC list reflects that this proposal, if it's approved in one region it can have an impact in the rate of consumption of IPv4 in general. So the impact on the decision of one region can reflect in other parts of the world. Even though we are worried about this, these discussions, we don't want to influence in other decision processes in other Regional Internet Registries but we only ask for you - the discussions take into account all the variables involved in this, in this proposal. That's my comment. KENNY HUANG: OK, thank you. Geoff. GEOFF HUSTON: I was asked a couple of weeks ago by the RIPE NCC to do an investigation of the impacts of this policy in the RIPE region in terms of its impact on total address consumption of the remaining /8s in the unallocated pool. What I did was actually look at the last five years of allocations from all of the RIRs and look at their distribution in size. So you get the sort of lots of /20s, a few /19s and so on. And then I went back and said, "Well, these allocations have been performed on the basis of an 80% utilisation," so you can actually do a spread of populations. You randomly pick a population that would have qualified for a /20 and so on. I simulated an RIR doing 10,000 allocations, each RIR doing 10,000 allocations using that principle and ran that experiment a further thousand times. So I felt I had a relatively good range of, you know, this is what the last five years looked like in demand. And then I said, "Well, instead of using an 80% fixed utilisation, what would have been the result had this policy been implemented?" So for the RIPE region, at a 0.96 HD-ratio, the impacts are felt on the large applications and they're significant. The address consumption rate of the RIPE NCC, had it been using that allocation strategy for the last five years, was a total increase in address consumption for the same range of populations that they were servicing by 47%. So, in other words, rather than allocating three /8s, you would have got through approximately 4.5 for the same population. If this proposal was adopted in the APNIC region, it's 49%. Now, the LACNIC issue is, in some ways, significant, and should be borne in mind; that, if RIPE adopted this all by itself and none of the other RIRs did, then this does have an impact on consumption rates and would bring in this expected date when we're going to run out by approximately one year. If all of the RIRs adopted this policy today, it would bring in that date by two years because, in particular, RIPE and APNIC would have effectively 50% more addresses being released for the same populations. So, when you, as a community, look at this particular policy proposal, I think this is a useful statistic to bear in mind - that its impact is not just, if you will, adjusting the address allocations to suit what we think the industry structure is, but we should be mindful of precisely what we're doing in terms of consumption rates and the basic message is that for those RIRs - and there are three - ARIN is included - that have a sizeable percentage, significant percentage of high allocations, the total allocation consumption increases significantly. I believe I posted this to the APNIC policy mailing list, copies have also been posted to the RIPE and the ARIN mailing list and, yes, I have discussed this with the LACNIC folk. It's hard to actually mirror the LACNIC implications here, but certainly inside this framework, LACNIC might, if you will, not be able to get one or two /8 s near the end of the period of exhaustion, so, yes, there are cross-RIR impacts here that we need to be mindful of. SAVE VOCEA: Thank you, Geoff. Paul. PAUL WILSON: I've got a question for Geoff, actually. When this policy was first formulated, I think we had 15 to 18 years of IPv4 address supply available and according to the projections - not predictions, but projections - that are done, what is it today? GEOFF HUSTON: January 6, 2012. PAUL WILSON: Wow. RANDY BUSH: What time? LAUGHTER PAUL WILSON: Instead of 15 to 18 years, there's been an exponential growth and it's now seven years. GEOFF HUSTON: What has happened in the last couple of years, Paul, is actually the unadvertised pool of addresses - stuff that's been allocated that I can't see in the routing table - over the last few years, that amount of black space has been increasing rather than decreasing and that's had a dramatic effect on the total consumption rates because, if we're not actually managing to recycle addresses and we're feeding this black space, then the anticipated date of IANA exhaustion comes screaming in and, yes, we do have a relatively short period, using current industry behaviour, of the remaining lifetime of those 61 /8s. RANDY BUSH: This discussion drifted over to - I think it was the ARIN ppml list or NANOG or something, and there was discussion that, "Oh, so what's happened is you're fitting a log to a linear so it's going to be bad at the high end so let's change it so it works at the high end," and then, of course, what happens is that, at the low end, it doesn't work. Essentially, you're trying to fit a log to a linear. It does not work, OK? In either case, it is the small people, the people with small requests, who get short stick. So it's either the large requests get more than they need, which disenfranchises the small people as we run out of resources, or you tilt it the other way to make the large come out the same and the small people get less than they need. It does not work. You're trying to fit a log to a linear. KENNY HUANG: OK, thank you, Randy. Any questions or comments? OK, regarding to this open action actually is pending for quite a while and we probably need to decide how to move to the next step. And either we have some consensus from the meeting of either we submit a proposal or we remain submitted to the mailing list to wait another month and then we make a decision after that. OK, I suggest we move the issue to discuss in the mailing list for another one month and, after one month, the SIG chair will decide what to at the next step - either pending a proposal, continue the proposal or abandon the proposal. OK. Thank you. Sorry, any objections? OK, right. Thank you. Before moving to the next session item, I would like to change my chair to our co-chair Eugene Li and he will chair the next session. Thank you very much. EUGENE LI: Hi, everyone. This is Eugene Li, the co-chair of this policy SIG. I will chair the following two presentations. Let's start with today's only policy proposal, presented by Geoff Huston from APNIC. Please. GEOFF HUSTON: This is a really quick proposal and it assumes that you are familiar with or have read a report I did at the previous APNIC meeting on the consumption of AS numbers. So this proposal is actually about what to do when we're looking at the expected exhaustion of the 16-bit AS number pool. So, at some point, sometime between now and around 2011, we need to actually transition the new part of the Internet into use 32-bit AS numbers and possibly assist in transitioning the existing part to use the same 32-bit numbers. Although the second part of this, upgrading the existing infrastructure, is actually not required as part of this transition. So this policy proposal is actually aimed at assisting the industry, vendors and deployers, in transitioning to use 32-bit numbers. What we're trying to do is to plan ahead rather than panic at the time. Because we know on consumption rates that the AS number pool of 65,535 numbers will exhaust. It will exhaust some time around 2011 or so. There doesn't seem to be a panic rush going on there. This is not like IPv4 addresses. But certainly right now on the routers you run, from a number of major vendors, there is no code in your routers to support the use of a 32-bit AS number if you happen to get one for your network. Now, if you don't get one, you don't need to change your routing system. But, if you do get one, you need new code. So, at some point, we need to send some signals out there to the industry about what kind of dates are required for us to do this transition painlessly. The essential attributes of this policy is to ease this transition, to try and inform all of you and the industry at large what actions will happen on what date so you can plan for that and give very clear dates in terms of registry actions themselves. So the underlying thing here - and I've got it in the wrong font colour but if you have a look at draft IETF 4-byte AS Number Proposal, you will see there is something that describes the elements to bootstrap ourselves into that domain. I've got some work on the projected exhaustion of that space. Henk Uijterwaal presented some work yesterday from RIPE looking at a similar scenario, slightly different bent looking at reclamation but, between the two of us, both of us agree that there is a problem coming up and considering this is now not a very small operation - the Internet is a big one - and there are 21,000 ASes out there at the moment, a few of you need to consider what you're doing and understand that, in the size of your organisation's network, you might take some years to get the necessary testing and deployment phases done before you're ready. So we'd like to do this in an ordered fashion that doesn't produce surprises. So the assumption here is that the IANA actions in setting up a 32-bit AS number registry, which we believe is relatively simple, should be documented and completed by the 1st of January next year. In essence, all this does is take the existing number registry and add another 4.3 billion numbers to it as a single-line entry. It doesn't change any other structure of the registry. The proposal itself is hopefully relatively simple. It actually just nominates three dates. The first date is the date the proposal becomes effective and commencing 1 January next year, if you want to experiment or otherwise use a 32-bit AS number, you will be able to ask explicitly for one of those numbers from the number pool. If you don't say anything, you will get an existing 16-bit number as you'd always have gotten. So as of 1 January 2007, the proposal is that, if you want to use a 4-byte number, you can say so and the registry will give you one according to its normal allocation practices. There's no change in the allocation policy, just the number we're dealing with. The next date is very closer to the predicted run-out date for the 32-bit numbers. One would hope that folk building new networks or wanting new AS numbers, would have been able to source and deploy new versions of BGP in their routers to keep with 4-byte AS numbers. So the proposal is that by 1 January 2009, we flip and that 32-bit numbers will be allocated by default. In other words, the top 16 bits will be non-zero. There should be, according to the prediction, sufficient AS numbers left in the 16-bit pool such that, if you want a 16-bit number because you haven't got access to new versions of BGP by then, you should be able to ask for them explicitly. So one would hope that, on 1 January 2009, if you meet the allocation criteria, by default after that date, you would get a 4-byte number unless you explicitly ask for a 2-byte number. The proposal disappears on 1 January 2010. After that, it's one 32-bit number pool. You should consider all the numbers by 1 January 2010 as 4-byte numbers. Down there (refers to slide) - what do I mean by 2-byte to 4-byte? The 16-bit numbers are from 0 to 65,535. The 32-bit only numbers are from 65,536 through to 4.2 billion. And after 1 January 2010, we say it's a very big number pool and it extends from zero to 4.3 billion. What it doesn't do - no more private AS number pools. It doesn't define any documentation-use AS numbers. It doesn't continue any legacy pool after 1 January 2010. It's just 4-byte numbers at that point. This policy would effectively vaporise on 1 January 2010 and we're dealing with a 4-byte AS number pool. APNIC can adopt this policy unilaterally as did can any other RIR, so it doesn't require coordinated actions, nor does it define additional AS number allocation practices. This is merely a case of offering some dates and some default RIR registry practices commencing at each of those three dates. And that's the proposal. End of slides. Any questions or comments? IZUMI OKUTANI: Izumi from JPNIC. We actually, you know, shared this proposal within our community and we didn't have a big, you know, comment or problems, but there was one question. And I personally think that it would probably lose the spirit of the proposal, but there was a question - how flexible this date could be and if it's a really rigid date and it's got to be, you know, set on this date no matter what or if some unexpected problems happen it could be reviewed and changed again. That was the question from one of the community members. GEOFF HUSTON: Certainly, the issue here was indeed to specify dates for, I suppose, quite a particular reason. When this was first aired as, "We have a problem, we should do something about this," over a year ago, one of the major router vendors had responded along the lines of, "Well, you know, we put features in routers when customers ask for them and basically we only listen to customers who spend money so that, when customers scream that this is an important consideration for purchasing our gear, it will be in there and we haven't heard anyone so we're not doing anything," which struck me as a relatively backward view of this problem. Since then, I believe, that particular router vendor has, I hear second-hand, put this particular feature in BGP on their implementation track. But, of course, then comes the issue of when should it be done. And we know pretty much that, if our current allocation rates stay the way they are, we had better be completely finished with this transition about around 2011. And knowing some very big networks take some certain months if not years to do the testing and deployment of this kind of stuff, then this is trying to offer some dates to the industry at large to say, "Look, by 2010, we'd better have solved this." That's why the first date, 2007 says, "If you're ready and want to use it, you can." The 2009, some three years hence from today, it's a case of saying, "We really should have got most of the software fielded. If you feel that you haven't got software ready in your BGP, you can ask for a 2-byte number and will get it." So it's not that you won't have access to those numbers, it's just by default, we expect most of that BGP to be out there by that date. So I think I would respond in saying, there are good reasons for having dates but if, as an ISP, you can't make it, certainly by 2009 to 2010, there's a way out. You can use a 2-byte number if you want one. It's not a case that you have to demonstrate anything particular. This policy proposal says, "You just simply have to say, 'I'd like a 2-byte number please'." IZUMI OKUTANI: Thank you very much. I think we support this proposal and I think it would help in the transition of AS numbers. Thank you. GEOFF HUSTON: Thank you. EUGENE LI: Any other questions or comments? No? GEOFF HUSTON: OK. Thank you. EUGENE LI: Since this is a policy proposal, we need to look for consensus here. Anyone who is in favour of this proposal, please raise your hands. (Pause) Thanks. That's 14 hands. Who is not in favour of this proposal? Please also raise your hands. (Pause) OK. This is consensus. Thanks, Geoff. GEOFF HUSTON: Thank you. EUGENE LI: The next presentation will be from Toshi-san and it is called 'IPv6 portable assignment for multihoming'. TOSHIYUKI HOSAKA: Thank you. My name is Toshi from JPNIC. This presentation is from a special interest group on IPv6 portable assignment for multihoming. This originally was planned to be made by Katsuyasu Toyama but he can't make it. So I will go through his slide on his behalf. And Toyama-san is waiting in the Jabber chat room. He can answer your questions if you have them. So this is the outline of this presentation. This presentation introduced our discussions so far in JPNIC communities. Discussions in IPv6 portable assignment for multihoming. And, first, I will go through our principles. And, second, requirement analysis. And, third, I'd like to go through issues on the IPv6 global routing table. And finally I want to go through draft policy for assignment of IPv6 PI address space for multihoming. So, our principle - we recognise how these principles and goals are important when we consider the condition of the IPv6 multihoming assignment. We recognise we should be consistent with the goals of IPv6 address management, which is described in the current IPv6 policy document. Those are uniqueness, registration, aggregation, conservation, fairness and minimised overhead. But on the other hand we should be flexible to operational reality. We should be ready to accommodate business's operational needs from communities. And we should accommodate the control over the routing table. We should control the routing table. And we should ensure it will not be out of control. The criteria of IPv6 multihoming PI should be fair among the community. So, the requirement for the multihoming PI for IPv6 address - currently, there are various discussions taking place on this issue, IPv6 multihoming PI. Mainly in the ppml mailing list in ARIN region. And there are comments made in this mailing list. It varies by person to person. So we should sort out those kind of requirements. So when we think of the PI requirement, there are some categorisation. At first, there is a requirement for a multihoming for organisations which use redundant connectivity. And there is also requirement for the permanent address space in other address space which don't need renumber. For organisations which require unique address to be independent of upstream providers. And also we can categorise the requirement. There are two types of organisations which need a portable space but unable to have portable allocation under current IPv6 policy. For example, smaller LIRs which cannot demonstrate to assign 200 customers in two years. Like, such as transit-only provider or very small local providers. And the end-sites cannot receive portable allocation or assignment because current IPv6 policy prohibits to give the allocation to end-sites. And we have the issue of size. Organisations which require portable assignment can also be categorised by size. There are various network, so which has a large network or small network and the number of devices in the network varies, network by network. So, our target. Our target is here. We don't care for other permanent address space requirement because it should not be considered currently because someone can say this is just a selfish requirement or something. And this area, LIR, a smaller LIR requirement, we should separate this from portable assignment requirement because this should be addressed by a current IPv6 policy. In particular, 200 customer requirement. So we don't care. We don't care about this area this time. So, to summarise, we focus the target for only multihoming because end-sites organisations has strong needs for redundant Internet connectivity. Technical requirement for multihoming is clear and easy to define the criteria. And also we focus on end-sites only and not LIR because the policy for small LIRs to be covered by modifying the current IPv6 policy. And, currently, no policies for end-sites, so end-sites cannot receive portable assignment. So we focus on end-sites. And we do not differentiate the criteria by size of the organisations because organisations' size does not justify their needs of PI address space. Sometimes smaller organisations require redundancy of Internet access. We do not differentiate by size. So our target is multihomed or our plans to be multihomed network. And our target is also end-sites. And no differentiation by size of the organisation. So we should consider this. When we talk about this issue, we cannot avoid the issue on the IPv6 global routing table. So I will mention about this issue. In principle, we think that the growth of IPv6 global routing table is unavoidable because regardless whether we implement PI policy or not, the global routing table growth is inevitable because the end-sites will use a punching hole. So we think it is more constructive to PI address from particular block. That is better than to create punching holes in PA block. And we estimate some future trend of IPv6 global routing table, which is described in this slide. There will always be some requirement for redundant connectivity in the future from the business perspective. Currently, we have a lot of multihomed network in the enterprises or small ISPs also in organisations. If we do not have PI address, such organisations will multihome by making punching holes which is not legitimate in the current IPv6 policy document. And leaving the situation as it is would allow punching holes just like the current IPv4 Internet and it will inevitably lead to a messy situation. There will be maybe lots of /48s or /56s in the global routing table. So, allowing portable assignments for a multihomed network from a particular specified address block at an early stage, it can prevent chaos in portable allocation range. And this is better in terms of the address space management. And according to some router bender - routers possibly handle prefixes in the separate PI space better than punching holes in PA space. Basically, punching holes are harmful. For example, it can be used to intentionally reroute traffic to cheaper links. If better multihoming method comes up in the future, we can enforce them to move to new space or new multihoming method until some specified date. So, I will go through our draft policy for the IPv6 PI address space. So the target is end-sites regardless of size. And assignment criteria is like this - the end-sites picture assigned IPv6 PI address space must be multihomed using the assigned PI address space in three months. The second - if the PI address space is not used for multihoming after three months, the address space can be reclined. This is just like IPv4 PI group. And the end-sites that receive IPv6 address space must pay the fee for this space. And regarding PI address space. Portable assignment should be made from a specified block. This should be separated from current PA address space. For example, 3001. The size should be the same size as provider aggregatable address, currently a /48. So this is the summary of this presentation. Regarding IPv6 portable assignment for multihoming - we analysed the requirement for IPv6 PI address space and defined the target. And this is currently plans to be multihomed end-sites regardless of its size. Its network size. And we considered the future trend of the IPv6 global routing table and we should control the PI address space by separating it from PA address space to avoid the punching holes. And currently, we are discussing assignment policy for PI address space. And end-sites, which currently plan to be multihomed and end-sites must be specified - multihomed in a specified period - three months. So, that's all from me. Thank you. EUGENE LI: Any comments or questions? TOSHIYUKI HOSAKA: We are gathering the routing table data and discussing the condition of the PI assignment and we're coming back with the formal proposal in the next APNIC meeting. If we can have some feedback from you, that would be much appreciated. EUGENE LI: Thank you. APPLAUSE Toshi will chair the following sessions. TOSHIYUKI HOSAKA: The first session of this policy SIG ends at 10:30, so we only have nine minutes left, so we can enter the tea break from now for 40 minutes. So please come back to this room at 11am. Thank you. [SESSION 2 - 11am] TOSHIYUKI HOSAKA: So it's 11am. Welcome back to the Policy SIG again. The first presenter of the second session in this Policy SIG is Mr Kosuke Ito from IPv6 Promotion Council of Japan. KOSUKE ITO: Good morning. My name is Kosuke from IPv6 Promotion Council of Japan. Regularly we report our large IPv4 address space utilising trial since back in 2001, I believe. And this time it will be our 10th report at an APNIC meeting. For this time, I'd like to report that, first of all, we ended the Phase 1 of this trial and that was two APNICs ago, we were proposing to extend this program toward the end of 2008. Then we tried to make the purpose of the Phase 1 and Phase 2. So I'd like to report how we have done in Phase 1. Then, at the last part, we report how we started off Phase 2 of this trial. Phase 1 - at the end of the Phase 1 - as of the end of 2005, Phase 1 was closed, as we planned. Then, for a participant has completed to transit to IPv6 service deployment, the address space allocated to has been returned to IPv6 PC by the deadline, which is the end of 2005. There are six participants who are involved in the Phase 1 and there's one participant that is deploying IPv6 service, which is YOZAN is the participant who is operating a WiMAX carrier service. So we collected address space from them to be data shifting to the real business space. For the other participants, address space allocated to each of them is succeeded to be utilised for Phase 2. Then, as at last January, we collecting the reports of the Phase 1 from each of the participants at the regular hearing session. Now, according to them, we summarised that Phase 1 of the results, which is - first part - goodness of the trial. By this trial, large global address space allocation at the one time leads the new service deployment, which is - we can observe that it's less-expensive - Always-on broadband services for home users and also multiple fixed-IP address service and also area-wide wireless LAN service, which requires that a certain address block at each of the access points. And VoIP/IP phone service and contents delivery network service. And new findings we could have is that ease of the large-scale network service design, by the large global address space allocation at the one time, leads to less operational cost which is more efficient way to design the network. And also, actually, they are start looking at how they can start up the v6 transition. So this is very good part of the trial itself. Each participant considering when they are feel like it would be better to shift toward the v6 so that they can save operational costs or save - I mean, trying to make their network service more scaleable. So that they started off to how they can do for that future network involvement. Then they find out some issues to be cleared, or issues to be solved. And some participants found that IPv6-based service is cost saving, as I said so this is one very good goodness of the trial. However, as I said, many of them are still experiencing many barriers for the transition to IPv6. IPv6 readiness of devices - many of them now, most of the routers and many of the PCs are getting ready for v6. However, not ready yet for many of the necessities surrounding or integrating the network service, which is like maintaining basic service, like load balancing, so many of the things to maintain a service level and service in the very business level. They can't get all the components together for the v6 ready to use. And also access network to users, which is not ready for the many of the ISPs. Of course, in Japan, many of the large-scale ISPs started off the v6 service but not all of them. And especially in the suburbs or rural areas of the ISPs, small ISPs, they don't start a v6 service. So it's pretty hard to make the native v6 service through end to end. And that's maybe the part that is difficult to make the awareness of the users for the v6 itself. And some of the v4 network is not able to accommodate PC enabling the IPv6. So we have to get rid of these kinds of existing v4 networks, trying to be more operatable with the IPv6-ready PCs. And readiness of software. I think that, so far, getting better, but still the DNS query, stability, that kind of stuff, is still not fully deployed yet. Many of the browsers or basic applications is not ready yet and, like, web authentication, or that kind of application level readiness for the v6 is not ready. And, of course, that makes some security halls. So many of the participants feels like it's pretty too soon to start off the service by v6. And this is the very serious part - they are a little bit hesitant to start off the large-scale service by the v6, is that security part. And also, they - some of them try to start off the v6, but they have to know, I mean, they found to know that additional care is necessary for v6 DoS or DoS attack or spam filtering, that kind of stuff. Some of them experienced that many of the DoS attack increased on unused IPv6 address space, so they have to make certain treatment of that kind of space for that v6 when they start to use it. So that's all about we found out by closing of Phase 1. Then these are - these barriers or issues we should try to clear up for the Phase 2. Many of them expressed that they like to continue this program by - because of they would like to clear up these kinds of issues. Then we start at Phase 2, at the beginning of this year. So far, IPv6 Promotion Council and continuing participants have worked to renew the contract so that they can continuously participate on in program. And, as of January 1st, we officially started off the trial. And this Phase 2 is to be end by the end of 2008. And, in the contract, participants needs to agree the three basic conditions as listed. First of all, this trial is closed at the end of 2008 and no extension. This is the promise we made at the APNIC meeting in Fiji maybe, and when this extension was approved by the APNIC committee. And participants need to set the IPv6 service deployment goal within this trial. And need to submit the deployment schedule. So the mandate that the participants started off any sort of v6 service officially which the end-users or users of the service can be choosing from their official business. And, as we have done so far, report regularly - twice a year - between IPv6 PC and participants of this program. And participants of the Phase 2 is quite not changed from the Phase 1. Nationwide ADSL/VoIP service provider. Nationwide Always-on FTTH service provider, L3 connectivity/IP-Phone service provider and contents delivery network ASP and public wireless-LAN access service provider. These five are continuing participants to the Phase 2. And maybe you can guess what they would like to start off with IPv6 and this is here. Native/dual connectivity service and L3 service, which is stable with L3 connectivity by IPv6 regardless of the base IP infrastructure, which is they are on top of the - this service provider is like VN, or virtual network, operator, so they struggle with across the basic infrastructure to accommodate v6 or not, so they are trying to utilise the tunnel or VN type of technology, which they can make that independent from the basic infrastructure and their service IP network. And a city-wide IPv6 public wireless service, which is maybe many of you are experienced in Kyoto with the Kyoto city area-wide wireless service which they are trying to makes IPv6 ready and the IPv6 contents delivery network platform service by the ISPs. Then we just started off the Phase 2 and many of them are quite reasonable time schedules, which is - I cannot disclose up here but they are trying to make this kind of a service by the end of 2007 or middle of 2008. So this should be more practical time schedule, I believe, than we are - from the IPv6 PC, we are trying to observe how we can act in this program and trying to catch up regularly from them about how it's going on on that individual participants' activities. And some basic things we should share here - we like to bring those kinds of issues or findings at the regularly in APNIC Policy SIG. That's all. Thank you. Is there any questions or comments? TOSHIYUKI HOSAKA: Any comments or questions? Izumi, are you making comments or questions? IZUMI OKUTANI: No, I'm getting ready for my presentation. Sorry. TOSHIYUKI HOSAKA: OK, that's fine. Thank you, Ito-san. I believe you will be coming back next APNIC meeting to report this update? KOSUKE ITO: Yes. We are happy to report this trial status every APNIC meeting. TOSHIYUKI HOSAKA: Thank you, Ito-san. KOSUKE ITO: Right. Thank you very much. APPLAUSE TOSHIYUKI HOSAKA: So next speaker is Izumi Okutani from JPNIC. She will be talking about survey results in JP on IPv6 policy change. IZUMI OKUTANI: Sorry. It took some time to get ready. Hello, everybody. My name is Izumi Okutani and I work for JPNIC, which is the National Internet Registry in Japan. In this presentation, I would like to introduce the results of the surveys we made over the change of IPv6 assignment size, which was proposed at the last meeting by Geoff. So just to explain the background a little bit - in the last meeting, in APNIC 20, I remember that Geoff Huston made a proposal to - not exactly to change - but add a new assignment size of /56 in addition to the current /48. And, for this particular idea, there was a strong concern expressed by one of the members in Japan and we wanted to find out if it was just this member which was really concerned about this change or, you know, it reflects the concerns of the community in general. So we decided to conduct a survey. And the objective is from two points. Firstly - to see how this policy change would impact LIRs from the perspective of services they're providing, the network and the impact to their customers and also if it would, you know, lead to any additional expenses. And the second point is that, we understand that there has been, like, slight three variations of the similar proposal. One is what's been proposed in APNIC 20 and another one has been proposed in RIPE, which is a little bit different version from the APNIC one, and also in ARIN. So we wanted to know if, out of these three proposals, a particular proposal would make it more agreeable to the LIRs in Japan or not, or they just don't like the idea in general. So what we did was that, we have 64 LIRs who are currently receiving IPv6 assignments in Japan, so we sent an e-mail questionnaire to these people. We got responses from 36 LIRs, so that's a little over 50% responses. And the services they're providing is a little over 70%, the majority of the LIRs are currently still providing the testing service and the rest - a little less than 30% of the LIRs - have started the commercial service. And the method is that we basically sent an e-mail questionnaire on these four areas that I've just explained earlier - which is services, network, customer and cost. And we asked questions - how the policy change would have an impact on these four areas for each of the three cases. Case 1 is the case which was introduced, proposed, in APNIC 20. This is simply adding a /56 as an additional assignment size to /48. And this is intended to be used for SOHO or home users. The second case is what was proposed in RIPE 50 and RIPE 51, I believe. And the difference between the APNIC one and this one is that an LIR can decide whether to have a /48 or /56, depending on their needs. So it's more flexible than the one that was proposed in APNIC 20. And Case 3 - I don't think it's formally been proposed in ARIN, but there was a talk about removing the fixed boundary. So instead of fixing boundaries to /48 or /56, let's do it like IPv4, so it can be anywhere within the boundary. For example, it can be a /39 or /64 or whatever size the LIR thinks is appropriate to fit the size of the network. So we tried to see the impact on each of the three cases. And so the result is first, the impact on the service. We found that regardless of which case it was, the majority of the people felt that there's no impact on their service they're providing. So over 80% of the people replied 'no impact'. And reasons that they felt there was no impact was because most of them haven't started the commercial service. And we were expecting maybe, you know, they might give the reason, "It would have more flexibility in size for Cases 2 and 3," but, when we actually see the results, not that many people see this as the reason. And for those people who have actually replied that there will be impact on the service, for most of them, they have to change the target of the service if this policy would be implemented. For example, I think at the moment they don't really differentiate between, like, SOHO and corporate services but they might have to, you know, start splitting the target or things like that. The impact on the network. Again, the majority of the people replied there's no impact on the network. And as the flexibility of the policy increases, the impact slightly decreases. And it seems that the more flexibility that there is given to the policy, the impact will shift from the customer network to the infrastructure. So they have to make more changes to the infrastructure rather than the customer, for Case 3 compared to Case 1. And the third impact on existing customers, again, there's hardly no impact on the existing customers and, as you can see, for Case 3, there is hardly no impact, because it gives a lot of flexibility. But - this is the area that was - people expressed there would be a substantial impact. This is the cost. Over 50% of the people replied that they would have to, you know, have additional cost, additional cost to deal with this policy change. And although, if you look at each of the three cases, Case 3 would have the least impact out of the three, the impact is still over 50%. And so we looked further into it and so, what would be - what would specifically be the actual cost that will be incurred as a result of this policy change. And the majority of the people replied that it's between - it's about less than 1 million yen - sorry, the majority of the people replied that it would be less than 500,000 yen or 0.3 man months but there were also about three LIRs, maybe less than 10% of the LIRs, replied that they have to pay more than 1 million Japanese yen to deal with this policy change. Which is a very large amount. And we also received some comments regarding this policy change, which, instead of just, you know, ticking the questions. And first is that there were generally very negative feelings towards removing fixed boundaries. So, for Case 3, quite a lot of LIRs - not in numbers, but people expressed strong concerns over this, not necessarily because of the direct cost that might be incurred from there, but it would increase their fixed cost for their hostmaster work or network because it would increase the complexity of their network. And some people also felt that there seems to be quite a few policy changes before, you know, the IPv6 is actually taking place. So it might give some impressions to users or people in the company that, you know, IPv6 is still a stable technology and it might have some impact on the deployment. Another thing is that I think some people genuinely didn't understand - why we still need to change this policy instead of the HD-ratio change, which reached consensus in the last meeting. And I understand that this is just a projection and not a prediction, but, you know, people felt that if it would extend the life of IPv6 up to 600 years, why do we have to go through further changes of changing the assignment size as well. That was a question. And I also briefly introduced the situation in the ARIN community, that there seems to have quite a substantial support for removing the fixed boundaries, and questions were asked over why there is a difference in opinion in JP and ARIN and whether the rest of the community outside Japan is aware of this kind of impact and situation in Japan and discussing these kinds of changes. And, if not, they wanted us to share this situation with the rest of the community. And then the third point is pretty much - maybe it's a lot to do with, like, the nature of our nation, that we really like to, you know, look into the details, but people felt that the details of the actual implementation was not so clear - how it would affect the additional allocation or how they should judge, you know, which size to assign. So some people felt that they can't judge, you know, if they support this proposal or not because the details are not clear. So, the overall observation on the result of the proposal is that, generally, there are no major notable impact in most of the areas - i.e. services, network and to their customers - but there are substantial impact on the cost to deal with this change and not just in terms of the numbers but two of the LIRs in Japan actually have to go through over US$85,000 to deal with this change, so it really is not small. And also, in terms of the survey results, if we just look at the numbers, it seems that Case 3 demonstrates the least impact but, in the comments section, people did, you know, express quite a strong concern. So our feeling is that, if we are going to implement this policy at all in the future, Case 2 would probably be most agreeable but we still have to consider the impact it would have on the cost. So the general feeling in Japan over this, you know, proposal is that, they're not necessarily against, you know, the changes, if they can be convinced that it would be for the good of the Internet. But the practical, actual impact is very real to them and how it would help the Internet in general seems really conceptual to them at the moment. So that's why they're not really convinced of the needs for this kind of policy change. But, at the same time, if they can be more convinced that, you know, this would be for the good of the Internet, I don't think they would strongly be opposed to this policy change. And, well, they feel that HD-ratio change, which was passed in the last meeting, you know, that could be acceptable and, OK, maybe we can go through this change, but why do we really have to go further and make changes in the assignment size when there are these kind of impacts. These were the questions that were raised. And since it did not reach consensus at the last APNIC meeting, we did not take a consensus vote, so it's more my impression of opinion rather than a full representation of the consensus in Japan. So the issues to be considered would be to what extent should we consider this kind of impact to the ISPs for changing the policy? And the second point is that JPNIC also understands that the intention of the policy and we have to look in the long term for the good of the Internet, so what would be a good balance between this long-term impact and the short-term impact that it might have on the ISPs? And that's all from me. Thank you. TOSHIYUKI HOSAKA: Thank you. Thank you, Izumi. Any comments or questions? I'm sure you have, Geoff. GEOFF HUSTON: Geoff Huston, APNIC. As one of the folk who authored, I think, that proposal at the start, I'd like to thank you, first, for conducting the survey and the answer is, indeed, very interesting and useful. I think your final comments were actually precisely the point of the problem. What's the balance between the long-term view and the short-term issues? And the underlying thinking behind this particular proposal was actually concerned with how long should the industry view IPv6 as a sustainable solution and, in that time frame, how many things get made out of silicone that want to communicate? The other assumption inside v6 that actually wasn't stated upfront in that policy proposal, but nevertheless is a fundamental piece of IPv6 assumption - there are no NATs. So every device, every thing, every RFID, every thing, gets an address. And when the original IPv6 addressing architecture was set up - and there were a number of iterations of it - the feeling inside the community at the time was, "Well, we'll do this for the first one eighth of the address space and, if we're wrong, we'll just change it later." I think what we're finding as an industry is that that attitude doesn't work. And that we're finding, particularly with IPv4, that the early recipients of address space are certainly being examined in terms of one university, an entire /8, you know, what happened there and why should that persist? And we're finding that undoing those early decisions and changing things on the fly is remarkably hard. IZUMI OKUTANI: Yeah. GEOFF HUSTON: So part of the intention of the proposal was, indeed, to err towards the long-side view and, if there was any kind of, "Well, you know, the HD-ratio might not be enough," what do you do then and how easy would it be to change? The comment that I made at the time and I would make again is once you get to deploying 50 billion - 100 billion - devices on a network and you get entrenched operations that are commodity-based - it's no longer high expertise, high touch - can you change anything? Have you then started on a track that you cannot deviate from due to its sheer size and inertia? So the question about the balance between long and short is just spot on. And it's a tough question to answer in any industry and we're now being faced with it here. I had certainly erred on the view of long term. I have enormous hope in v6 that it encompasses an amazing world, much, much bigger than any of us could possibly imagine and, in that case, you need more addresses than the existing policy will give you. So, yes, it's a good question. I'd like to highlight that in this discussion. IZUMI OKUTANI: Thank you very much for the explanation. I think pretty much everyone in JPNIC understands your idea and concept. So we probably have to go a little bit more into, you know, explaining the situation to our community. At the same time, at this stage, the whole thing seems a bit conceptual to them. That's the current stage. We probably have to still, you know, coordinate between our community and the AP as well. Thank you, Geoff. RANDY BUSH: Randy Bush, IIJ. Sorry to continue the Geoff and Randy show. What we have here, interestingly, Geoff, is a very example of an installed base that's having difficulty changing. Even at this stage. How much it will cost to change from the way we're doing it now to Case 1, Case 2, Case 3, right? Is the core of, you know - how much will the cost be? How much effort? We already have the problem of the installed base trying to change. So maybe they could think that this is, you know that this is a problem we have at the baby step today and, if we don't make the changes now that we know how to make well, that the problem is going to be 1,000 times larger three years from now. The whole problem is when do we make the change and changes that we know or that we are fairly confident are wise changes for the long term should be made as early as possible because of that greatly increasing cost. IZUMI OKUTANI: Yeah. I think that's a really good point but, at the same time, I think maybe feel that, if this was proposed at the time of when the policy was first developed, that it would have been OK. But what are we going to do about those two companies that, you know, are facing these kind of costs? Are we going to say, "You're just, like, two in the whole world so just forget it." RANDY BUSH: Will it get better for them? I shouldn't even use the third person. I believe I can say 'we' in this case. Will it get better when we have to make the bigger change three years out? Those of us that lived through the CIDR change where we paid late, where we paid this very change late, it was 100 times more difficult and expensive than if we'd done it 10 years earlier. So those two companies that have a significant cost today, if we are confident that the design change will eventually have to be made for a better Internet, you know, they are trading - whatever it is - 1,000 yen for 1 million yen tomorrow. And that's an American planning point of view, not a Japanese planning point of view. IZUMI OKUTANI: OK. Thank you, Randy. TOSHIYUKI HOSAKA: Thank you. Any other comments or questions? No? GEOFF HUSTON: Geoff Huston. I'm actually now just a little bit confused about next steps and I actually would like to understand, at least from this Policy SIG's point of view, what the next step is. Right now, the proposal relating to end-site allocations is not a proposal any more. It's gone away. It's not active. There is a proposal inside the RIPE community, as you pointed out, the variable-size one, with a better degree of detail as to how allocations are assessed. But there's nothing in APNIC. I'm quite happy to work with the ad hoc committee that I've been working with before as part of the IAB to resubmit a proposal more like the RIPE NCC one for consideration. But I don't want to waste this room's time if it's simply nothing's changed and it won't go anywhere. So if there is some interest in reconsidering this matter, and you would like a policy proposal to focus your attention on what is possible here, I am more than happy, if you will, to take this advice and resubmit a proposal. But I would actually prefer some guidance from the SIG upfront as to whether you really want to continue to consider this issue. So do you want to see this proposal more along the lines of a RIPE NCC model, where it's purely variable, resubmitted into the APNIC process or not? It's not a case of whether you'd eventually approve it or not. It's do you want to keep on discussing this? RANDY BUSH: I'll help if you do it. GEOFF HUSTON: That was Randy Bush volunteering some help, which would be gratefully accepted. TOSHIYUKI HOSAKA: So, Geoff, yes, you can always submit your proposal at any time if you like to. I'm not sure whether there is a need from other members or participants in the SIG. So I'd like to know whether you have the interest to see the proposal coming again. GEOFF HUSTON: I would like to know the same answer. Yes. TOSHIYUKI HOSAKA: OK, OK. So I would like to see your hand if you have any interest to see the proposal to change the assignment size in IPv6 assignment sizes. If you have any interest, please raise your hand. (Pause) Thank you. GEOFF HUSTON: I'll obviously take the chair's guidance here, but given that show of hands, I don't believe you're going to see this policy proposal. TOSHIYUKI HOSAKA: I know that but I'd like to see how many of you are interested. Kosuke-san. KOSUKE ITO: Kosuke speaking. Many of us are really interested in this discussion but it's pretty much long-term issue to be clarified - how, even how this is proposed at this stage, I guess. It's been a little bit too short to say whether changing the assignment size is in favour or not. We never know how much impact there's going to be. So I guess, if you call the hands how many people are interested in this discussion, then many of them will raise their hands. But I don't know how many people are in favour to change the assignment size and I, myself, is hardly raising my hand, I guess. TOSHIYUKI HOSAKA: Thanks for your comment. RANDY BUSH: We have been here before. We will change the assignment size. Do you want to do it now, while it's cheap? Or do you want to do it later, while it's a thousand or a million times more expensive? GEOFF HUSTON: I'm sorry if I was unclear. I was indeed asking for interest, not approval. TOSHIYUKI HOSAKA: We know. GEOFF HUSTON: I thought I heard some confusion about what you're asking for. It's not whether you're in favour of doing the change at this point but it helps the discussion to have a proposal to talk about it. And the question really was from me - do you wish in this SIG to continue to consider this, in which case I'm happy to produce a policy proposal again that would help you discuss. But if there's no interest in even talking about it, then there's no point in producing a policy proposal at this point if you're not interested in discussing. So that's what I thought the show of hands was about and, if there was some confusion there, then I hope this has clarified it. Would you like to ask for another show of hands, simply for interest? TOSHIYUKI HOSAKA: OK, OK. Simply on interest, would you like to continue discussion on this matter. Please raise your hands. OK. Thank you. KENNY HUANG: Good enough? TOSHIYUKI HOSAKA: Yeah. Apparently we should continue this kind of discussion in the future. GEOFF HUSTON: In that case, with your approval, I will submit a policy proposal to that affect to assist discussion. TOSHIYUKI HOSAKA: Yes, please. AKINORI MAEMURA: Izumi-san is not the network operator and she just represents JPNIC in the community. So I'd like to have that kind of discussion from the Japanese community so I'm asking the Japanese community to participate in this discussion very much and then I think that will move the discussion forward for our community in Japan. TOSHIYUKI HOSAKA: Thank you, Maemura-san. Any other comments? OK, so thank you, Izumi. IZUMI OKUTANI: Thank you. APPLAUSE TOSHIYUKI HOSAKA: So the next speaker is Billy who's talking about an issue with critical infrastructure assignment size. BILLY CHEON: Hi. Nice to meet you. My name is Billy Cheon from KRNIC of NIDA. I'm not here to propose anything. I just convey the concerns and messages from Korean community over IPv6 allocation and Assignment Policy on critical infrastructure. I am just going to use APNIC policy. Sorry for my laziness. If you look at APNIC IPv6 allocation Assignment Policy, especially on the critical infrastructure, "The minimum assignment made is at least a /32." As other countries always does, we in Korea have a ccTLD site and we implemented IPv6 in April on our ccTLD site but we have another site for back-up region and then we, you know, possibly implement IPv6 on the other particular sites. But we already have /32 for our ccTLD sites but we, like I mentioned, we, in the future implementation of IPv6, we would like a /29 based on this policy to APNIC and then APNIC recommend /48 assignment on critical infrastructure. So I think, this statement is riddled with confusion. I don't know if it's since Korea, English is not the first word, so probably it's level of English. But from our understanding, we thought the minimum assignment made under this is /32 - that means, in one country, every ccTLD site can receive one /32 prefix. And, actually, they don't care about the prefix. They care about routing policy. As far as I know - I mean, I discussed it with them and they told me that there is no clear statement on the clear routing policy on routing table at this moment, like RFC or, you know, internationally agreed documentation on routing policy. It pretty much looks like it's dependent on LIR's allocation policy. So they are worried about the filtering of their prefix. So I just wanted to share opinion and the experience for - with our community and other regions. So, if anyone was in this kind of situation, would you tell me about this. RANDY BUSH: I run - not for IIJ, but myself - six ccTLD - two ccTLD servers. I see no reason for this. It does no good. You can look up the servers in the DNS. Why do they have to be in special address blocks? TERRY MANDERSON: Can I just clarify - was the issue about the actual size of the allocation or the fact that it's in a special address range? BILLY CHEON: It's actual size. TERRY MANDERSON: OK. Thank you. And, furthermore, I want to clarify - are you actually saying that you are having difficulties because of the said de-aggregation rule for IPv6 so you have a /32 and reluctance to de-aggregate. Is that correct? BILLY CHEON: Yeah. That's correct. Actually, they are worried about the future aggregation, yeah. TERRY MANDERSON: Maybe we should point back to the work from Izumi and Geoff and, in future, Randy, about variable-length allocations, perhaps. Thank you. TOSHIYUKI HOSAKA: Billy, I just want to clarify. Is there any case in your country that your ccTLD have to receive multiple /32s? BILLY CHEON: Like I said, at the moment, they don't have - I mean, there is one ccTLD which receives the /32 already and another site is, you know, is planning to implement IPv6 on their site. And then, you know, there is several - TOSHIYUKI HOSAKA: Separate networks? BILLY CHEON: No, several sites waiting for IPv6 implementation. So, for the future implementation of IPv6, we, you know, thought probably we need the same size of IP address /32. The reason is that aggregation - I mean, filtering is the main reason. SANJAYA: Sanjaya from APNIC. This is more of a question to the routing community. Because if I recall correctly, looking at the routing table in IPv6, the last time I checked, there are even some /64s being advertised. So there's quite a few /48s. My question is to the IPv6 operators - have you started filtering size? TERRY MANDERSON: Terry again. Sorry to answer my boss's question. But, yes, operators have started filtering size. I've noticed in experiments that I've done about de-aggregation and announcing /35s and smaller from our /32 allocation, that, in fact, they do not get full visibility due to filtering policies of other operators. SANJAYA: So that sort of validates Billy's concerns, then. BILLY CHEON: Oh, OK. Thanks. PHILIP SMITH: Philip Smith, Cisco. I run Cisco's present IPv6 Internet as it is and, basically, there are two filtering policies that ISPs seem to follow. Both are based on either relaxed filters or strict filters. Some ISPs implement strict filters, basically those on the minimum allocations, /32. Others don't. They operate as /48s. I operate the latter because no-one has as yet explained how IPv6 filtering will work with /32 as the limit. I don't really understand the concern in Korea. Yes, I announced the Cisco /32 aggregate. Yes, there are /48s with that being announced as well and there's no real reachability issue. SEUNGHOON LEE: I know that these related issues. You know I read RFC 2772. This is about the 6Bone routing guidelines. They say that BGP administrators filtering issues, they could advertise BGP prefix. They couldn't advertise BGP prefix, longer prefix than the RIR - no, RIR's delegated assigned prefix. They do not advertise longer prefix than RIR assigned - BILLY CHEON: So it's pretty much dependent on RIR allocation. PHILIP SMITH: RFC 2772 covers 6Bone. We're talking about the real IPv6 Internet. 6Bone disappears on the 6th of June this year. BILLY CHEON: Yes. Philip, is there any, like, standards for the - I mean, de-aggregation on clear statement on the filtering, like RFC or documentation. Was there any in native environment? PHILIP SMITH: Not that I know of. I mean, it boils down same as people do for IPv4. What you should be doing is announcing your aggregate that you receive from the registry and do the necessary subdivision to get whatever traffic engineering you need to achieve. That's what I would say. I don't think that's written down as a rule anywhere that I'm aware of. BILLY CHEON: OK. SEUNGHOON LEE: Actually, I know that there is no concrete routing schemes. So I refer to the 6Bone routing guidelines, you know. TOSHIYUKI HOSAKA: We have Jordi here to make a presentation regarding your topic. JORDI PALET: I guess this webpage could be interesting for this topic. It's webpage where I believe most of the ISPs which are implementing IPv6 are looking for recommendations for prefixes. So, for filtering prefixes. So you have here even examples for different routers and you have a list of all the prefixes that should be filtered, even if you want to go for the thing that Philip mentioned. I think it's well maintained and I really recommend, at least my customers, to follow these rules because, really, really are very nice in the sense that following up what is going on in all the prefixes allocated to the LIRs and also the ISPs. So I guess it could be interesting. Everybody can take a look on that. So that's it. BILLY CHEON: OK, I'd like to thank you for your opinions and suggestions. I will go back to my community and share this knowledge and, if there's still concerns or needs for this, you know, issues, I will be back at next APNIC meeting. Thank you. TOSHIYUKI HOSAKA: Thank you, Billy. So we could cover all the preparations in this SIG session. And we have more time to end this session. So I will pass this mic to Kenny. KENNY HUANG: OK, thank you. Because we still have time before the lunch, and I would like to take the opportunity to elaborate some of the topics we discussed in the previous session. OK, let's look at the open action items. Proposal 20-001 - application of HD-ratio to IPv4. In the previous session, I already conclude - think that we don't have proposal, we don't have any suggestion to tell the community what we should do and what we should do for the next step so I recommend we take it back to the mailing list for one month and we see what happens and, after one month, we make a decision. And I'd like to elaborate more regarding to your opinion regarding the open action item. Because, once it goes to the mailing list, very few traffic comes in and hardly get input from the community. So if you have any opinion or comment or question regarding to the open action, I would like to have your input and also share your input with the community. Regarding to the second proposal in the other RIRs. The last call already proceed in the RIPE region and in the LACNIC and ARIN, the proposal is abandoned. So before we take it back to the mailing list, please let us share your opinion and your comment. So, last call - any comment or opinions or suggestion regarding to the open action? ANNE LORD: Kenny, I've just got a question - what is the decision that you're going to make at the end of the one month? Are you going to suggest to abandon the proposal or continue discussing? KENNY HUANG: It really depends on the discussion on the mailing list. If there's no discussion in the mailing list, probably I would discuss with the two co-chairs. We can either abandon the proposal. Yeah. ANNE LORD: Because there was a sense from this morning's earlier discussion, at least articulated by Geoff, that we should they very carefully and cautiously about continuing with this in the light of the research that's been done about conservation and the impact of conservation. So there has been some feedback, at least to that extent. KENNY HUANG: OK. Right. Thank you. Any other comments? (None) OK, if no other comment, I'll still take if back in the mailing list and also thank you, Anne, for sharing information. At least it is some feedback. And so we will discuss the open action item during the mailing list and also I will discuss with the co-chairs for the Policy SIG to see how we're going to proceed in the next step regarding the open action item. So if there is no other comment or question, I'd like to conclude the meeting is adjourned and lunch will be served outside in the Level 2 foyer. OK. Thank you for your participation. I'll see you next time. Thank you. APPLAUSE