Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Subject: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Sat, Dec 03, 2011 at 05:06:42PM -0500 Quoting Ronald Bonica (rbonica@xxxxxxxxxxx):
> Folks,
> 
> On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because:
> 
> - it is difficult. (We are choosing between the lesser of two evils.)
> - a lively discussion on this mailing list has not yet converged
> 
> Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus:
> 
> - Is the reserved /10 required for the deployment of CGN?

No. RFC1918 will do, if done wisely. There indeed is additional
(oprational) cost, but nothing that can't normally be attributed to the
use of non-unique address space. Also, noone has touched on the
not-too-unusual use case of "one DSL, one PC" where the cutomer does not
attach a "home router/NAT box" but instead follows the instruction manual
that says "Connect PC to DSL modem Ethernet jack.". In that scenario,
the CGN is a marginal difference technically speaking. The assignment
of a previously-unicast v4 prefix in this case would cause confusion
since all How-To's currently present will point out that "anything non-
RFC1918 is unique or Multicast". Further, if the ISP decides to use 1918
space for CGN deployment there is nothing preventing assigning several
addresses (like a /28 or similar) to each customer, removing the need
for customer-operated NAT boxes.
 
> - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4?

Depends on where you are -- for me and my employers (past and present),
none. We enjoy the benefits of abundant Early Registrations. If, OTOH,
a new ISP can get a bunch of v4 /24's to properly dualstack important
services and interfaces exposed globally, and thus be able to get off
the ground using 1918 as v4 dualstack component for the rest, that is
a major improvement.
 
> - Can alternative /10s be used?

While the re-assignment of experimental space up above multicast
allocations remains an interesting (or at least amusing) exercise in
pain-shifting, the purpose here is to allow more or less orphaned
customer equipment to continue working. Forcing previously-
experimental address space on them is counter-productive.
And, as addressed above, unicast v4 space should be used for things
essential.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... I don't like FRANK SINATRA or his CHILDREN.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]