SIG: Address policy
Thursday 27 February 2003, Taipei International Convention Center (TICC), Taipei, Taiwan
Minutes
Meeting commenced: 11:10 am
Chair: Takashi Arano
The Chair introduced the Seventh Address policy SIG and thanked the sponsors. The Chair explained the agenda and encouraged participation throughout the meeting.
Election of co-Chairs
It was explained that there has been a call for nominations for the two positions of co-Chair of this SIG.
The nominees were introduced:
- Yong-Wan Ju
- Kenny Huang
- Jeff Williams (not present)
Yong-Wan Ju and Kenny Huang were elected as co-Chairs of the Address policy SIG.
The two new co-Chairs briefly addressed the meeting and expressed their willingness to help the SIG perform its function of reviewing Address policy in the Asia Pacific region.
Contents
- A review of policy development processes in the Asia Pacific
- APNIC policy process - provoking discussion
- Signing the DNS root: Authentication and trust
- Proposed amendment of APNIC document review policy
- IPv6 address space management
- 6bone planning issues
- IPv6 policy in action: Feedback from other RIR communities
- Issues in the delegation of 2.0.0.2.ip6.arpa
- 223.255.255.0/24 problem
- Policy documentation status update
- RFC2050 update
- Large space IPv4 trial usage program for future IPv6 deployment: Update 4
- Open action items
- A review of policy development processes in the Asia Pacific
- It was noted that the implementation of policies requires a broader consideration. It was asked what part of the ARIN process would be used to consider issues that are related to corporate responsibilities. It was explained that at ARIN such issues are the responsibility of the Board of Trustees, but the Board members are subscribed to the policy lists and are able to monitor the progress of proposals throughout the process. It was noted that in APNIC, the nature of the corporate structure requires that such responsibility rests with the Members Meeting.
- A LACNIC representative explained that the Board of LACNIC approves consensus items; however, these decisions are then ratified in the Members Meeting.
- It was explained that in the ARIN region there is a legal responsibility on the Board of Trustees to be diligent in the corporate governance.
- It was noted that there are many interests to be considered in relation to this proposal.
- None
- APNIC policy process - provoking discussion
- The Chair asked to break down the discussions in four issues: use of mailing lists (how can they be used more effectively); who will make the final decision (especially if decisions are to be made after the meeting, and who evaluates discussions on mailing list); the use of presentation slides as opposed to full written proposals; and how strictly should deadlines be applied to proposals for meeting agenda.
- Use of mailing lists
- The Chair asked for feedback on how to better use mailing lists.
- It was suggested that many people have problems understanding the proposals in the meetings and that it is better to allow more time to discuss issues on the mailing lists.
- It was suggested that if a late proposal is put forward, then it should be allowed to go on the meeting agenda, but should then be required to be opened on the mailing list for an appropriate time. It was argued that it is not important whether the mailing list discussion takes place before or after the meeting, so long as there is sufficient time for it to happen.
- Where will the final decision take place?/Who will make the final decision?
- It was noted that in ARIN, it is not the Board who makes the decision. Rather, the Board decides whether the community has made the decision. It was also noted that if a proposal has been discussed to the point where consensus has been reached, and then a meeting is held, then it is no problem for the decision to be made at the meeting. What is important is that the discussion has taken place properly in both forums.
- There was a question as to whether the term "final decision" means a decision that is binding on the corporate entity. There was a question as to how to distinguish between decisions binding on APNIC, and decisions that still must be adopted by the membership association.
- There was a question about the proposal by Randy Bush. It was clarified that the existing policy is proposed to be widened and that timelines need to be applied more strictly. It was also suggested that decisions made at a member meeting should then be announced for a last call on the mailing lists. It was noted that the intention of the proposal is to find the best way of achieving a broadly representative consensus.
- It was suggested that the Secretariat should draft up the proposed formal process and release it for discussion.
- It was argued that there must be an opportunity for the membership to formally adopt the process and the decisions that flow from it. It is important for the membership to acknowledge the process and the interests of the entire community. However, the ability to make the final decision should not be taken away from the organisation.
- It was noted that APNIC has applied various processes for members to follow in reaching decisions. It was argued that the Secretariat and the organisation as a whole need protection that decisions have been properly taken.
- The Chair asked for comments as to whether it is important to have a discussion period after the meeting. There was a show of hands. Some hands were raised in favour of this point and no hands raised against it.
- Documentation style for proposals: presentation slides or full documents?
- It was suggested that having a full proposal text is important for ensuring that everyone understands what they are agreeing with.
- It was suggested that if the process is online, then it will obviously require a text document. However, it was suggested that for discussions at meetings it is appropriate to use a presentation.
- It was argued that it is important to use text documents for the proposals, but that the slides should simply be the means to express the proposal.
- There was a show of hands strongly in favour of requiring proposals to be provided as text documents.
- How strictly should deadlines be applied to proposals for the meeting agenda?
- It was argued that discussions at meetings and mailing lists are equally valuable. If late agenda items are proposed, it is no problem to put them on the agenda then ensure there is adequate time to discuss them on the mailing list, with no decision to be made until the next meeting.
- It was proposed that there could be a three month mandatory period for discussion of an issue and that discussion time must include a meeting.
- It was noted that there are two conflicting suggestions - one to allow a three month minimum discussion with a meeting involved, and one to ensure that late agenda items cannot be decided until the next meeting.
- It was suggested that simply requiring late proposals to be determined at the next meeting could be open to abuse, as it would allow people to strategically push through items at the first meeting. Therefore, the requirement for discussion both before and after the meeting would be fairer and preferable.
- The rapporteur summarised the discussion:
- The more effective use of mailing lists is desired
- The final recommendation would still be subject to legal, procedural, and other review before implementation.
- The meeting has reached a consensus that there needs to be more mailing lists discussion after the meetings.
- Full texts of proposals is required to support the discussions.
- In general late proposals should be allowed to be discussed at a meeting, but no decision can be made until the next meeting, in order to allow more mailing list discussion.
- The Chair noted that he will report these consensus items to the AMM.
- Action add-15-001: Secretariat to draft a proposal summarising the suggested formal process for receiving and discussing proposals.
- Signing the DNS root: Authentication and trust
- It was noted that there seems to be a new set of terminology. It was noted that not all of the DNSSEC work is directed towards existing X.509 structures. It was explained that these keys are defined within the DNS, not as part of the X.509 or PGP. However, there is a strong basis in the RFCs for this technology.
- There was a question about exactly what the keys are certifying. It is proposed that the system is designed to attest that the zone signing key being used is from a particular root zone operator.
- It was suggested that there is a strong issue about core business focus of the RIRs. It was noted that sometimes the RIRs are asked to do non-core activities that are difficult. It was suggested that this proposal could drag the RIRs back into a situation where they become involved in decisions that are very political.
- It was suggested that most servers would be controlled not by APNIC members but by other enterprises.
- It was also suggested that there are security concerns relating to the destruction of keys.
- The presenter explained that it is necessary to distinguish carefully between authorisation and authentication.
- It was noted that so far there is no formal agreement between root servers and ICANN, and that it is possible that the RIRs could be dragged into disputes as to whether an organisation is actually an authorised root server. It is from this lack of formal agreement that the political concerns arise.
- It was argued that if the only concern is to avoid the political problems then important things will never happen.
- The Chair suggested that this is not strictly an Address policy issue and asked that it be referred to the DNS Operational SIG, for further discussion.
- Action add-15-002: Secretariat to refer discussion of signing the DNS root to the DNS Operational SIG.
- Proposed amendment of APNIC document review policy
- It was clarified that this proposal is not substantially affected by the other policy development proposals discussed at this meeting. This proposal is intended to provide a simpler editorial process that is used in the implementation of decisions that reach consensus in the approved decision making process.
- None
- IPv6 address space management
- There was a question as to how filtering would be done. It was clarified that there would no longer be a block of regional address ranges. Providers would still be able to filter on prefix boundaries, but this would require per-address or per-allocation lookups.
- It was suggested that it may not be good to prevent filtering on a regional basis and that therefore it may be better to use smaller ranges that are distributed on a regional rather than a global boundary.
- There was a question as to whether this proposal had the same effect as the former TLA arrangements, which could cause routing pollution and create golden allocations. However, it was argued that this proposal is different to the TLA structure and that individual organisations would still only receive the standard /32 allocations. It was noted that there would not be fixed boundaries in the allocation algorithm.
- It was argued that this proposal applies more flexibility which helps to protect against future problems.
- It was argued that there is uncertainty as to how the future will pan out, there are no examples of organisations coming back for more than their initial /32, and the proposal may provoke a dispute with ICANN.
- It was noted that there is no different system for multihoming in IPv6 than there is in IPv4. It was also argued that it is important to make allowances for flexibility in filtering.
- There was a question as to whether this would require a global whois. It was suggested that this was an implementation issue but that it would not necessarily require a global whois.
- It was argued that it is important to ensure that the allocation structure does not undermine the whois tree.
- It was noted that this problem is intended to avoid the problems that have affected IPv4 for the past ten years.
- The Chair asked for an indication as to whether there was a community consensus to continue to develop this proposal.
- It was noted that under this proposal, members of NIRs would be treated in the same way they are today, in that they would act as agents between their members and the CRS.
- Concern was expressed in relation to the administrative load of creating a new organisation to "baby-sit" the IPv6 address space. It was explained that the CRS would be established as an administratively lightweight and simple organisation. It was suggested that this is what IANA is perceived as being.
- It was noted that the proposal is to allow the RIRs to act as agents between the address users and the address pool. In this respect it is similar to the new NIR allocation structure. There was a question as to whether, under this proposal, NIR members would be treated the same as APNIC members so that they would also have the best chance of contiguous subsequent allocations.
- It was suggested that NIRs could go directly to the CRS. However, it was noted that this was more of administrative and implementation issue that would need to be the subject of further discussion.
- It was noted that this proposal is not intended to be used as a way of policing de-aggregation of address space for multihoming or other purposes. Rather, it is intended to provide ISPs the maximum opportunity to aggregate their address space.
- It was acknowledged that this proposal will need to become a globally coordinated policy before any action could be sought from IANA.
- The Chair asked whether there was consensus for generally supporting this proposal. There were many hands raised in favour of the general direction of the proposal and a small number against.
- The Chair rephrased the question, asking whether there was consensus that the proposal should be discussed further.
- There was consensus that there are no objections to continuing with more discussion of this proposal.
- It was confirmed that this proposal has not yet been formally discussed in the RIPE region, despite the release of the draft proposal as RIPE document.
- None
- 6bone planning issues
- It was noted that an alternative to a single transition of the 6bone is for individual APNIC members who also hold 6bone space to transfer the management of the space to APNIC on a case by case basis. It was noted that there are no major administrative or policy problems with such an approach.
- It was noted that this topic was presented as a status update and does not require a consensus decision from this meeting.
- None
- IPv6 policy in action: Feedback from other RIR communities
- It was noted that most of the comments in the RIPE and ARIN region centre around the 200 customer threshold. There was a question as to whether there is another way to address this problem more quickly than the full document revision. It was noted that it is the reality that whatever amendments are proposed, it will still be necessary to seek consensus of these in all the regions.
- It was noted that there is a plan to form an endowment that would request an IPv6 address space allocation and then distribute /48s at no cost to certain organisations as a way to help them get established.
- It was confirmed that wording of the document does confuse some applicants.
- A representative of the RIPE region noted that they had only rejected one applicant, on the basis they were requesting a second allocation even though they have not used much of their first.
- It was noted that the 6bone has started taking back unused allocations, so this should take away the motivation for people to seek 6bone space in preference to RIR space.
- A representative of the ARIN region noted that they had only rejected two applicants under the new policy. This was on the basis that the applicant had no current intention of using the allocation.
- A representative of JPNIC also mentioned that some members had expressed concern that although they had large customer bases, they were not able to show that they would have more than 200 /48 assignments. Another JPNIC representative noted that the criteria are not clear and JPNIC are investigating these perceptions and will share them with the community.
- It was noted that the document is not clear on how to get allocations larger than /32.
- It was noted that it is too early to properly evaluate the current IPv6 policy, although it is acknowledged that it is not perfect. It was noted that there was an intention with the current criteria that not all requestors would be able to obtain IPv6 space and that end-users do need to be discouraged from seeking allocations. It was argued that the 200 customer threshold is useful, but that some problems may arise in relation to this. It was requested that investigations be directed to the effect of the 200 customer threshold on implementation. It was also suggested that in this respect, it may be necessary to provide better communication to mobile operators that the threshold is not intended as a barrier to them.
- It was noted that it would be useful to see a list summarising the comments that are received on the problems with the document. All registries should collect information on this.
- None
- Issues in the delegation of 2.0.0.2.ip6.arpa
- There was a question as to how many users will use this type of delegation and will face this type of problem. It was also asked whether the 6to4 mechanism is useful. It was noted that, unlike Japan, there are many places where IPv6 connectivity is not easy and that 6to4 remains the best available hack. It was also noted that there are many operators who do not accept traffic from networks that do not have reverse delegation set up.
- It was suggested that it would be administratively easy for the APNIC Secretariat to provide this service to members. APNIC also has a provision in the fee structure to accommodate this service for non-members. It was explained that this service would be quite straightforward.
- The Chair asked for an expression as to whether there was a general feeling that APNIC should take on this task. There was no clear consensus. The Chair suggested that there may not be an understanding of the impact.
- It was suggested that the impact will be greater in those regions with poor IPv6 infrastructure.
- It was suggested that the RIR communities may agree in principle to provide this service, but could still provide the IETF with feedback that it may be difficult to obtain reverse delegation.
- It was noted that there does not appear to be any other body that would be able to take on this task. It would be undesirable to split APNIC's reverse delegation responsibilities with another body.
- It was also suggested that the fee issue would also be able to be reviewed if it presented problems.
- The meeting indicated some agreement that 6to4 can be a useful technique.
- None
- 223.255.255.0/24 problem
- An IANA representative noted that IANA did discuss with the IETF the wording of the reservation within the relevant RFC. IANA is unlikely to have a problem with any decision that APNIC makes.
- It was suggested that this is not an important issue and that so long as the "reserved" range is marked in the database as reserved, there is no problem.
- However, it was argued that this represents a problem about getting a consistent view of address space. It was argued that it raises issues as to who is able to reserve address space and for what it is able to be reserved. It was argued that at this point the address space is reserved by the IETF and should not be changed in status except by another IETF document.
- There was a comment that the RFC that reserves this range is purely informational, seeking to clean up several other reservations. It was argued that if IANA and APNIC both mark it as reserved then its treatment is consistent.
- It was noted that there have been some concerns raised that APNIC has taken some form of illegitimate action. In this context, it would be best to send it back and have it replaced. APNIC would then be able to receive it back at a later time if its status is resolved.
- It was noted that this should be treated as a purely operational matter that does not require a policy response from this SIG.
- It was clarified that the IETF is not able to respond within days on issues such as this. It was also noted that the IESG had commented that there was no particular region why these addresses should not be used. However, the issue of marking the range as IANA reserved is one to be resolved between the IANA and APNIC.
- It was suggested that there are still coordination issues to be sorted out between the IETF and IANA in relation to ad hoc terminology and consistency of address space management.
- None
- Policy documentation status update
- None
- None
- RFC2050 update
- None
- None
- Large space IPv4 trial usage program for future IPv6 deployment: Update 4
- None
- None
- Open action items
Action add-15-001: Secretariat to draft a proposal summarising the suggested formal process for receiving and discussing proposals.
Action add-15-002: Secretariat to refer discussion of signing the DNS root to the DNS Operational SIG.
Anne Lord, APNIC
This presentation described the current policy development processes in this region, provided a comparison of the processes in other regions, and discussed the problems with the current process.
The presenter noted that there has not been a formal review of this process since October 2000. She noted that the problem is that it is not yet clear what is the best way for creating good process in this region. She noted that there is a need to have an inclusive process that takes account of all stakeholders and which balances local and global interests, including technical interests.
There was a detailed description of the SIG and AMM processes currently in place, including the role of the mailing lists. It was noted that currently the recommended timelines for submission of proposals are often not met.
The presenter noted the practical difficulties of determining when there is consensus on a particular issue. She discussed the role of the APNIC Executive Council, including the provisions of the APNIC By-Laws, which empower the EC members to act on behalf of members between meetings.
The presenter noted that in this region there is limited use of the mailing lists.
The presenter reviewed the procedures used in the RIPE and LACNIC communities. At this point, the presenter invited Ray Plzak of ARIN to explain the process in the ARIN region.
ARIN Internet Resource Evaluation Process
It was explained that ARIN uses a cyclical process which involves identifying a need; discussing the issue; seeking consensus (as appraised by the Advisory Council); implementing the consensus (following ratification by the Board of Trustees that the process was followed); and evaluation of the impact and effect of the policy.
The ARIN process uses a series of fixed milestones. Until proposals meet the milestones, they may not move into the next phase. The presenter gave details of the specific milestones in the ARIN process.
Questions and discussion
Action items
Randy Bush, IIJ
This presentation sought to provoke discussion on developing a process that would be more inclusive and representative of a broader range of legitimate stakeholders.
The presenter noted that APNIC is more culturally diverse than the other RIRs. However, he also noted that some members of the communities, such as protocol, backbone, and router engineers are not well represented. The presenter suggested that some policy decisions have already been made which will have long term effects on the technical communities.
He noted that the current policy process in APNIC does not allow enough notice to allow proper discussion and participation.
He suggested that the ARIN model is too complicated, but that the IETF model would be more appropriate for the APNIC region. He stressed the need for tracking and archiving proposals, discussions, and decisions. He suggested that slowing the process down would not be harmful.
He proposed that there be no discussion without a written proposal. He argued that discussions at meetings alone leave out most of the community. He argued that the mailing lists should be the primary media for discussion, but that all communication channels should be opened and should be legitimate.
Questions and discussion
Action items
[Break 12:35 - 2:00 pm]
Johan Ihren, Autonomica
This presentation described the issues currently documented in a draft RFC relating to DNSSEC. He explained that DNS is fundamentally about trust. He noted that those involved in DNSSEC so far have been technical and protocol people, occupied with the issues involved in making it work. It may now be appropriate for the RIRs to become involved to provide the mechanism for trust.
He noted that this suggestion has an impact on RIR resources and operations and so should be considered by the RIR communities.
DNSSEC is now nearly completed and ready to deploy. It relies on a chain of trust terminated by a trusted key. Therefore, the subject of management and distribution of the trusted key becomes a major challenge for deployment. The presenter described a set of criteria for entities that are able to sign the trusted keys - they would need an existing trust base, would exist as multiple entities, and would have a willingness to work with others in the Internet community. The presenter suggested that the RIRs meet these criteria. He noted that the RIRs also have also been working to establish certification procedures.
Questions and discussion
Action items
Gerard Ross, APNIC
This presentation proposed amending the existing document review policies to properly recognise the operations of the SIGs and AMMs in the decision-making process. It is proposed to simplify the editorial procedures which apply in the implementation of consensus decisions.
Questions and discussion
Action items
Paul Wilson, APNIC
This presentation discussed a proposed method for the allocation of IPv6 address space. It was noted that the current system of delegation from IANA to the RIRs has led to a serious fragmentation of IPv4 address space.
It was explained that IPv6 has no built-in safeguards to protect against routing table growth, therefore it is necessary to minimise fragmentation in the IPv6 address space. A draft system for a new allocation system has been published as a RIPE document but is still to be determined by the RIR communities.
The intention of the proposal is to provide a mechanism that would ensure that address holders would be able to grow into and announce a single prefix. The presenter outlined the sparse allocation method that is proposed to achieve this result. This approach would require that the RIRs allocate from a single address space rather than receiving multiple smaller address ranges.
The proposal is to form a Common Address Pool (CAP), to be operated by a Common Registry Service (CRS). Under this proposal, the RIRs would request that IANA delegate the entire range 2000::/3 (FP001) to the CAP.
The presenter demonstrated how the sparse allocation algorithm would operate. He noted that the proposal contains an intention to review the allocation operations after the 1024th allocation (which is expected to take 2-3 years).
Questions and discussion
[The next presentation was delivered now, but the Chair returned to this discussion]
Action items
David Kessens, Nokia (co-authored by Bob Fink)
This presentation gave an overview of the history and operations of the 6bone project. He noted that the 6bone become a de facto registry alongside the other RIRs and this caused problems of perceptions. The 6bone was never intended to be permanent and discussions have now commenced on how to phase it out.
A draft plan has now been proposed to transition the 6bone to the existing registries. The presenter summarised the discussions that have taken place so far and the feedback from the 6bone community.
Questions and discussion
Action items
[The Chair returned to the discussion regarding the proposal for sparse allocation of IPv6 address space.]
[Break: 3:40 - 3:55pm]
David Kessens, Nokia
This presentation discussed the implementation of the revised IPv6 Address policy and the experience of operators in working with that policy.
The presenter summarised the comments that have been received by IPv6 operators in the RIPE and ARIN regions. He noted that many of the comments arose at the same time from different regions.
There have not been any comments received from people who have had IPv6 applications rejected.
The most common complaint about the policy is that the 200 customer threshold is a barrier to entry. Some have suggested lowering the threshold, but others have suggested abolishing the barrier altogether until a certain number of prefixes have been allocated. Some have suggested that it would be better to just allocate /48s.
There have been concerns that the wording of the document makes it difficult to understand.
Some have suggested a need for longer prefixes to be given to small ISPs that want to multihome. There are also concerns about what sorts of organisations should be defined as big enough to qualify for an allocation.
The presenter noted that the editorial committee that worked on the original IPv6 policy document has informally discussed editing the current policy document with a view to making changes to a limited number of issues which could be easily fixed. This document would then be circulated to stimulate and focus discussions across the regions. It is unlikely that bigger issues, such as multihoming, would be included in the revisions at this stage.
Questions and discussion
Action items
Randy Bush, IIJ
This presentation discussed the issues related to RFC 3056, which deals with enterprises with internal IPv6 sites trying to communicate with IPv4 networks, using automatic 6to4 tunnelling.
The presenter noted that forward DNS mapping is simple, but that reverse mapping is more complicated, due to the problems of delegating the DNS zone. The top of the 2.0.0.2.ip6.arpa tree is the RIRs. But problems are caused for downstream ISPs that are served by upstream ISPs who do not support IPv6. They are then required to move up the tree, potentially all the way to the RIRs. This could have a policy implication if small fragments of the 2.0.0.2.ip6.arpa space need to be delegated to small end sites.
Questions and discussion
Action items
Anne Lord, APNIC
APNIC recently received the address range 223/8, which contains a /24 range currently marked as IANA reserved.
There have been comments on the NANOG list that IANA should consult IETF/IAB before allocating reserved prefixes.
It has been suggested that APNIC should mark the reserved range as reserved in the APNIC database, but to allocate normally from the rest. It was also suggested that APNIC should return the entire range to IANA.
Questions and discussion
Action items
Gerard Ross, APNIC
This presentation summarised the documents that have been produced or modified to implement policy decisions from the past two APNIC meetings. The presentation contains links to all relevant documents, forms, and FAQs.
Questions and discussion
Action items
Ray Plzak, ARIN (on behalf of Mark McFadden)
This presentation summarised the progress of the project to update the material contained in RFC 2050 and replace that document with several more concise documents.
The presenter noted that the project is currently seeking more volunteers to serve on the editorial teams.
Questions and discussion
Action items
Kosuke Ito, IPv6 Promotion Council of Japan
This presentation updated the current status and activities of the large space IPv4 trial usage program.
The presenter reported that for most participants there have been no changes to the main uses of the project. The project team has observed that the program contributes to a growth in the Internet market and makes users aware of the goodness and usefulness of global IP addresses. The program also stimulates demands for increased broadband usage and development of new applications. In particular, there has been an increase in the number of VOIP users.
The presenter also summarised the results of surveys on the users' views and concerns of IPv6 service deployment.
Questions and discussion
Action items
The Chair reviewed the open action items. All open items from last meeting have now been closed.
Meeting closed: 5:35 pm
Minuted by: Gerard Ross
