You're viewing an archived page. It is no longer being updated.
RIPE 54
RIPE Meeting: |
54 |
Working Group: |
Address Policy |
Status: |
Final |
Revision Number: |
1.0 |
- content to the Chair of the working group.
- format to [email protected].
WG: Address Policy
Meeting: RIPE 54, Tallinn
Date: Wednesday, 9 May 2007
Time-1: 11:30 - 12:30 (GMT +0200)
Time-2: 14:00 - 15:30 (GMT +0200)
Chair: Gert Doering, Sander Steffann, Andrea Borgato (not present)
Minutes: Arno Meulenkamp
A. Administrative Matters
- Selecting (thanking) the scribe
- Approving the minutes from RIPE 53
There were no comments on the minutes. Approved, with thanks to the scribe.
- Agenda bashing
No comments on the agenda.
B. Election of a new AP Working Group Co-Chair
Hans Petter Hollen has stepped back from his position. Sander Steffann stepped forward as a candidate. There was no opposition and no arguments, so Sander Steffann was appointed co-chair of the AP Working Group. Congratulations Sander!
C. Statistics from the RIPE NCC Registration Services
Alex le Heux, (RIPE NCC)
Wilfried Woeber (University of Vienna) wanted to clarify that PI requests account for 2% of the address space allocated, but that there
are more PI assignments given out than PA, so 2% of the amount of address space accounts for more prefixes in BGP than the other 98%.
Leo Vegoda (IANA/ICANN) asked a question related to the graphs for ASNs. He asked why Ukraine seems to get a disproportionate amount of ASNs. The RIPE NCC has no real explanation yet, although the RIPE NCC is looking at what happens. It seems organisations in
Ukraine value independent routing.
Paul Wilson (APNIC) asked if there was a change in the PI policy that would account for the change in number of requests. Alex mentioned that there is no change in the policy, but simply that more requests are coming in. PI address space has a cost but it is part of the RIPE NCC Billing Score algorithm.
Daniel Karrenberg (RIPE NCC) commented on Leo's remark about the high number of ASNs in Ukraine. Daniel Karrenberg asked that reports about unusual patterns in resource allocation and registration should be augmented with information from Internet measurements in order to understand the causes of unusual behaviour. In particular, the RIPE NCC should make use of its own measurement resources for this purpose but not exclude other data.
Richard Cox (Spamhaus) agreed that that would be useful. Richard specifically asked for information on the consistency of the announcements of the ASNs given out. The amount of traffic seen from the Ukraine would make it a good candidate to check from where the prefixes are being announced. Specifically he'd like to know if the location from which it is being announced changes. This is something the "revolving door" theory suggests.
Action item on the RIPE NCC to give more indepth statistics.
D. Address Policy Proposals in the RIPE region
D.1 Concluded Protocols (overview)
2006-06: IPv4 Maximum Allocation Period
Concluded. Status: Accepted.
No discussion
2006-07: First Raise in IPv4 Assignment Window Size
Concluded. Status: Accepted.
No discussion
2006-04: Contact e-mail Address Requirements
Concluded. Status: Withdrawn.
No discussion
D.2 Ongoing Protocols (overview and discussion)
2005-08 : Amend IPv6 Assignment and Utilisation Requirement
Status: Review phase
No discussion
2006-02 : IPv6 Address Allocation and Assignment Policy
Status: Review phase
Jordi Palet Martinez (Consulintel) clarified the proposal.
There was some support for removing the "200" number from Wilfried Woeber (University of Vienna) and Bill Manning (ARIN). Tony Hain (Cisco) had no objections to removing it either.
There was some discussion on what exactly was meant with point 5.1.1.B - advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet. It left it unclear wether or not it more specifics could be announced or if only the aggregate could be announced. Gert Doering felt more specifics would be allowed, Tony Hain felt it wasn't clear. Bill Manning felt that probably Tony read 5.1.1.B wrong, but he felt that the "to be used on the Internet" was too vague. Announcing through a routing protocol? RIP? eBGP? He felt that the text in the policy forced people to work in a particular way that might not work for certain business models. Since this text was not changed from the existing policy, the point was dropped for now.
Tony Hain proposed 5.1.1.B should be removed, as it was operations related, not policy. Dave Wilson (HEAnet) did not agree, as the policy doesn't necesarily restrict itself to what RIPE NCC can enforce, but also about what operators can do. (filtering and such) He felt that even though the new text wasn't perfect, it was an improvement and it should move forward and get another improvement later on.
The proposal will be moved this to last call, point 5.1.1.B can be discussed at a later time.
Bill Manning wanted to go on record that he felt the policy, with a bad part, would detract from the credibility of RIPE.
That concluded the morning session. End at 12:25.
Continuation 14:00
2006-01 : Provider Independent (PI) IPv6 Assigments for End Users
Status: Discussion phase
Jordi Palet Martinez (Consulintel) clarified the proposal and the changes made since originally introduced.
The proposal did not clarify the status of PI holders and their contract with the RIPE NCC. Gert Doering (Spacenet) didn't want the definition to mention "ISP", but simply that the entity will not sub-allocate or assign to other entities. Carsten Schiefner (Deutsche Telekom AG) agreed as the term ISP is ambiguous. Wilfried Woeber (University of Vienna) felt that the "contract" part of the proposal should first be specified before the proposal could go further. With the removal of the "200" requirement from the regular IPv6 policy, this policy may not be needed anymore anyway. Max Tulyev (NetAssist LLC) asked for some specification to what "ISP" meant.
The size of the PI assignments was also discussed. Wilfried Woeber mentioned reserving a /32 from which a /48 would be assigned. Gert Doering mentioned that ARIN reserves a /41 instead of /32. Jordi Palet Martinez felt this level of operational detail should not get into the policy.
A last remark was made by Ruediger Volk (Deutsche Telekom T-Com) who pointed out that the "type" of company shouldn't be a criteria, as companies change what "type" they are, for whatever reason.
With this, the discussion was closed.
2006-05 : (IPv4) PI Assignment Size
Status: Review phase
Philip Langelund (jay.net) was not available. Gert Doering summarised the proposal.
Max Tulyev (NetAssist LLC) voiced his support for this proposal, as he felt the current policy forced people to lie. He proposed to remove the multihoming requirement, to simply allow a "globally routable block" of a /24.
Wilfried Woeber (University of Vienna) had some issues with the proposal:
1. What are the exact requirements? How are those requirements checked? Are they rechecked on on ongoing basis?
2. This proposal might recreate the swamp issue again, which would be bad.
3. It would make using PI more advantageous than using PA for addressing needs, which isn't in the community's best interest.
Wilfried proposed to put the proposal on hold until issues surrounding a contractual relationship between PI recipients and the RIPE NCC have been resolved.
Leo vegoda (IANA) felt that removing the multihoming requirement would effectively make the minimum assignment size a /24, as everyone would want that. As to the proposal as it was, he wanted information from experiences by APNIC and ARIN as to how things went after similar proposals had been accepted in their regions.
Piotr Strzyzewski (Centrum Komputerowe Pol. Sl.) felt that taking out the multihoming from the proposal would be bad, it would effectively allow the behaviour for which people now still have to lie.
Gert closed the debate on this topic concluding that the discussion was no where near consensus.
2007-01: Direct Internet Resource Assignments to End Users from the RIPE NCC
Status: Discussion phase
Nick Hilliard (INEX) was not there. Gert Doering summarised the proposal.
Max Tulyev (NetAssist LLC) did not support the proposal, even though he agreed to the goals of the policy. His point is that contracts in the former USSR with a foreign organisation are so hard that it would be better to allow, for instance, making a contract with the LIR that arranges the address space. Gert Doering clarified that the contracts issue will need a lot of thought and work with the RIPE NCC Board.
Leo Vegoda (ICANN) and Wilfried Woeber (University of Vienna) supported the proposal, both for helping to get correct contact info in the RIPE Database as well as making reclaiming PI address space easier. The contract situation in the former USSR (and possibly other places) is an issue, and proper legal advice is needed.
Raymond Jetten (Saunalahden Serveri Oy) felt that this proposal seemed like it was selling IP addresses and that this should be addressed. Paul Wilson (APNIC) mentioned that in the APNIC region contracts were changed for anyone that got resources from APNIC. There weren't any real issues. And the clarity of the policies helps in clarifying wether or not addresses are being sold.
With that Gert Doering closed the discussion on this topic.
2007-02: Change in IP Assignments for Anycasting DNS Policy
Status: Discussion phase
Tobias Cremer (Cable & Wireless) clarified his proposal.
Peter Koch (DENIC) felt that while there was no doubt that other operators than ccTLD operators might need anycast addresses, it would be hard (if not impossible) to set good criteria. He also felt this policy would open the next round for people that want multiple anycast clouds and so on. Ruediger Volk (Deutsche Telekom) mentioned that the proposed policy for a minimum of a /24 PI for multihoming would also cover the need that this policy addresses.
Jim Reid wondered why should anycast be limited to DNS, and not used for anything else? He wondered what would happen if people got addresses through this policy and then changed what they did with the address space.
With that the discussion was closed.
2007-03: IPv4 Countdown Policy
Status: Discussion phase
Akinori Maemura (JPNIC) clarified his policy proposal.
There was a lot of opposition to the proposal. Jordi Palet Martinez (Consulintel) did not like creating artificial measures to exhaust the pool of available addresses. He felt that this policy would go against the policy development model which assumes that any policy can be adjusted later on. Tony Hahn (Cisco) mentioned that we might already be within the two year window that this proposal mentions, which means it is too late to implement now. Alain Durand (Comcast) cautioned that since all predictions point in the same direction, they might all be wrong. He suggested to to reserve some address space for renumbering, as otherwise the number of small prefixes being announced might grow a lot, causing possible routing issues.
Akinori-san mentioned that termination of allocation might be taken out of the proposal. An alternative might be a stricter allocation regime. Ed Lewis (NeuStar) mentioned that one of the good things of this proposal, even if it wouldn't be accepted, is that it made him (and presumably others) think about what needs to be done. He was glad the issue was addressed. This sentiment was widely shared.
Gert Doering concluded that this proposal would probably not get consensus.
2007-04: IANA Policy for Allocation of ASN Blocks to RIRs
Status: Discussion phase
Axel Pawlik (RIPE NCC) presented the proposal.
Gert Doering (SpaceNet) suggested larger pools for 32-bit ASNs. Geoff Huston (APNIC) did not want this, as there were no aggregation benefits for AS numbers. He felt that requesting regularly from IANA meant that checks on registration and policy would be performed regularly, which would be a good thing.
Leo Vegoda (IANA) mentioned that this policy would be easy to implement, as it was based on current practice.
Gert Doering mentioned he would like the larger blocks as it would allow him to see roughly where traffic came from, based on the AS Number. This caused some upheaval in the room, where opposition to this was voiced from several people at once.
Gert Doering then closed the discussion, declaring rough consensus for the policy as proposed.
D.3 NEW proposals since R53 (presentation and discussion)
Informal Proposal
Piotr Strzyzewski (Centrum Komputerowe Pol. Sl.) introduced his proposal to change the IPv6 policy. The issue is that some LIRs have two seperate networks but it is not possible to get 2 IPv6 allocations, nor is it possible to deaggregate to 2 /33 announcements, as filtering is done on /32 boundaries. The proposal is to make it possible to get an extra allocation under certain circumstances. Jakub Jermak (Centrum Komputerowe Pol. Sl.) clarified that the blocks for routing were the issue, not the number of ASNs.
Gert Doering mentioned a policy in the ARIN region for discrete networks ( http://www.arin.net/policy/nrpm.html#four5 ), which might be used as a starting point for making a policy in the RIPE region.
Wilfried Woeber suggested this issue could be solved through routing, possibly with a BCP document from the routing-wg. This would mean that address space would be conserved too. Gert mentioned that conservation was not an issue in IPv6, especially since not many networks would be in this exceptional category. Fernando Garcia (Tecnocom Telecom y Energia) felt there wouldn't be enough LIRs in this situation to set up a special policy.
Leo vegoda (ICANN), wondered why two different businesses used just one LIR. He suggested in this case the one company could be two LIRs.
Gert Doering summarised that the proposal still needed detail and clarification to get it to a point where it could be considered.
2007-05: IPv6 ULA-Central
Status: Discussion phase
Jordi Palet Martinez (Consulintel) clarified the proposal.
There was some clarification by Heather Schiller (Verizon Business and ARIN advisory council) that ULA was not sufficient for the "micro-allocation for internal infrastructure" policy, so it should not be referenced for this policy. Ray Plzak (ARIN) mentioned that this policy was based on an IETF draft, which is not a good basis for a policy.
With that the discussion was closed.
Z. AOB
End of session.