I strongly support both of these drafts. Allocation of the /10 will have only minimal negative impacts on the community, if any. Almost all of the impacts raised in the objections to draft weil will occur whether or not draft weil is moved to BCP status. The difference is that with draft weil in place, most of them can actually be mitigated whereas no such mitigation will be possible without draft weil. Delaying draft weil is, in this case, roughly equivalent to refusing it because operators are going to have to start implementing CGN and other IPv4 exhaustion coping mechanisms whether the IETF is ready or not. The objections listed in Ron's sending this to IESG ballot are: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Taking each objection in order: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. The first part of this statement is true. The second half is not an entirely accurate characterization. What this /10 will do is enable carriers and ISPs to provide services to end users in a consistent manner that vendors can adapt to. Absent this shared transition space, the uses for this space will not magically disappear and all of the problems described will still exist. The primary resulting difference will be that it will consume more global unicast addresses and create more potential for collision and other negative consequences while simultaneously removing all hope of allowing vendors to provide mitigation in software. I am one of the biggest IPv6 cheerleaders in the industry, but, I also have to work within the framework of operational reality. We're going to run out of IPv4 before everyone is ready, whether we like it or not. ISPs are going to have to cope with some various forms of IPv4 services for their customers after exhaustion. No matter what, this will be a bad situation. Failing to allocate this /10 will make it worse. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. I'm not convinced this argument is true, but, it can be made about virtually any RFC reserving space. Any special use or conventional allocation can be used in a manner contrary to it's prescribed intent. Rejecting this request with strong support and definite need from the operational community will not prevent misuse of address space, it will create the inevitable increase in such misuse as providers are forced to scramble to the use of "dark space", re-use of global unicast space, and other less than ideal solutions for this purpose. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. I just don't see this. Nobody made this objection to the Documentation prefixes. Nobody made this objection to localhost getting a /8. Why is this special use request any more likely to encourage more such requests than any other? - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. All of the applications that will break if providers use this space will also break if providers use any of the following: RFC-1918 that collides with the customers internal network. Dark space Recycled Global Unicast Space Class E space The difference is that with this allocation, providers will all break in the same consistent way and vendors can mitigate the breakage through software upgrades in some (many) cases. Without this allocation, providers will use some random mixture of all of the above in an uncoordinated and undefined way, making it impossible for vendors to provide any mitigation to such breakage. Respectfully Submitted, Owen DeLong Co-author draft-bdgks IPv6 Evangelist Director Professional Services Hurricane Electric Member, ARIN Advisory Council The opinions contained here are my own and do not necessarily reflect the views of my employer, ARIN, or the ARIN Advisory Council. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf