The Chair introduced the SIG and explained the agenda for this sixth Address policy SIG and thanked the sponsors. He called for volunteers to consider helping by co-chairing future meetings.
The Chair also explained that this session will introduce the "rapporteur" system, with Sanjaya from APNIC helping to define the consensus items.
- A proposal for IPv4 essential infrastructure assignments
[Presentation]
Paul Wilson, APNIC
This presentation proposed a policy to specifically allow assignments to critical infrastructure services in the Asia Pacific region. The presenter noted that currently the policies only consider the amount of address space an organisation needs, rather than the specific need of the organisation. The proposal is to allow for minimum assignments of /24 to be made to critical or essential infrastructure.
The proposed definition of critical infrastructure is restricted to Root DNS servers, gTLD servers, ccTLD servers, RIRs, NIRs, and IANA. The presenter noted that ARIN has a similar policy in place. RIPE NCC has no specific policy, but assignments may be made by LIRs on behalf of their customers. LACNIC currently has no similar policy but is considering a proposal at their next meeting.
The presenter outlined two options for determing the source of the assignments. The first option would be to use a single specified large block of address space. The second option is to use existing swamp space.
Questions and discussion
- In clarification, it was noted that this proposal does not describe existing practices; it is a proposal for a new policy.
- There was a comment that it may be necessary to define critical infrastructure for IPv4 separately from IPv6. It was clarified that the current proposal deals only with IPv4 but that the next presentation examines the need in IPv6.
- It was noted that selecting assignments from a single block does not in fact increase the risk of DoS attacks.
- It was also noted that ARIN makes IX assignments from a published reserved block and makes micro assignments from a different published reserved block.
- RIPE NCC confirmed that their policies for IXPs and root name servers apply only to IPv6 address space.
- It was argued that users are more interested in large hosting services than in the types of infrastructure described in this policy, and that the policy does not reflect true operational experience.
Action items
None
Top
- Proposal for IPv6 policy for essential infrastructure in the Asia Pacific region
[Presentation]
Izumi Okutani, JPNIC
This presentation proposed a policy very similar to the previous proposal, but specific to IPv6 infrastructure. The presenter briefly summarised the implementation of the new IPv6 Address policy.
The presenter compared the essential infrastructure policies of ARIN, APNIC, and RIPE NCC. She noted that infrastructure assignment sizes vary across the regions.
The proposal is to make a /48 IPv6 assignment to all defined forms of essential infrastructure, including, Root DNS servers, IXPs, gTLDs, ccTLDs, RIRs, NIRs, and IANA.
Questions and discussion
- It was noted that in IPv4, the rationale for this type of policy relates to an interest in conservation. It was argued that the conservation is not as important in IPv6 and so there is no rationale for treating these allocations differently to any others.
Action items
None
Top
- IPv6 address allocations for the Root DNS servers
[Presentation]
Akira Kato, WIDE
This presentation noted that development is still ongoing in relation to IPv6-ready DNS servers. The presenter proposed that Root DNS servers should be eligible for regular /32 allocations. It was also proposed that the prefix could be used outside the AP region, including for uses such as anycast. The presenter also tentatively proposed that the allocation fee should be waived for allocations to Root DNS servers.
The presenter noted that /32 is suitable for traditional multihoming techniques. He also noted that micro-allocations are unsuitable due to doubts about their routability. He also noted that larger allocations may help to prevent future routing table growth.
The Chair sought consensus on the following questions
- Do we consider essential infrastructure as special? Do we need a policy?
- It was suggested that the existing policies do not currently match the actual deployment experience. However, that did not necessarily lead to a definition that accorded with the one that had been proposed.
- There was a show of hands in favour of introducing a special policy. There were two objections to this.
- The Chair observed consensus on the issue of the need for a special policy.
- What should the definition of essential infrastructure include? The current proposal includes Root DNS, gTLD, and ccTLD servers, IXPs, RIRs, NIRs, and IANA. (Note, only the network infrastructures themselves are eligible - this proposal is not meant to apply to registrars).
- There was a discussion about including other types of organisations; however, no other specific proposals were made.
- There was a show of hands in favour of the proposed list. There were no objections to this.
- The Chair observed consensus on the proposed definition of essential infrastructure (for IPv4 and IPv6).
- What should be the source for essential infrastructure assignments (IPv4 only)? Use "swamp space (202, 203)? Or nominate a special block?
- It was argued that using 202 and 203 space was preferable due to the filtering arrangements already in place. It was also suggested that this would be a good way to use space in that range.
- It is not expected that there would be a large number of these assignments.
- It was explained that the intention of this proposal is different from the current multihoming policy.
- There was strong support for selecting swamp space; however, there were several hands raised in favour in using a special range. The Chair asked for some comments from those preferring the use of a special range. It was explained that a special block would be better as it would aid in the simple configuration of filters. However, there was also a comment that a special range would require the addition of a new configuration line, whereas the swamp space is generally taken into account already on most routers. There was a second show of hands taken. This time, there were no objections to the use of swamp space.
- The Chair observed consensus on the use of swamp space for these IPv4 assignments.
- Should we assign /48 or /32 for IPv6 essential infrastructure assignments?
- It was argued that since the conservation goal does apply to the same degree as in IPv4, it is preferable to assign /32.
- It was also argued that /32 assignments would increase the routability of the assignments. It was also noted that assigning /48s would require special router configurations.
- It was suggested that it would make sense to include IXPs in the list of infrastructure eligible for a /32 assignment.
- There was a suggestion that conservation should not be totally disregarded and that there was no real problem with assigning /48s.
- It was argued that routability should be a major consideration in deciding assignment size, and that /32 would be more routable.
- It was suggested that although essential infrastructure is special, it should still be considered a "site". It was also noted that because there are not a large number of these assignments to be made, then maintaining the filters will not be difficult.
- There were discussions about the uncertainty of multihoming considerations in IPv6, and a suggestion that it could lead to essential infrastructure requiring multiple /32s.
Concern was expressed about why /32s were considered so special in terms of routing.
- It was noted that no matter the assignment size, there would still be only one entry in the routing table.
- Assignments to routable infrastructure.
- There was a show of hands on what assignment size was favoured for routable infrastructure. Many people supported /32; a smaller numbered supported /48.
- The Chair observed consensus in favour of /32 assignments for routable infrastructure.
- Assignments to non-routable infrastructure (e.g. IXPs)
- There was a show of hands on what assignment size was favoured for non-routable infrastructure.
- The Chair observed consensus in favour of /48 assignments for non-routable infrastructure.
- It was noted that efforts would be needed to seek global consensus on these policies in the interests of consistency. It was suggested that it would not be inconsistent with the global policy development for APNIC to now make an amendment. It was stated that there is no need to wait for global consensus before implementing this proposal.
- It was clarified that all existing /35 holders in this region will be eligible for an automatic upgrade to /32, but that it is up to them to apply for the upgrade.
- The Chair reviewed the consensus items from this session. He noted that there was an additional agenda item to be held over until the next session.
[Meeting adjourned at 5:50pm, to be reconvened at 9.00am on Thursday]
[Meeting reconvened at 9:10am Thursday 5 September 2002]
The Chair thanked the sponsors for this day and reminded members that APNIC hostmasters are available during the meeting for consultations. He then reviewed the agenda for the day.
Top
- Policies for ASN management in the Asia Pacific region - revised draft
[Presentation]
Anne Lord, APNIC
This presentation reviewed the current status of the proposed APNIC ASN policy draft. The presenter reviewed the changes to the draft since the previous APNIC meeting. In particular, the draft would allow LIRs to provide ASN services to their customers (subject to certain restrictions). The draft would also make registration of routing policy optional.
The proposed policy seeks to provide more secure management of ASN resources. It is also intended to separate ASN policy from IP Address policy. The proposal maintains the principle of resource licensing, rather than ownership and requires unused ASNs to be returned.
The presenter summarised the official review process and noted that the document has been presented on a final call for comments. She then asked for approval of the document in the current form.
Questions and discussion
- It was clarified that the proposal is for ASNs assigned by LIRs to be non-portable, but that all other assignments would be portable.
- It was noted that JPNIC currently only assigns directly. It was noted that under this proposal, it would still be open to JPNIC to determine whether to adopt the indirect assignments.
The Chair sought consensus on whether LIRs should be able to assign ASNs to customers under the terms described in the current revised policy document. There was a show of hands in favour of this proposal.
- The Chair observed consensus on this issue.
- It was agreed to present the document for another final call for comments, noting the acceptance of the principles at this meeting.
Action items
- Action add-14-001: Secretariat to release ASN policy draft for an additional final round of comments.
Top
- Experimental Internet resource assignments
[Presentation]
Geoff Huston, Telstra
This presentation proposed a policy to allow for temporary address space allocations to be made for experimental projects, without having to meet the regular allocation criteria. The proposal would require that all experiments that receive temporary address space would require public disclosure and that outcomes should be published.
The presenter also explained the intention to approach the IETF with regard to making modifications to the requirements of experimental RFCs.
The proposal is that allocations would be made for one year. Extensions would be possible, but are not intended to be the norm. It was also noted that additional allocations would not be made in the annual cycle of the original allocation.
It is also proposed that there be a specific fee for these allocations which would not be prohibitive to researchers. It was also stressed that the allocations could not be used for commercial purposes.
Questions and discussion
- It was noted that customers of some members also wish to receive global addresses on an experimental basis. It was suggested that the customer could apply directly to APNIC for an allocation under this policy, rather than having the LIR make an assignment for the experiment.
- It was explained that not every experiment that might be performed would be eligible under this proposal.
- It was noted that the 6bone address space has been in use for several years now and it appears to have moved from being an experimental space into a space used for applications which promote the use of IPv6. It was noted that this proposal does not intend that promotion should be considered in the same way as experimentation.
- It was noted, by way of an example, that there is a plan to experiment with the deployment of four-octet ASNs. It would be useful to experiment with long ASNs in conjunction with short ASNs before deployment.
- It was noted that the one year limit on experiments is a good idea.
- It was noted that this proposal is for experimenters inside the AP region. It would be helpful if other RIRs had a similar policy and if all experiments globally could be published in a single place. However, the global coordination of the experiment would be the responsibility of the experimenter. The RIRs could consider the use of global routing and the global network when evaluating the request.
- It was argued that experimentation may be quite different from deployment and that there may be needs to experiment with totally new ways of using address space.
- The Chair noted that there may be a grey area between the IETF and the RIR and asked whether there was a need for a recommendation from the IETF in relation to evaluating experiment proposals. It was suggested that the proposal references an experimental RFC, rather then Internet Drafts. There would be adequate opportunity for the RIRs to make comments during the IETF process. In clarification, it was noted that the IETF accepts comments from individuals rather than organisations.
The Chair sought consensus on this proposal.
- There was a show of hands in favour of accepting the proposal and no objections.
The Chair observed consensus on this issue.
Action items
- Action add-14-002: Secretariat to take steps to implement the experimental allocation proposal.
Top
- Proposal for IPv4 Allocations by LIRs to ISPs
[Presentation]
Anne Lord, APNIC
This presentation proposed a policy amendment to allow LIRs to make non-portable allocations to their customers, provided the LIR maintains aggregation, all allocations and assignments are registered, and all allocations above the LIR's assignment window are subject to the second opinion process.
The presenter explained that this practice has been used informally, but changes to the recent whois database require a more formal approach to registering resource status.
It was noted that there is a trade off in terms of address space utilisation. For this reason, downstream allocations will only be allowed at the LIR level and no further.
Questions and discussion
- It was clarified that this proposal only applies to IPv4. Under IPv6, downstream allocations are already possible.
- It was noted that in IPv6, allocations to downstream providers are treated differently when calculating utilisation. It was explained that IPv4 requires a greater consideration to be given to conservation issues.
- It was noted that for ISPs this will be a welcome policy; however, it does raise the possibility for abuse of the process. It was explained that the second opinion process would be used to help avoid that issue. It was also noted that the evaluation would also take place when LIRs request additional address space.
- ARIN confirmed that the policy is in place in their region and works well.
- The proposal does not specify criteria for the downstream allocations; however, an LIR's practice would be carefully considered in second opinions and subsequent requests.
- It was suggested that LIRs should be responsible for the utilisation rate within their allocations. This had been considered, but appeared to impose significant practical difficulties for LIRs.
- There was a concern about whether giving LIRs an allocation function would require a change to fee structure. However, it was explained that the role of the NIR is quite different.
- There was a suggestion that the policy should be recursive downstream. It was explained that the proposal is deliberately restricted to the LIR level because of the potential adverse effects on registration and management.
- The proposal currently only anticipates use of the APNIC or an NIR database.
- It was explained that if a downstream requires portable address space, then it would be required to approach the NIR or APNIC.
- The general principle that applies to assignment size would also apply to downstream allocations. This would be considered on the basis of documentation provided to APNIC in the second opinion process or a subsequent request.
- It was noted that there may be a need for APNIC to provide supporting documentation to assist LIRs in evaluating assignment size.
- If a downstream customer has already received allocations and assignments, they would need to use 80 percent of their address space before they could request more from their LIR. The total amount of address space held would be considered.
The Chair sought consensus on this proposal.
- There was a show of hands in favour of accepting the proposal and very few objections.
The Chair observed consensus on this issue.
Action items
- Action add-14-003: Secretariat to implement the LIR sub-allocation proposal.
- Action add-14-004: Secretariat to provide supporting documentation to assist LIRs in evaluating allocation sizes.
Top
- IPv6 documentation policy
[Presentation]
Philip Smith, Cisco
This presentation proposed a policy for setting aside a range of addresses to be used for documentation purposes. It was noted that unlike IPv4 and ASNs, there are no IPv6 addresses set aside that can be used for documentation examples. Operational problems can arise from misuse of documented numbers.
It was noted that the intention of this proposal is not to specify a "private" address range.
Questions and discussion
- There was a comment in support of the proposal, with a suggestion that only one prefix is required globally. It was agreed that if the proposal is accepted, APNIC should liaise with the other RIRs to select an address prefix.
- It was noted that documentation authors do not want to use link local or site local addresses, as they need examples that look like normal addresses.
- There was a suggestion that cutting-and-pasting link local addresses would mean that only internal systems would be affected, but not the wider Internet.
- It was explained that this proposal was taken to the RIR rather than to other bodies, because RIRs are the ones who distribute address space. No specific range has been nominated in the proposal.
- There was a comment in support of the proposal, but expressing concern about using the current 2001 range. It was suggested that one of the 6bone ranges may be suitable in the future.
The Chair sought consensus on the principle expressed in the proposal, with the particular address range to be considered later.
- There was a show of hands in favour of accepting the proposal and very few objections.
The Chair observed consensus on this issue and requested further work to be done in discussing with other RIRs to determine the details of the range to be used.
Action items
- Action add-14-005: Secretariat to discuss the IPv6 documentation proposal with other RIRs to determine the details of the range to be used.
[Break 11:00 - 11:15 am]
Top
- 6bone address registry proposal
[Presentation]
Ray Plzak, ARIN (on behalf of Bob Fink)
This presentation was a proposal to provide a framework for migrating the existing 6bone allocations into the RIR system. This proposal has previously been posted to RIR lists and discussion has begun in the 6bone community.
The presenter outlined the background of the 6bone test-bed and noted that all 6bone addresses had been allocated outside the RIR process. He noted that it is intended provide for easy and supportive volunteer efforts to continue.
Under the proposal, the 6bone participants would be required to associate with their appropriate RIR. Fees would be waived for the first year. Organisations would receive 6bone allocations only with the approval of 6bone, although participants could opt to arrange with the RIR for additional registry services under different terms.
The proposal also contains provisions in relation to registration, return of addresses, and compliance with other RIR policies and procedures.
It is proposed to continue discussion of this proposal in the 6bone and RIR communities until there is a rough consensus. However, there is a deadline of December 2002 to finalise the policy.
Questions and discussion
- It was suggested that this proposal could create separate classes of membership, with one class paying and one not. It was explained that there may be the imposition of a fee similar to that proposed under the Experimental Allocation proposal discussed earlier. It was also noted that the allocations would be regarded as valid only for the duration of the project.
- The Chair noted that this session should be considered as an input session, with feedback to be sent to the 6bone community.
- There was an encouragement for the community to get involved in the discussion of this issue on the 6bone mailing lists in particular.
- It was suggested that the 6bone really should be wound up soon as the application testing has been done sufficiently and additional work should be done in regular global addresses.
- There was a question regarding how this proposal could be implemented. It was clarified that 6bone participants would be required to renumber into RIR space for any commercial or non-experimental application.
- There were several comments generally supporting the principles in this proposal.
Action items
- Action add-14-006: Secretariat to provide feedback of the 6bone migration proposal discussion to the 6bone community.
Top
- Comments to RFC2050 revision
[Presentation]
Ruri Hiromi, JPNIC IP Group
This presentation reported on the discussion relating to this issue at the recent JPNIC Open Policy Meeting. In particular, the presenter described the activities of the RFC2050 Working Group.
The presenter raised questions relating to the current applicability of RFC2050 and the possible need to replace it. She noted that RFC2050 appears to be out of date, and has been effectively replaced by RIR documents. She suggested that RFC2050 should be made obsolete.
This raises the question of whether it is better to replace RFC2050 with references to each RIR document or to create a new global document. The result of the JPNIC discussion was to recommend making RFC2050 obsolete and then to consider the intended purpose and value of the new document.
Questions and discussion
- The Chair noted that this session should be considered as an input session, with feedback to be sent to the RFC2050 Working Group and the other discussions relating to this issue.
- The Chair called on the APNIC Director General to describe the current status of the project led by Mark McFadden to replace RFC2050 with a suite of new documents. It was noted that McFadden has more than 20 volunteers helping to produce documents. They have set a timeline, which aims to produce documents by the end of the year.
- There was a comment that the existence of RFC2050 needs to be put in its historical context. It was developed at a time when there was no RIR structure. It was argued that it may be more appropriate to simply make the document obsolete and not replace it with anything else. It was suggested that the RIR communities should encourage efforts to describe common elements in current RIR policy, rather than to seek to dictate global policy.
- It was noted that there is no intention for the RFC2050 project documents to be taken to the IETF. Rather, it is intended to present the series of documents to the RIRs for consensus.
- It was noted that there will also be a update presentation made at the upcoming RIPE meeting.
Action items
- Action add-14-007: Secretariat to provide feedback of the APNIC discussion on RFC2050 revision to the appropriate mailing lists.
Top
- Large space IPv4 trial usage program for future IPv6 deployment - update 3
[Presentation]
Kosuke Ito, IPv6 Promotion Council of Japan
This presentation provided an update on the status of a project that has been discussed at several previous APNIC meetings. The presenter reviewed the background and goals of the project. He also described recent activities, including interviews that have been conducted with project participants.
The user interviews are intended to gain a better picture of address usage within the project. Users reported that the project has been very useful for start-up of new services, particularly because of the growing demand in always-on services and P2P applications.
The presenter noted some difficulties that providers experience from current policies, especially in relation to estimating demand in rural areas, launching broadband services under slow start policies, and the demands of wireless "hot spot" services.
The presenter also described the needs of Content Delivery Services, which require large numbers of global addresses in order to manage content delivery. Although these providers are looking to IPv6, they currently need to start experimenting over existing networks.
The presenter concluded that the project is helping to accelerate the introduction of new IP services, and helps providers prepare for IPv6 deployment.
Questions and discussion
Action items
Top
- Deployment status of wireless LAN services in Taiwan
Eugene Chang, Chunghwa Telecom
This presentation provided an overview of the deployment of wireless services in Taiwan. The presenter described the main types of network architecture that are being adopted to provide these services. He also reviewed the addressing policies used by networks, which generally use DHCP for a start-up portal page and HTTPS access.
The presenter outlined some of the challenges that private IP addressing poses for these services. He noted that it is possible to separate the address pools that are required by authenticated and non-authenticates users.
Questions and discussion
Top
- Call for co-Chair of Address policy SIG
The Chair called for volunteers to act as co-Chair and provide support to the existing Chair for the important work required for Address policy development.
- There were no volunteers from the floor, so the matter will be referred to the appropriate mailing lists.
Meeting closed: 12:30 pm
Minuted by: Gerard Ross
Open action items
Action add-14-001: Secretariat to release ASN policy draft for an additional final round of comments.
Action add-14-002: Secretariat to take steps to implement the experimental allocation proposal.
Action add-14-003: Secretariat to implement the LIR sub-allocation proposal.
Action add-14-004: Secretariat to provide supporting documentation to assist LIRs in evaluating allocation sizes.
Action add-14-005: Secretariat to discuss the IPv6 documentation proposal with other RIRs to determine the details of the range to be used.
Action add-14-006: Secretariat to provide feedback of the 6bone migration proposal discussion to the 6bone community.
Action add-14-007: Secretariat to provide feedback of the APNIC discussion on RFC2050 revision to the appropriate mailing lists.
Top | SIGs
Hosted by: 
