[6bone] Request: two 6bone pTLAs

[Iljitsch van Beijnum]

On 10-mei-04, at 23:46, Lars-Johan Liman wrote:

>> 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
> it.)

This issue is completely orthogonal to what we're discussing here. 
Obviously hardcoding (emphasis on HARD) an address without consent from 
the people using that address is very bad. However, the whole point of 
this request is to set aside two prefixes especially for this purpose. 
If for some unfortunate reason the traffic to these addresses gets out 
of hand, the prefixes can be removed from the global routing table, no 
harm, no foul.

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

Hence the need for controlled experimentation.

>> 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
>> anyway.

> 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).

If this happens, that will be a valuable, if unfortunate, lesson 
learned from the experiment.

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

There will be some pressure, sure. Nothing we can't press back against, 
though. Remember that these are values that the user can change 
herself, so any problems created here are non-fatal. Also, I would 
probably agree with you if the people that see no problem in clicking 
on .exe attachments were all using this. But for better or for worse, 
IPv6 deployment isn't quite that far yet.

> 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 don't like beer - but in this case I'll drink it.  :-)

>> I don't see how you would be forced to start an anycast service.

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

I really don't see the problem here. If you want to deliver a certain 
quality of service, obviously customers only get to complain if they 
actually use YOUR service. And if customers can't use DHCP (which is 
likely, I don't talk DHCP in v4 with my ISP either) then it's probably 
a lot easier for you to run a local WKA instance rather than distribute 
resolver addresses the oldfashioned way.

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

This is immaterial. Either you run a DNS resolver and you know and 
control pretty much everything, or you don't and you don't. Which kind 
of address this resolver happens to have doesn't come into play here.

> And - more important - the WKAs become very obvious targets for (e.g.)
> DDoS attacks.

If there are enough people running WKA instances this won't be a 
problem.

> (BTW, this problem is already very real with existing WKA servers.)

Like what?

>>> 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. :-) :-)

The reason I don't like DHCPv6 is that I don't want to run more 
services than necessary. I already have to run a router advertisement 
service, so it's a much better idea to have resolver addresses in there 
than add an extra service with all the potential for security problems 
that running services in general entails.

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

Guess what, no operating system is perfect. All in all I'm happy with 
the one I use most, and I'm not about to give up the advantages it has 
just because YOU don't like well known addresses and think I should be 
running DHCPv6.

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

Here you go. You feel that a portable, free OS is superior to one 
that's closely tuned to the hardware and is supported by paying users. 
I don't.

>> Please understand that this is an experiment. It won't break the
>> internet.

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

If this all works well then obviously the next step is thinking about 
permanent WKAs. Or hopefully there will be a widely implemented 
alternative by then, so permanent WKAs aren't needed.

> How do you plan to migrate from a successful 6bone experiment to
> production in "real" IPv6 space?

Publish the new addresses, wait a while, remove the old ones. Same as 
all use of 6bone address 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
> services?

Tell them to use well known NAMES instead. Which is exactly the way in 
which DNS resolvers are unique: you need to know their addresses rather 
than their names.