Election of co-chairs

The Chair expressed thanks to co-chair Yong Wan Ju, who has stepped down from his position. He noted that he made a call for replacement co-chairs. The nominees are Randy Bush, Billy MH Cheon, and Toshiyuki Hosaka. He called on each nominee to make a short speech.

Randy Bush noted that he is Chief Scientist at IIJ, was on the founding Board of Directors of ARIN, helped negotiate the DNS dispute resolution policy, and was the founding engineer at Verio. He noted his strong continuing interest in engineering, particularly in relation to routing. He explained his belief that engineering and policy meet daily and this is why he nominated.

Billy MH Cheon of KRNIC/NIDA noted that this is his seventh APNIC meeting and he believes it is time he contributed his experience to the APNIC community.

Toshiyuki Hosaka from JPNIC noted he has been working at JPNIC since 2002. He has co-chaired the group that developed the IPv6 Guidelines document. He has experience with an international telecom provider. He expressed his desire to give his best efforts to the community.

The Chair thanked the nominees and asked for a show of hands to vote for the new co-chair:

Randy Bush 8

Billy Cheon 6

Toshiyuki Hosaka 16

The Chair congratulated Hosaka-san on his appointment as the new co-chair of the Policy SIG.

Review of open action items

pol-16-008: Proposer to resubmit revised version of IXP proposal (prop-011-v001) dealing with remaining proposal elements, such as fee waiver (which had been withdrawn during discussion), characteristics (which became ambiguous with withdrawal of fee portions), and combined IPv4 and IPv6 assignments (which were not fully discussed).- Update: It was noted that there have been attempts to get the proposer to revise the proposal, but there has been no response. There was a comment that there is a related topic that could also be proposed, namely making IPv6 and IPv4 IXP assignments at the same time. It was agreed that this should be dealt with as a separate proposal at the next policy SIG. It was agreed to close this action item.

pol-17-001: Pending approval at each remaining stage of the policy proposal process, proposer to resubmit a modified version of the proposal (prop-013-v001) to the mailing list. The rewritten proposal will define multiple discreet networks and consider the HD ratio for sub-allocating address blocks.- Update: The Secretariat has discussed this with UUNET, who report that they wish to keep the proposal open, however the original proposer is no longer with UUNET.

pol-17-002: Pending approval at each remaining stage of the policy proposal process, Secretariat to implement the proposal (prop-016-v001), with the modification that there is an added a requirement for LIRs to have plan to move some of their customers from IPv4 to within two years.
- Update: Done

pol-17-004: APNIC Secretariat to edit the IPv6 guidelines document, post to the sig-policy mailing list for comments and to publish after review period. - Update: Done

pol-17-005: Pending approval at each remaining stage of the policy proposal process, secretariat to implement the proposal to reduce the minimum initial allocation size to /21 and to lower the criteria for an initial allocation to demonstrate an immediate need for a /23 and use of a /22 within one year (prop-014-v001).- Update: Done

pol-17-006: Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal to recover unused address space (prop-017-v001).- Update: This is in the process of being implemented and is expected to be completed by the middle of December 2004.

pol-17-007: Secretariat to call for volunteers of a new working group to review the current DSL/cable guidelines in the document 'APNIC guidelines for IPv4 allocation and assignment requests'.- Update: Done. However, to date there has been only one volunteer. The Chair encouraged more volunteers to come forward after this meeting.

A proposal to prevent the routing of "dark" address space

This is a proposal to develop specific procedures to prevent the use of unallocated, or 'dark', address space for illegal or unsavoury practices, such as spam. The proposal seeks to deal with the problem using a combination of technical, business, and legal practices. The proposal is that APNIC should seek to recover address space from ISPs which continue to route dark address space after being warned. The presenter argued that this proposal relies on the allocation of rights ' those who refuse or neglect to maintain or update their routing tables should lose their right to allocated address space. The presenter noted that this proposal involves a very strong penalty and should only be applied in the most egregious cases.

Questions and discussion

It was suggested that if the proposal was implemented, APNIC would be sued out of existence.

It was confirmed that APNIC currently has a hostmaster procedure, which looks to the bogon lists and contacts ISPs which appear to be routing unallocated space, requesting them to stop.

It was argued that this proposal would require the RIRs to become the routing police, which would seriously disrupt ISP business and destroy the RIR system as it currently stands. The presenter agreed but suggested that by discussing these issues in this forum, it may help to prompt a less drastic solution. The presenter urged vigilance in how operators route and actions to put pressure on those who seek to operate outside the responsible practices. It was argued that by providing services to scofflaws, operators do a disservice to the rest of the Internet.

It was argued that research into dark addresses shows two major problems. The first is that the proposal targets routing, rather than originating. Most major carriers will, therefore, be routing dark address space. Second, for historical reasons, there are many organisations which may wrongly appear to be affected by dark address space.

It was argued that a better approach is to focus on developing a system of trust in relation to addresses that are being injected into the system. This relates back to the work done recently in the Routing SIG in relation to certification of routing information. The proposer agreed with this sentiment, but noted the current lack of authentication in the public Internet. He suggested that IPv6 may help, but pointed to the long timeframe expected for IPv6 roll out.

There was a clarification of the use of a show of hands to seek consensus on this proposal.

It was noted that there are no firm statistics on the amount of spam originated from dark address space, although there appears to be some work ongoing.

A representative from JPNIC noted that JPNIC would not be able to support this proposal due to the effect it would have on JPNIC members.

The Chair called for a show of hands to seek consensus on this proposal. There was no support for this proposal.

HD ratio for IPv4 allocations

This proposal describes an alternative method for determining utilisation levels in IPv4 allocations. This proposal was first presented in 2003 as an informational proposal. The proposal is to apply the HD ratio to determine the utilisation threshold at which an LIR can request an additional IPv4 address block from the RIR or NIR. At present, the utilisation threshold is 80 percent. The presenter explained that there has been significant feedback from several large networks in the region that the 80 percent rule disadvantages large ISPs, which maintain complex internal hierarchies to manage their address space. There is an overhead in maintaining a large network, which tends to have more service types and geographic diversity. The presenter provided examples of how the HD ratio would apply to solve this problem for larger networks and explained how the ratio is calculated.

The presenter noted that there have been many comments received on the mailing list. One comment received was that it may be easier to simply lower the exiting threshold to 70 percent. It was suggested that this rejects the overhead of maintaining a hierarchy. It was also suggested that lowering the threshold across the board may be too lenient to smaller networks. Other comments related to the suitability of the HD ratio itself and suggestions that the proposal may have an adverse impact on conservation.

Questions and discussion

There was a comment that an ISP's need for the boundary is time. It was suggested that a smaller ISP may need a lower value as time will run out more quickly for them. It was argued that the curve proposed may be the wrong way around. However, it was also noted that a smaller ISP with relatively small and simple requests is likely to have their requests dealt with more quickly. It was also suggested that the 80 percent rule imposes behaviour on large networks that they would not otherwise undertake.

A representative from JPNIC reiterated the view that several ISPs have expressed problems with applying for new allocations, but no such feedback has been received from large ISPs in Japan.

There was a question about the effect this proposal may have on projected IPv4 lifetime. It was suggested that because most delegations are not large, if past behaviour continues, then this proposal is not expected to have a significant effect.

There was a comment that the introduction of MyAPNIC may help ease problems relating to the timing issues that have been discussed.

It was explained that the HD ratio value proposed for IPv4 is different to the IPv6 value and does not have create a dramatic drop in the utilisation level for large networks.

A representative from ARIN clarified the ARIN position, suggesting that the proposal was rejected there not because of complexity, but because people did not perceive there was a problem that needed to be fixed.

A representative from KRNIC reported that some small ISPs feel the proposal would advantage large ISPs. However, it was suggested that many argue the current system unfairly disadvantages large networks.

There was a discussion about the rationale for having a utilisation requirement in the first place.

There was a comment that regardless of utilisation, ISPs with a genuine need for more address space are able to obtain it from ISPs.
- There was a suggestion that if the number of networks being disadvantaged is relatively small, then perhaps it is better to deal with the problem operationally.
- The Chair suggested dealing with various elements of the proposal separately. He asked for a show of hands on using the HD ratio. There was no strong consensus either way.
- There was a request for the Secretariat to provide more analysis of which ISPs are feeling there is a problem with the current 80 percent rule.
- It was suggested that it could take some time for the Secretariat to survey ISPs in an effective way. The Chair sought a second show of hands on the proposal, which brought a mixed response, tending to favour the proposal. The Chair then asked for a show of hands on who would like to see the proposal returned along with a survey of ISPs. The Chair noted that a majority of those supporting the proposal would prefer that there be a survey.
- It was argued that there would be no surprises to be revealed by surveying large members on this issue.

Action items

pol-18-001: Secretariat, with assistance from NIRs, to conduct a survey of ISPs' resource management practices, to allow better analysis of the issues.

This is a proposal to allow existing IPv6 address holders to expand their initial allocation, using their existing IPv4 infrastructure to justify an allocation larger than a /32. The use of IPv4 infrastructure to justify a larger initial allocation was passed at APNIC 17 (prop-016-v002). This current proposal allows networks that received an initial allocation before prop-0160-v002 to be given the same opportunity to receive an initial allocation greater than /32.

The presenter noted that there had been some feedback on the mailing list to the effect that this proposal is based on real requirements and that there are some ISPs who wish to expand their existing allocations.

Questions and discussion

There was a comment supporting the proposal, but asking whether requests for a larger allocation would require renumbering. It was suggested that ISPs would not want to take up this option if it meant they had to renumber. It was suggested that ISPs will be able to expand up to /29 without renumbering.

There was a question about the current practice for handling this kind of request. It was noted that there was a request received recently, which APNIC is evaluating using the current policy.

There was a suggestion that this policy does not seem to be addressing a real problem. However, there was an example given of an ISP in Japan that is designing a network that will require more than a /32 for an efficient architecture.

It was suggested that again this is about the trade-off between conservation and routing needs.

It was explained that this proposal is meant to address a lack of fairness for those who received their space early.

It was noted that there is very little actual use of IPv6 at this point, so proposals to allocate much larger blocks should be viewed with caution.

It was explained that new applicants are able to provide justification to receive allocations much larger than /32, but this option is not open for those hold early allocations.

It was suggested that this is proposal does not require a significant change to the existing policy.

There was a discussion of a hypothetical example that shows the reason for this proposal.

There was a question as to whether APNIC had ever denied an IPv6 address request. It was noted that there was a case where the situation was possible unde the literal use of the policy. That situation was resolved following an executive decision to interpret the policy broadly.

It was clarified that the policy fixes something which is literally different from the practice.

The Chair asked for a show of hands of the proposal. The Chair observed consensus in favour of the proposal.

Action items

pol-18-002: Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal to
expand IPv6 address space for existing IPv6 address holders, on the basis of a deployment plan or with IPv4 infrastructure, without satisfying the subsequent allocation requirements (prop-021-v001).

IPv6 address space management

This presentation attempted to model what the registry and routing status would be if the existing Internet development had taken place with IPv6 instead of IPv4. The presenter started by describing the IPv6 addressing structure. He noted that addresses are only valuable if they are routed, and routing is only worthwhile if works effectively. He noted that there is no clear knowledge how existing routing technology would handle a massively large network. Uncertainty as to the future of routing technologies drives the view for conservatism in address management and aggregation.

The presenter noted that the current size of allocations to RIRs restricts the ability of the RIR to ensure aggregation over an extended period. He sought to evaluate what allocation size would allow RIRs to sustain good aggregation over an extended time. He discussed the basic assumptions and methods used to examine this issue. The presenter showed an IPv4 to IPv6 equivalence table to show relative allocation sizes appropriate for various customer counts.

The presenter noted that if the RIRs were dealing in IPv6 now in the same way they deal with IPv4, they would each use a /20 every six months. However, he noted that IPv6 may have a higher customer count as there would not be NATs. If NATs are factored in, the RIRs would need a /12 for 12 months of operation.

The presenter discussed allocation algorithms, particularly the sparse allocation algorithm that has been discussed in the RIR communities. He discussed a modification to the sparse allocation algorithm based on considering the rate of growth of the LIRs, to reduce the amount fragmentation of address space. The presenter concluded that a large enough block over a long enough time can achieve the aim of protecting the routing system. He suggested a /12 for a 36 month period would be suitable.

Questions and discussion

There was a discussion of the sensitivity analysis that has been done. The parameter that makes the greatest difference would be changing the fixed 16 bit subnet.

It was explained that even the best sparse allocation algorithm will create a certain amount of dead stock at the end.

IANA global IPv6 allocation policy

This proposal is based in part on the results of the previous informational proposal. The presenter explained that this proposal would need to be approved through a global policy development process in order to be accepted. It will need to be approved by each RIR community then passed to the ASO for input into the ICANN process. This is the first region to consider this proposal.

The presenter described the current terms under which IANA makes IPv6 allocations to the RIRs. He noted that the current allocations are quite small and that this is sacrificing aggregation. The presenter noted that the policy for allocations from RIRs to LIRs stresses aggregation rather than conservation.

As background to this proposal, the presenter described RIPE 261, which was not adopted, and a follow up proposal in July 2003 requesting larger IPv6 allocations from IANA so that the RIRs could practice sparse allocations. The presenter noted the need to keep the process as streamlined as possible to avoid long delays.

This proposal draws on Geoff Huston's analysis and recommends that IANA should allocate each RIR a /12, to be used over a period of 36 months.

The presenter noted that he wished to withdraw the element of the proposal that recommended that IANA reserve a /6 for each RIR. He also withdrew the element recommending that with each subsequent allocation to an RIR its total holding would be one bit shorter than previously. This element is replaced with a recommendation that each subsequent allocation be in multiples of /8.

The presenter reviewed the main elements of the proposal: the initial allocation is a /12; the subsequent allocations are multiples of /12; IANA will allocate enough to allow the RIRs to operate for 36 months; and the RIR receives a subsequent allocation when it has used 50 percent.

It was noted that this proposal should have no administrative impact on the NIRs.

The presenter summarised the feedback that had been received on the mailing list. It was also noted that in the ARIN region, a community member has recently put forward a similar proposal. The ARIN proposal has also been forwarded to the LACNIC community. In the RIPE region, there has been a proposal that is identical to the original version of this current proposal.

Questions and discussion

The Chair suggested that the meeting should seek consensus on the individual elements of the proposal, but he first called for general comments on the proposal as a whole.

A representative of LACNIC clarified that a similar policy was proposed in the LACNIC community. There was also a question about the justification for changing the model for how subsequent allocations are made, basing it on percentage, rather than on a projection of usage. It was explained that this is intended to provide a simpler method.

There was a suggestion that the wording in the summary slide needed to be clarified to better match the proposal in terms of the RIR being eligible to request a subsequent allocation.

There was an explanation of the process that will need to be followed to get this proposal adopted globally. The presenter asked the Chair to consider, when seeking consensus, that discussions in other regions may require some amendments to this proposal.

It was noted that the large reservation recommendation would have allowed easy identification of the source on a regional basis. It was suggested that it would still be possible for IANA to implement a smart system of sparse allocation, even if this was not specifically proposed.

A representative of JPNIC spoke in support of the proposal, but asked for clarification from the RIRs that they felt a /12 was a sufficient amount of address space for three years. It was explained that the analysis that this proposal was based, did confirm that a /12 did gives a realistic chance of maintaining good aggregation. It was also clarified that the intention is not that a /12 should take three years to use, but that the minimum allocation should be /12 and the IANA should allocate to meet the three year needs of the RIR.

A representative of IANA agreed with the previous point and suggested referring to 'units of allocation' rather than 'minimum allocation'. He reported that ICANN and IANA are pleased to see this discussion taking place. He also agreed with Geoff Huston's analysis that focuses on the need for aggregation above that of conservation. He encouraged the use of past knowledge from the IPv4 world to be applied to IPv6 policies. However, he questioned the unqualified assumption of a /48 to be the standard assignment to all users. He encouraged input from the other RIRs in relation to allocation size to be proposed. Finally, he noted IANA's willingness to discuss with the RIRs IANA's practice in relation to making announcements.

In response to the assumption of /48 assignments, it was noted that this is drawn from existing Internet standards, which will not be able to be changed quickly. There was a discussion about whether /48 is a standard or not. It was noted that the IETF now considers it outside of their scope to declare that a standard. This is considered to be a policy issue. There followed a discussion about the definition of a site and the appropriate assignment sizes for sites.

The Chair thanked the sponsors, then called on Paul Wilson to continue his proposal from the previous day.

The proposal was again summarised. Under the proposal, IANA would make initial and minimum allocations of /12; subsequent allocations would be made in multiples of the minimum allocation unit; IANA should allocate enough to allow the RIR to operate for 36 months; the RIR qualifies for subsequent allocation when the allocated or reserved amount reaches 50 percent; IANA is to process requests according to the NRO and IANA agreed procedures; and communication should be from IANA to RIRs only.

It was again noted that as this is global policy, consensus on this proposal will mean that the proposal will then need to be discussed in other regions.

The Chair asked for a show of hands on the proposal being accepted with some degree of flexibility.

It was noted that it had been intended to accept comments on each of the elements.

There was a comment that there could be a possibility of separating the initial allocation and subsequent allocation units. It was suggested that there could be a large initial allocation, but a smaller allocation unit for the subsequent allocation units. This was argued to be based on consideration of expected IPv6 allocation patterns. It was suggested that there is expected to be a rapid initial uptake of IPv6, followed by a slower rate of continuing allocation. It was argued that a smaller subsequent allocation size could allow more flexibility.

It was noted that the growth rates may be different in different regions. It was argued that a consistently sized minimum allocation will provide the most responsible management. It was argued that changing allocation units is not an appropriate way to proceed.

There was a comment that there should be one minimum allocation size; however, it was asked why the size should be /12. It was suggested that /14 may be better.

It was clarified that there is no proposal for different regions to be given different allocation units. However, it was suggested that smaller allocation units allow greater flexibility in meeting the actual needs of the RIR.

There was an argument that the counter proposal does not take enough account of the needs of the routing table. It was argued that the smaller allocation units could lead to more fragmentation and that the problem could last for decades.

There was an argument that another way of interpreting the lesson from IPv4 is to avoid enormous fixed sized boundaries, which run the risk of creating an another swamp.

It was argued that if the allocations are distributed sequentially, there will be another swamp, but this could be avoided by using intelligent sparse allocation methods. Again the question was raised as to why the proposal looks to a nibble boundary.

It was noted that this proposal is about IANA giving the RIRs enough space to use sparse allocations to LIRs, so as to maximise the chances for aggregation.

There was a discussion of how to word the element relating to initial allocations. It was suggested that this is not a great concern as there will be only five of these.

The proposal summary was modified as follows:

Defined allocation unit (suggested size is /12)

All allocations should be in multiples of the minimum allocation size (suggested to be as a single CIDR block)

IANA allocations are made for a defined period (suggested as 36 months)

RIR qualifies for subsequent allocation when a defined amount is utilised by allocation or

reservation (suggested amount is 50 percent)

IANA to process requests according to NRO and IANA agreed procedures

Communication by IANA to RIRs only.

The Chair also asked the meeting to consider reaching consensus on this proposal, but with an eye to remaining flexible about changes to some details which may arise in the other regions. The Chair noted consensus to adopt this proposal, with more discussion of exact details to be held on the mailing list.

Action items

pol-18-003: Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to refer this proposal (relating to IANA IPv6 allocations) to the mailing list and to other RIRs, with the advice that the APNIC region has accepted the proposal in principle but remains flexible to the specific details of the main parameters.

IPv6 policy status from ARIN, LACNIC, RIPE and APNIC communities

The presenter reviewed the status of proposed IPv6 policy changes in the various regions.

ARIN has a current proposal to modify the allocation criteria so that requestors could be eligible if they are 'an existing, known ISP in the ARIN region or have a plan for making at least 200 /48 assignments to other organizations within five years'.

Changes have already been implemented in the LACNIC region, designed to encourage the use of IPv6. 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 routed this block within one year and customers in the LACNIC region should have access to the IPv6 services within two years.

RIPE NCC did begin discussing plans to clarify the language of the IPv6 policy; however, these discussions have revealed some support for actually changing certain aspects of the policy.

IPv6 policy update in APNIC region

The presenter reviewed the modifications made in the Asia Pacific region to the IPv6 policy document. The presenter also described the work of the IPv6 Guidelines Working Group, which produced an IPv6 Guideline Document, which is now available on the APNIC web site. The presenter noted the changes that have been proposed or made to the initial allocation criteria in other regions. He asked the community to provide feedback as to whether any policy changes are required in this region.

Questions and discussion

It was noted that it would be a good thing to clarify the language in the policy document itself. The JPNIC community will discuss this and, if necessary, raise proposals in the next Open Policy Meeting.

Unique Local IPv6 unicast addresses

The presentation was a report on some IETF standards activity in relation to unique local addresses. Unique local addresses are intended to be private addresses, but unlike IPv4 private addresses, they are intended to be globally unique (although there is no guarantee of that). A single pool of addresses is intended to be divided into /48 fragments. They are not intended to be routed or aggregated and will have no hierarchical structure.

There are two proposed ways of using the addresses. One is for a user to simply pick a prefix with no assurance of uniqueness. The other is to get an assignment from a central registry, that will pick a prefix at random. The second method will assure uniqueness.

The allocations of these prefixes are intended to be permanent, without any de-allocations, and paid for with a single, non-recurring fee. It is not intended to publish details of ownership. There will be a requirement for the registry to apply a method that will prevent individuals from hoarding addresses.

The presenter discussed the issue relating to these prefixes leaking into the global Internet. He also reviewed the current open issues in relation to this development.

Questions and discussion

It was noted that the document for locally assigned, self-selected addresses is close to being published. However, the centrally-assigned address description still has many open issues and it is uncertain when this will available.

There was a question about registry issues that are raised by the recommendations in the proposed standards. It was noted that these addresses may become a haven for spammers and hackers if they were ever able to leak to the public Internet. It was noted that this raises the issue of whether the standards body has moved beyond standards and into policy and implementation.

It was noted that the RIRs had provided some cautious support for the developments, subject to concern about the registration issues.

It was clarified that the original proposal was split in half. The self-selected specification is likely to be available very soon, but there is no likely timeline for the centrally assigned addresses.

There was a comment that with the size of the IPv6 address pool, there appears to be no reason to implement these standards.

There was a question as to the role of the RIRs in providing feedback. It was noted that the RIRs have provided comments to the IESG, but there has been insufficient detail for the RIRs to hear any actual proposals on supporting the standards.

This presentation continued a regular report on the progress of the large space IPv4 trial usage program in Japan, which is intended to promote IPv6 deployment activities. The presenters noted that participants in the trial are reporting that it is very difficult for them to eliminate their need for IPv4 infrastructure at this stage. The presenters provided brief case studies of several participants. They also discussed the introduction of an IPv6 Address Assignment Management tool.

The presenters noted that it is now necessary to reconsider the initial assumption that it would be possible to recover the IPv4 addresses from the trial participants by 2005. Although participants have reported that the IPv6 allocation policies are appropriate, technical issues remain that require the operators to continue running dual IPv4/IPv6 networks. The presenters noted that IPv4 space is being recovered from those who are not starting IPv6 services.

Questions and discussion

It was commented that because this project was always described as a trial, it is appropriate for it to be extended to meet the needs of the participants.

Status report on APNIC policy implementations from APNIC 17

The presenter explained the policy tracking pages on the APNIC web site and described the status of policy proposals implemented since the last meeting. The Secretariat has implemented the following proposals:

The Secretariat is due to implement the following proposals in the third quarter of 2004:

prop-007-v001 Privacy of customer assignment records

prop-004-v001 Lame delegation cleanup

The Secretariat is due to implement the following proposals in the fourth quarter of 2004:

prop-017-v001 Recovering unused address space

prop-018-v001 Protecting historical records in APNIC Whois database

Finally, the global policy proposal, prop-008-v001 IANA IPv4 resource request procedures, has now reached consensus in all RIR communities and was forwarded to the ASO for approval on 19 August 2004, to be then sent to the ICANN Board for ratification.

Questions and discussion

There was a question about whether APNIC had received any applications for IPv6 for unconnected networks. It was noted that APNIC did make one allocation in the past, but had received no more requests since the policy was modified

IPv6 address assignment size for end-users

Tomohiro Fujisaki and Toshiyuki Hosaka, JPNIC

This presentation described the practice for making IPv6 end-user assignments in Japan. The presenter noted that RFC3177 recommends assignment sizes. He noted that most major ISPs now offer IPv6 services. In general, the trend of assignment size is /48 for enterprise and /64 for residential services. The ISPs have reported that they make this distinction to differentiate enterprise and residential services. They also reported that they have not received any complaints from residential users. It was also noted that privacy concerns about public assignment registration are also a factor. The presenter reported that ISPs prefer to assign /64s dynamically. The presenter also noted that as there are so many /64 assignments, the initial allocation criteria may need to be reconsidered.

Questions and discussion

- There was a comment that if ISPs are assigning /64s because they feel the /32 is too small, then they should consider applying for a larger block. There was also a comment that there is a need to consider the effects of assigning multiple unaggregated /64s to customers.

Open action items

pol-17-001: Pending approval at each remaining stage of the policy proposal process, proposer to resubmit a modified version of the proposal (prop-013-v001) to the mailing list. The rewritten proposal will define multiple discreet networks and consider the HD ratio for sub-allocating address blocks.- Update (APNIC18): The Secretariat has discussed this with UUNET, who report that they wish to keep the proposal open, however the original proposer is no longer with UUNET.

pol-17-006: Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal to recover unused address space (prop-017-v001).- Update (APNIC18): This is in the process of being implemented and is expected to be completed by the middle of December 2004.

pol-18-001: Secretariat, with assistance from NIRs, to conduct a survey of ISPs' resource management practices, to allow better analysis of the issues.

pol-18-002: Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal to
expand IPv6 address space for existing IPv6 address holders, on the basis of a deployment plan or with IPv4 infrastructure, without satisfying the subsequent allocation requirements (prop-021-v001).

pol-18-003: Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to refer this proposal (relating to IANA IPv6 allocations) to the mailing list and to other RIRs, with the advice that the APNIC region has accepted the proposal in principle but remains flexible to the specific details of the main parameters.