Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Martin Millnert <[e-mail]>]

Hi Chris,

On Thu, 2012-02-16 at 10:09 -0700, Chris Grundemann wrote:
> On Thu, Feb 16, 2012 at 09:35, Martin Millnert <[e-mail]> wrote:
<snip>
> > you seem to be of the opinion that improving the feasibility of CGN, by
> > making it suck less, will not have any impact on potential set of
> > networks who are deploying it, or in what way they will deploy it.
> 
> Correct.

.. except for the part of actually changing what addresses they put on
the inside, which the I-D is about.  Perhaps it's splitting hairs
whether that constitutes a "change" or not, but if it's not a change,
it's weird that it would improve the quality of the network. :-)

<snip>

> I am stating that:
>  - Dual-Stack requires both IPv4 and IPv6 addresses
>  - There is a non-zero number of networks which will exhaust all
> available IPv4 resources before the world is able to fully transition
> to IPv6
>  - These networks must choose one of either:
>   -- Go out of business
>   -- Find a new way to provide IPv4 connections to customers
>  - NAT44* CGN will be chosen by a non-zero number of these networks
>  - This decision is independent of what addresses they will use inside
> of the CGN (No one wants to go through two transitions. Folks who
> deploy CGN do so because they must. As such, the addresses used are an
> afterthought. The cost of CGN and it's alternatives are what drive the
> decision, not this I-D or the addresses it seeks to reserve.)

In the end, I suppose, networks who do not also roll-out DS in
combination with NAT44* CGN, are a blessing for their competition...
where such competition physically exists.

> > I'm curious how you can possibly have sufficient knowledge to make those
> > statements as *facts*, rather than opinions, informed as the may be (but
> > of limited scope -- I think it unlikely you've spoken to every network
> > on the planet).
> 
> You are again correct, I have not spoken to every network on the
> planet. I have spoken to many. Several in the Asia/Pacific region have
> already experienced the chain of events I outlined above.

Check. (I'm aware, as well.)

> Further, my job is to understand the IPv6 transition and as such, much
> of my time is dedicated to creating this understanding. I do not make
> these claims lightly.

Cool. I haven't/certainly didn't mean to suggest you did.

> >   In fact, neither you nor I nor the IETF can stop operators who must
> >   deploy CGN for business continuity from doing so.
> >
> > I hold no such illusions.  What the IETF ought to do however, IMHO, is
> > to point them in a good direction. I don't see that happening in this
> > document.
> >
> > A less-sucky IPv4-run-out access network is still a local maxima
> > compared to the global maxima of DS.
> >  Convince me that our journey to reach the global maxima will not be
> > negatively affected by this document, and gain my support.
> 
> Once an operator has decided that they have no other choices remaining
> and that they must deploy CGN, they then have to decide how to
> architect that deployment. One of the architectural decisions to be
> made (and the one we are concerned with here) is what addresses to use
> within the CGN. They have several options:
> 
> - Globally Unique "Public" Addresses
> This option burns addresses that they or others could use to number
> devices that actually require a unique address, this is a net loss to
> the Internet.
> 
> - RFC 1918 "Private" Addresses
> The chance for collision and the low margins of residential broadband
> make this option a non-starter. Nothing any of us say will convince
> any substantial number of operators to shoot themselves in the foot in
> this way.
> 
> - Class E Addresses
> Too much equipment is hard coded to reject these addresses. It simply
> will not work in time to make a difference.
> 
> - "Squat" Addresses
> Without a shared address space, this is the likely winner. Squatting
> on someone else's address space works and is free. A misconfigured
> filter allows these to leak however, another net loss to an un-borked
> Internet.
> 
> - "Shared" Addresses
> This is the solution put forth in the I-D under discussion here. This
> allows an alternative that is attractive to operators and can be
> managed (since it is a known prefix). If one operator leaks routes,
> others will have filters in place. This option removes the least
> amount of addresses from the remaining free pools thus allowing
> Dual-Stack to work in the most possible networks. All in all, this is
> the best way to ensure a less broken Internet than any of the other
> options can provide.

Not seeing a limitation to NAT444, you left out various alternatives
which have integrated IPv6/DS. Alternatives which, once installed, will
lead to a steady (comparing with the v4-only case) reduction in load on
the CGN equipment, as the world increasingly moves towards DS/v6-only. 

Such alternatives may not apply to the CGN variant NAT444, which I ACK
the I-D addresses.

> Again, we are not talking about encouraging or discouraging CGN use,
> that is outside the scope of this discussion. What we can do is "point
> them in a good direction" when they must deploy it...

I agree, and would like the direction we point them in to include the
case for DS.  There's always the risk there are very ill-advised
networks around, who push through such upgrades without simultaneously
enabling (a gradual roll-out of) DS, perhaps for nothing else than lack
of sufficient knowledge!

Thanks!

Best,
Martin