[170026] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: misunderstanding scale (was: Ipv4 end, its fake.)

daemon@ATHENA.MIT.EDU (Mark Tinka)
Sun Mar 23 15:02:35 2014

From: Mark Tinka <mark.tinka@seacom.mu>
To: nanog@nanog.org
Date: Sun, 23 Mar 2014 21:02:05 +0200
In-Reply-To: <20140323183548.GA27838@pob.ytti.fi>
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

--nextPart10191459.nW08YSNfNT
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Sunday, March 23, 2014 08:35:48 PM Saku Ytti wrote:

> Or IT isn't buying the 'renumbering is easy' argument,
> for any non-trivial size company even figuring how where
> exactly can be IP addresses punched out statically would
> be expensive and long process.
> If you are pushing for customer to use your PA in their
> LAN, I'm guessing net-result is you should never reclaim
> those addresses after customer leaves, since chances
> are, some customers won't renumber, but will 1:1 NAT
> your PA to new operator PA, and your next customer with
> this block will complain about reachability problems to
> this other customer.

In all fairness, I'm not so sure, as operators, that we want=20
to push our PA space as assignments to customers in IPv6-
land.

Yes, it makes sense, but then again, it's not hard for=20
enterprises to obtain PI space from $favorite_registry. Yes,=20
that will pollute the routing table and potentially mean=20
your customer can run away from you at any time. But IPv6 is=20
so vast, and as you rightly point out, Saku, it might be=20
unreasonable for us to expect the enterprise to renumber=20
when they churn and take their business elsewhere. It,=20
physically, is a lot of work.

So while I have lots of /56's and /48's to assign to=20
customers from my /32, I'm not sure I want to actively=20
encourage it, unless as a last resort.

Of course, assigning this to broadband users makes more=20
sense, as use is generally temporary and well controlled.

Mark.

--nextPart10191459.nW08YSNfNT
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAABAgAGBQJTLy+tAAoJEGcZuYTeKm+GdGEQALXQNha42ZJpm4cBgBzWGdeP
GC5vFdzIXImJucB+ielh4Lym7SCjhWe+R2P4wBKFFMfIrhs1CKXhPgNPaPNV9rNx
AupbnLVV6zaI7mzi16sOl93zYOzoeYHcg6F6J/7wIuivvOEcNiXY4yKetYGXkwbx
Qwfp0BhfUn8BiNi2mKFqZDch0aOb9x8/049QORmDdwo3vQv1hyL/dXpEFhjBxhdp
ZxOZFA2a7J/8FogAEwsuIZrp0GWcEkQl2ioDmcy/72dRAO89KpB4cgqQo+XV11UK
+RasMMQuXqAkI5cpuRhIKpNUEGOcHbJlqzvRZyoBJVJsit5n3N7PwI80Cf8qnJCX
lYYhu1EQMUmImTEv9GlVRoJLmECaUA+8T6KSy/6nJAYOuOivnA9GMTrBi9/i01RQ
U9mIIQijiGpjDPu69Wl4pRIQw7gasdl5AILqWbvzN0OtM5ntPtq04x56hPytqDlR
0RABQq7KvvxfqvWh8moK9k8VnKgcChv1g5MdeocPxa+cL3ium8pL2aFFTPHwNklm
svcWem2Eep6YjwxhYOoIYS+EPT+hZnyXK4feQV5TMQV/n7el7dcCDx+osDSlPcbA
NdhBtZJJZ6JEY5kPTNpZtHCZ2SaLsMtEz67dKGi57MmoW39OHY2028lhJ+i25W6b
hJQrp/6J3e9RiwecwN+2
=hWWB
-----END PGP SIGNATURE-----

--nextPart10191459.nW08YSNfNT--


home help back first fref pref prev next nref lref last post