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

[Ville]

Bob,

On Sun, 17 Feb 2002, Bob Fink wrote:

> 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 
  ^    ^

	I find myself comfortable with the rest of the policy being
	introduced, yet I feel it would be sad trying to enforce a
	specific rule for renumbering - especially with an exception
	clause such as the one above.
 
	I'll try and outline my own view on the issue below:

	    The exception-clause still permits for /some/ of the current
	    pTLA-holders to continue using their present 6BONE address-
	    space. (logically)

	(1) This both, introduces an advantage over other pTLA-parties
	    (size of address-space, continued usage) and also, in a
	    nasty - yet imaginable - scenario, even further strenghtens
	    the pTLA's will and desire to develop services that really
	    cannot be renumbered into another IP-block. After all, it
	    will make for the only means of sticking on to one's "own"
	    (current, static and free) pTLA. --

	    Nobody says the services developed purely for the purpose
	    wouldn't be all useful and beneficious, yet if the exception-
	    clause didn't exist, the renumbering probably would also
	    have been taken into account while developing the piece of
	    software (or H/W, for that matter), effectively avoiding
	    the unnecessary imbalance.

	(2) Unfortunately, if the exception-clause exists, a rule
	    won't help make the address-space more coherent. Individual
	    entries will still exist in a non-continuous 3ffe:80c0-
	    zone. Result: We still can not filter the whole, future
	    3ffe::-space as one of unified length (be it /32 or any
	    other), because of the pTLA-remnants.

	    Also, it would be difficult to determine whether the old
	    prefix is truly still being used or just has been hijacked
	    by future spammers (like I assume is currently happening
	    with swamp-/24's [IPv4-wise] popping in and out).

	    This is mostly caused by the fact the zone and any IP-
	    blocks under do remain technically legit as opposed to being
	    fully invalidated - which would make possible for complete
	    and thorough filtering of the space.


	Other issues that do come to kind about re-numbering on the
	practical level include--

	(1) Fair amounts of link-lists (WWW/FTP/NTP/...) are currently
	    being maintained, largely by volunteers. Any changes to
	    current IP-addresses mean extra work, in addition to the
	    normal pTLA->sTLA address-updates.

	    I suspect some of the people maintaining these lists are
	    no longer on the 6BONE themselves, thus resulting in a number
	    of seemingly valid, yet non-working lists of sites.

	    (Long version: Their page states the linked site belongs to
	    company A, which more or less makes it looks like company A
	    simply either does not provide the service anymore or that
	    their server is down. While company B providing the outdated
	    listing is more the cause.)

	    I know, all these lists should be based on DNS, but on a
	    quick look this often seems not to be the case. :-( Digging
	    all the info up manually is tiresome and perhaps unneeded.

	(2) Peering loopback-addresses, physical connections to IX'es
	    (if using 6BONE-address-space) and reverse-DNS-servers
	    will all have to be renumbered. Esp. the renumbering of
	    loopback-addresses and any related tasks will need assistance
	    from both sides of any tunnels and links.

	    While the above clearly is useful for ensuring people do not
	    attempt to provide production-quality service on the 6BONE,
	    it also does produce (read: generate) a fair amount of work
	    and puts us a number of years back in terms of quality

	    In my opinion, it effectively makes using 6BONE for gaining
	    operational-experience more difficult: If you cannot reach a
	    site by its old IP-address, should you first check if they
	    have recently swapped into new address-space? Or whether
	    the problem is on the link-level, BGP, filtering?

	    Everything was already working smooth for once.  ,)

	    It adds for an extra level of complexity in trying to find
	    out why something doesn't work.  Even if we have developers
	    participating on the 6BONE (or IPv6, in general), it does
	    not (unfortunately) necessarily mean all of them are overly
	    keen on following the politics. (I would personally
	    view it as more logical that this development, even if over
	    a longer time-spam, is indeed carried out under 3ffe::/16 as
	    opposed to under the RIR-allocations at 2001::/16 which we
	    were wishing to use solely for production.)

	(3) In practice, renumbering might degrade the number of companies
	    wanting to provide near-production-quality evaluation of
	    IPv6 for free. Roughly, I would assume this is how generic
	    upper-management would find it: renumbering means work, free
	    means no pay. (Conclusion: Why is the service being provided
	    for free in the first place?)

	    As pointed out by Pim, people have different uses for pTLAs
	    and sTLAs. This also applies to us: pTLA is an easy way
	    for us to permit non-customers free use and testing of our
	    capabilities without the fear of them more representing
	    neither us nor our customers.

	Apologies if any of this has been previously stated, I had
	quite some catching up to do with e-mails from the past
	week.

	The rest of the proposal sounds ideal. I'm glad it was
	brought up at this point-- It's always easier to introduce
	a full-blown policy in its wholeness for new participants,
	instead of having to add and sum up individual requirements
	along the way.

	As for the size of the future pTLA's, personally I would
	most be in favour of sizes either 1-2 bits less than the RIR-
	standard or alternatively exactly the same size.

	Pekka of Netcore already put it nicely.

	The first would make it possible for easy migration and the
	latter for more broadly unified bitmask-sizes.


> Bob

Cheers,
-- 
	Ville <viha@stealth.net>  Network Security/IPv6 Solutions
				  Stealth Communications, Inc.