On 9/18/12, Jeroen Massar <jeroen@unfix.org> wrote:

Some people have to learn that not every address is only used on the Internet. According to the above there will be large swaths of IPv4 left at various large organizations who have /8's as "they are not announced" or as the article states it "as there is no ASN".

When IPv4 exhaustion pain reaches a sufficiently high level of pain; there is a significant chance people who will be convinced that any use of IPv4 which does not involve announcing and routing the address space on the internet is a "Non-Use" of IPv4 addresses, and that that particular point of view will prevail over the concept and convenience of being allowed to maintain unique registration for non-connected usage. And perception that those addresses are up for grabs, either for using on RFC1918 networks for NAT, or for insisting that internet registry allocations be recalled and those resources put towards use by connected networks...... If you do have such an unconnected network, it may be prudent to have a connected network as well, and announce all your space anyways (just not route the addresses)

Greets, Jeroen -- -JH

Not to mention Ford Motor Company has 19.0.0.0/8, and there are no announcements for it whatsoever. There are other /8s like it...lots of them early allocations. Why ARIN doesn't revoke them is frankly baffling to me. On Tue, Sep 18, 2012 at 10:27 PM, Randy Bush <randy@psg.com> wrote:

...

When IPv4 exhaustion pain reaches a sufficiently high level of pain; there is a significant chance people who will be convinced that any use of IPv4 which does not involve announcing and routing the address space on the internet is a "Non-Use" of IPv4 addresses,

and that that particular point of view will prevail over the concept and convenience of being allowed to maintain unique registration for non-connected usage.

And perception that those addresses are up for grabs, either for using on RFC1918 networks for NAT, or for insisting that internet registry allocations be recalled and those resources put towards use by connected networks......

If you do have such an unconnected network, it may be prudent to have a connected network as well, and announce all your space anyways (just not route the addresses)

this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans.

randy

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans." I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush <randy@psg.com> wrote:

...

When IPv4 exhaustion pain reaches a sufficiently high level of pain; there is a significant chance people who will be convinced that any use of IPv4 which does not involve announcing and routing the address space on the internet is a "Non-Use" of IPv4 addresses,

and that that particular point of view will prevail over the concept and convenience of being allowed to maintain unique registration for non-connected usage.

And perception that those addresses are up for grabs, either for using on RFC1918 networks for NAT, or for insisting that internet registry allocations be recalled and those resources put towards use by connected networks......

If you do have such an unconnected network, it may be prudent to have a connected network as well, and announce all your space anyways (just not route the addresses)

this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans.

randy

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

On Wednesday, September 19, 2012, Mike Hale wrote:

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans."

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool?

Er, just because it isn't announced in the global routing tables doesn't mean it isn't used. I work for a company that has one of those early allocation /8s. It is densely packed with hosts of one kind or the other - but you can't reach (and there is no business need for anybody at all to reach) them except at an office location or having vpn'd in to the company intranet. I rather suspect that this is the case with most such early class A / B / C allocations that aren't currently routed .. if the corporation isn't defunct you can safely assume that especially the /8s are heavily used. It makes all kinds of sense to seek out and reclaim allocations from defunct corporations because if the individual RIRs don't, then various spammers and botmasters will, as we've seen time and again in the past few years. --srs -- Suresh Ramasubramanian (ops.lists@gmail.com)

In message <CAN3um4zGsbRL9K2snL0N6qDgP7RU_4dw_z1F0RQ3bnbr1H8eDA@mail.gmail.com>, M ike Hale writes:

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans."

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool?

Go back and re-read the entire thread. No one is arguing that unused resources shouldn't be returned. The problem is that people, including the person that started the petition that triggered this thread, have no idea about legitimate use that isn't visible on the publically visible routing tables. Routed => in use Not routed =/> not in use Mark

On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush <randy@psg.com> wrote:

...

...

When IPv4 exhaustion pain reaches a sufficiently high level of pain; there is a significant chance people who will be convinced that any use of IPv4 which does not involve announcing and routing the address space on the internet is a "Non-Use" of IPv4 addresses,

and that that particular point of view will prevail over the concept and convenience of being allowed to maintain unique registration for non-connected usage.

And perception that those addresses are up for grabs, either for using on RFC1918 networks for NAT, or for insisting that internet registry allocations be recalled and those resources put towards use by connected networks......

If you do have such an unconnected network, it may be prudent to have a connected network as well, and announce all your space anyways (just not route the addresses)

this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans.

randy

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <CAN3um4zmT2L8uMMwQTDq1coxjXOyvgdQfVtMPGwG2tTmf87frQ@mail.gmail.com>, M ike Hale writes:

So...why do you need publicly routable IP addresses if they aren't publicly routable?

Route announcements can be scoped. See NO-EXPORT. Just because _you_ can't see the announcement doesn't mean others can't see the announcement along with the rest of the publically announced networks.

Maybe I'm being dense here, but I'm truly puzzled by this (other than the "this is how our network works and we're not changing it" argument).

IP addresses are not just assigned so that one can connect to the public internet. There are lots of other valid reasons for addresses to be assigned. Go look them up. They are documented in RFC's and at the RIR's. Mark

I can accept the legal argument (and I'm assuming that, in the original contracts for IP space, there wasn't a clause that allowed Internic or its successor to reclaim space).

On Tue, Sep 18, 2012 at 9:46 PM, Mark Andrews <marka@isc.org> wrote:

...

In message <CAN3um4zGsbRL9K2snL0N6qDgP7RU_4dw_z1F0RQ3bnbr1H8eDA@mail.gmail.com , M ike Hale writes:

...

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans."

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool?

Go back and re-read the entire thread. No one is arguing that unused resources shouldn't be returned. The problem is that people, including the person that started the petition that triggered this thread, have no idea about legitimate use that isn't visible on the publically visible routing tables.

Routed => in use Not routed =/> not in use

Mark

...

On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush <randy@psg.com> wrote:

...

...

When IPv4 exhaustion pain reaches a sufficiently high level of pain; there is a significant chance people who will be convinced that any use of IPv4 which does not involve announcing and routing the address space on the internet is a "Non-Use" of IPv4 addresses,

and that that particular point of view will prevail over the concept and convenience of being allowed to maintain unique registration for non-connected usage.

And perception that those addresses are up for grabs, either for using on RFC1918 networks for NAT, or for insisting that internet registry allocations be recalled and those resources put towards use by connected networks......

If you do have such an unconnected network, it may be prudent to have a connected network as well, and announce all your space anyways (just not route the addresses)

this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans.

randy

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 9/18/12, Mike Hale <eyeronic.design@gmail.com> wrote:

I can accept the legal argument (and I'm assuming that, in the original contracts for IP space, there wasn't a clause that allowed Internic or its successor to reclaim space).

Assume you have a public IPv4 assignment, and someone else starts routing your assignment... "legitimately" or not, RIR allocation transferred to them, or not. There might be a record created in a database, and/or internet routing tables regarding someone else using the same range for a connected network. But your unconnected network, is unaffected. You are going to have a hard time getting a court to take your case, if the loss/damages to your operation are $0, because your network is unconnected, and its operation is not impaired by someone else's use, and the address ranges' appearance in the global tables. -- -JH

On Sep 19, 2012, at 9:24 AM, John Osmon <josmon@rigozsaurus.com> wrote:

On Wed, Sep 19, 2012 at 12:07:33AM -0500, Jimmy Hess wrote:

...

Assume you have a public IPv4 assignment, and someone else starts routing your assignment... "legitimately" or not, RIR allocation transferred to them, or not.

There might be a record created in a database, and/or internet routing tables regarding someone else using the same range for a connected network.

But your unconnected network, is unaffected.

Ahh... But the network may not be unconnected. Just because *you* don't have a path to it doesn't mean others are similarly disconnected. All of those "others" would be affected.

...

You are going to have a hard time getting a court to take your case, if the loss/damages to your operation are $0, because your network is unconnected, and its operation is not impaired by someone else's use, and the address ranges' appearance in the global tables.

Think about a company that has thousands of private interconnects with other companies. Unique address space would remove the chance of RFC1918 space clash, and any of the bad effects of NAT. (e.g The network *works* as it was originally designed.)

Such a network would not have $0 in loss/damage when the partners can't reach it due to a rogue announcement.

The Internet is not the same from all viewpoints.

This discussion is repeating ones heard hear in the mid 1990s. Having a block of IP addresses not seen in YOUR IP routing tables is NOT evidence of unused addresses. For example, an inter-network SMTP relay correctly forwards messages via MX DNS entries only if unique IP address exist on both sides of the relay. This is just one example of application level gateways used to isolate networks at Layer 3 that has been in use for decades. As noted above, there are many instances of private interconnects which rely on assigned integers to tag destinations in a globally unique fashion. In the case of IP addressing, IANA and the various registries provide this globally unique assignment service. Use of these unique integers for packet routing is left as an exercise for the Network Engineer. IANA and the registries are not in the business of directly policing the use of any assigned integers. Those of us who have been involved in interconnecting private networks with overlapping IP address assignments are well aware of the pitfalls, hazards, and costs of using non-unique addressing. An entity which uses its ignorance of how addresses are used internally by another entity as an excuse to ignore proper IP address assignment is deliberately contributing to network chaos and to the culture of ignoring rules "because we can". The bottom line is that "Connected" does not mean "Routable via IPv4/IPv6". This is in addition to "Hidden" does not mean "Unused" as pointed out by others.

So...why do you need publicly routable IP addresses if they aren't publicly routable?

Because the RIRs aren't in the business of handing out publicly routable address space. They're in the business of handing out globally unique address space - *one* of the reasons for which may be connection to the "public Internet", whatever that is at any given point in time and space. RIPE are really good about making the distinction and using the latter phrase rather than the former. I'm not familiar enough with the corresponding ARIN documents to comment on the language used there. Regards, Tim.

On 2012-09-20 16:01 , John Curran wrote:

On Sep 19, 2012, at 5:01 AM, Tim Franklin <tim@pelican.org> wrote:

...

...

So...why do you need publicly routable IP addresses if they aren't publicly routable?

Because the RIRs aren't in the business of handing out publicly routable address space. They're in the business of handing out globally unique address space - *one* of the reasons for which may be connection to the "public Internet", whatever that is at any given point in time and space.

RIPE are really good about making the distinction and using the latter phrase rather than the former. I'm not familiar enough with the corresponding ARIN documents to comment on the language used there.

It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), <https://www.arin.net/policy/nrpm.html#four11> -

"4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable."

While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states "we don't guarantee that you can route it everywhere", which is on top of the uniqueness portion. This is quite not what is meant with using it completely off-grid, thus not showing up in the global "Internet" BGP routes anywhere. Greets, Jeroen

I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force. Steven Naslund -----Original Message----- From: John Curran [mailto:jcurran@arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:10 AM, Jeroen Massar <jeroen@unfix.org> wrote:

On 2012-09-20 16:01 , John Curran wrote:

...

It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), <https://www.arin.net/policy/nrpm.html#four11> -

"4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable."

While close, that is not the same.

The RIPE variant solely guarantees uniqueness of the addresses.

The ARIN variant states "we don't guarantee that you can route it everywhere", which is on top of the uniqueness portion.

Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are "publicly routable address space" (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John

On Sep 20, 2012, at 10:56 AM, "Naslund, Steve" <SNaslund@medline.com> wrote:

Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable?

I certainly would not say that. I would say that I get addresses from the RIRs to avoid address collisions with other network operators using the same approach. And, please note this well, address collisions affect more than Layer three routing. See all the previous mentions of application gateways. James R. Cutler james.cutler@consultant.com

At 9:56 -0500 9/20/12, Naslund, Steve wrote:

I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers.

ARIN does not provide transit - how could they guarantee or even just provide best-effort routability?

However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable?

Perhaps, but that is misguided. ARIN, et.al. don't get involved in peering or block lists or firewall configuration guides or hurricane forecasting or ... anything else that bars reachability. If I decide to unilaterally block traffic from your address range, ARIN, et.al., can't do anything about it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars!

not how i read that section Owen... "...networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity." One does not have to request RFC 1918 space from ARIN (or other RIR) and the NRPM is mute on legacy address assignments wrt "connectivity". /bill On Thu, Sep 27, 2012 at 07:32:17PM -0700, Owen DeLong wrote:

I believe that this section of NRPM says no.

4.3.5. Non-connected Networks

End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity.

Owen

On Sep 20, 2012, at 7:56 AM, "Naslund, Steve" <SNaslund@medline.com> wrote:

...

I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force.

Steven Naslund

-----Original Message----- From: John Curran [mailto:jcurran@arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...)

On Sep 20, 2012, at 10:10 AM, Jeroen Massar <jeroen@unfix.org> wrote:

...

On 2012-09-20 16:01 , John Curran wrote:

...

It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), <https://www.arin.net/policy/nrpm.html#four11> -

"4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable."

While close, that is not the same.

The RIPE variant solely guarantees uniqueness of the addresses.

The ARIN variant states "we don't guarantee that you can route it everywhere", which is on top of the uniqueness portion.

Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are "publicly routable address space" (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.)

FYI, /John

ah... again the distinction between routed and routable. RFC 1918 space is clearly routeable and routed. one does not need ARIN to assign such space. what i -think- the NRPM section you refered to actually touches on (but does not state outright) the concept of uniqueness. In the dim mists of the past, the NIC (SRI) ran two sets of books, the "connected" database and the "unconnected" database. There was a lack of address block uniquenss between these two databases; e.g. 192.146.13.0/24 was assigned -TWICE-. This occured for hundreds of delegations I was responsible for - I can only assume there were thousands of sites affected (Impacted for the gramatically challanged). This was problematic when "unconnected" sites connected... and is why some of the admonitions in RFC 1918 exist. The section of the ARIN NRPM you quote was developed when there was: a) a shortage of globally unique IPv4 blocks available and b) NAT and RFC 1918 space was easy. Hence the admonishion to use RFC 1918 space if you were "unconnected" and when you decided to "connect", ARIN would be willing to listen to your request. Two thing have changed: a) IPv4 is nearing equalibrium ... Most of it is fielded and so it is not clear ARIN can supply IPv4 on demand as it has in the past. Yes, please tell me the IPv6 story Grandpa, I've -never- heard it before... :( b) Many networks are not "connected" or "unconnected" (begs the question, from what PoV/ASN?) but are transients - with connections being sporadic either in time or by service. What this boils down to is global uniqueness - not routed (by whom) or routability (are the headers legal)... And that (IMHO) is a key attribute of what the RIRs are trying to protect. YMMV of course. /bill On Fri, Sep 28, 2012 at 07:04:43AM -0700, Owen DeLong wrote:

Bill, I am unable to make sense of your reply.

The question I was answering was:

"Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable?" (Which I admit at the time I interpreted to also indicate an expectation that it would be routed, but I see now could be ambiguous).

In that context, I believe that the policy section I quoted indicates that there is no expectation that numbers issued by ARIN or RIPE (or any other RIR) "will be routed" and other policy sections certainly convey that ARIN (and the other RIRs) have no control over routers, so I'm not sure it matters what they say about routability.

As to your statement about legacy assignments, I fail to see any part of ARIN policy that distinguishes them from any other assignment with regards to the application of policy. However, other than the section quoted below (which essentially states that some level of connectivity is required to justify new resource allocations or assignments), I believe that the NRPM is mute with regards to connectivity on all addresses. Since there are, by definition, no new legacy allocations or assignments, I'm not sure how legacy is relevant to the discussion at hand.

Owen

On Sep 28, 2012, at 5:07 AM, bmanning@vacation.karoshi.com wrote:

...

not how i read that section Owen...

"...networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity."

One does not have to request RFC 1918 space from ARIN (or other RIR)

and the NRPM is mute on legacy address assignments wrt "connectivity".

/bill

On Thu, Sep 27, 2012 at 07:32:17PM -0700, Owen DeLong wrote:

...

I believe that this section of NRPM says no.

4.3.5. Non-connected Networks

End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity.

Owen

On Sep 20, 2012, at 7:56 AM, "Naslund, Steve" <SNaslund@medline.com> wrote:

...

I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force.

Steven Naslund

-----Original Message----- From: John Curran [mailto:jcurran@arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...)

On Sep 20, 2012, at 10:10 AM, Jeroen Massar <jeroen@unfix.org> wrote:

...

On 2012-09-20 16:01 , John Curran wrote:

...

It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), <https://www.arin.net/policy/nrpm.html#four11> -

"4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable."

While close, that is not the same.

The RIPE variant solely guarantees uniqueness of the addresses.

The ARIN variant states "we don't guarantee that you can route it everywhere", which is on top of the uniqueness portion.

Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are "publicly routable address space" (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.)

FYI, /John

On Tue, Sep 18, 2012 at 9:49 PM, Mike Hale <eyeronic.design@gmail.com>wrote:

So...why do you need publicly routable IP addresses if they aren't publicly routable?

Because doing anything else is Harmful! There's even an RFC that says so! http://tools.ietf.org/html/rfc1627 - Network 10 Considered Harmful Ford's /8 was allocated in 1988, a full 6 years before RFC1597 (the precursor to RFC1918) was released. Scott.

Imagine that you are the DWP. You're given a block of addresses, told that they will be yours forever, plan your network accordingly, and implement your plan. Now, decades later, people are telling you that "forever" is over, and you have to totally re-address your network because you have something that other people want. To make the request that much more interesting, the reason that they want your block is because they failed to implement the actual solution to the problem, IPv6. We were already looking at the IPv4 runout problems when I was at IANA in 2004. We already knew (in large part thanks to folks like Tony Hain and Geoff Huston) that we'd run out in the 2010-2012 time frame, and a lot of us pushed a lot of rocks up a lot of hills to get our part of the IPv6 infrastructure rollout done well in advance of that date. We (and by we here I am explicitly including the RIRs) also heavily discussed every single option for every single block ... holders of legacy blocks were quietly approached and asked about the potential of returning them, and some of them actually did. We scoured ERX space, re-thought a lot of long held assumptions (e.g., we could never allocate 1/8); and squeezed every drop of blood we could from the IPv4 turnip. Of course, this good work was continued long after I left ICANN, and the Internet community should be grateful to those who have spent many thankless hours dealing with this problem. ... and now, we're done. IPv4 is what it is. There are no new solutions, there is no magic bullet, and no quantity of pixie dust is going to cause new space to appear out of thin air. You can spend more time flogging long-concluded arguments, or you can spend your time productively by implementing IPv6. Doug

On Wed, 19 Sep 2012 18:36:08 -0400, Joe Maimon said:

So 6-8 years to try and rehabilitate 240/4 was not even enough to try?

6 years of work to accomplish something that would only buy us 16 /8s, which would be maybe 2 year's supply, instead of actually deploying IPv6. And at the end of the 2 years, you'll *still* have to do the work of deploying IPv6 That sort of trade-off only makes sense for somebody in *serious* denial.

On Sep 19, 2012, at 5:50 pm, Joe Maimon <jmaimon@ttec.com> wrote: […]

...

...

So 6-8 years to try and rehabilitate 240/4 was not even enough to try?

6 years of work

What I said is that they knew they would have had at least 6 years or _more_ to rehabilitate it, had they made a serious effort at the time.

Remind me, who is "they"? I remember this: http://tools.ietf.org/html/draft-fuller-240space-02 and this: http://tools.ietf.org/html/draft-wilson-class-e-02 There was even a dedicated mailing list. But the drafts never made it beyond drafts, which suggests there was not a consensus in favour of an extra 18 months of IPv4 space with dubious utility value because of issues with deploy-and-forget equipment out in the wild. The consensus seems to have been in favour of skipping 240/4 and just getting on with deploying IPv6, which everyone would have to do anyway no matter what. Is that so terrible? Regards, Leo

On 9/19/12, Joe Maimon <jmaimon@ttec.com> wrote:

Why is this cast as a boolean choice? And how has the getting on with IPv6 deployment been working out?

"getting a single extra /4" is considered, not enough of a return to make the change. I don't accept that, but as far as rehabilitating 240/4, that lot was already cast, I think, and the above was the likely reason, there have been plenty of objections which all amounted to "too much trouble to lift the pen" and change it..... So if you want some address space rehabilitated, by a change of standard, it apparently needs to be more than a /4. There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage...

That the discussion continues is in and of itself a verdict. Joe -- -JH

In message <CAAAwwbW2OH0-CpsVwYRfDODvjOTAVaQ8WdLUSsqvShs5CoTUYQ@mail.gmail.com> , Jimmy Hess writes:

On 9/19/12, Joe Maimon <jmaimon@ttec.com> wrote:

...

Why is this cast as a boolean choice? And how has the getting on with IPv6 deployment been working out?

"getting a single extra /4" is considered, not enough of a return to make the change.

I don't accept that, but as far as rehabilitating 240/4, that lot was already cast, I think, and the above was the likely reason, there have been plenty of objections which all amounted to "too much trouble to lift the pen" and change it.....

So if you want some address space rehabilitated, by a change of standard, it apparently needs to be more than a /4.

There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage...

The work to fix this on most OS is minimal. The work to ensure that it could be used safely over the big I Internet is enormous. It's not so much about making sure new equipment can support it than getting servers that don't support it upgraded as well as every box in between.

...

That the discussion continues is in and of itself a verdict. Joe -- -JH

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Sep 19, 2012, at 9:58 PM, Jimmy Hess <mysidia@gmail.com> wrote:

There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage...

Excellent idea. Now build a time machine, go back to 2005, and start work. It will be somewhat less relevant of a solution by 2019, which is about when you finish if you start today... The market window is closed. George William Herbert Sent from my iPhone

On Sep 20, 2012, at 12:21 AM, joel jaeggli <joelja@bogus.com> wrote:

On 9/20/12 12:09 AM, George Herbert wrote:

...

On Sep 19, 2012, at 9:58 PM, Jimmy Hess <mysidia@gmail.com> wrote:

...

There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage...

Excellent idea. Now build a time machine, go back to 2005, and start work.

Sorry it was a bad idea then, it's still a bad idea.

Bad Idea or not, stopgap or not, it was and remains technically, programmatically, and politically feasible. The critical failure is that starting RIGHT NOW would deliver five years-ish too late, which renders it a moot point. In two or three years we may well regret not having done it in 2005; in seven years we will have had to have solved and deployed IPv6 successfully anyways. We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory. All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality. Pining for 240/4 fjords is not a time machine to change the past. George William Herbert Sent from my iPhone

Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will?

Joe

Easy - Greater return on the investment; i.e. - instead of getting an IPv4 /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just for starters, counting neither the rest of the unicast nor multicast, etc. spaces.). Also, the impact of the "changes required" is close to the same in that every node needs to be touched - that is the hard part, getting updates deployed. *(Unless you want 240/4 to be a special/limited use case - in which case the effort is smaller, but so is the reward ...)* /TJ

Let us spin this another way. If you cannot even expect mild change such

...

...

as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will?

Joe

Easy - Greater return on the investment; i.e. - instead of getting an IPv4 /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just for starters, counting neither the rest of the unicast nor multicast, etc. spaces.).

::/3 /48 /64

Do you think we may ever come to regret baking that in? And use that regret to torpedo any attempts at change?

If we do ever grow to regret the /48 and /64 splits, I guess it is a good thing we have 5 more /3s to deal with it ...

As far as roi is concerned, we can make all the calculation we want. What we cannot do is force everyone else to come up with the same numbers we did.

We also cannot make everyone happy all of the time. We can only do the best we can, and make it work as good as we can. Such is life.

Also, the impact of the "changes required" is close to the same in that

...

every node needs to be touched - that is the hard part, getting updates deployed. *(Unless you want 240/4 to be a special/limited use case - in which case the effort is smaller, but so is the reward ...)*

The scope of the change is far far different, no matter the use case. Never more than a simple update.

Yes, but making a change (regardless of size) on a given platform is often dwarfed by the effort of getting the update pushed out, to every possible instance of said platform. Multiply that by the number of platforms ... With IPv6, it is a bigger single change (in code terms), but the hard part (deployment) is roughly the same order of magnitude in deployment. It is also easier to know if your platform is in an area that now has IPv6, vs a router discovering whether or not the hosts understand the new /4. That is, dual-stack (IPv4 + IPv6) create fewer problems than the coexistence of nodes supporting 240/4 and not supporting 240/4. And again, an additional IPv4 /4 is *just a bit smaller* than what IPv6 brings to the table ... /TJ *... all IMHO / IME, of course.*

On 20-Sep-12 14:14, Tony Hain wrote:

...

Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. To some degree yes. In this particular case, why don't you personally go out and tell all those people globally (that have what they consider to be perfectly working machines) that they need to pay for an upgrade to a yet to be shipped version of software ...

In many cases, particularly embedded devices, the vendor may have gone out of business or ceased offering software updates for that product, in which case customers would have to pay to /replace/ the products, not just upgrade them--for no benefit to themselves. Good luck with that. That's why the 240/3 idea was abandoned years ago, and nothing has changed since then. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

-----Original Message----- From: Nick Hilliard [mailto:nick@foobar.org] Sent: Thursday, September 20, 2012 2:37 PM To: Tony Hain Cc: nanog@nanog.org Subject: Re: The Department of Work and Pensions, UK has an entire /8

On 20/09/2012 20:14, Tony Hain wrote:

...

Once the shift starts it will only take 5 years or so before people start asking what all the IPv4 fuss was about.

Tony, ipv4 succeeded because it was compelling enough to do so (killer apps of the time: email / news / ftp, later www instead of limited BBS's, teletext, etc), because the billing model was right for longhaul access (unmetered instead of the default expensive models at the time) and because it worked well over both LANs and WANs (unlike SNA, IPX, decnet, etc).

ipv6 has none of these benefits over ipv4.

You are comparing IPv6 to the historical deployment of IPv4. Get with the times and realize that CGN/LSN breaks all those wonderful location-aware apps people are so into now, not to mention raising the cost for operating the network which eventually get charged back to the user.

The only thing in its favour is a scalable addressing model. Other than that, it's a world of pain with application level support required for everything, poor CPE connectivity, lots of ipv6-incapable hardware out in the world, higher support costs due to dual-stacking, lots of training required, roll-out costs, licensing costs (even on service provider equipment - and both vendors C and J are guilty as accused here),

Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'. The real costs are in app development and support, so crap in the middle of the network (which is only there to keep the network managers from learning something new) will be worked around. While shifting apps to IPv6 has a cost, doing that is a onetime operation vs. having to do it over and over for each app class and new wart that the network managers throw into the middle. IPv4 even with all its warts makes a reasonable global layer-2 network which IPv6 will run over just fine. (Well mostly ... I am still chasing a 20ms tunnel asymmetry which is causing all my IPv6 NTP peers to appear to be off by 10ms)

poor application failover mechanisms (ever tried using outlook when ipv6 connectivity is down?), etc.

Outlook fails when IPv4 service is lame (but I could have stopped at the second word). I use Outlook over IPv6 regularly, and have had more problems with exhausted IPv4 DHCP pools than I have with Outlook over IPv6 in the last 10 years.

The reality is that no-one will seriously move to ipv6 unless the pain of address starvation substantially outweighs all these issues from a

financial perspective. It may be happening in places in china - where

business / there is

ipv4 significant address starvation and massive growth, but in places of effectively full internet penetration and relatively plentiful ipv4 addresses (e.g. the US + Europe + large parts of asia), its disadvantages substantially outweigh its sole advantage.

That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street, then you will have a hard time making a case before the customers have started jumping ship in significant enough numbers that you will never get them back. If your time horizon is measured in decade units, you will have an easier time explaining how a 5 year roll out will alleviate costs and minimize pain down the road. Most of the press and casual observers didn't get the point of the 2003 DoD/US Fed mandates for 2008. That date was not picked because they believed they needed IPv6 in production by 2008, it was picked because they had significant new equipment purchases starting at that point that would be in production well past the point when it becomes likely those devices will find themselves in some part of the world where 'IPv6-only' is the network that got deployed. The only way you turn a ship that big is to set a hard date and require things that won't make sense to most people until much later.

I wish I shared your optimisation that we would soon be living in an ipv6 world, but the sad reality is that its sorry state bears more than a

passing

resemblance to the failure of the OSI protocol stack.

If operators would put less effort into blocking transition technologies and channel that energy into deploying real IPv6, the sorry state wouldn't be there. For all the complaints about 6to4, it was never intended to be the mainstay, it was supposed to be the fall back for people that had a lame ISP that was not doing anything about IPv6. All the complaining about 6rd-waste is just another case of finding excuses because an ISP-deployed-6to4-router with a longer than /16 announcement into the IPv6 table does a more efficient job, and would not have required new CPE ... Yes that violates a one-liner in an RFC, but changing that would have been an easier fix than an entirely new protocol definition and allocation policy discussion. In any case, the end system stacks that are less than 10 years old are ready, so the missing component is to get the app vendors to switch api's. That has been difficult since they are waiting for a network, and the network managers are waiting for apps. The entire point of the transition technologies was to break the dependencies and deadlock. The part that didn't happen that should have was for MSFT to fix DevStudio to constantly scream at the app dev about using a deprecated API, thereby getting them to shift to the new one just to shut the compiler up. If the apps are using the new api, they will continue to use IPv4 if that is all DNS gives them, but as soon as DNS is updated with a AAAA record, all that traffic will shift, and tunnel if it has to. That plan makes network managers upset, because they want to be in control, but if they really want that control they have to get out in front and deploy native IPv6 so the tunnel never starts, or is managed between routers they control. Again the vast majority of the support cost is at the edges, so it is cheaper from the edge perspective to ignore and tunnel over the middle if it is not ready. I focused on MSFT above, but AAPL could do the same at the drop of a hat if they chose to. Consider the impact if AAPL chose to change the requirement for an app to be in the iTunes store such that it 'had to work over an IPv6-only network, and could work over an IPv4 network'. If they coupled that with bundling miredo in the OS X & iOS updates, then published a few AAAA records, the network managers would be blinded to what their customers are doing overnight. All they would see was a vast shift to udp, while the app developers would see cheaper support costs after the initial investment to change api's. So far neither MSFT or AAPL has been willing to push hard on the app development community. If the network managers keep making life harder by inserting even more nonsense into the network, they won't have to do more than suggest there is an easier way, and packet shuffling will become even more of a commodity than it already is, because the endpoints will be working in a different space and immune to changes in service providers. Yes life in the core looks pretty dismal right now, because bean-counters lack vision. Those bean-counters will find replacement jobs though at the ISPs offering IPv6 once the customer base has abandoned the IPv4-only one. The people that will have trouble finding new work will be the ones that should have shouted down the bean-counters and pointed out the cliff they were driving the failed company over. Tony

Nick

-----Original Message----- From: Nick Hilliard [mailto:nick@foobar.org] Sent: Friday, September 21, 2012 9:13 AM To: Tony Hain Cc: nanog@nanog.org Subject: Re: The Department of Work and Pensions, UK has an entire /8

On 21/09/2012 00:47, Tony Hain wrote:

...

You are comparing IPv6 to the historical deployment of IPv4. Get with the times and realize that CGN/LSN breaks all those wonderful location-aware apps people are so into now, not to mention raising the cost for operating the network which eventually get charged back to the user.

Address translation (already commonplace on many networks) is the consequence of the lack of a scalable addressing model. Yup, NAT breaks lots of things. Piles. It sucks.

...

Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'.

Networking people build and (in some cases) care about networks. It's not the job of nanog people to fret about software development.

...

The real costs are in app development and support

It's certainly one of the costs. And application developers have only just begun to realise that they now need to be aware of the network. Previously, they could just open up sockets and fling data around. Now they need to handle protocol failover and multiple connectivity addresses and the like. Yep, it's an extra cost point - one which has been studiously ignored by most ipv6 evangelists over the lifetime of ipv6.

App developers have never wanted to be aware of the network. As far as they are concerned it is the network managers job to get bits from the endpoint they are on to the endpoint they want to get to. Making them do contortions to figure out that they need to, and then how to, tell the network to do that adds complexity to their development and support. This is not an IPv6 issue, it is historic reality. The only place IPv6 gets involved is that it offers a way back to the transparent end-to-end consistent addressing model. The actual path may have firewalls which prevent communication, but that happens on both versions and has nothing to do with the simplicity of a consistent addressing model.

...

That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street,

Most organisations are in this category, not just those beholden to the whims of Wall Street.

...

If operators would put less effort into blocking transition technologies and channel that energy into deploying real IPv6, the sorry state wouldn't be there.

There are never shortages of fingers when failures happen, whether they be used for wagging or pointing.

...

For all the complaints about 6to4, it was never intended to be the mainstay, it was supposed to be the fall back for people that had a lame ISP that was not doing anything about IPv6.

6to4 is full of fail. Inter-as tunnelling is a bad idea.

Asymmetric inter-as tunnelling is worse, and asymmetric inter-as tunnelling based on anycast addresses with no hope of tracing blackholes is complete protocol fail.

Despite the total failure that it causes the ipv6 world, we couldn't even agree on v6ops@ietf that 6to4 should be recategorised as historical. My facepalm ran over my wtf.

But really, 6to4 is a minor player.

...

All the complaining about 6rd-waste is just another case of finding excuses because an ISP-deployed-6to4-router with a longer than /16 announcement into the IPv6 table does a more efficient job, and would not have required new CPE ... Yes that violates a one-liner in an RFC, but changing that would have been an easier fix than an entirely new protocol definition and allocation policy discussion.

I'm not understanding the 6rd hate here. Intra-as tunnelling is fine, because the network operator has control over all points along the way. It fixes

And something that is easy to fix by simply deploying a 6to4 relay in each AS and announcing the correct IPv6 prefix set to make it symmetric. the

problem of having eyeball access devices which don't support v6 properly. Don't hate it - it's useful for some operators, and quite good for deploying v6 over an older infrastructure.

There is no 6rd hate here. I personally spent many hours helping Remi tune up the original doc and get in into the IETF process. My point was that we didn't need to go through that entire process and have extended policy discussions about what size prefix each org needs when they are deploying 6rd. At the end of the day, a 6to4 relay at every point that has a 6rd router does exactly the same thing at the tunneling level (except that 6to4 always results in a /48 for the customer). It may have resulted in more prefixes being announced into the IPv6 table, but given the ongoing proliferation of intentional deaggretation for traffic engineering, there may eventually be just as many IPv6 prefixes announced with 6rd.

...

So far neither MSFT or AAPL has been willing to push hard on the app development community.

This is a generic awareness problem in the developer community and it's

not

microsoft's or apple's business to tell them what to do about it. Deprecating historic APIs is fine, but you cannot force an application developer to do what they don't want to do. Software didn't get ported from ipx and decnet to ipv4 just because the compiler manufacturers nagged the developers about it.

Those ports happened because there were more endpoints reachable directly without having to deal with network layer gateways and translators. IPv4 lost that with RFC 1597, and with the layering of the problem that is ahead, the app community will be driven away. MSFT & AAPL can't make the app developers change, but they can offer a path to make their life easier. If one does so and word starts to spread that "it is easier to build and support location aware apps on platform Z", expect the other to announce the same tool set to counter that. In some ways I am surprised that GOOG hasn't already started something like that for the 4G android devices, but maybe it just hasn't gone public yet ...

IPv6 will become commonplace when there is a compelling reason for it to

do

so. History tells us that it won't happen before this point.

And network managers that are squeezing the balloon to over optimize their part of the system without concern for the rest will provide the compelling event. Those that are doing so intentionally, while providing the long term path in parallel, can be described as weaning their customers off the legacy. Those that are doing so inadvertently, because they don't care about anything but their tiny part of the overall system, will lose customers to the provider offering the long term path. Tony

Nick

In message <505CDD21.4080103@foobar.org>, Nick Hilliard writes:

On 21/09/2012 19:23, Tony Hain wrote:

...

App developers have never wanted to be aware of the network.

By not sitting down and thinking about the user experience of a dual-stacked network, we have now forced them to be aware of the network and that's not a good thing because they are as clued out about networking as most network operators are about programming. If we had designed a portable and consistent happy-eyeballs API 10 years ago, it would be widely available for use now. But we didn't do that because we were thinking about the network rather than the users. So now, each dual stack developer is going to have to sit down and reimplement happy eyeballs for themselves. What a waste.

RFC 1123 told app developers that they needed to support multihomed servers. That was over 2 decades ago. HE would not have been needed if app developers had followed that advice.

...

As far as they are concerned it is the network managers job to get bits from the endpoint they are on to the endpoint they want to get to. Making them do contortions to figure out that they need to, and then how to, tell the network to do that adds complexity to their development and support. This is not an IPv6 issue, it is historic reality.

No, it's a current reality for early venturers into ipv6. It may become a future reality in the mainstream if ipv6 takes off in a way that I can't foresee at the moment. One day in the future, maybe, it will become less of an issue if people go back to a single-stack endpoint system.

IPv6 will still be multi-homed. Dual stack is just a example of multi-homed.

...

And something that is easy to fix by simply deploying a 6to4 relay in each AS and announcing the correct IPv6 prefix set to make it symmetric.

In theory yes. In practice no.

...

event. Those that are doing so intentionally, while providing the long term path in parallel, can be described as weaning their customers off the legacy. Those that are doing so inadvertently, because they don't care abou t anything but their tiny part of the overall system, will lose customers to the provider offering the long term path.

So long as the cost of that is less than the cost of deploying ipv6 and pushing people in that direction, it's a good business plan in the short term. Which is what most people care about. I'm with you that it's a hopeless long term business plan, but that's not the world we live in.

Nick

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Thu, Sep 20, 2012 at 7:10 AM, Joe Maimon <jmaimon@ttec.com> wrote:

George Herbert wrote:

...

We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory.

All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality.

Pining for 240/4 fjords is not a time machine to change the past.

What is not amusing is continued evidence that the lessons from this debacle have not been learned.

Or that other past lessons are being forgotten.

Baking in bogonity is bad.

Ok, but the bogonity is baked in in two areas already; both 240/4 and IPv6. 240/4 is baked in (or out) of IPv4 on a large quantity of deployed firmware and devices, and larger quantity of local OS IPv4 stacks. The local OSes are, as a rule, upgraded on 2-3 year timelines and patched in many cases something like annually or every few months. Firmware, less so. As someone else pointed out, a lot of those devices are not under support anymore or from now defunct vendors, so a hardware replace is the fix. IPv6 was also baked out of a large quantity of deployed firmware and devices, and OS stacks. This has largely already been remedied, and people are largely aware that device firmware that's not upgradable needs replacement, so the fix is mostly in and already most of the way through happening. In both cases, a roughly 7-10 year total process in practice; in one case, we're already 5-6 years of serious effort in to it. Do you understand the difference between starting a 7, 8, 10 year process fresh from zero right now versus continuing one we're nearly done with?

Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling.

No. This is a classic techie-makes-business-failure problem. You are not creating products for today's customers. You're creating products for customers who will be there when the product is ready. You're not creating a product to compete with today's products; you're competing with the products that will be out when it's done and shipping, and that come out subsequently. This is what "market window" is all about.

Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will?

We're somewhere around 2/3 of the way through on the IPv6 changes. We haven't started a 240/4 activation project yet. We have found while doing the IPv6 that there are some glitches; a very few of them at protocol level, with so-far tolerable workarounds or adjustments in expectations. A lot of them at operational process and usage levels. A lot more of them at business / user levels. There's a difference between "IPv6 doesn't work" and "IPv6 is not perfect". IPv6 is deployed, running nationally, represents 0.6-1.0% of active IP traffic right now to big websites depending on who you talk to (Google was 0.6% I think, Wikipedia reporting 0.8% on an internal list a couple of weeks ago, etc). It's obviously not "doesn't work" as it's showing functional IPv6 traffic levels that approximate those of the whole Internet 15 years ago. It's obviously not perfect. It's asserted that the operational problems are big for a number of sites, but others are making it work. We'll have to see on that. In any case, it's not 7-10 years away from working. Even if we have to respin a support protocol (DHCPv6.1, anyone?) the core protocol and most of the stacks and the routers and devices probably wouldn't need replacement. Someone who objects to current operational issues is likely to eventually (soon) just write code rather than wait for arguments to settle and the protocol wizards to pronounce. Running code trumps theory and argument. If you think you can accomplish a full 240/4 support rollout across the world's devices and infrastructure faster than we can get IPv6 running, I would suggest that you reconsider. It's an easier fix at one level only - the code in the stacks that needs changing is relatively minor. Even if the protocol and code changes were completely done tomorrow by magic, the deployment phase, all 5+ years of it, is starting at zero. IPv6 is deployed; not universally, but most of the way through. We're shaving operational issues with the protocol and support protocols off now, and dealing with deployments into slow-adopters. IPv6 is able to be operational for many people now; 240/4 would not be operational for anyone in a safe sense until 2017-2020. This is a classic market window failure. It's not just engineering. Timing is ultimately just as important. -- -george william herbert george.herbert@gmail.com

On 09/19/2012 15:36, Joe Maimon wrote:

So 6-8 years to try and rehabilitate 240/4 was not even enough to try?

All the experts I consulted with told me that the effort to make this workable on the big-I Internet, not to mention older private networks; would be equivalent if not greater than the effort to deploy v6 ... and obviously with much less long-term benefit. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)

So 6-8 years to try and rehabilitate 240/4 was not even enough to try?

Since it would require upgrading the IP stack on every host on the internet, uh, no. If you're planning to do that, you might as well make the upgrade handle IPv6.

...

and no quantity of pixie dust is going to cause new space to appear out of thin air.

No, but money can work wonders, once the IP address space market comes out of the shadows. R's, John

You know what sucks worse than NAT? Memorizing an IPv6 address. ;) To everyone: Thanks for the clarifications. I don't necessarily agree with some of the arguments...but since I'm not fortunate enough to be in possession of a /8, that agreement (or lack thereof) is worth the electrons this email is sent with (less so, even). The assumption behind my original question is that the IP space simply isn't used anywhere near as efficiently as it could be. While reclaiming even a fraction of those /8s won't put off the eventual depletion, it'll make it slightly more painless over the next year or two. Is that worth the effort required in getting them back? *shrug* Probably not? At any rate, thanks for taking the time to respond. I'll stop derailing the thread now. On Tue, Sep 18, 2012 at 10:05 PM, Randy Bush <randy@psg.com> wrote:

...

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans."

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool?

QED

the ipv4 pool is about gone, move to ipv6 nat sucks bigtime, big nats suck even bigger global bgp never converges all devices fail, often two or more at once 'private' routing announcements will leak unless there is an air gap

get over it and get back to work moving packets

randy

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

There is something that I think they call DNS. It may help. :) .as On 19 Sep 2012, at 02:27, Mike Hale wrote:

You know what sucks worse than NAT?

Memorizing an IPv6 address. ;)

On Tue, 18 Sep 2012, Owen DeLong wrote:

On Sep 18, 2012, at 21:11 , Mike Hale <eyeronic.design@gmail.com> wrote:

...

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans."

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? Many of them _ARE_ using them, just not using them directly on the public internet. There is nothing wrong with that.

As others have said... !announced != !used.

Is they are not using them directly on the public internet, then there's no reason we can't use them. Problem solved! -Dan

In message <Pine.LNX.4.64.1209182339200.5518@sasami.anime.net>, goemon@anime.ne t writes:

On Tue, 18 Sep 2012, Owen DeLong wrote:

...

On Sep 18, 2012, at 21:11 , Mike Hale <eyeronic.design@gmail.com> wrote:

...

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans."

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? Many of them _ARE_ using them, just not using them directly on the public internet. There is nothing wrong with that.

As others have said... !announced != !used.

Is they are not using them directly on the public internet, then there's no reason we can't use them.

Problem solved!

-Dan

!announced whole world != !announced. There is a simple rule. DO NOT USE ADDRESSES THAT YOU HAVE NOT BEEN ALLOCATED. Anything else has the potential to cause operational problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 19/09/12 08:04, goemon@anime.net wrote:

On Wed, 19 Sep 2012, Mark Andrews wrote:

...

In message <Pine.LNX.4.64.1209182339200.5518@sasami.anime.net>, goemon@anime.ne t writes:

...

On Tue, 18 Sep 2012, Owen DeLong wrote:

...

...

"this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans."

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? Many of them _ARE_ using them, just not using them directly on the

On Sep 18, 2012, at 21:11 , Mike Hale <eyeronic.design@gmail.com> wrote: public internet. There is nothing wrong with that.

As others have said... !announced != !used.

Is they are not using them directly on the public internet, then there's no reason we can't use them.

Problem solved! !announced whole world != !announced.

There is a simple rule.

i guess my sarcasm was missed.

...

DO NOT USE ADDRESSES THAT YOU HAVE NOT BEEN ALLOCATED.

Anything else has the potential to cause operational problems.

Tell that to the providers who keep routing hijacked blocks for spammers :)

-Dan

On the other hand, the scarcity is of *globally unique routable* addresses. You can make a case that private use of (non-RFC1918) IPv4 resources is wasteful in itself at the moment. To be provocative, what on earth is their excuse for not using IPv6 internally? By definition, an internal network that isn't announced to the public Internet doesn't have to worry about happy eyeballs, broken carrier NAT, and the like because it doesn't have to be connected to them if it doesn't want to be. A lot of the transition issues are much less problematic if you're not on the public Internet. Perhaps the military have a lot of weird equipment that is IPv4 only - in fact it's a racing certainty - but DWP is a gigantic enterprise data processing organisation. They also have some big Web sites, but obviously those aren't on the private network. (If they had enough workstations to need the whole /8, we wouldn't need DWP as the unemployment problem would have been definitively solved:-))

On 9/19/12 10:42 AM, Jo Rhett wrote:

And second, have you ever worked on a private intranet that wasn't connected to the internet through a firewall? Skipping oob networks for equipment management, neither have I. Plenty of people on this list have worked on private internet(s) with real AS numbers, public IP space and no direct internet connectivity.

On Sep 19, 2012, at 1:42 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

And second, have you ever worked on a private intranet that wasn't connected to the internet through a firewall? Skipping oob networks for equipment management, neither have I.

Yes, for many years. External connections only via Application Level Gateways for SMTP, HTTP and Virtual Network connections. And, using assigned IPv4 addresses. And, no one willing to pay for IPv6.

From: Jo Rhett <jrhett@netconsonance.com> Date: Wed, 19 Sep 2012 10:42:30 -0700 Subject: Re: The Department of Work and Pensions, UK has an entire /8

[[ sneck ]]

And second, have you ever worked on a private intranet that wasn't connected to the internet through a firewall? Skipping oob networks for equipment management, neither have I.

Yes, in fact, I have. <grin> In the financial and/or brokerage communities, there are internal networks with enough 'high value'/sensitive information to justify "air gap" isolation from the outide world. Also, in those industries, there are 'semi-isolated' networks where all external commnications are mediated through dual-homed _application- layer_ gateways. No packet-level communications between 'inside' and 'outside'. The 'inside' apps onl know how to talk to the gateway; server- side talks only to specific (pre-determined) trusted hosts for the specific request being processed. NO 'transparent pass-through' in either direction.

On Wed, 19 Sep 2012 18:46:54 -0700, Jo Rhett said:

You're all missing the point in grand style.

Given that the entire thread is based on somebody who missed the point in totally grand style and managed to get press coverage of said missing the point, I am starting to suspect that several people in the thread are doing so intentionally to see how hard they can troll the NANOG list without anybody catching on.

On Sep 19, 2012, at 7:09 PM, Brett Frankenberger wrote:

It works fine if the gateway has multiple routing tables (VRF or equivalent) and application software that is multiple-routing-table aware.

If you are arguing that it is technically possible to build an environment in which every piece of software is aware at an application level whether or not a given service is inside the network or outside the network and thus eliminate issues with routing overlaps… uh, sure. I agree that you can do this in a very customized environment. Now if you want to suggest that most businesses with a diversity of applications and access methods should be doing this, in order to allow overlapping IP usage on the internet, I'm going to have to point and giggle. I really love how everyone keeps advancing these "businesses should rebuild their entire infrastructure, at their cost, and with no benefit to themselves, so that I can use their IP space!" arguments. Ya huh. Right. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.

On 19-Sep-12 03:46, Alex Harrowell wrote:

On the other hand, the scarcity is of *globally unique routable* addresses. You can make a case that private use of (non-RFC1918) IPv4 resources is wasteful in itself at the moment. To be provocative, what on earth is their excuse for not using IPv6 internally? By definition, an internal network that isn't announced to the public Internet doesn't have to worry about happy eyeballs, broken carrier NAT, and the like because it doesn't have to be connected to them if it doesn't want to be. A lot of the transition issues are much less problematic if you're not on the public Internet.

Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available. The "enterprise" networking world is just as ugly as, if not uglier than, the consumer one. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

On 20-Sep-12 20:51, George Herbert wrote:

On Thu, Sep 20, 2012 at 5:13 PM, Stephen Sprunk <stephen@sprunk.org> wrote:

...

Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available.

The "enterprise" networking world is just as ugly as, if not uglier than, the consumer one.

I haven't worked much on the commercial private internets, but I did work for someone who connected on the back end into numerous telco cellphone IP data networks.

For all of those who argue that these applications should use 1918 space, I give you those networks, where at one point I counted literally 8 different 10.200.x/16 nets I could talk to at different partners (scarily enough, 2 of those were "the same company"...). And hundreds and hundreds of other space conflicts.

That's all? I consulted for one customer that had several (six? eight?) instances of 10/8 within their own enterprise, simply because they needed that many addresses. That doesn't include the dozens of legacy /16s they used in their data centers--plus the hundreds of legacy /24s they used in double-sided NAT configurations between them and various business partners, COINs, etc. Yet all that was exposed to the consumer internet was a couple of /24s for their web servers, email servers and VPN concentrators.

Yes, you can NAT all of that, but if you get network issues where you need to know the phone end address and do end to end debugging on stuff, there are no curse words strong enough in the English language.

That's the truth. To get from a credit card terminal to the bank involved _at least_ three layers of NAT on our side, and I don't know how many layers of NAT there were in total on the bank's side, but it was at least two. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

Op 19-9-2012 14:35, Leo Bicknell schreef:

...

I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? There's also a ROI problem. People smarter than I have done the math, and figured out that if X% of the address space can be reclaimed via these efforts, that gains Y years of address space. Turns out Y is pretty darn small no matter how agressive the search for underutilized space. Basically the RIR's would have to spin up more staff and, well, harass pretty much every IP holder for a couple of years just to delay the transition to IPv6 by a couple of years. In the short term moving the date a couple of years may seem like a win, but in the long term its really insignificant. It's also important to note that RIR's are paid for by the users,

In a message written on Tue, Sep 18, 2012 at 09:11:50PM -0700, Mike Hale wrote: the ramp up in staff and legal costs of such and effort falls back on the community. Is delaying IPv6 adoption worth having RIR fees double? Forcing a government organization to renumber their (large!) network to 10/8 just to give it back it to ARIN would be a massive undertaking. There are considerable drawbacks:

1. The renumbering of a government organization is payed for by the UK taxpayers. I'm sure the UK can use the funds somewhere else right now. 2. The time taken to complete this operation would likely run into years, see 1. 3. Even if the renumbering completes by 2015 it would be far too late, since we need it now rather then later. 4. The actual value of the "sale" of the /8 could either be huge in 2015, or insignificant in 2015. So the irony is that the taxpayer lobbying for return wants to have the /8 returned to or sell it. But there is a significant non-zero cost and he would be paying for it himself. I also like the idea of public services to be reachable in the future. Just because it is not in use now, I'll see them using it in the future. Regards, Seth

On Tue, Sep 18, 2012 at 3:17 PM, Paul Thornton <prt@prt.org> wrote:

On 18/09/2012 15:07, Eugen Leitl wrote:

...

http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in...

Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 Addresses

The only slight snag in his argument is that the addresses are not unused. Not announced != Not used.

And for the definitive answer on this block, the official response is: http://www.whatdotheyknow.com/request/internet_protocol_ipv4_address_a and http://www.whatdotheyknow.com/request/internet_protocol_ipv4_address_a_2

1. We can confirm that the address block is assigned to the DWP.

2. In principle, none of the address space is exposed to the public Internet. There may be a very small number of addresses that have been exposed for specific purposes, but certainly no significant block of addresses is visible from the public Internet.

3. The address space is already shared across government. We have used or allocated approximately 80% of the address space, and have earmarked the remaining space for use within the proposed Public Services Network (PSN). The PSN is building an Internet for government, and the DWP address space is a key building block for delivery of this.

4. DWP have no plans to release any of the address space for use on the public Internet. The cost and complexity of re-addressing the existing government estate is too high to make this a viable proposition. DWP are aware that the worldwide IPv4 address space is almost exhausted, but knows that in the short to medium term there are mechanisms available to ISPs that will allow continued expansion of the Internet, and believes that in the long term a transition to IPv6 will resolve address exhaustion. Note that even if DWP were able to release their address space, this would only delay IPv4 address exhaustion by a number of months.

And for 25.0.0.0 to 25.255.255.255 the response from the Ministry of Defense is:

I can confirm that the IPv4 address block about which you enquire is assigned to and owned by the MOD; however, I should point out that within this block, none of the addresses or address ranges are in use on the public internet for departmental IT, communications or other functions. To date, we estimate that around 60% of the IPv4 address block has been allocated for internal use. As I am sure you will appreciate, the volume and complexity of the Information Systems used by the Armed Forces supporting military operations and for training continues to develop and grow. We are aware that the allocation of IPv4 addresses are becoming exhausted, and the issue has been recognised within the Department as a potential future IS risk. In summary, therefore, we are unable to consider releasing parts of the address block that has been allocated to the UKMOD for reassignment to non-UK Government organisations.

And someone should further alert him that they do not "own" these addresses.

MIT is probably using less of their /8 than MOD is, and as far as I know, MIT has neither commando forces nor nuclear weapons. You might want to pick, so to speak, your battles more carefully. R's, John

Are we still talking about this? I setup a lan at home once at that used 6/8 :) On Tue, Sep 18, 2012 at 6:17 PM, Christopher Morrow <morrowc.lists@gmail.com

wrote:

On Tue, Sep 18, 2012 at 5:10 PM, John Levine <johnl@iecc.com> wrote:

...

...

And someone should further alert him that they do not "own" these addresses.

MIT is probably using less of their /8 than MOD is, and as far as I know, MIT has neither commando forces nor nuclear weapons.

You might want to pick, so to speak, your battles more carefully.

more over, who cares? a /8 is less than 2 months rundown globally... and, once upon a time I constructed on this list a usecase for apple's /8 ... it's really not THAT hard to use a /8, it's well within the capabilities of a gov't to do so... especially given they PROBABLY have: o unclassified networks o secret networks o top secret networks o other networks

I'm sure there's plenty of ways they could use the space in question.

On Tue, Sep 18, 2012 at 4:29 PM, John R. Levine <johnl@iecc.com> wrote:

On Tue, 18 Sep 2012, james jones wrote:

...

Are we still talking about this? I setup a lan at home once at that used 6/8 :)

They have nuclear weapons, too. Just saying.

Which, the Army? I don't believe that's true anymore. I think all the Army nuclear weapons have been disassembled or retired. (Quick check... B61, W76, W78, W80, B83, W84, W87, W88... The W84 was in the GLCM, and B61-10 used to be W85s in the Pershing II missiles, but those delivery vehicles are all chopped up). Or is 6/8 used by more of .mil than just the Army? -- -george william herbert george.herbert@gmail.com

On 18 Sep 2012, at 15:32, Nick Hilliard <nick@foobar.org> wrote:

On 18/09/2012 15:07, Eugen Leitl wrote:

...

Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 Addresses

"unused"? sez who? Oh, it said it on the internet so it must be true.

Other than that, I'm totally failing to see what's newsworthy about who or what happens to hold a legacy /8. Could someone explain?

Pssst! Want a nice unused /4? Yours cheap! Tim

I'm having problems finding any announcements for this net 10/8, too. Can someone talk to these "IANA" folks about reclaiming it, too? They have a bunch of other space in 172.x they should be able to use... George William Herbert Sent from my iPhone On Sep 18, 2012, at 8:36 AM, "John Levine" <johnl@iecc.com> wrote:

...

John Graham-Cumming, who found this unused block, wrote in a blog post that the DWP was in possession of 51.0.0.0/8 IPv4 addresses.

Please, don't anyone tell him about 25/8.

Well 172.0.0.0 to 172.15.255.255 is now owned by AT&T and they have live systems on some of them already. On 18 September 2012 17:39, George Herbert <george.herbert@gmail.com> wrote:

I'm having problems finding any announcements for this net 10/8, too. Can someone talk to these "IANA" folks about reclaiming it, too? They have a bunch of other space in 172.x they should be able to use...

George William Herbert Sent from my iPhone

On Sep 18, 2012, at 8:36 AM, "John Levine" <johnl@iecc.com> wrote:

...

...

John Graham-Cumming, who found this unused block, wrote in a blog post that the DWP was in possession of 51.0.0.0/8 IPv4 addresses.

Please, don't anyone tell him about 25/8.

-- ฤ๊๊๊๊๊็็็็็๊๊๊๊๊็็็็ ฮ้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้ ฦ้้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้ BaconZombie LOAD "*",8,1

Robert, On Sep 19, 2012, at 1:35 PM, Robert Guerra <rguerra@privaterra.org> wrote:

Am I correct in assuming that the unused IP block would not be sold as is mentioned in the article, but instead be returned to RIPE to be reallocated?

Assuming for the sake of argument that the 51/8 is actually unused (which it apparently isn't), the UK gov't would be under no contractual obligation to return the address space to IANA (which is (arguably) the allocating registry, not RIPE) -- I believe that "class A" was allocated prior to the existence of the RIRs and registration service agreements. Regards, -drc

In article <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> you write:

Am I correct in assuming that the unused IP block would not be sold as is mentioned in the article, but instead be returned to RIPE to be reallocated?

Since there is no chance of either one happening, no. R's, John