Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC]

I am against the use of existing public space being defined as private
on the following grounds.

1.  You cannot legitimately assign a block of space that is big enough
to solve the problem of large networks.  I use several /8 bogon ranges
for customers and Verizon Wireless said at the Google IPv6 conference
that they have 40 instances of 10.0.0.0/8 in their network.  If the
purpose of assigning new private space is to stem this behavior, the
size of the new private range should probably be /6 or better ...
which i do not believe is rational or achievable.

2.  The public IPv4 addresses are needed in the public Internet,
especially for developing nations that are bringing people on-line to
the Internet at a very brisk pace.

3.  It's all about business.  We should avoiding IPv6 should not be
free. I see 4 possibilities to deal with today's issue:

a.  BOGONs.  Not pretty, but they work for users and it does not block
services like IMS.  There is also an on-going operational cost of
getting off space (rotating your bogons) as it is assigned to RIRs or
announced on the Internet.  Been there, done that, it cost money, but
once again it works and there is a business case that accounts for
that risk and work.

b. n * 10.0.0.0/8, in the USA, AT&T and Verizon wireless do this many
times throughout the country.  Yes, IMS is held back because of it,
SIP B2BUA can used but they cost money, but once again the risks  and
complexity are accounted for.

c.  240/4.  IMHO, if something must be done for large private networks
that need IPv4, this it.   This way the large private network must
fully realize the cost of "operationalizing" the space without taking
from the public pool.

d.  IPv6-only networks with NAT64 / DNS64.  This option best
encourages the use of IPv6 and really gets network and application
designers focused on the end-game, not wallowing in some middle-state
of CGN / LSN / and endless NAT444.

Allocating un-tainted public IPv4 addresses to large networks will
slow the adoption of IPv6.  If these large networks must have new
space, they must run the business case that assumes the risk of
duplicate internal address (n* 10/8), duplicate external addresses
(bogon), operationalizing class E, or really going IPv6 (which can be
option d or dual-stack with a,b, or c).

IMHO, there should not be "free" option for avoiding IPv6.

Regards,

Cameron

On Mon, Jul 26, 2010 at 8:32 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
>
> In today's session we talked about OPS area making a recommendation against shared ISP addressing. I didn't remember if there was a document. There is, it just came out for Last Call review now. Please comment.
>
> -------- Alkuperäinen viesti / Orig.Msg. --------
> Aihe: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC
> Päiväys: Mon, 26 Jul 2010 06:33:59 -0700 (PDT)
> Lähettäjä: The IESG <iesg-secretary@ietf.org>
> Vastausosoite: ietf@ietf.org
> Vastaanottaja: IETF-Announce <ietf-announce@ietf.org>
>
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Additional Private IPv4 Space Issues '
>    <draft-azinger-additional-private-ipv4-space-issues-04.txt> as INFORMATIONAL RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2010-08-23. Exceptionally,
> comments may be sent to iesg@ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-azinger-additional-private-ipv4-space-issues-04.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19011&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>