Fuel for the B Ark...
Brian Carpenter writes:
| Sorry, this makes no sense at all. There is no way to "restrict"
| certain types of domain name that has any meaningful effect
Eh? I can assure you that my colleagues and I will defend the
brand value of, for example, ebone.net, by only delegating subdomains
to Approved Entities. I am sure this is true of IBM.COM, and could
be true of a hypothetical owner of e.g. kids.tm or .kids.
Likewise, I can assure you that two of the national top level domains
I have history with vigorously and assiduously "restrict" access
to their TLDs according to policies established by the "owners"
of the rights in that TLD as identified by the IANA.
"Defend" here also implies -- and in some cases has meant --
actual removal of the subdomain delegation entirely when
the "brand rules" (or TLD rules, where the TLD is effectively a brand)
are violated.
| given the absence of international jurisdiction, and IP addresses
| relate to network topology not to content
It's very simple - if you want a piece of my "branded" TLA,
you have to be logically connected to my network. In order
for that to occur, you first and foremost have to agree to
my brand's rules, and secondly have to have a virtual connection
to my TLA, or in a CIDR sense, you have to be able to announce
subnets. This *is* done with IPv4 now -- in fact, IBM itself
announces various subnets of 4.0.0.0/8 (e.g. 4.22.193.0/24)
and 9.0.0.0/8 (e.g. 9.2.0.0/16, 9.3.4.0/24, 9.3.5.0/24 (why not aggregate?),
9.20.0.0/17, ...). Presumably the ASes originating the longer
prefixes have negotiated with and gotten an OK from the entities
delegated the original covering prefixes.
If we can make that last assumption -- that any globally announced
holes blown into a CIDR-style prefix have an OK from the "owner"
of the TLA -- then surely those holes and anything abstracted by
using logical connectivity rather than announcing longer prefixes
count as "restricting the address space".
Obviously this is a fine thing to fit into the next revision of
draft-ietf-ipngwg-default-addr-select-01.txt, since IPv6 has
the cool property of multihoming-done-by-source/dest-address-pair-
selection, and clearly [SELECT] should say that kids-safe end
systems (e.g., in classrooms, at libraries) MUST always prefer
a kids-safe prefix, even if using that kids-safe prefix is
not the optimal choice in terms of fewest hops, shortest delay,
highest availability, lowest loss, or some other metric.
| so they can't be used
| in this way, whatever misapprehensions some of the commission members may
| be under.
No, no, they are really on to something. They should push for:
1/ a formal policy that makes a string of numbers an
item of intellectual property (following 1-800-FLOWERS example)
2/ an entity which is "kids safe" to be granted sole use
of a particular IPv6 routing prefix, and which will advertise
the existence of this "kids safe" prefix to all and sundry,
and will facilitate the use of addresses from within the prefix
by approved "kids safe" hosts, by -- including but not limited to --
i/ forming a virtual topology to which "kids-safe" hosts, sites,
or ISPs can connect (a la 6bone)
ii/ negotiating with ISPs the carriage of globally-visible
subnets of the "kids-safe" prefix in some future "native"
IPv6 internet, if and only if the "kids-safe" protection
body approves the delegation of a complete subnet
3/ the adoption by the IETF of a "pre-fabricated" source/destination
address pair selection algorithm which will at the very least:
-- always choose the "kids-safe" source address
(when sending SYNs to web servers, for example)
-- raise an alarm or reject connections which are
not to or from a "kids-safe" source or destination
It is very clear that IPv6's approach to multihoming is infinitely
superior to IPv4 + CIDR's multihoming scheme, and I am glad to see
that even politicians recognize the opportunities that arise as
a result of this wonderful new technology.
Sean.