ietf
[Top] [All Lists]

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

2011-12-07 19:30:49

In message <20111207223526(_dot_)GJ20780(_at_)besserwisser(_dot_)org>, 
=?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(_at_)ietf(_dot_)org
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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>