new IPv6 policy draft - real soon now
Dear colleagues, We are aware that the promised deadline for the next IPv6 policy draft has passed. We are sorry for that delay and thank you for your patience. The ARIN members met yesterday and today and were given the opportunity to discuss the proposed policies. During this discussion we received very good input. These comments are now being incorporated in the new draft and we expect to send this new version out in a couple of days. Mirjam Kuehne RIPE NCC
Hello Mirjam, Can you or someone else who was at the meeting summarise the input received from the ARIN community to the 6bone and ipv6-wg lists? For those not present, the specific feedback would be most interesting/useful... thanks! philip -- At 00:56 14/04/99 +0200, Mirjam Kuehne wrote:
Dear colleagues,
We are aware that the promised deadline for the next IPv6 policy draft has passed. We are sorry for that delay and thank you for your patience.
The ARIN members met yesterday and today and were given the opportunity to discuss the proposed policies. During this discussion we received very good input. These comments are now being incorporated in the new draft and we expect to send this new version out in a couple of days.
Mirjam Kuehne RIPE NCC
Hi Philip, A working group was created to discuss allocation policies. This working group also discussede the initial allocation criteria as proposed in the current draft (with participation on the 6bone added as one criteria). The feedback was very positive, also regarding the slow start mechanism. We also received useful input regarding some of the parameters in the allocation criteria, for example 12 for the number of months within which IPv6 services will have to be provided and 42 :-) for the number of customers the ISP has to have in one of the other criteria (we'll probably round this up or down in the final document :-) I suggest to further discuss this when the new draft will be sent to the list in one of the next days. Mirjam Philip Smith <pfs@cisco.com> writes: * Hello Mirjam, * * Can you or someone else who was at the meeting summarise the input received * from the ARIN community to the 6bone and ipv6-wg lists? For those not * present, the specific feedback would be most interesting/useful... * * thanks! * * philip * -- * * At 00:56 14/04/99 +0200, Mirjam Kuehne wrote: * > * >Dear colleagues, * > * >We are aware that the promised deadline for the next IPv6 policy draft * >has passed. We are sorry for that delay and thank you for your * >patience. * > * >The ARIN members met yesterday and today and were given the * >opportunity to discuss the proposed policies. During this discussion * >we received very good input. These comments are now being incorporated * >in the new draft and we expect to send this new version out in a * >couple of days. * > * >Mirjam Kuehne * >RIPE NCC * > * > * > * *
Mirjam, On Wed, Apr 14, 1999 at 04:59:18PM +0200, Mirjam Kuehne wrote:
A working group was created to discuss allocation policies. This working group also discussede the initial allocation criteria as proposed in the current draft (with participation on the 6bone added as one criteria).
The wg was (interim-)chaired by: Sandra Reimer from McLeadUSA. I hope we will be able to get the minutes from her as soon as possible.
The feedback was very positive, also regarding the slow start mechanism. We also received useful input regarding some of the parameters in the allocation criteria, for example 12 for the number of months within which IPv6 services will have to be provided and 42 :-) for the number of customers the ISP has to have in one of the other criteria (we'll probably round this up or down in the final document :-)
It was my impression that the number of 42 was the optimal number and that nobody wanted to have anything less/more ;-). There is no reason to start playing again with those numbers. Another point that was discussed was the removal of the condition entirely since the other condition (intent to provide IPv6 service) was easier to qualify for anyways. The biggest concern left was the slow start procedure within the sTLA. It was discussed at length but no agreement could be reached. The registries want to have some kind of control against allocations that are given out that are not used as they are supposed to be used, while at the same time most customers of the registries would obviously like to have maximum freedom & minimal paperwork. The registries asked for alternatives that would have the same effect - one of the variations that was discussed, was to make the slow start even slower (eg.: you can only assign a very small number of NLAs before returning to the registry), and to allocate the full space soon thereafter. It was agreed that more discussion this topic would be needed. David K. ---
Hi David, thanks for adding some details. David Kessens <david@Qwest.net> writes: * * Mirjam, * * On Wed, Apr 14, 1999 at 04:59:18PM +0200, Mirjam Kuehne wrote: * > * > A working group was created to discuss allocation policies. * > This working group also discussede the initial allocation criteria * > as proposed in the current draft (with participation on the 6bone added * > as one criteria). * * The wg was (interim-)chaired by: Sandra Reimer from McLeadUSA. I hope * we will be able to get the minutes from her as soon as possible. * * > The feedback was very positive, also regarding the slow start * > mechanism. We also received useful input regarding some of the * > parameters in the allocation criteria, for example 12 for the number * > of months within which IPv6 services will have to be provided and * > 42 :-) for the number of customers the ISP has to have in one of the * > other criteria (we'll probably round this up or down in the final * > document :-) * * It was my impression that the number of 42 was the optimal number and * that nobody wanted to have anything less/more ;-). There is no reason * to start playing again with those numbers. Another point that was * discussed was the removal of the condition entirely since the other * condition (intent to provide IPv6 service) was easier to qualify for * anyways. * * The biggest concern left was the slow start procedure within the sTLA. * It was discussed at length but no agreement could be reached. The * registries want to have some kind of control against allocations that * are given out that are not used as they are supposed to be used, while One other reason is that if all organisations/networks have the same prefix length ISPs will have difficulties to make rationale routing decisions if that may be necessary in the future. Mirjam * at the same time most customers of the registries would obviously like * to have maximum freedom & minimal paperwork. The registries asked for * alternatives that would have the same effect - one of the variations * that was discussed, was to make the slow start even slower (eg.: you * can only assign a very small number of NLAs before returning to the * registry), and to allocate the full space soon thereafter. It was * agreed that more discussion this topic would be needed. * * David K. * --- *
* The biggest concern left was the slow start procedure within the sTLA. * It was discussed at length but no agreement could be reached. The * registries want to have some kind of control against allocations that * are given out that are not used as they are supposed to be used, while
One other reason is that if all organisations/networks have the same prefix length ISPs will have difficulties to make rationale routing decisions if that may be necessary in the future.
Well hang on a moment. sTLAs are intended for ISPs and exchange points, and we're expecting them all to show up in the default-free table. I don't see your point. Brian
Brian, At 01:48 PM 4/15/99 +0100, Brian E Carpenter wrote:
* The biggest concern left was the slow start procedure within the sTLA. * It was discussed at length but no agreement could be reached. The * registries want to have some kind of control against allocations that * are given out that are not used as they are supposed to be used, while
One other reason is that if all organisations/networks have the same prefix length ISPs will have difficulties to make rationale routing decisions if that may be necessary in the future.
Well hang on a moment. sTLAs are intended for ISPs and exchange points, and we're expecting them all to show up in the default-free table. I don't see your point.
It is a built in discriminator for the future. That is, if in the future the larger ISPs with sTLAs decide to not carry routes for lesser sTLAs, they make their cut on length of prefix. I've been getting lots of flack from ESnet engineering staff for having any such built in discriminator (as if I had a choice :-). I had been skeptical at first that this was the intent, but increasingly I see that their fears are justified by comments such as Mirjam's. TO say the least, I don't like it. It is basically the large (which often means more financially influential) being able to automatically discriminate against small. If it was simply a way to avoid ultra large routing tables, maybe it could be justified, but the hidden agenda that appears more and more in the v4 world is for large ISPs to muscle the smaller into paying for peering/connectivity. It would be nice if v6 could stay as neutral as possible on this, and at least not give overtly obvious ways to encourage such behaviour. Bob
Right. Well, I still want to see the revised text before I rush to judgement. Brian Bob Fink wrote:
Brian,
At 01:48 PM 4/15/99 +0100, Brian E Carpenter wrote:
* The biggest concern left was the slow start procedure within the sTLA. * It was discussed at length but no agreement could be reached. The * registries want to have some kind of control against allocations that * are given out that are not used as they are supposed to be used, while
One other reason is that if all organisations/networks have the same prefix length ISPs will have difficulties to make rationale routing decisions if that may be necessary in the future.
Well hang on a moment. sTLAs are intended for ISPs and exchange points, and we're expecting them all to show up in the default-free table. I don't see your point.
It is a built in discriminator for the future. That is, if in the future the larger ISPs with sTLAs decide to not carry routes for lesser sTLAs, they make their cut on length of prefix. I've been getting lots of flack from ESnet engineering staff for having any such built in discriminator (as if I had a choice :-). I had been skeptical at first that this was the intent, but increasingly I see that their fears are justified by comments such as Mirjam's.
TO say the least, I don't like it. It is basically the large (which often means more financially influential) being able to automatically discriminate against small. If it was simply a way to avoid ultra large routing tables, maybe it could be justified, but the hidden agenda that appears more and more in the v4 world is for large ISPs to muscle the smaller into paying for peering/connectivity.
It would be nice if v6 could stay as neutral as possible on this, and at least not give overtly obvious ways to encourage such behaviour.
Bob
Bob Fink <fink@es.net> writes: It is a built in discriminator for the future.
Yes it is. I have been quite frank about this at the IETF. Look at it another way: Engineers agree that currently the one major concern when making adress space distribution policy is routing system complexity. This is governed by topology and the number of prefixes. Address space distribution policy can only address the number of prefixes. Experience shows that policies cannot ultimately establish an upper bound on the number of prefixes routed. Even worse, the number to design to is a moving target about which the IETF cannot even agree at a particular instant in time, let alone make predictions for the future. When a routing system problem is going to hit, providers will have to make a choice about which prefixes to drop. They will make that choice no matter what. They can base that choice on any consideration. We hope that the consideration will be somewhat rational and hopefully somewhat consistent across ISPs if it is based on a rational measure. The prefix length (amount of justified address space) is established by a policy established by community consensus and implemented by neutral and impartial entities, the registries. It is such a rational measure. If such a rational measure is not available there is a lot of room for instability and lots more room for arbitrary decisions. There are other desirable properties of the proposed policy, such as effective discouragement of stockpiling, etc for which I have not seen workable alternatives. But this is besides the point being discussed. Now Bob raises the concern that this measure could be used by the big guys to squeeze the smal ones even *without* a routing problem existing. I cannot see how this concern can be relevant because the big guys, or anyone else, can do this at *any* time based on *any* criteria. It is even being done now, i.e. small ones have to *pay* bigger ones to be routed. I'd be much more worried about the case where a routing problem exists but no rational descriminator and the routing problem will provide a perfect exuse for anyone to make arbitrary decisions. This is when the small guys will get squeezed. This is when it is an enourmous help if you can point to a rational and neutral measure. Daniel PS: I do not understand you presenting this as a hidden agenda. It has been out in the open and I have explained this to you personally during the last IETF.
Daniel, At 06:21 PM 4/15/99 +0200, Daniel Karrenberg wrote: ...
PS: I do not understand you presenting this as a hidden agenda. It has been out in the open and I have explained this to you personally during the last IETF.
Sorry to have given the impression that this is something I just found out about. You have definitely explained it to me and others at the recent IAB meeting, and I appreciate your taking the time to do that. Of course that doesn't mean that there is agreement with the approach. It was also the case that, at the IAB discussion, you and/or other RIR folk present felt that it might not be necssary to take this approach if we could control the land rush for TLAs/sTLAs (by methods such as 6bone prequalification and tough entry policies). Unfortunately this tack in the conversation wasn't folowed up due to time constraints. I have been waiting to see the next draft to see what the updated thinking of the RIRs is while also pursuing the 6bone prequalification process. However, I am concerned about this approach for more than the social policy stuff. When one does aggregation the way v6 does, it needs reasonably sized NLA space to provide a decent level of aggregatable hierarchy below the sTLA level for multiple levels of lower tier providers and their end-sites below them. With the /29 sTLA slow start, as specified in RFC 2450, there are only 19 bits of NLA to play with... a tight but reasonable tradeoff if one imagined a two- or three-level hierarchy (sTLA and one or two levels of NLA transits below). With a /35 sTLA it gets real tight as only 13 bits are left to play with. To summarize, I don't think the RIRs have any hidden agenda here, and do hope the RIRs don't use the /35 system and stay with the /29 the IETF process proposed to them. Thanks, Bob
At 10:31 AM 4/15/99 -0700, Bob Fink wrote:
Daniel,
At 06:21 PM 4/15/99 +0200, Daniel Karrenberg wrote: ...
PS: I do not understand you presenting this as a hidden agenda. It has been out in the open and I have explained this to you personally during the last IETF.
Sorry to have given the impression that this is something I just found out about. You have definitely explained it to me and others at the recent IAB meeting, and I appreciate your taking the time to do that. Of course that doesn't mean that there is agreement with the approach.
It was also the case that, at the IAB discussion, you and/or other RIR folk present felt that it might not be necssary to take this approach if we could control the land rush for TLAs/sTLAs (by methods such as 6bone prequalification and tough entry policies). Unfortunately this tack in the conversation wasn't folowed up due to time constraints. I have been waiting to see the next draft to see what the updated thinking of the RIRs is while also pursuing the 6bone prequalification process.
However, I am concerned about this approach for more than the social policy stuff. When one does aggregation the way v6 does, it needs reasonably sized NLA space to provide a decent level of aggregatable hierarchy below the sTLA level for multiple levels of lower tier providers and their end-sites below them. With the /29 sTLA slow start, as specified in RFC 2450, there are only 19 bits of NLA to play with... a tight but reasonable tradeoff if one imagined a two- or three-level hierarchy (sTLA and one or two levels of NLA transits below). With a /35 sTLA it gets real tight as only 13 bits are left to play with.
To summarize, I don't think the RIRs have any hidden agenda here, and do hope the RIRs don't use the /35 system and stay with the /29 the IETF process proposed to them.
Thanks,
Bob
Bob, I understand your concerns but I honestly think you can accomplish your goals using the slow start method. If an organization requesting address space can justify a larger block than a /35 for heirarchical reasons or other than they will receive it. I believe many organizations will start out *very* slow at first so I don't see a reason to issue the entire sub-tla. Instead, issuing a smaller block (8K+) will give the RIRs ample time to verify that the organizations are utilizing the space and sending reassignment info, etc. Kim Hubbard ARIN
Kim Hubbard wrote: ...
Bob,
I understand your concerns but I honestly think you can accomplish your goals using the slow start method. If an organization requesting address space can justify a larger block than a /35 for heirarchical reasons or other than they will receive it. I believe many organizations will start out *very* slow at first so I don't see a reason to issue the entire sub-tla. Instead, issuing a smaller block (8K+) will give the RIRs ample time to verify that the organizations are utilizing the space and sending reassignment info, etc.
Kim, This is the argument you gave us in Minn. and I bought it, as long as it is *not* transformed later into an excuse for sub-allocating the /29s and thereby inviting the creation of an IPv6 toxic waste dump. That's why I'm eagerly awaiting the exact wording of the new draft. Brian
I'll quickly summarize the IPv6 portion of the IP allocation policy WG held at the ARIN member meeting and the discussion held during the general membership meeting. The latest proposed draft seems to be acceptable to everyone. There was some discussion on the slow-start issue with one ARIN member wanting to receive the entire /29 instead of a /35. The rest of the WG and membership seemed to agree that an initial /35 would be okay. It was made clear that even if only a /35 was initially issued the remainder of the /29 would be held in reserve for future allocations to the organization. It was also clarified that if an organization can justify an initial allocation of more than a /35 they would receive more. The justification section of the document needed some numbers filled in so our members made some recommendations. All in all it was a good discussion and interest. As Mirjam said, you will see the document withing a day or so. Please let me know if you have any questions. Kim at 07:54 PM 4/14/99 +1000, Philip Smith wrote:
Hello Mirjam,
Can you or someone else who was at the meeting summarise the input received from the ARIN community to the 6bone and ipv6-wg lists? For those not present, the specific feedback would be most interesting/useful...
thanks!
philip --
At 00:56 14/04/99 +0200, Mirjam Kuehne wrote:
Dear colleagues,
We are aware that the promised deadline for the next IPv6 policy draft has passed. We are sorry for that delay and thank you for your patience.
The ARIN members met yesterday and today and were given the opportunity to discuss the proposed policies. During this discussion we received very good input. These comments are now being incorporated in the new draft and we expect to send this new version out in a couple of days.
Mirjam Kuehne RIPE NCC
participants (7)
-
Bob Fink -
Brian E Carpenter -
Daniel Karrenberg -
David Kessens -
Kim Hubbard -
Mirjam Kuehne -
Philip Smith