______________________________________________________________________ DRAFT TRANSCRIPT SIG: Policy Date: Thursday 2 March 2006 Time: 11.00am Presentation: IPv6 portable assignment for multihoming Presenter: Toshiyuki Hosaka ______________________________________________________________________ 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.