Ron,
Please see in-line.
Chris
On 12/3/11 3:06 PM, "Ronald Bonica" <rbonica(_at_)juniper(_dot_)net> wrote:
- 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
exhaustion of IPv4?
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf