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

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

On 28/10/2010 3:53 PM, Chris Donley 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:brian.e.carpenter@gmail.com]
> Sent: Wednesday, October 27, 2010 2:55 PM
> To: Chris Donley
> Cc: opsawg@ietf.org; Victor Kuarsingh (victor.kuarsingh@rci.rogers.com)
> 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
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>