You're viewing an archived page. It is no longer being updated.
RIPE Meeting |
75 |
Working Group |
Address Policy |
Status |
Final |
Chairs: Gert Doering, Sander Steffann
Scribe: Antony Gollan
Gert Doering welcomed attendees and ran through the agenda. There were no changes to the minutes.
Marco Schmidt, RIPE NCC
This presentation is available at:
https://ripe75.ripe.net/presentations/77-Current_Policy_Topics-RIPE75.pdf
There were no questions.
Andrea Cima, RIPE NCC
This presentation is available at:
https://ripe75.ripe.net/presentations/80-AP_WG_RS_Feedback_final.pdf
Gert noted that Andrea had said around 2,500 PI assignments had been converted to PA. He asked how many PI assignments had become regular PI with contracts.
Andrea said he didn’t have those numbers at hand, but he thought it was at least a few hundred.
Gert said they should go through the questions Andrea had raised one by one.
Gert suggested they send a proposal for a textual change to the WG mailing list and see what happened. This was really about fixing the glossary in the document and not a policy change.
Peter Koch, DENIC, said he was making his usual remark: as the document would be getting a new timestamp, maybe they could use this as an opportunity to clean up other things that were outdated, such as old references in the document.
Gert said they still had the outdated references work items proposal on his desk. This was kind of the point – they could find more substantial things to change and include the reference changes as well.
Gert said the problem here was that you couldn’t do full-featured BGP with 32-bit numbers due to Large Communities. This had been fixed, but the implementations weren’t there yet, so he could see why large transit providers would still want 16-bit ASNs.
Juri Bogdanov, IP4Market, said they had problems with RIPE NCC staff requesting additional information for 16-bit ASN requests that they couldn’t understand. For example, they might ask for the software version of the router and then not understand the text they sent them. He didn’t think it should take so long to explain why they needed 16-bit ASNs.
Gert said the WG had given the RIPE NCC a mandate to assign 32-bit ASNs by default and only give out 16-bit ASNs if the need was justified.
Juri said RIPE NCC staff should only ask questions if they were able to understand the information that they received.
Andrea said as far as he was aware, the RIPE NCC had never rejected a 16-bit ASN. The reason they asked questions was because they wanted to know the issues that organisations were having. He agreed that in some cases, the issue was very technical and they might not know this at the time.
Juri asked how many 16-bit ASNs the RIPE NCC had remaining.
Andrea said they had three years of ASNs left – around 1,900.
Gert said it was helpful to put this into perspective. Hopefully everyone would be 32-bit compliant in three years.
Eric Bais, A2B Internet, said the BGP Large Communities was about 17.3 Junos version where it was now released or almost out of BETA. He had seen the other implementations where it was actually coming into the router software for Large Communities. He thought the requests for 16-bit ASNs would go down and didn’t see any reason to change the current policy.
Brian Nisbet, HEAnet, said he didn’t think everyone would be deploying the Large Communities software anytime soon.
Gert said you only needed to deploy this if you were connected to a peering point or a transit ISP that used a large ASN. So, if those few stuck with 16-bit ASNs, and leaf sides could use 32-bit ASNs just fine, the big pressure was gone. He could understand not going to the latest router software release – he was quite conservative in that respect.
Gert said what he heard from the WG was that Andrea was making people’s life miserable when they made 16-bit ASN requests. This was what the WG had instructed them to do, so they should keep this up.
Gert said that someone walking in from the street representing an organisation could only have an IPv6 allocation if they were an LIR. This meant that organisation meant LIR. However, replacing the word “organisation” with “LIR” would make the text strange – because then an LIR could have an allocation only if it was an LIR. The text currently said an LIR could have an allocation – it didn’t say that a member could have an allocation.
Eric said they had brought this up in the last week. They noticed this with customers that had an initial LIR and later went on to open second or third LIRs. He was in favour of having the same policy for IPv4 as for IPv6, which would make everyone’s life a lot easier. This would have an impact if you started merging LIRs. He actually had an LIR with three /29s in it, without providing proper documentation, because he had merged LIRs. This was before multiple LIRs were specifically allowed by member choice. If you looked at the decision at the GM from a while ago, this was outdated policy text that should be clarified. However, from an IPv6 perspective, he could see that this may not be the best choice.
Jordi Palet, the IPv6 Company, said he wasn’t sure they needed to align the IPv4 and IPv6 policies. They were two different protocols, even though the administrative issues might be similar. While people were able to request more IPv6 without justification, this was already the case with the first /29. He asked why they needed to stop organisations from having multiple allocations when they had several LIRs – as they might have separate internal infrastructures.
Juri agreed with Jordi and said they had already run into difficulties where the RIPE NCC staff said that differences in infrastructure and equipment were not enough of a reason to justify separate LIRs and IPv6 allocations. He understood that some IPv6 space was reserved after allocations were made and asked Andrea to clarify.
Andrea said they reserved a total of a /26 for every allocation between a /32 and a /29. For larger allocations, they reserved three bits. These were internal reservations and were not attached to the name of the LIR. There was no guarantee that the LIR would get this address space in the future.
Juri suggested LIRs be able receive as much IPv6 as they needed, but with a smaller allocation size, and if they needed more they could ask for it. This would let them see how much LIRs needed.
Gert said they could lower the minimum allocation size to be smaller, but that was out of scope for this discussion and would require a different proposal.
Jan Zorz, speaking as a random guy from the community, said he didn’t see any need to put additional burdens on people who wanted IPv6 space. He suggested they add a new point stating that an organisation could have multiple LIRs and could request an initial IPv6 allocation per LIR.
Sander said one of the disadvantages of the current text was that it said allocations were made to organisations that had to be LIRs. But in practice, they were allocating to LIRs rather than organisations (the LIR that belonged to that organisation). Clearing this up would be better than adding a new point.
Eric said an organisation could have multiple business entities. And a business entity could have multiple LIRs. This was where it became tricky to use the word organisation unless they meant one specific business entitiy. He knew this was semantics, but semantics was why they were here. If people had IPv6 and wanted to use it, why should the WG want to make it harder than it already was?
Gert said a business entity was an organisation. He and Sander would be an organisation if they tried to organise as themselves – so the text was not really clear in what it was trying to convey. Regarding wasting address space, a /29 was not a massive waste, as there were as many in IPv6 as there were in IPv4, so they were not in any danger of running out.
Eric said he was happy to see this topic. The peering LAN and route servers were required, but web servers, mail servers, the office network, or similar things shouldn’t be covered. He said there shouldn’t be a requirement for an IXP peering LAN to be in the routing table.
Sander asked if there should be a requirement that the Peering LAN was specifically not in the routing table. Or should they leave this to the IXPs themselves?
Eric said they shot themselves in the foot by doing this. He thought they should recommend that people don’t do this, but not enforce it.
Andrea asked how strongly they should recommend this – was it a should or a must?
Eric said he preferred a should. He asked how long Andrea thought this address space would last.
Andrea said they had given out four /24s in the last four months – so they had something like ten years of resources remaining at the current rate.
Eric asked if there was any need on their side to add another /16.
Andrea said that because they were strict, people were only using these resources for peering LANs. This was keeping the usage down. They could make it easier for people to get and use the space, but that would increase usage.
Eric asked what the exact requirements were to get the allocation.
Andrea said they had to be an IXP, be publicly open with their joining policy, and show the number of peers they had. The requirements to get the space were not difficult to meet, but it was more the the knowledge that you could only use it for a peering LAN or you would be contacted if the RIPE NCC saw it was visible in the routing table.
Eric asked if there was a minimum member requirement.
Andrea said it was three members.
Maximilian Wilhelm, via remote participation, said he wanted to respond to Eric’s statement that IXP peering LANs should not be in the global routing table. He suggested IXP operators were strongly encouraged not to export the IXP peering LAN to the global routing table.
Aaron Hughes, ARIN Board, said that as a long-term operator of IXPs and service providers, it was notable that IXP LANs were generally was injected by the IXP’s members, so they should not blame IXPs for the problem – as it was out of their hands.
Jan said it wasn’t a huge amount if only 12 of these 96 /24 assignments were being announced into the global routing table.
Andrea said this was because the RIPE NCC contacted them when they saw it was being used for other reasons. He added that there was no malicious intent behind this – it was by mistake or misunderstanding.
Jan said if they had to draw a line, he would draw it just below running the route server’s peering LAN.
Nick Hilliard, via remote participation, said they shouldn’t insist IXP prefixes were not announced into the default prefix zone. Announcing IXP LAN prefixes had substantial benefits in terms of debugging and remote monitoring.
Gert said what he was hearing was that the policy was doing its job. This reserve was for IXPs and it should last as long as new IXPs were built that needed IPv4 for their peering LAN. If they had ten years to go, that was a good number – as more IXPs would be built in that time. He didn’t see a need to change anything here. Gert thanked Andrea for providing his feedback to the WG.
Maximilian Wilhelm
This presentation is available at:
https://ripe75.ripe.net/presentations/82-RIPE75-IPv6-PI-Sub-assignment-Clarification.pdf
Jordi said his concern was with the v6Ops document that was in Last Call – which said it may be useful to assign one /64 per host. If he understood the proposal correctly, it would not allow this. This meant they were making a policy that was in conflict with something that would be a standard in a couple of weeks.
Gert said it wasn’t a mandatory thing. The document said that if you ran a public WiFi with customer isolation (which they didn’t), then it was a best practice to give one /64 per host. But that didn’t mean you couldn’t run your WiFi otherwise. It meant that this sort of practice wouldn’t be possible with the new policy text – but it wasn’t possible with the old text either. So, while they might want to update the policy again in the future, it wasn’t an argument to hold up the change.
Jordi said they were restricting people.
Sander said DHCPv6 Prefix Delegation was also not allowed with PI space in this way. They weren’t saying that they restricted RFCs. If you wanted to provide this kind of service you needed to have PA space and not PI space.
Jordi said he agreed, but his point was that either they could keep the current proposal text and not change anything or they could do this in a way that gave people all of the options. Or they could get rid of the PI/PA distinction altogether. He knew this was a different story, but ultimately it came to the same thing. If they went with this proposal text, maybe tomorrow someone would want to use a /64 for wireless client isolation and they might change it again.
Sander said if they tried to make the policy the way everyone wanted it they would never get anywhere. It was better to take care of these issues one step at a time.
Maximilian Wilhelm said at RIPE 74 they had decided to postpone the PI/PA discussion and get on with this particular fix. As far as he had understood the impact analysis, from the RIPE NCC’s point of view, the /64 delegation would be allowed with this policy change. He asked the RIPE NCC to clarify this.
Peter, said he thought they were introducing a new complication by using “sub-assignment” without having a clear understanding of what they meant by “assignment”. Sub-assignment wasn’t defined in ripe-684. The term was used, but what was missing was the transient nature of that thing that he guessed was trying to be addressed by sub-assignment. Regarding the PA/PI distinction – if he was a PI holder and he had a guest LAN and he gave out a /64 for his guest, he would be violating this policy, in the same way that Maximilian thought that he was violating the policy – which he personally disagreed with.
Gert said the RIPE NCC also thought Maximilian was violating policy. He had put in a PI request with a very clear description of what he intended to use it for and the RIPE NCC had rejected it. He could have put in a request where he said he intended to use the PI for himself, but he was being very upfront and honest about colliding with the policy.
Peter said they also had this ambiguity about “organisation”. If he was personally a guest of someone who had PI space and assigned a /64 to someone signing up on a wireless LAN, was he an organisation in this context? He thought they were on a slippery slope trying to catch something that they could address in a different way. He was missing the transient nature of handing out an address and everything else to be captured, including the purpose, the holding, and the responsibility. He thought they were going into the wrong direction by trying to endlessly capture details of what this might be, whereas someone like Jordi or himself could come up with something that would still not be covered. They needed to think about the transient nature and not call these things sub-assignments or at least first find a proper definition if they wanted to use it.
Sander said this was what the proposal did.
Gert said that it didn’t. It said assign and then later on it said sub-assign without defining sub-assignment, so there was definitely housekeeping to be done. There were inconsistencies around the references to assign and sub-assign and if they wanted to keep that track, there were more wording changes needed.
Peter asked if he had a contractor working in his PI space and the contractor wasn’t part of his organisation – was that sub-contractor another organisation that he had sub-assigned address space to?
Gert replied that in this case they were another organisation, as he would be giving them addresses – this was an assignment.
Peter said they were splitting hairs. In this case the problem was somewhere between the keyboard and the chair.
Gert said the problem was that the current policy said no sub-assignments whatsoever were permitted. The RIPE NCC had brought this up to the WG a few times and said that this was not clear enough to draw a line between some things that they thought were okay and some things that they thought were not okay. The RIPE NCC’s interpretation was that whenever you gave an address to a different party that was not your organisation (whatever “your organisation” meant, which was not very clear), they would deny the request. And that was causing the friction.
Marco Schmidt, RIPE NCC, responded to Maximilian’s earlier question. He said it was true that when they had prepared the impact analysis, they had considered configuration mechanisms that would give a separate, single address to a customer as being consistent with the policy, on the condition that it was a dynamic assignment like with WiFi hotspots. This was why they had taken a long time to be more open to the different use cases, but all the discussion here had shown that this would create a new grey area – and they had tried to find a good compromise between being practical and comprehensive while not allowing the policy to be abused.
Jordi said it was even worse than Peter had suggested – if an employee joined your wireless network with a smartphone you were violating the policy. It was a grey area. If he understood what Marco had said properly, if you were assigning by means of DHCP, you would not be following the policy, but if you were using router advertisement you would be. Was it the assignment mechanism?
Marco replied that it depended on the case, which was making their evaluation more complicated. If there was any prefix delegation involved, the policy would not allow it. But if there was a mechanism that gave out a single address, this would be allowed.
Jordi summed up by saying that basically using routing advertisement for the point-to-point link or for connecting the customer would work but using DHCPv6 prefix delegation would not work. He agreed with that, but then because the single prefix per host was done using slack, it should be inside the policy. He said they needed to fix their position one way or the other, but not something in the middle. He also wanted to comment that when he volunteered a few moments ago with the previous change regarding what an organisation was – he had found that they had no definition of organisation and this was a broader problem than what they were looking at.
Erik said his definition of an assignment was something that was registered in the RIPE Database.
Gert asked if that meant he could run a full ISP on this so long as he refused to register anything.
Erik said no, because as an ISP you would have assignments for your infrastructure in the RIPE Database, the same as IPv4. For instance, they did assignments in the RIPE Database for customer VLANs. The policy further down the line actually prohibited you from providing certain services like allocations to third-parties. If it was a temporary use of addresses, this was different in his definition from an assignment – and you couldn’t do an assignment once you already had PI. So by definition this disallowed it already. He said the definition of an assignment was the root cause here.
Jan Zorz, Go6 Institute, said he knew he was risking his own IPv6 space, but he wanted to comment anyway. They ran Go6 Lab which was for IPv6 experiments and had IPv6 PI space. They had a /48 and that was plenty for them. But people from the likes of Google Measurement Labs had asked if they could put measurement servers in his lab, along with similar requests from NLNOG Ring and others – all things that were good for the Internet – but he was not able to do sub-assignments. If he wanted to not break the policy, he would need to become an LIR, and he didn’t see any point in that. He asked why they couldn’t just drop all of these burdens and let people use IPv6 as they wanted.
Gert said he was hearing very clearly from the group that while this version might fulfill Maximilian’s requirements, it was not what the room wanted. He asked WG members to voice their concerns on the mailing list as well, because they were different concerns and not just a wording issue. The current version didn’t have the support he thought it would have, so they would need to keep discussing it. He thanked Maximilian for his work on this, even if it hadn’t worked out as they had all hoped.
Maximilian said he was wondering about the new opposition – he had thought there would have been more support after the previous change.
Gert said the arguments were differentiated enough and complicated enough that the WG couldn’t achieve a common understanding at this session and they would need to discuss the issue further on the mailing list.
Gert said Sander’s term as WG chair was ending at the next meeting and he wouldn’t be running again. He asked people to approach either of them if they were interested in becoming WG chair.