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

[Pim van Pelt]

Hi,

Skimming through these notes, I would like to make one point.

With the recent issues concerning multicast (sorry to bring it up yet again:),
and global reachability for enterprises, I can very well imagine non ISPs
requesting a pTLA status (or even taking their case to a RIR) just for them
to be reachable via multiple paths. This would mean that large companies will
get this status where they could/would not in the IPv4 world. I see a possible
and even probable explosion of the DFZ with this in mind.

The first example of this has been given by our collegues from Microsoft. Not
to start a bash on them, on the contrary, their research into the protocol is
much welcomed by me personally. It does illustrate the point, however.

With the 6bone thouroughly intermixed with the sTLA world as of today, having
a pTLA has no disadvantages over RIR space. The ARIN region even has to pay 
for their allocation in the first place. This seems to me as a potential threat
to RIR policies in the mid term future.

I find your points 2 and 4 to be of some use. We should make the pTLA requester
aware that these network allocations made under the 3ffe::/16 network are not
to be used to circumvent RIR policies. 

I myself use the pTLA and sTLA for INTOUCH-NL differently, and would not like
to hand in, nor renumber, the current pTLA. For the record: my sTLA is used for
native (ams-ix) paying customers and affiliates of Intouch NV, and the pTLA is
kind of dedicated to the IPng project (the public tunnelbroker). It makes no
sense to me to renumber IPng into the sTLA. I would like to keep playtime and
business (well, future potential business, anyway ;-) separated. If point 4
is satisfied, why would the exception case in point 2 have to be proven ?

The 4th remark however is very smart. We (the 6bone community) should require
valid use and regular reports, I would even say every 12 months, in order for
the entity to be granted continued use of their pTLA. This way we might be able
to catch the potential RIR circumventing entities before they make use of the
6bone for production state networks.

The other points seem quite usable, and a /32 bit pTLA means we will be able 
to go on for some time until we hit even half of the 16K scope of these 
networks. It will take some filtering updates on most of our routers though,
as I think most of us accept only /28 in 3ffe:8000::/17 and /24 in 3ffe::/17
ie not -le 28 (at least I am very strict on policies at the moment).

| 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.
| 
| 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.
| 
| 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.
| 
| 4. requiring a restatement of pTLA usage and continuing need every 2 years.
| 
| 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.
| 
| 
| Please send comments to the 6bone list by 4 March 2002.
| 
| 
| Thanks,
| 
| Bob

-- 
                             __________________
Met vriendelijke groet,     /\ ___/
Pim van Pelt               /- \ _/  Business Internet Trends BV
PBVP1-RIPE                /--- \/            __________________