Subject: Consensus Call (Update): draft-weil-shared-transition-space-request

From: Ronald Bonica <[email-masked]>
Date: Sat, 3 Dec 2011 17:06:42 -0500

Folks,

On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because:

- it is difficult. (We are choosing between the lesser of two evils.)
- a lively discussion on this mailing list has not yet converged

Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus:

- Is the reserved /10 required for the deployment of CGN?

- What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4?

- Can alternative /10s be used?

By contrast, further discussion of the following topics would not help the IESG gauge consensus:

- Does the assignment of the requested /10 enable or hinder the deployment of IPv6?

- Is CGN a viable service model for IPv4?

- Can the deployment of CGN be prevented by not assigning Shared CGN address space?

- How many ISPs really want this assignment and how many don't care because they don't need it?

Further discussion of these questions is not helpful to us because we are deliberating over an address allocation, not the deployment of CGN/NAT444. Operators have already announced their intention to deploy. At least for the purposes of the current deliberation, we must assume that CGN/NAT444 will be deployed and concentrate on whether to allocate a /10 to facilitate its deployment.
                                                            Ron
                                                            Speaking as AD, 
                                                              But not on behalf of the IESG

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 04 Dec 2011 00:07:39 -0500

Ron,

>Folks,
>
>On Thursday, December 1, the IESG deferred its decision regarding
>draft-weil-shared-transition-space-request to the December 15 telechat.
>The decision was deferred because:
>
>Several topic have become intertwined in the mailing list discussion,
>making it difficult to gauge community consensus. Further discussion of
>the following topics would help the IESG to gauge consensus:
>

I would say for the sanity of the sum of all CGN deployments a common
space would be most sound.  It would allow operators to build common rules
on managing this CGN zone space.  These rules include how information is
propagated to and from the local ISP (I.e. BGP, DNS Information etc) and
how internal security policies are built.  This is important since many
ISPs will likely be using part (or all) of the RFC1918 space for other
functions which include management zones, back-office systems and the like.

Such an allocation would also help avoid any conflicts with RFC1918 space
used by customer networks.  Although there may be portions of the RFC1918
space that *may * be open in each network, the space is not likely going
to be the same (different parts of the range if any) which makes it hard
to build common rules and for vendors to accommodate this if required.

Should operators need to use squat (should the space not be allocated),
this would potentially resolve the address conflict issues, but would
promote bad form as many may choose space which can potentially be used on
the Internet in the future (making life bad for customers).  It would also
make building common rules/filers between ISPs difficult to impossible.

>- What is the effect of burning 4 million IPv4 addresses on the

This is a question better answered by the RIR themselves.  I hear much
speculation from those on the list, but I don't think anyone here can
authoritatively answer this question.

Also, the effect of the allocation should be commented on from a technical
position and not presumed  market impacts (if any) since this again is
speculation.  Economics of the IPv4 address markets should be left out of
the technical discussion (in my opinion).

If the IPv4 address pool is so important and we are so concerned about the
price, then one should talk to the 38 (by my count) of private companies
and defence organizations which have /8s and ask them for their space back
(I will assume this is not feasible)

>- Can alternative /10s be used?

As noted, some have suggested parts of the RFC1918 space, but operators
have noted the challenges with this.  240/4 would require upgrades to some
of the vary devices (CPEs) which are of concern to us.

A part of the legacy assigned space would work.  Not sure how feasible
that is.  I guess if not allocated (the /10), squatting will have the same
effect (with all the chaos along with it).

Regards,

Victor K

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 4 Dec 2011 09:06:40 +0100

> - Is the reserved /10 required for the deployment of CGN?

No. RFC1918 will do, if done wisely. There indeed is additional
(oprational) cost, but nothing that can't normally be attributed to the
use of non-unique address space. Also, noone has touched on the
not-too-unusual use case of "one DSL, one PC" where the cutomer does not
attach a "home router/NAT box" but instead follows the instruction manual
that says "Connect PC to DSL modem Ethernet jack.". In that scenario,
the CGN is a marginal difference technically speaking. The assignment
of a previously-unicast v4 prefix in this case would cause confusion
since all How-To's currently present will point out that "anything non-
RFC1918 is unique or Multicast". Further, if the ISP decides to use 1918
space for CGN deployment there is nothing preventing assigning several
addresses (like a /28 or similar) to each customer, removing the need
for customer-operated NAT boxes.
 
> - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4?

Depends on where you are -- for me and my employers (past and present),
none. We enjoy the benefits of abundant Early Registrations. If, OTOH,
a new ISP can get a bunch of v4 /24's to properly dualstack important
services and interfaces exposed globally, and thus be able to get off
the ground using 1918 as v4 dualstack component for the rest, that is
a major improvement.
 
> - Can alternative /10s be used?

While the re-assignment of experimental space up above multicast
allocations remains an interesting (or at least amusing) exercise in
pain-shifting, the purpose here is to allow more or less orphaned
customer equipment to continue working. Forcing previously-
experimental address space on them is counter-productive.
And, as addressed above, unicast v4 space should be used for things
essential.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... I don't like FRANK SINATRA or his CHILDREN.

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Dec 2011 08:20:16 -0800

Ron,

> - Is the reserved /10 required for the deployment of CGN?

Obviously not.

It isn't a question of whether CGN can be deployed, it is a question of how.  As far as I can tell, lack of the a new /10 will simply mean ISPs get to make an operational decision, the result of which will either be more rapid exhaustion of the remaining IPv4 free pools or the use of already allocated space with the potential collisions it entails.

> - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4?

It may reduce the likelihood that folks deploying CGN will request (and be granted) new large blocks, thereby extending the life of the remaining free pools by some (likely small, relatively speaking) amount. However, see below.

> - Can alternative /10s be used?

Not sure what "alternative" means here.  If the idea is to use space from 240/4, I suspect not since I believe part of the problem statement is the need to deal with old, non-field upgradable CPE, the exact boxes that are likely to have issues with trying to configure 240/4 on the WAN interface. 

> ...

Without knowing how many ISPs would make use of draft-weil space, it is difficult to estimate the impact on the remaining IPv4 free pools should draft-weil space not be allocated.

Regards,
-drc

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Dec 2011 18:33:39 +0000

> It isn't a question of whether CGN can be deployed, it is a question of how.  As far as I can tell, lack of the a new /10 will simply mean ISPs get to make an operational decision, the result of wh…

It may mean "more rapid exhaustion of the free pool" for a short time, but at some not-too-far-away time it will stop meaning that since the free pool will be exhausted.  So that's not a long-term result of not allocating a /10, and thus the phrase "either ... or" used in your email does not apply.

ISTM, ISPs would really be left with 4 choices:
1) Use whatever address space they have already now as this new CGN space, such that they stop advertising the space in BGP etc., and migrate all of their existing customers to a model where this previously-public address space is now private and behind CGNs.  That's not a result I think we should want to happen, both because it disrupts the current working IPv4 and because it limits potential new ISPs. (it gives an advantage to legacy ISPs with lots of existing v4 addresses)

2) "Squat" on someone else's space or un-allocated space.  I don't think that's a result we should want to happen, for obvious reasons. (I also don't think it's likely many ISPs would do this either - just noting it's possible)

3) Use RFC-1918 address space.  That would work for pure "consumer" applications, but would break things like remote employees using VPNs.  I don't think that's a result we should want to happen, because it affects "good-citizen" Enterprises who aren't even using that ISP while their employees are using the ISP.

4) The CGN vendors and ISPs create a "CGN Forum" industry association, pool money together and buy the space to use from others.  I'm not sure if that's a good or bad result, but at the going rate it would ~$50 Million as someone else has mentioned. (Cerner bought Borders' for $12 per IP, and Microsoft bought some of Nortel's for about the same price per IP)  I don't know if the interested parties could really get $50 Million together, nor whom they could buy it from.  Perhaps they could convince one of the CGN vendors or ISPs who already have large space to part with it for a price.

4b) If one were to think evil-ly, one thing a big CGN vendor could do is use some of their own address space for *their* CGNs, and thereby have a sales advantage over other CGN vendors who weren't given big blocks in years past.  I don't think that's a result we should want, either.

-hadriel
p.s. <rant> and we should really stop talking about this as a "us" vs. "them" problem, or that ISPs are the problem - they're not the cause of the problem, and are coming here for help, and "they" pay for their employee's expenses to be active IETF participants, as well as having been previous financial sponsors of IETF meetings.  In short: "they" are "us".  *We* have a problem to solve - we can debate if it's solvable, or how to solve it, but not by blaming others. </rant>

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Dec 2011 11:48:38 -0800

Hadriel,

> It may mean "more rapid exhaustion of the free pool" for a short time, but at some not-too-far-away time it will stop meaning that since the free pool will be exhausted.  So that's not a long-term…

The either/or (and it isn't necessarily xor) applies to the decision ISPs will make should draft-weil not move forward.

> 1) Use whatever address space they have already now as this new CGN space,

Right, this is one possible version of the 'redeploy' option I mentioned in an earlier message (the one with the $50M estimate).  I would imagine the cost of doing this would be sufficiently high as to make it a non-starter, but it is indeed an option.

> That's not a result I think we should want to happen, both because it disrupts the current working IPv4 and because it limits potential new ISPs. (it gives an advantage to legacy ISPs with lots of existing v4 addresses)

I suspect IPv4 exhaustion will be a bit more limiting to potential new ISPs than existing ISPs renumbering their existing space so they can make use of CGNs.

> 2) "Squat" on someone else's space or un-allocated space.  I don't think that's a result we should want to happen, for obvious reasons. (I also don't think it's likely many ISPs would do this eithe…

Say you are the CIO of a large ISP.  If you get to decide between spending $50M or having your customers be potentially unable to communicate with (say) a relatively tiny number of ham operators (44/8) or US SIPRnet (which I suspect is against the law for your customers to communicate with) or <pick your favorite block>, what would be your choice?

> 3) Use RFC-1918 address space.  That would work for pure "consumer" applications, but would break things like remote employees using VPNs.  

I thought the primary issue was the need to number the WAN interfaces of non-field-upgradable CPE that don't allow 1918 on that interface and/or in a way that doesn't collide with 1918 space used on the inside interface.  Since we've seen multiple iterations of what is now draft-weil over the years, I have to assume using 1918 space isn't really an option.

> 4) The CGN vendors and ISPs create a "CGN Forum" industry association, pool money together and buy the space to use from others.  

Right, this is a variation of the "use somebody else's space" option.  They wouldn't need to buy the address space (at least if they do it soon): all the RIRs except APNIC can allocate a /10 now if it is justified. Since as far as I know numbering interfaces is seen as sufficient justification, one ISP could obtain the space and simply say 'hey, this space will never be announced'.  Other ISPs could then use it or not as they see fit.

> 4b) If one were to think evil-ly, one thing a big CGN vendor could do is use some of their own address space for *their* CGNs, and thereby have a sales advantage over other CGN vendors who weren't…

Not sure why this would be considered 'evil'. It indeed might make business sense for a CGN vendor to do this and it is (arguably) a less inefficient approach than each CGN-deploying ISP going out and getting their own block for this purpose.  My assumption is that this issue only applies to really large ISPs and that the CGN vendors for those ISPs already have sufficient existing legacy address space to do this.

> p.s. <rant> and we should really stop talking about this as a "us" vs. "them" problem,

Agreed.  It is, after all, one address space. Well, sort of.

Regards,
-drc

---

From: Chris Donley <[email-masked]>
Date: Sun, 4 Dec 2011 15:20:24 -0700

Ron,

Please see in-line.

Chris

>- Is the reserved /10 required for the deployment of CGN?

No, but it simplifies operations, lowers risk, and reduces aggregate
demand. If you take ARIN's current burn rate of about a /10 per month, and
assume that Geoff Huston is correct that v4-v6 parity occurs in 2016, the
excess demand is around 144 M addresses (since ARIN is the RIR prepared to
supply this space, I'm focusing only on the ARIN region). As has
previously been discussed (and will be addressed below), neither RFC1918
nor 240/4 are operationally feasible, so if Shared CGN Space is not made
available, ISPs are likely to draw CPE-CGN addresses from either
A) Public space. This can either come from a new RIR allocation or from
existing customers.  In the ARIN region, this is problematic, since
address space allocations are based on 3-month need, but the CGN
high-water mark is expected to come in 3 years. So, if an ISP were to roll
out CGN and wanted an ARIN allocation to cover it, the ISP would have to
put a larger proportion of customers behind a CGN earlier than would
otherwise be justified.  Similarly, if an ISP were to take addresses from
existing customers, it would again need to put a higher proportion of
customers behind the CGN than would be required for Shared CGN Space.
B) "squat" space. 

>- What is the effect of burning 4 million IPv4 addresses on the
A) 4 M IPv4 addresses represents about one month's allocation by ARIN (at
current rates).
B) It would probably lessen the run on the bank at the very end by giving
ARIN justification for refusing allocations for CGN space
(currently allowed by ARIN policy), possibly buying a few extra months.

>- Can alternative /10s be used?
Not if you mean either RFC1918 or Class E. Both draft-bdgks and RFC 6319
describe the problems with 240/4 - too many legacy devices won't support
it. (Including some Cisco and Mac OS X devices, among others). In the
cable provisioning model, subscribers can be behind either a
customer-provided router or directly attached to the CM, so we need to
support both use cases (we intend the term "CPE" in draft-weil to cover
both). In addition, back-office systems would need to be able to use the
same 240/4 space for network monitoring/maintenance, billing, lawful
intercept, etc.

Regarding RFC 1918, as we described in draft-weil, RFC 1918 space would
only be operationally viable if:
The Service Provider knows that the CPE/NAT works correctly when
      the same [RFC1918] address block is used both on its inside and
      outside interfaces, and, the Service Provider knows that the
[RFC1918] address block that
      it uses to number interfaces between the CGN and CPE is not used
      on the subscriber side of the CPE.

Since the ISP in many cases does not control the CPE device selected by
the customer, nor the address range assigned by the customer to internal
systems, this is fraught with risk.  Given that a single support call
costs more than the revenue generated by a subscriber in a month, I think
ISPs would need to see > 99.9% assurance that such an address range would
not cause conflict with customer devices/address ranges before they could
begin to consider 1918 space.

(note: since Shared CGN Space would come from unassigned addresses, the
likelihood of a conflict is significantly smaller, and avoidance of the
new Shared CGN Space could be added to Terms of Service in a way that
RFC1918 space cannot).

As I mentioned above, the viable alternatives to Shared CGN Space are
public allocations or squat space; IMO, both are more operationally
problematic than Shared CGN Space, and both share the same problems wrt
6to4.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Dec 2011 22:40:28 +0000

> Say you are the CIO of a large ISP.  If you get to decide between spending $50M or having your customers be potentially unable to communicate with (say) a relatively tiny number of ham operators (4…

I was trying to be kind, but you're right that makes a lot of sense.  I hadn't considered the 44/8 ham operator block, but that one is kind of a hog waiting to be slaughtered... it's not kosher but they probably wouldn't squeal too much.  
;)

-hadriel

---

From: Pete Resnick <[email-masked]>
Date: Mon, 5 Dec 2011 09:36:08 -0600

> 3) Use RFC-1918 address space.  That would work for pure "consumer" applications, but would break things like remote employees using VPNs.  I don't think that's a result we should want to happen, b…

Maybe I'm not understanding the problem you're worried about here, but 
as far as I can tell, remote employees using VPNs are still a problem 
with a new allocation: If an enterprise has two remote sites, each 
served by a different CGN, those two sites will get address conflicts in 
the new space. A new allocation doesn't solve that problem.

pr

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Dec 2011 10:46:00 -0500

--On Monday, December 05, 2011 09:36 -0600 Pete Resnick
<[email-masked]> wrote:

>> 3) Use RFC-1918 address space.  That would work for pure
>> "consumer" applications, but would break things like remote
>> employees using VPNs.  I don't think that's a result we
>> should want to happen, because it affects "good-citizen"
>> Enterprises who aren't even using that ISP while their
>> employees are using the ISP.
>>    
> 
> Maybe I'm not understanding the problem you're worried about
> here, but as far as I can tell, remote employees using VPNs
> are still a problem with a new allocation: If an enterprise
> has two remote sites, each served by a different CGN, those
> two sites will get address conflicts in the new space. A new
> allocation doesn't solve that problem.

Agreed.  Also, as more and more organizations use kits and
third-party software of various sorts to permit people to work
from home via VPNs, the notion of a 'pure "consumer"'
installation becomes more of a myth in various part of the
world.  Consumer applications, yes.  But, from an addressing
standpoint, a LAN is either pure-consumer or it isn't.  There
are fewer of the former now than there were when 1918 was
adopted.  Worse, many of those that exist today are likely to be
converted in the next year or two.  An addressing policy that is
designed around the assumption that we can break addresses up
into "safe" pools that then breaks when "consumers" put in
applications that try to create VPNs is likely to be a far worse
support nightmare (and one of the expensive case-by-case
variety) than actually dealing with the issues, as a group, now.

    john

---

From: Chris Grundemann <[email-masked]>
Date: Mon, 5 Dec 2011 11:48:05 -0700

> - Is the reserved /10 required for the deployment of CGN?

No, but it is the best option and it's allocation and use will lower
the pain inflicted by CGN on the Internet at large.

> - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4?

The benefit of a shared space far outweighs one months worth of
addresses for one RIR. Plus, it is likely that the availability of a
shared CGN space will slow allocations enough to offset this one month
loss.

> - Can alternative /10s be used?

This has been stated many times already (and is contained in multiple
drafts), so I'll just leave a high-level summary of our other options
as a reminder:
 - RFC 1918 space WILL NOT be used by operators.
 - Globally unique space is a waste and has all the same problems as a
shared /10 with the added problem of lack of standardization.
 - Squat space has all the same issues as a shared CGN space plus the
lack of standardization plus add the complications of squatting.
 - 240 - All the same issues of a shared CGN space but add the
complications from an explicit/intentional lack of vendor support in
many of the devices in question.

> By contrast, further discussion of the following topics would not help the IESG gauge consensus:
<snip>

Agreed. The bottom line here is that if we remove ourselves from the
religious/political debate and focus on operational realities - the
choice is not a hard one. The allocation of a shared CGN space is the
best thing we can do for the Internet, it's users, it's operators,
it's vendors, and for IPv6 deployment as well (which is actually
redundant).

Cheers,
~Chris

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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 5 Dec 2011 22:18:05 +0100

> it's vendors, and for IPv6 deployment as well (which is actually

No it might not be a hard choice, but that dont make it a good solution,
just a choice of the lesser evil.

Btw: If this allocation are made from any of the free available pools, not
rfc1918 or 240/4, then lets us also give out a /8 from somewhere in 240/4
and lets see if it really is so d*mn hard to use this space. That might add
some value for the future....

--- Roger J ---

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 6 Dec 2011 21:06:20 -0600

Hi, Ron.

On Dec 3, 2011, at 4:06 PM, Ronald Bonica wrote:

> On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat.

I support the assignment of an IPv4 /10 for shared CGN space. Most of my thoughts on this topic have already been expressed in draft-bdgks-arin-shared-transition-space. And anything that wasn't captured in draft-bdgks has been discussed (and re-discussed ad nauseum) this past week on the IETF mailing list.

However, there is one essential point that I'd like to clarify:  We need a common standard for numbering CGN NAT444 deployments.

For NAT444 deployments of CGN, we are talking about a new scope - the intermediate "CGN zone" network - that is neither global or local. Within this scope, one cannot expect end-to-end (global) address fidelity (because traffic is NATted), nor can one expect forwarding to be confined to a single organization (because it touches CPE etc).

ISPs need to use addressing within this scope that does not cause (additional) problems for their existing customers (and their customers' equipment). And in the event of an addressing conflict, operators (on both sides) need a common reference to determine who is at "fault" - i.e. who is responsible for fixing the problem.

Of the various options, only unique GUA and/or a Shared CGN Space can be reasonably expected to meet these requirements.  For the sake of conservation and operational efficiency, I recommend that we allow the assignment of a Shared CGN Space for this purpose.

Cheers,
-Benson

PS - I also support turning 240/4 into unicast, as others have recommended. But this will not help in the immediate future timeframe, for the currently deployed equipment, which is driving the need for Shared CGN Space. It may be complementary, but does not reduce the need for a /10 assignment.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Dec 2011 08:46:53 -0500

On 2011-12-06 22:06, Benson Schliesser wrote:
> ISPs need to use addressing within this scope that does not cause (additional)
> problems for their existing customers (and their customers' equipment). And in
> the event of an addressing conflict, operators (on both sides) need a common
> reference to determine who is at "fault" - i.e. who is responsible for fixing
> the problem.

Are you suggesting that ISPs MUST use the proposed /10 for CGNs?

That's... interesting. Maybe it could empower customers when an ISP is using 
something else (e.g. squat space) for its CGN and it's causing issues...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Dec 2011 13:39:29 -0500

>>>>> "Benson" == Benson Schliesser <[email-masked]> writes:
    Benson> However, there is one essential point that I'd like to
    Benson> clarify: We need a common standard for numbering CGN NAT444
    Benson> deployments.

    Benson> For NAT444 deployments of CGN, we are talking about a new
    Benson> scope - the intermediate "CGN zone" network - that is
    Benson> neither global or local. Within this scope, one cannot
    Benson> expect end-to-end (global) address fidelity (because traffic
    Benson> is NATted), nor can one expect forwarding to be confined to
    Benson> a single organization (because it touches CPE etc).

Okay, while this address touches the CPE, it does not cross it.

    Benson> PS - I also support turning 240/4 into unicast, as others
    Benson> have recommended. But this will not help in the immediate
    Benson> future timeframe, for the currently deployed equipment,
    Benson> which is driving the need for Shared CGN Space. It may be
    Benson> complementary, but does not reduce the need for a /10
    Benson> assignment.

The CGN space seems like a very good place to use 240.0/10.

A single organization often controls and specifies all equipment which
will use the address space, and even in the cases where customers have
their own equipment, a lot of it will have no problem with 240.

-- 
]       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: David Conrad <[email-masked]>
Date: Wed, 7 Dec 2011 11:31:11 -0800

Michael,

> The CGN space seems like a very good place to use 240.0/10.

I believe the main driver behind this discussion is the need to deal with deployed non-field-upgradable CPE that has issues with having RFC 1918 space being assigned on the WAN interface.  I'd guess said hardware would also likely have issues with 240/4 space being instead.

> their own equipment, a lot of it will have no problem with 240.

I long ago gave up being surprised at the problems (particularly low end) devices connected to the Internet had anytime you did _anything_ out of the ordinary.  I am skeptical executive management of the ISPs interested in the draft-weil space would take your assurance that there would be no problems without data to back it up. More likely, they'll simply say "get another free block while we can" or "use 44.x.0.0/10" or something similar.

Regards,
-drc

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Dec 2011 14:52:15 -0500

>>>>> "David" == David Conrad <[email-masked]> writes:
    >> The CGN space seems like a very good place to use 240.0/10.

    David> I believe the main driver behind this discussion is the need
    David> to deal with deployed non-field-upgradable CPE that has
    David> issues with having RFC 1918 space being assigned on the WAN
    David> interface.  I'd guess said hardware would also likely have
    David> issues with 240/4 space being instead.

You'd guess, or you know.
I'd like to see 240.0/10 assigned for this purpose, regardless of
whether or not we assign another block.

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 7 Dec 2011 14:13:08 -0600

> Are you suggesting that ISPs MUST use the proposed /10 for CGNs?

In principle, I probably would not object to this suggestion. But I think that SHOULD is a better description of the requirement.  (And I could be missing it, but I can't find such language in e.g. RFC1918.)

> That's... interesting. Maybe it could empower customers when an ISP is using something else (e.g. squat space) for its CGN and it's causing issues...

Yes, I would hope so. As a BCP for numbering CGN NAT444 deployments, it would provide a useful reference point.

Cheers,
-Benson

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 7 Dec 2011 23:35:26 +0100

> I believe the main driver behind this discussion is the need to deal with deployed non-field-upgradable CPE that has issues with having RFC 1918 space being assigned on the WAN interface.  I'd gues…
 
I believe we can narrow the problem with RFC 1918 addresses down to "same
or overlapping prefix on the outside as inside", rather than assuming
that any use of 1918 space on the outside interface is detrimental.
Does anybody know of any evidence to the contrary? 

Vendor default allocations of RFC1918 to "broadband router" LAN interfaces
are limited to nets 10 and 192.168. Does anybody know of any evidence to the contrary? 

Therefore, point out a /15 from 172.16.0.0/12 and be done with it. The
few conflicts arising will fall in two classes:

a/ People who have knowingly changed their LAN prefix. 

b/ Organisations large enough to use _all_ of RFC 1918 inside. 

"a" means they can change again. Problem solved. 

"b" means that they are large enough to be able to buy public external
addresses, if they do not already posess swamp space. Problem solved.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Now I understand the meaning of "THE MOD SQUAD"!

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Dec 2011 12:30:05 +1100

In message <[email-masked]>, =?utf-8?B?TcOlbnM=?= Nils
son writes:
> Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-re=
> quest Date: Wed, Dec 07, 2011 at 11:31:11AM -0800 Quoting David Conrad (drc=
> @virtualized.org):
> > Michael,
> >=20
> >=20
> > I believe the main driver behind this discussion is the need to deal with=
>  deployed non-field-upgradable CPE that has issues with having RFC 1918 spa=
> ce being assigned on the WAN interface.  I'd guess said hardware would also=
>  likely have issues with 240/4 space being instead.
> =20
> Does anybody know of any evidence to the contrary?=20

This is not a ISP/CUSTOMER problem.  This is a ISP/CUSTOMER/WORK problem.

You have the ISP using 172.16/12
You have the customer using 192.168/16 or 10/8
You have WORK using 172.16/12

Enterpises have choosen to use 172.16/12 for EXACTLY the same reasons
you want ISP to use 172.16/12.  CPE equipment doesn't default to
that range.  Both the enterprise and the ISP don't want to clash
with the employee/customer.

ISP's also need a big enough range that they minimise the number
of times they have to re-use the address range as every re-use
introduces more potential for routing leaks, mis-diagnosis, etc.

In addition to all the RFC 1918 address are for *private* use.
Allocating RFC 1918 address is customers not private use, so are
you also planning to update RFC 1918 to permit this *new* use case.

> are limited to nets 10 and 192.168. Does anybody know of any evidence to th=
> e contrary?=20
> 
> a/ People who have knowingly changed their LAN prefix.=20
> 
> b/ Organisations large enough to use _all_ of RFC 1918 inside.=20
> 
> "a" means they can change again. Problem solved.=20
> 
> --=20
> M=C3=A5ns Nilsson     primary/secondary/besserwisser/machina
> --I/5syFLg1Ed7r+1G
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAk7f6i4ACgkQ02/pMZDM1cUZNgCgkdyeg55f8yTu/x3mxPCwFx86
> EMMAoJWcaq23P1g9SQfgeUZeDqw+M3sV
> =nEJ/
> -----END PGP SIGNATURE-----
> 
> --I/5syFLg1Ed7r+1G--
> 
> --===============0194820202636702821==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============0194820202636702821==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Chris Donley <[email-masked]>
Date: Wed, 7 Dec 2011 20:00:28 -0700

>Okay, while this address touches the CPE, it does not cross it.
In some cases, customers attach their Pcs directly to their Cable Modem
(w/o a router).  So, you can't exclude Pcs in this discussion.  They make
up a non-trivial percentage, and many don't support 240.x (My home Mac,
for instance, gives me an error about first quad out of range).
>their own equipment, a lot of it will have no problem with 240.

That's not true on many cable networks.  Subscribers bring their own
routers, and would be responsible for upgrading/replacing them. Too many
devices will not support 240, raising the risk of using this range to an
unacceptable level.

Also, as was pointed out in an earlier email in this thread, some backbone
routers neither accept nor forward 240/4 addresses.

If the IETF changed the status of 240/4 five years ago, this would
possibly be worth considering. Since it didn't, it's too late now.
Equipment in the field is not ready, and won't be ready fast enough for
this to be a practical proposal.
>   Kyoto Plus: watch the video
><http://www.youtube.com/watch?v=kzx1ycLXQSE>
>	               then sign the petition.

---

From: Chris Donley <[email-masked]>
Date: Wed, 7 Dec 2011 20:17:47 -0700

We're requesting a /10, not a /12 or /15 (devices attached to one CGN
might use the whole /15).  Such an allocation would be too small for a
regional CGN deployment at a larger ISP, and would likely result in
double-CGN.  Shared CGN Space really needs to be a /10.

Second, many ISPs do not control customer home network addressing
decisions.  It is not feasible to tell a customer to renumber, especially
when the customer is legitimately using RFC1918 space in accordance with
the RFC.  

Unfortunately, your proposal doesn't actually solve the problem we're
facing.

Chris

On 12/7/11 3:35 PM, "Måns Nilsson" <[email-masked]> wrote:

>Subject: Re: Consensus Call (Update):
>draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at
>11:31:11AM -0800 Quoting David Conrad ([email-masked]):
>> Michael,
>> 
>> I believe the main driver behind this discussion is the need to deal
>>with deployed non-field-upgradable CPE that has issues with having RFC
>>1918 space being assigned on the WAN interface.  I'd guess said hardware
>>would also likely have issues with 240/4 space being instead.
>

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 8 Dec 2011 08:35:27 +0100

> double-CGN.  Shared CGN Space really needs to be a /10.

The space is going to be reused several times anyway, and NAT (be it
carrier, enterprise or SOHO) breaks pretty badly when session space
is exhausted. It does not make sense to have much more than a, say,
/16 behind each. (CGN is just NAT in a NEBS certified enclosure with an
expensive support contract; the basic b0rkenedness remains.)
 
> when the customer is legitimately using RFC1918 space in accordance with

As has been restated several times, if you use RFC1918, be prepared to
renumber. Goes for everyone, including customers.

> Unfortunately, your proposal doesn't actually solve the problem we're

We are, by request, not discussing solutions (ie. larger address space)
but kludges. draft-weil-shared-transition-space-request is polishing
manure, not designing solutions.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Hmmm ... A hash-singer and a cross-eyed guy were SLEEPING on a deserted
island, when ...

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 8 Dec 2011 08:43:45 +0100

> with the employee/customer.

I have 1918 space at home, that is used at work. My VPN works. It is
common knowledge that split-tunneling is detrimental to network security
since so many functions rely (properly or not) on the containment to be
close to perfect.
 
> you also planning to update RFC 1918 to permit this *new* use case.

No. To me, ultimately, "private" equals an instance of routing policy,
ie. AS number. The customer is using 1918 space in spite of not having
an AS number (if they have one, they probably got fries with that and
have a /24 from swampspace, case closed) and thus must adapt to the
provider routing scheme. It MIGHT work with NAT. But not more than that. 
 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Was my SOY LOAF left out in th'RAIN?  It tastes REAL GOOD!!

---

From: Daryl Tanner <[email-masked]>
Date: Thu, 8 Dec 2011 10:44:37 +0000

Hi Ron

On 3 December 2011 22:06, Ronald Bonica <[email-masked]> wrote:

> draft-weil-shared-transition-space-request to the December 15 telechat. The
> decision was deferred because:
>
> making it difficult to gauge community consensus. Further discussion of the
> following topics would help the IESG to gauge consensus:
>

The shared /10 is required for the deployment of NAT444. This ensures a
standardised, consistent way to identify CGN internal addressing,
irrespective of service provider. This also provides the lowest risk of
address collision with existing networks.

CGN is a generic term, and in some cases 1918 space can be used - for
example, where the CPE is an end-device (single host) that is not providing
any additional LAN connectivity, eg mobile devices.

> - What is the effect of burning 4 million IPv4 addresses on the exhaustion

The impact of using a single /10 for CGN/NAT444 is far less than each ISP
assigning their own dedicated block. Large ISPs would consume a /10 each
for this purpose.

> - Can alternative /10s be used?

The alternatives (discussed) are:
1. RFC1918 space - I do not see that the inside addressing in NAT444 is
legitimate use for this space. It is defined as "Address allocation for
Private Internets", which ISP customer connectivity is not.

2. 240/4 - I agree that this block should be released for unicast use,
however for CGN/NAT444 it is not 'fit for purpose' for use with ALL
existing CPE and network hardware.

Perhaps a separate I-D is required to release the 240/4 address block for
future use, however this should not be confused with the immediate
requirement.

Regards
Daryl

---

From: Chris Donley <[email-masked]>
Date: Thu, 8 Dec 2011 09:56:29 -0700

I don't want to go too far down this road, as it touches sensitive network
architecture issues, but I think you're thinking of this in terms of a
box.  Please think, instead, of a regional network with failover
capabilities and widely distributed customers.    The aggregate need is
(at least) a /10 for a large number of providers.

Chris

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Dec 2011 15:04:00 -0500

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:
    Mark> This is not a ISP/CUSTOMER problem.  This is a
    Mark> ISP/CUSTOMER/WORK problem.

    Mark> You have the ISP using 172.16/12 You have the customer using
    Mark> 192.168/16 or 10/8 You have WORK using 172.16/12

    Mark> Enterpises have choosen to use 172.16/12 for EXACTLY the same
    Mark> reasons you want ISP to use 172.16/12.  CPE equipment doesn't
    Mark> default to that range.  Both the enterprise and the ISP don't
    Mark> want to clash with the employee/customer.

It's not in general a problem unless the tunnel to work is terminated on
the CPE device itself.    For the normal case, the *DEKSTOP/LAPTOP*
terminates the VPN, and so it sees CUSTOMER and WORK prefixes, while
CPE device sees CUSTOMER and ISP prefixes. WORK sees WORK and Public-IP
prefixes.

In the case where the VPN is terminated on the CPE device, I claim three
things: 
  a) customer/WORK is sophisticated and can communicate about problem.
  b) the CPE device already has a public IP on the outside, the ISP
     should not renumber it.
  c) the CPE device can be given a host route for it's default gateway,
     and it has no reason to talk to any other host in the ISPs CGN
     network anyway.

(Openswan installs a host route via the old default route for ESP
traffic, and a pair of 0.0.0.0/1 and 128.0.0.0/1 routes through the
tunnel if you are extruding.  This avoids removing the default route...)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Dec 2011 15:06:07 -0500

>>>>> "Chris" == Chris Donley <[email-masked]> writes:
    Chris> We're requesting a /10, not a /12 or /15 (devices attached to
    Chris> one CGN might use the whole /15).  Such an allocation would
    Chris> be too small for a regional CGN deployment at a larger ISP,
    Chris> and would likely result in double-CGN.  Shared CGN Space
    Chris> really needs to be a /10.

    Chris> Second, many ISPs do not control customer home network
    Chris> addressing decisions.  It is not feasible to tell a customer
    Chris> to renumber, especially when the customer is legitimately
    Chris> using RFC1918 space in accordance with the RFC.

So, this is being forced on existing customers, or is being used for new
customers only?