______________________________________________________________________ DRAFT TRANSCRIPT Policy SIG session 2 Thursday 2 September 2004 9.00am ______________________________________________________________________ TAKASHI ARANO: Good morning, everyone. Did you enjoy your social last night? Today's session is a full agenda so we will hurry up. I would like to make a small announcement. I thank the meeting hosts for their hosting and the sponsor for this session. First, Paul will introduce the summary briefly. PAUL WILSON: Just to summarise the policy proposal from yesterday. The IANA 2 RIR IPv6 proposal, the framework and specifics are here, but there is a presentation from IANA to the RIRs. As Doug Barton said yesterday we consider this to be the allocation unit - the proposal is for /12, as well justified by the research that Geoff Huston had done. Subsequent allocations to RIRs are in multiples of that minimum, one or more, with the intention that an allocation will provide the RIR with a certain number of months of utilisation and the suggested proposed number of months is 36 - three years. The RIR qualifies for that subsequent allocation when a certain percentage of the address base that they hold has been utilised, allocated or reserved and it's proposed that it's 50 per cent of that qualification for subsequent allocation is when 50 per cent is utilised. The IANA will, to be explicit, process requests according to procedures which are agreed with the NRO. That's really implicit in that the implementation of the policy is according to procedures that still need to be developed and in the case of IPv4, for instance, we have developed those procedures by way of request forms and response time lines and so forth. But that is just to be absolutely clear about how that works. We're still asking that the communication from IANA be to the RIRs and that we work out, certainly as Doug suggested, the parameters of that communication as a procedural matter. So those are the basics of this policy proposal. It's really quite a straightforward, simple system. Perhaps if there are any questions about it, I'd be very happy to clarify. So could I ask if there are any questions or comments. Please feel free. TAKASHI ARANO: Since this is a global policy - after we have some consensus about these things, other regions will have a similar or same consensus about it. So if you agree with the general proposal - with some flexibility - I mean flexibility with the number, the parameter. This suggestion says /20, but if some other region will agree on /16, for example, if we agree to consensus with some flexibility, that means that /16 should be OK. I wanted to see that we agree on the general proposal. Do you understand what I am saying? I would like to take the vote. I would ask you to raise your hand yes or no. How many of you agree with the general framework or general proposal with some flexibility? DOUG BARTON: I was under the understanding we were going to have a comment period for the separate elements. I apologise for the interruption. My understanding from yesterday was that we were going to have a comment period on the individual elements of the policy today. Is that still going to happen? Or would you like it to happen before the consensus? TAKASHI ARANO: If we get some consensus on the general things, I will not take a vote for each. DOUG BARTON: In that case I would like to add a brief comment in regard to the issue. In discussion last night with some of the fine folks here, one of the things that came up as a possible element of flexibility, as you suggested, was that we could potentially separate the issues of the size of the initial allocation and the size of the subsequent allocation unit, that perhaps a large initial allocation is justified by the research that Geoff and some others have done, but perhaps we would have more flexibility going down the road if the subsequent allocation unit were actually smaller. I don't want to propose numbers here, because I don't think that's my role, but the point is simply that I would like to introduce the concept of having the initial allocation and the subsequent allocation as a potential area of flexibility. RAY PLZAK: Don't run off - what's the rationale behind that? DOUG BARTON: The concern is the initial deployment of v6 might follow a different pattern than the research on v4 suggested. The v4 uptake pattern was very slow and more or less a gradual increase - recently we've seen a fairly steep increase. The opinion of some people I talk to about this is the v6 uptake pattern will be significantly different and there'll be a very large initial set of requests and then it's going to taper off a bit and then perhaps drop as people have received the allocations and reservations they need for future growth. The suggestion I'm making is you have a maximum amount of flexibility for adjusting the parameters of how we operate under this policy down the road if the initial allocation were large enough to take into consideration the rapid uptake of v6 but that the subsequent allocation unit was smaller, so that if we needed to have a smaller allocation unit we could. As you pointed out yesterday, under the existing v4 framework, if the RIR has multiples of the unit routinely, I expect the same framework would happen and the same operational rationale would happen as with v4. RAY PLZAK: The size of the allocation will vary as it goes from region to region. As Jordi pointed out in his presentation yesterday morning, the growth pattern will be different in various regions as they do IPv6 and then it will probably be the slowest in those regions where IPv4 has the largest distribution because of business cases and so forth. So it would be more commonsense to keep it uniform across the board instead of trying to figure out where the growth is going to be, because what may be good for a subsequent allocation in one region to receive from IANA is not necessarily going to be good in the other regions. Therefore they should be the same. The ability of individual RIRs to manage their address space is not in question. If it takes longer to use up a /12 and get another one and it takes longer or it takes less time to use up that one and they have to come and get one sooner, so what. The job here is to effectively manage the address space. By having a consistently sized minimum allocation - and the term operative here is minimum - we don't second guess growth. We pick what seems to be an optimum piece of space that can be managed by the RIR or RIRs collectively and as they fulfil the needs of their community they will add some more space. The RIRs do not have a similar policy with their ISPs. We don't have a policy by which you get an initial allocation of a /20 of v4 space and when you come back you have a different allocation unit for a subsequent allocation. We're supposed to be paid money to manage this resource. I don't see how by fiddling with multiple values of allocation sizes that anything is gained by it. DOUG BARTON: I think the RIRs do an excellent job. In no way am I impugning that. I would just like to quickly say that to my mind the fact that the different regions will have different needs for subsequent allocations is a point in favour of a smaller subsequent allocation unit. But I'm open to input from the community about that and happy to listen to others. TONY HAIN: The initial allocation may be a multiple of /14. Why are we stuck on the middle boundary was a question I had yesterday. We don't do that in IPv4. Why are we sticking ourselves with another boundary in v6 other than it makes it a little easier for people. RAY PLZAK: I'm stuck on making sure we have one allocation size we're talking about. It's a minimum, whether initial or subsequent. Initial will occur once for each RIR. If this policy is enacted before AfriNIC does it ... TONY HAIN: If there's an initial size that's different from the subsequent size the initial size is really a multiple of a smaller subsequent size. The allocation unit is a 14 - you start out with everybody getting at least two - just because everybody is going to need at least two to get started. RAY PLZAK: I don't have an argument with that. Pick the size you want and it's one size and that's it. You don't have one that's initial and one that's subsequent. It's one size. Then you need in multiples of that as necessary. JORDI PALET: I'm not sure whether I understand if Doug is proposing different subsequent allocations for different regions or flexibility to choose it later? DOUG BARTON: Thank you, Jordi, for the question. I'm not proposing different regions have different allocation units. I apologise if I didn't speak clearly about that. Specifically what I am proposing is - let's take a ridiculous number so that I'm not going to influence the decisions here. Let's say the initial allocation unit is a /100. Each RIR after we initiate the policy gets a /100. If there were subsequent allocations, my suggestion is that the subsequent allocation size could be a /200 or a /400 or a /457, if that's the appropriate size. My point is simply that if the subsequent allocation unit were smaller than the initial allocation, it would give us more flexibility to administer the space going down the road and not prevent the needs of the RIRs being met if they need larger allocations down the road. If we go through this at least one-year process adopting a global allocation policy - realistically I think that's what it's going to take - and then realise we've made a mistake with a subsequent allocation unit, it will take at least a year, possibly longer, to have it changed. If the subsequent allocation unit is small, then we can allocate multiples of that to the RIRs as our operational experience and needs require without having to go through a whole other policy process to undo a mistake we make at this point in the process. GEOFF HUSTON: The problem with that kind of approach is the one thing that never forgets is routing. Realistically, if IPv4 is any kind of benchstick here, the period of time over which you accumulate experience is not units of years, it's units of five years or longer. By the time we figured out that transfer addressing didn't work it was a long time after we started doing address distribution. What I think the issue is here, in looking at responsible management, you're actually looking at what are the outcomes. The outcomes are expressed in two areas: folk who need addresses can get them, but the routing table still works. The issue is the routing table never forgets. Once I've got a smaller allocation I fragment, I've fragmented and that's the end of it. By taking an approach that says I'm going to use what we've accumulated previously and saying that kind of size block maximises the potential for very strong aggregation. Because when we're talking about the routing table never forgetting, you're talking now over periods of decades. Trying to nibble away at this, we're saying that's an initial one, but the next one could be smaller and doing it too early after a year is going to leave a legacy of fragmentation that we've been living with with v4 and it's been uncomfortable. I'm trying to say responsible management is about what does it look like when I'm no longer around, but we're still dealing in BGP? What measures do we do today that make sure we haven't loaded a bomb in there that goes this is just fragmented beyond belief. That to my mind says what's being suggested here makes good conservative managerial sense in terms of the totality of what address space is all about, addresses being used in networks and routed. I would say saying it's 12 now and a 16 later with experience after a year is making a number of sweeping assumptions that didn't happen in v4. It took longer to understand the dynamics. We set up a legacy in v4 you wouldn't want to repeat. I would argue more towards what Ray is saying. Set up something you know will accommodate good aggregation in what we see now and keep it there for longer than a year. Work on that and understand after a while what may have been wrong with it or whether it was the right and conservative thing to do. RANDY BUSH: I think the lesson from v4, a different interpretation would be that coming up with enormous fixed size boundaries - A, B and C - and allocating on them is where it failed. What we changed to was allocation on bit boundaries according to need has actually judged by intelligent host masters. If we could do this automatically with these big blocks, we could write a program to do it and get rid of the mix - right? And I think a big block thing is trying to say we don't know anything, so we can make up these magic numbers and we're going to do these big blocks, and we're making another swamp - what we call a swamp - except we're making a massive swamp. I remember when we thought 32 bits was infinite. We now think 128 bits was infinite. I'm not sure if I'll live long enough to have to fix this mess. TONY HAIN: I agree with Randy in terms of it being the fixed size that was the problem. Going back to what I was saying yesterday in terms of recommendation to IANA that they do some sparse management where it's not fixed size but we go back and think about exactly what the units are. I would argue that the first two bullets are confusing the issue. In fact, what you're saying is there is an allocation unit size of some value and the initial request may be larger, but in any case you'll always get multiples of the allocation unit. The fact that the initial one might be larger is somewhat confusing the issue. You don't need to say that. You'll always get multiples of whatever the allocation unit is. The other thing Geoff was trying to get to and to some degree Randy was getting to in terms of the swamp is how you manage that space. If you allocate it sequentially you create the swamp. If you allocate it in a sparse mode where you have a feel for history and distribution of demand, then you can mitigate that and come up with an adequate fix in the routing. You go back to the why are we picking level boundaries question and are we confusing the issue by having initial units versus subsequent units, if we just get rid of that and say allocation units are X and you get multiples of X based on need. GEOFF HUSTON: The issue to my mind is it's allocation windows and the ability for an LIR or ISP to expand but not consume more routing slots, since that appears to be a resource under a fair amount of competitive pressure. It's not IANA to the RIRs where you can make that happen. It happens in the management down to LIRs and ISPs. At that point you're trying to preserve windows that allow expansion without fragmentation of the routing space. So, as I said, it's one level down in the management hierarchy where you actually are able to affect outcomes in routing and only at that level. SPEAKER: We ought to think about maximising aggregation instead of talking about allocation units to the end network. We're not there yet. We're talking about from IANA giving enough space that allows RIRs and NIRs to make a - you know, a sparse allocation as good as possible. And I think Geoff's presentation yesterday shows that I think the sweet spot - let's call it the sweet spot - for allowing to maximise aggregation would be a /12, so I'm all for that number actually. TAKASHI ARANO: Paul, would you like to amend the proposal? PAUL WILSON: I think without amending the proposal I've split the first bullet, as Tony suggested, into defining an allocation unit as one point of the policy, the initial allocation being one allocation unit as a separate point of the policy. TONY HAIN: Just to clarify I was arguing that allocations are done in multiples of the allocation unit. You don't have an initial versus a subsequent. Your initial demand may show you have a large number of multiple, where subsequent may not. But there really isn't any distinction. You'll always get multiples of the allocation unit, whatever your demand is that gets you through your window or whatever your demand is. PAUL WILSON: The thing that starts to worry me here about that is we may end up having an allocation unit of a /48 and ... TONY HAIN: Combining with the next bullet which is saying you get enough to carry you for however many months -- PAUL WILSON: If that's calculated on the basis of a unit such as a /48 we might find ourselves with allocations of 102,006, which is not a prefix, which is not able to be managed in a sensible manner from a sparse allocation point of view and creates all sorts of possible fragments of that allocation unit size. The point of this policy is definitely to maximise the allocation unit to the best reasonable single unit which is not subdivided, particularly not into non-powers of two or into other than single prefixes. TONY HAIN: I would suggest that maybe the right way to word the bullet is what you said, that allocations are done in minimum of the allocation unit, with the goal of avoiding fragmentation and to meet the needs of the X months, whatever that X months is. So if you restructured it into that kind of language so you're not dividing initial and subsequent, you end up not having the argument is it too big and then we have a different value for start-up versus down the road. You can take that whole argument away. It's one allocation unit - you get a multiple of that. The recommendation to IANA is to make sure it's big enough to meet the need of however many months without fragmentation. RAY PLZAK: I think we're getting a bit overconcerned about the initial allocation. There's only going to be five - one to each RIR. That's it unless another RIR gets created. Four of them are going to happen when the policy starts. The fifth when AfriNIC received final recognition. It may happen earlier and be administered by the other RIRs so they don't have to do renumbering. There's only going to be five. It's not like every two months or so there's going to be another RIR invented. There's only going to be five - that's it. It's defining how the policy starts is all it's doing. So the real issue is the /12 or whatever that number is for every time that they go back and ask for space. So the initial thing is merely - it's like when you set up anything. You have to have a starting point. A starting point definition is all it is. Unless someone decides that there's going to be 1,000 RIRs, then you'd have 1,000 initial allocations. You have an indeterminate number of initial allocations in terms of ISPs. RIRs hopefully don't have the same behaviour pattern when they come and go. TONY HAIN: I agree. We don't know the future. We don't want a policy that automatically grandfathers somebody in that's new because of politics. It makes no sense at that point in time because the language here dictates initial allocations. RAY PLZAK: As far as I'm concerned each of the existing RIRs would immediately be given one. The NRO, as the steward for AfriNIC - because they can't actively administer the space on their own yet, because they don't have formal recognition - would basically - we've done the same thing with v6 /23s. The RIRs are jointly managing one /23 for Africa. We're doing the same for the support base - /8. We did the same thing with LACNIC for v4 space. IANA wouldn't let us do that with v6 space. So it's just a practical matter. That's all it is. The real issue to be concerned about is the size that the RIRs come back and ask for. PAUL WILSON: I'm starting to feel self-conscious about the amount of time this proposal is taking up. In the interests of trying to facilitate the consensus here, I've changed the summary slide. I've briefly consulted with the chair who believes this is no very substantial change. If this is an acceptable rephrasing it's consistent with Tony's suggestion that all allocations are in multiples of the minimum allocation size - sorry, that should say the allocation unit. That is what we had said before in the general case. I would like to say here that should be a single sided block. That was at least one of the intentions of establishing the single minimum allocation unit that we don't start subdividing address space into small and unmanageable levels. So I would like to amend the proposal as such and leave it there if possible and hand over to the chair. TAKASHI ARANO: Now I would like to take a vote for the general one, with some flexibility. I especially point out we'll be discussing it in the mailing list. We will discuss whether that specific number will be in the common sense of flexibility. That will be discussed in the mailing list. Now I'd like to take a vote for the proposal as a whole. Do you understand? OK. How many of you agree with this general proposal? Raise your hand. PAUL WILSON: Please raise quite high - otherwise Miwa can't count. TAKASHI ARANO: How many of you disagree - raise your hand. TAKASHI ARANO: I think this is a rough consensus - 16 to 1. Thank you very much. TOSHIYUKI HOSAKA: I'd like to slightly change the order of the presentation due to the lack of enough time to present all the presentations. Firstly, we would like to have IPv6 policy status from Laura, and the next addresses from Geoff Huston, then after that we would like to have Ito San and Hashimoto San. Then policy implementation from APNIC. Lastly, we, if we have enough time to present, I would like to have... LAURA COBLEY: Good morning, everybody. Can you hear me? Good. My name's Laura Cobley from the RIPE NCC to give you an update on the IPv6 policy from the ARIN, LACNIC and RIPE Regions. It's gonna be a very quick update since we're short on time. Most of the discussions and proposals have been put forward in the regions have surrounded the initial application criteria, with the exception of the need to not be an end site, so these are the changes I'm going to go over quickly. In the ARIN region the policy proposal has been ratified and is currently awaiting implementation at this stage. It's expected to be adopted before the end of this year. The changes that have been made to the initial allocation criteria are that the requesters need to show a plan for making at least 200 /48 assignments within five years and that's instead of the previous two years. But this criteria is dropped in the case that the requester is a known existing ISP in the ARIN region. Changes have already been implemented and they're designed to encourage the use of IPv6 in the LACNIC region. Both LIRs and ISPs can apply for an allocation and the need for making the 200 /48 assignments has now been replaced with the need to show detailed plans of the IPv6 services and the IPv6 connectivity that the requester plans to offer to other organisations. They need to have globally reticked this block within one year and customers in the LACNIC region should have access to the IPv6 services within two years. In the RIPE region there have been no policy proposals put forward at this time. However, we have planned to clarify the text, we had planned to clarify the text to clear up any unclarities there. In the discussions that followed this plan it would appear that there is quite a lot of support for changing the policy, however the details of this haven't been discussed yet and we currently are awaiting further discussion on the topic. If you're interested to follow those discussions you can follow the address policy working group mailing list and if you're not subscribed the archives can be found at this URL. The presentation will be on the meeting site so you can double check the URL later. And that's it from me. If there are any questions, that's fine. (APPLAUSE) TOSHIYUKI HOSAKA: (Pause while presentation loads) TOSHIYUKI HOSAKA: I'm Toshiyuki Hosaka From JPNIC. I will present you with an IPv6 policy update on the APNIC community. We have a policy change in the APNIC region implemented on 16 August this year. Firstly, the use of existing IPv4 infrastructure and customer base when evaluating IPv6 requests is clarified. Secondly, allocations to private networks are explicitly allowed providing initial allocation criteria can be met. Thirdly, public registration of customer assignments is made optional by using a public attribute in the APNIC Whois database but will be hidden by default. These items are - what we reached a consensus in last APNIC meeting. In addition to the policy modification we had an IPv6 policy guideline document. This is developed to help requesters in the AP region, the purpose of this policy guideline document is to clarify the intention of the policy and also to provide practical information to the requester. The working group launched in November 2003, and the document was published in July 2004. It's done. Taking this opportunity I would like to thank you for the guideline working group members and APNIC secretariat who edited the draft document. Thank you. I would like to raise one question to the community regarding the next direction. As Laura presented all other regions, other than APNIC is now changing or has been - has changed the initial allocation criteria including 200 /48 assignments in two years. APNIC set guidelines regarding this initial allocation criteria, but so far we have no proposal nor discussion raised in mailing list. Also, we would like to have any opinion whether we have any other issues in IPv6 policy. So should stay as it is or start a discussion to change the initial allocation criteria? I would like to keep this question open to the community, so if you have any opinion on the IPv6 current policy, please let us know that so that we can start discussion to change or not change. Thank you. Any questions or comments? IZUMI: Personally, I think it's a good thing to clarify the policy document itself in addition to the guidelines, but as JPNIC we would like to first discuss this issue in our open policy meeting and what our community thinks and if our community thinks we need to change the policy itself then perhaps we will propose in the next APNIC meeting. TOSHIYUKI HOSAKA: Thank you. Any other comments? Thank you. (APPLAUSE) The next presentation is from Geoff Huston. GEOFF HUSTON: Good morning, Geoff Huston here. Again, this is a report on some IETF standards activity that has been going on. This particular area is a report on unique local addresses. Unique local addresses are intended to be private use addresses, but unlike site locals, which they roughly replace, they have a subtly different way of working. They're private in terms of uniqueness, in terms of their use but they're global in terms of their uniqueness. So unlike RFC 19 addresses where everyone uses net 10, network 172.16 and whatever the class C one was, and you all use the same address so it clashes, with unique local addresses the general concept is that everyone who uses an element of these addresses, a /48 actually chooses a different prefix. The objectives here is that a single pool of unique local addresses is subdivided into /48 instances, prefixes and each prefix is intended to be globally unique or, as we'll find out in a few slides, most likely, probably unique rather than assuredly unique. They're not intended to be part of the global routing domain so they are /48 fragments with no aggregation there. They're intended, though, that if I'm using one of these prefixes in my site and you're using one of them in your site we can privately cross-connect without the issues that happen when we're both using net 10 and v4, because they are different prefixes we can cross connect without having address clashes but they're not aggregatable, there's no hierarchical structure and no provider-based context going on here. It doesn't matter who your upstream is, these are not upstream-based addresses. In working through this, the IPv6 working group has come up with the concept of two address pools and they're subtly different again. A local self-assigned pool and a pool that sort of involves a kind of registration process they call centrally assigned. Why two? The first one which is a pool coming from DD00/8 says if I want to use one of these I don't tell anyone or talk to anyone. I just pick a prefix. There's no record of what I picked and they suggest an algorithm which is going to be relatively unique, hopefully, because you're picking across a large number of bits, so it's probably unique. The other way of doing this is to get assured uniqueness - to get that you go into common pool and a central registry function gives you a back prefix that no-one else has been given, records therefore need to be maintained and yes those prefixes are indeed uniquely assigned. Again, there's no provider hierarchy, no aggregation. The prefixes you get from the central registry are picked at random from the entire pool. What do these pools look like? This is a breakdown. 16 bits of a sub-net ID, and at the top FD00 and FC00, so the common prefixes FC00/7 and there's one bit to say whether it was locally or centrally assigned. What you need to do if you're going to use one of these if you're doing local local assignment is to pick a random 40 bit number. There is a draft out there - unique local addresses. It specifies the structure, the prefix and the random selection process. What it does is take the time of day when you run the roulette wheel, takes the base level interface identifier of the machine that's running the wheel and does an MD5# across that and truncates it to the lower 40 bits. They say that's relatively random. It probably is. The way it works is that certainly in the draft they mention the use of a /48 here allows you to do an overlay if you are using public addresses simultaneously, so that in my site I might have provider-based addresses and I might also want local addresses. The low order 80 bits would be the same if you want them to because the sub-net ID happens to work with the same 16-bit length if you're using fixed 16-bit length sub-net addresses. Which one should you prefer? If you read the draft they say if I can get there using the local address I should use that. So that in the address selection algorithm because now machines have two addresses, local should be preferred over global is my reading of that. It requires splitting DRS because there are machines that resolve into local addresses. There's a reverse issues about reversing local issues into names, that's a private resolution. The inference there is if you're doing reverse AAAA PDRs you have to do it as a non-authoritative server because you can't get delegation because these are not part of the global DPR delegation. When you say you're going to generate unique things they're not precisely unique. Indeed, across the entire world if everyone starts doing this, by about 2 million or so, two people would've picked the same number, but because they're local-use context it shouldn't matter, it's only if they leak into the routing system you have a problem. Part of this draft was centrally assigned. These come out of pool FC00/8. The working group is wanting an allocation registry that allows anyone to come to this registry and get a prefix, they want it to be a single transaction, no annual renewals, they want it permanent. They want the allocation to be permanent without renewal and without any deallocation, so it's once and forever. They want to provide a mechanism, they want the registry that stops someone sitting chewing through 40 bits, take a few hundred years, wouldn't it, 40 bits of request going, "Give me one, give me two, give me three" until they get to 2:40th so they want a mechanism that prevents that hoarding of space. The ownership, they are recommending should be private not published. And the numbers should be random. The open issues, certainly this is an interesting replay of site local. There are a number of questions I think you should be aware of and be asking yourself as you look at this. While they say they shouldn't be globally routed because these prefixes are in the centrally assigned case unique and in the - how do you stop them coming into the routing table? Declaration might not be enough. So, you may indeed see them in the routing table. The issue is - is it really a bad thing if they leak? I don't know. It's an open issue. If they do leak is this another way of getting a /48? And indeed is this a surrogate mechanism for distribution of IPv6 unicast prefixes. The corollary question is that good or bad? Don't know. You do, however, in this local address context start having machines with multiple addresses, I have multiple addresses, you have multiple addresses. I want to send you a packet. What address should I use to call me when I send you the packet? What's in the source field and what address should be in the destination field? How does that selection work when you're using multiaddressing. As I mentioned before you are working in a two-face DNS space now so the two-face DNS needs some rules about when it provides response that is include local addresses because if you were the public side and you want to know all the addresses from my machine, giving you local addresses doesn't make a lot of sense to you, so the answers going outwards should be a subset of the answers internally. Some question about address permanence. The last thing I'll leave you with - this probably should be looked at by the multi folk when they're looking at the differential identity and locater - is this pool of 128-bit tokens a good seeding place for identity space. If you're looking at identity you're trying to find a space to grab the identities from. This is actually not a bad space to consider as being a seeding space. I think that was it. Thank you very much. Any questions? SPEAKER: When do you forecast this will be available? GEOFF HUSTON: The unique local self-selection address is currently with the Internet Engineering Steering Group and currently being considered for publication. Once it is published, because it is self selection and because there's no global DNS then you could use it as soon as it's published with the hope that the IETF isn't going to change it again as it did with site local. SPEAKER: I heard there is still a remaining issue for how it is distributed, as much as it's unique possible. GEOFF HUSTON: You're talking about the other one? SPEAKER: OK. GEOFF HUSTON: This one locally assigned self selection is very close to complete. The issues that are trying to be resolved now are in the current draft they say " Use of these addresses in the global DNS is OK". And the current discussion is - did you really mean to say that? Maybe you should be saying precisely the opposite. That's the last piece of resolution for this. Once this comes out you can go and self select your 40-bit prefixes, use it in a local context and have a good time. This one is further backwards, there's much more to go, including a set of actions about setting up such an allocation registry. I have no idea, no advice to offer you as to how long that process might take, what the role and who might be an allocation registry and whether even these suggestions are going to survive the process of review. They may be changed along the way. PAUL WILSON: I had a question about the registration and particularly in the case of the permanent - these proposals for permanent one-off global centrally managed addresses with no recurring fees, periodic fees. What's the expectation with respect to registration, in order to ensure uniqueness the registry has to somehow identify the people who - which prefixes have been allocated but do they also record to whom they've been allocated and does - or assign, does a member of the public in fact have any ability to find out who to whom an address has been assigned? I'm asking because if there was any chance of the prefixes being routed then they become - in either case the locally assigned or globally assigned be, they become a spammer's and hacker's kind of haven and that's something that we've seen with historical addresses in IPv4. So I'm just wondering what consideration has been given to that set of issues. GEOFF HUSTON: You raise a really important question and in going back over v4 you can see a set of standards documents coming from a standards body that goes so far in describing the ultimate deployment environment in all its detail and then there are a whole bunch of additional documents, IANA and the RIRs, describing policy and practice of deployment. What this standards body document is doing is specifying some generic characteristics of what the outcome should look like from their perspective but I suspect that as this moves into an environment of deployment the allocation registry and its structure might well have to look at this and go - that's easy, that might correspond to problems if we did it precisely that way. There have been some discussions between the folk who are advancing this draft, the Internet engineering steering group, and others as to how viable are the mechanics that are being suggested, and perhaps it might be better for the standards body to describe the objectives of what they're trying to do and leave the mechanics further down the track to subsequent documents that reflect the practice of the allocation registry. I'm not sure that it would be the right thing for the standards body to be incredibly prescriptive about the allocation registry behaviour, I'm not sure that they're that omniscient about that kind of environment. So it's a good point. I think if you do have comments about that that say, be a little bit more generic, rather than be prescript if about this registry and let the folk who do have experience in deployment of addresses, registration and so on, add to this afterwards. TONY HAIN: The one thing that Geoff left out was there is a policy expectation that FC00/7 is explicitly blocked and the global. We all realise money talks, so some people might not do that but that's I think the question on the table that's outside the scope of standards, a policy issue and how do you deal with that in a policy level that comes more to this body. GEOFF HUSTON: I'm not even sure this body is the routing police, so the whole issue of - TONY HAIN: Clearly not. GEOFF HUSTON: - whether " Unique", and I mean truly unique prefixes leak into the routing space or not is a hard issue if you're trying to stop it. We can all advocate best practice but as you said, money does speak and if somebody came to a provider and said, "Here's money, please route," they may be quite successful. PAUL WILSON: If these prefixes are commonly filtered they'd have to pay more, pay to more than just their local provider to have the thing globally routed. You don't have to route through the global Internet to launch a spam assault or an attack via network address translation proxies and so on. A general practice doesn't solve that particular issue, does it? I'll point out just for information that the RIRs, the NRO did receive a request from the IETF for some feedback on some issues including the willingness of the RIRs to take on this function, and the response was a qualified yes to that, but highly qualified because there were quite a number of issues such as the registration issue which were raised in some detail in our response. That's quite some time ago. I haven't seen any further information on this. I'm not following it too closely, but relying on reports like this to see where the general discussion is up to. I did gather, incidentally, that this proposal is not continuing to gain acceptance. Is there some possibility of it being abandoned at some point? GEOFF HUSTON: There are two proposals. The original proposal was split in half. As I mention, the self selection local, local addresses are now well in the track of publication. I think it's likely that that will come out soon in terms of months or weeks rather than years. This document, which is the other half of the original single, is, I believe, back in the IETF's IPv6 working group agenda. I'm not sure the IESG are moving this one along at all. So that this might take quite some time to come out. RANDY BUSH: Geoff, I'm easily confused and this is fairly complex. I thought we already had a centrally allocated unique address facility and v6 has so much after space and why are we doing this, what problem are we solving? GEOFF HUSTON: I did try and bring up some issues from my perspective. I should note I am neither the author of these drafts nor a strong advocate of them personally. I am just trying to report here on related activity. I think your question is certainly an interesting and relevant one. But that entire conversation is sitting at this point in the IPv6 working group. So yes, it has been raised and I think it's a continuing point to be raised - RANDY BUSH: But if they're asking for our opinion. GEOFF HUSTON: No, I'm simply reporting rather than conveying any messages back. RANDY BUSH: I thought I just heard two paragraphs ago asking whether the RIRs, i.e. the community, supports the RIRs doing this. GEOFF HUSTON: I think Paul might well be able to respond but from my memory and recollection of this the IESG passed a note to the NRO asking for their comment on this rather than whether they expressly approved, disapproved or agreed. It was a comment on this. PAUL WILSON: It seemed to me to be premature to bring it to the community as a proposal to do it because we don't have certainty yet whether it's even going to happen or it's possible. So it was for information and exactly in the spirit you mention that I mentioned just now there had been an approach made as to preparedness and there was an in principle yes - sorry a qualified yes, one of the other qualifications was to do with the acceptability of the final proposal to the communities. RANDY BUSH: We always call ourselves bottom up. So I'm just trying to speak from the bottom. (Laughter) GEOFF HUSTON: Thank you. Any other questions. Thank you. TOSHIYUKI HOSAKA: Thank you, Geoff. (APPLAUSE) TOSHIYUKI HOSAKA: Next presentation is from Ito San and Hashimoto San, please. GAKU HASHIMOTO: I am from IPv6 promotion council, this is Ito. Today we will report about our last - large space IPv trial usage program for future IPv6 deployment. We will not explain program details this time. Our topics are these. We will talk about updates since the last meeting. Our consideration and about future planning. We conducted the 5th regular hearing session last month. Five participants are active, as you see. Unfortunately, one participant has terminated their service. Now we are going to correct that allocated address space as soon as possible. Results of the hearing is summarised here. First, many of them are very positive and aggressive toward providing IPv6-based services. Especially, IPv6 is quite favour for IP-phone/VoIP services. But the one provider only providing connectivity service expressed the difficulty to find out the business benefit out of IPv6. Second, all of them said that it is hard to eliminate IPv4, even accomplishing IPv6 service. Most of applications still rely on IPv4 environment at this moment. And most of the users still need IPv4. Many devices are not matured yet for commercial service level. For example, for IPv4 service provider they need IPv4 in order to make IPv6 over IPv4 connection till layer two carriers offer IPv6 transit service. Individual cases and other topics from Kosuke San. KOSUKE ITO: I will talk about individual cases. This large scale A DSL/VoIP service. They would like to provide a service without any awareness by users whether they're using v4 or v6. They were trying to switch the end devices or edge routers at home for v6 enabled things for future updates. In the meantime, they need v4 tunneling, for devices enabled by IPv6, however in between they need the v4 tunneling. So they need v4 infrastructure anyway for the time being when they can provide the pure v6 end-to-end. So they expressed it is still hard to eliminate v4 for their needs to be - sufficient for be - to be for tunneling infrastructure. For the FTTH service provider, broadband things. Their activities, observation of the service is quite interesting. The traffic size is pretty much increasing still, then upstream way is more typical increasing. Especially, against same FTTH post-way will be the same stream - speed. Then both ends of the users are using the same bandwidth the traffic upstream and downstream. It's kinds of a balance one to one. However, for those just connectivity service providing is pretty much... of the business model. No return out of the v6 enable. So that's a hard part for them going for the v6. They are thinking of how the additional application layer level of the service in addition to the v6. This is the IP-phone service provider. They are still going toward to investigating the infrastructure systems which can be enabled v6. They started off investigation and also the testing of the prototype of the IPv6, enabling the devices. They are developing v6-based SIP server and user-side devices and verifying IPv6-phone. In the meantime they can provide the v6 end-to-end, they also providing transition mechanism of the v4 tunneling things. They also expressed that it's pretty hard to eliminate the v4 at certain times, which we assess that returning of the v4 address space which we allocated by the end of the 2005, it will be pretty hard to accomplish that kind of deadline. For the contents delivery network service, they are still seeking the v6 enabled system. So until they can obtain that kind of availability in the market they could not transfer to the v6. So that's only availability in the commercial side. They start approaching the vendors to cache-servers. For the wireless-LAN access service. They are still active in increasing the user side of the numbers. They are pretty much positive for the v6 address space. They try to make themselves enable the v6 by the LIN 6 plus MISP. They are trying to support the 6to4 mechanism. They also express it's pretty hard to eliminate the v4. The system availability a bit slower than expected. This service is available when we are going to the next meeting in Kyoto, they are providing wireless system citywide so if you are going to the next meeting you can experience this. Other things - we are trying to make themselves easier to step into the v6 address management - assignment management side. So we developed one web based tools for others assignment management tools for their easiness. This is for LIRs, and also we are intending for the newcomers like in the past the vendor service and they're trying to start it off the network service based on their devices, that kind of stuff. So we are providing this to core, cost-free so it will be available soon. Tools - a web-based service so you can adapt this code easily. Functions: Assignment management. We are implementing kind of a mail-based reporting part to the APNIC so that we are combining into reporting for mat to APNIC. Whois setting is still not implemented yet but we are going to. Sub-allocation management and also delegation setting for the reverse DNS. So maybe we can demonstrate next time at APNIC meeting for these tools. When we are conducting these trials, considering is as follows - At the very beginning we started off this project we believed that we can eliminate IPv4 space when all services can enable based on v6. Then our estimation is by the end of 2005. However, in fact, our estimation is a bit aggressive and one to two-year delay is about required from our original estimation. Because there is no DNS service supported so far, it's just beginning. And still RFC is ongoing activity, so the device size needs to adapt new implementation. Also, it's pretty hard to convince the v6 to the users in certain areas. However, we didn't have any report that participants expressed that the allocation policy itself is not - so we believe the policy is quite OK for allocation if they necessary. Most services are going the dual way, which is not considered at the beginning of this trial. So they need a v4 and v6 so they just - they couldn't eliminate the v4. So it's an additional premium service. We heard from the participants that v4 addresses are necessary for deploying IPv6, so they need to expand their service area by v4 then they put on to the v6 network, that's the way they need to deploy the v6 when they started off the v4-based services. It is necessary to reconsider our project toward 2005 and we are sort of start thinking of how we are ending up this program or how we extend this program. This is the final slide. We are starting to think of our future planning. We try to keep the promise when we said at the end of the 2005, so, first of all, we would like to make sort of a summarising report to clarify what we accomplished and what we couldn't accomplish within these trials. Also making a plan of how to proceed after the end of 2005 because we found out we couldn't eliminate the whole IPv4 space from the participants. So we need to keep the current IPv4 use space in some way after 2005. On the other hand we are collecting IPv4 if the participant is not able to start IPv4-based service during the trial period. So we are trying to convince them to - they are shifting towards the IPv6-based service when they keep the IPv4. So we are going to propose in the next meeting our future plan in details more clearly. We are just starting the consideration of those kinds of planning. So that will be our plan. Thank you. Thank you very much. Any questions this trial? PAUL WILSON: Hi, I think this is a very interesting report. Thanks very much for the detail of the commitment that you've shown through this whole sequence of reports. This has always been, in every one of your reports, described as a trial. You refer to a promise to have completed or completed this transition by 2005. If it was a promise which you had to keep it wouldn't have been a trial. I would've seen it as the aim of the trial to do that. I know you've been working very hard to accomplish that aim of the trial but it wouldn't be a trial if there wasn't a possibility for a different result, so I think an extension of a couple of years is obviously a good outcome. It will keep up the pressure and the pace and it will be very interesting to see how much changes in the next two years in terms of the support that's needed for these ISPs to actually carry out the deployment which is being planned. I'd just like to say thanks and congratulations for the work. KOSUKE ITO: Appreciate that. Thank you. Any other comments? Or requests to us? TOSHIYUKI HOSAKA: Thank you very much. (APPLAUSE) We are intruding into the coffee break time but we will like to have still two more presentations. Next presentation is from Anne Lord of APNIC. A small announcement here - video cards of yesterday's policy SIG are already available on the APNIC18 web site. Thank you. ANNE LORD: Good morning, everybody. I'll try to keep this brief. This is just an update on the status of policy development - policy implementation of the APNIC secretariat. For people that are new to this meeting you may not be familiar with the SIG reference pages. You can find those under the documents index where you'll find a policy development sub-index. That will take you through to pages where the policy proposal numbers are listed with the title of the proposal. You can also click on archived SIG reference pages where all the completed policies and implemented policies are listed as well as those that have been obsoleted. If you click on any of the policy numbers you will go through to a page which gives you a complete archive trail of all of the related documentation to that proposal, so you can see where it was announced first, the presentations, the meeting minutes and so forth. That's just an introduction for people that are not familiar with those pages. Since the last meeting we've implemented three policies. One of those implemented in May was the policy proposal 15, which was the IPv6 allocations to unconnected networks, allocations will continue to be made to unconnected networks providing that other criteria initial allocation are met. Implemented in August were two policies, proposal 14 reducing the minimum allocation to size to a /21 and changing the initial allocation criteria to be you have used or plan to use a /23 immediately and you can demonstrate the need for a /22 in one year's timeframe and you agree to number from previously deployed space. Proposal 16 was the - yesterday many of you heard the proposal that was to allow that for other than additional - of the new requests proposal 16. That uses an algorithm, it counts any assignments in the databases as /48s. In the third quarter this year, end of September we will be implementing two policy proposals - 7, the privacy of customer assignment records. That means by default customer assignment and suballocation records will be hidden, and APNIC member will need to actively publish records. within MyAPNIC Will have a tool to make that public transformation from the private database to the public database very quick and easy. Sanjaya in the next SIG is going to give an update on the exact status of that policy proposal. So come along to that if you're interested. Proposal 4 - the lame delegation cleanup. That authorises the APNIC secretariat to test for and disable lame DNS reverse delegations. We're going to have an update on that by George Michaelson in the DNS SIG, shortly. At the end of the year we'll be implementing two other policies,No. 17 is to recover unused address space. That will be applying to all historical address space which has been managed by APNIC but not covered by membership agreement. The other - proposal 18: protecting historical records in Whois database. Sanjaya will be giving an update on this in the database SIG. That's a proposal to protect all historical records with the APNIC HM maintainers and an account fee will be charged for updating records. That doesn't prevent anybody from using their existing resource. Just if they want to change the resources. Lastly, proposal 8 - the IANA IPv4 resource request procedures policy. There was consensus in all of the RIR communities - this was approved as a global policy document - it has been forwarded to the ASO for approval. Once the ASO have approved that it will be forwarded to the ICANN board for ratification and will become a global policy. That's the end of my brief update. Thank you. TOSHIYUKI HOSAKA: Thank you. Any questions? RAUL ECHEBERRIA: Have you received any request for unconnected IPv6 for unconnected networks? ANNE LORD: Let me ask Son Tran to answer that, he's in charge of that. SON TRAN, APNIC: No, we received one a while ago but since then we haven't received any more. TOSHIYUKI HOSAKA: Thank you. Any other question? No. Thank you, Anne. (APPLAUSE) We would like to have one more presentation regarding IPv6 address sites. TOMOHIRO FUJISAKI: (Pause while presentation loads) Hello. I do my presentation briefly. In this presentation I introduce the Japanese practice of IPv6 assignment to end users. In Japan IPv6 service for - some are already paid customers. As you know, there is a recommendation for assignment site to end users in IPv6. This accommodation document RFC 3166, IAB/IESG recommendations. There are some discussions about this size at the last meeting and yesterday. In Japan, most, all major ISPs offer IPv6 service, there are various access line, leased line, DSL. And many targets: Enterprise to residential users. Services also commercial or experimental. In general, the trend of assignment size is /48 for enterprise service and /64 for residential service. This is an example of IPv6 service in Japan. As you see, some ISPs offer /46 to end users. And most of them are to residential users. And this graph shows the trend of assignment size. I ask ISPs why you use such assignment size and I got some - these are reasons. As you see, the ISPs want to differentiate enterprise service from residential service, especially in price. So they want to assign /48 to enterprise and /46 to residential SOHO users. They say /48 is too large for SOHO or residential users. They say currently into objection to this size from end users. I've heard this opinion from several LIRs, Whois database registration issue. They say this is mainly from privacy issue, it's important especially for residential users and they say if they choose a /48 assignment they have to register the assignment to the database or they have more workload than they choose the /64. This is the technical reason for /64 assignment. They say they want to specify the IPv6 prefix to provide IPv6 application service. This means that if they assign /48 to users they can't know which prefix will be used, so they assign /64. Some say not only about assignment size but to assign statistically or dynamically is very important. And they want to assign dynamic. This is mainly from the privacy issue, or they say current IPv4 based equipment assume dynamic assignment. So if they use the same device the IPv6 assignment should be / - dynamic. Next, this is Japanese end user's voice. Some IPv6 users express these opinions. They say there is a current recommendation - they want to use a larger IPv6 space with no additional fee. If the purpose why ISPs assign /64 for end users is reasonable, it may be necessary to reconsider the assignment recommendation and allocation policy. This is the end of my presentation. Thank you. TOSHIYUKI HOSAKA: Thank you very much. Any comments? Questions? JORDI PALET: Hi. I think if the reason to assign a /64 is because the /32 is too small then the policy allows to both for a bigger prefix so that should not be a rationale to provide the users a smaller prefix. I also think maybe it's a question to interview the ISPs who are already assigning /64, what happens when a user, for example, decides for whatever reason to have two segments or more, they are going to assign additional /64 and ask the user to renumber or different /64 non-consecutive. I think those are important questions not only from the user's point of view but also from the ISP management and operation cost when this starts to happen. Maybe it's something to ask before taking any decision to change that. TOSHIYUKI HOSAKA: Thank you. Any other comments? Thank you. TOMOHIRO FUJISAKI: Thank you very much. (APPLAUSE) TOSHIYUKI HOSAKA: We have covered all the presentations prepared for this session. I hope this session is very useful for you all. Let's close this session with a big hand. Thank you. (APPLAUSE) Morning tea break Time: 10.44am