<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I am fully opposed to any proposal that allows ARIN to set the expectation that anything longer than a /24 will be reachable. </div></div></blockquote><div><br class=""></div>You misunderstand the situation.</div><div><br class=""></div><div>The existing policy allows for /28s to be allocated from this /10. It does not set any expectations about reachability.</div><div><br class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">It is the long standing practice that such a small allocation is provided by the upstream from an aggregate block. </div></blockquote><div><br class=""></div>It is the long standing practice that upstreams have blocks to assign. It is the long standing practice that when they run out, they can go back to the RIR for more. These practices are coming to an end. The question is how to best handle supporting new entrants during the endgame.</div><div><br class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I will not be updating my prefix list filters and expanding my RIB if this passes. Those RIB spots are for ipv6, not another attempt at cgn / ipv4 life support. </div></blockquote><div><br class=""></div>I’d settle for you fixing IPv6 for iPhone users on your network. It currently doesn’t work. Insisting that Apple implement your particular favorite transition mechanism rather than providing a dual-stack solution does not, IMHO, allow you to blame Apple for this deficiency. (I say this as one of your customers)</div><div><br class=""></div><div>In any case, the proposal is to eliminate the current /28 possibility and limit allocations from this block to /24. As such, I think you are in support of the proposal though your expression of opposition to the current policy as if it were a proposal is somewhat confusing.</div><div><br class=""></div><div>Owen</div><div><br class=""></div></body></html>