Subject: Re: national security

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Sun, 30 Nov 2003 22:56:11 +0100

Dear Paul,
Thank you for your response even if it is not to the question asked. I 
never made any proposal. I have listed suggestions made by different 
parties (I certainly takes seriously) to address real life problems of 
immediate security for nations subject to catastrophe, war, international 
fights or confronted to a netwok collapse.

And I asked for serious warnings, anlyses, advices, alternative suggestions.

At 19:47 30/11/03, Paul Vixie wrote:
>this statement is akin to many others made in ignorance of what dns is.  you
>are treating it as a mapping service.  perhaps you have been successful at
>treating dns as a mapping service in some local context, and this may have
>led you to the impossible conclusion that dns itself is a mapping service.
>
>dns is a coherent, distributed, autonomous, reliable database.  "distributing
>the root" as you claim to believe is necessary would create multiple domain
>name systems,

Amusing. Yes I experimented that in 78. And some where unhappy :-). I will 
not tell you the DNS is several things to achieve a common purpose which 
addres maping. The way it does it _tryies_ to be a coherent, distibuted, 
autonomous, reliable database. What by essence it never is, except if you 
stop feeding it and you wait for all the TTL to die.

Here, we are in the case it is impeached to continue trying.

>not *a* domain name system with a distributed root.  there is no
>way to have *a* domain name system with a distributed root unless we (ietf
>or other similar agencies) first defined what that meant.

Interesting. Which agency? An agency under cooperation agreement with ICANN 
or NTIA, or a standarization body like ITU, or the P2P standardization 
committee.

Anyway, I do not look for a fundamental debate. But for serious, 
experienced  and documented considerations about the flexiblity of the 
existing system and its capacity to effectively sustain some duress under 
necessity. And how to best specify/design the solutions then to use.

>when you're ready
>to commission a multiyear study which would yield documents of the same size
>and scope as rfcs 1033+1034+1035+2181, then you'll have demonstrated that
>you have some understanding of what you're asking for .

NSA started the study. Work is engaged by the WH. 
http://whitehouse.gov/pcipb. ICANN has documented the way it should be done 
(ICP-3). NSI has commited a 500 million budget on DNS. Other projects are 
at works. The target now is to know what to in the meanwhile and what to do 
to protect onselef from their results.

>and note that you would then have to "sell" the resulting system to the 
>internet populance which includes end users, domain holders, registrars, 
>registries, ISPs, and as you point out, nations.  lots of luck, but "that 
>ship already sailed."

:-) amusing. The world lived millions years without the DNS. For 20 years 
international data nets created naming but lived without the DNS. True, for 
less than a decade, since the Web, the world faces a management problem 
because IETF has kept with an early 80's applications architecture. 3/4 of 
the world is just telling USA (WSIS, this week) "okay for your 'root 
bluff': how much".

Naming was not created by the DNS and will survive the DNS. The DNS 
application is a good example of an extended service but it must adapt to 
the current needs. It is a 1983 car. It is brillant, it has been 
refurbished a lot, but still it is a 1983 vintage.

>in no particular order, i'll address a couple of your other comments.
>
> > 5. the possibility of a redundant DNS system. Today the Internet has two
> > root files (the same file but presented on two main systems - DNS and 
> FTP).
> > If one is hacked there is not reference. A redundant system would consist
> > in two or more root masters refereeing to different sets of TLD name
> > servers (all of them carrying the same files, but possibly of different
> > origins for security reasons).
>
>there is a reference.  several references, actually.

hey! Is not a reference unique? As, John would say: wich unique master is 
the master?

>there is no possibility of a "hack" going undetected or uncorrected.

Not disputing that. The point is: what is the worst impact of one of the 
unique copies being hacked and detected. What are the recovery procedures? 
What are the control procedures? Are they fool proof? Are they accepted by 
users?

Police is often immediately notified bank robberies. Yet hold-ups hurt and 
kill people every day.  We are not salesmen here. But cops and insurance 
companies.

Most of all when the hacker seats in the Oval Office, what is the solution? 
Kaspurcheff was not the only root hacker to be known. Jon Postel was too.

WTC was built to resist the worst winds. Not 747s. Many people regret it. 
Our role is to make sure it does not to happen again.

>but more important, if you had several "root files" which indicated 
>different servers for some TLD's, you would have (by definition) several 
>domain name systems,

1. there are two different root files in use each time there is an update 
and update may take long.
2. you jump at war conditions. You assume that these root files would be 
different. Opposite to the suggestion. To the countrary the suggestion is 
to help making sure the root files do not differ, beause they do not differ 
from reality, in adding mutual consistency controls.
3. you presume the resulting name spaces are conflicting. While the 
hypothesis is they are not. .

The TLD Manager is authoritaive on his zone. That I cannot access these 
authoritative systems and may be incurred heavy losses in live or money, 
without a possibly absent or agressive third party 15 K public file 
produced by an NTIA secretary, is NOT acceptable, it is ridiculous.

All the more than today you will not remove from Gov's minds, that the 
permitted flexibility is of several monhs: they have been taught that by 
ICANN over KP&Quest.

>not a domain name system with high redundancy.

Redundancy in error is more error. Parallel root systems, means - if there 
is a conflict - that one is true and one is wrong. I prefer both are true. 
But I prefer confusion than both being wrong. What I expect from you is to 
discuss how to come back quickly to a proper situation, and how to handle 
the situtation if necessity (conflict) makes there are two roots.

Actually what we devised and started testing is a three root system, with 
mutual monitoring. The majority decides and the different one dies - or 
actually should be physically shut (nothing makes sure it will want to 
die). The interest was only to set-up the test bed, not to develop and test 
a particular logic.

Every human system/development involves risks at some stage. How many 
deaths the DNS today, how many potential? WH's Richard Clarke gave a 
response. I know IETF does not like him, but  no one has the right to 
overlook it.

This being accepted. Question. how to best configure the servers, what to 
change in the progams to reach the best (or last worst) securrity.

Question. If an ennemy root system is imposed on me. Cf. Karl/Randy exchange.

Question.What was done over NSI service to curb the authoritative 
infromation given by a TLD manager, was it not to create an alternative 
name space? If you think it was ligitimate you only make it an act of 
resistance to NSI's abusive but legitimate right and power. Would that be 
only reserved to some on the planet?

>until you demonstrate some understanding of that fundamental and 
>definitional aspect of dns, you won't be taken seriously among the 
>community who does understand those things.
>please learn the basics before you come in here and start making proposals.

Please go back to my initial remark.
Best regards.
jfc

---

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

> Kaspurcheff was not the only root hacker to be known. Jon Postel was too.

good bye, sir.
-- 
Paul Vixie

---

From: "Philip J. Nesser II" <[email-masked]>
Date: Fri, 28 Nov 2003 08:43:36 -0800 (PST)

On Fri, 28 Nov 2003, Anthony G. Atkielski wrote:

> Iljitsch van Beijnum writes:
>
> > In the multi6 (multihoming in IPv6) working group, as one of many
> > proposals, we've been looking at putting a 64 bit host identifier in
> > the bottom 64 bits of an IPv6 address. If such a host identifier is
> > crypto-based (ie, a hash of a public key) then it is possible to
> > authenticate a host at any time regardless of where the host connects
> > to the network at that particular time and without the need for a PKI
> > or prior communication.
>
> This is precisely the kind of mistake that will exhaust the entire IPv6
> address space just as quickly as the IPv4 address space.  Don't
> engineers ever learn from the past?
>
>
Ahhh...No.  Don't people understand the power of exponential growth?

---

From: "Michael H. Lambert" <[email-masked]>
Date: Sun, 30 Nov 2003 11:35:07 -0500

Dear jfc,

As far as I can tell, you have gone only by your initials on this 
thread.  To help some of us weigh this discussion, could you please 
identify yourself by name and affiliation?

Regards,

Michael Lambert

-----------
Michael H. Lambert                      Network Engineer
Pittsburgh Supercomputing Center        V: +1 412 268 4960
4400 Fifth Avenue                       F: +1 412 268 8200
Pittsburgh, PA  15213  USA

---

From: jfcm <[email-masked]>
Date: Tue, 02 Dec 2003 02:19:56 +0100

> > Kaspurcheff was not the only root hacker to be known. Jon Postel was too.

Dear Mr. Vixie,
Things will not fall a part on Dec 6th by midnight. But if 189 States and 
USA do not agree on something reasonable on THIS point, we will enter a 
period where there will be progressive disagreements over the naming, IMHO 
to no one's benefit. And the necessary changes will then not occur 
smoothly. Europe supports the US position with some internal differences 
which permit to help a compromise.

Unless you really want to say good bye to the whole thing, why don't you help?

For example, are we not able to just devise a procedure and a system which 
build the root file from the TLD Managers owns real time data? Would Vint 
have responded that, it was stability for ICANN and IETF for years. OK, 
ICANN's stablity through power greed is inadequate, but is that not also 
inadequate to permit it? And not to consider who to change that situation?

Be sure that whatever the outcome of Dec. 5/6, the IANA US root file 
management is condemned. And probably ICANN in two years time if it stick 
to it. The USA are not going to support them. As they did not in Marrakech 
for the IDNs. What would be their advantage?

The important issue is to know what will replace it? An automated 
compilation of the TLD Managers data by IANA would be preferable to an ITU 
system, after a rought debate and transfer.
Best regards
jfc morfin

---

From: [email-masked]
Date: Fri, 28 Nov 2003 11:28:18 -0500

On Fri, 28 Nov 2003 14:52:11 +0100, "Anthony G. Atkielski" <[email-masked]>  said:

> A 128-bit field contains 2^128 addresses.  If you divide that into two
> 64-bit fields, you may get as few as 2^64*2 addresses; that's 18
> million trillion times smaller than the 128-bit field.

Exactly.  And the *reason* why IPv6 has 128 bit addresses is because
the designers realized that such losses happen, and ruled out 64-bit
addresses because of that effect.  I suggest you figure out just how
much bigger 2^65 is than the current 2^32, and factor in the current
burn rate on the unused IPv4 addresses, and from there figure out if
there's really a problem there at all....

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Dec 2003 14:03:12 -0500

> RFC 3513 mandates that all unicast IPv6 addresses except the ones 
> starting with the bits 000 must have a 64-bit interface identifier in 
> the lower 64 bits.

This was shortsighted, just like having the notion of "class" built into
IPv4 addresses was shortsighted.  People are going to need to subnet
past /64 sooner rather than later, and subnetting past /64 is a LOT
better than NAT.  Fortunately  the mistake is easily rectified, so long
as software doesn't get into the habit  of expecting the lower 64 bits
of an address to be a unique interface identifier.  

> This has some important advantages, most notably it 
> allows stateless autoconfiguration. 

Providing an alternative to stateless autoconfiguration for subnets 
past /64 might be a acceptable compromise.

> Putting a 64-bit crypto-based host identifier in the bottom 64 bits of
> 
> IPv6 addresses shouldn't get in the way of regular IPv6 addressing 
> mechanisms and/or operation.

Putting a crypto-based host identifier in the address is unnecessary,
since there's really no need to include a strong host identifier in
every packet sent to a host.  The locator alone is usually sufficient,
and if that's not sufficient, the sender can generally encrypt the
traffic with a secret known only to the intended destination.

Keith

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 2 Dec 2003 21:04:03 +0100

Keith Moore writes:

> IPv4 addresses was shortsighted.

Just about everything about address allocation has always been
shortsighted.

I have a simple idea:  Why not just define the first three /32 chunks of
the IPv6 address space as three IPv4 spaces, and leave the rest of the
IPv6 reserved?  This triples the amount of address space available to 12
billion addresses.  You put all the existing addresses in the first
chunk, and then expand to the second and third chunks as required once
IPv6 is widespread.  You leave all the rest ALONE until these chunks are
exhausted.  Simple, no?  And it involves no stupid decisions that will
cause the entire address space to be exhausted in twenty years.  It buys
you possibly decades of time in which to think of a new and better way
to allocate a bit more address space.  You proceed by small increments
like this for the future, never attempting to allocate the entire space
at once.  And if you do it that way, there's a good chance that you'll
never run out of space, and rewriting will be minimal or nonexistent.

> Fortunately  the mistake is easily rectified, so long

Why dedicated /64 to anything?  We are getting by just fine on /32 for
the whole world right now.  Why is a sudden expansion of 2^32 required
RIGHT NOW?

See, that's the classic mistake: Everyone wants to divide the entire
address space RIGHT NOW, without any clue as to how the world will
evolve in years to come.  Nature may abhor a vacuum, but it certainly
also seems that engineers abhor unallocated address space, and will try
to allocate everything even when they are lightyears off the mark, and
even if it means rewriting all the software in the world a few decades
later.

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Dec 2003 15:40:33 -0500

> Putting a 64 bit crypto-based identifier in IPv6 addresses isn't 
> something that would be done because it's the only way to arrive at 
> certain functionality, but rather because it's a convenient way to do 
> it. The 64 bits are present in each packet anyway, and putting a crypto 
> identififer in each packet is much simpler than thinking very hard 
> about when one is required, and then find a good place for it.

well, you have to do that thinking anyway in order to get multihoming,
mobility, and renumbering to work right.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2003 21:42:17 +0100

> of an address to be a unique interface identifier.

Right. Fortunately the implementations that I'm familiar with seem to 
have ignored this requirement at least to some degree as they seem to 
function well with non 64-bit subnet boundaries. However, there is also 
another requirement that gets in the way of using very small subnets: 
the well-known anycast addresses. Since the address with all zero bits 
in the subnet part is the mandatory all subnet routers anycast address 
this address is unusable (even though this anycast address isn't 
universally implemented), and another 128 are reserved, making the 
smallest possible subnet a /126 or /120 respectively.

> past /64 might be a acceptable compromise.

DHCPv6 should work with non-/64 subnets as soon as it's integrated in 
the OSes.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2003 22:20:04 +0100

> the whole world right now.  Why is a sudden expansion of 2^32 required

Stateless autoconfiguration.

> to allocate everything even when they are lightyears off the mark

About 85% of the IPv6 address space is specifically left unused at this 
time. And even within the 2000::/3 which is defined for global unicast 
use *now* just 3/8192th is really used.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 2 Dec 2003 23:35:32 +0100

Bob Hinden writes:

> It was well understood that it was important to keep most of the IPv6
> address space open to allow for future use.

Why do we need 42,535,295,865,100,000,000,000,000,000,000,000,000
addresses right now, then?

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 2 Dec 2003 23:49:54 +0100

> use *now* just 3/8192th is really used.

But that represents 5,192,296,858,530,000,000,000,000,000,000,000
addresses.  Why do we need so many??

To put that in perspective, that's ten IP addresses for every square
_nanometer_ of the Earth's surface.

It doesn't matter if it's only 1/65536 of the total IPv6 address space;
it is still obviously too much.  And that illustrates my point.  Already
all these addresses are being allocated, even though it is unlikely that
every MOSFET transistor in the solar system is going to be assigned an
IP address.  Virtually all of this allocated space is wasted; in fact,
even if we gave every human being on Earth one trillion IP addresses for
his own use, only 0.1 billionth of one percent of this address space
would actually be used.

Do you see the problem?  IPv6 isn't even truly in place yet, and already
space is being consumed incalculably faster than any shortsighted
engineer ever dreamed.  People have trouble understanding large numbers,
so they confuse them with infinity.  And people have trouble
understanding the difference between a linear string of bits and
exponential series, so they think they can divide up a field of 128 bits
any way they want and yet still have some useful fraction of 2^128
addresses available.  But it doesn't work that way.

What will happen next? This slice of address space will be wastefully
suballocated in the same way that the slice itself was wastefully
allocated from the total IPv6 space. Easily 99.999999999999% of all
possible addresses will become unusable, thanks to wasteful allocation
schemes. Companies, organizations, and individuals will be given
staggering amounts of address space because "there's plenty of space"
and "it'll never run out." And in no time--far sooner than any of the
clueless designers ever thought possible--it will all be gone. And then
another slice will have to be allocated. And another. And another.

The ultimate result:  Instead of taking trillions of years to exhaust
the IPv6 address space, it will be consumed in a few decades.  And I'll
still be around to say "I told you so."

I really have to question the intelligence of engineers sometimes when
they can make the same glaring mistake over and over, and even with
careful explanation they still do not see it.

From a cognitive standpoint, this may be the same sort of failure to
understand that underlies many assumptions concerning national debt and
budget.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Dec 2003 10:11:31 +0900

Iljitsch;

> it.

Putting a 64 bit crypto-based identifier means people won't
type that long hexadecimal sequence.

That is, even if most people use DNS or something like that,
it is still inconvenient for DNS administrators. Note that
the value is psuedo random and completely different host
by host that copying some digit of other host does not work.

People relying on DNS do not notice even if a 64bit id from
DNS is different from the specified one. There is no one who
specifies the id.

So, there is no security nor convenience.

					Masataka Ohta

---

From: Bob Hinden <[email-masked]>
Date: Tue, 02 Dec 2003 13:13:50 -0800

>evolve in years to come.  Nature may abhor a vacuum, but it certainly

That not correct.  See:

    http://www.iana.org/assignments/ipv6-address-space

Where it says:

  2) For now, IANA should limit its allocation of IPv6 unicast
     address space to the range of addresses that start with binary
     value 001. The rest of the global unicast address space
    (approximately 85% of the IPv6 address space) is reserved for future
     definition and use, and is not to be assigned by IANA at this time.

Bob

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Wed, 3 Dec 2003 21:21:39 +0100

> address space open to allow for future use.

If it were well understood, nobody would have ever been foolish enough
to suggest blowing 2^125 addresses right up front.  I've already
explained the folly of this in a previous post.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Dec 2003 00:49:38 +0100

> explained the folly of this in a previous post.

You seem to assume that being frugal with address space would make it 
possible to use addresess that are much smaller than 128 bits. This 
might have been the case if efficiency in address allocation were the 
only issue we'd have to deal with. However, stateless autoconfiguration 
is an important feature, and it eats up a significant amount of address 
space because the interface identifier must be reasonably unique. But 
more important are routing limitations. We need to keep the size of the 
global routing table in check, which means "wasting" a good deal of 
address space. Even in IPv4, where addresses are considered at least 
somewhat scarce, a significant part of all possible addresses is lost 
because of this.

If we want to keep stateless autoconfig and be modestly future-proof we 
need at least a little over 80 bits. 96 would have been a good number, 
but I have no idea what the tradeoffs are in using a broken power of 
two. If we assume at least 96 bits are necessary, IPv6 only wastes  2 x 
32 bits = 8 bytes per packet, or about 0,5% of a maximum size packet. 
Not a huge deal. And there's always header compression.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 4 Dec 2003 00:53:57 +0100

Iljitsch van Beijnum writes:

> You seem to assume that being frugal with address
> space would make it possible to use addresess that
> are much smaller than 128 bits.

I assume that if we are getting by with 2^32 addresses now, we don't
need 2^93 times that many any time in the foreseeable future.

> This might have been the case if efficiency in address
> allocation were the only issue we'd have to deal with.

If we continue to throw away address space like this, it will be.
That's fully 1/8 of the _entire_ 2^128 addresses.

> But more important are routing limitations. We need
> to keep the size of the global routing table in check,
> which means "wasting" a good deal of address space. Even
> in IPv4, where addresses are considered at least somewhat
> scarce, a significant part of all possible addresses is lost
> because of this.

Maybe it's time to find a different way to route.

---

From: [email-masked]
Date: Wed, 03 Dec 2003 22:28:30 -0500

> Maybe it's time to find a different way to route.

If you know of a better way than BGP, feel free to suggest it,  Make sure you
do at least some back-of-envelope checks that it Does The Right Thing when
a single burp on one link of a multihomed site causes the withdrawal and
re-announcement of 50K routes.  And that the Right Thing happens when
a link outage happens 4-5 hops upstream...

While you're designing, remember that the routing table would be a lot bigger
if we weren't doing heavy CIDR aggregation - and that you'll burn a few bits
ensuring that aggregation works (try aggregating a /8 and 2 /12's even if they're
all announced from the same AS and are numerically consecutive...)

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Dec 2003 13:20:29 +0900

Iljitsch;

> We need to keep the size of the 
> address space.

That's not untrue. However, as the size of the global routing table
is limited, we don't need so much number of bits for routing.

61 bits, allowing 4 layers of routing each with 32K entries, is
a lot more than enough.

> Even in IPv4, where addresses are considered at least 

Only 20 bits or so for routing is, certainly, no good.

> Not a huge deal. And there's always header compression.

Stateless autoconfig is mostly useless feature applicable only
to hosts within a private IP network that 64 bits could have
worked.

128 bit is here to enable separation of 64 bit structured ID
and 64 bit locator.

						Masataka Ohta

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 4 Dec 2003 10:05:38 +0100

[email-masked] writes:

> If you know of a better way than BGP, feel free to suggest it ...

I've described variable-length addresses in the past.  Essentially a
system like that of the telephone network, with addresses that can be
extended as required at either end.  Such addressing allows unlimited ad
hoc extensibility at any time without upsetting any routing already in
place.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Dec 2003 21:32:39 +0900

Anthony G. Atkielski;

> hoc extensibility at any time without upsetting any routing already in

Unlimited? The limitation on public part is 20 digits.

Ad hoc extension beyond hardware supported length at that time will
fatally hurt performance.

								Masataka Ohta

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 4 Dec 2003 14:09:28 +0100

> Unlimited? The limitation on public part is 20 digits.

That's just a matter of programming these days.

> Ad hoc extension beyond hardware supported length
> at that time will fatally hurt performance.

What hardware limits numbers to 20 digits today?

---

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

Dear Masataka,
my interest in this is national security. I see a problem with IPv6 in two 
areas.

1. the 001 numbering plan as inadequate to national interests - digital 
soverignty, e-territory organization, law enforcement, security and 
safetey, etc. related reasons (I do not discuss their degree of relevance, 
just the existance).

2. the Y2K syndrome. IPv6 has 6 potential numbering plan. Launching it in 
real production without certifying it and the equipment to multiple plan 
support capacity is unacceptable. When there will be millions on IPv6 
inside without large scale testing of multiple numbering plan support, and 
many ways of use, applciations etc. developed with one single actually used 
plan in mind, no one will able to seriously propose an additional plan.

Comments welcome.
jfc

At 05:20 04/12/03, Masataka Ohta wrote:
>Content-Transfer-Encoding: 7bit
>
>Iljitsch;
>
>>We need to keep the size of the global routing table in check, which 
>>means "wasting" a good deal of address space.
>
>>Even in IPv4, where addresses are considered at least somewhat scarce, a 
>>significant part of all possible addresses is lost because of this.
>
>>but I have no idea what the tradeoffs are in using a broken power of two. 
>>If we assume at least 96 bits are necessary, IPv6 only wastes  2 x 32 
>>bits = 8 bytes per packet, or about 0,5% of a maximum size packet. Not a 
>>huge deal. And there's always header compression.
>

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Dec 2003 07:43:16 +0900

Anthony G. Atkielski;

> That's just a matter of programming these days.

On the Internet these days, it is a matter of hardware.

> What hardware limits numbers to 20 digits today?

On psuedo packet network, such as X.25 or ATM, with full of
connection, packets are forwarded by hardware with short
connection ids where e.164 numbers are used at the time of
complex signalling processed by software.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Dec 2003 08:55:39 +0900

jfcm;

> Dear Masataka,
> my interest in this is national security. I see a problem with IPv6 in 
> two areas.

Only two?

IPv6 contains a lot of unnecessary features, such as stateless
autoconfiguration, and is too complex to be deployable.

> Comments welcome.

As it is too complex, it naturally has a lot of security problems.

I'm not surprised some of them are national ones.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Dec 2003 15:32:46 +0900

Anthony G. Atkielski;

> And the hardware is a matter of firmware.

No, it is not.

Instead, software in routers is often called firmware.

						Masataka Ohta

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 5 Dec 2003 07:09:24 +0100

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 5 Dec 2003 12:26:41 +0100

> No, it is not.

Unless individual logic gates are being designed into the hardware to
perform the desired function, it's firmware.

I haven't heard of this type of hard-wired logic being used for much of
anything except RISC processor instruction logic in ages.  Given the
cost of developing chip logic from scratch for a specific purpose, and
particularly for the execution of complex tasks, I can't imagine anyone
doing it for any type of network device.  The trend historically has
always been in the opposite direction, with more and more being
accomplished by firmware and microprogramming.  The main distinction
between firmware and microgramming is that the former is more accessible
(and possibly modifiable) than the latter.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 05 Dec 2003 18:13:37 -0800

Jefsey,

which "we" are you speaking on behalf of?

--On 27. november 2003 23:20 +0100 jfcm <[email-masked]> wrote:

> While parallel issues start being discussed and better understood at
> WSIS, we have next week a meeting on Internet national security,
> sovereignty and innovation capacity.