RIPE 68

Chair: Gert Doering, Sander Steffann

Scribe: Antony Gollan (RIPE NCC)

Session I - Wednesday, 14 May 2014, 09:00 - 10:30
Session II - Wednesday, 14 May 2014, 11:00 - 12:30

Session I - Wednesday, 14 May 2014, 09:00 - 10:30

A. Administrative Matters

Gert Doering, RIPE Address Policy Working Group Chair, welcomed attendees and introduced himself and his fellow chair, Sander Steffann. He ran through the agenda and asked if there were any changes.

There were no changes.

The minutes from RIPE 67 were approved without comment.

B. Current Policy Topics

Marco Schmidt, RIPE NCC Policy Development Officer

This presentation is available online at:
https://ripe68.ripe.net/presentations/270-Current_Policy_Topics_RIPE_68.pdf

Masato Yamanishi, APNIC Policy Special Interest Group (SIG) co-chair, noted that APNIC Prop-117, which allowed the transfer of AS Numbers (ASNs) within the APNIC region, also allowed transfers with other regions with compatible policies. He noted that there were currently were no such other regions. He said that the APNIC community would be welcome to create a similar policy in the RIPE region.

There were no further questions.

E. On Personal Identity

Nick Hilliard, INEX

This presentation is available online at:
https://ripe68.ripe.net/presentations/271-inex-ripe-warsaw-apwg-personal-identity-2014-05-13.pdf

Due Diligence Considerations (part of the above presentation)
Athina Fragkouli, RIPE NCC

This presentation is available online at:
https://ripe68.ripe.net/presentations/279-Due_Diligence_AP_RIPE68.pdf

Raymond Jetten, Elisa Oyj, asked if these issues were with people who didn't want to give out their passport or ID papers, or if it was a case of them not being legally allowed to do so.

Athina said that they claimed it was illegal to give out copies of their IDs.

Andrew de la Haye, RIPE NCC, said that they had been running this project for five years and in that time there had been a handful of similar cases. He said that the RIPE NCC had other options and it was those cases where people did not want to supply this information that the door was closed.

Sander said that in this case it had been part law, and part principle.

Hans Petter Holen, RIPE Deputy Chair, said that the RIPE NCC could run into privacy issues by storing copies of passports. He said that he thought there was nothing illegal about asking people to identify themselves. He said it would be great if they could use some form of electronic ID, but it would still be some years before something like this could be used across their region.

Erik Bais, A2B Internet, asked whether the policy said that End Users needed to identify themselves to the sponsoring LIR or to the RIPE NCC during this process. He asked if it was possible for the End User to show their ID to the sponsoring LIR and to have the RIPE NCC accept this, even if it had never seen the documents directly.

Athina said that this was not specified in the policy, but because these resources came from the RIPE NCC's pool and not the sponsoring LIR's, they decided to use the same due diligence that they used for their members. She said that the sponsoring LIR was just the middleman.

Sander said that the policy didn't say anything about identification and the RIPE NCC had to ensure the contract was there. He asked if the RIPE NCC should blindly trust every LIR out there.

Andrew said that the RIPE NCC didn't want to be in a situation where they asked for verification in some cases and not in others. He said that they wanted to treat everyone equally.

Gert said that they had one procedure for very different customers. He said they could argue that there was a point for having two different processes.

Wilfried Wöber, Univie/ACOnet/VIX, said that, while it was convenient to put his passport on a scanner and email it, other things such as a birth certificate could be more reliable. He said that he would assume this would be sufficient. He disagreed with the statement that the resources came from the RIPE NCC and said that they came from another party.

Gert clarified that they were talking about PI assignments rather than legacy space.

Wilfried added that he was looking at this as a broader issue and it was about trust — whether the RIPE NCC wanted direct proof independent of the sponsoring LIR, or if they wanted to use the LIR to do this and then have the RIPE NCC double check. He added that he thought this was over the top but he just wanted to clarify what the problem was.

Lionel Hoffmann, Bouygues Telecom, said he didn't understand what they were referring to when they mentioned company registration papers from a national authority. He said that he thought they just had to identify the company of the operator — not the person as an individual. He asked what the problem was and why they were asking for this information.

Athina clarified that a contract could be signed by a legal person (which could be a company or an organisation) or an individual. She said that, in cases where they were dealing with a company, they needed proof that the company existed.

Lionel asked if Athina was saying that, in these cases, a passport was not required.

Athina said that was correct.

Sander said that, if the resource holder was a company, they required proof of the company and, if the holder was a person, they required proof of the person. He said that, in Lionel's case, he was a company so he wouldn't have to identify himself as a person.

Piotr Strzyżewski, Silesian University of Technology, said that he was from a university organisation and knew of some universities that were 650 years old and their company registration papers were from a government that no longer existed — they had been issued by the King. He asked how they verified this. He added that his own orgnaisation had been created by a temporary government shortly after the Second World War. He added that this was an open question and he wasn't expecting an answer to this. He continued by saying that, in Poland, anyone who signed a contract had to prove that they were able to represent the company. He said that the CEO was sometimes not able sign a contract on their own, and this would have to be signed by someone else. He said that if the RIPE NCC was not checking who was signing the contract, this would be a flaw in their procedure.

Piotr also responded to Wilfried's comment about birth certificates being a valid form of ID. He said that he was old enough to see enough birth certificates issued for people in Poland that came from a different reality, from before the war. He said that these would be difficult to validate. He added that this was a tough question and he wasn't expecting an answer but was curious about how they would verify this.

Athina said that Andrea Cima, the Registration Services Manager at the RIPE NCC, would likely have a lot of interesting stories about these kinds of issues. She said that they were handled on a case-by-case basis.

Andrew added that, in the five years the RIPE NCC had been running this project, there had only been a handful of these cases and the RIPE NCC could always find a way to resolve them. He said that they offered a number of options that were acceptable to a large majority of people. He added that it was difficult for the RIPE NCC to keep track of all the rules and regulations in all 76 countries in its service region.

Alex le Heux, Kobo, said that, while on the surface it made sense to have one procedure for all members, European and national laws made a big difference between identifying information for companies or natural persons. He added that Dutch law made a big distinction between checking ID and destroying it, or checking ID and keeping it. He said that maybe they should find a more permanent solution that solved this once and for all.

Elvis Valea, v4Escrow, (via remote participation) said that the RIPE NCC should accept documents from an authorised lawyer or notary certifying that a certain person existed.

Athina noted that this was already the case.

Gert said that they should try and limit the discussion to legal persons, as this was what they were talking about. He added that they should avoid technical solutions and should focus on what they thought the benefit of having the RIPE NCC do this was. He said that the RIPE NCC did this to prove that the person existed. He added that he could send in anyone's passport, or forge it, and asked what the RIPE NCC would do about this. He said that, if there was a method that was problematic, they should agree on whether the community wanted to do this or not. He said that they should focus on the level of detail of verification required, if they trusted the sponsoring LIRs enough, and if it was a good reason to go directly to the End User.

Nick asked if an assignment would be revoked if it had been requested using papers that were later discovered to be forged.

Athina said that it would. She added that people were obliged to send true and valid information and there would be consequences if they did not.

Erik noted that Andrew had referred to these issues occurring in only a handful of cases. He asked what options they had to fix this without going down a completely different path. He asked if there were options for people to come to a RIPE Meeting, training course, or the RIPE NCC's office with a passport and verify their identity that way. He added that if there was no requirement to actually store identification, perhaps this could be done by a RIPE NCC staff member.

Andrew said that Erik was correct in that it was about verifying and not storing this information. He said that options such as going to a notary were available. He added that he didn't think there would be an issue with people showing their passports to a trainer and thought that should be achievable.

Erik asked how many cases they were talking about.

Andrea Cima, RIPE NCC, said that out of 45,000 contracts in place, there had been two of these cases.

Erik said that they should just buy them a train ticket and get them to Amsterdam.

Gert said the fact that only two cases had been problematic was a strong argument that the RIPE NCC's options were not offensive to many people. He said that it was still good to have the discussion to get a sense of the issue and the scale. He added that he knew of a case where someone had approached a RIPE NCC staff member in person with their passport but had been rejected because there was no process in place. He said that maybe they could create one, and asked if the issue was that the RIPE NCC needed to see the passport.

Sander said that even if they agreed that there was no problem, it was good for the RIPE NCC to confirm this and to have the conversation.

Malcolm Hutty, LINX, said in the United Kingdom it was easy to find a company with no checkable form of identification and to then transfer that company to someone else. He said that anyone wanting to conceal their identity, therefore, already had an option available. He said that it would be disproportionate to create a strong control on identification in terms of the added bureaucracy, as any bad actors could find a way around this.

Hans Petter asked if this was an appropriate conversation for the Address Policy Working Group to be having. He said that the RIPE NCC used established legal controls to ensure the accuracy of registry data and he didn't think they should invent their own mechanisms. He said that they should follow the rules of their own countries. He noted that, in the future, it would be important to verify people's identities in relation to IPv4 transfers and asked how identity should be verified. He said that he didn't want to put that burden on a RIPE NCC employee. He said that they were much better using passport and notarised documents and he agreed with the earlier speaker who said birth certificates were not an official form of ID. He finished by saying that two out of 45,000 cases was way below the noise line.

Gert noted that Address Policy Working Group was discussing this because 2007-01 came from this group.

Hans Petter said that he understood that and his point was that they required the RIPE NCC to enter into a contract and know who they were dealing with. He said that they couldn't require the RIPE NCC to enter into contracts and keep an accurate registry and not give them the tools to do so.

Wilfried agreed that the discussion should go to the RIPE NCC Services Working Group. He said that he thought LIRs were a trustworthy partner and couldn't see why they needed secondary checks. He said that, if he was falsifying a set of assertions, this would be challenged in the case of a dispute and could lead to his resources being revoked. He said that, if they started questioning the existence of an LIR, they questioned the validity of the whole distribution tree.

Elvis (via remote participation) said that he thought the RIPE NCC should not retain passport data.

Sander asked how long the RIPE NCC kept this information on file.

Andrew replied that this information was in the process of being destroyed.

Gert clarified that the process was that they took in this information, verified it and then destroyed it, but that they currently had old stuff they were getting rid of. Gert said this was good enough for him as far as data protection goes. He said that he saw some differing points of view, but not enough to say that the RIPE NCC should change its processes. He said two out of 45,000 cases was pretty good.

Sander said this confirmed that the community agreed with what the RIPE NCC was doing.

Raymond said there were always some people who were unable to get bank accounts or a mobile phone, but it wasn't worth addressing if it was two out of 45,000.

D. Feedback from RIPE NCC Registration Services

Andrea Cima, RIPE NCC

This presentation is available online at:
https://ripe68.ripe.net/presentations/269-AP_WG_RS_Feedback_Final.pdf

Sander said that, in his presentation, Andrea had touched on something that would come up later — he had said an LIR “must” return their IPv6 PI assignment when the policy actually said it “should”.

Gert had a comment about closing and reopening LIRs. He stated that he thought what the RIPE NCC was doing was fine. He said that they were taking the policy literally — everyone received one /22 and if it was returned it was gone, so the process of allocating a /22 happened once and then never again.

Sander said that he also heard of LIRs that had acquired multiple /22s through mergers. He said that if those LIRs then closed and reopened, they received one /22. He said he thought that was a good implementation.

Gert also noticed that Andrea had mentioned an LIR taking over a business from another and not being able to transfer AS Numbers and IPv6 space. He asked why they couldn't just follow the merger and acquisition procedure if they were taking over all their business.

Andrea said that, in these cases, the resources were being transferred but there was no acquisition or merger taking place, or at least this was how it was being presented to the RIPE NCC.

Erik said that he was someone who consolidated multiple LIRs within one company structure. He said that he worked with one company that consolidated four or five LIRs into one and they had to return the AS Numbers and IPv6 blocks from the originating LIRs that went into the one he wanted to put the IPv4 blocks into. He noted that the destination LIR could expand the IPv6 block from a /32 to a /29. He said that, in these cases, the IPv6 blocks were not in use, but he could imagine cases where they would be. He said that he would like to work with the RIPE NCC to propose two additional policies to allow the transfer of AS Numbers and IPv6 blocks.

Gert said that they would take Erik up on his offer. He said that he still wasn't clear on the process around merging LIRs. He said his understanding was that if two LIRs merged, they got to keep their resources.

Erik said that, in this case, it was not a merger or acquisition, but was rather a consolidation.

Gert said that this sounded like the same thing to him.

Erik agreed.

Sander said that the difference was between merging companies and merging LIRs. He asked if there should be a difference there anyway.

Andrea clarified that there were cases where the RIPE NCC had contracts with a series of individual LIRs that were held by a parent organisation. He said that, if they wanted to combine LIRs without one taking over another, that would be an example of one of these cases. He said another example would be where one LIR wanted to transfer its resources to another LIR with no acquisition in place. He said that there had been 50 of these cases in April alone, all of which were purely a transfer of resources.

Sander said that Erik's proposal would therefore be very welcome.

Gert said that he still wasn't sure about this difference, but having clear policies would help everyone.

Wilfried Wöber, speaking as a RIPE Database Working Group Chair, said that recycling AS Numbers would also be on their agenda later that day. He said that there were two separate issues with the documentation of routing policy and the use of ASNs in the RIPE Database. He said that one of them was the routing object — where you needed the consent of both the AS holder and the IP address holder to register such an entry in the database. He said it would likely be rather easy to keep a tab on this one, even if other parties still thought they had something to do with an AS Number that had been returned and recycled. He said the more difficult issue was the AUT-NUM as routing policy on the basis of autonomous system interrelations. He said that, even if the RIPE NCC was going to remove the route objects, he didn't believe that it would be easy to mess around with individual import or export clauses in a particular AS policy description. He said that, even if they did that during the next regular update, the maintainer of that set of routing information would resubmit it to the database. He said he wasn't aware of any sanity checks that would prevent that from happening. He said this may even interfere with routing, as someone might advertise something that was wrong at that point in time, and someone else might believe them. He said it required careful investigation before they moved ahead.

Gert asked what he recommended, given that there was a need for 16-bit AS Numbers.

Wilfied said he couldn't comment, as he didn't have any information on the numbers.

Andrea clarified that IANA still had around 500 16-bit AS Numbers; the RIPE NCC had around 600, in addition to the 2,000 referenced ones. He said that it would be a pity not to use these.

Sander clarified that this was about import and export lines.

Andrea said that it was mostly about import and export lines, AS set objects, AS macros.

Sander said that this was then something for the Database Working Group.

Wilfried agreed.

Sergiusz Paprzycki, Viatel, said that he wanted to return to the issue of the RIPE NCC not recognising a group of companies. He said they had gone through this issue twice over the past year and had a lot of trouble convincing the RIPE NCC to consolidate their resources. He said that it looked like they would have to open a new LIR just to transfer their resources to it. He said that this was counterproductive and something that could be addressed.

Andrea said this was why they had opened the issue.

Lionel said that he wasn't sure why IPv6 blocks couldn't be transferred. He said he wanted to merge two LIRs and to move the IPv6 blocks as they were in use today.

Andrea said that this was because there was no policy in place for the transfer of IPv6.

Sander said that the message he was getting was that if it was a consolidation, the mergers and acquisitions process should be applied, even if it was only LIR consolidation.

Gert said that he agreed and the message he was getting from the room was that company structures were more complex than current processes took into account. He said the other message he got from the room was that there was an asymmetry regarding which numbers could be transferred. He urged people who felt this way to support Erik's proposal.

Hans Petter said that he couldn't find any reference to this in the RIPE NCC's procedural document for transfers and mergers.

Andrea said that Hans Petter was referring to a procedural document, while the RIPE NCC was reading this from the IPv6 allocation and assignment policy document, which did not make mention of transfers.

Sander said that some of the cases they were talking about weren't viewed by those in the room as transfers. He said that there were two aspects to look at — one was the policy around transfers, the other was that consolidation of LIRs shouldn't be seen as transfers.

Andrea added that there were legal requirements. He said that the RIPE NCC had to carry out all the due diligence checks to oversee contract transfers.

Gert said that they could therefore put an action item on Andrea and Athina before the next RIPE Meeting to sort these cases where they had an umbrella corporation that had acquired other companies and whether those could be fixed in the processes or not.

Nick said the reason there was a disparity between 16 and 32-bit ASNs was that they didn't have full feature compatibility between them on standard routers. He said the reason they didn't have this was that there was no IETF standard that allowed them to define fully 32-bit communities. He asked if the Address Policy Working Group wanted to formally ask the IETF to sort this problem out — because they could not run transit providers with 32-bit ASNs at the moment. He said this would become an issue soon and there was no sign of it being sorted out by the IETF.

Gert said that, as a Working Group, they could agree to funnel this to the IETF and say that this was a problem and to work on it. He asked if Nick would like to work on a draft and circulate this on the mailing list.

Nick said that he would.

Sander said that one thing that this reminded him of was that they given the problem of import/exports to the Database Working Group. He said there was still something that the Address Policy WG needed to decide on — whether the RIPE NCC should begin distributing these ASNs, or if it should wait until the Database Working Group had sorted out the referenced ASNs.

Alex said that he could put anything he wanted to in his import/export lines. He asked if there was anyone in the room who cared what he put in there. He said that they should therefore start assigning them.

Sander said that it would be possible to clean this up later. He said that people who put garbage in the import/export lines only did harm to themselves.

Wilfried said that the problem was there already, whether they were recycled AS Numbers or ones that had never been given out. He said that it was true that people were only shooting themselves in the foot by putting bad information into their import/export lines. He said the fundamental aspect was that there was no sanity check to see that the policy update that went into the RIPE Database made sense. He said that this was the problem the Database Working Group was experiencing.

Hans Petter said that they should first consider whether this was for the good of the Internet or not. He said that making individual mistakes was one thing, but it was another for the RIPE NCC or the Address Policy Working Group to make mistakes for the whole community. He asked if they should wait and make sure they got it right.

Freddy Kunzler said that they should go with the second option, as he had received a message asking him to clean a reference and had not done it.

George Michaelson, APNIC, said that 32-bit adoption was a global issue, and given the rates Andrea had given of 16-bit ASNs, they had about six to ten weeks before they ran out. He said they had between eight and ten weeks to think about this. He said that he personally favoured the approach of the RIPE NCC removing the references in the import/export lines.

Andrea said that this was the monthly rate of consumption — so they had a bit longer than that.

Alex said that the second option wasn't going to save anything. He said a long time ago the RIPE NCC had expended a lot of energy chasing these references, but the references were back again in a few weeks. He said that there was no operational impact and it was a non-issue. He said that the second option would be a waste of time.

Sander said that they should go for the second option for as long as possible, but if it ever came to a situation where they only had the option of issuing a referenced ASN or not giving someone a referenced 16-bit ASN, they should issue the remaining unclean ones.

Gert added that Freddy should clean up his references. He said that the RIPE NCC should send another round of reminders.

End of first session.

Session II - Wednesday, 14 May 2014, 11:00 - 12:30

G. On SHOULDs and MUSTs — RFC 2119 Language in RIPE Documents

Jan Zorz, no affiliation
Marco Schmidt, RIPE NCC

This presentation is available online at:
https://ripe68.ripe.net/presentations/288-APWG-co-presentation-should.pdf

James Blessing, Keycom (via remote participation), asked if an IXP could get IP addresses from the RIPE NCC without becoming an LIR for other purposes.

Gert said that this was off-topic and they had a very limited amount of time. He said that he therefore wanted to focus on the overall picture, and individual cases could be examined on the mailing lists.

Elvis Velea, v4 Escrow, said that the first thing they should do was to realise that this may confuse the RIPE NCC, and in fact it had done for years. He said that they must change this to make it clearer. He said that coming to the community to reach consensus on each item would be quite difficult — he suggested that they follow what had been done with the cosmetic surgery project, as it would be better to produce a finished document and try to find consensus on that.

Jan asked if they would be ensuring the clarity of “shoulds” and “musts” in new policy proposals.

Sander replied that they would be looking at this in future policy proposals and it would be pointless if they didn't.

Gert added that the Impact Analysis also highlighted these cases.

Sander said that the real problem would be when a “should” was implemented as a “must” and was intended to be a “must”. He said that it would be difficult to determine which should be which.

Gregory Cauchie, Bouygues Telecom, said it wasn't a case of making policies stricter, but really about achieving clarification. He said that this was something they had to achieve. He said that if the implementation today was a “must”, then it should be a “must” and vice versa.

Carsten Schiefner, DENIC eG, said that clarity was always good when ambiguity existed and expressed his support.

Malcolm said that he was in favour of making these changes and that the examples were all cases where a “must” was intended, so they should look at what was intended in the policies. He said that they should go through the policies, understanding that this did actually make them stricter, and change them. He said that, in cases where there was a controversy, they should put these ones aside to deal with in a different process. He pointed out that this was different to cosmetic surgery as it was policy changes. He said that they should focus on what the policy meant and not on trying to affect changes.

James (via remote participation) said if they were going to look at “must” and “should” for some examples, they must do so for all cases.

Kurtis Lindqvist, Netnod, agreed that they had to go through these proposals and look at what needed to be changed. He said that he thought this wasn't cosmetic surgery and was a policy change. He said that they didn't want to do this separately for each policy. He asked what they should do if someone disagreed with a change in one document and said perhaps they should handle the documents separately.

Sander said that this would be easier to handle, so individual objections didn't hold up the whole process.

Kurtis said that it would also be important to get input from the RIPE NCC and see how it interpreted things. He added that there could be issues if they thought something was clear in the policy but the RIPE NCC did not.

Marco Schmidt, RIPE NCC, noted that their findings were those cases where they were unsure about what was intended. He said that this didn't cause any serious operational issues but were examples of things that they would like to have clarified.

Elvis agreed that they should look at what the policy should say at that moment. He said this would be a difficult exercise, as some policies were years old and even the original proposer might not know what they had intended. He said that they should start by talking with the RIPE NCC. He said that if it was implemented as a “must” and they changed it to a “must” then this was cosmetic surgery.

Nurani Nimpuno, Netnod, said that these policies should be handled separately. She said that, if the goal was to clarify the document and they were pragmatic about it, they would not need to create a huge process. She noted that many new entrants into the Regional Internet Registry (RIR) world had to understand the rules and the community had a history of trusting the RIPE NCC. She said that clarifying the language should help them and not make things harder for them.

Gert said he was hearing from the Working Group that they wanted to go ahead with this and that it should be a policy proposal. He said they would need to find a volunteer and thanked Jan and Marco for their work in going through the policies.

Replacing 2012-02

Sandra Brown, IPv4MarketGroup

This presentation is available online at:
https://ripe68.ripe.net/presentations/292-RIPE-2014_Inter-RIR_Transfers.pdf

Sander said that this was a good summary of the intention of the policy.

Elvis Velea, v4 Escrow said that he thought the idea was good but might need further work and he was happy to help if needed. He said he wasn't sure it was the best idea to drop 2012-02 and start with a new policy, but this was an administrative issue. He said that he thought it was a good idea to move forward and he felt the time was right. He noted that in Marco Schmidt's presentation they had heard that ARIN was considering a “no-need” policy and he believed it likely that APNIC would revert back to this as well.

Sander highlighted that “no-need” was not an accurate title, as LIRs still had to declare that they would use the addresses. He also cautioned against speculating on policies in other RIR service regions.

Gert added that was why the text specified that the RIPE NCC would come up with a procedure to meet the policy requirements in other RIR service regions. He said that if someone wanted to transfer to the ARIN region and the ARIN policies required the LIR to document their need, then the burden was on the RIPE NCC to come up with a procedure for that.

Olivier Martin, ICT Consulting, asked about the size of the IPv4 transfer market.

Sandra said that most blocks being traded were /20 and smaller and about 20% were /19 and larger.

James (via remote participation) asked what methodology was used for this.

Sandra replied that this was using the numbers published by the RIRs and put into an excel spreadsheet.

Elvis said that he had done some numbers previously and the transfer market had seen more than a total of a /8 in transfers according to official statistics, excluding legacy space.

Sander said that they weren't hearing anything on the proposal itself, and so they would take it to the mailing list.

Gert thanked Sandra for coming up with the proposal.

2014-01 Abandoning the Minimum Allocation Size for IPv4

Carsten Schiefner, DENIC eG

This presentation is available online from page 15 in the document at:
https://ripe68.ripe.net/presentations/236-ripe68-apwg.pdf

Gert said that there had been enough support on the mailing list for the policy to move forward. He said that it would be entering the Review Phase with an impact analysis in a week or so. He said that they needed a few more comments to move forward, even if they were just statements of support.

Marco said that the RIPE NCC's impact analysis would not contain any great surprises, as all they had to do was adjust existing procedures to smaller allocation sizes. He said that there were about 2,000 of these smaller PI assignments that could be converted if the policy was accepted.

Wilfried asked if the impact analysis considered filtering. He said that as soon as they started to transfer blocks from this PA space, they would see routing announcements smaller than the minimum allocation size. He said that this wasn't an expression for or against the proposal, but he just wanted to highlight an aspect that might impact a routing reality.

Elvis said that a few years ago this had all been changed to a /29 and they should have updated this when the RIPE NCC announced everything was going to change. Elvis asked if there was any difference between versions one and two of the proposal.

Carsten said that he had heard feedback that some people would like the minimum sub-allocation size to be removed. He said that even though he personally thought these were only loosely related, he put that in, and that was the only difference.

Elvis said that he therefore supported the proposal.

Gert thanked Carsten.

2014-02 Allow IPv4 PI Transfer

Erik Bais, A2B Internet

This presentation is available online at:
https://ripe68.ripe.net/presentations/287-2014-02_ripe68.pdf

Cyprian Nica, IP Broker Limited, asked (via remote participation) if the fact that people were breaking policy was a good enough reason to change it. He said that this created a bad precedent. He noted that there was hijacking of IP address space and asked if they should change the policy to allow this, as it was already happening.

Erik said that hijacking was based on ill intent and the policy they were discussing was about helping them to have an accurate registry.

Wilfried referred to Erik's point about people being able to become LIRs to sell the /22 of IPv4 space. He said that this was orthogonal to the subject of PI resource transfers, because if the value of IPv4 was such that it became attractive for people to create LIRs to sell off /22 allocations, there was nothing stopping them from doing this anyway.

Erik agreed. He noted that he had raised this issue on the mailing list previously and had asked if they should disallow the merging of LIRs that already had their /22s or to not allow these to be transferred. He said that there hadn't been much response from the community.

Wilfried asked if they should close this loophole on a more general level by changing the last /8 policy.

Erik said that this was beyond the scope of this discussion.

Gert said that he would task the RIPE NCC to check how common this was. He added that this should be pretty easy to see — LIRs being created and then transferring their resources a few weeks away.

Andrea said that they were looking at this already. He said that they hadn't seen many cases, but there had been some cases where an organisation opened a new LIR and then transferred its /22 shortly after. He said that they were keeping an eye on this but it was a limited phenomenon so far.

Sander said that he wasn't sure how people could make a profit from this business model — as the buyer could just open an LIR themselves.

Erik answered that some people knew better than others how the policies worked. He said that a company with its last /22 would think it needed to go to a broker, other people could do this themselves. He said that it was a few thousand euros profit after member fees were removed, and it definitely did happen.

Ciprian (via remote participation) said that the wrong intent was misusing PI space.

Randy Bush, IIJ, (via remote participation) asked if the goal was to have an accurate registry or preventing people from making money.

Erik replied that accuracy of the registry was the only goal.

James Blessing, said (via remote participation) that he thought they were the only one in the UK with two /22s, but only because they bought another company.

Erik said he knew of an LIR with four or five /22s from the last /8.

Elvis noted that the /22s that were set up for sale were public and could be seen by browsing through the published list of transfers. He said that it did happen and he didn't understand why people weren't doing it more often. He noted that people could setup a company for 50 EUR and start making a profit of a few thousand in a couple of weeks. Elvis continued by saying that asking someone to become an LIR to transfer PI was just encouraging people to uncover more loopholes and make more money. He asked if those in the working group who had raised objections would continue to object if a revised proposal would include a RIPE NCC fee for the transfer. However, he conceded that this would not have PI and PA on the same road. He said that he now fully supported the proposal, but maybe for those objectors, they could see if they would accept this modification.

Sander said that they would take this to the mailing list.

Erik said that they wanted the policy to be as close to the PA transfer policy as possible. He said that he wasn't a fan of creating different charging schemes for different things. He said that, if they had a clear policy for this and allowed transfers of PI, it would be a minimum administrative burden on the RIPE NCC. He said that it made everything easier if it was the same.

Gert said that he wasn't seeing any massive objections and so they would continue on the mailing list. He said that they would send a reminder to the list that the discussion was still ongoing and they needed more voices. He thanked Erik for highlighting some of the details and noted that they didn't want to encourage people to use loopholes.

Remove Multihoming Requirement for AS Number Assignments for AS Number Assignments

Job Snijders, no affiliation

This presentation is available at:
https://ripe68.ripe.net/presentations/303-RIPE68_APWG-remove-multihoming-requirement.pdf

Wilfried said that he fully supported Job's proposal. He said that he'd had a funny feeling about these artificial requirements for years. He added that he didn't like the fact that the RIPE NCC was required to double check and verify this requirement that was impossible to do. He said that pointing fingers at private AS Numbers was just as cumbersome as it had been in the past. He said that there were good reasons to use unique AS Numbers.

Job said that he had seen people lie to the RIPE NCC to receive AS Numbers. He said that they could just email their random upstream provider and then a random route collector, which was technically mutlihoming.

Jan said that he fully supported the proposal. He said that he had seen many people lie in the past to get an AS Number. He said that, when people built a network, they were typically investing a lot of money into the hardware and typically could only afford a single upstream in the beginning. He said this requirement needed to be removed.

Nick said that he mostly supported this proposal. He said that he supported it completely for 32-bit ASNs, but did not support it as much for 16-bit ASNs.

Randy Bush, Internet Institute Japan, asked (via remote participation) for examples of needs for AS Numbers other than multi-homing.

Job replied that there was a concept in the telco world that was called peering, but was actually exchanging control plane data with one another that was not visible on the Internet but that required a globally unique AS Number to setup the BGP sessions among those telcos.

Job said that another use would be just being present on the Internet, but not having decided yet whether they wanted to multihome or not. He said that getting multiple vendors to supply him with a service had no correlation to running the services. He said that you didn't need to multihome to be present on the Internet.

Elvis said that he fully supported the proposal. He said even connecting to one ISP by various ways might actually require an AS Number for yourself. He said that he had seen a lot of requests that were ultimately for reasons of wanting independence; people didn't want to hang onto one provider announcing their address space. He agreed with Nick in that 32-bit AS Numbers were fine to distribute freely. He asked why Job was putting a burden on the RIPE NCC to determine the technical reason for the request.

Job asked if the burden would be self-imposed. He said that one reading of the text was basically to just rubber-stamp everything that came through.

Elvis said that the policy was saying the requester had to provide a very technical reason that the RIPE NCC had to understand in order to grant the request. He said that, if he wanted the RIPE NCC to rubber stamp these requests, then it should say that in the proposal.

Dave Wilson, HEAnet, said that there had been a case in the past where his own network was clearly multihomed, was peering with other networks but, as far as the commercial world was concerned, it looked like they had only one route. He said that there was no way the RIPE NCC could see this, as the Internet looked very different depending on where you stood. He said that he therefore fully supported the proposal.

Rüdiger Volk, Deutsche Telekom, said that unique AS Numbers should be available. He said that anyone who installed a network of a certain complexity and couldn't preclude in advance that they wouldn't interconnect with more than one external party, should probably have the chance to do the right thing from the beginning. He said that it made a lot of sense to ask that parties who did not currently have specific plans for doing multiple AS peerings have access to AS Numbers, however he added that 16-bit AS Numbers should probably be secured for parties that were, in the short term, doing something with them on the public Internet.

Randy referred to RFC 1930 and said that the purpose of Autonomous Systems was to connect to each other and use BGP and those sorts of things. He added that you'd naturally want an ASN for that. He said that there were good use cases for ASNs within certain internal network structures. He said that they saw 32-bit ASNs as infinite, but noted that they were stewards of resources. He said that he didn't support randomly rubber-stamping them and giving them away, but supported giving them to those with a technical need of them. He said that all of the use cases he had heard more or less involved connecting with two or more other autonomous systems over the Internet, and it didn't matter if they were visible or not.

Job said that he had seen use cases where private ASNs were assigned to the customer premises equipments (CPEs) of enterprises that connected to a free virtual private network (VPN) provider that was spread around the globe. He said that this was a valid case where you weren't multihoming, as you had only one provider, but you recycled a certain integer across a lot of sites. He asked why you would recycle those integers across all your customers and multiple sites.

Gert said that he had heard from the working group strong support on the general idea, some worries on rubber-stamping, but also support for retaining some criteria for the RIPE NCC to evaluate. He said that there were also worries about using 16-bit ASNs, but not as much with 32-bit. He apologised for cutting the discussion short.

2014-04: Relaxing IPv6 Requirement for Receiving Space from the final /8

Martin Pels, AMS-IX

This presentation is available online at:
https://ripe68.ripe.net/presentations/239-2014-04.pdf

Nick said that there was a bug. He said that they didn't seem to accept IPv6 allocations or assignments from other RIRs and asked if that was intentional.

Martin replied that they didn't think that it mattered, as if someone had an allocation from another RIR, they could still get PA from the RIPE NCC without any problems.

Nick said that it was a bit pointless having an assignment hanging around that you probably wouldn't use.

Martin agreed.

Elvis said that he didn't understand why they didn't just let an LIR get their /22 if they had IPv6. He said that some people might have IPv6 assignments and might become an LIR to get their /22 of IPv4. He said that these people wouldn't need the IPv6 allocation, and wouldn't want to renumber their network.

Martin asked if that would include using a tunnel from another provider.

Elvis said that they were still using IPv6. He asked when it was so easy to request an IPv4 /22 from the RIPE NCC, why were they asking them to get an IPv6 allocation that they were never going to use?

Aleksi Suhonen, Axu TM Oy, said (via remote participation) that, as one of the proposers of the change, they had considered other RIRs before publishing the initial proposal, but they didn't want to make this overly complicated.

Dimitry Kohmanyuk, Hostmaster Ltd, disagreed with Elvis and said people needed to have IPv6 address space from the RIPE NCC or an upstream LIR. He said that tunnel space would not qualify, as this was not in the spirit of being an LIR. He suggested that the policy text should clarify that the upstream provider should be from the RIPE NCC, as currently he read that as an upstream LIR from any RIR.

Nick asked why there was a requirement to have IPv6 in the policy at all. He said that. if people were going to use IPv6, they would use IPv6, and if they were going to use IPv4, they would use IPv4. He said that adding something to a RIPE Policy wouldn't make a difference. He suggested that Martin change this in his proposal.

Martin said that there had been suggestions in the other direction, saying that someone should send an email to the RIPE NCC using an IPv6 address. He said that he felt there wouldn't be much support for this.

Nick said that they had the historical precedent with this before — with the Open Systems Interconnection (OSI) debates. He said that they should just remove the requirement and be done with it.

Rüdiger disagreed with Nick. He said that it wasn't necessary, but it didn't really hurt. He said that it was a valuable opportunity to push people towards using IPv6 and missing this opportunity was a bad idea. He said that he hated it when he saw customers connected right now and their administrative procedures seemed to force them to give IPv6 data and nevertheless new customers showed up with new 32-bit ASNs and didn't do anything in IPv6. He said that he found that extremely annoying, and they were going to haunt him down the road.

Gert said that what he heard from the room was that no one wanted to keep the old policy text. He said that there was also not full agreement on the specifics — which meant that they should take it back to the mailing list and see if they could agree on some specific wording. He said that, at this point, it was easy to change the text to whatever it was, and that they could ask the mailing list.

Gert thanked the working group for helping to shape policy.

Sander announced that, at the last RIPE Meeting, there had been a proposal to unify PI and PA and he had heard that this might be restarted. He said that, if it did, it would appear on the mailing list.

End of second session.