James Hess

The RIRs are very limited in what unused resources they could seek to
reclaim; therefore, even if there are efforts, there are not likely to
be a large number of resources reclaimed for the forseeable future --
not within 12 months.

Such policy methods as transfer to specified recipient rules, and the
ARIN STLS, for example,   are the most likely path towards address
"reclamation".

The addresses that cannot be reclaimed in that manner, are probably
uneconomical to reclaim,  due to the resources, and long amount of
time it would take a RIR to implement.

The RIRs policy making authority is limited by certain contractual
obligations, to resource holders, and to the community, and the RIRs
cannot arbitrarily reclaim resources.

They also cannot force a holder of a resource to release or abandon
it, and attempts to do so for lack of V6 deployment,  would only serve
to reduce the legitimacy of the RIR, and result in network
instability.

The registration services agreements, at least in North American
region say that the RIRs cannot revoke resources solely for lack of
use.    And some effort of the sort would more likely wind up in the
courts.

Tthe RIRs are not permitted or don't have authority to reclaim any
IPv4 resources based on solely non-deployment of IPv6,  even if there
was some policy to that effect.

-JH

Read more »

Breaking global connectivity is bad.   I  don't see networks turning off ipv4.

I would favor differentiation of network characteristics -- eg
Make IPv4 a service just for bulk transfer applications.
make IPv6  the best choice for interactive applications.

-- for example: large Cable providers getting together and agreeing to
implement a 100ms RTT latency penalty for IPv4;  in other words,
heavy buffering of IPv4 traffic,  and heavy oversubscription
(Resulting in greater total performance throughput for data transfers
over Bittorrent or microtransport, but less perception of performance
for interactive applications).

This is probably what they already have,  just stop trying to throttle
IPv4 users,  so to encourage IPv6 adoption -- they just need to make
have some high capacity IPv6 only links, and make it an uncongested
service,  that will provide additional benefits to application
developers to favor it.

Under these conditions,  IPv6 service can be higher.   Don't give it
away for free;
the IPv6  Cable/DSL service should have twice the cost for the end
user as the IPv4 service does,  so that they feel the IPv6 service is
of value,   and  should include all the assistance to achieve the
greater performance.

The exhaustion of IPv4 address space also creates an inertia against
users switching around IPv4 providers (due to insufficient IP address
space available to accommodate build out of new infrastructure);
therefore,  content providers would be incentivized to get people
accessing their site over IPv6.

E.g.
dedicated higher-capacity links for IPv6,  and less buffering to
minimize latency,  that  way  web sites initially get an incentive to
become IPv6-enabled destinations,  in the form of  perceived
improvements in performance;
without breaking connectivity.

etc. etc.

--
-JH

Read more »

In this case, there really is no administrative cut though... the
provider administers the DNS record.

It seems this is more about providing a security function to DNS, to
inform the public, about where the responsible parties change.

The right place for this, is clearly the  DNSSEC extensions....

If  the DS record identifies a different signer, then you have an
administrative split,
or if the e-mail address field in the SOA fields of the parent zone
are different, then you have an administrative split, OR if one of the
two zones has  RP (responsible party records),  and the list of RP
records are different for the two zones, then you have an
administrative split.

If the DS record identifies the same signer, AND    the    e-mail
address in the SOA records is the same;  or the  list of e-mail
addresses in the two zones'   RP records are identical,
then you don't have an administrative split.

--
-JH

Read more »