Subject: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02

From: Chris Donley <[email-masked]>
Date: Tue, 26 Oct 2010 16:37:35 -0600

Hello,

To support Service Provider deployments of NAT444 and 6RD, we are proposing that IANA reserve a /8 for shared transition space.  We believe that this will be a more efficient way of using the remaining unallocated IPv4 space. By sharing space for transition technologies, we believe that this will free up additional public addresses beyond a /8 that would otherwise be allocated to Service Providers for transition technologies.

We believe that we have incorporated your feedback on previous versions of our draft, and are interested in your feedback on our -02 version: http://datatracker.ietf.org/doc/draft-weil-opsawg-provider-address-space/. In particular, do you support this draft becoming a WG item?

Thanks,
Chris

Chris Donley
CCIE, CISSP, SCiPM
Project Director - Network Protocols
CableLabs(r)
858 Coal Creek Circle
Louisville, CO 80027

---

From: "Davies, Greg J" <[email-masked]>
Date: Wed, 27 Oct 2010 16:02:42 +1100

Chris,
         We would certainly support that this draft become a WG item.  I believe there is growing recognition now that even with the introduction of IPv6 there will still most likely be a need for service providers to use IPv4 shared address solutions.  We will need to maintain IPv4 connectivity, in addition to IPv6, during the transition period which will take many years (for the entire IP ecosystem).

Allocating a single /8 for this purpose is not going to significantly affect the run-out date, in fact it may help delay it as you say, but the benefit is that it will help facilitate transition mechanisms which will be required by many service providers for many years.

Regards,
Greg Davies
Emerging Network Technology and Strategy
Chief Technology Office
Telstra Corporation Limited
Australia
Phone   +61 3 8649 2915
Mobile  +61 419 597 497
Email   [email-masked]
The information contained in this e-mail is confidential. It is only intended for the recipient/s named above. If you are not the intended or one of the intended recipient/s
any unauthorised use is prohibited. If you have received this e-mail in error, please notify the sender so that arrangements can be made for its retrieval or destruction.
Telstra Corporation Limited ACN 051 775 556
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Donley
Sent: Wednesday, 27 October 2010 9:38 AM
To: [email-masked]
Cc: Victor Kuarsingh ([email-masked])
Subject: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02

Hello,

Thanks,
Chris

Chris Donley
CCIE, CISSP, SCiPM

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2010 09:54:59 +1300

The arguments why this is a really bad idea have been made
often enough, so I won't repeat them here. I think that
the IETF should continue to not endorse the creation of yet
more ambiguous unroutable address space.

Instead, I'd like to see several other drafts moving on
as fast as possible, because we need to document as thoroughly
as possible why providers would come to deeply regret deploying
yet more ambiguous address space:

draft-donley-nat444-impacts
draft-kirkham-private-ip-sp-cores
draft-ietf-intarea-shared-addressing-issues

Regards
   Brian Carpenter

On 2010-10-27 11:37, Chris Donley wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Armstrong, Bill R" <[email-masked]>
Date: Wed, 27 Oct 2010 16:19:34 -0500

Support!

-Bill

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Donley
Sent: Tuesday, October 26, 2010 5:38 PM
To: [email-masked]
Cc: Victor Kuarsingh ([email-masked])
Subject: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02

Hello,

Thanks,
Chris

Chris Donley
CCIE, CISSP, SCiPM

E-MAIL CONFIDENTIALITY NOTICE: 

The contents of this e-mail message and 
any attachments are intended solely for the 
addressee(s) and may contain confidential 
and/or legally privileged information. If you 
are not the intended recipient of this message 
or if this message has been addressed to you 
in error, please immediately alert the sender
 by reply e-mail and then delete this message 
and any attachments. If you are not the 
intended recipient, you are notified that 
any use, dissemination, distribution, copying, 
or storage of this message or any attachment 
is strictly prohibited.

---

From: Matthew Ford <[email-masked]>
Date: Thu, 28 Oct 2010 10:11:49 +0100

> draft-ietf-intarea-shared-addressing-issues

This won't be a surprise to anyone, but I'll say it anyway:

+1

Mat

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 28 Oct 2010 11:21:59 -0400

I would vote in the other direction.

I agree the drafts Brian noted need to be progressed to show the issues and
concerns with technologies (NAT444 / NAT44/LSN and supporting addressing
like ISP Shared space), But....

Issues with the technologies do not change the fundamental need to support
them for a period of time as the industry moves forward.

Regards,

Victor

---

From: Chris Donley <[email-masked]>
Date: Thu, 28 Oct 2010 13:53:10 -0600

Brian,

I agree with you from a technical perspective that transitioning to IPv6 is the right long-term solution; NAT444 and other IPv4 multiplexing technologies cause problems, and are likely to provide a deteriorating user experience in the future. However, given that ISPs can't just switch to IPv6 - too many legacy devices in the home, CPE routers, network devices, and content providers either don't support IPv6 or don't fully support it, there needs to be a solution to extend IPv4 for at least a few years, and part of that solution will be NAT444, like it or not.  Another part of the solution to transition to IPv6 will be 6RD, allowing ISPs to deploy it before some infrastructure elements can be upgraded.  Agreed that both are sub-optimal, but both are needed.

Given that some ISPs will be deploying 6RD and/or NAT444, they will need an address block between the CPE router and the LSN/BR.  What is the appropriate addressing policy? As we see it, there are three options for providing that address space:
	1) Reserve a /8 from IANA (our proposal)
	2) Have ISPs individually request addresses from the RIRs.  By our count from just the ISPs we've spoken with, operators will need at least 60 million addresses (~3.75 /8s) to fill this need.  The total need is probably higher.  We believe that this is an inefficient use of public address space for addresses that don't need to be routed on the Internet. Allocating a single /8 for shared transition space will be more efficient.
	3) ISPs could 'squat' on a /8 allocated to another entity.  I think this is the worst of the three - problems with this approach have been documented in draft-azinger-additional-private-ipv4-space-issues, among other places. 

I agree with you that none of these options are great.  Of the three, we think (1) is the preferable policy, as it ties up a smaller allocation of otherwise public space. Do you have a different preference?  Is there a better option for providing a /8 or /9 to each large ISP that needs it for NAT444/6RD that we haven't considered?

Note: we don't think 240/4 space is viable, as too many home/enterprise routers don't support it, and it will not be operationally feasible to upgrade all the routers (particularly customer routers).

Chris

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, October 27, 2010 2:55 PM
To: Chris Donley
Cc: [email-masked]; Victor Kuarsingh ([email-masked])
Subject: Re: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02

Regards
   Brian Carpenter

---

From: Tom Taylor <[email-masked]>
Date: Thu, 28 Oct 2010 20:13:46 -0400

For 6rd, have a look at draft-tsou-softwire-gwinit-6rd-01.

---

From: huang cancan <[email-masked]>
Date: Fri, 29 Oct 2010 12:32:31 +0800

Hi,authors:

 I have read your draft and I think it is well written. The idea is
creative, but I don't think it is practical and reasonable to allocate a /8
address pool from now unallocated address pool. It seems to solve the
problem fundamentally, but this so called "fundamently" will cause more
troubles.

 To allocate a /8 address pool from unallocated address pool is target to
solve the IPv4 address depletion and reduplication problem when using NAT44
and 6RD. There are some problems I want to ask you listed below:

1. From the NAT44 respect:
   (1)Flexibility:
 The IPv4 address here, which facing the exhaustion and overlay problem, is
private IPv4 address. To allocated a reserved /8 IPv4 address aim at
complement insufficient of private IPv4 address. However, according to the
ISP, which is big enough to run out all the net-10 IPv4
address in a metropolitan network, due to the huge project, they may not
willing to adjust their network to adapt public IPv4 address deployment. In
addition, a /8 address space is also not enough if the subscriber growth
rate is very high. There are not obviously better than using private IPv4
address. Here, I can not clearly find the flexibility character when using
/8 address pool from unallocated IPv4 address pool.

   (2) Efficiency:
 I don't understand why the /8 IPv4 address from unallocated address space
can "reduce the demand for public IPv4 space by Service Providers, and
result in a net gain of available public IPv4 address space." The public /8
IPv4 address is just the succedaneum of private IPv4 address. From the NAT44
CGN aspect, these address still need translated to another public IPv4
address to be routed in the global network.So, the demand for public IPv4
space is not reduced and still remain the same.

   (3)RFC1918 Overlap:
 "Utilization of separate assignment can remove the challenge of [RFC1918]
address overlap between the customer  network and the provider network." I
do agree with you on this point. However,although it is a method to solve
the overlap problem, it isn't the best practise method. Because we can deal
the reduplicate problem through address planning specially for the ISP who
can control the users' CPE and update them online. For the ISP who can not
remotely control the CPEs, they can use commercial means to require
subscribers to configure private IPv4 address of certain range within their
families.

   (4)  Removes need for bogon space or IPv4 squatting:

 "Providers can avoid the use of bogon and/or squatted space within their
networks.  This type of address usage can cause connectivity problems for
customers and can be difficult to diagnose." It is right, but I don't think
it is the advantage of the method. Because using private IPv4 address can
also avoid the squatted space problem.

   (5) Clear IP allocation for IPv6 transition technologies:
 "A block reserved for transition usage can be well defined and provide best
practices for transition technology deployment." May I ask why? This
sentence seems like to tell me that private IPv4 address block can not well
define the transition usage, but actually it can.

  (6) Security:
" It is easier and more secure to build security polices for larger address
blocks, rather than multiple smaller blocks. Larger blocks minimize the
number of firewall rules or access list statements required to implement
such a policy, and thereby reduce the number of errors.  This results in
better customer Internet experiences.  In addition, service providers can
filter[RFC1918] space at the edge of their network, and creating separate
policies for shared transition space, which ought to only be deployed
between the customer premise router and the service provider NAT/ Border
Relay." This sentence seems like to tell me that private IPv4 address block
will meet such problem, but actually it wouldn't.It all depend on address
planning.
2. From the 6RD respect:
   The IPv4 address here, which facing the exhaustion and overlay problem,
may be public IPv4 address or private IPv4 address.For private IPv4
address,the comments of flexibility, efficiency, overlap and so on are the
same with the NAT44.
  (1)Flexibility:
  From the public IPv4 address aspect, using another /8 public IPv4 address
specially for transition will lead to less flexible. Because, the users use
6RD visiting the IPv6 Internet and at the same time , they can use public
IPv4 address to visit IPv4 Internet. If we allocate a /8 public IPv4 address
reserved for transition,the ISP should add another similar NAT44 gateway to
translate these IPv4 address to other public IPv4 address which can be
routed in the Internet. It is not flexible .
   (2), (4) ,(5) and (6) are the same with the upper comments on NAT44

   (3) overlap:
       There is no overlap problem in the 6RD scenario. Because, for the
family network,the CPE allocate private IPv4 address to the PCs, and the CPE
is allocated the public IPv4 address, there is no possibility to overlap.
   Besides the different opinion with your upward advantages listed in the
draft, I think the allocation of /8 IPv4 address may bring complexity and
difficulties to the network management and operation. The network routing
deployment always needs very careful.To revise the routing strategy may lead
to routing disorder.
   In conclusion, I don't think it is quite necessary and reasonable to
allocate a /8 IPv4 address block from the unassigned IPv4 address pool.
    Thank you very much!

Cancan Huang

---

From: Arturo Servin <[email-masked]>
Date: Thu, 28 Oct 2010 21:43:35 -0500

> more ambiguous unroutable address space.

	Agree. I think the proposal has more cons than pros and those have been said repeatedly. The new draft does not seem to address those concerns.

Regards,
-as

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 28 Oct 2010 15:57:31 -0400

+1

On 28/10/10 3:53 PM, "Chris Donley" <[email-masked]> wrote:

> Brian,
> 
> I agree with you from a technical perspective that transitioning to IPv6 is
> the right long-term solution; NAT444 and other IPv4 multiplexing technologies
> cause problems, and are likely to provide a deteriorating user experience in
> the future. However, given that ISPs can't just switch to IPv6 - too many
> legacy devices in the home, CPE routers, network devices, and content
> providers either don't support IPv6 or don't fully support it, there needs to
> be a solution to extend IPv4 for at least a few years, and part of that
> solution will be NAT444, like it or not.  Another part of the solution to
> transition to IPv6 will be 6RD, allowing ISPs to deploy it before some
> infrastructure elements can be upgraded.  Agreed that both are sub-optimal,
> but both are needed.
> 
> Given that some ISPs will be deploying 6RD and/or NAT444, they will need an
> address block between the CPE router and the LSN/BR.  What is the appropriate
> addressing policy? As we see it, there are three options for providing that
> address space:
>         2) Have ISPs individually request addresses from the RIRs.  By our
> count from just the ISPs we've spoken with, operators will need at least 60
> million addresses (~3.75 /8s) to fill this need.  The total need is probably
> higher.  We believe that this is an inefficient use of public address space
> for addresses that don't need to be routed on the Internet. Allocating a
> single /8 for shared transition space will be more efficient.
>         3) ISPs could 'squat' on a /8 allocated to another entity.  I think
> this is the worst of the three - problems with this approach have been
> documented in draft-azinger-additional-private-ipv4-space-issues, among other
> places.
> 
> I agree with you that none of these options are great.  Of the three, we think
> (1) is the preferable policy, as it ties up a smaller allocation of otherwise
> public space. Do you have a different preference?  Is there a better option
> for providing a /8 or /9 to each large ISP that needs it for NAT444/6RD that
> we haven't considered?
> 
> Note: we don't think 240/4 space is viable, as too many home/enterprise
> routers don't support it, and it will not be operationally feasible to upgrade
> all the routers (particularly customer routers).
> 
> Chris
> 
> Subject: Re: [OPSAWG] Request for feedback:
> draft-weil-opsawg-provider-address-space-02
> 
>> > To support Service Provider deployments of NAT444 and 6RD, we are proposing
>> that IANA reserve a /8 for shared transition space.  We believe that this
>> will be a more efficient way of using the remaining unallocated IPv4 space.
>> By sharing space for transition technologies, we believe that this will free
>> up additional public addresses beyond a /8 that would otherwise be allocated
>> to Service Providers for transition technologies.
>> >
>> > We believe that we have incorporated your feedback on previous versions of
>> our draft, and are interested in your feedback on our -02 version:
>> http://datatracker.ietf.org/doc/draft-weil-opsawg-provider-address-space/. In
>> particular, do you support this draft becoming a WG item?
>> >
>> > Thanks,
>> > Chris
>> >
>> > Chris Donley
>> > CCIE, CISSP, SCiPM

 ---------------------------------------------------------------------------
   Victor Kuarsingh
   IP Architect, Network Technology
   Rogers Communications Inc
   Business: 647-747-1785
   Mobile: 647-338-1533
   [email-masked]
 ---------------------------------------------------------------------------
-

This e-mail (and attachment(s)) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived. If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this e-mail or any of its content is strictly prohibited and may be unlawful. All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business. E-mails are not secure and you are deemed to have accepted any risk if you communicate with us by e-mail. If received in error, please notify us immediately and delete the e-mail (and any attachments) from any computer or any storage medium without printing a copy.

Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et peut faire l’objet de droit d’auteur et de privilège juridique; aucun droit connexe n’est exclu. Si vous n’êtes pas le destinataire visé ou son représentant, toute étude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est strictement interdite et peut être illégale. Tous les messages peuvent être surveillés, selon les lois et règlements applicables et les politiques de protection de notre entreprise. Les courriels ne sont pas sécurisés et vous êtes réputés avoir accepté tous les risques qui y sont liés si vous choisissez de communiquer avec nous par ce moyen. Si vous avez reçu ce message par erreur, veuillez nous en aviser immédiatement et supprimer ce courriel (ainsi que toutes ses pièces jointes) de tout ordinateur ou support de données sans en imprimer une copie.

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 29 Oct 2010 08:09:11 -0400

Arturo,

I do not think the draft was targeted at explicitly fixing the concerns of
specific issues documented with using this type of address space.

Rather, it shows that this is a viable option and less impacting then other
options.  Unfortunately, something will happen.. Operators will be forced to
do something to expand IPv4 along side adding in IPv4.

I think the major concern is that it will either be more controlled and
deterministic, or operators will go out (whether we like them to or not) and
implement other options (drafts like
draft-azinger-additional-private-ipv4-space-issues explain some of those
other options).

We feel the case is that this is "better" then the alternatives such as
"camping out on other IPv4 space", or many providers making a run at the
IPv4 pool with individual requests for such space (which in the end will end
up being the same thing but using potentially more addresses as pointed
out).

Regards,

Victor Kuarsingh

On 28/10/10 10:43 PM, "Arturo Servin" <[email-masked]> wrote:

> Agree. I think the proposal has more cons than pros and those have been said
> repeatedly. The new draft does not seem to address those concerns.
> 
> Regards,
> -as
> 
>

---

From: Arturo Servin <[email-masked]>
Date: Fri, 29 Oct 2010 13:44:51 -0200

Victor,

> specific issues documented with using this type of address space.

	Considering the implications on the adoption of this draft as RFC I think that it should. But that is only IMHO.

> options.  

	I think it only shows the benefits but it does not make any comparisons. At least it is not clear for me how it has less impact than other options, may be I just missed it.

> Unfortunately, something will happen.. Operators will be forced to

	Hopefully it would be native IPv6.

> up being the same thing but using potentially more addresses as pointed

	Not sure If I agree with you, but the case is that this argument is not clear in the text. Again, probably it is there and I just missed.

> Victor Kuarsingh

Best wishes,
als

---

From: Chris Donley <[email-masked]>
Date: Fri, 29 Oct 2010 09:45:16 -0600

Cancan,

Thanks for your feedback.  Please see in-line.

Chris

From: huang cancan [mailto:[email-masked]]
Sent: Thursday, October 28, 2010 10:33 PM
To: Tom Taylor
Cc: Chris Donley; [email-masked]; Victor Kuarsingh ([email-masked])
Subject: Re: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02

Hi,authors:

 I have read your draft and I think it is well written. The idea is creative, but I don't think it is practical and reasonable to allocate a /8 address pool from now unallocated address pool. It seems to solve the problem fundamentally, but this so called "fundamently" will cause more troubles.

 To allocate a /8 address pool from unallocated address pool is target to solve the IPv4 address depletion and reduplication problem when using NAT44 and 6RD. There are some problems I want to ask you listed below:

1. From the NAT44 respect:
   (1)Flexibility:
 The IPv4 address here, which facing the exhaustion and overlay problem, is private IPv4 address. To allocated a reserved /8 IPv4 address aim at complement insufficient of private IPv4 address. However, according to the ISP, which is big enough to run out all the net-10 IPv4
address in a metropolitan network, due to the huge project, they may not willing to adjust their network to adapt public IPv4 address deployment. In addition, a /8 address space is also not enough if the subscriber growth rate is very high. There are not obviously better than using private IPv4 address. Here, I can not clearly find the flexibility character when using /8 address pool from unallocated IPv4 address pool.

[CD] We have spoken with a number of Service Providers who have either exhausted Net-10 space, or find it impractical to use because of overlap with their customers.  This reserved space offers those providers another tool to provide addresses between the CPE Router and operator LSN/BR.

   (2) Efficiency:
 I don't understand why the /8 IPv4 address from unallocated address space can "reduce the demand for public IPv4 space by Service Providers, and result in a net gain of available public IPv4 address space." The public /8 IPv4 address is just the succedaneum of private IPv4 address. From the NAT44 CGN aspect, these address still need translated to another public IPv4 address to be routed in the global network.So, the demand for public IPv4 space is not reduced and still remain the same.

[CD] The operators we spoke with need /8s, /9s, /10s, or /12s for transition space between the CPE Router and LSN/BR, totaling 60 million addresses (3.75 /8s).  This probably understates the total need, as we haven't spoken with all operators.  This address space does not need to be routed on the Internet - it's limited in scope to between the CPE Router and LSN/BR.  They can take address space currently allocated directly to customers and move it in front of the LSN to multiplex multiple customers. By allocating 1 /8 and sharing it among multiple operators, it reduces the total demand on the IPv4 address pool from 60 million+ addresses to 16 million addresses, about a 75% reduction in demand. This would free up around 44 million addresses to be used for other purposes.

We understand that some operators may need more than a /8 - this proposal gives them 16 million addresses, and can reduce the demand for other allocations from RIRs to satisfy their need (e.g. assuming an ISP needs 32 million addresses, this proposal can give them 16 million, and they can go to their RIR for another 16 million, rather than asking the RIR for the whole 32 million).
   (3)RFC1918 Overlap:
 "Utilization of separate assignment can remove the challenge of [RFC1918] address overlap between the customer  network and the provider network." I do agree with you on this point. However,although it is a method to solve the overlap problem, it isn't the best practise method. Because we can deal the reduplicate problem through address planning specially for the ISP who can control the users' CPE and update them online. For the ISP who can not remotely control the CPEs, they can use commercial means to require subscribers to configure private IPv4 address of certain range within their families.

 "Providers can avoid the use of bogon and/or squatted space within their networks.  This type of address usage can cause connectivity problems for customers and can be difficult to diagnose." It is right, but I don't think it is the advantage of the method. Because using private IPv4 address can also avoid the squatted space problem.
 [CD] Many of the providers we've spoken with have either exhausted Net-10 or can't use it because of overlap with their customers.  Moving past Net-10, we think that it is preferable to have a defined range for transition space, rather than have operators use bogon/squatted space for lack of better options.
   (5) Clear IP allocation for IPv6 transition technologies:
 "A block reserved for transition usage can be well defined and provide best practices for transition technology deployment." May I ask why? This sentence seems like to tell me that private IPv4 address block can not well define the transition usage, but actually it can.
[CD] as mentioned above, there are a number of operators that can't use existing private space for this purpose.
  (6) Security:
" It is easier and more secure to build security polices for larger address blocks, rather than multiple smaller blocks. Larger blocks minimize the number of firewall rules or access list statements required to implement such a policy, and thereby reduce the number of errors.  This results in better customer Internet experiences.  In addition, service providers can filter[RFC1918] space at the edge of their network, and creating separate policies for shared transition space, which ought to only be deployed between the customer premise router and the service provider NAT/ Border Relay." This sentence seems like to tell me that private IPv4 address block will meet such problem, but actually it wouldn't.It all depend on address planning.
2. From the 6RD respect:
   The IPv4 address here, which facing the exhaustion and overlay problem, may be public IPv4 address or private IPv4 address.For private IPv4 address,the comments of flexibility, efficiency, overlap and so on are the same with the NAT44.
[CD] You're right - in many cases, ISPs will deploy 6RD and NAT444 together and the problem looks the same.

  (1)Flexibility:
  From the public IPv4 address aspect, using another /8 public IPv4 address specially for transition will lead to less flexible. Because, the users use 6RD visiting the IPv6 Internet and at the same time , they can use public IPv4 address to visit IPv4 Internet. If we allocate a /8 public IPv4 address reserved for transition,the ISP should add another similar NAT44 gateway to translate these IPv4 address to other public IPv4 address which can be routed in the Internet. It is not flexible .
   (2), (4) ,(5) and (6) are the same with the upper comments on NAT44

   (3) overlap:
       There is no overlap problem in the 6RD scenario. Because, for the family network,the CPE allocate private IPv4 address to the PCs, and the CPE is allocated the public IPv4 address, there is no possibility to overlap.
   Besides the different opinion with your upward advantages listed in the draft, I think the allocation of /8 IPv4 address may bring complexity and difficulties to the network management and operation. The network routing deployment always needs very careful.[CD]  agreed To revise the routing strategy may lead to routing disorder.[CD]  Many operators are currently revising their routing strategies in light of the pending IPv4 exhaustion.  Not to discount use of RFC 1918 space, but we are trying to provide an additional tool to minimize operational/network management complexity compared to the other remaining options (e.g. individual allocations, squatting, reusing net-10 space).
   In conclusion, I don't think it is quite necessary and reasonable to allocate a /8 IPv4 address block from the unassigned IPv4 address pool.
    Thank you very much!

Cancan Huang