In message <20111207223526.GJ20780@xxxxxxxxxxxxxxxx>, =?utf-8?B?TcOlbnM=?= Nils son writes: > Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-re= > quest Date: Wed, Dec 07, 2011 at 11:31:11AM -0800 Quoting David Conrad (drc= > @virtualized.org): > > Michael, > >=20 > > On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote: > > > The CGN space seems like a very good place to use 240.0/10. > >=20 > > I believe the main driver behind this discussion is the need to deal with= > deployed non-field-upgradable CPE that has issues with having RFC 1918 spa= > ce being assigned on the WAN interface. I'd guess said hardware would also= > likely have issues with 240/4 space being instead. > =20 > I believe we can narrow the problem with RFC 1918 addresses down to "same > or overlapping prefix on the outside as inside", rather than assuming > that any use of 1918 space on the outside interface is detrimental. > Does anybody know of any evidence to the contrary?=20 This is not a ISP/CUSTOMER problem. This is a ISP/CUSTOMER/WORK problem. You have the ISP using 172.16/12 You have the customer using 192.168/16 or 10/8 You have WORK using 172.16/12 Enterpises have choosen to use 172.16/12 for EXACTLY the same reasons you want ISP to use 172.16/12. CPE equipment doesn't default to that range. Both the enterprise and the ISP don't want to clash with the employee/customer. ISP's also need a big enough range that they minimise the number of times they have to re-use the address range as every re-use introduces more potential for routing leaks, mis-diagnosis, etc. In addition to all the RFC 1918 address are for *private* use. Allocating RFC 1918 address is customers not private use, so are you also planning to update RFC 1918 to permit this *new* use case. > Vendor default allocations of RFC1918 to "broadband router" LAN interfaces > are limited to nets 10 and 192.168. Does anybody know of any evidence to th= > e contrary?=20 > > Therefore, point out a /15 from 172.16.0.0/12 and be done with it. The > few conflicts arising will fall in two classes: > > a/ People who have knowingly changed their LAN prefix.=20 > > b/ Organisations large enough to use _all_ of RFC 1918 inside.=20 > > "a" means they can change again. Problem solved.=20 > > "b" means that they are large enough to be able to buy public external > addresses, if they do not already posess swamp space. Problem solved. > > > --=20 > M=C3=A5ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > Now I understand the meaning of "THE MOD SQUAD"! > > --I/5syFLg1Ed7r+1G > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: Digital signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk7f6i4ACgkQ02/pMZDM1cUZNgCgkdyeg55f8yTu/x3mxPCwFx86 > EMMAoJWcaq23P1g9SQfgeUZeDqw+M3sV > =nEJ/ > -----END PGP SIGNATURE----- > > --I/5syFLg1Ed7r+1G-- > > --===============0194820202636702821== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > --===============0194820202636702821==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf