You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
63 |
Working Group: |
Address Policy |
Status: |
Final |
Revision Number: |
1.0 |
Session I – 2 November, 9:00 – 10:30
A. Administrative Matters
Gert Doering (WG chair) opened the session and presented the agenda. There were no changes in the agenda. The WG chair thanked the scribe and introduced both of the APWG co-chairs.
The minutes from RIPE 62 were approved and are now final.
B.CurrentPolicyTopics- Emilio Madaio, RIPE NCC
Emilio Madaio (RIPE NCC) gave an overview on the common policy topics being discussed in all regions with a summary of the policy proposals in the RIPE NCC Service Region since RIPE 61.
The presentation is available for download at:
http://ripe63.ripe.net/presentations/118-CurrPolTop-RIPE63-Final.pdf
No questions were asked.
C.PolicyDevelopmentOfficeActivities – Emilio Madaio
The presentation is available for download at:
http://ripe63.ripe.net/presentations/117-PDO-Activities-RIPE63-Final.pdf
Emilio Madaio (RIPE NCC) gave a presentation on all the activities that were taking place in the Policy Development Office and with Registration Services and on co-ordination with the community.
D.FeedbackfromRIPENCCRegistrationServices – Alex Le Heux
Alex Le Heux (RIPE NCC) gave the Registration Services Department report on all implemented policies and issues or unintended side effects which showed up during implementation. He also highlighted that not all policies were easy to implement.
The presentation is available for download at
http://ripe63.ripe.net/presentations/102-rs-report.pdf
No questions were asked.
Gert Doering thanked Alex for the presentation which also included statistics on the run-out fairly analysis as this allowed the community to see the results of the policy implementation. He also expressed his happiness about the fact that communication was working better. Alex Le Heux agreed.
Gert Doering gave an overview on how the Address Policy session works: discussions are made here and feedback is gathered but the final decisions take place on the mailing list.
E. Discussion of open policy proposals, part I
Sander Steffann volunteered to give an update. He stated that the proposal was in Last Call and had received some concerns and comments on how it would affect the routing table. He further added that the working group chairs decided to conclude the Last Call and gave recommendation to other WG chairs as they would need to verify if the process was followed properly and could conclude if there has been consensus. Furthermore, he talked about the discussion to limit the number of PI assignments to be made according to this proposal. The WG chairs decided to work with the people who had comments regarding this to come up with a new proposal to address those points and that was the best way to move forward. He also added that they were waiting for the results from the other WGs to see if there had been consensus or not.
James Blessing (Limelight Networks) commented that from what had just been said, it implied that there had been consensus on removing the multihoming requirements and he did not think there was any point following up with other proposals if the first one would not pass.
Sander Steffann responded that the chairs did think there was consensus and also referred to Mikael Abrahamsson's comments on the mailing list who specifically suggested there was a need to conclude this proposal and call consensus.
Gert Doering added that it is a tough call and the PDP is not very clear about what is consensus and that it does not need everybody to agree.
James Blessing continued that he did not think it was a good idea and that it should not be done.
Sander Steffann thanked James for the comments and responded that it was not up to them to decide and they would see if the other chairs would agree. He further added that they did weigh the various options and finally chose this one as there was a strong demand for it .
Gert Doering added an action item on the AP WG chairs that they will summarise the thoughts behind this decision and send to the mailing list for explanation.
Gert Doering also said that he did not want to continue discussions on this policy but wanted to move forward to the next policy proposal, 2010-04, discussions.
Jan Zorz (Go6 Institute Slovenia), one of the co-authors of this proposal gave the presentation. He added that the other co-authors, Mark Townsley and Jordi Palet, were unable to attend the meeting. Ole Troan (Cisco), another co-author and a 6rd specialist, accompanied Jan on stage to explain certain technical details behind 6rd as there had been questions which kept on coming up several times about this on the mailing list.
The presentation is available for download at:
http://ripe63.ripe.net/presentations/119-zorz-2011-04-proposal.pdf
Ole Troan (Cisco) took over to explain further the technical details of 6rd and commented on why operators did not want to consider multiple 6rd domains. He also referred to his previous explanation on mapping made during the IPv6 WG. He added that this was basically the same kind of scheme.
The presentation on mapping can be downloaded at:
http://ripe63.ripe.net/presentations/40-RIPE63-MAP-lightning.pdf
Gert Doering thanked the authors for the presentation and reminded the attendees that, during the last RIPE Meeting, the WG decided that they did not want a special policy for 6rd but rather a more liberal policy on allocation size. They did not want to tie the discussion too much to 6rd, it is just one of the incentives to change the initial allocation size. He then invited discussion.
Jan Zorz remarked that they could move forward but he wanted to be clear on the mailing list that he personally would never deploy 6rd in their country. They were just trying to fix issues coming back from the community, operators and real life. They had seen that not giving out /29 was an obstacle to deploying IPv6 as a service.
Ragnar Anfinsen (Altibox AS) supported this proposal and commented that for him, an operator with multi-domains, many prefixes would help them to do their stuff. He added that for them a bigger size would be great to do their things properly and did not care much whether it was a 6rd special proposal or not.
Gert Doering mentioned that this was what other operators on the mailing list had stated. They said that they would not deploy 6rd but would appreciate an easy way to increase their allocation size as there were more benefits to having a larger allocation than just 6rd.
Jan Zorz remarked that the /29 space was actually reserved for the operators so he asked why we should not just let them use this space.
Andy Davidson (Hurricane Electric) also gave his support stating that was a great idea and the default size /32 should be kept unless people asked for more and it should not be tied to any technology.
Gert Doering added that it was a very clear direction from Andy Davidson. He asked for arguments against it. He also added that there could be valid reasons to re-consider this proposal, therefore if anyone had concerns against it then they should bring it up.
Raymond Jetten (Elisa Oyj) expressed his support for this proposal but wanted to know more on how to get address space more than /29 and whether the same rule would still be applied.
Jan Zorz replied that the HD-ratio would still be applicable.
Gert Doering asked Raymond if he was referring to the initial or additional allocation.
Raymond confirmed that he was asking about additional allocation.
Gert Doering remarked that this proposal was not going to modify the criteria for additional allocation.
Raymond further added that this was what he wanted to know.
Ole Troan remarked that this was a good point to bring up and there was no need for any special policy for 6rd.
Sander Steffann commented that at the moment the initial allocation size does not take the HD-ratio size into account and was smaller than what you would get with the HD-ratio. That fixed one of the problem as now the RIPE NCC would look at the number of customers and not at the ratio for the initial allocation.
James Blessing (Limelight Networks) asked for a clarification. He asked if he would get /29 now if he already had /32 and if the policy would include the ability for every LIR to do that.
Gert Doering replied that the RIPE NCC reserved /29 and this could be used.
Jan Sorz added further that renumbering would not be required and Gert Doering agreed.
James Blessing (Limelight Networks) asked if the part regarding 6rd would be deleted from the proposal.
Gert Doering replied that there was nothing like it was for 6rd or not.
James Blessing asked if the request for any purpose could be made by anybody.
Gert Doering said that you could just go and ask the RIPE NCC for it as you needed more address space. The new text stated that you had considered the options and you would have to tell them you want more and this would not be sufficient.
Jan Zorz remarked that you did not need to say why you would need more address space. If you asked for it and you would get it.
Gert Doering added that no additional documentation was required. If you had no idea you could get a /32 and if you wanted more than that, the specific text would allow you to get you more.
Jan Zorz said that the space was there and would not be used by anyone else.
Gert Doering commented that it would be there unless the RIPE NCC ran out of IPv6 addresses.
Gert Doering thanked everyone for their input and that they now had clear guidance. He added that there would be textual change that would be sent to the mailing list for discussions and then would move to the review phase. He commented that Emilio Madaio (RIPE NCC) would tell him how to get it right.
Session II – 2 November, 11:00 - 12:30
Gert Doering welcomed everyone back to the next session.
The video on the RIPE Policy Development Process which could not be played during the previous session was shown.
The video is available at:
http://www.youtube.com/watch?v=-LfrRjQUomc
After the video, Gert thanked the RIPE NCC for producing it. He then presented the next items in the agenda.
F.Discussionofopenpolicyproposals,partII
The policy proposal can be viewed at
http://www.ripe.net/ripe/policies/proposals/2011-05
Andy Davidson (Hurricane Electric) explained that that the reason for writing an IPv4 policy when IPv4 address space was running out was mainly to allow new Internet Exchange Points (IXP) to emerge as well as allowing existing ones to grow as these things would affect the quality of development of the Internet in general. He further added that they would like to do lot of work in encouraging the community to organise themselves to build more IXPs where it did not exist and this proposal aimed to reserve a /16 from the final /8 which the RIPE NCC would assign exclusively for IXP peering LANs. He stated that the policy was open and this had received large amount of support on the mailing list and that an IXP that was running out of space could get extra address space by handing back their existing addresses.
He also mentioned that during the last meeting in Amsterdam, there were discussions in the EIX working group to look for technical measures which could be used to avoid this policy like using RFC 1918 space, unannounced space, using IPv4 prefix exchange over IPv6 transport. However, all measures still needed IPv4 address space. This work received rigorous technical appraisals and is receiving a rigorous policy appraisal. He then asked for feedback and comments from the floor.
Will Hargrave (LONAP Ltd) supported this proposal and added that they needed this space for the future of IXPs and the development of the Internet.
Maksym Tulyuk (AMS-IX) came forward to support this proposal and added that his IXP migrated from /23 to /22 and they had already used 80 addresses from the new block.
Andy Davidson informed the attendees that there had been much discussions in other WGs and there had been strong support on the mailing list as well as the normal policy process was being followed and if anyone had further comments he could be contacted during breaks or lunch.
Gert Doering added that there had been an amazing amount of support for this proposal on the mailing list. However, there were comments about the wording to be much more explicit as this could be obvious to an IXP operator but not to the RIPE NCC IP Resource Analysts who might never have seen an IXP.
Gert ended the discussion stating that as there were no objections seen in the room and there seemed to be clear guidance and strong support for this policy on the mailing list, he asked to move forward with the textual changes.
K.on(Inter-RIR)transfers – Dave Wilson (HEAnet)
The presentation is available for download at
http://ripe63.ripe.net/presentations/95-davew-inter-rir-transfers.pdf
At the end of the presentation, Dave Wilson invited the audience to discuss about the three main questions that he had for the community:
Gert Doering thanked Dave Wilson and suggested that we should take each question one by one.
Dave Wilson repeated the first question and asked the community if they feel any constraints regarding the transfer policy on how it was going in other regions.
Commentsfromthefloorregardingthefirstquestion:doesanyonehaveconstraintsagainstaneed-basedtransferpolicyinthisregion?
Remco Van Mook (Equinix) felt that it would be good to reiterate the explicit limitations of the current transfer which allowed unused allocations from an LIR to an LIR only and it would be good to have a look at it at all issues including inter-RIR transfers that were not possible and removed those limitations.
Rob Blokzijl (RIPE Chair) commented that when IPv4 address space has run out and there would be a strong demand for it, transfers would happen and if policies were too complicated then people would lie or not inform the RIPE NCC. He added that as a community, we must keep one strong requirement for this policy: the transfer should be reflected in the registry. We should keep track of where the addresses are and not how they came there. He finally urged for a sense of realism in this region.
Sander Steffann then responded if he understood Rob correctly then by removing restrictions, it would not be possible to receive address space from the ARIN region and the community should be considering that as ARIN was imposing it.
Rob Blokzijl added that there are five RIRs with five different sets of local policies and the RIPE region was not forced to follow any policy which was not realistic and that people would find a way from ARIN to transfer to our region.
Sander Steffaan remarked that the RIPE region would be registering blocks which ARIN would still be registering and he could see problems but he suggested to discuss this later.
Rob Blokzijl responded that these were detailed individual observations and we should not be making general rules on hypothetical concerns.
Remco Van Mook informed about a legacy block of about 1 million addresses which was transferred to the Netherlands last week. This is outside the current transfer policies we have. He said that it was considered to be a good thing for legacy space to be added to the pool of addresses which could be moved around and he did not want to argue against the pros and cons for a needs-based policy but he insisted that restrictions should be removed.
Paul Wilson (APNIC Director General) thanked Dave Wilson for the report which stated what happened in the APNIC region very well. He added that the community in the APNIC region would be looking for address space in other regions as APNIC has very little left. He also added that in his opinion the policy change they made was related to what was happening in ARIN, who is keeping the needs-based requirement in their inter-RIR transfer policy proposal. He stated that he does not believe that the needs-based requirement will cause the black market. At APNIC they have always been applying the needs basis on the normal allocation procedures and their members were happy to demonstrate their needs and get their addresses this way. If the system did not have worked then they would have already seen the evidence of a black market.
Rob Blokzijl responded about how people have happily followed the needs-based policies before: they had the choice to either follow the rules or get nothing. He added that what was being discussed was slightly different. It related more to two parties discussing shifting address space and a third party coming in with the strange requirement of demonstrated need. He thought this situation was different and expressed his availability to discuss it further offline.
Gert Doering agreed that this specific bit should be discussed at another time.
Grespan dos Santos Tacio (Private individual) wanted to understand more on the role of the ROA in transfers.
Gert Doering answered that certification was an interesting subject and if it was implemented and subsequently the ROA, then the status of the registration would be reflected in the RIPE database. If you had it registered in the database, you would get a certificate and then a ROA. If you didn't register it then no ROA.
Grespan dos Santos Tacio further asked if you could track down where prefixes were.
Gert Doering confirmed so.
Gert Doering then wrapped up discussions on the first question and concluded that there is a need to revisit the transfer policy and then see what would come out of it. He asked if Remco van Mook would like to volunteer to work on this again.
Remco Van Mook pointed out that before a new policy proposal was written by anyone, some guidance should be received from the community on those restrictions that are unnecessary and need to be removed. He reminded the attendees that back in 2007 when the transfer policy was written, it went round in endless circles.
Gert Doering agreed that discussions should be started and then the text should be written.
Commentsfromthefloorregardingthesecondquestion:WastheresomethingspecialwhichneededtobedoneintheRIPEregiontoaccepttransfersfromotherregions?
James Blessing (Limelight Networks) asked if there was a need for an inbound transfer proposal to cope with transfers coming in the RIPE region as mentioned by Dave Wilson.
Alex Le Heux (RIPE NCC) replied that it may depend on the type of transfers and its implementation and added that there had been various projects between RIRs to transfer legacy space.
James Blessing (Limelight Networks) said that it was still not clear if we would need a proposal or not and if all had been sorted out.
Alex Le Heux (RIPE NCC) replied that it might depend on how transfers are implemented on the other side as well. There had been inbound transfers of address space without a policy. If it could fit under these principles then we would not need a policy but there could be situations where we would.
Dave Wilson asked that people clarify if anything was broken before deciding to fix it as he was not sure if anything was broken.
Gert Doering replied that as it was not clear whether we would need an inbound policy or not, therefore he would like to include this as an action item on the RIPE NCC to determine if the organisations were happy with what they had or would like to have a written proposal approved by the community.
Gert Doering proceeded further with the last question: “If the community wanted to have a transfer away policy”. He commented if the community wanted to spend more time on this and gave an example where a European company would have a daughter company in the APNIC region and they would want to transfer resources to it and document it properly. He added that due to company relations, this could happen.
James Blessing (Limelight Networks) asked if there would be a transfer policy, there should be the option of global relations between RIRs because, for example, the company he works for just divested themselves of another company. Potentially, they could transfer address space outside of the region.
Dave Wilson added that the address space holder changing ownership could be seen as a corner case. If it was clear, we all would agree for the right thing to happen. If two unrelated entities wanted to sell or buy space then we would need to think hard about it. Any conclusion about not letting them do it need also needed more thought.
Rob Blokzijl replied to the previous question by stating that the only thing the RIPE NCC or this community was selling was a properly maintained registry that is used and would be used in future to take routing decisions and other types of decisions and it was in everybody interest that we could track these addresses. We should not make complicated transfer policies as there are no instruments to enforce it and this would result in our registry becoming less valuable.
Gert Doering concluded that there was a clear need of more discussions on the mailing list and depending on that, a decision would be made about whether inter-RIR transfers should be facilitated. He further thanked Dave Wilson for his input.
M.IPv4MaintenancePolicy – Rob Blokzijl, RIPE Chair
Rob Blokzijl presented the next point on the agenda without using slides. He explained that he had been working on for a couple of months with the RIPE NCC. He stated that in two years time, once there is no more IPv4 address space to allocate, all IPv4 allocations policies would become historical. The only relevant ones would be the small special purpose policies such as the reserved space for start-up ISPs or growing IXPs. The thought behind this policy is to have a single document describing the IPv4 registry and the remaining few policies in place like the allocation of specially reserved blocks or transfers etc.
An exercise was carried out to find the parts of the various policies which would still be relevant in two years time. He noticed that there was problem in trying to compile all parts together and it was not easy to understand them when put together. He thanked the RIPE NCC's Communications Department for the good work in making all text into one consistent document from which this new detailed policy proposal appeared.
Rob Blokzijl mentioned that all discussions that happen during the week would be incorporated in the document and would be published on the mailing list but not as a policy proposal as he would rather gather the input from the community. He also gave an example of sentences used in various policies and procedures but these were not specified in any policy. He emphasized keeping the focus on the RIPE NCC's central role as a registry for IPv4 in two year's time and to keep the registry in order. He further added that this document was not a defined document for transfer policy but a document for the maintenance of IPv4.
He explained about the different statuses of address space over the past 25 years and that, in the next generations, such things would not be reflected at the registry level. For example, we will cease to differentiate in principle between PA and PI space or a special role for legacy that would exist.
He concluded with a message to the community by requesting them to keep an eye on the AP mailing list for this document describing the full spectrum of all issues related to IPv4 space. He asked the community to read it carefully and see what would be crucial and important to them in two-five year's time.
Remco Van Mook strongly supported Rob's effort and said that the IPv4 allocation policy would not change down the line over few years, therefore we need to clean it up and remove any mess now.
Heng Lu (Outside Heaven) commented that difficult rules should not be made for transferring outside of the region and organisations should be obligated to register their information properly in database.
Gert Doering thanked Rob Blokzijl and the RIPE NCC for this work.
N.OnRenumberingIPv6networks – Shane Kerr
[report from the discussion in the IPv6 WG on Tuesday]
Shane Kerr summarised the discussions from the IPv6 working group regarding renumbering IPv6 networks.
The presentation made during the IPv6 WG is available at:
http://ripe63.ripe.net/presentations/111-ripe63-renum-02.pdf
He talked about the work that is currently going on at the IETF and how this was related to policy and technology recommendations for renumbering and also the difficulties associated with renumbering.
There hadn't been any output from the working group but the discussions will be moved to the mailing list. At the next RIPE Meeting there will be something more specific on this matter.
There were no questions asked.
Gert Doering concluded by emphasising how renumbering could be hard for some networks and that knowing about these facts would help in having less heated discussions. He also encouraged everyone to join the IPv6 mailing list.
O.OnCertificates- from the AP WG Chair
Sander Steffann summarised the path of policy proposal 2008-08. He mentioned that, at some point, the community wanted to have Certification (RPKI) in place and this should be discussed. The RIPE NCC had a budget and started working on it. Discussions took a long time and consensus was almost reached during Last Call but then concerns were raised about its dangers and consequences. This resulted in the proposal being withdrawn but with the RIPE NCC already having a working Certification system in place. Later there was going to be discussion in the RIPE NCC's General Meeting about whether the community wanted the RIPE NCC to spend money on this project or not as it was unclear whether the membership supported the activity or not. He also added that 700 organisations were already using it and the mailing list was quiet, with no mention about the certification system. He further stated that they were in a difficult situation as people were opposing and asked what should be done. Sander asked the audience to speak its mind.
Rob Blokzijl asked for clarification on one sentence, which stated that the RIPE NCC was doing something and there was no policy in place. However, he added that the certification is an IETF standard and that requires a CPS (Certification Practice Statement). The CPS describes the necessary policy. He directed the community to find out more at ripe.net/certification.
Ruediger Volk(Deutsche Telekom) commented that he wanted RPKI (certification) for all resources as soon as the relationship to the holders can be ascertained and he also voiced that he would like all operators to do this and agreet that RPKI is necessary. Additionally, he remarked that the community had manoeuvered itself into a situation where creating detailed influence on how things were handled had got lost. This is be a bad thing and we need to figure out how to fix this again.
Sander Steffann asked Ruediger Volk if he would be ready to formulate a policy proposal for this.
Ruediger Volk confirmed that if there would be a need then he would.
Rob Blokzijl clarified to the community that there was no need for a RIPE policy document for certification as it is in the CPS and this was already documented.
Immo Wehrenberg (rrbone) stated that RPKI technically should not be rolled out now. But the idea to build the system to issue RPKI is good and the RIPE NCC should continue doing that. However, we should not implement it in the RIRs because there was no good way to do this right now and there were strong issues which would be major show-stoppers. If people rolled it out in the architecture in the state it is now, it might cause major problems later which might not be fixed easily. We should wait for the technology to be ready to be rolled out in other ways.
Nigel Titley (RIPE NCC Board and author of 2008-08) came forward to clarify one point. He said there is a clash of policies. The transfer policy requires blocks to be digitally signed to allow the transfers and this implies the existance of a RPKI system. There is also the mandate from the community to the RIPE NCC to work on certitification. On the other hand, there is no consensus on proposal 2008-08. He further added that there would be motion voted on during the RIPE NCC General meeting; either the RIPE NCC would need to stop all RPKI related work or would be asked to continue RPKI but switch off the ROA generation.
Sander Steffann asked what would happen if both motions are not accepted.
Nigel Titley replied that the RIPE NCC would then continue doing what it had been doing.
Wilfred Woeber (Vienna University) commented that digitally signing and certifying the rightful users of a resource was a good thing and this is one of the RIPE NCC's core services. He added that it was not always possible to follow what the IETF had been doing and some of the RFCs are not applicable to the operations of the RIPE NCC. Therefore, he fully supported the case to develop a policy statement regarding handling the RPKI system for certifying resources. The community should go ahead and discuss what to put into a policy as a mandate to RIPE NCC on how to properly do that, more than merely pointing at another document outside the RIPE Policy Development Process. He also confirmed that he did not read the most recent version of the CPS but he stated that the quality of the document would not stand up in a security environment. He finally added that ROA were not policy issues and did not have to be discussed here.
Randy Bush (IIJ) said that he could not understand why CP (Certificate Practice) was being mentioned in the Address Policy WG session which is about address allocation and not about ROA. He also added that the people who have been working on this technology had not educated people properly because they created mis-communication and confusion.
Sander Steffann asked if Randy was suggesting to move discussion to the RIPE NCC Services working group session.
Randy Bush replied that what to do with RPKI or not is a RIPE NCC service issue and whatever policy the RIPE NCC would be using when issuing certificates was not an address policy matter. He added that what the RIPE NCC is legally guaranteeing should come from the Executive Board.
Lutz Donnerhacke (remote participation) stated “RPKI models the need for hierarchical system using the wrong technical solution and he would like to step back to think again about the use cases and the real requirements before choosing a solution."
Richard Barnes (BBN Technologies) wanted to make an analogy of another security technology which was deployed by RIPE NCC. He said that after TLS protection was implemented on the http access on the RIPE Database, it was then discussed in the Database WG. He supported Randy Bushs' suggestion about the RIPE NCC Services WG being more appropriate for the discussion and finished by saying that it is not a change of policy but rather how to protect the information given that it was already there.
Rob Blokzijl agreed with Randy Bush's comments about discussing these topics in the RIPE NCC Services WG or maybe even the Database WG. He also stated that he feels that people do not understand the role of the RIPE NCC: the RIPE NCC is keeping the registry. The certificate only shows that a number block is kept in the registry, it does not say by whom. If people want more details they must look in the registry. People can decide what to do with the certificate: they can generate ROAs with the help of the RIPE NCC or, locally, without it. They can even not generate the ROA and use the certificate when they will sell resources. He said that if the RIPE NCC members decide to stop the work on certification and in the future something new would come up which could only work with certificates or ROA, then the community would have to bear the consequences of ill-thought decisions.
Sander Steffann concluded that there had been objections against the ROA but did not see oppositions to certificates themselves and added there should be discussions whether we would need a policy for that and in which working group that should be discussed.
Gert Doering thanked everyone for the discussions and made a few remarks regarding the RIPE NCC General Meeting that would happen later that day. He spoke about the new charging scheme that would be discussed later and highlighted and urged every RIPE NCC member to have a look at it and exersize their right vote on it because address policy is influenced by the charging scheme.
Session III - Thursday, 3 November, 9:00 — 10:30
Gert Doering welcomed the attendees in the second session of the Address Policy WG and presented the agenda, which mainly consisted of IPv6 PI/PA Unification and the open policy hour. He added that Kurtis Lindqvist would discuss on a new RFC from the IETF which could have an impact.
R.OnIPv6PI/PAUnification-GertDoering(WGChair)
Gert Doering started the discussion on how the IPv6 PA/PI policies could be reworked in a fundamental way to better fit the needs of all IPv6 Users.
This presentation is available for download at
http://ripe63.ripe.net/presentations/143-wg3.pdf
James Blessing (Limelight Networks) thought it was a good idea and that the proposal made sense but he had a comment regarding the charging scheme: in his opinion it would unlikely be changed after the outcome of the RIPE NCC General Meeting.
Gert thanked James for his input.
Immo Wehrenberg (rrbone) commented that it was a good idea and they should continue that way.
Nina Bargisen (TDC) commented that it would be very difficult for her to explain this to her end customers. For some of the PI it's all they have been seeing. Telling them this change is going to be a very difficult task .
Gert Doering responded that there had always been confusion between using PA and PI in the ISP world and asked Nina if keeping the same policy and having a text on PA and PI would make life easier.
Nina Bargisen (TDC) answered probably not.
Sascha Luck (Cork Internet Exchange) supported by stating that this was an excellent idea. He added a comment about the RIPE NCC General Meeting on the day before: the fact that there are over 7,000 LIRs and 300 of them voted. This clearly showed that there are a lot of LIRs that do not really want to be LIRs. They are just LIRs because they have to be. The downside of this is that if these people are not LIRs anymore the fees of the actual LIRs will go up again.
Geza Turchanyi (INFO-IPv6 KFT) said he was unable to understand two arguments which were not emphasised sufficiently: one was about routability and the other was about the aggregation of Internet numbers that are allocated as multiple blocks to the same customer.
Gert Doering replied that he was not trying to hand out more blocks and that aggregation and routing were on his mind. He was of the opinion that today people who needs a routing table slot can get one, even if they have to become LIRs. He also added that he found it unfair if the amount of money you invest in your numbers is relevant on what you can do with your numbers. Something else he would not like is, for example, if millions of Deutsch Telecom End Users all show up and request a block of numbers that will appear in the routing table. He was confident that would not happen but from the discussions so far he felt that they would need to be careful about how they wanted to do this.
He asked the attendees if they thought that current model should be kept or if they should adopt the new model, as proposed, where the RIPE NCC would have direct contracts with End Users as any entity requiring address space would need to become a member of the RIPE NCC. He also stated that some people would not think this is a good idea due to the hassle with international paper work.
Kurtis Lindqvist (Netnod) suggested to keep the model of sponsoring LIRs because this ensures that we have accurate and up to date data.
Grespan dos Santos Tacio (private person) asked if a network was changed from one country to another, would there be a need to renumber.
Gert Doering added that country indication would be where your company would be registered, within the RIPE NCC service region. If you wanted to transfer the network to another party then it would be transfer policy.
Grespan dos Santos Tacio asked if he would need to be an LIR.
Gert Doering declined it and added that addresses were assigned to people signing the contract and not to a specific country. But if the person moved to another country then the documents would have to be updated accordingly if there would be a need.
Grespan dos Santos Tacio asked if he would need another sponsoring LIR.
Gert Doering responded that if you would change sponsoring LIR then you would need to update the documents and you could keep the old sponsoring LIR if you would still have good relationship. The network itself is independent from the sponsoring LIR.
Sascha Luck (Cork Internet Exchange) agreed with Kurtis and commented that if only those who want to be an LIR become so, the quality of the data will become much better because most of the ‘have to be' LIRs do not have any interest besides getting address space.
Gert Doering said that that was an interesting comment. He asked if that would be workable for the RIPE NCC.
Alex Le Heux (RIPE NCC) confirmed that something like this would be workable except in the case of a very large ISP, for example, who had decided to go through a sponsoring LIR rather than becoming LIR itself.
Gert Doering stated that he could not see any difference between becoming an LIR and going through an LIR.
James Blessing (Limelight Networks) commented that you might want to register special use in the database.
Gert Doering agreed that this would be handled in the documentation to allow people not to just look at numbers but also at the database.
Kurtis Lindqvist said that if there were special cases then we would want to see them and treat them as special. And he further added that certain cases like route servers and IXP prefixes should not be treated as any PI space.
Ivan Beveridge via remote participation commented that the LIR quality of data issues would be quite valid and we would only buy it after a number of years considering the ERX contact issues today.
Gert Doering stated that correctness of the database is important.
He further discussed the cost issues of the proposal and different charging schemes that might or might not create the right incentives. On the other hand, it would not be correct to create a flat charging scheme as it would be the wrong signal. He specified that they can only recommend something, then the RIPE NCC General Meeting will decide.
Sander Steffann added during the recent RIPE NCC General Meeting it was specified that it is not possible to charge per single address because the tax rulings would state that the RIPE NCC is then selling IP addresses.
Wilfried Woeber pointed out that it seemed we were drifting from the traditional model where costs should be related to the RIPE NCC's effort. He saw two large separate areas of activities of the RIPE NCC: keeping the infrastructure in place and keeping contacts with the other parties as over the last three to five years. This represented costs that he thought should be shared rather flatly by the community.
The parties and entities interested in the well-being and proper management of the Internet should have the environment and willingness to join the RIPE NCC and enter a contractual relationship and to pay for this infrastructure. On the other hand, he would not like to see that one /48 costs x and a larger prefix costs n times as much because this is against the tradition of paying the RIPE NCC for the effort to maintain the registry service. He compared the situation in the past which was many small blocks of IPv4 that required quite a bit of registration effort and keeping track of it. As IPv6 technology comes around, he did not see any difference in effort to the RIPE NCC whether someone registers a /19 or a /56. In conclusion he disliked the idea of having a direct relationship between the size of a block and the cost of a block, regardless of the tax aspect which he did understand.
Gert asked back if what Wilfried would like to see is a base fee that covers all the general work of the RIPE NCC and then a single fee per address block, independent of the size of the block, that covers the database operations and registry services.
Wilfred Woeber confirmed. He said it would be too much to charge per ticket, he would prefer something related to the effort at the RIPE NCC's end, not at the customer's end.
Sander Steffann asked if he would supported the per piece installation fee.
Wilfred Woeber answered that per piece installation fee and the current set up fee would be probably similar. Maybe they should be named differently but he agreed on the concept because the effort is easy to analyse and document. So it would be easy to price it and charge for it.
Immo Wehrenberg commented that that would look more like selling IP addresses.
Gert Doering acknowledged.
Tacio Grespan dos Santos asked how conservation was taken into consideration.
Gert Doering replied, assuming 50 people requesting big assignments per year, if we give away a billion /32 and we request good documentation, we should stop these large requests. He explained that they were not talking about giving away a /16. Even a small fee per prefix and good documentation should take care of the conservation.
Kurtis Lindqvist (Netnod) expressed his concern regarding the discussions taking place. He said that the model being proposed seemed cheaper than what LIRs were currently paying, though it is the same effort and amount of addresses. He commented that the charging scheme should be the same as it had been up to now.
Gert Doering replied that the policy would be better balanced taking into account Kurtis comments and then get together on the mailing list and eventually go to the RIPE NCC General Meeting.
Immo Wehrenberg added that there should not be a higher charge on the bill for conservation. The documentation should be made strict enough to help preservation.
Gert Doering clarified that he wanted to be consciously liberal on /48 and /32: you request address space, with the case that you have a different network and you get the prefix. Not much more documentation. There was potential for people using up a lot of resources but having even a small financial condition in the model would actually stop them from using up 500 million of them. He explained that he wanted to have documentation without overdoing it. This charging model may not work but there will be more discussion on that on the mailing list
Gert Doering moved to the next section about receiving multiple blocks.
James Blessing (Limelight Networks) commented that the wording of the definition of network should be stricter.
Gert Doering suggested that James' input should be taken to the mailing list and he could ask the RIPE NCC to help with the wording. He added that if the criteria were removed and people had to pay per block, it would be easier. But from experience that would receive resistance against liberal policy.
Kurtis Lindqvist (Netnod) expressed doubts on what would be the opposition to having multiple block assigned to one single organisation.
Gert Doering replied that he could agree to remove the restrictions presented. However, from past experience he expected much more resistance against too liberal policies.
Kurtis Lindqvist commented that LIRs should be able to justify why they need multiple blocks, for example for redundancy and discontinued networks of multinational companies. With the current proposed text they cannot have that. He added that we would need to take into account our definition of networks or if they could argue that they had routing requirements.
Gert Doering replied that the current policy states that LIRs have to provide reasonable documentation to the RIPE NCC. The RIPE NCC is usually not happy if we were not clear what criteria we would want to apply. He added that if guidelines were unclear then the policy implementation will not be what we expect.
Kurtis Lindqvist admitted that he did not quite understand the meaning of routing policy requirements. He gave the example of a multinational company that may have the same AS number in multiple locations but in disconnected islands and therefore will need different policies. He asked whether it was considered a routing policy or not.
Gert Doering said if it is disconnected then it is not immediately the same network.
Kurtis Lindqvist added that then it would not be right to call this a network but an organisation.
Gert Doering commented that this would be taken to the list and we would come up with something clearer.
Alex Le Heux (RIPE NCC) pointed out that the RIPE NCC would like clear guidance about if there would be a limit on the number of blocks handed out to an LIR. Without clear guidance the implementation would become difficult.
Gert Doering put an action item the RIPE NCC and it to come up with a list of problem cases that cause discussions. Then it could be better evaluated.
Nurani Nimpuno (Netnod) asked why there would be a limit on the number of blocks as an LIR could either justify the number of blocks or not. She added that there should not be any artificial limit.
Gert Doering agreed with Nurani's point and said he would take that to the list after taking input from the RIPE NCC .
Y. Open Policy Hour: Kurtis Netnod
Kurtis Lindqvist (Netnod) presented RFC 6382, recently published by the IETF. He also added that this was not his idea nor did he think it was a good idea. RFC 6382 suggested the use of unique source ASN for anycasted services.
The presentation is available for download at
http://ripe63.ripe.net/presentations/120-rfc6382.pdf
Alex Le Heux (RIPE NCC) commented, explaining that, as per policy implementation, anycast instances were seen as a separate network: they could get an ASN if they were multihomed as mentioned in the current policy. He added that the RFC says they don't have to be multihomed.
Kurtis Lindqvist explained that the policy does not allow anycasts to get separate AS Numbers. They have many single-homed networks and could not get ASNs for them.
Gert Doering said that he assumed anycast instances located at an exchange would be multihomed in terms of policies.
Kurtis Lindqvist explained that instances within locations inside carrier networks could be single-homed.
Alex Le Heux asked if a private ASN could be used for these instances.
Kurtis Lindqvist said it would not be possible because then you would not have control of the policy.
Sander Steffann asked if the ASN of the carrier network can't be used to announce.
Kurtis Lindqvist said that it was not an issue but the RFC said that you if you would want to do this then do ROAs. The policy said you can't do ROA with private ASNs.
Remco van Mook asked if this region was aware that there is already a definition of critical infrastructure.
Kurtis responded that policy allowed only root, ENUM and TLDs to qualify for critical infrastructure.
Remco Van Mook suggested that the community should write down a critical infratructure as a node-set.
Wilfred Woeber asked a question for clarification about the mindset behind the RFC and added that, at first. it seemed that the mindset is that anycasted service at the edge was provided by one single box with one single IP address which probably was applicable for DNS type stuff, but not necessarily for other types of anycast. He asked if he got that right.
Kurtis replied that none of the anycast services was one address and one box. There were multiple boxes and multiple prefixes.
Wilfed Woeber expressed his thoughts on technologies like cloud or similar things where you might have stuff which had been distributed amongst many different boxes or at least many virtual different boxes. He is concerned about the potential reading of it, that each and every instance of that, or each and every box or virtual would get their own ASN.
Kurtis Lindqvist responded that anycast for DNS are used in many many places so lot of ASNs would be used.
Sacha Luck (Cork Internet Exchange) added that this seemed to have been designed to help large content distributors' networks to better engineer their traffic. He wondered if all this would mean that 32-bit ASN will be snapped up by large CDNs.
Kurtis Lindqvist replied that he did not think there was any particular user purpose on this.
Patrick Gilmore (Akamai Technologies) responded to Sascha's previous comment that they, as a CDN. would not be doing this but many other CDNs might do. He commented further on an operational point. He highlighted that many people have a multipath BGP configured on their routers and this policy would break that. He suggested that the attendees think about the IETF creating a policy that has an effect on many operators' internal routing configuration and he stated he was against it.
Remco van Mook suggested that since this is mostly about ROAs we should add these thoughts to the certification policy.
Kurtis Lindqvist added that the RFC mentioned ROAs as an argument infrequently. The entire perception was on the fact that if the path in the anycast instance which gets broken there would need to be a way to filter that out. He added that it would be possible to do that with one AS as the path was known. However this explanation was lost in the RFC and he stated that he was not defending the RFC as he did not agree with it.
Remco van Mook replied that the RIPE NCC is not the routing or protocol police and that the only part that is relevant to the Address Policy was the ROA bit. He suggested that if there would be a certification policy, it should be included there.
James Blessing (Limelight Networks) commented that as a CDN, it wouldn't affect them as they have a connected network and this RFC talked about the unconnected networks. He further asked if we could get the IETF to delete it as this was a bad idea.
Kurtis Lindqvist responded that he would be happy to co-author a draft to say why this would be a bad idea and he asked who would like to help him with that.
James Blessing (Limelight Networks) volunteered.
Jen Linkova (Google) did not like the idea and asked if we would be able to change the wording so that people who would like it could use it and people who didn't like could just forget about it.
Kurtis Lindqvist replied that it wouldn't be possible but we could go to the IETF and ask. And it was not possible for him to explain why the RFC said “should” and not “could” in the RFC.
Richard Steenbergen (nLayer Communications) explained that he saw the value of what the IETF was trying to to do. He suggested using a BGP community, composed of a range of reserved communities, that would help in identifying anycast nodes, filter the route and not consume global resources.
Kurtis Lindqvist agreed that consensus was not to change the policy but to write a text and go to the IETF.
Gert Doering stated that the anycast operators would need to make up their minds whether they wanted to follow the RFC and if so, then they would need to change the policy to take into account single-homed anycast nodes and if not, then they did not have to do anything.
Kurtis Lindqvist replied that he did not think that they would do this as changing ASN on thousand peering sessions might not be feasible. Other route servers did not seem to be doing this as well.
Patrick Gilmore commented that the community was pretty clear that this was a bad idea operationally. Furthermore the policy was not fully thought out since there are single-homed instances of anycast that would have to change drastically just to fit anywhere near the policy itself. He clearly voiced that it is an objection to the RFC and we would need to tell the IETF.
Gert Doering stated that from the discussions in the room there was no work for the Address Policy community right now.
Bengt Gorden (Resilans AB) agreed with the previous speakers but wanted to remind the community that this was a best current practice not suitable for standardisation.
Gert Doring ended the session by thanking Kurtis for presenting this issue and the attendees for their participation.
The session was closed.