[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[6bone] Request: two 6bone pTLAs
>> While I recognize that automagically finding resolvers can be quite
>> important, I think that WKAs have already been proven to be not a dead
>> end, but a velodrome from which you cannot escape, and where you just
>> have to pedal faster and faster.
> Do you have any pointers for this?
The one pointer I have and extrapolate from, is the story I was told
about the appliance vendor that hardcoded IP-addresses to NTP servers
at some university in ROM code in ther boxes. (Note ROM, so that it
*CANNOT* be updated, even if the owner of the appliance was made aware
of the problem, and had the necessary competence to do something about
>> 1) A client system shouldn't spew packets (DNS or other) on any other
>> host, without local configuration to make it do so - preferrably
>> through a local configurations service such as DHCP.
> Why do you feel so strongly about this?
Because I know that systems are put in the hands of people that know
*NOTHING* about how they behave, and in no way have what it takes to
foresee the effect in large systems.
You cannot seriously mean that if I put up a server on the 'net, that
I must be prepared to handle any amount of traffic that is generated
not by people at will (surfers and crackers), but by the sheer fact
that a software vendor decided that my box was a suitable target just
because his random number generator happened to generate my IP address
when he coded the crap.
A box should remain silent, until you configure it to talk. Or, as I'm
told the Irish say, in a proverb: "A man should refrain from talking,
unless he can improve on silence." :-) (Exact wording modified by my
> I would be perfectly fine with stipulating that these addresses
> shouldn't be hardcoded by vendors, but rather specifically configured
> by end-users or their system administrators. Since these addresses
> will disappear in 2 years, hardcoding them would be counterproductive
That's a good step in the right direction, but there are two points
where we probably have different opinions:
a) You cannot stipulate anything on the 'net - especially not
regarding operational practices. Hence someone *WILL* hardcode them
- probably because its cheaper, and they want to use their money
for marketing purposes instead, and because of that the product
will sell really well, and "another university will have to shut
down their NTP servers" (if you get my point).
b) Because of a) (and quite possibly other similar problems), there
will be a substantial market pressure to keep the 6bone addresses
going *FAR* longer than for the coming 2 years.
User: "Remind me again - what's *REALLY* the point of removing
useful address space, that is uniquely distributed? I have invested
heavily in this. You can't make me turn off these systems! It will
ruin me! And if that happens, I will sue your butts off!"
... and when that happens in a US court, the outcome is given ...
If the 6bone addresses are really taken out from the general IPv6
network infrastructure in two years time, I'll by you a beer.
>> I really dislike a system where I or my ISP can be forced into
>> starting an anycast instance just to balance the traffic and make
>> sure that the service to the "local" clients is up to standard.
> I don't see how you would be forced to start an anycast service. And
> if you were so forced, this means there is no uptake of a "real" DNS
> resolver discovery mechanism, so the alternative would be that users
> either have no resolvers, or have to find them manually. Both seem
> infinitely worse than any inconvenience caused by the well-known
Umm, I realize that I didn't use enough detail in my description.
Suppose the following situation:
ISP1 has contract with user that includes certain quality of service
(in the general sense) clauses with regards to DNS. Users uses systems
with DNS clients that use WKA, and not what the ISP1 tells them with
DHCP. In order to fulfill its commitments, the ISP1 then has to start
a DNS service on these WKA:s, because if they don't, the DNS packets
will dissapear like turbo charged mosquitos towards the nearest lamp,
um sorry, nearest WKA DNS server, which - by pure chance - happens to
be operated by ISP2 (ISP1's fiercest competitor), which, of course,
has a suitable filter for queries coming from ISP1, to which delay is
added, and, just for fun, a certain amount of random malfunction.
And - if ISP1 *does* start a service on the WKAs, they will have to
jump through a few loops to make sure that just the right customers
(a.k.a. they paying ones) reach their servers, so that they don't get
hit when ISP2 turn theirs off, since they just realized that the DNS
service comes for free at ISP1, if you just turn off your routing.
Now, if the client took the DNS-data in DHCP, ISP1 could tell them
which servers to use, and that would be the end of it.
>> Things shouldn't be turned "on" by default on the Internet, they
>> should be turned "off". Otherwise you stand the risk of ending up
>> like Windows, where every bell and whistle is turned on by default
>> - open for each and every cracker to take advantage
>> of. Automagically having them turned "on" also puts you in an
>> awkward position from a legal standpoint:
>> E.g., in court:
>> Party1: "You keep bombarding me with traffic!"
>> Party2: "I haven't turned on anything such, so it can't be my
> I'm sorry, I don't find this argument convincing.
>From a legal standpoint, I find it important that the actions
performed by a computer can be traced back to an individual who can be
held responsible for them. I'm worried about the scenario where a
person buys a computer, hooks it up to the 'net, and leaves it. "I
didn't do anything, so it cannot be my fault!". The software vendor
will say: "We didn't put the computer there, so it cannot be our
fault!". Who's right? Who's fault is it?
>> 2) Locking these well known addresses into systems is likely to cement
>> the use of 6bone addressees in a way that we *REALLY* don't want
> 3ffe::/16 is going to be ususable anyway for years to come because of
> stray configuration that has to be cleaned up. And it's not like we're
> running out of IPv6 address space any time soon...
You'll be surprised. In the early days of the Internet, they weren't
running short of addresses any time soon either, because they hade the
*HUGE* address space of 8 bits! (IPv1 - I think.) And who would ever
consider a computer network with *256* computers in it?!
To start with, the address space has been cut down to ~5.5E-20 of what
it could be, since someone decided to waste the lower 64 bits on
something that already unique!
On top of that - what's killing IPv4 space is not the number of
computers, but how the prefixes have been distributed, which has lead
to both address depletion and routing table growth. Now, they're
tossing out /20s in IPv6 land. That's pretty big chunks. Far bigger
than the old /8s (class As), and their are mathematically exactly as
many /20s in v6 land as there are in v4 land ...
>> 3) I think it opens up a Pandora's box of security issues that I, for
>> one, don't want to touch even with my thickest gloves.
> Like what?
Like me trusting the DNS answers from a resolver I have no relation
with what so ever, and cannot even deterministically predict the
topological location of.
And - more important - the WKAs become very obvious targets for (e.g.)
DDoS attacks. If the addresses are hard coded into the end nodes, it's
*VERY* hard to get away from that situation. You *have* to maintain
the service on exactly those addresses, and the your enemies will keep
bombarding exactly those addresses.
(BTW, this problem is already very real with existing WKA servers.)
>> DHCP is the way to go. It's there, it works, it's been proven to fit
>> into really small appliances.
> Do you REALLY want to get into this on this list?
I'm not quite sure. :-) But it seems to be too late for me to back
out. :-) :-)
> Even if for the sake of argument it would be a good idea to run DHCP
> everywhere (which it isn't),
Like where? :-)
> then we still have the problem that some significant operating
> systems currently don't support it don't allow the user to add such
> support easily.
That argument isn't convincing to *me*. :-)
If the user is unhappy with the operating system, switch to another
one. The market is full of them. Or, put pressure on the vendor to
implement it. I will gladly list at least 4 operating systems, all of
which run on a multitude of platforms (from palmtops to mainframes)
and implement DHCP. And all of them are free.
> Please understand that this is an experiment. It won't break the
I agree that my arguments are geared more towards a general WKA
scenario, than towards your specific proposal of using 6bone space for
an experiment, but I think one has to deal with the principals, and
not only with the details.
Suppose your proposed experiment turns out to be a commercial
success. What do you say to "your" users when the day comes to shut
down 6bone? "Sorry, guys, the party is over."? No, I guess not. So you
have to look at the future now already.
How do you plan to migrate from a successful 6bone experiment to
production in "real" IPv6 space?
What about expansion: how many WKA prefixes do we expect in the long
run and how do you deal with growth rate? If it can be used for DNS,
others will find other applications for the technology, and one has to
look into scaling problems. What happens when you do this to other
Taking my example from above: How many services will ISP1 have to
start on WKAs to fulfill all of its obligations towards the customer?
Anycast is a two-edged sword. Using it as a means to work around the
problems with the operating systems you mention could be the least
senseless way to do it, but only if done on a local scale. The thing
that scares me is the WKA part. I simply don't want that kind of
implicit trust relationship between non-consenting partners. It worked
when the Internet was a few thousand university hosts. It's not really
feasible in a system where businesses turning over billions of dollars
hinge on the function and non-function of servers that you cannot
control. The DNS of today has bits of that, and I don't see it as
good. There is, e.g., lots of legitimate concern about how to handle
the situation with the root name servers, their respective operators,
and their responsibilities.
I want to move away from that uncertainty, although I don't know how
to yet. This doesn't seem to be the right way.