<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I think to some extent 4.10 attempted to do that.<div><br></div><div>I think that 116 is an attempt to do a little more of that. As it currently stands, there are no criteria</div><div>for 4.10 so arguably ARIN staff could either not be able to issue space for any technology under</div><div>existing 4.10, or, they may not be able to make any determination that any particular claimed</div><div>usage is not transitional.</div><div><br></div><div>As such, I think we need to do something to shore up 4.10. 116 was an attempt to do that while</div><div>not restricting the policy only to the technologies known now.</div><div><br></div><div>So, I think the closest you might be able to come to punting right now would be to support the</div><div>discussion petition for 116.</div><div><br></div><div>Owen</div><div><br><div><div>On Jul 29, 2010, at 10:18 PM, Andrew Dul wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
    Has anyone considered that maybe what we should do is just reserve
    the block for future use and not try to predict the future too much
    at this point and instead comeback after IPv4 exhaustion and then
    write an appropriate policy.  Yes this does kick the ball down the
    field, but it also allows the ability to have space to work with in
    the future to use for an appropriate use after IPv4 run-out.<br>
    <br>
    Andrew <br>
    <br>
    On 7/26/2010 1:49 PM, Hannigan, Martin wrote:
    <blockquote cite="mid:C8736CFE.A81C%25marty@akamai.com" type="cite">
      
      <font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
          <br>
          And a minor correction please. I meant proposal 116 v. 109
          when I referenced it.<br>
          <br>
          <br>
          On 7/26/10 4:37 PM, "<a moz-do-not-send="true" href="x-msg://455/cja@daydream.com">cja@daydream.com</a>" <<a moz-do-not-send="true" href="x-msg://455/packetgrrl@gmail.com">packetgrrl@gmail.com</a>>
          wrote:<br>
          <br>
        </span></font>
      <blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Owen,<br>
            <br>
            So do you feel that this is bad all around or just the
            minimum allocation unit needs to be changed to something
            smaller?  Others out there?  What are your thoughts
            regarding a minimum/maximum allocation size for this last
            /8?  <br>
            <br>
            ----Cathy<br>
            <br>
            On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <<a moz-do-not-send="true" href="x-msg://455/owen@delong.com">owen@delong.com</a>>
            wrote:<br>
          </span></font>
        <blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Marty,<br>
                      How do you expect anyone but the largest of the
              large and extra large<br>
              organizations to qualify for a /20 of IPv4 space under
              this proposal?<br>
              <br>
                      This is a really interesting way to attempt to
              reserve the last /8 for use<br>
              only by the largest organizations ARIN serves, but, I
              really don't think that<br>
              is good policy.<br>
              <font color="#888888"><br>
                Owen<br>
              </font><br>
              On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:<br>
              <br>
              ><br>
              ><br>
              > Hello PPML:<br>
              ><br>
              ><br>
              > Since it seemed to have been very helpful to vet the
              global policy idea on<br>
              > the list, I thought it might be helpful to use it to
              frame my non-support<br>
              > for 109. This is, just like the last time, very raw,
              but I expect to solicit<br>
              > some time during open policy hour to discuss a more
              polished version.<br>
              ><br>
              > A few points.<br>
              ><br>
              > - This idea takes us in the direction of actual
              transition<br>
              > - Define an acceptable use list<br>
              > - Seeks to address COSTS<br>
              > - Levels the playing field between small and large<br>
              > - Reserves an entire /8 for transition, not for
              business as usual<br>
              > - Counters the high priced "market" that is emerging
              by deferring it's need<br>
              ><br>
              > May not get us all the way through, but every month
              that we can avoid<br>
              > sending people to markets is a month of reduced costs
              IMHO. And it is about<br>
              > costs at this point. It's a given that it is going to
              happen.<br>
              ><br>
              > Too soon for "for" or "against", but most definitely
              open to feedback. Don't<br>
              > focus on the words, focus on the ideas. Feedback very
              much appreciated.<br>
              ><br>
              ><br>
              > --draft, group working comments removed for ease of
              read<br>
              ><br>
              > 1. Transition Pool<br>
              ><br>
              > ARIN will set-aside the final /8 allocated form the
              IANA to facilitate<br>
              > transition from IPv4 to IPv6. The resulting
              "transition pool" will become<br>
              > immediately available for allocations under this
              policy. This pool will be<br>
              > known as the "transition pool".<br>
              ><br>
              > 2. Minimum and Maximum Allocation Unit<br>
              ><br>
              > The minimum allocation unit will be a /20. The
              maximum allocation unit will<br>
              > be /15.<br>
              ><br>
              > 2. Allocation Method<br>
              ><br>
              > ARIN will determine and utilize the best method
              possible for allocations<br>
              > with the goal of maximizing what can be allocated
              balanced by minimum<br>
              > deaggregation.<br>
              ><br>
              > 3. Eligibility<br>
              ><br>
              > An applicant will become eligible to receive IPv4
              addresses from this pool<br>
              > when they meet the following requirements:<br>
              ><br>
              > 1. Applicant will provide a written plan detailing
              how the addresses will be<br>
              > used and on what devices.<br>
              ><br>
              > 2. Previous allocations or assignments under this
              policy must continue to<br>
              > meet the justification requirements of this policy.<br>
              ><br>
              > 3. Must have applied for, been approved, received and
              be utilizing an ARIN<br>
              > allocated IPv6 allocation or assignment.<br>
              ><br>
              > 4. All allocations or assignments made under this
              policy must be efficiently<br>
              > utilized to a rate of 80%.<br>
              ><br>
              > 5. Applicant must demonstrate that no other
              allocations or assignments that<br>
              > they have received will meet their requirements.<br>
              ><br>
              > 6. Applicants must provide documentation that
              demonstrates that the<br>
              > addresses received under this policy will be used
              only on dual stack devices<br>
              > that will have both an IPv4 and IPv6 address that
              will both be reachable<br>
              > natively.<br>
              ><br>
              > 7. Be in compliance with Section 4, Acceptable Use of
              Addresses.<br>
              ><br>
              ><br>
              > 4. Acceptable Use of Addresses<br>
              ><br>
              > 1. A single IPv4 /32 for providers to assign to 6 to
              4 NAT gateways for each<br>
              > each layer 3 contagious v6 only customer networks
              thereby enabling IPv4<br>
              > connectivity for an IPv6-only customer networks.
              Customers must not have<br>
              > available IPv4 addresses.<br>
              ><br>
              > 2. A single IPv4 /32 for providers to assign to 4 to
              4 NAT gateways for each<br>
              > each layer 3 contagious v6 customer networks to
              deploy IPv4 RFC-1918 in<br>
              > addition to (and NOT instead of) IPv6 thereby
              enabling IPv4 connectivity for<br>
              > an IPv6-only customer networks.. Customers must not
              have available IPv4<br>
              > addresses.<br>
              ><br>
              > 3. Customer networks qualifying under 4.1 or 4.2
              (above) may qualify for<br>
              > additional IPv4 address to meet multi-homing traffic
              engineering needs or to<br>
              > address stand-alone NAT devices as specified below:<br>
              ><br>
              > A. A single IPv4 /32 for each interconnect for each
              mult-homed layer 3<br>
              > contiguous customer network that requires traffic
              engineering. For example a<br>
              > network with two interconnects to a single upstream
              provider can get one<br>
              > IPv4 /32 for each of their two interconnects, and
              distribute their internal<br>
              > hosts between the two outside NAT addresses for
              traffic engineering.<br>
              ><br>
              > B. Customer networks that require stand-alone NAT
              devices (not integrated<br>
              > into their CPE router) qualify for enough IPv4
              addresses to number the<br>
              > loopback addresses (if needed) for all edge routers
              that have one or more<br>
              > connections to a transit provider, enough IPv4
              addresses to number each of<br>
              > the point-to-point links between those routers and
              their transit provider,<br>
              > as well as the point to point links between those
              routers and directly<br>
              > connected NAT appliances. As well as one IPv4 address
              for each of these<br>
              > directly connected NAT appliances.<br>
              ><br>
              ><br>
              > 4. Loopback addresses for edge routers that have one
              or more connections to<br>
              > transit providers and/or peers<br>
              ><br>
              > 5. Address for point to point links between edge
              routers and their transit<br>
              > providers [why does it need to be unique v. 1918?]
              [that is an interesting<br>
              > point... We use globally unique as a matter of not
              breaking routing by<br>
              > accident. I have to think about if it would be
              generally acceptable to use<br>
              > RFC-1918. Interesting question!]<br>
              ><br>
              > 7. A /32 for routers in a greenfield network that are
              dual stacked.<br>
              > [redundant to 3/5?] [this is not redundant... In this
              case I need an IPv4<br>
              > routerID to make BGP work. If I want to be a
              green-filed IPv6 transit<br>
              > provider I need one IPv4 address for each router]<br>
              ><br>
              > 8. /32 for public facing name servers, NTP servers,
              SMTP servers and Web<br>
              > servers which are dual stacked and reachable on IPv4
              and IPv6 networks.<br>
              ><br>
              > 9. Dual stacked VPN aggregation ex. v6 -> v4 one
              IPv4 /32 per VPN aggregator<br>
              ><br>
              ><br>
              > 5. Reservation Forecasting<br>
              ><br>
              > An applicant may provide ARIN with a thirty-month
              forecast of IPv4 address<br>
              > need. ARIN will reserve the requested size in
              compliance with Section 2 and<br>
              > 3. When a reservation forecast is approved by ARIN,
              the applicant will then<br>
              > be authorized to draw down from the forecast
              quarterly. Prior to requesting<br>
              > reserved addresses, applicant will provide
              documentation to ARIN that they<br>
              > have maintained utilization requirements for previous
              allocation. If<br>
              > applicant fails to meet utilization requirements for
              two consecutive<br>
              > quarters, ARIN will cancel the reservation and return
              unused addresses to<br>
              > the pool.<br>
              ><br>
              ><br>
              > Example:<br>
              ><br>
              > Applicant applies to ARIN under this policy and
              submits a thirty-month<br>
              > forecast requesting a /16. Using criteria established
              in the NRPM and this<br>
              > policy, ARIN will determine if applicant is eligible
              and has need. If the<br>
              > applicant meets the requirements for the allocation,
              they will reserve a<br>
              > /16. The applicant will then be allocated 3/30th of
              the forecasted<br>
              > requirement in a CIDR block or equivalent number of
              IPv4 addresses. ARIN<br>
              > will round down allocations or assignments to the
              closest CIDR single block.<br>
              > Rounding errors will be applied to the last
              allocation of the last quarter<br>
              > of the thirty month period and allocated then.<br>
              ><br>
              ><br>
              > 6. Dual Stack Requirement<br>
              ><br>
              > Addresses from this pool may only be used on dual
              stack devices that are to<br>
              > be reachable via both IPv4 and IPv6 networks.<br>
              ><br>
              ><br>
              > 7. Application Frequency<br>
              ><br>
              > Applicants may apply for address space from the
              transition pool once per<br>
              > quarter. If an applicant has an existing thirty-month
              forecast that has been<br>
              > approved by ARIN, they are ineligible to apply for
              more address space until<br>
              > their reservation has been exhausted. If an applicant
              has had a reservation<br>
              > cancelled due to policy compliance issues including
              utilization, they are<br>
              > not eligble to apply for addresses.<br>
              ><br>
              ><br>
              > 8. Post Exhaustion Refresh<br>
              >> From the point of the issuance of the final /8
              from the IANA, ARIN will<br>
              > dispose of all address space that it may receive
              using this policy.<br>
              ><br>
              > _______________________________________________<br>
              > PPML<br>
              > You are receiving this message because you are
              subscribed to<br>
              > the ARIN Public Policy Mailing List (<a moz-do-not-send="true" href="x-msg://455/ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
              > Unsubscribe or manage your mailing list subscription
              at:<br>
              > <a moz-do-not-send="true" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
              > Please contact <a moz-do-not-send="true" href="x-msg://455/info@arin.net">info@arin.net</a> if you experience
              any issues.<br>
              <br>
              _______________________________________________<br>
              PPML<br>
              You are receiving this message because you are subscribed
              to<br>
              the ARIN Public Policy Mailing List (<a moz-do-not-send="true" href="x-msg://455/ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
              Unsubscribe or manage your mailing list subscription at:<br>
              <a moz-do-not-send="true" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
              Please contact <a moz-do-not-send="true" href="x-msg://455/info@arin.net">info@arin.net</a> if you experience
              any issues.<br>
            </span></font></blockquote>
        <font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
            <br>
          </span></font></blockquote>
      <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact info@arin.net if you experience any issues.</blockquote></div><br></div></body></html>