ietf
[Top] [All Lists]

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

2012-02-16 11:39:02
Hi Chris,

On Thu, 2012-02-16 at 10:09 -0700, Chris Grundemann wrote:
On Thu, Feb 16, 2012 at 09:35, Martin Millnert 
<martin(_at_)millnert(_dot_)se> 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

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>