Subject: Re: national security

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 2 Dec 2003 21:27:55 +0100

> The post KP&Quest updates are a good example of what Govs do not want
> anymore.

I can't make this sentence out. Do you mean the diminish of KPNQwest?
In that case, please explain. And before you do: I probably know more
about KPNQwest than anyone else on this list with a handful of
exceptions that where all my colleagues doing the IP Engineering part
with me. Please go on...

> Consider the French (original) meaning of "gouvernance". For networks
> it would be "net keeping". Many ICANN relational problem would
> disappear.

Ok, enough of references to France/French/European. I am born and grown
up in Finland, I have more or less lived in Germany and the Netherlands
for 6-36 months, I live in Sweden since 9 years and I have a resident
in Switzerland. I have worked on building some of the largest Internet
projects in Europe and the largest pan-European networks. Even with
governments trying to meet their needs. So I should be the perfect
match of what you are trying to represent. And I just don't buy any of
your arguments. Sorry.

> What would be the difference if the ccNSO resulted from an MoU? It
> would permit to help/join with ccTLDs, and RIRs, over a far more
> interesting ITU-I preparation. I suppose RIRs would not be afraid an
> ITU-I would not be here 2 years from now.

As someone who is somewhat involved in the policy work of the RIRs, I 
really,
really, really want you to elaborate on this.

[Quotes rearranged]

> The complexity is that ICANN wants to be two conflicting things
 >(American and International) and to organize something multinational.

> Vint, you will never change that IANA is part of the Internet and
> Internet is the current solution of the world for its
> datacommunications. So IANA must be involved. ITU is the way govs
> cooperate in communications (data, telephone, TV, radio) and where
> they have so many mixed interests that they must be cautious (this is
> what protects us, the consumers). So ITU must be involved.
>
> If you are serious about becoming multinational, you must disengage
> from the US Gov. But IANA will never lose its US Flag without ITU. ITU
> will never develop an acceptable higher layers capacity (ITU-I) before
> long, without ICANN, ccTLD etc.
>
> So, how long will we have to wait for you to ally (and not to try to
> swallow) with ccTLDs and to sit down with Mr. Zao, stop WSIS worrying
> and permits jointly care about fostering development and innovation.

I just fail to see this. What is it with the ITU that will give us

	a) More openness? How do I as an individual impact the ITU process?
	b) More effectiveness and a faster adoption rate?
	c) A better representation of end-user needs?

> The lack of users networks. Multiorganization TLDs Jerry made
> introduced as a reality we started experiencing. Just consider that
> the large user networks (SWIFT, SITA, VISA, Amadeus, Mnitel, etc.)
> started before 85. OSI brought X.400. CERN brought the Web. But ICANN
> - and unreliable technology - blocks ULDs (User Level Domains).

To be honest, none of those networks are really large compared to the
Internet, or in terms of users and especially bandwidth to some of the
large providers.

And, yes, OSI brought X.400 - but I am not really sure what to make out
of that point...:-)

> I just note that you never cared about Consumers organizationsn, while
> a world e-consumer council would have given you the legitimacy of
> billions and the weight to keep Gov partly at large, and satisfied. A
> National Security Kit would then be one of the ICANN raisons d'être,
> keeping Govs happy.

I think that the national governments that are thinking they need
control over ICANN in order to handle a national emergency simply needs
to understand the problem better. There are non-US governments with
contingency planning that works without any of the I* organizations
being under the control of ITU. I just guess those have done a better
job.

- - kurtis -

---

From: Franck Martin <[email-masked]>
Date: 03 Dec 2003 15:12:19 +1200

On Wed, 2003-12-03 at 08:27, Kurt Erik Lindqvist wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

> 	c) A better representation of end-user needs?

ITU is worried like hell, because the Internet is a process that escapes
the Telcos. The telcos in most of our world are in fact governments and
governments/ITU are saying dealing with country names is a thing of
national sovereignty. What they most of the time fail to see, is that
most registry are willing to hand it over to the governments provided
they DO understand the issues, and not use DNS to empower telcos in more
exclusive licencing power.

ITU has been also misleading countries by making them think that DNS
issues will be solved at ITU meetings. I have been telling countries
that they must attend ICANN meetings and no other one. When this
happens, US corporations will have less power over ICANN and things will
be better.

on a side note, Vint/ICANN if you are reading this, the Pacific Islands
Chapter of the Internet Society will have its annual meeting in
September 2004 in Vanuatu. I think it is time you send some outreach
people to explain here, what the hell is ICANN and how you manage a DNS.
(www.picisoc.org). Vint, wanna come? Port Vila, is a very very nice
place...

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 3 Dec 2003 09:21:24 +0100

On onsdag, dec 3, 2003, at 04:12 Europe/Stockholm, Franck Martin wrote:

> ITU is worried like hell, because the Internet is a process that 
> escapes the Telcos. The telcos in most of our world are in fact 
> governments and governments/ITU are saying dealing with country names 
> is a thing of national sovereignty. What they most of the time fail to 
> see, is that most registry are willing to hand it over to the 
> governments provided they DO understand the issues, and not use DNS to 
> empower telcos in more exclusive licencing power.
>
> happens, US corporations will have less power over ICANN and things 
> will be better.
>
I agree and realize this. However, the let's take that argument out in 
the open and not hide it behind "national security". The countries I 
have worked with, do have national disaster plans that can handle a IP 
network completely cut off from the rest of the world. But those plans 
are made together with the industry, as today you can not have this 
type of planning without co-operation of the large, world wide 
companies. Even if the governments own and control many of the telcos 
of the world, the operation of the sub-sea cables that transport the 
traffic is mostly run by organizations they have no control over.

Best regards,

- - kurtis -

---

From: Dean Anderson <[email-masked]>
Date: Wed, 3 Dec 2003 16:00:29 -0500 (EST)

> exclusive licencing power.

I'm not sure that this is really the case with respect to assignment of
ccTLD registries. Though I can't personally vouch for this, I think all of
the ccTLD's have been handed to government designated representatives when
the governments asked. So I dispute the implied assertion that there is
present evidence of ICANN, IETF, or IANA involvement or interference in
political or governmental controls.

But of course, governments have the sovereign right to control the
communications of their citizens, and if the governments choose, can 'use
DNS to empower telcos in more exclusive licencing power'.  If governments
are concerned about information anarchy, they will undoubtedly bring it up
through the UN and through the ITU.  Or perhaps they will just employ
national firewalls like China did to block unwanted information.

		--Dean

---

From: jfcm <[email-masked]>
Date: Thu, 04 Dec 2003 14:41:56 +0100

At 09:21 03/12/03, Kurt Erik Lindqvist wrote:
>I agree and realize this. However, the let's take that argument out in the 
>open and not hide it behind "national security".

I regret such an agressiveness. I simply listed suggestions I collected to 
ask warning, advise, alternative to problems identified not from inside the 
internet but from outside. I was labelled as a topic of national security 
because it was to prepare a menting on national vulnerability to Internet. 
If it had been about a Web Information and Services Providers, or User 
Networks demands, it would have been the same

I expected warnings, advices, alternative propositions. If you need a long 
discssion among specialists to come with that, please do. I am only 
interested in an authorized outcome. And we will all thank you for that.
jfc

---

From: jfcm <[email-masked]>
Date: Thu, 04 Dec 2003 15:48:19 +0100

Dear Mr. Lindqvist,
I am afraid I do not understand some of the points you try to make. I will 
give basic responses, please do not hesitate to elaborate.

On 21:27 02/12/03, Kurt Erik Lindqvist said:
>about KPNQwest than anyone else on this list with a handful of exceptions 
>that where all my colleagues doing the IP Engineering part with me. Please 
>go on...

I am refering ("post" KPNQuest) to the reference management lesson ICANN 
gave concerning root management when the 66 ccTLD secondaries supported by 
KPNQuest were to be updated. NO one will forget at many ccTLDs, and Govs.

>match of what you are trying to represent. And I just don't buy any of

I suppose that you are living in a French speaking Switzerland part then. 
May be people there have not a common command of the XIIIth century French 
from North of France (where the word comes from) or from current Senegal 
administration (where the word is in current legal use)?

>really,really, really want you to elaborate on this.

Glad you do. I keep your entries to simplify the reading.

>    a) More openness? How do I as an individual impact the ITU process?

This is not the topic (I come initially from a national point of view) and 
not to disuss but to listen.

But this is also an IETF separted issue. As deeply involved for years in 
@large issues (ICANN) and far longer political, public, coporate, 
technology development network issues and for having shared for some years 
in the ITU process (at that time CCITT), I think I will say "Yes".

1. As a user I have no impact on IETF ICANN. Not even do not get heard.
2. but (and with a big "but" unlil ITU adapts and created an "I" sector for 
us) ITU has the structures and procedures (Focus Groups and Members called 
meetings) just to do that.

You may have studied/shared in the WSIS and observed the way it works?

>    b) More effectiveness and a faster adoption rate?

Probably yes. For a simple reason. Internet is just another technology to 
support users data communications needs. I may find faster, better; 
parallel solutions else where. Competition fosters speed and quality or 
death. As a user I am darwinian about the process I use.

>    c) A better representation of end-user needs?

Certainly. This is a recurring issue. Quote me the way IETF listen to 
end-users needs. I have been flamed enough as a user representative to know 
it. And don't tell me "who do you represent?" or I will bore everyone 
responding. This thread show it. As a user I rose a question. Responses:

- question are disputed. I learned a long ago that questions are never 
stupid, but responses may be.
- question asked back to me: who are you. I appreciate that you may warn me 
about KPNQuest to spare us a trolls response. But I wander why the author 
would have any impact on a new question.

>Internet, or in terms of users and especially bandwidth to some of the

I agree. But I fail to see howit relates to the point?

My point is that SWIFT should have been able to become .swift for a very 
long. That .bank was denied to the World Bank Association and that SITA was 
given a try with .aero.

So we can technically compare the capacity of Internet to support the needs 
of a very, very old network like SITA. It does seem to be very appealing on 
the air transportation community. Never saw any ad for "aerolinas.aero" yet 
howver the mnemonic interest.

>And, yes, OSI brought X.400 - but I am not really sure what to make out of 
>that point...:-)

This is IETF speaking. SMTP brought us spam. :-)

What we are looking for are good solutions. X.400 architecture is not bad. 
The rest is ...odd. But did today someone find a solution for e-mail. I am 
working on something "above" - just to keep me abreast - if you have some 
French you cast a glance at http://weemail.org . This is a complex issue.

>being under the control of ITU. I just guess those have done a better

I suppose you misundertood the point. I am not sure of your point either, 
so I prefer you elaborate. Who could be fool enough to want to take control 
over ICANN? Even the USG cannot od it :-)

BTW it is a complex problem to discuss such issues in American language (or 
more in broken basic American as I do). Because the only word used is 
"control" which may mean many things, but is certainly totally foreign to 
the governance of a distrubited network.

So it can only apply to one very very particular point which is the White 
House relations with the NTIA. Everywhere else relations are much more 
complex.

As a European citizen yourself you konw the meaning of the "concertation" 
Eurospeak word which means something complex, precise and efficient in that 
area, which had no equivalent in English but that the English inherited 
subsidiarity principle made a necessity, after the Maastricht Treaty.

Take care.
jfc

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 4 Dec 2003 19:59:00 +0100

>> I agree and realize this. However, the let's take that argument out 
>> in the open and not hide it behind "national security".
>
> I regret such an agressiveness. I simply listed suggestions I 
> collected to ask warning, advise, alternative to problems identified 
> not from inside the internet but from outside.

Why don't you simply go inside and find out? There is nothing like 
first hand knowledge!

> I was labelled as a topic of national security because it was to 
> prepare a menting on national vulnerability to Internet. If it had 
> been about a Web Information and Services Providers, or User Networks 
> demands, it would have been the same

I know a number of countries that have looked at this from a national 
perspective. None of them have argued that the ITU is the solution. On 
the contrary, the distributed control of the Internet is a good value.

> I expected warnings, advices, alternative propositions. If you need a 
> long discssion among specialists to come with that, please do. I am 
> only interested in an authorized outcome. And we will all thank you 
> for that.

What the collective Internet thinks is documented largely through the 
IETF process, or related organizations. I think that the issues you are 
trying to raise are already answered at any point in history as being a 
reflection of the current set of standards.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 4 Dec 2003 22:00:49 +0100

> I am refering ("post" KPNQuest) to the reference management lesson 
> ICANN gave concerning root management when the 66 ccTLD secondaries 
> supported by KPNQuest were to be updated. NO one will forget at many 
> ccTLDs, and Govs.

I was there when KPNQwest went down. I think I have concluded that what 
you are referring to was a machine called ns.eu.net. That machine has a 
history that goes back to the beginning of the Internet in Europe. 
Through mergers and acquisitions it ended up on the KPNQWest network. 
It was secondary for a large number of domains, including ccTLDs. When 
KPNQwest down, the zone content and address block was transfered to 
RIPE NCC. As far as I can tell it is still there. TLDs where asked to 
move away from the machine over time.

As a matter of fact, several studies the year before KPNQwest went 
down, pointed out the problem with having all the worlds TLDs using 
just a few machines as slave servers. However, the DNS is designed to 
work fine even with one slave not reachable. So even if ns.eu.net would 
have gone off-line abruptly, which it never did, people got, and 
apparently still have, plenty of time to move. I think this incident 
clearly shows the robustness of the current system, more than anything 
else.

> This is not the topic (I come initially from a national point of view) 
> and not to disuss but to listen.

> But this is also an IETF separted issue. As deeply involved for years 
> in @large issues (ICANN) and far longer political, public, coporate, 
> technology development network issues and for having shared for some 
> years in the ITU process (at that time CCITT), I think I will say 
> "Yes".
>

IETF and ICANN in this prospect are two completely different 
organizations and processes. In IETF, you are making yourself heard. 
Quite a lot actually.

> 2. but (and with a big "but" unlil ITU adapts and created an "I" 
> sector for us) ITU has the structures and procedures (Focus Groups and 
> Members called meetings) just to do that.
>

It certainly doesn't strike me as open at least. I have read the 
following : http://www.itu.int/wsis/participation/accreditation.html. 
An organization where I have to apply for accreditation doesn't sound 
open to me. Actually I am not even sure what WSIS expect as input. To 
me it seems as a forum for governments to be seen. With the hope that 
they will have a forum where they can raise issues to other governments.

What I am missing is a) The input of the professionals b) How they 
expect to use any eventual output.

Again, I fail to see what the ITU process gives that have a clear 
advantage over the current IETF process. And as said, there are also 
governments who have come to understand this and learnt how to deal 
with the IETF process at the same time as making contingency planning.

> Probably yes. For a simple reason. Internet is just another technology 
> to support users data communications needs. I may find faster, better; 
> parallel solutions else where. Competition fosters speed and quality 
> or death. As a user I am darwinian about the process I use.

So you are saying that the ITU will provide better standards at fast 
speed? That has most certainly not been the case before...

> end-users needs. I have been flamed enough as a user representative to 
> know it. And don't tell me "who do you represent?" or I will bore 
> everyone responding. This thread show it. As a user I rose a question. 
> Responses:

The IETF makes decisions by rough consensus. If you have a point that 
is valid enough, you will get enough people to support you. If not, 
life goes on.

> stupid, but responses may be.

No, but the question might tell a lot about who you are and what your 
motives are.

> - question asked back to me: who are you. I appreciate that you may 
> warn me about KPNQuest to spare us a trolls response. But I wander why 
> the author would have any impact on a new question.

Knowing peoples background is always helpful in understanding a 
discussion.

> My point is that SWIFT should have been able to become .swift for a 
> very long. That .bank was denied to the World Bank Association and 
> that SITA was given a try with .aero.
>
> So we can technically compare the capacity of Internet to support the 
> needs of a very, very old network like SITA. It does seem to be very 
> appealing on the air transportation community. Never saw any ad for 
> "aerolinas.aero" yet howver the mnemonic interest.

I just fail to see what advantage that .swift will give over swift.org 
or swift.com etc...

> I suppose you misundertood the point. I am not sure of your point 
> either, so I prefer you elaborate. Who could be fool enough to want to 
> take control over ICANN? Even the USG cannot od it :-)

you said that ICANN should have given them a Security Kit. I say it's 
more or less there. And is use.

- - kurtis -

---

From: Franck Martin <[email-masked]>
Date: 05 Dec 2003 10:44:00 +1200

> clearly shows the robustness of the current system, more than anything 

There are now organisations installing root servers in all countries
that want one. If you are operating a ccTLD, you may want have sitting
next to your machines a root server, so if the national Internet link
goes down (something major but not impossible when many countries have
only one link to the Internet) the system still works for all the
national domain names...

This is a not a very well known fact, and I stumbled upon it recently
after wanting to complain that root servers where only in developed
countries.

Oh, btw to install a root server, any PC will do, it is not something
difficult as it carries only a couple of hundred records (200 countries
and a few gTLDs), not the millions of a .com.

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Franck Martin <[email-masked]>
Date: 05 Dec 2003 12:37:36 +1200

On Fri, 2003-12-05 at 12:16, Suzanne Woolf wrote:

> On Fri, Dec 05, 2003 at 10:44:00AM +1200, Franck Martin wrote:
> We (ISC) are widely anycasting f.root-servers.net. Several of the
> other operators of root nameservers have begun to anycast their
> servers as well, or announced plans to do so.
> 
> Is this what you meant? If not, could you elaborate?

Yes this is what I mean

> It's hard to quantify what "developed" means in this context. Our
> anycast f-root systems, for example, do need some infrastructure
> around them in order to be useful, but we have anycast clusters in
> over a dozen locations, most outside of the G8. See
> f.root-servers.org.

Well just use the LDS index of the UN if you are in doubt, but we are
not here in any contest... Outside the G8 is "something". Yes they do
need some infrastructure that you may not find in developing country...
but then see my last point...

> Operationally, this is a dangerous half-truth. It may be the case that
> you can run a nameserver that believes it is authoritative for the
> root zone and will answer for it in this way. But under real world
> conditions (significant numbers of queries, possibility of DDoS or
> other attack, etc.) this is far from adequate.
> 

This is not a dangerous half-truth, It has to be demystified. Let's take
the example of a country like Tonga. A simple PC will do for them
because the number of Internet Users there is may be about a 1000
people. With anycast properly set up only the packet of that country
will reach the local root-server (proximity), so it is unlikely to be
under heavy load with a 1000 of people on the Internet there...

Finally before a root-server is installed somewhere, someone will do an
assessment of the local conditions and taylor it adequately. I want
countries to request installation of root servers, and I know about 20
Pacific Islands countries that need root-servers in case their Internet
link goes dead.

cf www.picisoc.org if you want to join us...

> 
> thanks,
> Suzanne
> 
> 
> ============
> Suzanne Woolf				+1-650-423-1333
> Senior Programme Manager, ISC		
> 
> 		** Fortune favors the prepared mind **

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Paul Vixie <[email-masked]>
Date: 05 Dec 2003 01:53:16 +0000

[email-masked] (Franck Martin) writes:
> the example of a country like Tonga. A simple PC will do for them because
> the number of Internet Users there is may be about a 1000 people. With
> anycast properly set up only the packet of that country will reach the
> local root-server (proximity), so it is unlikely to be under heavy load
> with a 1000 of people on the Internet there...

my experience differs.  when a root name server is present it has to be
fully fleshed out, because if it isn't working properly or it falls over
due to a ddos or if it's advertising a route but not answering queries,
then any other problem will be magnified a hundredfold.  doing root name
service in a half-baked way is much worse than not doing it at all, since
over time the costs of transit to a good server will be less than the costs
of error handling and cleanup from having a bad one.

moreover, your statement "only the packet(s) of that country will reach the
local root server" is presumptive.  under error conditions where transit
is leaked, such a server could end up receiving global-scope query loads.
in our current belt-and-suspenders model, we (f-root) closely monitor our
peer routing, AND we are massively overprovisioned for "expected" loads,
since a ddos or a transit-leak can give us dramatically "unexpected" loads.

if you know someone who is willing to provision a "root" name server without
a similar belt and similar suspenders, then please tell them to stop.

> cf www.picisoc.org if you want to join us...

on a connectivity island (which might be in the ocean or it might just be
a campus or dwelling), the way to ensure that local service is not disrupted
by connectivity breaks is to make your on-island recursive name servers
stealth slaves of your locally-interesting zones.  in new zealand for
example it was the custom for many years to use a forwarding hierarchy
where the nodes near the "top" were stealth slaves of .NZ, .CO.NZ, etc.
that way if they lost a pacific cable system they could still reach the
parts of the internet which were on the new zealand side of the break.

using a half-baked root-like server to do the same thing would be grossly
irresponsible, both to the local and the global populations.

note that f-root, i-root, j-root, k-root, and m-root are all doing anycast
now, and it's likely that even tonga would find that one or more of these
rootops could find a way to do a local install.  (c-root is also doing
anycast but only inside the cogent/psi backbone; b-root has announced an
intention to anycast, but has not formally launched the programme yet.)

---

From: Dean Anderson <[email-masked]>
Date: Thu, 4 Dec 2003 21:59:14 -0500 (EST)

On 5 Dec 2003, Paul Vixie wrote:

> then any other problem will be magnified a hundredfold. 

It depends on the "problem profile" you working to avoid.

> doing root name service in a half-baked way is much worse than not doing
> it at all, since over time the costs of transit to a good server will be
> less than the costs of error handling and cleanup from having a bad one.

This could be true, but irrelevant. It depends on the costs of transit and 
cleanup.  Transit to a remote island could be very expensive, while labor 
to cleanup any problems might be very cheap.

> local root server" is presumptive.  

Not necessarilly.  If the country operates a root server that is only
accessible from that country, that is, only in the preloaded in the caches
of that countries' nameservers, then the 'presumption' is true.  The list
of root nameservers is determined by the lists that are pre-loaded into
other nameservers, not by the 'dig . ns' query on a real root.  You could
have hundreds of root slaves, but only a small number of truly global root
servers without any problems at all.  This would probably be a good thing 
for the global servers.  

> under error conditions where transit is leaked, such a server could end
> up receiving global-scope query loads. in our current
> belt-and-suspenders model, we (f-root) closely monitor our peer routing,
> AND we are massively overprovisioned for "expected" loads, since a ddos
> or a transit-leak can give us dramatically "unexpected" loads.

This is a feature that is specific to your anycast setup.  Simpler,
non-anycast setups wouldn't have this problem.

> a similar belt and similar suspenders, then please tell them to stop.

Are all the roots doing anycast?  I've run private roots without any
problems, and have experienced significant improvements for doing so. (see
below)

> parts of the internet which were on the new zealand side of the break.

This assumes that you are mixing authoritative and caching nameservers. 
Something that many people (including you) advise against.

Operating a root nameserver is much easier.  Obviously, in the case of an 
island or small country that has only one connection, or perhaps one 
network center, a DDOS that affects the local root is going to affect all 
connectivity. Their only option may be to drop connectivity.  Actual war 
could have the same impact, due to broken communications line. A local 
root in each country is probably a good idea.

I've also found that when setting up non-connected laboratory networks, it
is better to have a 'lab root' server, that acts like a root, since
machines in the lab can't access real root servers.  This greatly enhances
performance in the case where a wrong, or just non-lab domainname is typed
in, since you can get an nxdomain back right away instead of waiting for a
timeout as the root servers at tried.

---

From: jfcm <[email-masked]>
Date: Fri, 05 Dec 2003 04:32:37 +0100

Paul,
1. all this presumes that the root file is in good shape and has not been 
tampered.
     How do you know the data in the file you disseminate are not polluted 
or changed?
2. where is the best documentation - from your own point of veiw - of a 
root server organization.
thank you
jfc

---

From: Franck Martin <[email-masked]>
Date: 05 Dec 2003 16:12:06 +1200

>      How do you know the data in the file you disseminate are not polluted 
Because somebody will complain... ;)

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 5 Dec 2003 07:12:37 +0100

On torsdag, dec 4, 2003, at 23:44 Europe/Stockholm, Franck Martin wrote:

> that want one.

I am the CEO of one of those organizations.

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Dec 2003 12:38:10 +0100

On 5-dec-03, at 1:37, Franck Martin wrote:

> Finally before a root-server is installed somewhere, someone will do 
> an assessment of the local conditions and taylor it adequately. I want 
> Pacific Islands countries that need root-servers in case their 
> Internet link goes dead.

Might I suggest that there is a much easier way to do this: if the 
constituency for such a root server is so small and so homogenous (= 
they all share a single link to the rest of the net) then it would be 
much simpler for all of these users to simply share a single set of 
nameservers, which can then all be primary or secondary for all the 
domains used locally. This allows communication to continue even if the 
root servers are unreachable AND it allows users to register domain 
names under any TLD they like.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 5 Dec 2003 11:16:45 -0500 (EST)

Indeed, this is what they do when the agree to put the "national" root
nameservers in their own nameserver root configs.  It is far easier to
have per-country stealth root slaves than it is to make every nameserver
the stealth slave of every other domain in that country.  

When that country is isolated from the rest of the net, (due to single
connection failure, multiple connection failure, war, etc), then they
still have nameservice for their CCtld and its delegations, and those of
whatever other countries they remain connected to.

Stealth root slaves are such a far better solution, in terms of
configuration, maintenance, and scaling than configuring every nameserver
to be a stealth slave of every other domain.  Imagine the difficulty of
doing that...  Even a small country with a few tens of thousands of
domains makes that unrealistic.  Yet a stealth root is comparably easy:
You just tell your nameserver operators to configure in the IP addresses
for your national root servers, instead of the "official" root servers.  
Now all you have to do is keep that set operating, which isn't that hard,
and can be done even if the country becomes isolated from the world net,
and the official nameservers.

Indeed, it is probably sensible for ISPs to do the same.  This would keep
things working internally in the event of an effective isolation due to a
DOS attack, for example.

		--Dean

---

From: Matt Larson <[email-masked]>
Date: Fri, 5 Dec 2003 12:41:18 -0500

On Fri, 05 Dec 2003, Paul Vixie wrote:
> rootops could find a way to do a local install.

Apologies for taking this thread perhaps even further off-topic.

VeriSign is planning to anycast J root beyond the 13 sites where it is
(or will be shortly) co-located with the com/net name servers.
Currently under-served areas are particularly appealing as possible
locations.  Briefly, we'll supply the hardware for a J root instance
and manage it if you supply the space, power and bandwidth.  No fees
are involved.  Interested ISPs should please contact me privately.

Matt
--
Matt Larson <[email-masked]>
VeriSign Naming and Directory Services

---

From: jfcm <[email-masked]>
Date: Fri, 05 Dec 2003 21:49:38 +0100

>Because somebody will complain... ;)

Dear Franck,
I am afraid you are right. This leaves however a few questions such as:
1. what/who does say he is right?
2. he complains to who?
3. and then what?
4. if a decision is taken how the pollution will be corrected? Just waiting 
for ttl (and may be people or businesses) to die?
5. who will the hurt parties sue?
6. are they insurred?
7. who pays for the insurrance?
etc.

I understand last time somebody complained, he called Ira Magaziner and 
they solved the case in calling on Joe Sims and subsequently creating ICANN.
jfc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Dec 2003 23:18:10 +0100

> the stealth slave of every other domain in that country.

I don't think this stealth business is a very good idea. If you want a 
root servers somewhere, use anycast. That means importing BGP problems 
into the DNS, which is iffy enough as it is. But for a small network 
island just having a single set of resolvers and make sure those have 
all the needed information isn't a huge deal. Obviously such a place 
doesn't have a huge number of ISPs so the number of DNS servers will be 
quite limited in the first place.

> Yet a stealth root is comparably easy:

So I have to trust these fake roots a 100%: not only that they don't 
change the root zone, but also that they're always up to date and never 
down. Tall order. An official anycast setup is much better: updates are 
done the way they should be (last year when I wrote an article I 
checked this: there is no policy anywhere on access to the root 
zonefile. You can download it through FTP or even do a zone transfer in 
a few places, but nothing official) and when your local root clone is 
down there should be at least 12 others elsewhere.

> things working internally in the event of an effective isolation due 

I think what we need to really solve this is a redesign of the DNS, as 
the way it is now it breaks a fundamental design principle of the 
internet: when two nodes have reachability, they should be able to 
communicate, regardless of what else is (un)reachable. (I'm not 
volunteering, though.)

I've been in a situation where root servers where unavailable for the 
better part of a day, and it's pretty frustrating to see your resolver 
cache disappear over tiem so you can no longer reach places to which 
you still have connectivity.

---

From: jfcm <[email-masked]>
Date: Sat, 06 Dec 2003 16:15:57 +0100

Iljitsch,
have we figures about the frequency of changes in the root file? Always 
wanted to check that, but since it is of interest on a substantial duration 
never did. The only serious figure I have is that ICANN decided that three 
months and half to update major ccTLD secondaries was OK (after KPNQuest).
thank you.
jfc

On 23:18 05/12/03, Iljitsch van Beijnum said:
>Content-Transfer-Encoding: 7bit
>
>island just having a single set of resolvers and make sure those have all 
>the needed information isn't a huge deal. Obviously such a place doesn't 
>have a huge number of ISPs so the number of DNS servers will be quite 
>limited in the first place.
>
>done the way they should be (last year when I wrote an article I checked 
>this: there is no policy anywhere on access to the root zonefile. You can 
>download it through FTP or even do a zone transfer in a few places, but 
>nothing official) and when your local root clone is down there should be 
>at least 12 others elsewhere.
>
>I think what we need to really solve this is a redesign of the DNS, as the 
>way it is now it breaks a fundamental design principle of the internet: 
>when two nodes have reachability, they should be able to communicate, 
>regardless of what else is (un)reachable. (I'm not volunteering, though.)
>
>cache disappear over tiem so you can no longer reach places to which you 
>still have connectivity.
>
>
>

---

From: Dean Anderson <[email-masked]>
Date: Sat, 6 Dec 2003 17:04:03 -0500 (EST)

I think there are three confluences which tend to support the notion of 
national root nameservers:

1) Root Server scalability
2) Foriegn distrust of US control on the internet
3) Isolation due to technical or political issues.

On Fri, 5 Dec 2003, Iljitsch van Beijnum wrote:

> into the DNS, which is iffy enough as it is. 

That seems to argue against anycast...

> But for a small network island just having a single set of resolvers and
> make sure those have all the needed information isn't a huge deal.
> Obviously such a place doesn't have a huge number of ISPs so the number
> of DNS servers will be quite limited in the first place.

Its the same "deal" as distributing the "official" root nameserver
updates.  Some people don't pay attention to this until they can't get
nameservice to work.  Its a problem, but it isn't made better or worse.

> > Yet a stealth root is comparably easy: You just tell your nameserver
> > operators to configure in the IP addresses for your national root
> > servers, instead of the "official" root servers.
> 

They aren't exactly fake. They are just not listed by the "dig . ns"  
query, so they aren't technically authoritative. Though, I suppose they
could be--I'm just assuming they aren't.  As far as trust goes, since they
are run by your government, yes, you can trust them.  Since these zones
don't change much, they can be updated by zone transfers, or by other
official distribution.  As far as reliability goes, that's why you have 
more than one. And you scale it just like any other part of 
infrastructure.

Anycast doesn't make this job easier--it makes it harder. An Anycast
server can't easily do a zone transfer from itself.  This is just another
complication of running anycast.  Anycast is just a means of scaling up 
server infrastructure.  There are other methods of scaling.  Anycast 
doesn't particularly match the political interests.

I also don't conceive of a single national stealth server. I assume that
they may be many. Probably at least 2, and certainly more depending on the
size of the country.  The US would probably have a lot.

> > Indeed, it is probably sensible for ISPs to do the same.  This would
> > keep things working internally in the event of an effective isolation
> > due to a DOS attack, for example.
> 

I agree completely, but I don't think anything needs to change other than
management of existing services.  The internet has to continue to work
when it is partitioned, regardless of the reasons for the partitioning.
Those reasons could be technical, or political.  And the internet should
then just work when its glued back together again.  But address and DNS 
delegations are hierarchical, so there is not reason that this can't be 
done.

> you still have connectivity.

This is fixed by stealth slaves at large ISPs.  Small ISPs, if isolated 
probably don't have enough customers to really care about getting to the 
other customers. But this might not be true for large ISPs, and might not 
be true of islands and small countries.  A small island in the Pacific 
might have several ISPs but only one underwater cable. If the cable is 
cut, they could be isolated for a while. But there is no reason they 
shouldn't be able to get to other sites that are on the island.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 7 Dec 2003 00:19:20 +0100

> That seems to argue against anycast...

If there were 65 actual root servers, I would very much prefer the 
situation where I could contact each and any one of those, rather than 
a subset of 13 that are chosen by a protocol that was NOT designed for 
this. (Selecting the "best" path is pretty much an after thought in 
BGP: the RFC doesn't even bother giving suggestions on how to do this.) 
But the DNS protocol has problems supporting 65 (or 45 or even 25) 
individual root server addresses, it's either no more than around 13 
individual servers or a larger number of anycasted ones.

I don't have a problem with some controlled anycasting, but the root 
operators shouldn't go overboard. For instance, the .org zone is only 
served by two addresses, which are then anycast. There have been 
reports from people who were unable to reach either of these addresses 
when there was some kind of reachability problem. The people managing 
the .org zone are clearly lacking in responsibility by limiting the 
number of addresses from which the zone is available without any good 
reason.

The situation that must be avoided is where all or most root servers 
seem to be in the same location from a certain viewpoint, as a BGP 
black hole towards that location will then make them all unreachable. I 
would prefer it if several root servers weren't anycast at all, just to 
be on the safe side.

(And some IPv6 roots wouldn't be bad either.)

> nameservice to work.  Its a problem, but it isn't made better or worse.

The difference is that official root servers are updated through the 
official channels, which I have no reason to distrust. Having a stealth 
root server means you can't listen to the real root servers anymore 
(because then you'd have a 13/14th chance of learning the list of 
official root servers and forgetting about the stealth one when a 
resolver starts) which is a big fat single point of failure.

>> So I have to trust these fake roots a 100%:

> could be--I'm just assuming they aren't.

Ok, let's not debate the word "fake".

> As far as trust goes, since they
> are run by your government, yes, you can trust them.

Their intentions, maybe. Their DNS operating prowess, I don't think so.

> Since these zones
> don't change much, they can be updated by zone transfers,

You missed the point in one of my previous messages: there is no 
officially supported way to do zone transfers for the root. This can 
stop working at any time.

> or by other official distribution.

Which I don't think there is either.

> management of existing services.

How is that agreeing with my point that we need a redisign (if we want 
to solve this)???

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 07 Dec 2003 00:40:43 +0100

have we figures about the frequency of changes in the root file?

The serial # changes twice a day. The contents hardly as far as I
can see.

    Always wanted to check that, but since it is of interest on a
    substantial duration never did.

It is very easy to check. Just pull over the zone file at a regulary
base and do a diff.

    The only serious figure I have is that ICANN decided that three
    months and half to update major ccTLD secondaries was OK (after
    KPNQuest).

Document your figures.

Note that ns.eu.net was never dead, so I wonder what the relevance
is anyway.

	jaap

PS. I wonder how soon someone will tell me I shouldn't be feeding ...

---

From: Bill Manning <[email-masked]>
Date: Sat, 6 Dec 2003 16:03:41 -0800 (PST)

% 
%     have we figures about the frequency of changes in the root file?
% 
% The serial # changes twice a day. The contents hardly as far as I
% can see.

	other contents change about three times a week.

% 	jaap
% 
% PS. I wonder how soon someone will tell me I shouldn't be feeding ...
	
	you shouldn't, not w/out a permit.  :)

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Paul Vixie <[email-masked]>
Date: 07 Dec 2003 01:26:26 +0000

[email-masked] (Iljitsch van Beijnum) writes:

> ... (Selecting the "best" path is pretty much an after thought in 

congradulations, you're the millionth person to think that was an oversight.

> operators shouldn't go overboard.

i don't think you will ever meet a more conservative bunch of people, so, OK.

> For instance, the .org zone is only served by two addresses, which are
> then anycast. There have been reports from people who were unable to
> reach either of these addresses when there was some kind of reachability
> problem. The people managing the .org zone are clearly lacking in
> responsibility by limiting the number of addresses from which the zone is
> available without any good reason.

see the icann agreements to find out how much of this was ultradns's choice.

> would prefer it if several root servers weren't anycast at all, just to 

that's exactly what's likely to continue happening.  diversity is good.

> (And some IPv6 roots wouldn't be bad either.)

there are several.  see www.root-servers.org.  (now if we can just advertise.)

> officially supported way to do zone transfers for the root. This can stop
> working at any time.

indeed, it's been downhill ever since 10.0.0.53 went away.  now it's chaos.
-- 
Paul Vixie

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 7 Dec 2003 13:21:04 +0100

> congradulations, you're the millionth person to think that was an 

I don't think this is an oversight, I'm pretty sure this was 
intentional. However, since in practice the BGP best path selection 
algorithm boils down to looking at the AS path length and this has the 
tendency to be the same length for many paths, BGP is fairly useless 
for deciding the best path for even low ambition definitions of the 
word.

> i don't think you will ever meet a more conservative bunch of people, 

Excellent.

> see the icann agreements to find out how much of this was ultradns's 

Hm, nothing about this in http://www.icann.org/tlds/agreements/org/. In 
fact, it talks about a maximum of 13 servers in some places. Not that 
it matters much who's bright idea it was.

> there are several.  see www.root-servers.org.  (now if we can just 

Just for fun, I cooked up a named.root file with only those IPv6 
addresses in it. This seems to confuse BIND such that its behavior 
becomes very unpredictable. And only 2 of the 4 v6 addresses are 
reachable as one isn't advertised at all and the other as a /48 which 
are heavily filtered.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 07 Dec 2003 19:52:25 +0000

> > ... oversight.
> for deciding the best path for even low ambition definitions of the word.

that depends on what you want to use it for.  not all routes are transitted.
for f-root we do limited-horizon peering in all locations outside the SFbay 
area, and bgp's path selection machinery almost never has any work to do.

i'm a little more worried about j-root which receives transit everywhere and
is somewhat at the mercy of not only its own ISP's but other ISP's as well.
however, "diversity is good".  i'm glad that different roots are different.

> Just for fun, I cooked up a named.root file with only those IPv6 addresses
> in it. This seems to confuse BIND such that its behavior becomes very
> unpredictable. 

hmmm.  that configuration works fine for me here.

>               And only 2 of the 4 v6 addresses are reachable as one isn't
> advertised at all

those issues are probably going to influence which AAAA RR's go into the
root-servers.net zone and the named.cache files.

>                   and the other as a /48 which are heavily filtered.

not according to the RIR's.  at least in ARIN's case the micro-allocation
policy seems to have met with approval by the membership, which is why we're
using a /48 for f-root.  if this is a bad idea because all kinds of ISP's
won't be accepting such routes even though they seem to be grouped together
in a place where a different prefix filter could be employed, then you ought
to tell the RIR's this and get the microallocation policies altered or torn
down.  (i personally don't think a /35 route with just one host in it makes
much sense, but i guess ipv6 has a lot of space to burn on stuff like this.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 7 Dec 2003 22:23:26 +0100

On 7-dec-03, at 20:52, Paul Vixie wrote:

>> addresses

> hmmm.  that configuration works fine for me here.

Ok... But does it also do anything useful? My understanding of what 
happens when a resolver starts is that it asks a root server for the 
list of root servers and then uses that list from then on. Since this 
list only contains IPv4 addresses currently that initial query is also 
the last one done over IPv6.

> down.

What I see is this:

http://www.ripe.net/ripe/docs/ipv6-policies.html#minimum_allocation

which doesn't mention micro allocations and is newer than this:

http://www.arin.net/policy/2001_3.html

ARIN does maintain a list of individual micro allocations at 
http://www.arin.net/registration/ipv6/micro_alloc.html but they don't 
bother saying which address blocks future ones will be coming from.

I think this stuff is too important to leave up to individual RIRs.

> (i personally don't think a /35 route with just one host in it makes
> much sense,

Agree.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 07 Dec 2003 21:36:26 +0000

> Ok... But does it also do anything useful? My understanding of what happens
> when a resolver starts is that it asks a root server for the list of root
> servers and then uses that list from then on. Since this list only contains
> IPv4 addresses currently that initial query is also the last one done over
> IPv6.

yes, that's how BIND works.  other implementations (DJB or uSoft) may differ.

> > not according to the RIR's.  at least in ARIN's case the
> > micro-allocation policy seems to have met with approval by the
> > membership, which is why we're using a /48 for f-root.  if this is a
> > bad idea because all kinds of ISP's won't be accepting such routes
> > even though they seem to be grouped together in a place where a
> > different prefix filter could be employed, then you ought to tell
> > the RIR's this and get the microallocation policies altered or torn
> > down.
> ...

i'm sure there's a correct forum for you to state your concerns.  is this it?

---

From: Franck Martin <[email-masked]>
Date: 08 Dec 2003 11:03:27 +1200

> quite limited in the first place.

I'm a little bit confused here, but I'm starting to get the ideas...

In the Pacific Islands:
http://map.sopac.org/tiki/tiki-map.phtml?mapfile=pacific.map&zoom=1&size=400&Redraw=Redraw&minx=110&miny=-67.6&maxx=230&maxy=52.6&Topography=1&EEZ=1&12+miles+zone=1&Country+Names=1

Countries there have about in general 1000 Internet users, and one ISP
usually some 2 or 3 max...

> communicate, regardless of what else is (un)reachable. (I'm not 

Are we going to something like the Kaza protocol (or peer sharing). The
DNS know their environement and other DNS around and get the ones that
are available to solve ANY query?

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Dean Anderson <[email-masked]>
Date: Mon, 8 Dec 2003 10:14:40 -0500 (EST)

> individual servers or a larger number of anycasted ones.

I don't need any more than 13, and I would, were I director of some
country's telecom, much prefer that I had several within my borders. So
that argues for at least 3 * 190, or about 600+ root servers worldwide
(large countries like the US and China having more than 3).  Anycasting
probably isn't going to easily scale that large, and requires more
complexity, which makes thinks much harder at the lower end.

Also, anycasting doesn't work for TCP.  

> number of addresses from which the zone is available without any good 

A much larger number of root servers also tends to avoid this problem, and 
localize problems.  As someone pointed out, it is fast becoming the case 
that no one has enough knowledge of what's happening to understand the 
problems. Obviously, the solution is to make sure that problems are 
localized, and can be partitioned without bringing down the global or 
national infrastructure.

> would prefer it if several root servers weren't anycast at all, just to 

I agree.  It is easy to create a blackhole, or even a DDOS on an anycast 
address.  It is much harder to DDOS 600 IP addresses spread through some 
200 countries.

> resolver starts) which is a big fat single point of failure.

Err, no. The "root servers", from the point of view of a person in a given 
country, is the list given by the countries' telecom authority. Just like 
the SS7 point codes for that country.  There is no reason to distrust the 
FCC.  For the United States, they are the "official authority"

The official contents of the root zone is controlled by an international
commission.  This would be distributed to the root server operators by
some agreed channel:  FTP, Certified Letter, Diplomatic pouch, or carrier
pidgeon ;-)  The root zone is not very big.  It probably could be
distributed by carrier pidgeon. Exaggeration and humor aside, distribution
is not a big problem.

> Their intentions, maybe. Their DNS operating prowess, I don't think so.

Oh please. Root server operation is not that difficult.  The government is
responsible to find someone to run it competently.  But if their operators
are incompetent, they only affect that country. They would not be able to
affect other countries by their incompetence.

Other countries do not trust the US (to run things competently, fairly,
whatever)  The solution (if possible) is to distribute the responsibilty
to each country, so that mal intent or simple incompentence by another
country can't affect their infra-structure, and so that they can de-peer
with that country if they please.  And years later, if they reconnect,
then things should just work. (Cuba is a good example--Phone service to
the US was disconnected, and later reconnected).  My proposal meets these
objectives.  Anycasting does not.

> stop working at any time.

Well, there is obviously some (perhaps private) agreement amoung the
current operators on how to update the contents of the root.  This is but
a formality, since the root isn't large, and it changes infrequently.

> How is that agreeing with my point that we need a redisign (if we want 

I agree that a fundamental design principle is that when two nodes have
reachability, they should be able to communicate, regardless of what else
is (un)reachable.  We do not need to redesign DNS to achieve this.  All we
need to do is change the management of its operation.

		--Dean

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Dec 2003 11:19:38 -0500

> for deciding the best path for even low ambition definitions of the 

For the service aspects of F we're more concerned with reliability than 
performance. Recursive resolvers ask questions to the root relatively 
infrequently, and the important thing is that they have *a* path to use 
to talk to a root server, not necessarily that they are able to 
automagically select the instance with the lowest instantaneous RTT 
(and continue to find a root regardless of what damage might exist in 
the network elsewhere).

For example, local routing policies might lead a resolver in South 
Africa to select a path to 192.5.5.0/24 in California over the node in 
Johannesburg under normal operation. We hope, though, that in the event 
that the resolver becomes isolated from California, a path exists to 
Johannesburg which will allow F-root service to continue reliably (and, 
for example, to allow names under ZA corresponding to local, reachable, 
services to continue to resolve).

The selection of anycast node has more importance when you consider the 
other, non-service role of F, which is to sink attack traffic: we'd 
like to sink attack traffic as close to its source as possible. 
Fortunately the rough-hewn and clumsy hammer of BGP path selection 
seems good enough to attempt to attain that goal right now, since our 
routing policy generally leads people to favour a local node (peer) 
over a global node (transit) through application of pre-existing 
routing policy. This is a natural result of the common truth that 
peering paths are cheaper than transit ones.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Dec 2003 11:07:11 -0500

> Also, anycasting doesn't work for TCP.

Would you care to elaborate on "doesn't work"?

> address.  It is much harder to DDOS 600 IP addresses spread through 

It's arguably easier for a distributed attack to cause degrade the 
availability of a service bound to a unicast-reachable address than an 
anycast-reachable address. The former will tend to collect traffic 
along a progressively narrow funnel until congestion occurs; with an 
anycast target the pain is distributed over a set of funnels, and in 
general not all will experience the same degree (or any) pain, 
depending on the distribution and behaviour of the attacking nodes.

In a non-distributed attack anycast victims fare subtantially better 
(since non-select anycast targets are unaffected, and only suffer 
topological fallout from the node sinking the attack traffic).

Joe

---

From: Bill Manning <[email-masked]>
Date: Mon, 8 Dec 2003 11:17:36 -0800 (PST)

% > (i personally don't think a /35 route with just one host in it makes
% > much sense,
% 
% Agree.

	/35 routes are being discouraged in favor of /32 entries...
	4,064,000,000 addresses to ensure that just one host
	-might- have global reachability.  IMHO, a /48 is even 
	overkill...  :)

--bill

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Dec 2003 20:00:25 +0000

> 	4,064,000,000 addresses to ensure that just one host -might-
> 	have global reachability.  IMHO, a /48 is even overkill...  :)

i think the important points for ietf@ to know about are (a) that this
is an open issue, (b) that it's generally agreed that all the RIR's ought
to have the same rules regarding microallocations, and (c) exactly where
(as in what working group or mailing list or smoke filled room) the
discussion is being held.  for example, bill says above that "/35 routes
are being discouraged" and that's probably true but "by whom?" and "where?"

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Dec 2003 05:25:27 +0900

Joe Abley;

> automagically select the instance with the lowest instantaneous RTT (and 
> continue to find a root regardless of what damage might exist in the 
> network elsewhere).

I'm afraid F servers does not follow the intention of my original
proposal of anycast root servers.

The intention is to allow millions or trillions of root servers.

While you can rely on someone else's root server with the BGP
best path selection, it is a lot better to have your own
root server.

In addition, it is not necessary to have any hierarchy between
anycast servers at all, as long as there is a single source of
information. Hierarchy may be useful if a single entity manages
all the anycast root servers. However, you can manage your own.

Finally, using only a single address, F, does not provide any
real robustness.

						Masataka Ohta

---

From: Bill Manning <[email-masked]>
Date: Mon, 8 Dec 2003 12:43:33 -0800 (PST)

% > 	/35 routes are being discouraged in favor of /32 entries...
% > 	4,064,000,000 addresses to ensure that just one host -might-
% > 	have global reachability.  IMHO, a /48 is even overkill...  :)
% 
% i think the important points for ietf@ to know about are (a) that this
% is an open issue, (b) that it's generally agreed that all the RIR's ought
% to have the same rules regarding microallocations, and (c) exactly where
% (as in what working group or mailing list or smoke filled room) the
% discussion is being held.  for example, bill says above that "/35 routes
% are being discouraged" and that's probably true but "by whom?" and "where?"

	By ISPs, in conjunction w/ IETF and RIRs. Check the allocation
	policies.  I'll agree that (a) is valid,  there is little that
	is cast in stone.  (b) on the other hand, has any number of 
	legal implications... collusion, monopolies, etc. As for (c),
	check the RIR working groups and mailing lists, the V6OPS wg of the
	IETF and the IPv6 protocol wg.

-- 
--bill

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Dec 2003 05:57:57 +0900

Joe Abley;

> This may well be the case (I haven't read your original proposal).

The IDs have expired. I'm working on a revised one.

> Apologies if I gave the impression that I thought to the contrary.

No, no need of apologies.

> Fortunately there are twelve other root nameservers.

But, one should have one's own three root servers with different addresses.

						Masataka Ohta

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 8 Dec 2003 22:01:53 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Paul Vixie wrote:

> is an open issue, (b) that it's generally agreed that all the 
> RIR's ought to have the same rules regarding microallocations, and (c) 
> exactly where (as in what working group or mailing list or smoke filled room) the
> discussion is being held.  for example, bill says above that 
> "/35 routes are being discouraged" and that's probably true but "by 
> whom?" and "where?"

There are currently quite some ISP's who filter anything >/35.
Generally ISP's should be filtering on allocation boundaries.
Thus if a certain prefix is allocated as a /32, they should not
be accepting anything smaller (/33, /34 etc)

Checking http://www.sixxs.net/tools/grh/tla/all/

8<------------
The database currently holds 630 IPv6 TLA's.
Of which 18 (2.86%) are returned to the pool, 202 (32.06%) IPv6
TLA's didn't have a routing entry.
Thus 410 (65.08%) networks are currently announced.
0 (0.00%) only announced a /35 while they have been assigned a /32.
13 (2.06%) announce both their /32 and their /35.
- ------------>8

I have to add that there is an error here as 2001:dc0::/35 is in
the tables, but doesn't get picked up by the software, will be
fixing that soonish. Generally if you announce a /35 it will get
through to most ISP's. But we should be avoiding that. Currently
the ipv6 global routing table is quite small, but it could grow
quite large and when ISP's still don't filter correctly, or better
if ISP's don't aggregate it will explode and we will be needing
the follow up to BGP soon, which is more work for the IETF :)

As for which smoked filled room, this should be a task of the
RIRs, thus RIPE's IPv6 WG etc. but it usually takes place when
communicating between ISP's. Notice that many ISP's use Gerts list:
http://www.space.net/~gert/RIPE/ipv6-filters.html

I would applaud a generic /32 that is 'allowed' to being cut up
into multiple /48's for the purpose of critical infrastructure.
But please, keep it to 1 *documented* /32. That way people will
know that they will see more specifics from that prefix and that
they should be accepting it too.

Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 2001:7fa::/32)
are seen being announced in pieces too. Maybe these IX blocks, which
are common already could be used for assigning 'critical infra' from?

This is a RIR thing and should be discussed there (ipv6-wg cc'd).
The IETF though should ofcourse advise in all matters.

Greets,
 Jeroen

---

From: John Stracke <[email-masked]>
Date: Mon, 08 Dec 2003 16:06:42 -0500

Bill Manning wrote:

>% b) that it's generally agreed that all the RIR's ought
>% to have the same rules regarding microallocations, 
>
>	(b) on the other hand, has any number of 
>	legal implications... collusion, monopolies, etc.
>  
>
But this is a example where uniformity is desirable on technical grounds 
(i.e., if the policies aren't uniform, nobody will know how small they 
can afford to filter).  That's got to be legal, or no standards body 
would be safe.  Or do you think the participants in, say, the ipp WG are 
vulnerable to charges of colluding to drive competing printing protocols 
from the market?

-- 
/=====================================================\
|John Stracke      [email-masked]              |
|Principal Engineer|http://www.centive.com            |
|Centive           |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/

---

From: Zefram <[email-masked]>
Date: Mon, 8 Dec 2003 21:17:00 +0000

>	-might- have global reachability.  IMHO, a /48 is even 

Just wondering, as I have about IPv4 anycast allocations: why can't we
designate a block for microallocations, within which prefix length filters
aren't applied?  The number of routes in the DFZ is the same either way;
is there any technical reason why /64 or /128 prefixes, or /32 in IPv4,
can't be used?  I'm not a routing person, so apologies if this is somehow
unspeakably dumb.

-zefram

---

From: Gert Doering <[email-masked]>
Date: Mon, 8 Dec 2003 22:16:03 +0100

Hi,

> be accepting anything smaller (/33, /34 etc)

There is no commonly agreed-upon best practice for this yet.

We do *not* suppress more-specifics from those address blocks, as we
think it's a legitimate wish for certain networks to be multihomed,
and currently there is no other solution than to go for the pragmatic
approach, and just announce a /40 or even /48.

I agree that things that are more specific than a /48 should not be
out there.

[..]
> the follow up to BGP soon, which is more work for the IETF :)

If every holder of an AS will announce one prefix at maximum (which
should be doable by proper aggregation), the v6 BGP table would grow
to about 20.000 entries.  This is still manageable, although it would
kill my good old Cisco 2500 that still has a full v6 BGP table...

> they should be accepting it too.

As you cite my page, you will also know that it does not make a specific
recommendation on the subject of "filtering things between /35 and /48"...

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  57386  (57785)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Dec 2003 15:29:12 -0500

Joe

---

From: Bill Manning <[email-masked]>
Date: Mon, 8 Dec 2003 13:31:29 -0800 (PST)

% Bill Manning wrote:
% >	/35 routes are being discouraged in favor of /32 entries...
% >	4,064,000,000 addresses to ensure that just one host
% >	-might- have global reachability.  IMHO, a /48 is even 
% >	overkill...  :)
% 
% Just wondering, as I have about IPv4 anycast allocations: why can't we
% designate a block for microallocations, within which prefix length filters
% aren't applied?  The number of routes in the DFZ is the same either way;
% is there any technical reason why /64 or /128 prefixes, or /32 in IPv4,
% can't be used?  I'm not a routing person, so apologies if this is somehow
% unspeakably dumb.
% 
% -zefram

	"we" can.  There is no reason why... routing table slots are
	routing table slots.  It does place the onus on the ISPs to
	be more vigorous in tracking what they will and will not accept
	or propogate. Now, they tend to depend on RIRs to set their 
	routing policies for them... :)

--bill

---

From: [email-masked]
Date: Mon, 08 Dec 2003 16:43:51 -0500

> can't be used?  I'm not a routing person, so apologies if this is somehow

No technical reason - except if you say "I'll filter IPv4 announcements at
/28", then you're open to routing table burps if somebody accidentally
or intentionally de-aggregates to a very long prefix.  Imagine if somebody
flubs and withdraws a /12 and announces a /12 worth of /28.... (Yes,
this sort of stuff DOES happen.)

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 8 Dec 2003 23:03:57 +0100

-----BEGIN PGP SIGNED MESSAGE-----

[This should go to v6ops@ or ipv6@ietf :) ]

Zefram wrote:

> designate a block for microallocations, within which prefix 
> length filters aren't applied?

That would be the best solution, make it documented and publically known.

>  The number of routes in the DFZ is the same 
> either way; is there any technical reason why /64 or /128 prefixes, or 
> /32 in IPv4, can't be used?  I'm not a routing person, so apologies if 
> this is somehow unspeakably dumb.

Expect to see routers being optimized that will only route
the upper 64bits of the address, so you might not want to do
anything smaller than that.

Ofcourse one can use /128 routes, and /64's etc.
But because of anycast you don't want to use /127's though.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Dec 2003 23:27:05 +0100

On 8-dec-03, at 21:00, Paul Vixie wrote:

> for example, bill says above that "/35 routes

It is generally understood in the routing community that some kind of 
prefix length filtering is desirable and/or necessary. So the question 
becomes: on which bit boundary do we filter? This question seems to be 
answered by:

http://lacnic.net/en/chapter-4.html
http://ftp.apnic.net/apnic/docs/ipv6-address-policy
http://www.ripe.net/ripe/docs/ipv6-policies.html
http://www.arin.net/policy/ipv6_policy.html
http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02

(All the same document, slightly different versions.) It says:

"4.3. Minimum Allocation

RIRs will apply a minimum size for IPv6 allocations, to facilitate 
prefix-based filtering.

The minimum allocation size for IPv6 address space is /32."

I don't see how giving out micro allocations can possibly be compatible 
with this policy.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Dec 2003 23:42:01 +0100

> be accepting anything smaller (/33, /34 etc)

So how are ISPs supposed to know what the allocation size for a 
particular prefix is? This type of filtering only works if the filter 
list is relatively short and pretty much never changes. Anything else 
and the cure is worse than the disease.

> they should be accepting it too.

I'm not sure if it needs to be a /32 or if it needs to be just a single 
one, but I fully agree this should be documented very well and in a 
central place. Buried somewhere on a RIR website isn't good enough. 
(Try finding the the micro allocation list on the ARIN site without 
help from Google.)

I think this means it must be an RFC. RIR documents just don't have the 
same standing in the community, and, apparently, quality control.

> are common already could be used for assigning 'critical infra' from?

Note that announcing the actual prefix for an internet exchange subnet 
tickles an undesirable BGP feature in places where the prefix isn't 
filtered, so these prefixes are best not announced. The allocations 
seem to be /48s and not /64s though, so in practice this shouldn't be a 
problem but still no reason why these should be globally visible.

Root nameservers are a very different story of course...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Dec 2003 23:50:35 +0100

[my apologies for burning so much bandwith]

> can't be used?  I'm not a routing person, so apologies if this is 

In RFC 3513 (section 2.6) it more or less says that anycast addresses 
must be host addresses and they must be propagated throughout the 
region where there are interfaces configured for the anycast address. 
So if there are root servers sharing an anycast address all over the 
globe, there must be a globally visible /128 for that root server.

So no, this isn't dumb. Also, if anycast addresses are going to come 
from micro allocations there is no particular reason to stop at 48 
bits. A prefix size that is different from what millions of end users 
will be getting might in fact be a plus.

---

From: Zefram <[email-masked]>
Date: Mon, 8 Dec 2003 23:00:53 +0000

[email-masked] wrote:
>                                                       Imagine if somebody
>flubs and withdraws a /12 and announces a /12 worth of /28....

That's why I suggested relaxing the filters only within a designated
block.  So (for IPv4) the /12 worth of /28s gets ignored, but the /32s
in the micro-allocation block are accepted.  It always seemed odd to me
that we allocate a /24 per anycast service, and worry about the address
space wastage, when all the anycast services we can expect to find useful
in IPv4 will comfortably fit into less than a single /24.

If there's a problem due to the need for 100% implementation of
the relaxation of prefix length filters, we should allocate a
micro-allocation block for IPv6 *now*, while the number of routers
requiring reconfiguration is relatively small.  I propose 0:1::/32,
which is distinctive, causes no fragmentation, and is in a region of
the address space already recognised as being for weird stuff.

-zefram

---

From: Franck Martin <[email-masked]>
Date: 09 Dec 2003 11:21:45 +1200

Just some perspectives on the IPv6 addressing scheme, that I have
highlighted to APNIC.

A country like Tuvalu with about 10,000 people, which is an island with
many possibility of connectivity to the Internet would be attributed
what range if they request IPv6?

Don't tell me they do not need IPv6 or they can get it from their
upstream provider. It is a country, they should be able to change their
upstream provider every 6 months without having to change the IP space
of the country...

BTW: I know about 10 countries in this case in the Pacific Islands,
unfortunately few are APNIC members or attend APNIC.

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 9 Dec 2003 00:20:20 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> There is no commonly agreed-upon best practice for this yet.

Some ISP's do it, most don't.

Btw CH-SUNRISE-20031124 = 2001:1700::/27, so Libertel isn't the
biggest girl on the block anymore with their /31 :)

> I agree that things that are more specific than a /48 should not be

Indeed. And yes there are ISP's announcing /128's etc.
And private ASN's for that matter or even using them as transit.

<SNIP>

> recommendation on the subject of "filtering things between /35 and /48"...

Yups and I fully support that argument.

If it was done we would currently see 413 prefixes, those are the
'allocated' prefixes that are getting announced.
In GRH each of the ~30 peers have an average of 459 prefixes.
Checking just know, the highest number of prefixes send to GRH
was 515 prefixes, which is far from the 20k or even 30k if all
the ASN's would announce 1 IPv6 prefix.

At the moment that is certainly no problem and it shouldn't be
for years to come, unless IPv6 really takes off. Google/Doom3 IPv6 anyone?

The biggest advantage that IPv6 already has is that a single
ISP already gets enough space, thus it doesn't need to 

> and the cure is worse than the disease.

The proposed "Redistribution of Cooperative Filtering Information" draft
could help out there which allows one to redistribute 'good prefix' lists.
See https://www1.ietf.org/mail-archive/working-groups/idr/current/msg00201.html
for the draft or http://arneill-py.sacramento.ca.us/redisfilter.ppt for
the presentation given in Minneapolis.

Without that or a similar system, it would be a pain indeed.
That's why I pointed to Gert's page which has a better and
currently working solution.

<SNIP>

> filtered, so these prefixes are best not announced.

As far as I can see with the GRH tools etc, all the prefixes
that are allocated as "IX Prefixes" and those that are in use
are currently visible worldwide.

> The allocations seem to be /48s and not /64s though, so in
> practice this shouldn't be a problem but still no reason why
> these should be globally visible.

The only reason I heared so far is so that people in Tokio can
ping the IX interface in London or a similar kind of scenario.
They argue that it is handy for debugging. My take is that if
it isn't your network, you can't fix it either, so if a traceroute
ends on that box, contact them, they can really figure it out.

> Root nameservers are a very different story of course...

A /32 contains 65k /48's, so these IX blocks could provide for
enough /48's for 65k IX's, thus unless that switch at the back
of my desk, which connects 'neighbours' too is to be called an
IX, because they have a linux router and me too and they speak
BGP is going to be called an IX it shouldn't be a problem if
the same block is used for 26? and maybe 3 tld servers per country.

At least everybody will know that that /32 will have more specifics.

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 9 Dec 2003 00:45:27 +0100

-----BEGIN PGP SIGNED MESSAGE-----

[You should ask this to the RIR's, not IETF]

Franck Martin wrote:

> Just some perspectives on the IPv6 addressing scheme, that I 
> have highlighted to APNIC.
> 
> A country like Tuvalu with about 10,000 people, which is an 
> island with many possibility of connectivity to the Internet 
> would be attributed what range if they request IPv6?

As Tuvalu, of which I only know that they are exploiting the .tv
tld for commercial domain names, falls under the APNIC region it
is quite simple. An ISP that is located on the island becomes a
LIR and that LIR requests address space from APNIC, which then
grants it to them.

Multiple ISP's can do that. Address space is not bound to countries
or even islands. It is bound to the ISP, may that ISP serve only
a 'small' island or may it serve the complete globe. Notez bien
that the only 'real' limit is that an ISP should be able to demonstrate
the need for this space by declaring that it will have 200 customers.
See the allocation policies. It thus depends more on the ISP that
requests the space, but if they get any space at all it will be
a /32 on minimum.

> Don't tell me they do not need IPv6 or they can get it from 
> their upstream provider. It is a country, they should be able 
> to change their upstream provider every 6 months without 
> having to change the IP space of the country...

They get it from their ISP, just like everybody else ;)

> BTW: I know about 10 countries in this case in the Pacific 
> Islands, unfortunately few are APNIC members or attend APNIC.

Greets,
 Jeroen

---

From: Ted Hardie <[email-masked]>
Date: Mon, 8 Dec 2003 15:48:15 -0800

At 11:21 AM +1200 12/09/2003, Franck Martin wrote:
>Just some perspectives on the IPv6 addressing scheme, that I have highlighted to APNIC.
>
>A country like Tuvalu with about 10,000 people, which is an island with many possibility of connectivity to the Internet would be attributed what range if they request IPv6?

The key question I would ask is whether Tuvalu is planning to provide services to
its 10,000 people.  If it plans a state monopoly ISP with eventual service to
some fraction (possible 100%) of its citizens, then it is a service provider
with that base.

If, on the other hand, it is not planning to provide services itself, but will allow
competition among service providers so that some folk get IP connectivity
through Vendor A and some through Vendor B, then it is appropriate to say
those folks getting service from A have space allocated from Vendor and
those from Vendor B from Vendor B.

>Don't tell me they do not need IPv6 or they can get it from their upstream provider. It is a country, they should be able to change their upstream provider every 6 months without having to change the IP space of the country...

Their being a country isn't nearly so important as whether or not they are a network. 
Provider independent address space for a network can make sense (whether justified
through multi-homing, sovereignty, or correct form-filling skills).  Provider independent
address space for something that is not a network is just bits.

>BTW: I know about 10 countries in this case in the Pacific Islands, unfortunately few are APNIC members or attend APNIC.
>
>Cheers
>
>
			regards,
				Ted Hardie

---

From: Bill Manning <[email-masked]>
Date: Mon, 8 Dec 2003 16:39:10 -0800 (PST)

% Expect to see routers being optimized that will only route
% the upper 64bits of the address, so you might not want to do
% anything smaller than that.

	This, if it happens, will be exactly opposed to 
	the IPv6 design goal, which was to discourage/prohibit
	hardware/software designers from making presumptions or
	assumptions about the size of prefixes and HARDCODING them
	into products.

--bill

---

From: Mark Prior <[email-masked]>
Date: Tue, 09 Dec 2003 10:18:41 +1030

> unfortunately few are APNIC members or attend APNIC.

I know it's a bit bigger but see Papua New Guinea (2001:0C60::/32). I'm 
not sure if they are using it yet as I stopped providing support for PNG 
before I could roll out new router OS versions necessary to support 
IPv6. I doubt that APNIC would have a problem with Tuvalu making a case 
for a prefix.

Mark.

---

From: Bill Manning <[email-masked]>
Date: Mon, 8 Dec 2003 16:48:30 -0800 (PST)

% > Root nameservers are a very different story of course...
% 
% A /32 contains 65k /48's, so these IX blocks could provide for
% enough /48's for 65k IX's, thus unless that switch at the back
% of my desk, which connects 'neighbours' too is to be called an
% IX, because they have a linux router and me too and they speak
% BGP is going to be called an IX it shouldn't be a problem if
% the same block is used for 26? and maybe 3 tld servers per country.
% 
% At least everybody will know that that /32 will have more specifics.
% 
% Greets,
%  Jeroen

	2001:0478:: was delegated expressly for IX and core infrastructure.
	Thats where at least one of the IPv6 prefixes for root-servers
	exists.  Two are from ARIN micro-allocations and there is a
	/32 for another server.

--bill

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 9 Dec 2003 02:20:19 +0100

-----BEGIN PGP SIGNED MESSAGE-----

[2 mails into one again]

> 	assumptions about the size of prefixes and HARDCODING them

Good point. With current allocation schemes it should work but
maybe in the future, for anything outside 2000::/3 it could
indeed change and then the above could indeed break.

Hope the implementators of routing engines did notice that
unlike what I did :)

> 	2001:0478:: was delegated expressly for IX and core infrastructure.

- - is this documented somewhere?
  (google on the prefix only returns discussions about it's use ;)

- - is it available to the world(tm) as it looks like this is only
  available for exchanges managed by EP as per http://www.ep.net/wtgipa.html
  Thus also to the RIPE/APNIC/LACNIC region ?
  Regionalizing a root-server shouldn't be the case anyways as it
  shouldn't be bound to a certain spot.

I, personally, see absolutely no problem into making it the 'critical infra'
or 'root server' prefix, when it is documented correctly. EP.NET acts as
a neutral body, with this way kinda of a sub-RIR though. All root-servers
should be using the space then btw, not a few, but all of them.
Exceptions to the rule will only cause that the exceptions are forgotten
or that the rule is bent to badly that the rule isn't in place anymore.

> 	exists.  Two are from ARIN micro-allocations and there is a

Grepping on root+dns in http://www.sixxs.net/tools/grh/tla/all/

2001:7fd::/32      K-rootserver-net-20030829 (not seen)
2001:7fe::/32      I-rootserver-net-20030916 (seen per 2003-09-17)
2001:dc0::/32      APNIC-AP-V6-20030124      *
2001:dc3::/32      M-ROOT-DNS-IPv6-20030619  (seen per 2003-08-31)
2001:dc4::/32      jp-dns-JPNIC-JP-20031117  (seen per 2003-12-03)

* = 2001:dc0::/35 + 2001:dc0:2000::/35 are announced, not the /32

The ARIN microallocs are not in there as they are not TLA's.
Should I start tracking those too with GRH?

Btw currently seen in the routing table (as per GRH)
2001:478::/32 (from SPRINT / AS6175)
2001:478::/45  (from EP.NET / AS4555)
2001:478:65::/48 (from EP.NET / AS4555)

Greets,
 Jeroen

---

From: Paul Vixie <[email-masked]>
Date: 09 Dec 2003 02:46:09 +0000

> should be using the space then btw, not a few, but all of them.

i, both personally and professionally, think that this would not be desirable.
-- 
Paul Vixie

---

From: Bill Manning <[email-masked]>
Date: Mon, 8 Dec 2003 19:46:43 -0800 (PST)

% > I, personally, see absolutely no problem into making it the 'critical infra'
% > or 'root server' prefix, when it is documented correctly. EP.NET acts as
% > a neutral body, with this way kinda of a sub-RIR though. All root-servers
% > should be using the space then btw, not a few, but all of them.
% 
% i, both personally and professionally, think that this would not be desirable.
% -- 
% Paul Vixie

	EP.NET has been doing "micro-allocations" for longer than all but
	one RIR has been in existance. That said, I am greatful that RIRs
	themselves are doing micro-allocations. This for two reasons:

	) customers should have -choice-
	) using multiple prefixes reduces the impact of route flap
	  taking out everyone.

--bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Dec 2003 10:54:47 +0100

> In fact, we have a shorter and easier to read document giving details 
> of minimum allocation lengths. It was produced at the request of the 
> routing community and can be found at:

>    <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html>

> We update it when we receive a new block from the IANA.

Ok, that's good, but it doesn't fix the problem that the list of 
documents above _seems_ authoritative and says it's ok to filter at 
/32. And this isn't just theory: I'm sitting behind an ISP that filters 
out the /48 for the F root server.

(You don't mention micro allocations by the way, but unless I'm 
mistaken you guys do give those out sometimes.)

---

From: leo vegoda <[email-masked]>
Date: Wed, 10 Dec 2003 10:28:23 +0100

>http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02

In fact, we have a shorter and easier to read document giving details of 
minimum allocation lengths. It was produced at the request of the 
routing community and can be found at:

Regards,

-- 
leo vegoda
RIPE NCC
Registration Services Manager

---

From: leo vegoda <[email-masked]>
Date: Wed, 10 Dec 2003 11:22:05 +0100

Iljitsch van Beijnum <[email-masked]> wrote:
>/32.

I don't think it's clear that the wording in the IPv6 policy document 
should be improved. It's a bit ambiguous at the moment. We're keen to 
help improve the text.

>And this isn't just theory: I'm sitting behind an ISP that filters out 
>the /48 for the F root server.
>

We assign small networks to IXPs.

The document has the following in it reflecting this:

CIDR block         Smallest RIPE NCC        Smallest RIPE NCC
                    Allocation               Assignment
2001:0600::/23     /35                      /48

Again, if people feel that the text published needs to be improved then 
please let us know. We don't want to publish anything ambiguous or 
misleading. We're happy to improve text whenever people indicate 
improvements can be made.

Regards,

---

From: Bill Manning <[email-masked]>
Date: Wed, 10 Dec 2003 07:37:55 -0800 (PST)

% We assign small networks to IXPs.
% 
% The document has the following in it reflecting this:
% 
% CIDR block         Smallest RIPE NCC        Smallest RIPE NCC
%                     Allocation               Assignment
% 2001:0600::/23     /35                      /48
% 
% Again, if people feel that the text published needs to be improved then 
% please let us know. We don't want to publish anything ambiguous or 
% misleading. We're happy to improve text whenever people indicate 
% improvements can be made.
% 
% leo vegoda

Leo, this is the text we use for IX delegations. For CI uses, transit of 
said prefix is a valid injection.
	--------------------------------------------------

Exchange Point Announcement Statement

Our statement regarding the injection of EP.NET address space into a routing 
system. 

"anyone who has a properly delegated /32 address delegated/assigned from a /24 
within 198.32.0.0/16 may announce that /24 to their peers. This is also true 
in IPv6 space in that anyone with a properly delegated /64 assigned from a /48 
in the 2001:0478::/32 space may annouce that /48 to their peers. Prefix 
aggregates are discouraged and as a general rule may be considered to be proxy 
aggregations made by parties who are not direct participants in any address 
assignments from these ranges." 

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Dec 2003 12:30:27 +0900

Bill Manning;

> 	assumptions about the size of prefixes and HARDCODING them

That is a foolish design goal demonstrating lack of understanding
on how large 2^64 space is.

A better design, for example, is to use only upper 16 bits (note
that 100,000 routes of IPv4 is already overkill) at the core
backbone, which makes high speed backbone routers not very
expensive and faster.

Though multicast and QoS needs more bits, they, anyway, need
separate mechanism.

						Masataka Ohta

---

From: leo vegoda <[email-masked]>
Date: Wed, 10 Dec 2003 16:06:31 +0100

leo vegoda <[email-masked]> wrote:

[...]

>should be improved. It's a bit ambiguous at the moment. We're keen to 

An extra "don't" slipped in there.

Sorry,

---

From: leo vegoda <[email-masked]>
Date: Wed, 10 Dec 2003 16:44:50 +0100

Hi Bill,

Bill Manning <[email-masked]> wrote:

[...]

>said prefix is a valid injection.

As a general rule we try to avoid statements that might give people the 
impression we are telling them what they may and may not route. In 
another paragraph in the "Smallest RIPE NCC Allocation / Assignment 
Sizes" document we write:

"Routing decisions for blocks of address space are the sole 
responsibility of network operators. However, network operators taking 
routing decisions based on prefix length are requested and encouraged to 
route at least blocks of sizes corresponding to the 'smallest 
allocation' and larger."

Regards,

---

From: Joao Damas <[email-masked]>
Date: Thu, 11 Dec 2003 13:25:21 +0100

> should be using the space then btw, not a few, but all of them.

No, no and definitely no!!!

It is one thing to put all IXP prefixes in the same block, after all it 
does not matter if they are not seen in the global Internet as, in 
fact, they should not be visible.

However, putting public infrastructure all in the same prefix is about 
the worst idea I have heard in some time. One hiccup would kill them 
all at the same time.

Joao Damas
ISC

---

From: Sascha Lenz <[email-masked]>
Date: Fri, 12 Dec 2003 12:20:36 +0100

Hay,

> I agree that things that are more specific than a /48 should not be

Well I think everyone agrees, that Prefixes longer than /48 should
definately not show up in the global routing table, simlar to prefixes
longer than /24 in the IPv4 world.

I even could somehow understand, that we might not want /48s, i.e.
"end-sites" to be in the global BGP table.

But what i really oppose is, that there should or must be filters
on RIR Allocation boundaries, i.e. /32's and shorter.

_At_least_ "NLA" space (yes, i know, NLA-acronym is depreciated) must
be routable and accepted everywhere,
for example Sub-Allocations to smaller ISPs or non-commarcial organisations
who do not want to get a RIR membership or simply can't afford it
(there is no low-cost membership for non-commercial organisations
available at any RIR AFAICS).

Otherwise this would be a huge discrimination in my eyes, which cannot
be even in today's totally commercialized Internet.

Consider the other options:

- People with money would start making things up to get a RIR allocation
  just like they do nowerdays some times to get portable address
  space ("PI" Assignments or a PA Block of a /20 or something)

  Everyone can get a RIR member, even end-users. 
  They now get an IPv4 Allocation as soon as they are member (an can
  show some need for IP-space).
  Current IPv6 policy forbids "end-sites" to get an Allocation,
  but why the difference? 
  Even if this part stays in the policy, people will start to make up
  things, "we have 100 employees and 100 contractors which we connect
  in their home-office and assign them /48s" .. and they most likely 
  will have their /32 to announce globally.
  
  On the other hand, organisations who don't have the money will be
  completely discriminated.

- Rather focus on the "one (or few) Prefixes per AS" part

  As already stated within this thread, IPv6 fixes the biggest
  problem by design - many many many Prefixes per AS will be no issue.

  Now if we also consider that many many many customers (end-sites)
  who have PI space, ASNs, BGP Multihoming just because there was
  no other solution in the IPv4 world back some years at all...
  Most _are_ happy with whatever IPv6 Multihoming solution other than
  BGP-Multihoming is out there, for example multiple lines to the
  same ISPs, Fallback-Tunnels or whatever the other IPv6 multihoming draft
  was about...
  Not everyone who does full BGP multihoming today does really need it.
 
  BUT - noone who really wants "real" Multihoming like it is done
  today by announcing a unique prefix, should be denied that.
  This just won't work in the real world, because some customers need
  this, and some non-commercial organisations rather want to invest
  in their infrastructure than in a RIR membership when they only
  have whatever, 200 members and are happy with a /40.
 
  The routers do not care if a prefix is a /32 or a /40 or even a /48.
  No much difference, the amount of Prefixes is the problem.
 
So, probably we should rethink the global IPv6 Policy anyways.
As Gert said - this lack of IPv6 Multihoming possibility with the current
Policy and filters just hinders IPv6 deployment at the moment.
"I can't do this in IPv6? On sorry, then i don't see why i need it when
my connectivity gets worse than with IPv4"

BTW: I announce several /40s and don't really see routing problems up to 
     now. I really thought, all those folks who fought the holy war for
     strict filters were long gone? Am I wrong?

-- 
==========================================================================
= Sascha 'master' Lenz          SL277-RIPE              [email-masked]     =
=                                                                        =
= You can rent this space for $$$          * PGP public Key on demand *  =
==========================================================================

---

From: "Jeroen Massar" <[email-masked]>
Date: Sat, 13 Dec 2003 18:23:55 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Joao Damas [mailto:[email-masked]] wrote:

<BIG SNIP>

> fact, they should not be visible.

My idea exactly, though some others think differently and
they have their valid reasons to do so.

> However, putting public infrastructure all in the same prefix 
> is about the worst idea I have heard in some time. One hiccup
> would kill them all at the same time.

All the 'public infrastructure' is under 2000::/3 at the moment.
Do hiccup's over there cause any problems? I mean, come on, even
Cisco (AS109 FYI) is passing prefixes through their routers that
have private ASN's as transits.

If they are all in the same prefix (/32 for instance) at least
people could safeguard and put monitoring on those prefixes as
they are easily identified as being 'critical infra', which is
the reason why it is currently seperately specified in the RIR
allocation policies.

Next to that if DNS's are given a micro-allocation from that
/32, ISP's will know that it is normal and default behaviour
for that prefix, unlike the current set of a number of 'special'
prefixes that simply look like normal prefixes.

I really don't see any difference between:
 - 2001:db8::/32 = 1 NS
or:
 - 2001:db8::/32 = contains all NS's
    2001:db8:1:/48 - A.root
    2001:db8:2:/48 - B.root
    2001:db8:3:/48 - C.root
    2001:db8:2000:/48 - nl.tld
    2001:db8:3000:/48 - de.tld
    ....

The last one are more specifics anyways, if anybody is able
to announce a /32 or a /48, it doesn't matter it will always
be a BGP and trust problem. Same if I would announce say,
198.41.0.0/22 on the AMS-IX to the peers over there, it will
have the shortest path and any ISP not filtering correctly
will start sending the traffic to me. That is a BGP security
and peering-trust problem and has nothing to do with the above.

Greets,
 Jeroen

---

From: jfcm <[email-masked]>
Date: Tue, 16 Dec 2003 12:06:13 +0100

At 23:42 08/12/03, Iljitsch van Beijnum wrote:
>central place. Buried somewhere on a RIR website isn't good enough. (Try 
>finding the the micro allocation list on the ARIN site without help from 
>Google.)
>

I suggest ISO should define an international trans network numbering scheme 
that could be adopted as the IPv6.010 numbering plan, the same way as the 
ccTLD list is the ISO 3166 2 letters list, and IDNA uses unicodes etc.

This would relieve IETF from these user, political, etc. oriented 
inapropriate controversies. IPv6 is supposed to support 6 plans. Whatever 
relates to a specific plan kills that possibilty. The "IPv6 inside" label 
should only be granted when everything is transparent to the current 
IPv6.001 and may function the same with IPv6.010, whatever IPv6.010 may be. 
As an IPv6 user this is my legitimate expectation to show me that IPv6.111 
will most probably work if 001 and 010 are orthogonal.

My suggestion for 010 is orthogonal to 001 from structure, management etc. 
to economical model.
jfc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Dec 2003 15:20:54 +0100

On 16-dec-03, at 12:06, jfcm wrote:

> I suggest ISO should define an international trans network numbering 
> scheme that could be adopted as the IPv6.010 numbering plan, the same 
> way as the ccTLD list is the ISO 3166 2 letters list, and IDNA uses 
> unicodes etc.

The ISO is already in charge of NSAP addresses. I don't see how 
importing the complexity that exists there into IP is going to help us.

> inapropriate controversies.

There is very little, if any, controversy in IPv6 addressing. Ask for 
address space and you'll get it. Moving addressing issues to a new 
organization would in fact create controversy as it is virtually 
guaranteed that address policies and routing policies will fall out of 
alignment, to the detriment of the net as a whole.