ietf
[Top] [All Lists]

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

2011-10-09 20:52:30
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" <narten(_at_)us(_dot_)ibm(_dot_)com> 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC, Chris Donley <=