I read the document again today for the first time in a while and went through the more recent threads on the ietf list. I have 2 main comments. First, where did the /10 figure come from? Why not a /16? Some justification is needed for a particular figure. Second, this will break stuff, and even though the document talks about it some, we are dreaming IMO if we think talking about the problems (and encouraging implementations to fix things) will have any impact. At least not in the next few years. The problem will happen with stuff deployed today, or already in the pipeline for deployment. So, this will cause things to break. I don't feel good about that, even if one accepts the argument that neither approach is painless and we're gonna have breakage anyway. E.g., breaking 6to4 seems like a bad thing to do for IPv6. E.g.,: ingress links. DNS queries for Shared CGN Space addresses MUST NOT be forwarded to the global DNS infrastructure. This is done to avoid having to set up something similar to AS112.net for RFC 1918 private address space that a host has incorrectly sent for a DNS reverse- mapping queries on the public Internet [RFC6304]. This is totally unenforceable. We will be forced to deal with this. Existing software that is massively deployed will do this. Saying MUST NOT here is kind of like some IETF document saying you MUST NOT use NAT. When configured with a Shared CGN Space address (or other address range not described in [RFC5735]), such devices may attempt to initiate 6to4. Since 6to4 includes the WAN IPv4 address embedded in its IPv6 address, should 6to4 traffic traverse a CGN, return traffic could be misdirected and not reach the originating router. Service Providers can mitigate this issue using a technology such as 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel]. When the address range is well-defined, as with Shared CGN Space, home router vendors can include Shared CGN Space in their list of special-use addresses (e.g., [RFC5735]) and treat Shared CGN Space similarly to private [RFC1918] space. When the WAN address is not well-defined, as in the case of Globally Unique space, it will be more difficult for home router vendors to mitigate against this issue. This won't happen for a long time (if ever). so counting on this seems like a dream. Finally, what this document/reservation does is shift pain around. I.e., moving pain felt by one party (if nothing is done) to another party (if this is done). Are we unfairly pushing the pain to people (e.g., CPE routers) to help the ISPs? How do we decide or justify who deserves the pain? I'm pretty ambivalent about recommending this document. I don't like it and I don't like the precedent it sets, particularly in pushing pain from one party to another. I do understand what the document is trying to do. I think it will result in some small amount of sharing of space (thus slightly reducing demand for IPv4 addresses), which is arguably a good thing. But the amount of address space we are talking about here is negligible in the overall scheme of things.... Thomas _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf