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

[Victor Kuarsingh <[e-mail]>]

+1


On 28/10/10 3:53 PM, "Chris Donley" <[e-mail]> 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:
>         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:[e-mail]]
> Sent: Wednesday, October 27, 2010 2:55 PM
> To: Chris Donley
> Cc: [e-mail]; Victor Kuarsingh ([e-mail])
> Subject: Re: [OPSAWG] Request for feedback:
> draft-weil-opsawg-provider-address-space-02
> 
> 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:
>> > 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
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > OPSAWG mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/opsawg
> 

 ---------------------------------------------------------------------------
   Victor Kuarsingh
   IP Architect, Network Technology
   Rogers Communications Inc
   Business: 647-747-1785
   Mobile: [phone]
   [e-mail]
 ---------------------------------------------------------------------------
-

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.