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
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
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
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
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
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 each
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
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
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
Keith,
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 implementation
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 implementation
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
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
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
14 matches
Mail list logo
