Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

From: Keith Moore <[email-masked]>
Date: Fri, 23 Sep 2011 21:20:13 -0400

I already made one Last Call comment, but I neglected to state unambiguously whether I supported the proposal.   

I do support this proposal.

I think that this question needs to be viewed as a choice between two risks:

1) the risks associated with this proposal
2) the risks associated with reuse of RFC 1918 address space by ISPs, and/or reuse of public IPv4 address space by ISPs

To me it seems clear that the risks associated with this proposal are less than the other risks.  Software that assumes that IPv4 space other than RFC 1918 space is unambiguous will break in either case.  But at least with this proposal, there's a well-defined and easily-understood path to fix such software to minimize the breakage.   

It needs to be understood that at this point, there is no path that will avoid widespread breakage of much existing IPv4-based software, including some software that is widely used.  Upgrades to that software will be needed in order to continue using such software on a widespread basis.  

Furthermore, even with such upgrades, the reliability of IPv4-based applications can generally be expected to decrease over time.   There is no path to permit IPv4-based applications to continue to be used reliably, at Internet scale, over the existing Internet infrastructure.

Keith

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 23 Sep 2011 18:53:46 -0700

On Sep 23, 2011 6:20 PM, "Keith Moore" <[email-masked]> wrote:
>
> I already made one Last Call comment, but I neglected to state
unambiguously whether I supported the proposal.
> 2) the risks associated with reuse of RFC 1918 address space by ISPs,
and/or reuse of public IPv4 address space by ISPs
>
> To me it seems clear that the risks associated with this proposal are less
than the other risks.  Software that assumes that IPv4 space other than RFC
1918 space is unambiguous will break in either case.  But at least with this
proposal, there's a well-defined and easily-understood path to fix such
software to minimize the breakage.
>
> It needs to be understood that at this point, there is no path that will
avoid widespread breakage of much existing IPv4-based software, including
some software that is widely used.  Upgrades to that software will be needed
in order to continue using such software on a widespread basis.
>
> Furthermore, even with such upgrades, the reliability of IPv4-based
applications can generally be expected to decrease over time.   There is no
path to permit IPv4-based applications to continue to be used reliably, at
Internet scale, over the existing Internet infrastructure.

So if there is going to be breakage, and folks are willing to fix it over
time because the good outweighs the bad (I personally do not believe this),
then why not dedicate 240/4 for this purpose?

The 240/4 work has been shot down multiple times ( I don't know the history
), are we now changing the rules for the end run ?

For my use case, a /10 does nothing.  I use tens of /8s of squat space...  A
/4 would really help... or having everyone really moving vendors and
networks to ipv6....because they have to.... if this draft goes through,
there is clearly less business pressure to solve the numbering problem and
there will be new business pressure to roll out nat444

Furthermore, I find this draft's statements about "we are trying real hard
to deploy ipv6" as not convincing... we are 10 years in on v6, no?

I only seriously deployed ipv6 when it was clear the business had to deploy
ipv6.... there were no other choices.

ARIN is looking for the IETF to bless this because they know it's bad, they
know this is a step in the wrong direction.... but the IETF made me do
it....

Cb

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 23 Sep 2011 22:03:30 -0400

On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote:
> So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose?
> 
> The 240/4 work has been shot down multiple times ( I don't know the history ), are we now changing the rules for the end run ?
> 
It's hard to know for sure, but I believe there's greater risk associated with use of 240/4 than with a /10 from existing public IPv4 space.  That is, I think more software would be needed to allow 240/4 to be used reliably.
> For my use case, a /10 does nothing.  I use tens of /8s of squat space...  A /4 would really help... or having everyone really moving vendors and networks to ipv6....because they have to.... if this draft goes through, there is clearly less business pressure to solve the numbering problem and there will be new business pressure to roll out nat444
> 
The IPv4 numbering problem isn't going to be solved.  Solving that problem is much more difficult than migrating to IPv6.  It's not for lack of business pressure; it's just inherently easier to build a new network with new address space, than to add another layer of indirection to the existing IPv4 network.  If we were going to tackle the IPv4 address exhaustion problem by adding another layer of indirection, we needed to get started on it about 20 years ago when there was still a considerable amount of IPv4 space left to work with.  For better or worse, that's not what happened.
> Furthermore, I find this draft's statements about "we are trying real hard to deploy ipv6" as not convincing... we are 10 years in on v6, no?
> 
> I only seriously deployed ipv6 when it was clear the business had to deploy ipv6.... there were no other choices.
> 
> ARIN is looking for the IETF to bless this because they know it's bad, they know this is a step in the wrong direction.... but the IETF made me do it...
> 
To me, it doesn't look like a step in the wrong direction.  The only argument I can see against allocating this space is that it will prolong the life of IPv4 and CGN.   But on balance, I think that's probably necessary, distasteful though it may be.

Keith

---

From: "Benson Schliesser (bschlies)" <[email-masked]>
Date: Sat, 24 Sep 2011 10:35:57 -0500

> So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose?
240/4 would be very useful if designated unicast. We should do that, in my opinion. But it's not immediately deployable. It can't be "fixed over time" in the sense that a prefix reserved from GUA might be; that is, it can't be deployed today and fixed over time. Rather, 240/4 is only useful after the fix is deployed.

For what it's worth, to my knowledge none of the co-authors of draft-weil or draft-bdgks have ever expressed any love for the architectural impact of CGN. We all agree that IPv6 is the best choice from a forward-looking perspective. But we also know that the short-term needs of some service providers are driving them to deploy CGN as NAT444.

This reservation may help make it less broken. But one concerned over IPv6 deployment may take solace in the fact that, even in the best case, CGN will be worse than native IPv6 in multiple dimensions. Just because I'm putting on a bandage today, doesn't mean that I consider it a good long-term solution.

Cheers,
-Benson

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 24 Sep 2011 09:24:43 -0700

>
> 240/4 would be very useful if designated unicast. We should do that, in my
opinion. But it's not immediately deployable. It can't be "fixed over time"
in the sense that a prefix reserved from GUA might be; that is, it can't be
deployed today and fixed over time. Rather, 240/4 is only useful after the
fix is deployed.
>
> For what it's worth, to my knowledge none of the co-authors of draft-weil
or draft-bdgks have ever expressed any love for the architectural impact of
CGN. We all agree that IPv6 is the best choice from a forward-looking
perspective. But we also know that the short-term needs of some service
providers are driving them to deploy CGN as NAT444.
>
> This reservation may help make it less broken. But one concerned over IPv6
deployment may take solace in the fact that, even in the best case, CGN will
be worse than native IPv6 in multiple dimensions. Just because I'm putting
on a bandage today, doesn't mean that I consider it a good long-term
solution.
> -Benson

Let's avoid having yet another thread where there is no consensus but the
parties continue to restate their claims over and over.

I don't see anything new in what you wrote.

Things happen fast when revenue is on the line.

Now, if you are in the business of selling ipv4 address space on the
secondary market, as folks have linked to you before on the nanog list, you
must like the idea of pushing out ipv6 deployment in favor of the broken
nat444 ipv4 ecosystem.... platitudes about ipv6 aside.
Here you claim to be "friends" with ipv4 black-marketeers
http://diswww.mit.edu/charon/nanog/139751

The ietf must stick to the guidance that ipv6 replaces ipv4, not that shady
black markets and middle boxes replace ipv4.

Now, my motivation -- I have taken the ietf guidance and have laid the
ground work for deploying ipv6 to mass consumers in the near term. The ietf
has been unequivocal that ipv6 is the path forward for years. As an ipv6
network, I am subject to Metcalfe's law... meaning, if I am the only one
doing v6 I am in bad shape, but if everyone else has been listening to the
ietf in good faith, then ipv6 will be deployed soon (as ipv4 depletes) and
Metcalfe's law is a fortuitous cycle of compound benefits for me, ipv6
networks, and ipv6 users.

And, conversely, efforts to prolong ipv4 are a direct inhibitor to my short
term and medium term benefits in deploying ipv6.  The IETF prolonging IPv4
with this effort is changing the rules of the game and overturning well
known and long standing precedent, including not joining 240/4 with public
or private pools.

Governing bodies should not overturn long standing precedent and change the
rules of the game at critical times where change is required.

Cb

---

From: Benson Schliesser <[email-masked]>
Date: Sat, 24 Sep 2011 12:13:20 -0500

> parties continue to restate their claims over and over.

Fair enough. We're discussing the reservation of a prefix; the context is a
foregone conclusion.

> http://diswww.mit.edu/charon/nanog/139751

Yes, I'm friends with many people. Some of them vote for the opposite
political party as me, some of them work for my competitors, etc. I may
agree with some friends, disagree with others, and even hold competing ideas
in my mind at the same time. Yet I remain my own person.

-Benson

---

From: John C Klensin <[email-masked]>
Date: Sun, 25 Sep 2011 09:42:40 -0400

--On Friday, September 23, 2011 21:20 -0400 Keith Moore
<[email-masked]> wrote:

> 2) the risks associated with reuse of RFC 1918 address space
> by ISPs, and/or reuse of public IPv4 address space by ISPs
>...
 
> It needs to be understood that at this point, there is no path
> that will avoid widespread breakage of much existing
> IPv4-based software, including some software that is widely
> used.  Upgrades to that software will be needed in order to
> continue using such software on a widespread basis.  

And that helps identify a third risk.  How relevant it is
depends on one's perspective and understanding of reality but
that risk is:

	3) People will conclude that these various kludges are
	actually medium-term solutions and will put resources
	into them that would have gone into deploying IPv6
	instead.  

As soon as you say "folks are going to need to go to the trouble
and expense of developing and deploying replacements for a lot
of installed-base IPv4 software, the resources involved become
significant and there are tradeoffs with other ways in which
those resources could be invested.

Remembering that an ISP who wants to avoid the use of public
IPv4 addresses on its backbone/infrastructure has the option of
simply converting that infrastructure to IPv6, tunneling
public-address IPv4 packets (both its own and those of its
customers) over that IPv6 infrastructure using a tunneling
approach of its choice. Longer-term, that approach makes the ISP
far more IPv6-ready, while "more private/shared IPv4 space" is
just another dead end.

Without commenting on the merits of this particular proposal
relative to other ways to squeeze a few more addresses out of
the IPv4 space, it seems to me that a lot of the presumed value
is ultimately a cost tradeoff.  If the squeezing technique buys
extra addresses and time at very low cost, then it is worth
considering (and comparing to other squeezing-out proposals).
If it requires changing enough deployed software and
infrastructure to start approaching IPv6 deployment costs, it
seems to me to be bad strategy and worse economics.

    john

> 
> Furthermore, even with such upgrades, the reliability of
> IPv4-based applications can generally be expected to decrease
> over time.   There is no path to permit IPv4-based
> applications to continue to be used reliably, at Internet
> scale, over the existing Internet infrastructure.
> 
> Keith
>

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 25 Sep 2011 15:57:56 +0200

On Sun, Sep 25, 2011 at 3:42 PM, John C Klensin <[email-masked]> wrote:
<snip>
<snip>
> those resources could be invested.

It is quite likely that resources will be used on prolonging IPv4
if there is a way of doing that, like putting this last netblock into
use. That just put IPv6 even further off and cause even more
trouble down the road.

However, if this proposal goes through and that last netblock
are assigned to use, how long will it take before anyone ask
the following question:

Why haven't that last netblock been put to use by the RIR earlier
and with that given us more time to prepare for IPv6?

-- 

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 25 Sep 2011 13:25:17 -0400

> far more IPv6-ready, while "more private/shared IPv4 space" is

Yes, but even if it does this (and I agree that it's a strategy well worth considering) that ISP is going to need IPv4 addresses to assign to its customers until the customers migrate to IPv6.  

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 25 Sep 2011 14:34:01 -0400

--On Sunday, September 25, 2011 13:25 -0400 Keith Moore
<[email-masked]> wrote:

>> IPv4 addresses on its backbone/infrastructure has the option
>> of simply converting that infrastructure to IPv6, tunneling
>> approach of its choice. Longer-term, that approach makes the
>> ISP far more IPv6-ready, while "more private/shared IPv4
>> space" is just another dead end.
> 
> Yes, but even if it does this (and I agree that it's a
> strategy well worth considering) that ISP is going to need
> IPv4 addresses to assign to its customers until the customers
> migrate to IPv6.  

So? I was sort of assuming that an ISP who was aggressive about
converting their internal infrastructure would be freeing up
public IPv4 addresses for endpoint and boundary use in fairly
large quantities.  Renumbering shouldn't be a lot harder than,
well, renumbering.

    john

---

From: Keith Moore <[email-masked]>
Date: Sun, 25 Sep 2011 14:41:23 -0400

> large quantities.  Renumbering shouldn't be a lot harder than,

My assumption is that most ISPs are already using RFC 1918 for internal infrastructure whenever possible in order to free up more public IPv4 addresses to assign to customers.  At least, I hope that's the case.

Keith

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 25 Sep 2011 23:00:52 +0100

> To me it seems clear that the risks associated with this proposal are less than the other risks.  Software that assumes that IPv4 space other than RFC 1918 space is unambiguous will break in either…

+1, but I'm a little bit concerned about transition mechanisms which depend on exclusively upstream NAT functions rather than in addition to the CPE, i.e. DS-Lite.  As it stands, the two cases can be distinguished, and it seems to me to be against this proposal, for that situation, since private addresses will probably provoke "Find my public address" semantics in existing software rather better than "Public-seeming" addresses on directly-attached hosts behind a DS-Lite gateway.

Otherwise, yep, it's inevitable.

Cheers,
Sabahattin

---

From: SM <[email-masked]>
Date: Mon, 26 Sep 2011 04:37:05 -0700

Hi Keith,

I changed the subject line.

At 11:41 25-09-2011, Keith Moore wrote:
>My assumption is that most ISPs are already using RFC 1918 for 
>internal infrastructure whenever possible in order to free up more 
>public IPv4 addresses to assign to customers.

See draft-kirkham-private-ip-sp-cores-06  There is also 7/8 which was 
used internally by an ISP [1].  Some may use RFC 1918 addresses for 
economic reasons [2] or because of its security properties.  The 
choice made by the ISP might be based on the notion of satisficing.

RFC 1287 argued for a plan which takes us past the exhaustion of the 
(IPv4) address space.   In my opinion, such a plan is unfeasible for 
non-technical reasons.  On a tangent, I don't know whether that RFC 
contains the original S.I.N.

Regards,
-sm

1. The market for lemons.

2. See Purchasing power parity.  The discussion would be way 
off-topic.  RFC 1744 examined some of the issues associated with the 
current management practices of the Internet IPv4 address space.

P.S. Although the subject line has been changed, it is not the 
appropriate way to create a new thread as the subject line is not a 
thread identifier.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 26 Sep 2011 09:58:46 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Friday, September 23, 2011 10:04 PM
To: Cameron Byrne
Cc: IETF Discussion
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

Furthermore, I find this draft's statements about "we are trying real hard to deploy ipv6" as not convincing... we are 10 years in on v6, no? I only seriously deployed ipv6 when it was clear the business had to deploy ipv6.... there were no other choices.

WEG] I really don't think it's useful to discuss penetration of "serious" IPv6 deployment based on absolute timescale for precisely that reason - until there's a business reason, being visionary or leaders in the space doesn't convince enough money to be shaken loose for that particular budget cycle or planning window. I think it's more useful to look at the progress made since IANA exhaust actually happened and since some testing showed how bad CGN might be, signifying some idea of when this actually "got real" and at the next 12-18 months in terms of major last-mile providers and their rollout plans.

WEG] Well, no. ARIN is looking for the IETF to allocate this because they were told by the IAB that they couldn't do it on their own, which sort of removes the teeth from the policy that their membership approved. I think that ARIN happened to be the first forum that the folks suggesting this (very much not new) idea found enough support to move it forward. That said, I don't think that support for the idea is in any way specific to ARIN, it just came up at the right place and time. I  think that more and more folks (myself included) are coming to the realization that the need is legitimate, and we sort of need to hold our noses and do it, and focus on making it less harmful rather than blocking it on philosophical grounds.

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 26 Sep 2011 10:07:21 -0400

On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote:
So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? The 240/4 work has been shot down multiple times ( I don't know the history ), are we now changing the rules for the end run ?

>It's hard to know for sure, but I believe there's greater risk associated with use of 240/4 than with a /10 from existing public IPv4 space.  That is, I think more software would be needed to allow…

WEG] you know, the more I think about this line of logic, the more I wonder about it.
In essence, the 240/4 problem is that lots of host and router implementations have one or more functions in their input validation code that says "240/4 == invalid" thus preventing you from configuring or using it. To my (admittedly oversimplified) view, this is a simple matter of:

1)      Search source code for "240"

2)      Comment out any relevant code you find

3)      Recompile, test (changes only), ship
I'd be happy for one or more folks who have some experience with the appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would explain where I'm oversimplifying.

Now, compare that with the discussion of adding a new set of non-unique address space where you likely have to add code to catch this if you care about the scope of the address that you've been assigned.
The authors (or at least one of them) of draft-bdgks maintain that they've discussed this with vendors (http://www.ietf.org/mail-archive/web/opsawg/current/msg01879.html, search for Linksys to find the relevant section of the message) and the vendors seem willing to make code changes in support of this, at least in new gear. Now this doesn't represent a commitment nor a critical mass necessarily, but I'm wondering why 240/4 is so much harder?

Also, I don't see why we don't use all of the tools in our toolkit. We're out of IANA space, except for a whole /4, which keeps getting shot down due to the perceived problems with getting global support, when there are probably multiple use cases that absolutely don't require global support. Why haven't we gone ahead and unreserved the space, and then let those interested in using it beat on the appropriate folks to fix it, rather than not even trying? I think that it would be fully possible to caveat use of the space appropriately so that people know what the risks are, but right now it's essentially useless even for those who might be able to try.
Seems wasteful, no?

I'm willing to write a draft about it if there are people willing to support it, but I only have so many windmills that I can tilt at per cycle, so I'd like to hear support either privately or publicly before I undertake it.

Wes George

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Sep 2011 07:08:16 -0700

On Sep 26, 2011 6:58 AM, "George, Wes" <[email-masked]> wrote:
> Subject: Re: Last Call:
<draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4
Prefix for Shared Transition Space) to Informational RFC
> Furthermore, I find this draft's statements about "we are trying real hard
to deploy ipv6" as not convincing... we are 10 years in on v6, no? I only
seriously deployed ipv6 when it was clear the business had to deploy
ipv6.... there were no other choices.
>
> WEG] I really don’t think it’s useful to discuss penetration of “serious”
IPv6 deployment based on absolute timescale for precisely that reason –
until there’s a business reason, being visionary or leaders in the space
doesn’t convince enough money to be shaken loose for that particular budget
cycle or planning window. I think it’s more useful to look at the progress
made since IANA exhaust actually happened and since some testing showed how
bad CGN might be, signifying some idea of when this actually “got real” and
at the next 12-18 months in terms of major last-mile providers and their
rollout plans.

Agreed.  The ietf is trying to help these companies have a business reason
for ipv6, not a business reason for nat444

> ARIN is looking for the IETF to bless this because they know it's bad,
they know this is a step in the wrong direction.... but the IETF made me do
it...
>
> WEG] Well, no. ARIN is looking for the IETF to allocate this because they
were told by the IAB that they couldn’t do it on their own, which sort of
removes the teeth from the policy that their membership approved. I think
that ARIN happened to be the first forum that the folks suggesting this
(very much not new) idea found enough support to move it forward. That said,
I don’t think that support for the idea is in any way specific to ARIN, it
just came up at the right place and time. I  think that more and more folks
(myself included) are coming to the realization that the need is legitimate,
and we sort of need to hold our noses and do it, and focus on making it less
harmful rather than blocking it on philosophical grounds.

And the step before that is that the people who now call themselves ARIN
were told no before in the IETF directly, afaik.  So it's the same people,
same logic, but now they come to the IETF with a different name, same
request, and they expext a different answer?

Cb
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this
E-mail and any printout.

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Sep 2011 12:41:59 -0400

On Sep 26, 2011, at 10:07 AM, George, Wes wrote:

> In essence, the 240/4 problem is that lots of host and router implementations have one or more functions in their input validation code that says “240/4 == invalid” thus preventing you from configuring or using it. To my (admittedly oversimplified) view, this is a simple matter of:
> 1)      Search source code for “240”
> I’d be happy for one or more folks who have some experience with the appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would explain where I’m oversimplifying.

I think that's basically right.   The problem isn't in the difficulty of finding these changes and fixing them, for currently maintained code.  The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained.     This is of course, in addition to any changes that have to be made to application software because of its wired-in assumptions about 240/4.  By contrast, if a /10 from public unicast IPv4 address space is used, only the application software has to be changed (if the application software needs to care about whether an address is ambiguous).  That's a much smaller impact, though probably still a significant one.

Actually it wouldn't bother me personally if the /10 were specified only for use with DS-Lite or with some other service that provided native v6 prefixes to customers in addition to any IPv4 service...though I don't know of any way to enforce that.

> I’m willing to write a draft about it if there are people willing to support it, but I only have so many windmills that I can tilt at per cycle, so I’d like to hear support either privately or publicly before I undertake it.

Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Sep 2011 18:47:01 +0200

On 26 Sep 2011, at 18:41 , Keith Moore wrote:

> The problem isn't in the difficulty of finding these changes and fixing them, for currently maintained code.  The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained.

This is the traditional problem with using 240/4, but it doesn't really apply in this specific case, because those addresses will only be touched by the CGNs in the ISP network, the routers in the ISP network and the home gateways.

So especially in the case where NAT444 is only used for new customers this may not be an issue at all.

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Sep 2011 12:51:21 -0400

> This is the traditional problem with using 240/4, but it doesn't really apply in this specific case, because those addresses will only be touched by the CGNs in the ISP network, the routers in the…

and the "home" gateways _never_  expose their external addresses to internal hosts or applications?    not even via NAT-PMP or UPnP?

(are they really "home" gateways in all cases?)

seems to me that if you're an ISP and have the luxury of upgrading all of the CPEs, that's a very compelling case for DS-Lite instead of relying on more v4 address space kludges.  but of course the devil is in the details.

Keith

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Sep 2011 09:57:36 -0700

On Mon, Sep 26, 2011 at 9:41 AM, Keith Moore <[email-masked]> wrote:
> Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt>
> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
>
> then why not dedicate 240/4 for this purpose? The 240/4 work has been shot
> down multiple times ( I don't know the history ), are we now changing the
> rules for the end run ?
>
>>It's hard to know for sure, but I believe there's greater risk associated
>> with use of 240/4 than with a /10 from existing public IPv4 space.  That is,
>> I think more software would be needed to allow 240/4 to be used reliably.
>
> In essence, the 240/4 problem is that lots of host and router
> implementations have one or more functions in their input validation code
> that says “240/4 == invalid” thus preventing you from configuring or using
> it. To my (admittedly oversimplified) view, this is a simple matter of:
> I’d be happy for one or more folks who have some experience with the
> appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would
> explain where I’m oversimplifying.
>
> I think that's basically right.   The problem isn't in the difficulty of
> finding these changes and fixing them, for currently maintained code.  The
> problem is in the zillions of systems in the field that have assumptions
> about 240/4 wired into them, most of which either have no automatic upgrade
> mechanism, aren't set up to use it, or aren't being maintained.     This is
> of course, in addition to any changes that have to be made to application
> software because of its wired-in assumptions about 240/4.  By contrast, if a
> /10 from public unicast IPv4 address space is used, only the application
> software has to be changed (if the application software needs to care about
> whether an address is ambiguous).  That's a much smaller impact, though
> probably still a significant one.
> Actually it wouldn't bother me personally if the /10 were specified only for
> use with DS-Lite or with some other service that provided native v6 prefixes
> to customers in addition to any IPv4 service...though I don't know of any
> way to enforce that.
>

This is the 2nd time DS-lite has come up, this comment is off topic,
but i want to make sure the inputs are right.

DS-lite would not use this space and does not need this space, DS-lite
assumes the following: RFC1918 + IPv6 public in the end-site (my home)
with a B4 tunneling home gateway, IPv6-access network (DSL/Cable
access network), and public routable space in the CGN/AFTR.

DS private IPv4 LAN -----{IPv6 only access network} ---- CGN ---- Internet

draft-weil space is only for what draft-weil says it is for, and that
is the NAT4'4'4, the middle 4 SP access network or to facilitate
6to4-PMT (NAT66 of 6to4).

IPv4 LAN ---IPv4 access with shared space---- CGN --- Internet

IMHO, this allocation does not move IPv6 forward... it just makes
NAT444 more possible and "fixes" 6to4 so that the IPv6 part returns to
the correct IPv4 NAT network.

DS-lite does move IPv6 forward.

But, AFAIK, the draft-weil folks want a /10 so that they don't have to
spend money to upgrade their access network or associated CPE.  In
this way, end points that need real unique IPv4 space are subsidizing
the upgrade deferral of these networks.

Cameron

> I’m willing to write a draft about it if there are people willing to support
> it, but I only have so many windmills that I can tilt at per cycle, so I’d
> like to hear support either privately or publicly before I undertake it.
>
> Honestly I'd guess that if vendors started changing their code today, it
> would be 10 years before 240/4 could be widely used in the field.
> Keith
>

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 26 Sep 2011 10:36:29 -0700

Regardless of the ease of implementing the change (which is quite simple
in the linux case for example), the question is really what is the
impact on existing systems? The presumption is they won't change until
they age out of the network which is the same reason any a+p solution
that requires host signalling or new private scope unicast ranges have
negative implications for the support of legacy systems. By that measure
240/4 is unequivically not useful (for this purpose). It was also not
useful 4 years ago (for this purpose).

On 9/26/11 07:07 , George, Wes wrote:
>  
> 
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Keith Moore
> *Sent:* Friday, September 23, 2011 10:04 PM
> *To:* Cameron Byrne
> *Cc:* IETF Discussion
> *Subject:* Re: Last Call:
> So if there is going to be breakage, and folks are willing to fix it
> over time because the good outweighs the bad (I personally do not
> believe this), then why not dedicate 240/4 for this purpose?The 240/4
> work has been shot down multiple times ( I don't know the history ), are
> we now changing the rules for the end run ?
> 
>  
> 
>>It's hard to know for sure, but I believe there's greater risk
> associated with use of 240/4 than with a /10 from existing public IPv4
> space.  That is, I think more software would be needed to allow 240/4 to
> be used reliably.
> 
> implementations have one or more functions in their input validation
> code that says “240/4 == invalid” thus preventing you from configuring
> or using it. To my (admittedly oversimplified) view, this is a simple
> matter of:
> 
> Now, compare that with the discussion of adding a new set of non-unique
> address space where you likely have to add code to catch this if you
> care about the scope of the address that you’ve been assigned.
> 
> The authors (or at least one of them) of draft-bdgks maintain that
> they’ve discussed this with vendors
> (http://www.ietf.org/mail-archive/web/opsawg/current/msg01879.html,
> search for Linksys to find the relevant section of the message) and the
> vendors seem willing to make code changes in support of this, at least
> in new gear. Now this doesn’t represent a commitment nor a critical mass
> necessarily, but I’m wondering why 240/4 is so much harder?
> 
>  
> 
> Also, I don’t see why we don’t use all of the tools in our toolkit.
> We’re out of IANA space, except for a whole /4, which keeps getting shot
> down due to the perceived problems with getting global support, when
> there are probably multiple use cases that absolutely don’t require
> global support. Why haven’t we gone ahead and unreserved the space, and
> then let those interested in using it beat on the appropriate folks to
> fix it, rather than not even trying? I think that it would be fully
> possible to caveat use of the space appropriately so that people know
> what the risks are, but right now it’s essentially useless even for
> those who might be able to try.
> 
> Seems wasteful, no?
> 
>  
> 
> I’m willing to write a draft about it if there are people willing to
> support it, but I only have so many windmills that I can tilt at per
> cycle, so I’d like to hear support either privately or publicly before I
> undertake it.
> 
>  
> 
> Wes George
> 
> 
> ------------------------------------------------------------------------
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is addressed.
> If you are not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or action taken
> in relation to the contents of and attachments to this E-mail is
> strictly prohibited and may be unlawful. If you have received this
> E-mail in error, please notify the sender immediately and permanently
> delete the original and any copy of this E-mail and any printout.
> 
>

---

From: "George, Wes" <[email-masked]>
Date: Mon, 26 Sep 2011 14:15:21 -0400

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Friday, September 23, 2011 10:04 PM

The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained.
<snip>
Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field.

WEG] See that's the point, I think we keep looking at this from a "boil the ocean" perspective. The question is not, "could we use 240/4 as more global unicast space?" as the ship sailed on that years ago when IETF apparently decided it was too hard to change and nothing should be done.
The question is, "if the space were unreserved, are there valid use cases where networks within a given administrative control might be able to make use of it?"
This idea of limited use puts the impetus on the network/operator itself to identify a use case and force their vendors to confirm support for the space, but it makes it more likely that for that definition of "widely used" it would be successful. But if IETF/IANA removes the reservation, this means means that people can go in and check in the update to the 3 lines of BSD kernel code (based on a private reply I received on the matter) necessary to remove the block, vendors can stop putting that logic into new devices, etc, thus making it more attractive to attempt to use the space from that point forward.
I don't expect this to be a perfect solution for legacy IPv4-only devices, but I do expect that it could have some use, especially when compared with other alternatives.

Cameron's example is a case in point - you have a mobile provider who for the most part tells the vendors exactly what features their user devices need to support and they are built to spec, plus a closed network with NAT at the edges that is currently squatting on public space. This means that a large amount (or possibly all) of the devices that would need to support use of this space are within their administrative control, and they would be responsible for updating the code to a version that won't reject 240/4, and they could contain it within their environment by keeping it inside of the NAT border.

Wes George

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Sep 2011 16:15:56 -0400

On Sep 26, 2011, at 2:15 PM, George, Wes wrote:

> WEG] See that’s the point, I think we keep looking at this from a “boil the ocean” perspective. The question is not, “could we use 240/4 as more global unicast space?” as the ship sailed on that years ago when IETF apparently decided it was too hard to change and nothing should be done.
> The question is, “if the space were unreserved, are there valid use cases where networks within a given administrative control might be able to make use of it?”

maybe.  But I personally don't believe that such addresses won't leak out. 

I'd say if a network operator wants to make a case for it using 240/4, it can write up an Internet-Draft detailing how it would be used along with containment measures, and petition IETF to ask IANA to permit such use.

The last thing that's needed is to open up that space for general use for anybody who thinks it's a good idea.  And I sympathize with the notion that any use of the precious remaining reserved v4 space should somehow credibly promote IPv6 adoption.

Keith

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 27 Sep 2011 00:01:09 +0200

On 26 September 2011 16:07, George, Wes wrote:

> I’m willing to write a draft about it if there are people willing
> to support it, but I only have so many windmills that I can tilt at
> per cycle, so I’d like to hear support either privately or publicly
> before I undertake it.

Maybe the IETF could agree that it won't use the former "class E" for
any past, present, or future experiments.  Updating RFC 1112 (STD 5)
or maybe RFC 1166, and then RFC 5735 for 6.25% of all windmills minus
one.

-Frank

<http://omniplex.blogspot.com//2008/06/lost-found-268435455-free-ips.html>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Sep 2011 22:21:26 +0000

I will be a bit more direct than Keith.

There is no such thing as "no leakage." These addresses will leak, no matter how well you believe you are isolated. Indeed, the issues posed by similar leakage were one of the main argument developed in RFC 3879, "Deprecating Site Local Addresses."

We see here a proposal to create site local IPv4 addresses for Internet providers. The IETF previously expanded significant efforts to deprecate IPv6 site local addresses. Why exactly do we believe that IPv4 site local addresses would be a good idea, when the consensus was that IPv6 site local addresses caused more harm than good?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Monday, September 26, 2011 1:16 PM
To: George, Wes
Cc: IETF Discussion
Subject: Re: 240/4 unreservation (was RE: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Keith Moore
Sent: Friday, September 23, 2011 10:04 PM

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Sep 2011 08:31:45 +0900

> or maybe RFC 1166, and then RFC 5735 for 6.25% of all windmills minus

Given that NAT can expand the space 100 or 1000 times, while
maintaining the end to end transparency if you so wish, it's
not 6.25% but 625% or 6250%.

That is, unreservation is worth doing and as the first step,
it is a good idea to use some of the space for shared
transition where all the equipments having the unreserved
addresses should be able to treat the unreservation.

However, as the unreserved space is still precious, only
small part of the space should be allocated for shared
transition.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Sep 2011 09:08:52 +0900

Frank Ellermann wrote:

Oops, I failed to send the following to the list.

> Updating RFC 1112 (STD 5)

Updating RFC1112 is not necessary because, even though it says:

   *    a datagram whose source address does not define a single
        host -- e.g., a zero address, a loopback address, a
        broadcast address, a multicast address, or a Class E
        address.

Class E is an example and, more interestingly, the rule is silently
ignored by ICMPs generated against private use addresses, which
do not define single hosts.

Updating RFC can be as simple as follows:

   240.0.0.0/4 - This block, formerly known as the Class E address
   space [RFC1112], and was reserved for future use [RFC5735] is
   now allocated for use in IPv4 unicast address assignments with
   default netmask of 0xffffffff.

   The addresses in the block is not special use IPv4 addresses
   anymore.

   There are two exceptions to this.

   One exception is the "limited broadcast"
   destination address 255.255.255.255.  As described in [RFC0919]
   and [RFC0922], packets with this destination address are not
   forwarded at the IP layer.

   Another exception is the "shared transition" block
   of 240.0.0.0/12, which is set aside for use in private ISP
   (not end user) networks. Its intended use is to be documented
   in a future RFC, As will be described in that RFC, addresses
   within this block do not legitimately appear on the public
   Internet. These addresses can be used without any coordination
   with IANA or an Internet registry.

                        Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Sep 2011 23:00:57 -0400

> We see here a proposal to create site local IPv4 addresses for Internet providers. The IETF previously expanded significant efforts to deprecate IPv6 site local addresses. Why exactly do we believe…

Not exactly to play devil's advocate here, but I don't think these are quite like site-locals.   It seems like they're more like "ISP locals".

One of the problems with site locals was that they were ambiguous addresses AND that they would need to be used by applications, and we had plenty of experience that said that RFC 1918 addresses caused harm.    If 240/4 wouldn't be used or seen by applications at all, the fact that those addresses would be reused in other networks wouldn't be such an issue.  Though I agree that these will leak, even if they're never used as application endpoints.  If one of them ever appears as a source address on an ICMP reply, for instance, that actually will cause problems - perhaps not problems that directly affect applications, but problems nonetheless.  (Then again, tunnel use is now quite widespread, which means that packets travel paths that are completely invisible to the endpoints and look like a single hop to them.    And there are of course problems with those, but we sort of deal with them.)

Another of the problems with site locals was that there was no clear boundary that corresponded to a site, so why have a special class of addresses for a site? If that's also true for an ISP, maybe an ISP local address isn't such a good idea either.

What happens if two ISPs that are each using 240/4, merge?   Probably the same kind of mess you get when two enterprises that use RFC 1918 addresses merge.   Granted, ISPs might not merge as often as enterprises, but still...

It was especially important to get rid of site locals in IPv6 because IPv6 was in very early stages of deployment, and any errors in its design would be magnified over time.  By contrast, IPv4 is a dinosaur struggling to take its last unassisted breaths, and which is starting to be put on life support.  Some sort of extraordinary measures to keep IPv4 vlable for a short time might be in order, even if those measures would never make sense in IPv6.

So my take is that using 240/4 is not an absolute no.  But that bit of address space is a very precious resource and there needs to be strong justification for using it, along with reasonable assurance that it will not do significant harm in relation to the amount of benefit it will likely provide.  And merely prolonging the life of IPv4 is probably not sufficient justification.

Keith

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Sep 2011 03:45:57 +0000

> Not exactly to play devil's advocate here, but I don't think these are quite like site-locals.   It seems like they're more like "ISP locals".

I know that is the proposition. But if an address space is somehow set aside, we have no mechanism to enforce that only ISP use it. So we have to assume it will be used by whoever feels like it.

>  It was especially important to get rid of site locals in IPv6 because IPv6 was in very early stages of deployment, and any errors in its design would be magnified over time.  

It is also important to avoid mistakes during the transition period from IPv4 to IPv6. I understand that many actors are anxious and waiting for some kind of fix. This is a common scenario for making substantial mistakes...

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 Sep 2011 11:39:35 +0200

On 27 Sep 2011, at 5:45 , Christian Huitema wrote:

>> if an address space is somehow set aside, we have no mechanism to enforce that only ISP use it. So we have to assume it will be used by whoever feels like it.

How is that different from the current situation? Is there a reason why potential users of 240/4 will refrain from that use because it's called "class E" but not if it's called "ISP private"?

And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That saves more usable addresses for other uses.

> It is also important to avoid mistakes during the transition period from IPv4 to IPv6. I understand that many actors are anxious and waiting for some kind of fix. This is a common scenario for maki…

Agree. We have to make absolutely sure that all the hacks that are going to be implemented to stretch IPv4 don't find their way into the IPv6 world.

---

From: "George, Wes" <[email-masked]>
Date: Tue, 27 Sep 2011 10:23:49 -0400

From: [email-masked] On Behalf Of Iljitsch van Beijnum

>And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That >saves more usable addresses for other uses.

WEG] The problem is that people really can't today, because vendors mostly do not want to implement something for general consumption that is deliberately out of compliance with one or more RFCs. My point in asking the question was that I'm not sure that we need to define what use cases it can/should be used for as much as we simply need to unreserve it and provide some guidance about risks.
IMO, the question tree on determining what (if any) course of action to take is something like this:
1) should it be unreserved for *any* reason, or are we just going to stick with the 5735 status quo (Future use)?
2) should it be made into more global unicast space in all or in part?
3) should it be simply unreserved as non-global space with a few caveats about limitations, and leave the use cases to the consenting adults considering its use?
4) should it have a designated use(s) to the exclusion of all not explicitly defined?

For #1, My view is that there's no good reason to maintain the reservation, because then essentially no one can use it, and the likelihood of someone coming up with a use for it that justifies holding it in reserve for "future use" continues to drop. So it's more a question of how we might use the space, and the justification for doing any one of several things. I don't agree that the burden of proof should favor doing nothing.
For #2, We know that it is not trivial to get it working for this purpose due to the critical mass of support required. But in some cases where there is tight control over equipment and networks, and a community of interest that routinely communicates between one another across a portion of the Internet, perhaps it's possible. I'm thinking that this makes more sense as a means to buy us time to get IPv6 deployments completed if CGN ends up being bad and the demand for global IPv4 space gets high enough that any tradeoffs associated with using this space as global unicast are deemed acceptable. It may be that we carve the space up so that some of it is tentatively reserved for global unicast, but not released to IANA until some later point to give folks time to fix things. I agree that this one has a lot of risk that it ends up simply prolonging IPv4 without aiding the transition to IPv6.
For #3, it's mainly about the caveats to its use - it may not be supported by legacy equipment, we have to carve out 255.255.255.255 (or perhaps something between 255/8 and 255.255.255/24) for broadcast, it MUST NOT show up in the global routing table, etc
For #4 - I'm not sure we can come up with enough designated uses at the outset to not have to continue evaluating new ones all of the time and end up needing a WG just to keep up with the discussion. So far, we've heard about its use within a mobile provider in place of RFC1918 as Mobile UE addresses behind a CGN that's already in place today. The folks wanting a shared CGN address pool have already turned down 240/4 because of the limited support within the legacy home router CPE gear. What other potential uses are there? 1918 space in enterprises where all of 1918 is already in use (eg mergers, extranets, etc)?
I think Iljitsch's point is a good one - why do we care how people use it? As long as we can give them some guidance about how *not* to use it in order to avoid breakage, I think we're doing our jobs.

Wes George