Re: [OPSAWG] Heads up - Plea for allocating a /8 to ISPs
Mark Smith <ipng-KJKIt35SYvig+96AiQNgT+hiC5znLf7cZPcaUtDxc8WOQDzvkKpvAmD2FQJk+8+b@public.gmane.org>
| Newsgroups | gmane.ietf.v6ops,gmane.ietf.ops |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 15 Nov 2010 02:24:26 +1100 Christopher LILJENSTOLPE <[email protected]> wrote: > Greetings, > > It's a trade-off between slop in public address consumption by the CGNs and multiplication of services that need to be before the second nat (intercept comes to mind), and the desire to limit the impact of the request. > > If, say, we had a small block, and needed to re-use it 16 times, then I would need 16 intercept infrastructures, and, more importantly, 16 public address pools (one for each CGN cluster, assuming one cluster to NAT444 "network"). That means that each of the public pools will have to have buffer, vs. sharing the buffer over fewer CGN clusters. > So why should the global Internet miss out remaining IPv4 address space, just because you want to avoid "16 intercept infrastructures"? In your employer's market, your employer is large. On the world market, your employer is small. Would your employer consider it fair if one of the much larger global providers said, "we want all the available IPv4 address space for NAT444, to avoid "128 intercept infrastructures"? I understand the specific issue of transitioning to IPv6 with customer owned CPE. I don't however think it is fair that ISPs with this problem to try to place opex and capex of dealing with it on the global Internet community. These customers have participated in a market that expects to be able to buy the CPE, from ISPs or other outlets. That means that while they've benefited from price competition and choice, they've also taken on some of the responsibility for the operational costs of owning the CPE. Costs incurred due to software or hardware upgrades, or costs incurred by their ISP dealing with them not performing software or hardware upgrades when necessary, should be borne by the people who've created and benefited from that market form - the customers. As an ISP, that means passing on those increased capex and opex costs onto to the customers themselves, not the global Internet community. > There is a bit of truth in what Randy says, although, not necessarily his intimation. > > 1) We want to use as small a block as reasonable without causing too many problems as identified above > 2) By asking for a smaller block, we hoped to remove some of the emotion and heat from the discussion. > > Chris > > On 13Nov2010, at 14.05, Sam Silvester wrote: > > > On Fri, Nov 12, 2010 at 5:13 PM, Christopher LILJENSTOLPE > > <[email protected]> wrote: > >> It's not being used for internal devices, please re-read the draft. It is > >> to enable NAT444 to allow the delivery of IPv4 services, after run-out, > >> using NAT444, to act as the v4 substrate between a CPE supporting 1918 to > >> the customer, and the public internet. > > > > I may have put that badly (Friday afternoon and all) in my original > > reply - that's exactly what I meant. It seems (as has now been > > commented on by a few) that a /10 seems like an awful mightly lot of > > addresses to do this, considering this space would exist 'betwen' the > > CPE and the CGN (I hate that term). > > > > Can you speak as to where the decision was made for the 2^22 address > > requirement & reasons why this couldn't be done with multiple > > VRF-style instances of existing public IP address space? > > > > --- > 李柯睿 > Check my PGP key here: > https://www.asgaard.org/~cdl/cdl.asc > _______________________________________________ v6ops mailing list [email protected] https://www.ietf.org/mailman/listinfo/v6ops