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?
On 2-dec-03, at 21:04, Anthony G. Atkielski wrote:
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?
Stateless autoconfiguration.
See, that's the classic mistake: Everyone wants to divide the en
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> This being said, I note that this thread is only oriented to
> prospective numbering issues. May I take from that that none of the
> suggested propositions rises any concern ?
>
> In particular, that there is no problem with two parallel roots file
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On fredag, nov 28, 2003, at 20:10 Europe/Stockholm, Anthony G.
Atkielski wrote:
>
>> Ah, I see what you mean now. However, the devision is a done deal as
>> RFC 3513 mandates that all unicast IPv6 addresses except the ones
>> starting with the bits
he
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 woul
On 2-dec-03, at 20:03, Keith Moore wrote:
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 shortsi
> > 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
> > tr
On 2-dec-03, at 20:42, Schiro, Dan wrote:
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 is a dangerous prospect. The company I work for makes a
networking
stack
Schiro, Dan writes:
> This is a dangerous prospect. The company I work for makes a networking
> stack and our IPv6 implementation expects the lower 64 bits to be the unique
> interface identifier.
Does anyone see how wasteful this is? What's the likelihood of having
2^64 unique interfaces in th
Keith Moore writes:
> This was shortsighted, just like having the notion of "class" built into
> 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
>
> >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 is a dangerous prospect. The company I work for makes a networking
> stack and our IPv6 implementat
ECTED] [mailto:[EMAIL PROTECTED] Behalf Of Keith
Moore
Sent: Tuesday, December 02, 2003 1:03 PM
To: Iljitsch van Beijnum
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: IPv6 addressing limitations (was "national security")
> RFC 3513 mandates that all unicast IPv
> 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
Alas for this rosy vision, ICANN *tried* to boss the RIRs and get them to
sign contracts agreeing to pay it and obey it, but they balked. So all
credit to the RIRs - and none to ICANN - on this one.
On Mon, 1 Dec 2003, John C Klensin wrote:
>
>
> --On Monday, 01 December, 2003 07:24 -0500 "v
At 22:21 01/12/03, Paul Vixie wrote:
[EMAIL PROTECTED] ("J-F C. (Jefsey) Morfin") writes:
> 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.
good bye, sir.
--
Paul Vixie
Dear Mr. Vixie,
Things
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 S
--On Monday, 01 December, 2003 07:24 -0500 "vinton g. cerf"
<[EMAIL PROTECTED]> wrote:
karl, ICANN has responsibility to do what it can to make sure
the DNS and ICANN root system work. It does not have to
disenfranchise the RIRs and the root servers to do this.
Vint,
I would go even further th
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
[EMAIL PROTECTED] ("J-F C. (Jefsey) Morfin") writes:
> 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.
good bye, sir.
--
Paul Vixie
karl, ICANN has responsibility to do what it can to make sure the DNS and ICANN root
system work. It does not have to disenfranchise the RIRs and the root servers to do
this.
vint
At 12:02 AM 12/1/2003 -0800, Karl Auerbach wrote:
>Verisign will wave the flag of bias and ask ICANN to demonstra
Paul Vixie;
The switch to anycast for root servers is a good thing.
again there's a tense problem. there was no "switch to" anycast. the last
time those thirteen (or eight) ip addresses were each served by a single host
in a single location was some time in the early 1990's.
So?
Service by mul
On 1 Dec 2003, Paul Vixie wrote:
> > ICANN's obligation is to guarantee to the public the stability of DNS at
> > the root layer.
>
> i disagree...
>From ICANN's own bylaws:
The mission of The Internet Corporation for Assigned Names and Numbers
("ICANN") is to coordinate, at the overall le
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
karl, we raised the question of anycast risk with SECSAC in response to your
concerns and the conclusion was that the risks had not materialized in the
operation of anycast in roots that had already deployed it.
There are lots of ways in which routing can be wedged - until we get some
form of aut
karl wrote:
> ...
> ICANN's job is not to make decisions in secret, by unknown members of
> "staff", based on unknown criteria and using unknown assumptions. ...
that sentence is punctuated incorrectly. there's a period after "decisions."
> ... so, which is what you are saying has been done, i
On Sat, 29 Nov 2003, vinton g. cerf wrote:
> >I can't seem to recall during my 2 1/2 years on ICANN's board that there
> >ever was any non-trivial discussion, even in the secrecy of the Board's
> >private e-mail list or phone calls, on the matters of IP address
> >allocation or operation of the DN
On Sun, 30 Nov 2003 20:42:18 EST, Dean Anderson said:
> The main criticism of the IETF/IANA/ICANN by the rest of the world seems
> to fall under the democratic constituencies issue. People outside the US
> seem to distrust the US, and feel that their voices are not being heard,
> and that they ar
> IETF is to deliver technical solutions. IANA is to deliver a registry
> service. What is ICANN up to? Except what we agree: "to guest forums" to
> help consensus there.
>
> BTW is that very different from ITU? Just that Paul Twomey's Nov 19th
> document would have resulted from a painstakingly g/
At 17:35 30/11/03, Michael H. Lambert wrote:
Content-Transfer-Encoding: 7bit
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?
Sorry for this. The question was
i'm going to bend my own policy a bit and reply to a role account:
[EMAIL PROTECTED] (jfcm) writes:
> ... The interest is not sites nor network protection layers, but nations
> protection from what happens on or with the networks. This is in line
> with the White House document http://whitehouse
Iljitsch van Beijnum writes:
> It seems there are (or were) 450 million bicycles in China. Think about
> it: what's cheaper to mass produce, a 20 kilo steel bicycle with lots
> of intricate mechanics, or a simple 1 kilo plastic sub-laptop?
The bicycle, by far. The mechanics are not intricate, t
Iljitsch van Beijnum wrote:
I have a slightly better than handwaving indication that the current
statistics don't show the full picture. In the past 4 years we've seen
large scale always-on internet access deployment. However, this
doesn't show up in the address space usage statistics. So add
% Anycast may even have preceded the creation of ICANN - perhaps an IETF
% source or one of the root server operators can say when the first ANYCAST
% deployments were done.
Not an IETF source. In discussions on the earliest anycast
instance, there was general agreement that "M" wa
On 30-nov-03, at 4:17, [EMAIL PROTECTED] wrote:
The "at current burn rate" assumption is far from safe though...
Oh? Have any better-than-handwaving reasons to suspect the current
allocation rate will change drastically?
I have a slightly better than handwaving indication that the current
stati
Michel,
>
> The organization has 800 hosts, all behind NAT (they have PA space, NAT
> is there for renumbering ease), and there is only a small fraction of
> servers that have one-to-one NAT and therefore require a public IP per
> host. In your average 800 hosts network (if such a thing exists) i
> [EMAIL PROTECTED] wrote:
> I'm more than happy to accept any realistic projections
> that point to a change in the burn rate - if you know of
> something I've overlooked, please enlighten us
The "savings" due to NAT might be underestimated, which in turn pushes
the v4 exhaustion even further
On Sat, 29 Nov 2003 22:17:41 GMT, Tim Chown <[EMAIL PROTECTED]> said:
> The "at current burn rate" assumption is far from safe though...
Oh? Have any better-than-handwaving reasons to suspect the current allocation
rate will change drastically? I don't forsee the cellphone or embedded
markets ta
Dear John,
thank you for your comment even if it does not discuss the "internet
national survival kit". I am afraid it continues a qui pro quo where we
often say the same thing but from different points of view (not vision).
Where you look from inside your technology, and me from a user's point
nizationsn, 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.
Best regards.
jfc
vint cerf
>--
&
At 03:39 PM 11/29/2003 -0800, Karl Auerbach wrote:
>On Sat, 29 Nov 2003, vinton g. cerf wrote:
>
>> I strongly object to your characterization of ICANN as "abandoning"
>> the operation of roots and IP address allocation. These matters have
>> been the subject of discussion for some time.
>
>I can't
On Sat, 29 Nov 2003, vinton g. cerf wrote:
> I strongly object to your characterization of ICANN as "abandoning"
> the operation of roots and IP address allocation. These matters have
> been the subject of discussion for some time.
I can't seem to recall during my 2 1/2 years on ICANN's board tha
On Sat, 29 Nov 2003, Tim Chown wrote:
> On Fri, Nov 28, 2003 at 03:15:04PM -0500, [EMAIL PROTECTED] wrote:
> > On Fri, 28 Nov 2003 20:06:26 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]>
> > said:
> >
> > > 33 bits
> >
> > 8,589,934,592 times as many addresses. At current burn rates, it will
On Fri, Nov 28, 2003 at 03:15:04PM -0500, [EMAIL PROTECTED] wrote:
> On Fri, 28 Nov 2003 20:06:26 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said:
>
> > 33 bits
>
> 8,589,934,592 times as many addresses. At current burn rates, it will take
> us some 20 years to go through the *current* f
Karl,
I strongly object to your characterization of ICANN as "abandoning"
the operation of roots and IP address allocation. These matters have
been the subject of discussion for some time. ICANN absolutely
recognizes the critical role of the RIRs and the voluntary root
servers as part of the comp
ttp://www.cavebear.com/rw/apfi.htm ) ICANN will remain a non-technical
body that regulates and governs internet business practices.
As for this thread - national security - One has to remember that ICANN's
reaction to 9/11 was to create a committee. That committee is filled with
intelligent
At 05:49 PM 11/29/2003 +, Paul Robinson wrote:
>John C Klensin wrote:
>
>>With regard to ICANN and its processes, I don't much like the
>>way a good deal of that has turned out, even while I believe
>>that things are gradually getting better. I lament the set of
>>decisions that led to the US
John C Klensin wrote:
With regard to ICANN and its processes, I don't much like the
way a good deal of that has turned out, even while I believe
that things are gradually getting better. I lament the set of
decisions that led to the US Govt deciding that it needed to be
actively involved and to s
Jefsey,
You should also entertain the hypothesis that no one has
commented on those issues/suggestions because they are have been
discussed too many times before and are inconsistent with the
visions that drive the Internet. Some of them have even been
the subject of fairly careful evaluation an
At 00:49 29/11/03, [EMAIL PROTECTED] wrote:
OK.. change "HQ computer" to "www.ANYTHINGBIG.com", and change "enemy" to
"random hacker in another country". There's boxes that *have* to be visible
to the world because they provide service and connectivity to the outside
world - and you can't even han
At 23:20 28/11/03, Anthony G. Atkielski wrote:
> I am sure that many security officers or generals would feel unatease if
> they known their HQ IPv6 address can be just one unknown bit different from
> the IPv6 address of a ennemy computer.
Nah ... security officers and generals--if they are compet
On Fri, 28 Nov 2003 23:20:20 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said:
> jfcm writes:
>
> > I am sure that many security officers or generals would feel unatease if
> > they known their HQ IPv6 address can be just one unknown bit different from
> > the IPv6 address of a ennemy compu
jfcm writes:
> I am sure that many security officers or generals would feel unatease if
> they known their HQ IPv6 address can be just one unknown bit different from
> the IPv6 address of a ennemy computer.
Nah ... security officers and generals--if they are competent--don't put
their HQ computer
Dear Anthony,
RFC 2373 permits 6 plans. The best would be to organize them by purpose.
Not them all to do the same thing. Here we talk about national security not
about intellectual elegance.
When you are at war, you want your network to continue operating, not to
depend on a numeration
At 15:20 28/11/03, Jaap Akkerhuis 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.
Who is "we" in above paragraph?
Hi! Jaap,
"we" is
[EMAIL PROTECTED] writes:
> OK, so a /48 has 50% more bits than a /32. On the other hand,
> I've heard no *major* problems with end users getting their /32 from
> their provider, and there's 65,536 more /48s. Also, remember that many
> end users are getting *multiple* IP's from their provider fo
On Fri, 28 Nov 2003 18:40:53 +0100, Iljitsch van Beijnum said:
> a /48 further deminishes the available bits. The situation is most
> notable in the case of a home user, who would get a single IPv4 address
> but gets a /48 in IPv6. So we've quadrupled our address space (in bits)
> for a 50% gai
On Fri, 28 Nov 2003 20:06:26 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said:
> 33 bits
8,589,934,592 times as many addresses. At current burn rates, it will take
us some 20 years to go through the *current* free IPv4 space. And nobody's
proposed any killer app that will take millions o
Iljitsch,
Stop feeding the troll please.
Michel.
Iljitsch van Beijnum writes:
> Ah, I see what you mean now. However, the devision is a done deal as
> 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 has some important advantages,
[EMAIL PROTECTED] writes:
> 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.
Since those losses are not significantly diminished by doubling the
address length, why bothe
[EMAIL PROTECTED] writes:
> Exactly. And the *reason* why IPv6 has 128 bit addresses is because
> the designers realized that such losses happen ...
Such losses don't just happen. They are the result of incompetent
engineering.
Donald Eastlake 3rd writes:
> See RFC 1715, November 1994, and the endless discussions that appeared
> on a variety of mailing list about IPv6 addresses.
I guess the endless discussions didn't help, but that doesn't surprise
me.
Spencer Dawkins writes:
> Well, sure. And then you do routing aggregation how?
I was describing the simplest scheme that ensures use of the entire
address space, nothing more.
> I also deplore the waste of bits, and would love to hear
> alternatives...
I've described alternatives before, but no
On 28-nov-03, at 14:47, Anthony G. Atkielski wrote:
I guess not because I have no idea what you're talking about.
There is a natural tendency to think that by dividing a 128-bit address
field into two 64-bit fields, the address space is cut in half (or
perhaps not diminished at all).
Ah, I see wh
On Fri, 28 Nov 2003 14:52:11 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> 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
On Fri, 28 Nov 2003 14:47:41 +0100
"Anthony G. Atkielski" <[EMAIL PROTECTED]> wrote:
> (or perhaps not diminished at all). However, in reality, dividing the
> field in this way may reduce the address space by a factor of as much
> as nineteen orders of magnitude. Again and again, engineers make
ED]>
> Subject: Re[4]: national security
>
> Iljitsch van Beijnum writes:
>
> > I guess not because I have no idea what you're talking about.
>
> There is a natural tendency to think that by dividing a 128-bit address
> field into two 64-bit fields, the address spa
From: "Anthony G. Atkielski" <[EMAIL PROTECTED]>
To: "IETF Discussion" <[EMAIL PROTECTED]>
Sent: Friday, November 28, 2003 7:52 AM
Subject: Re[2]: national security
>
> In order to use the full potential address space, you must devise a
> scheme that a
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.
Who is "we" in above paragraph?
jaap
Jari Arkko writes:
> However, I do not believe these proposals consume any
> more address space than, say, manual or EUI-64
> based address assignment.
In order to use the full potential address space, you must devise a
scheme that allocates every single combination of bits. The simplest
scheme
Iljitsch van Beijnum writes:
> I guess not because I have no idea what you're talking about.
There is a natural tendency to think that by dividing a 128-bit address
field into two 64-bit fields, the address space is cut in half (or
perhaps not diminished at all). However, in reality, dividing th
or EUI-64
based address assignment. There's still just one address consumed per
node. Perhaps you were thinking that the address contains a MAC field?
This isn't strictly speaking the case, at least not in the way that
the MAC value would change from one packet to another.
Anyway, back to
On 28-nov-03, at 13:04, Anthony G. Atkielski wrote:
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) t
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 pos
On 27-nov-03, at 23:20, jfcm wrote:
Some others have technical implications. I would like to quote some
suggestions listed in the preparatory document, to get advices I
could quote at the meeting or in its report. Also to list the
alternative and additional suggestions some might do.
Ok, I'm n
Sorry for the typo - I miss my glasses :-) - http://rs.internic.net (not
ns.internic.net as I typed).
jfc
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.
The interest is not sites nor network protection layers, but nations
protection from what happens on or with the networks
101 - 177 of 177 matches
Mail list logo
