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

From: Jinesh Doshi <[email-masked]>
Date: Wed, 1 Feb 2012 09:49:57 -0700 (MST)

I support the updates to this draft.

Jinesh

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Feb 2012 20:25:34 -0500 (EST)

> From: =?iso-8859-1?Q?M=E5ns?= Nilsson <[email-masked]>

    > We do not need another reason for people to delay v6 deployment. 

The last time this issue (CGNAT space) was discussed, we were asked not to
open this can of worms. I don't know if that request still holds, but
seriously, nothing good can come of a discussion on this topic. It will
just be a lot of rhetoric, and _zero_ minds will be changed.

	Noel

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 11 Feb 2012 09:15:48 +0100

On Fri, Feb 10, 2012 at 10:13:25PM -0500, Noel Chiappa wrote:
>     > I still strongly oppose the publication of this draft. In any form
>     > except a complete rewrite telling providers to use RFC1918 and be done
>     > with it.
> 
> If you have any good technical reasons for finding this a bad idea _other_
> than the supposed negative effects on IPv6 deployment, it would be useful to
> hear them. Are there any?

There is no case for it. Any space so allocated will, by tearing down
the last community restrains on address reuse, become an extension to
RFC1918. There are legitimate uses for unique v4 space as documented in
RIR policy and v4 sunset procedures. Let the /10 go there instead.

-- 
Måns

---

From: Mark Andrews <[email-masked]>
Date: Mon, 13 Feb 2012 09:11:30 +1100

Mark Andrews writes:
> 
> In message <[email-masked]>, =?iso-8859-1?Q?M=E5ns?=
>  N
> ilsson writes:
> > On Sat, Feb 11, 2012 at 08:39:03PM -0500, Noel Chiappa wrote:
> > >     > From: Doug Barton <[email-masked]>
> > 
> > >     > We already have a way to make collisions "very unlikely," don't use
> > >     > either of 192.168.[01]. =
> > 
> > > I gather that that's not desirable, because otherwise people wouldn't be
> > > asking for another block. Of course it could probably be made to work
> > > somehow - with enough thrust, etc, etc. But that's not the point - engine
> =
> > ering
> > > is (or ought to be) all about balancing costs and benefits.
> > 
> > Close. The cost to these late adapters without sensible business plans
> > will be higher if they aren't given this allocation.
> 
> How is this a "late adapter" problem?  You either have enough
> addresses to give every customer a IPv4 address or you don't.  If
> you don't have enough addresses you are going to have to use some
> sort of CGN whether that is NAT444 or AFTR or some other transition
> technology which shares IPv4 addresses.

And if you restrict it to those that do IPv4 literals there isn't much
other than NAT444 and AFTR and how many cpe's support B4 at this point?
 
> Isn't the IETF's preferred transition strategy still "dual stack"
> or are you thinking that ISP's that can't get enough IPv4 address
> have to go IPv6 only?
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 12 Feb 2012 18:41:56 -0500 (EST)

> From: Nilsson <[email-masked]>

    >> denying this block is likely to _accelerate_ usage of what space
    >> remains

    > What happened to

    >>> - See CGN deployed using various hacks (e.g. squatting on space)
    >>> - See CGN deployed using a block of space allocated for that purpose

    > ...that were the ONLY two choices we have?
    > Suddenly, you introduce a third.

No. 'Everyone allocating their own CGN block' falls under "various hacks" (i.e.
option i).

    > Let me quote from RIPE-530, the in-force allocation policy document
    > for RIPE NCC

Well, I guess European ISPs are going to be forced to squat, then (there are a
number of non-backbone-routed /8s allocated to things like intelligence
agencies, which are unlikely to appear on the backbone) - unless we can get a
common CGN block allocated from elsewhere.

	Noel

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 14 Feb 2012 09:16:03 +0100

Sorry Noel but I choice to reply public to this one.

On Mon, Feb 13, 2012 at 10:52 PM, Noel Chiappa <[email-masked]> wrote:
>    > IPv6 is The Key!
>
> If you think denying a CGN block will do anything at all to help IPv6,
> you're very confused.

quote out of context etc... but my change of mind from supporting this
draft to not supporting has nothing todo with IPv6 at all. Nothing.

It all boils down to RFC1918 space, there are 3 huge network blocks
there and double, tripple NAT work, just as well as CGN will (it will
break plenty of application either way).
* 10.0.0.0/8  ~16mill addresses
* 172.16.0.0/12  ~1mill addresses
* 192.168.0.0/16 ~65K addresses

I can't really see what difference another /10 will make really,
especially now that we're in essence out of IPv4 addresses. We're all
much better of with some pain  (address collision etc) during the
transition to IPv6 than to delay it even more.

And about your quote, yes we have to change to IPv6, there are at
currently no other options at all.

Sure there are plenty of not optimal design choice made, stupid things
(like we're wasting /64 due to EUI-64) etc etc, but that is an entire
other range of subject. Right now, we only have one real choice, move
to IPv6. Everything else is moving the pain around.

and for those that really really really want to continue to use IPv4,
well try to make 240/4 (E-class) usable... there you have an entire /4
instead of /10.
 240.0.0.0/4          Reserved for Future Use        [RFC1700, page 4]

I personally think that reservation should have been lifted years ago.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 14 Feb 2012 09:38:18 -0500 (EST)

> From: Roger Jorgensen <[email-masked]>

    > Sorry Noel but I choice to reply public to this one.

Ah, no, actually. Had you thought about it for a moment or two, you could
have realized that you could have made your point just as well without
publicly quoting my private email. But why am I not surprised?

    > there ... I can't really see what difference another /10 will make
    > really, especially now that we're in essence out of IPv4 addresses.

The issue is not whether it _can_ be made to work (in Milo's famous phrase,
'with enough thrust, anything will fly'). The issue is all about costs and
benefits.

Speaking of the costs, if we assign a block of size N, it's not as if N
people are not going to be able to get on the network as a result. To the
contrary, N*M people are going to be able to get on the network as a result.

Of course, the N would have had globally visible addresses, whereas the N*M
will not, but that dropoff in functionality does not seem to bother most
people: pretty much every wireless hub I've ever seen is also a NAT box. (I'm
not even sure if there's even a way to turn off the NAT functionality in the
one in our house - I don't recall one.) Given that most people are happy to
take the choice 'limited access is preferable to no access' in the wireless
case, I see no reason to doubt that they would, were they able to explicitly
make the choice, make the same choice here.

Allowing more people access to the Internet is a problem... how?

	Noel

---

From: james woodyatt <[email-masked]>
Date: Thu, 16 Feb 2012 09:54:22 -0800

everyone--

My position on this draft remains unchanged.  It is far too forgiving of the 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] proposal, which I regard as abominable.  That reason alone, in my judgment, is sufficient grounds that it should not be published.  I also share the concerns of most of the opponents of this draft.

My recommendation regarding this draft, to the people inside Apple who implement customer-edge router functions, is to ignore it.  It is too late to add the shared transition space to the list of special-use addresses excluded from use as 6to4 tunnel endpoints in all the units already deployed in the field.  Such a disruption to existing customer configurations is generally unacceptable behavior for software updates.  Also, while it might seem reasonable to add the new space to the list of special-use addresses only in *forthcoming* products that support a 6to4 tunnel router feature, that too is unlikely ever to happen. (Note well: we don't comment publicly about the features of unreleased products.)

Shorter james: this draft is a bad idea; please don't publish it.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking