Subject: Re: Consensus Call: draft-weil-shared-transition-space-request

From: Ida Leung <[email-masked]>
Date: Tue, 29 Nov 2011 19:40:36 -0800 (PST)

All,
 
I read a lot of emails today regarding this subject.  I would like to express my personal thought on it.   I support the allocation of the /10 for this purpose as laid out 
in "draft-weil-shared-transition-space-request" 
In organizations like the one I work for, we have solid IPv6 
rollout plans which include the necessity to support some ongoing IPv4 
connectivity beyond run out.  This is related to the fact that too mach 
IPv4-Only equipment remains in the network (and still on retail store selves, 
selling daily just in time for Christmas demand) which cannot be feasibility 
removed in a short period of time.
We have worked tirelessly with vendors to move forward, but 
reality is king.  IPv4 (with address sharing in some form) will need to 
accompany the IPv6 deployment for a period of time, of which CGN plays a vital 
role (in the form of CGN and later potential in the form of DS-Lite or the such 
technologies).
To facilitate this functionality, non-RFC1918 space will need to 
be used such that we can offer a working service to customers.  Using a 
pre-defined allocation helps us and other operators achieve a deterministic 
approach without the variances of needing to find other, less legitimate space 
for such purpose.  The alternative to the /10 is likely squat space.  Worse 
yet.. Many operators choosing many pools of RIR space which in aggregate will be 
much greater then a single /10 (with no guidance as to what and how it's 
used).
...Ida

---

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 29 Nov 2011 21:09:22 -0700

I concur that we need to be realistic about this. Having had discussions with operators who are trying to deploy IPv6, the reality is that even if IPv6 were enabled universally tomorrow - a subset of subscribers, subscribers' devices/applications, and content providers will only support IPv4 until key pieces of consumer gear are replaced (many of which do not yet support IPv6, even if replaced). CGN facilitates transition, as the move to IPv6 happens.

ISPs have already indicated (a few times) that RFC1918 space is not practical behind the CGN due to the (real) possibility of overlap with customer addressing. Thus, having a shared /10 minimizes the use of public globally assigned addresses and avoids address squatting.

- S
(as an individual contributor)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ida Leung
To: [email-masked]; [email-masked]
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request

All,

I read a lot of emails today regarding this subject.  I would like to express my personal thought on it.   I support the allocation of the /10 for this purpose as laid out in "draft-weil-shared-transition-space-request"
In organizations like the one I work for, we have solid IPv6 rollout plans which include the necessity to support some ongoing IPv4 connectivity beyond run out. This is related to the fact that too mach IPv4-Only equipment remains in the network (and still on retail store selves, selling daily just in time for Christmas demand) which cannot be feasibility removed in a short period of time.
We have worked tirelessly with vendors to move forward, but reality is king. IPv4 (with address sharing in some form) will need to accompany the IPv6 deployment for a period of time, of which CGN plays a vital role (in the form of CGN and later potential in the form of DS-Lite or the such technologies).
To facilitate this functionality, non-RFC1918 space will need to be used such that we can offer a working service to customers. Using a pre-defined allocation helps us and other operators achieve a deterministic approach without the variances of needing to find other, less legitimate space for such purpose. The alternative to the /10 is likely squat space. Worse yet.. Many operators choosing many pools of RIR space which in aggregate will be much greater then a single /10 (with no guidance as to what and how it's used).
...Ida

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2011 13:30:16 +0900

anyone who thinks this will not be used as 1918 space should share
what they are smoking.  the question is not if, but rather how many
milliseconds before it is.  that is the operational reality.

and we should have a betting pool on how long before it is leaked
into a measure such as route-views.

and all this is aside from the pnp, skype, ... and other breakage.
and, imiho, we can screw ipv4 life support.

this has become a contest of wills, not a technical discussion.

randy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Nov 2011 15:49:38 +1100

> milliseconds before it is.  that is the operational reality.

And what harm to others does that cause?  If a ISP is using this and
the customer is using this rather than RFC 1918 space then they only
have themselves to blame for operational problems it causes.

> into a measure such as route-views.

And users would be advised to filter routes for it the same as they
should be filtering routes for other space they are using.
 
> and, imiho, we can screw ipv4 life support.

skype etc. will learn.  This does prevent the breakage it just makes
it more controlled.  What's the bet Skype has a patched released
within a week of this being made available?

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2011 14:09:32 +0900

> within a week of this being made available?

cool.  then, by that logic, let's use 240/4.  the apps will patch within
a week.  ok, maybe two.

i will spare you cites to the measurements of patch installation, or
lack thereof.

randy

---

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 29 Nov 2011 22:13:05 -0700

I did share what I was smoking - it's called 'reality' :).

On a serious note, there aren't many clean (practical) solution that I am aware of as we migrate to IPv6. Given where  are, and considering the harm caused by the alternatives of not having a reserved space (inaction -> squatting), the proposed option certainly seem better, IMO.

To your point, I agree that the perils of misuse exist - and those who do misuse (e.g., customers who use this space incorrectly, in conflict with ISPs) will have themselves to blame (and are probably smart to correct themselves?). Others that can break may break due to this  - but, IMHO - would probably adapt more quickly than customer equipment adapting to support IPv6 overnight (which would seriously be nice!)...

My $0.02!

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 30 Nov 2011 00:19:43 -0500

Randy

>and, imiho, we can screw ipv4 life support.

Non-RFC1918 space is already used widely in Wireless Networks within CGN
Zones.
 
In fact I placed a number of Skype calls today from behind a CGN which is
behind a Wireless Gateway (numbered in non-RFC1918 on Radio link).

Setup:
<HOST> RFC1918 <GATEWAY> NON-RFC1918 <CGN> PUBLIC ADDRESS <PEERING>
INTERNET <SERVICE>

I also VPNed into another network from behind the same infrastructure to
do some work, wrote emails, did some shopping online and watched a Kevin
Hart Standup Movie on Netflix - all the things most people do.

>this has become a contest of wills, not a technical discussion.

Did the above count towards the technical discussion?

Regards,

Victor K

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2011 14:45:33 +0900

> On a serious note, there aren't many clean (practical) solution that I
> am aware of as we migrate to IPv6.

talk to free.fr, camron byrne, ...  there are roadmaps.

but this proposal is not about migrating to ipv6.  it is about ipv4 life
extension and nat4444444 4ever.  to hell with that.

randy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Nov 2011 16:46:18 +1100

> cool.  then, by that logic, let's use 240/4.  the apps will patch within

240/4 is not treated as unicast / routable by many OS.
 
> i will spare you cites to the measurements of patch installation, or

Skype, by default, will tell you when there is a patch available.
Also if you don't patch you are not in a worse position than you
will be when your ISP starts to hand you ambigious addresses that
are not identified as such.

What we do in is a way for the customers to request non-ambigious
addresses in response to DHCP/PPP etc. requests along side this
allocation and for the return address to be properly annotated.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 Nov 2011 06:16:02 +0000

> I did share what I was smoking - it's called 'reality' :).

Which reality? I think Randy is much more realistic!

You are telling us that you want a /10 of private address space set aside because you cannot use the current allocation of private address space in RFC 1918. You tell us that the effect you want to achieve cannot be attained if the address that you use are also used by customer networks. But then, there is no mechanism whatsoever that would prevent customer networks from using the new /10 as soon as it would be allocated. Sure, you may put text in a RFC somewhere, but that is not a mechanism. Ergo, if we were to make that allocation, it will become unusable for your stated purpose in a very short time. 

I think that's not a very good idea. I would rather not see that allocation being made.

-- Christian Huitema

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 29 Nov 2011 22:17:27 -0800

> 240/4 is not treated as unicast / routable by many OS.

Necessity is the mother of invention. There was already an assumption that
patches will be made for draft-weil, 240/4 will cut deeper for sure.

Truth told, I only started ipv6 pushing after my 240/4 efforts proved
fruitless with the ietf and my vendors.

I hope the networks supporting draft-weil can turn that same corner.

Cb

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Nov 2011 17:22:26 +1100

In message <[email-masked].
microsoft.com>, Christian Huitema writes:
> You are telling us that you want a /10 of private address space set aside b=
> ecause you cannot use the current allocation of private address space in RF=
> C 1918. You tell us that the effect you want to achieve cannot be attained =
> if the address that you use are also used by customer networks. But then, t=
> here is no mechanism whatsoever that would prevent customer networks from u=
> sing the new /10 as soon as it would be allocated. Sure, you may put text i=
> n a RFC somewhere, but that is not a mechanism. Ergo, if we were to make th=
> at allocation, it will become unusable for your stated purpose in a very sh=
> ort time.=20
> 
> I think that's not a very good idea. I would rather not see that allocation=
>  being made.

	By that logic I call for RFC 1918 to be made historic.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 29 Nov 2011 22:40:39 -0800

> Which reality? I think Randy is much more realistic!

+1

> I think that's not a very good idea. I would rather not see that allocation being made.

That is my view as well.  I think this is a bad idea for the reasons stated. 
 
Bob

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 Nov 2011 17:19:10 +0700

Date:        Tue, 29 Nov 2011 21:09:22 -0700
    From:        Sumanth Channabasappa <[email-masked]>
    Message-ID:  <76AC5FEF83F1E64491446437EA81A61F81D7CBBA11@srvxchg>

This whole question is weird, when someone needs an address to use,
and given that the pool of free (or close to it), that is, easily
available, addresses no longer exists, I'm going to take whatever
address will work for me for its purpose.

What the various addresses are marked as in some RFC or IANA list, is
immaterial, all that matters is what works.

If that means "borrowing" (or squatting if you prefer) on the addresses
some ISP in some remote part of the world  uses for its customers, that my
customers will never need to communicate with (in my opinion), then that's
what I will do.

More likely, if I can, will be to take some address that I know can't
be needed, and use that - 1918 addresses are in that category.  So is the
"documentation prefix" (which only has as its problem that it is too
little address space to actually use for most purposes).  The only real 
criteria is whether the address I'm considering is in the routing tables or
not - if it isn't, regardless of reason, then I can use it without harm.

For most purposes, the 1918 address space is going to be the right choice
whenever I don't need a routable address, and it is here too.

  | ISPs have already indicated (a few times) that RFC1918 space is not
  | practical behind the CGN due to the (real) possibility of overlap
  | with customer addressing.

Frankly, that's nonsense.   Not that there's the possibility of overlap,
of course there is that possibility.   And not that things would break
if there was a duplicate allocation on both sides, they might, probably
even would.  But that that actually matters if done sensibly.

We know that normal consumer CPE equipment doesn't use network 10 (you
just have to look at some to see that, they almost all use 192.168
addresses).  Further, it is hard to imagine how any network not managed
by network professionals would, or could, ever use network 10, with the
possible exception of 10.0.0/24 or 10.255.255/24 which are numbers that
one might imagine some odd CPE manufacturer might just pluck from the
air.

If the ISP were simply to use 10.64.0.0/10 as the /10 they claim to need
for their CGN's, the chances of that conflicting with any customer who
doesn't have a network staff smart enough to deal with the issue is
basically zero.

For the one in a thousand (probably less) customers who do end up having a
problem, there are plenty of other 1918 addresses that the ISP could pick from,
for that individual customer, which would not cause problems.  Certainly,
no-one is going to want to have to deal with every individual customer,
but dealing with one or two odd cases should be no burden.

Further, I can't imagine that the ISPs aren't aware of this, they know
what CPE equipment is being used, and how it is typically configured.
They also know they could cope with the one in a thousand end user who
actually has configured 10.64/8 in the inside of their CPE, and isn't
willing to change that.

The paranoid in me suspects that the IESG should not be making a decision
to approve a /10 for CGN usage without making sure the anti-trust policy
that's being discussed in another thread is in place, and that everything
in this request has been in accordance with that policy.   That's because,
to me, this smells like a cartel of major ISPs with plenty of allocated
IPv4 address space (legitimately allocated, and used properly right now)
looking for a blessing from the IETF (that using private addresses and CGNs is
OK) to be able to reclaim much of their currently allocated v4 address space.
And I cannot imagine a single one of them (or almost any) just returning
that space to the RIR's for allocations - in many countries, doing so (by
any of the major ISPs that are listed public companies) would probably be
a breach of the director's duty to properly manage the resources of the
company - since addresses (address blocks) sell for such high returns these
days, simply giving away whatever the company has had allocated could easily
lead to prison terms for the directors of the ISP...   Other than small
privately owned ISPs, they really cannot return the addresses, so their
only option is to be selling the things for the profit they'd gain.

Does the IETF really want to be blessing a doc written by a group who all
appear to come from the very types of ISPs who would be subject to & likely
to benefit from such an action?   (Note: I am not intending to suggest that
any of the authors of the doc was actually planning such an action, just
looking at how it all appears from the outside.)

Lastly, while I am here, I have absolutely no sympathy at all for
manufacturers of consumer equipment (or any equipment) that is currently
being sold, or has sold in the past 5 years (at least) that is not
able to use IPv6 rather than IPv4 for network connectivity.   Which it
should actually use in practice is a different issue, but any IPv4 only
equipment on the market is not our problem.  We do not need to keep making
that trash functional.  If people buy it, and it fails to work, let them
just return it for a refund.   The manufacturers will soon learn then.

At the minute, this policy of "we must keep IPv4 working because there
are still people with no other choice, and there keep being more new
users with no other choice" is just penalising the equipment manufacturers
who have invested the time & effort to be ready for when IPv6 is needed,
in order to favour those who have only ever been concerned about today's
bottom line.   It is time to draw the line, and start telling people that,
as predicted, IPv4 addresses are now exhausted, and to connect, they need
to use IPv6.    If, short term (one hopes) we need some IPv6->IPv4 type NAT
(NAT-PT) then at least that's a step towards a long term solution, rather
than yet another attempt to avoid change, which is all CGN's are.

If the IESG eventually decide to go ahead and publish the draft in
question, the number they should fill in in the IANA considerations
section should be 10.64.0.0/10 or 10.192.0.0/10 - reducing the pool of
available routable addresses, even further, even by just a /10 (0.1% of
the available address space) would be insane.   Reducing the pool of 1918
addresses by a fraction would be harmless.   If ARIN have spare /10s
lying around that they don't need to allocate, I'm sure APNIC, or RIPE,
or LANIC (or anyone else) would be happy to take them.

kre

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 30 Nov 2011 10:27:49 +0000

On 30/11/2011 05:46, Mark Andrews wrote:
> In message<[email-masked]>, Randy Bush writes:
Aren't there a whole lot of other user gadgets that also need to
work their way round this? Dyndns perhaps?  How about
some of the home VPN packages? Will remote desktop
continue to work? The list looks large in the draft, but
just how large is it in reality?

Stewart

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 30 Nov 2011 08:58:40 -0500

On Wed, Nov 30, 2011 at 5:27 AM, Stewart Bryant <[email-masked]> wrote:

>> In message<m2r50q42nn.wl%randy@**psg.com <[email-masked]>>,
>> Randy Bush writes:
>>

And these applications will continue to need to work around this since
non-RFC is already used (for years), and will continue to be used in CGN
zones.  The real issue is should this be controlled and predictable or not.
 This draft in no way changes that reality but seeks to improve.

Victor K

>
>
> Stewart
>
>
>
>
>
>
> ______________________________**_________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ietf<https://www.ietf.org/mailman/listinfo/ietf>
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 30 Nov 2011 09:21:55 -0500

Folks,

Can anyone present empirical evidence that skype will break? I have heard claims in both directions.

                                                         Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Andrews
> Sent: Tuesday, November 29, 2011 11:50 PM
> To: Randy Bush
> Cc: IETF Disgust

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Nov 2011 09:27:47 -0500

>>>>> "Randy" == Randy Bush <[email-masked]> writes:
    >> skype etc. will learn.  This does prevent the breakage it just
    >> makes it more controlled.  What's the bet Skype has a patched
    >> released within a week of this being made available?

    Randy> cool.  then, by that logic, let's use 240/4.  the apps will
    Randy> patch within a week.  ok, maybe two.

Seriously, I think we *SHOULD* use 240/10.
(let's keep some for the next horrible hack)

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 30 Nov 2011 09:46:12 -0500

> Randy Bush
> but this proposal is not about migrating to ipv6.  it is about ipv4
> life extension and nat4444444 4ever.  to hell with that.
>
[WEG] let's see... free.fr = 6rd. Cameron Byrne (TMO) = NAT64 (which requires IPv6-capable end devices) + squatting on routable space (*not* 1918) + CGN.
Please explain how either of those help to ensure that I can stay in business, given that my business requires me to provide functional IPv4 service to devices that my *customers* own which do not support IPv6, *IN ADDITION TO* deploying IPv6 [citations: 1, 2, 3, 4] for devices that do.
Should I stop selling IPv4 service citing the IETF's principles on the matter? Tell all of my customers that they must spend hundreds or thousands of dollars to upgrade all of their otherwise functional IP-capable devices because the old ones are obsolete (not to mention that the current new ones *still* might not support IPv6)?
I admit that DSLite would potentially help, but that requires support in CPE that is currently extremely limited, and my business model does not allow for me to purchase a new router for all X Million of my customers anyway.
*taps the mic, clears throat*
<RandyBush> "I strongly encourage all of my competitors to do the above." </RandyBush>

<snip>
> this has become a contest of wills, not a technical discussion.
[WEG] only because a number of folks, including you, insist on arguing about "the principle of the thing" and "making the internet work better" and "IPv4 life support" while rejecting technical arguments that you don't believe/like despite hearing them from multiple operators and other sources.
This is turning into a referendum on CGN and whether the industry as a whole has deployed IPv6 fast enough for a set of armchair quarterbacks' taste, and now people seem content to wag fingers and revel in saying "I told you so..." because business reality didn't line up with their view of how the universe should work. This is akin to standing on the deck of the Titanic and yelling "I told you we needed more lifeboats!" instead of finding a piece of wood to float on.

CGN = RFC6264. I'm not sure why it passed IETF LC or IESG vote given the resistance this draft is getting, but if you don't like it because it breaks the internet and extends IPv4, then write the draft to make that historic, along with NAT44, and any other astoundingly bad ideas that IETF has had for extending IPv4 beyond its original design life. For that matter, write a draft to make IPv4 historic. I (along with several authors of this draft) am already trying to update IETF's official position (for some value of official) from "version agnostic" to "IPv6 is a requirement", and I'd welcome the help.

But stop conflating a practical solution to a practical problem with whether IPv6 is deployed or whether CGN (and IPv4) is fundamentally bad.

I've been conflicted on this draft all along. I hate the idea for all the same reasons everyone else does, and I'm just as unhappy that IPv6 isn't further along. But I see few good alternatives, and I'm not sure it's worth cutting off my nose to spite my face, so I chose to stop opposing it. You may be correct, that RFC1918 would work in the majority of cases, and that people are likely to use this new space for off-label uses the first time they run into an RFC1918 conflict. So what? Is squatting on allocated space really the better idea? What about people who legitimately *can't* use RFC1918 space? Are they just SOL, or are you convinced that they're lying? As far as I can tell, your argument regarding this being used as RFC1918 annex is - "people are idiots and they'll do things we tell them not to, despite RFCxxxx that says 'Very Bad Things will happen if you do x', so we shouldn't even give them the option." The problem with idiot-proofing is that there are always better idiots.

Wes George

CF
1 http://www.timewarnercable.com/SoCal/support/IPv6.html
2 http://www.comcast6.net/
3 http://ww2.cox.com/residential/idaho/support/internet/article.cox?articleId=%7B0bced860-9666-11df-6baf-000000000000%7D
4 http://www.att.com/esupport/article.jsp?sid=KB409112&cv=812&_requestid=723971#fbid=V_Bys5OCNCJ

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: Warren Kumari <[email-masked]>
Date: Wed, 30 Nov 2011 10:20:02 -0500

>> Which reality? I think Randy is much more realistic!

+lots.

> That is my view as well.  I think this is a bad idea for the reasons stated. 

<sob>
I was *really* trying to stay out of this (both because I made my position clear at the beginning of this effort, and because it has turned into a political pissing match).
While Ron had made it clear that this was not intended to be another last call, it seems to have morphed into one, so... 

I too believe that this is a bad idea for the reasons already stated (and restated, and then restated again and then discussed and restated and then churned around and restated...).

W

---

From: Chris Donley <[email-masked]>
Date: Wed, 30 Nov 2011 10:18:56 -0700

Draft-donley-nat444-impacts-03:
+--------------+--------+--------+--------+--------------+----------+
   | Skype video  | Pass   | Pass   | Pass   | Pass         |          |
   | chat 
   +--------------+--------+--------+--------+--------------+----------+

We tested it.  Skype worked in our lab through CGN.

Chris

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 30 Nov 2011 13:10:41 -0500

> Draft-donley-nat444-impacts-03:

It also works in a real production deployment in a real network.  As I
noted earlier.  So oppose to claims that it does not work, I can let you
know that it in fact works.

regards,

Victor K

---

From: Bob Hinden <[email-masked]>
Date: Wed, 30 Nov 2011 11:39:51 -0800

> (let's keep some for the next horrible hack)

I agree, this is a good use of the "Experimental" Class E IPv4 addresses.  It seems to me that this is for new deployments (the CDN gear and new customer CPE equipment).  The operators who want this should be able to make this work and and incur the cost for doing so.

Bob

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Nov 2011 20:47:43 +0100 (MET)

Bob Hinden wrote:
> 
> 
>Michael Richardson wrote:
>> 
>>Randy Bush <[email-masked]> writes:
>>> 
>>> cool.  then, by that logic, let's use 240/4.  the apps will
>>> patch within a week.  ok, maybe two.
>> 
> I agree, this is a good use of the "Experimental" Class E IPv4 addresses.
> It seems to me that this is for new deployments (the CDN gear and new
> customer CPE equipment).  The operators who want this should be able
> to make this work and and incur the cost for doing so.

How about 240/8 (more room than /10, easier to recognized
for humans, but still addresses left for future hacks).

-Martin

---

From: John Leslie <[email-masked]>
Date: Wed, 30 Nov 2011 14:48:57 -0500

Bob Hinden <[email-masked]> wrote:
> customer CPE equipment). The operators who want this should be able to
> make this work and and incur the cost for doing so.

   While I am neither for nor against allocation of a /10 from ordinary
routable space, I would strongly favor allocation of a /10 from 240/4.
It's not obvious to me from reading draft-weil why this wouldn't work;
and I believe that allocations from 240/4 are quite appropriate, given
the imminent exaustion of ordinary IPv4 space.

--
John Leslie <[email-masked]>

---

From: Wes Beebee <[email-masked]>
Date: Wed, 30 Nov 2011 15:18:24 -0500

> extension and nat4444444 4ever.  to hell with that.

<ipv6 deployment enthusiast>
If NAT4444444 gets deployed, then IPv4 will become progressively less
reliable over time.  As more people work on IPv6, IPv6 will become more
reliable over time.  Eventually, IPv6 will become more reliable than IPv4.
At that point, I can tell my family that they should move to IPv6 - not
because they've run out of addresses - but because they're fed up with an
unreliable Internet connection.

>From a service provider perspective, adding NAT444444 to the network comes
at the cost of lighting up the call center.  Eventually, the cost of the
call center will become more expensive than deployment of IPv6...
</ipv6 deployment enthusiast>

<cgn developer>
This allows me to work with really complicated code that I can become an
expert on that will have a constant stream of new work and will provide
revenue for my company for years to come.
</cgn developer>

See - all you need is a change in perspective...

- Wes

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 30 Nov 2011 21:57:18 +0100

Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Wed, Nov 30, 2011 at 03:18:24PM -0500 Quoting Wes Beebee ([email-masked]):

> Eventually, IPv6 will become more reliable than IPv4.

for me, v6 is more reliable at my two most frequented tethering points
for the laptop. today. mostly because v6 is clean slate and 100% e2e. this
is over tunneling to home. does not matter. the tunnel has lower latency
than the v4 route to where I want to go. (wonders of peering wars)
 
> See - all you need is a change in perspective...

or perhaps timetable. "now -1 year" was a good time to roll out v6. those
who do not have v6 in their backbones today are lagging and will have
to pay for it. early adopter pain was 10 years ago (line cards with v4
only feature sets and similar b0rkenendness.)

access networks (especially dsl and cable) are a pathetic story in
themselves wrt v6, but the backbone has been a breeze to v6-enable
for years.

peoples RFQen should have started _requiring_ v6 transit and feature
parity for v6 and v4 at least two years ago. I did. it helps.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
SANTA CLAUS comes down a FIRE ESCAPE wearing bright blue LEG WARMERS
... He scrubs the POPE with a mild soap or detergent for 15 minutes,
starring JANE FONDA!!