new 6bone pTLA prefix proposal, comments by 4 March 2002 please

[Michael Kjorling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 17 2002 17:47 -0800, Bob Fink wrote:

> 6bone Folk,
>
> We are seeing a recent increase in pTLA requests, and it prompts me to
> recommend a change in pTLA prefix length to allow for future growth.
> Basically I propose changing from the /28 prefixes we now allocate to /32:

Just a reflection: why not change to a /35, which I believe is the
normal production subTLA allocation? This would mean that when
companies migrate to a production subTLA there will be significantly
less work involved, as they can just hand out the very same NLA/SLAs
but under the new prefix. Customers would have to renumber anyway, so
there is little reason they cannot renumber to the same prefix, which
still means changing only the first 48 bits of the address (plus
*possibly* the SLA, but that would be unrelated to the prefix change).

Comments, please?


> ===
> The current 6bone pTLA numbering plan is:
>
>    3FFE:0000::/24 thru 3FFE:3900::/24 are allocated [there are 58 /24 pTLA's]
>
>    3FFE:8000::/28 thru 3FFE:8340::/28 are allocated [there are 54 /28 pTLA's]
>
> I propose:
>
>    3FFE:0000::/24 thru 3FFE:3F00::/24  [no new allocations here]
>
>    3FFE:8000::/28 thru 3FFE:83F0::/28  [no new allocations here]
>
>    3FFE:4000::/32 thru 3FFE:7FFF::/32  [which provides for 16K /32 pTLA's]
>
> leaving:
>
>    3FFE:8400::/32 thru 3FFE:FFFF::/32  for future use

I have no objections against such an allocation except the /35
proposal I mentioned above. The 16,383 new pTLAs given by
3ffe:4000->7fff::/32 as well as the 31,743 still available under
3ffe:8400->ffff::/32 should be enough for the reasonably forseeable
future (especially given that the 6bone is a testbed and not a
"production" network). The policy changes (which I will comment on
below) does not make this worse, either.


> ===
>
> In addition, I would like you to consider some possible policy changes:
>
> 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32,
> unless justifying why it is not possible due to usage and/or address layout
> issues, within 6 months (12 months?) of the change in policy.

This would hopefully mean that we'd move most current pTLAs into a /32
block. (Even though it would be nice to hear comments about my
proposal of a /35 pTLA allocation scheme.) It certainly does not sound
like a bad idea to me.


> 2. encouraging pTLA holders to apply for a production subTLA allocation
> when they move to a fully production mode; requiring those charging for
> service to also apply for a production subTLA allocation; requiring the
> pTLA to be released within 6 months (12 months?) of acquiring a subTLA
> unless justifying why the pTLA allocation is still needed/required.

This was a lot at once. Let's take your individual suggestions one by
one:

"encouraging pTLA holders to apply for a production subTLA allocation
when they move to a fully production mode": Encouraging, yes. Forcing,
no, I believe that is not the way to go (e.g. by revoking the pTLA
allocation.)

"requiring those charging for service to also apply for a production
subTLA allocation": This is not by any means an unreasonable
requirement. After all, if you are paying for access you probably
expect production level service. The 6bone and IPv6 part of the
Internet seems fairly stable to me, but I wouldn't exactly love paying
for experimental services. For dial-in/cable/etc. ISPs especially,
renumbering should be fairly simple, but even with customer /48
assignments it shouldn't be impossible.

"requiring the pTLA to be released within 6 months (12 months?) of
acquiring a subTLA unless justifying why the pTLA allocation is still
needed/required": Once one has obtained a production subTLA I can see
little need for keeping the pTLA, as long as the clients' networks can
be renumbered without an extreme workload on the administrators (which
in one sense would go against the idea behind address
autoconfiguration and such anyway).

Let's not forget what Michel Py mentioned, either. One way to try to
help stopping global routing table pollution might be to require those
applying for production subTLAs to actually provide ISP services to
customers (whether for a fee or not), but this is something that would
require further discussion.


> 3. pTLA holders should not assign pTLA based allocations to paying
> customers except for early test/trial purposes.  paying customers should
> always receive RIR based allocations when service is not for test/trial
> purposes.

This is something I certainly have no comments about, except that I
agree with it. Even for trial purposes, having a dedicated block (say,
perhaps a /40 or something on that order for a really big ISP) under a
subTLA where addresses can be handed out is not unreasonable. That
would mean a 1/32 of the /35 subTLA.


> 4. requiring a restatement of pTLA usage and continuing need every 2 years.

Not by any means unreasonable. Also see below.


> 5. requiring the return of a pTLA when it is no longer used by the original
> requesting entity. this is the de facto policy, but has not been stated
> previously.

Agreed. Another idea: require that pTLA allocations are returned or at
least reconsidered when the need that prompted the allocation is no
longer there. This seems to be standard practice today about IPv4
allocations (even for rather small allocations like my IPv4 /28) and I
cannot see why IPv6 should have to be much different in that aspect?
It is better to adapt such a policy while we are still at a fairly
early stage than rushing to it later on.

Comments, please?


> Please send comments to the 6bone list by 4 March 2002.
>
>
> Thanks,
>
> Bob


Michael Kjörling

- -- 
Michael Kjörling  --  Programmer/Network administrator  ^..^
Internet: michael@kjorling.com -- FidoNet: 2:204/254.4   \/
PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e

``And indeed people sometimes speak of man's "bestial" cruelty, but
this is very unfair and insulting to the beasts: a beast can never be
so cruel as a man, so ingeniously, so artistically cruel.''
(Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov')

*** Thinking about sending me spam? Take a close look at
*** http://michael.kjorling.com/spam/ before doing so.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Public key is at http://michael.kjorling.com/contact/pgp.html

iD8DBQE8cMZyKqN7/Ypw4z4RAvCEAJ9ZFZXSYycn6GERBYGGe6PxnfyU2gCfbvjE
F0zZiO7xXH6R4XdzKK/f3xk=
=mWKg
-----END PGP SIGNATURE-----