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

From: Daryl Tanner <[email-masked]>
Date: Tue, 14 Feb 2012 14:19:41 +0000

I support this updated draft, and I am keen for this to be published as a
BCP.

I believe the amendments in this revision clarify the usage and intended
purpose of the shared transition space.

Daryl

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 14 Feb 2012 09:54:21 -0500

I also support this draft.

Donald

BCP.

-- 
Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: [email-masked]
Date: Tue, 14 Feb 2012 07:06:55 -0800 (PST)

> I support this updated draft, and I am keen for this to be published as a

+1

> purpose of the shared transition space.

+1

				Ned

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 11:19:12 -0500

I support this draft as updated.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Feb 2012 12:38:00 -0600

To the addressed folks who's messages appear below:

I'm not sure I understand what you're saying. There was some objection 
at the beginning of this thread by Wes George, Noel Chiappa, and Brian 
Carpenter. I agreed that the document could be misunderstood as 
encouraging the use of the space as 1918 space and proposed some 
replacement text. There seemed to be some agreement around that text. 
Are you now objecting to that replacement text and want -14 published as 
is? Do you think the document should say that the new allocation can be 
used as 1918 space? If so, please explain.

pr

On 2/14/12 9:06 AM, [email-masked] wrote:
> On Tuesday, February 14, 2012, Daryl Tanner<[email-masked]  <mailto:[email-masked]>>  wrote:

On 2/13/12 1:05 PM, Owen DeLong wrote:
> I support draft-weil as revised. There is a vital need for this to 
> move forward and the IETF should stop standing in the way and let ARIN 
> allocate the space already.

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: [email-masked]
Date: Tue, 14 Feb 2012 11:50:49 -0800 (PST)

> used as 1918 space? If so, please explain.

Not sure how a +1 to a statement saying "I support this updated draft, and I
am keen for this to be published as a BCP." can be interpreted in any but one
way, or for that matter how it can be stated much differently.

Anyway, to use different words, I would like to see the current draft 
approved and published as a BCP. Clear enough?

				Ned

---

From: Leif Sawyer <[email-masked]>
Date: Tue, 14 Feb 2012 10:57:24 -0900

Pete Resnick wrote:
> I'm not sure I understand what you're saying. There was some 
> objection at the beginning of this thread by Wes George, Noel 
> Chiappa, and Brian Carpenter. I agreed that the document 
> could be misunderstood as encouraging the use of the space as 
> 1918 space and proposed some replacement text. There seemed 
> to be some agreement around that text. Are you now objecting 
> to that replacement text and want -14 published as is? Do you 
> think the document should say that the new allocation can be 

On the first hand,  I do support draft-weil. I think I
understand the use cases enough to see that it *is* required,
especially for large MSO's, and potentially larger enterprises.

On the other hand, I can see the confusion regarding "using RFC-1918 space *for this purpose*"  vs  "use this space as *additional RFC-1918*.  The former just doesn't work due to
unmanaged overlap.   The latter *seems* like it should work,
but if you play it out until the first vendor starts releasing
equipment that uses it, you've now joined the first-case scenerio.

On the gripping hand, I hate the back-and-forth quibbling over the tiniest motes, hoping that the delays will just make the problem disappear...

So yes, lets please move this draft forward, with the text cleaning stating that it NOT be used as RFC-1918 space.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Feb 2012 14:09:16 -0600

> approved and published as a BCP. Clear enough?

Nope. Perhaps my question was unclear. I'll try and ask my question 
again with different words:

Do you, or do you not, object to the proposed change that changes the 
text from saying, "This space may be used just as 1918 space" to "This 
space has limitations and cannot be used as 1918 space"? Nobody on the 
list objected to that new text. That new text significantly changes -14. 
You have stated your support for -14. Do you object to changing the text?

pr

---

From: [email-masked]
Date: Tue, 14 Feb 2012 12:12:34 -0800 (PST)

> You have stated your support for -14. Do you object to changing the text?

I assumed the proposed change was in the current draft - isn't that how it's
supposed to be done? Anyway, I think the change is fine, but I also think
the draft is acceptable without it.

				Ned

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Feb 2012 12:35:12 -0800

> space has limitations and cannot be used as 1918 space"?

what silliness.  it will be used as rfc 1918 space no matter what the document
says.

nine years ago i was in bologna and did a traceroute out.  i was surprised 
to find that the isp was using un-announced us military space as rfc 1918 
space internal to their network.  this turns out to be common.

any thought that this is not just adding to rfc 1918 is pure bs.

randy

---

From: Leif Sawyer <[email-masked]>
Date: Tue, 14 Feb 2012 11:40:42 -0900

Randy Bush writes:
> in response to Pete Resnick, who wrote:
>> Do you, or do you not, object to the proposed change that 
>> changes the text from saying, "This space may be used just
>> as 1918 space" to "This space has limitations and cannot be
>> used as 1918 space"?
> 
> nine years ago i was in bologna and did a traceroute out.  i 
> was surprised to find that the isp was using un-announced us
> military space as rfc 1918 space internal to their network.
>  this turns out to be common.
> 

In that I completely agree with what Randy is saying, the point
that needs to be made is that this should not be officially
sanctioned as RFC-1918 space --  no manufacturer or programmer
should treat this netblock the same.

If some fly-by-night company chooses to use it on their own,
well, then they have chosen to operate outside the bounds of
the best-principles - exactly the same as in Randy's example.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2012 09:47:17 +1300

> what silliness.  it will be used as rfc 1918 space no matter what the document

Of course it will. My suggestion was to change the text to "is not intended
to be used" instead of "can be used", hoping that would be viewed as a
fair warning.
http://www.ietf.org/mail-archive/web/ietf/current/msg71596.html

    Brian

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Feb 2012 12:49:26 -0800

> the best-principles - exactly the same as in Randy's example.

and the packets will be very ashamed, right?

we can say all the crap we want, but it will be used as 1918 space and,
like 1918 space, bgp announcesments of it will leak.  get over it.

randy

---

From: Leif Sawyer <[email-masked]>
Date: Tue, 14 Feb 2012 11:56:12 -0900

Randy Bush writes:
> in response to me:
> we can say all the crap we want, but it will be used as 1918 
> space and, like 1918 space, bgp announcesments of it will leak.
> get over it.

And that's fine -- on a per-operator basis --  they chose their path.

What we're trying to avoid by explicitly NOT marking this as RFC-1918
space is  VENDORS  using it inside their equipment, thereby negating
the entire practical use of the space.

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Feb 2012 02:12:11 +0100 (MET)

> You have stated your support for -14. Do you object to changing the text?

I support the document _with_ that proposed change to discourage
the (ab)use of that ARIN /10 CGN space as 1918 space.

-Martin

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Feb 2012 19:26:27 -0600

On 2/14/12 2:35 PM, Randy Bush wrote:

> [...]

Of course it will be used as 1918 space. That's not the point of the text.

The text is saying, "You could read 1918 to say that we somehow promised 
that you would never be connected to a network run by someone other than 
yourself and see 1918 addresses on it. That's not an entirely 
intelligent reading, but we see how you can read it that way. So, if you 
built yourself a device where it isn't able to deal with 1918 addresses 
on its 'outside' interface that you were using on the 'inside' 
interfaces, we could see how that might happen. It was not at all smart 
of you to build your device that way, but you probably were technically 
within spec. Now we're adding some address space to the pool. It's not 
global and it's not routable, just the same as 1918 space. But we're 
letting you know right now: You *will* see these addresses on networks 
that you don't run. If you want to use this space the way that you used 
1918 space, peachy, but understand that if you're unable to deal with 
these addresses duplicating ones you're using, your device is toast. 
Deal with it."

Any thought that the text is saying something more than this is nonsense.

pr

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Feb 2012 10:50:21 +0900

> what silliness.  it will be used as rfc 1918 space no matter what the document

The difference is on how future conflicts can be resolved.

> space internal to their network.  this turns out to be common.

What if the military space is sold to public and announced?

Who is forced to renumber and why?

						Masataka Ohta

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 14 Feb 2012 21:28:31 -0500

>like 1918 space, bgp announcesments of it will leak.  get over it.

Sure, but with a well known address range, it's not just what one AS
leaks.. The other AS(s) can also block incoming.  That's one of the
benefits of a well known space for this.

For squat, good luck figuring out who is using what from where.

Victor K

---

From: Doug Barton <[email-masked]>
Date: Tue, 14 Feb 2012 19:39:31 -0800

> Of course it will be used as 1918 space. That's not the point of the text.

My first reply in this most recent version of the thread pointed out
that now that we're finally willing to admit that if a new block is
issued it will be used as 1918 space then that leads to the obvious
conclusion that the *best* we can do with this draft is to kick the can
down the road, which is not enough justification for actually doing the
allocation.

I'll resist the urge to repeat the other points that I've already
repeated too often. :)

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Feb 2012 08:08:55 +0100 (MET)

Victor Kuarsingh wrote:
> 
> "Randy Bush" <[email-masked]> wrote:
> >

Considering the huge amounts of unused IPv4 address space,
why is there a need for squat space at all?

Out of curiosity, I tried to configure interface addresses from
0/8 or 240/4, but neither my Linux nor my Windows boxen allowed me that.
And lots of CPEs are based on Linux.  And a lot of that equiment
is used _much_ longer than its firmware is maintained by its vendor!

Any idea how long it takes to grow such hardwired restrictions out of
an installed base?

I wish there was more forward thinking among implementors.

One can not complain about the squat use of *assigned* space when all
of the unassigned address ranges have been made totally unusable by
implementors of IPv4 network stacks.

-Martin

---

From: Owen DeLong <[email-masked]>
Date: Tue, 14 Feb 2012 14:39:11 -0800

I'm agnostic about the latest round of changes or not. I just want EITHER version to move forward soon!

Owen

On Feb 14, 2012, at 10:38 AM, Pete Resnick wrote:

> I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain.
> 
> pr
> 
>> On Tuesday, February 14, 2012, Daryl Tanner <[email-masked]> wrote:
>> I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already.
> 
> Pete Resnick <http://www.qualcomm.com/~presnick/>

---

From: Martin Millnert <[email-masked]>
Date: Thu, 16 Feb 2012 11:43:00 +0100

> Of course it will be used as 1918 space. That's not the point of the text.

No support.

For the various reasons people have put forth, and my own below, this
draft should not be put through.

> these addresses duplicating ones you're using, your device is toast. 

This is 100% matched by an allocation of globally unique space from a
RIR, shared by whoever the interested parties are. 
  The IETF *need not* specify any BCP on how to improve NAT444
"CGN"-scale alone, because such action is attached with high risk of
leading to a local maximum in a plot of the state of the Internet,
rather than towards a global maximum.

Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6
Transition" warns:
   Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
   Scale NAT, compounds IPv4 operational problems when used alone but
   does nothing to encourage IPv4 to IPv6 transition.  Deployment of
   NAT444 CGN allows ISPs to delay the transition and therefore causes
   double transition costs (once to add CGN and again to support IPv6).

The draft as written, makes no effort to require the RFC6264 or
equivalent approaches to a IPv6 transition, to the CGN deployments it
specifies v4 address space for. All carrot, no stick.
  I believe the state of the Internet would be much more reliably
improved by the RIRs each having (for the purpose of being able to serve
their own users) one /10 special allocation for this purpose, which they
can assign to multiple users upon demonstrating, under contract, they
are transitioning to IPv6 according to 6264, or equivalent.

As written there is no effort to mitigate the risk mentioned in the
quote above, and I can't support a draft that will hurt the Internet and
neither should you.

Best,
Martin

---

From: Chris Grundemann <[email-masked]>
Date: Thu, 16 Feb 2012 08:43:14 -0700

> quote above, and I can't support a draft that will hurt the Internet and

Apologies for my bluntness, but this argument is a complete
misinterpretation of the facts on the ground. This draft is not about
encouraging nor facilitating CGN deployments. Allocating a /10 for
inside CGN addressing use _will not_ make anyone deploy CGN who would
not have otherwise done so. Not allocating a /10 for inside CGN
addressing use _will not_ stop anyone from deploying CGN who would
have otherwise done so. In fact, neither you nor I nor the IETF can
stop operators who must deploy CGN for business continuity from doing
so. What we can do, is ensure that when those folks who must deploy
CGN do so, that they break the Internet as little as possible. And
_that_ is what this I-D seeks to accomplish. And that is why I support
it, and why you should too.

Cheers,
~Chris

-- 
@ChrisGrundemann
http://chrisgrundemann.com

---

From: Martin Millnert <[email-masked]>
Date: Thu, 16 Feb 2012 17:35:34 +0100

Dear Chris,

On Thu, 2012-02-16 at 08:43 -0700, Chris Grundemann wrote:
> misinterpretation of the facts on the ground. 

Taking:
   This draft is not about encouraging nor facilitating CGN deployments. 
   Allocating a /10 for inside CGN addressing use _will not_ make anyone
   deploy CGN who would not have otherwise done so. Not allocating a /10
   for inside CGN addressing use _will not_ stop anyone from deploying
   CGN who would have otherwise done so. 
+
   What we can do, is ensure that when those folks who must deploy
   CGN do so, that they break the Internet as little as possible. And
   _that_ is what this I-D seeks to accomplish.

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.

You seem to want me to believe that: 
  - there is a fixed set of networks, who are going to deploy either:
    - a sucky IPv4 network, or, 
    - a less sucky IPv4 network, 
  - it would be entirely depending on the passing of this draft, 
  - the failure of passing of this draft somehow will exclude from these
networks the possibility of obtaining non-RFC1918 space in another way,
for example as I outlined

The latter two points seem a bit far-fetched.

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).

   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.

Kind regards,
Martin

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Feb 2012 16:58:04 +0000

> The latter two points seem a bit far-fetched.

Martin,

Far-fetched - like all straw men.

> of limited scope -- I think it unlikely you've spoken to every network

More straw men.  Look, we're adults here: please present good arguments.

The bottom line for this ID is that address space will be required for CGN,
and rfc1918 doesn't cut it for reasons described in the ID.  This means
that the address space must come from somewhere else.  The choices are:

1. one or more shared pools allocated by RIRs/IANA/whatever
2. private pools, each of which come from the carriers' own address blocks

option #1 is by definition more efficient than #2.

At least one of the RIRs has indicated that they cannot assign this space
due to charter problems.

There is no particular reason to allocate this space on a regional basis,
unless for some reason you believe that you can force carriers only to use
this shared address space for specific purposes - and I cannot see why you
think that this is remotely feasible for shared address space.  Private
address space, perhaps.  But certainly not shared address space.

The core function of a RIR is to guarantee that if they allocate you a
bunch of numbers, that they haven't allocated the same bunch of numbers to
someone else.  Therefore by definition they have no particular authority
over the way that shared address space might be used internally by a carrier.

Incidentally, I support this draft.

Nick

---

From: Chris Grundemann <[email-masked]>
Date: Thu, 16 Feb 2012 10:09:25 -0700

> networks who are deploying it, or in what way they will deploy it.

Correct.

> The latter two points seem a bit far-fetched.

Not quite, let me try again.

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.)

> of limited scope -- I think it unlikely you've spoken to every network

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.

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.

> 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.

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...

Cheers,
~Chris

PS - See https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#section-2.2
for a more detailed analysis of these alternate options.

---

From: Martin Millnert <[email-masked]>
Date: Thu, 16 Feb 2012 18:16:42 +0100

Hi Nick,

On Thu, 2012-02-16 at 16:58 +0000, Nick Hilliard wrote:
> There is no particular reason to allocate this space on a regional
> basis, unless for some reason you believe that you can force carriers
> only to use this shared address space for specific purposes - and I
> cannot see why you think that this is remotely feasible for shared
> address space.  Private address space, perhaps.  But certainly not
> shared address space. 

I'm not sure why a contract with a RIR would be less enforceable than
this I-D. On the contrary, I think the chances of correct use are higher
in that scenario than the other.

It's just bits, you know. IPv4-code on the general internet certainly
won't care about these bits. Routing policy however, may.  I do not see
how having the BCP makes any difference, if the allocation comes from
the RIR in either case, provided there is at least one RIR which can
assign address space to an entity who will share it.

Best,
Martin

---

From: Martin Millnert <[email-masked]>
Date: Thu, 16 Feb 2012 18:38:30 +0100

Hi Chris,

> On Thu, Feb 16, 2012 at 09:35, Martin Millnert <[email-masked]> wrote:
<snip>
> > networks who are deploying it, or in what way they will deploy it.

.. 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>

> 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.

> already experienced the chain of events I outlined above.

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

> of my time is dedicated to creating this understanding. I do not make

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

> the best way to ensure a less broken Internet than any of the other

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.

> 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

---

From: David Conrad <[email-masked]>
Date: Thu, 16 Feb 2012 11:42:40 -0800

> 2. private pools, each of which come from the carriers' own address blocks

3. private pools, independently chosen by ISPs using some method from allocated space (aka squat space).

> option #1 is by definition more efficient than #2.

and option #1 is safer than option #3.

> There is no particular reason to allocate this space on a regional basis,

I'd say it would be silly to do so -- what would be the point?

> Incidentally, I support this draft.

One implication of draft-weil not being accepted is that it will likely accelerate IPv4 free pool exhaustion as the folks interested in draft-weil will simply go out and get blocks from their RIRs while they still can.  I will admit a small part of me finds this appealing as it would end the seemingly interminable rearrangement of deck chairs on the IPv4 address policy-wonk Titanic.

Regards,
-drc

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Feb 2012 22:15:22 +0000

On 16/02/2012 19:42, David Conrad wrote:
> One implication of draft-weil not being accepted is that it will likely
> accelerate IPv4 free pool exhaustion as the folks interested in
> draft-weil will simply go out and get blocks from their RIRs while they
> still can.  I will admit a small part of me finds this appealing as it
> would end the seemingly interminable rearrangement of deck chairs on the
> IPv4 address policy-wonk Titanic.

This deck-chair rearrangement stuff is as predictable as it is pointless.
The only good point about the ID is that at least it puts most carriers on
the same footing and gives them some level of ability to continue to
support their customers' ipv4 connectivity requirements.  In its absence, a
lot of providers will end up using even worse alternatives.

Nick