Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

[Chris Donley <[e-mail]>]

Thomas,

1) When we were developing the original draft-weil request for a /8, we
estimated that the total aggregate demand for Shared CGN Space is about
~40 million addresses worldwide. A /8 would allow most ISPs to deploy CGNs
without address overlap within their networks. As a compromise to the
community, we changed our request to a /10 in Beijing.  In our talks with
a lot of service providers, a /10 is the smallest block that will allow
for a regional CGN deployment for many service providers without nested
CGNs (e.g. NAT4444). Also, draft-shirasaki-isp-shared-addr demonstrates a
similar need, showing that a /10 was able to satisfy metropolitan areas in
Japan. 

2) Yes, Shared CGN Space breaks 6to4 (unless you use 6to4-PMT), but so
does any non-RFC1918 space including squat space and public GUA in a CGN
environment. We've tested it, and included this analysis in the latest 2
versions of the draft (-07 and -08).  Based on our testing, 6to4 is the
only application we've discovered that breaks specifically due to the
address range between the CPE router and CGN (see
draft-donley-nat444-impacts for other applications that are affected in a
CGN environment). None of the ISPs I've spoken with are planning to use
1918 space behind the CGN, which leaves global unicast space, Shared CGN
Space, and squat space.  All three cause the same impact to 6to4, and of
the three, Shared CGN Space offers the best hope of fixing it by agreeing
on a common address range.  Yes, it will take some time before router
vendors include Shared CGN Space in their 6to4 code, but I believe that
it's better than the alternatives, for which the only solution is 6to4-pmt.

Chris    
-- 
Chris Donley
CCIE, CISSP, SCiPM
Project Director - Network Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO 80027
303-661-3480 (v)
303-661-9199 (f)






On 9/30/11 5:14 PM, "Thomas Narten" <[e-mail]> wrote:

>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ietf