Subject: Re: "class E" (was: Consensus Call: draft-weil-shared-transition-space-request)

From: [email-masked] (Noel Chiappa)
Date: Mon, 5 Dec 2011 13:58:20 -0500 (EST)

> From: Bob Hinden <[email-masked]>

    > As far as I can tell, it would only require the CPE router, CGN's, and
    > routers between the CPE and CGN's to support it. ... I think it's
    > reasonable for the ISPs who want to deploy this CGN gear to the deal with
    > upgrading the CPE routers of their customers.

The problem is that for a lot of ISPs, the CPE equipment is owned by the
customers, and comes from a zillion different vendors, and upgrading all of
them is just not feasible.

    > The proposal to use some of the remaining public IPv4 space for this,
    > IMHO has everyone else incur the costs.

Scenario I: The IETF defines a /10 for this use, to be shared by all ISPs.
Scenario II: The IETF refuses to define a /10 for this use, each ISP goes
	out and asks for its own.

Scenario II is incurring less cost on 'everyone else'... how?

Which does lead me to something I've been wondering about, though.

Why don't the ISPs get together, outside the IETF (I so wanted to expand on
this thought, but I had better not), and have one of them - one which is in
an area with an RIR with the most available space - go their RIR and ask for
a /10 for their in-house CGN - and then publish the number and say 'hey,
everyone, here's a /10 that anyone can use for their CGN'? And then, _once
it's already allocated_, they could even publish an I-D/non-standard-track
RFC documenting it, and how to use it...

	Noel

---

From: Bob Hinden <[email-masked]>
Date: Mon, 5 Dec 2011 11:36:28 -0800

Noel,

> them is just not feasible.

Sure, for all forms of CPE currently deployed.  I assume that there aren't any CPE deployed behind CGN today.  That is, all CPE today work without CGN and any sort of special addresses, probably use public IPv4 space on the WAN/ISP side.  So a CGN deployment is a new deployment and the ISPs choosing to do this could make sure that their customers CPE can support class E addresses, upgrade the CPE firmware, or send them new CPE.  

Bob

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

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 05 Dec 2011 19:48:28 +0000

> RFC documenting it, and how to use it...

Given that we just saw a /16 sold for $12/ip, what makes you think that any
carrier would open up a /10 allocated to them for the good of humanity, at
a potential future asset loss of $50m?

This is why this sort of address space needs to be allocated by policy, not
by bequest.

Nick

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Dec 2011 11:54:14 -0800

Bob,

On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
> So a CGN deployment is a new deployment and the ISPs choosing to do this could make sure that their customers CPE can support class E addresses, upgrade the CPE firmware,

I think the ISPs are saying that there is a non-trivial base of deployed non-upgradable CPE out there now.

> or send them new CPE.  

This assumes either (a) the ISP is responsible for the CPE and/or (b) the ISP is willing to pay for this.  I'm guessing these assumptions aren't valid.  

Regards,
-drc

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Dec 2011 16:13:22 -0500

--On Monday, December 05, 2011 11:54 -0800 David Conrad
<[email-masked]> wrote:

>> So a CGN deployment is a new deployment and the ISPs choosing
>> to do this could make sure that their customers CPE can
>> support class E addresses, upgrade the CPE firmware,
> 
> I think the ISPs are saying that there is a non-trivial base
> of deployed non-upgradable CPE out there now.
> 
>> or send them new CPE.  
> 
> This assumes either (a) the ISP is responsible for the CPE
> and/or (b) the ISP is willing to pay for this.  I'm guessing
> these assumptions aren't valid.  

Right.  But, unless there is CPE gear out there that is so
locked into a particular 1918 (or other) address range that it
can't use anything else internally (I haven't heard of such
equipment, but maybe it is out there), this is a much stronger
argument for a "dear customer, either renumber or upgrade your
hardware" position than for an allocation that will force that
"renumber or upgrade" position as soon as, e.g., ISPs merge or
discover a need for an extra layer or CGN.

   john

---

From: Chris Donley <[email-masked]>
Date: Mon, 5 Dec 2011 14:26:28 -0700

>discover a need for an extra layer or CGN.
On DOCSIS networks, there are typically two deployment scenarios:
A) subscriber plugs PC directly into the CM
B) subscriber provides a router, which connects to the CM

In both cases, the subscriber is responsible for the equipment.  Many
subscribers don't know what an IP address is, and don't care.  I'm trying
to imagine my parents receiving such a letter "renumber your IP address
and/or buy a new PC or router".  Such a letter would probably cause anger
and confusion and an increased readiness to switch to the ISP across town
that's using squat space and doesn't require customers to call Geek Squad
or buy something else.

Chris

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Dec 2011 08:38:56 +1100

> discover a need for an extra layer or CGN.

It's not that the CPE's can't renumber.  The ISP are already using
RFC 1918, in good faith, internally to talk to the management
interfaces of modems so using RFC 1918 is forcing the ISP's to
renumber out of whichever RFC 1918 block that is choosen for this
purpose.  Customers that are using RFC 1918 addresses, in good
faith, are being force to renumber because the IETF is changing the
rules retrospectively.  Using a RFC 1918 block for this purpose
will also force companies to stop using this block internally as
it will break routing over VPNs to addresses in this block.

Ask everyone everywhere that is using this block, in good faith,
for some purpose other than supporting addresses behind a CGN to
renumber out of this block of RFC 1918 addresss which is now being
re-purposed 16 years after it was allocated.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Dec 2011 08:53:37 +1100

> that's using squat space and doesn't require customers to call Geek Squad

It's really only those that have a router connected that need to
check.  The ordinary PC that is not being used as a router is not a
issue with RFC 1918 addresses.

"If you have a router connected to the cable modem or are using a
PC in Internet Connection Sharing (ICS) mode please reconfigure it to not
use the address range "...." for the home network.  Most routers and
PC in ICS mode already do not use this address range."

That said a lot of customers won't know how to check and/or change
the address range.

Additionally this also affects everybody that is currently using
this block of RFC 1918 address as the IETF is taking it away from
them.  Not just the customers behind CGNs.

Mark

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Dec 2011 14:58:52 -0800

John,

On Dec 5, 2011, at 1:13 PM, John C Klensin wrote:
> this is a much stronger argument for a "dear customer, either renumber or upgrade your
> hardware" position

I'd imagine the vast majority of the customers of ISPs who are facing this issue would react either with anger or non-comprehension if presented with such a position. If you were running such a network, would you risk it?

> than for an allocation that will force that

I'm confused: why would an ISP merge/extra layer of CGN for the ISP to relay that position to their customers? My impression is that we're talking about ISP-side (only) . I'd think this would be handled by the ISP changing the IP address on the WAN side of the CPE via normal provisioning systems if/whern collisions occur with the merged/layered network.

Regards,
-drc

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 6 Dec 2011 06:57:56 +0100

> re-purposed 16 years after it was allocated.

I do not understand why it is so hard to come to terms with the fact
that IF you have -- in whatever faith -- chosen to use non-unique address
space, you have been taking your chanches that sometime, in the future,
you WILL have to renumber to keep the illusion of quasi-uniqueness. This
goes for everybody. Customer, operator, middlebox or CPE vendor,
and my mother. This is inherent in all non-unique space. A new shared
allocation from the RIR pools or Class E will not change this fundamental
characteristic.  Therefore, 1918 space, being the prime example of
non-uniqueness, should be quite suited to populate the inside of a CGN.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Am I SHOPLIFTING?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Dec 2011 00:19:49 +1100

In message <[email-masked]>, =?utf-8?B?TcOlbnM=?= Nils
son writes:
> Subject: Re: "class E" (was: Consensus Call: draft-weil-shared-transition-s=
> pace-request) Date: Tue, Dec 06, 2011 at 08:38:56AM +1100 Quoting Mark Andr=
> ews ([email-masked]):
> =20

Actually it isn't inherent.  It's only if two of the parties involed
are forced to use the same address pools that renumbering is inherent.

Mark

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Dec 2011 17:53:24 +0100

Mark,

On 12/5/11 10:38 PM, Mark Andrews wrote:
> It's not that the CPE's can't renumber. The ISP are already using RFC
> 1918, in good faith, internally to talk to the management interfaces
> of modems so using RFC 1918 is forcing the ISP's to renumber out of
> whichever RFC 1918 block that is choosen for this purpose. Customers
> that are using RFC 1918 addresses, in good faith, are being force to
> renumber because the IETF is changing the rules retrospectively.

This overstates the case, or at least shows confusion over what we meant
by the term "enterprise" in RFC-1918.  I don't know about the other
authors, but I meant an enterprise that was an end user, and
specifically *not* a service provider.   Nevertheless, SPs *are* using
the space today.  That is the world in which we live, no matter what
1918 says.  What, then, is the best approach to deal with the conflict
(if it exists– see Rob Elz's note)?

Eliot

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Dec 2011 07:47:01 +1100

> (if it exists– see Rob Elz's note)?

The best approach is to give the service providers a different pool.
Just because some service providers are mis-using RFC 1918 address
to number clients (there is no problem with them using RFC 1918 to
number the management interfaces), it doesn't mean we should be
forcing them to use RFC 1918 addresses to number clients.  Nor
should we be forcing them to hand shared addresses without the
clients having the ability to identify that the address is shared.

If the only tool you have is a hammer (RFC 1918 addresses) then
thay is what you use.  This is about giving the ISPs a different
tool better suited to the purpose.  Now if the enterprise (includes
home user) chooses to use this other tool then it is on their heads.
I would also hope that ISP's that are using RFC 1918 addresses to
number customer would stop the practice.

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 6 Dec 2011 19:39:47 -0600

> I'd imagine the vast majority of the customers of ISPs who are facing this issue would react either with anger or non-comprehension if presented with such a position. If you were running such a net…

Precisely. This proposition would result in both (1) increased support costs*, and (2) irritated customers that decide to switch ISPs rather than renumber or upgrade. We can't (realistically) expect ISPs to choose this.

The sad / funny thing is that result #2 rewards ISPs that use squat space or globally unique blocks...

Cheers,
-Benson

* - e.g. 30-60 min toll-free phone call with a technician, which might actually cost more than the profit margin on some residential broadband services

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 7 Dec 2011 07:08:39 +0100

> are forced to use the same address pools that renumbering is inherent.

Oh, sorry, I meant the _risk_ (taking your chanches) of conflict as being
inherent. Unique addresses are meant to be collision-free, whereas any
allocation that might be made as a consequence of this draft can only
result in potentially conflicting allocations.

Thus, RFC 1918 is as [bad|good] as any other allocation. I furthermore
think that any recommendation about address space for CGN insides should
try to point out likely candidates (172.28/15, perhaps) but not do more
than that. Then broadband router vendors could stay away from that prefix
for their defaults (which they do; I've never seen, and anecdotal data[0]
confirms it, anything but 192.168/16 and 10/8.) and things would "work"
until the infrastructure and services are upgraded.

Further, I think, with personal experience from several 1918-using
enterprises[1], that the situation with "large organisation with all 1918
space used internally gets put behind CGN" is a hoax. Those people nearly
always have a guarded stash of old class C swampspace that they use for
things like DNS servers, firewall outsides, MX records, etc. Ususally,
they can come up with a /27 from that to number a bunch of p2p links.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Xerox your lunch and file it under "sex offenders"!

[0] http://www.answersthatwork.com/Download_Area/ATW_Library/Networking/Network__4-List_of_default_Router_Admin_Passwords_and_IP_addresses.pdf

[1] here defined as largish organisation with dedicated IT staff and some cashflow.