Subject: Re: "class E" (was: Consensus Call: draft-weil-shared-transition-space-request) Date: Wed, Dec 07, 2011 at 12:19:49AM +1100 Quoting Mark Andrews (marka@xxxxxxx): > > In message <20111206055756.GD20780@xxxxxxxxxxxxxxxx>, =?utf-8?B?TcOlbnM=?= Nils > son writes: > > Subject: Re: "class E" (was: Consensus Call: draft-weil-shared-transition-s= > > pace-request) Date: Tue, Dec 06, 2011 at 08:38:56AM +1100 Quoting Mark Andr= > > ews (marka@xxxxxxx): > > =20 > > > Ask everyone everywhere that is using this block, in good faith, > > > for some purpose other than supporting addresses behind a CGN to > > > renumber out of this block of RFC 1918 addresss which is now being > > > re-purposed 16 years after it was allocated. > > > > I do not understand why it is so hard to come to terms with the fact > > that IF you have -- in whatever faith -- chosen to use non-unique address > > space, you have been taking your chanches that sometime, in the future, > > you WILL have to renumber to keep the illusion of quasi-uniqueness. This > > goes for everybody. Customer, operator, middlebox or CPE vendor, > > and my mother. This is inherent in all non-unique space. A new shared > > allocation from the RIR pools or Class E will not change this fundamental > > characteristic. Therefore, 1918 space, being the prime example of > > non-uniqueness, should be quite suited to populate the inside of a CGN. > > Actually it isn't inherent. It's only if two of the parties involed > are forced to use the same address pools that renumbering is inherent. Oh, sorry, I meant the _risk_ (taking your chanches) of conflict as being inherent. Unique addresses are meant to be collision-free, whereas any allocation that might be made as a consequence of this draft can only result in potentially conflicting allocations. Thus, RFC 1918 is as [bad|good] as any other allocation. I furthermore think that any recommendation about address space for CGN insides should try to point out likely candidates (172.28/15, perhaps) but not do more than that. Then broadband router vendors could stay away from that prefix for their defaults (which they do; I've never seen, and anecdotal data[0] confirms it, anything but 192.168/16 and 10/8.) and things would "work" until the infrastructure and services are upgraded. Further, I think, with personal experience from several 1918-using enterprises[1], that the situation with "large organisation with all 1918 space used internally gets put behind CGN" is a hoax. Those people nearly always have a guarded stash of old class C swampspace that they use for things like DNS servers, firewall outsides, MX records, etc. Ususally, they can come up with a /27 from that to number a bunch of p2p links. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Xerox your lunch and file it under "sex offenders"! [0] http://www.answersthatwork.com/Download_Area/ATW_Library/Networking/Network__4-List_of_default_Router_Admin_Passwords_and_IP_addresses.pdf [1] here defined as largish organisation with dedicated IT staff and some cashflow.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf