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 a
At 23:42 08/12/03, Iljitsch van Beijnum wrote:
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 lis
-BEGIN PGP SIGNED MESSAGE-
Joao Damas [mailto:[EMAIL PROTECTED] wrote:
> 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.
Hay,
On Mon, Dec 08, 2003 at 10:16:03PM +0100, Gert Doering wrote:
> Hi,
>
> On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
> > There are currently quite some ISP's who filter anything >/35.
> > Generally ISP's should be filtering on allocation boundaries.
> > Thus if a certain pr
On 9 Dec, 2003, at 2:20, Jeroen Massar wrote:
-BEGIN PGP SIGNED MESSAGE-
[2 mails into one again]
Bill Manning [mailto:[EMAIL PROTECTED] wrote:
% 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
Hi Bill,
Bill Manning <[EMAIL PROTECTED]> wrote:
[...]
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
leo vegoda <[EMAIL PROTECTED]> wrote:
[...]
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.
An extra "don't" slipped in there.
Sorry,
--
leo vegoda
RIPE NCC
Registration Services
Bill Manning;
% 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 desig
% We assign small networks to IXPs.
%
% The document has the following in it reflecting this:
%
% CIDR block Smallest RIPE NCCSmallest RIPE NCC
% Allocation Assignment
% 2001:0600::/23 /35 /48
%
% Again, if people feel th
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
On 10-dec-03, at 10:28, leo vegoda wrote:
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/ipaddre
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
On 8-dec-03, at 21:00, Paul Vixie wrote:
for example, bill says above that "/35 routes
are being discouraged" and that's probably true but "by whom?" and
"where?"
It is generally understood in the routing community that some kind of
prefix length f
On 10-dec-03, at 10:28, leo vegoda wrote:
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
In fact, we h
% > 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 t
> 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,
-BEGIN PGP SIGNED MESSAGE-
[2 mails into one again]
Bill Manning [mailto:[EMAIL PROTECTED] wrote:
> % 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
% > 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 a
% 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/softwar
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
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?
Don't tell me t
-BEGIN PGP SIGNED MESSAGE-
Gert Doering [mailto:[EMAIL PROTECTED] wrote:
> On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
> > There are currently quite some ISP's who filter anything >/35.
> > Generally ISP's should be filtering on allocation boundaries.
> > Thus if a cert
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
[EMAIL PROTECTED] 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 th
[my apologies for burning so much bandwith]
On 8-dec-03, at 22:17, Zefram wrote:
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
On 8-dec-03, at 22:01, Jeroen Massar wrote:
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)
So how are ISPs supp
On 8-dec-03, at 21:00, Paul Vixie wrote:
for example, bill says above that "/35 routes
are being discouraged" and that's probably true but "by whom?" and
"where?"
It is generally understood in the routing community that some kind of
prefix length filtering is desirable and/or necessary. So the q
-BEGIN PGP SIGNED MESSAGE-
[This should go to v6ops@ or [EMAIL PROTECTED] :) ]
Zefram wrote:
> 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. I
On Mon, 08 Dec 2003 21:17:00 GMT, Zefram <[EMAIL PROTECTED]> said:
> 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
% 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 allocation
On 8 Dec 2003, at 15:25, Masataka Ohta wrote:
I'm afraid F servers does not follow the intention of my original
proposal of anycast root servers.
This may well be the case (I haven't read your original proposal).
Apologies if I gave the impression that I thought to the contrary.
Finally, using o
Hi,
On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
> 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
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
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 grou
-BEGIN PGP SIGNED MESSAGE-
Paul Vixie 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... :)
>
> i think the important points fo
Joe Abley;
I'm afraid F servers does not follow the intention of my original
proposal of anycast root servers.
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.
% > /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 is
Joe Abley;
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 t
> /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, (
% > (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
On 7 Dec 2003, at 07:21, Iljitsch van Beijnum wrote:
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 pa
On 8 Dec 2003, at 10:14, Dean Anderson wrote:
Also, anycasting doesn't work for TCP.
Would you care to elaborate on "doesn't work"?
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.
It
On Sun, 7 Dec 2003, Iljitsch van Beijnum wrote:
> On 6-dec-03, at 23:04, Dean Anderson wrote:
>
> >> 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.
uld
agree that unless IPv6 is first implemented with two different numbering
plans, we will never know if it (and each installed IPv6 system) supports
multiple numbering plans, creating ourselves a Y2K syndrom. So why not to
work on both, in parallel, since anyway national security will call for i
On Sat, 2003-12-06 at 10:18, Iljitsch van Beijnum wrote:
On 5-dec-03, at 17:16, Dean Anderson wrote:
> 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
> > 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 add
On 7-dec-03, at 20:52, Paul Vixie wrote:
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.
Ok... But does it also do anything useful? My
> > ... oversight.
>
> 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
On 7-dec-03, at 2:26, Paul Vixie wrote:
... (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.)
congradulations, you're the millionth person to think that was an
oversight.
I don't think this is an oversight, I'm
jfcm wrote:
[..]
> I suggest we
> start a specialized WG with a clean shit study charter.
Well you've come to the right place! Don't get it much cleaner
than around here, that's for sure.
gja
[EMAIL PROTECTED] (Iljitsch van Beijnum) writes:
> ... (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.)
congradulations, you're the millionth person to think that was an oversight.
> I don't have a problem w
%
% 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 .
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
On 6-dec-03, at 23:04, Dean Anderson wrote:
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.
That seems to argue against anycast...
If there were 65 actual roo
I don't know what jefsey means by "IP zones"
Louis and I met in 1973 and his datagram ideas, sliding window ideas for flow control,
influenced my thinking about TCP. Gerard LeLann, who worked in Louis Pouzin's group at
IRIA came to Stanford in 1974 to work on the TCP and Internet. IEN 48 refers
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:
> On 5-dec-03, at 17
dy decided and engaged.
To try to add some last minute competitve edge to IETF (sometimes works),
in having the resolutions made more favorable, I started the "National
Security" thread (something they could fully understand) and made sure that
people I know, who could make a few words
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
At 17:28 05/12/03, John C Klensin wrote:
The first "mail" program at MIT, as well as what was probably the the
first instance of what we would now call instant messaging, was specified
and implemented by Tom Van Vleck and Noel Morris in around 1964 or 65,
maybe a bit earlier (I have documentatio
Jefsey,
which "we" are you speaking on behalf of?
--On 27. november 2003 23:20 +0100 jfcm <[EMAIL PROTECTED]> 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.
On 5-dec-03, at 17:16, Dean Anderson wrote:
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 domai
At 05:12 05/12/03, Franck Martin wrote:
On Fri, 2003-12-05 at 15:32, jfcm wrote:
> 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?
Because somebody will complain.
On Fri, 05 Dec 2003, Paul Vixie wrote:
> 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.
Apologies for taking this thread perhaps even further of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note that I did not mean my comment as sarcasm or irony. If I would
have, I would have put a ":-)" after it. I didn't. I am a newbie. I am
still having déja vu.
- - kurtis -
On fredag, dec 5, 2003, at 15:35 Europe/Stockholm, jfcm wrote:
> At 21:2
--On Friday, 05 December, 2003 15:35 +0100 jfcm <[EMAIL PROTECTED]>
wrote:
...
But I have Louis Pouzin involved (we both are on Eurolinc BoD)
who you may know. He specified the first "mail" program at
MIT, the scripts, the end to end datagram, the IP zones
(recently Vint recalled the Internet c
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 iso
At 21:22 02/12/03, Kurt Erik Lindqvist wrote:
Hasn't this idea been killed enough? I am a newbie on the Internet
(only been here since 1988) and _I_ am fed up with this discussion.
Hi! Kurt,
did not see that one. I will respond it because it may help you
understanding. I am also a newbie as I only
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
countries to request installation of root servers, and I know about 20
Pacific Islands countries that need root-
Masataka Ohta writes:
> 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
c
Anthony G. Atkielski;
On the Internet these days, it is a matter of hardware.
And the hardware is a matter of firmware.
No, it is not.
Instead, software in routers is often called firmware.
Masataka Ohta
Masataka Ohta writes:
> On the Internet these days, it is a matter of hardware.
And the hardware is a matter of firmware.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On torsdag, dec 4, 2003, at 23:44 Europe/Stockholm, Franck Martin wrote:
> There are now organisations installing root servers in all countries
> that want one.
I am the CEO of one of those organizations.
- - kurtis -
-BEGIN PGP SIGNATURE
On Fri, 2003-12-05 at 15:32, jfcm wrote:
> 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?
Because somebody will complain... ;)
Franck Martin
[EMAIL PROT
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
At 02:5
On 5 Dec 2003, Paul Vixie wrote:
> 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
On Fri, Dec 05, 2003 at 10:44:00AM +1200, Franck Martin wrote:
> 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.
On Fri, 2003-12-05 at 12:16, Suzanne Wool
On Fri, 2003-12-05 at 12:16, Suzanne Woolf wrote:
On Fri, Dec 05, 2003 at 10:44:00AM +1200, Franck Martin wrote:
> 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
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
On Fri, 2003-12-05 at 09:00, Kurt Erik Lindqvist wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> > 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 e
Anthony G. Atkielski;
Unlimited? The limitation on public part is 20 digits.
That's just a matter of programming these days.
On the Internet these days, it is a matter of hardware.
Ad hoc extension beyond hardware supported length
at that time will fatally hurt performance.
What hardware limits
s 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 just note that you never cared about C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> 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
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
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, alternat
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.
> I just note that you never cared about Consumers organizationsn, while
> a world e-consu
Masataka Ohta writes:
> 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?
Johnny Eriksson writes:
> You can start designing the ASICs now. It won't be easy.
It worked with Strowger switches and crossbar mechanical exchanges; why
would it be more difficult with ASICs?
Anthony G. Atkielski;
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 alre
"Anthony G. Atkielski" <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] 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
> exten
[EMAIL PROTECTED] 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 unli
Iljitsch;
We need to keep the size of the
global routing table in check, which means "wasting" a good deal of
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 eac
On Thu, 04 Dec 2003 00:53:57 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said:
> 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 sing
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
On 3-dec-03, at 21:21, Anthony G. Atkielski wrote:
It was well understood that it was important to keep most of the IPv6
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 alre
On 3 Dec 2003, 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 th
Bob Hinden writes:
> 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
>
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
That not correct. See:
http://www.iana.org/assignments/ipv6-address-space
Where it say
r 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
On Wed, 2003-12-03 at 08:27, Kurt Erik Lindqvist wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 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 wo
Iljitsch;
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 h
Iljitsch van Beijnum writes:
> 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.
But that represents 5,192,296,858,530,000,000,000,000,000,000,000
addresses. W
Kurt Erik Lindqvist writes:
> so you are making claims and comments on something you don't even have
> bothered to read the basic documentation on. Wow.
Wait twenty years, and we'll see who's surprised.
1 - 100 of 177 matches
Mail list logo
