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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf