I echo Owen and JF's comments Given the available options, the dedicated /10 provides the least problematic solution.
If the address space used by CGN is standardised, and identifiable then it can be managed appropriately by everyone in a consistent way. The sooner this is adopted, the easier it becomes to manage. Daryl On 30 November 2011 17:13, <jean-francois.tremblay...@videotron.com> wrote: > > I'd like to thank Owen for explaning his point of view with such clarity > and I'd like to concur with him by rephrasing in my own words (most of this > has already been said by others thought). > > Taking the objections in order, again: > > 1. Allocation of a special-use /10 does not hasten the deployment of IPv6. > It only extends the life of the IPv4 network. > > Indeed. This affirmation is entirely true IMHO. However the stone-cold > reality is that IPv6 is not yet ready despite huge multi-years efforts by > the community and many service providers (speaking by experience here). The > huge IPv4-only installed base and the lack of IPv6 support by vendors can't > be ignored wherever the blame is put. > > 2. 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. > > Of course. Mark has pointed it out already, we don't need the prohibition > to be *enforced*, only to have it *written* in the document. If a > provider's client complains of overlap, then the burden of renumbering is > on him, not on the ISP or anybody else. > > 3. If a special-use /10 is allocated, it will encourage others to request > still more special-use address space. > > I doubt "others", whoever they are, will have 1) sufficient justification > and 2) time to do so. > > 4. 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. > > Applications will break anyway with squat space or multiple overlapping > RFC1918 space. As Owen and others pointed out, at least with a known prefix > it can be fixed in a consistent manner. > > CGN will happen and is already happening now because it's the only > rational way to keep a service provider business running, whether one like > it or not. Dedicated addressing space will only make this deployment > cleaner than if it's done with squat space. > > In my very humble opinion, draft Weil is definitely the lesser of to evils > here. Just as an example, what suspiciously looks like squat space can be > seen now (*>i47.154.0.0/16 ... 3561 701 9929 4808 4808 i). At least with a > dedicated prefix it can be properly filtered and blackholed. > > These were my 2 (Canadian) cents. > > JF Tremblay > Long time IPv6 enthusiast and Sr IPv6 Engineer at Videotron > > (The opinions contained here are my own and do not necessarily reflect the > views of my $employer or any other affiliation) > > > > 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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > >
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
