--- David Conrad [EMAIL PROTECTED] wrote:
On Oct 17, 2005, at 10:39 PM, Paul Jakma wrote:
Wrong issue. What I'm unhappy about is not the
size of the
address - you'll notice that I didn't say make
the whole address
space smaller. What I'm unhappy about is the
exceedingly sparse
On Oct 17, 2005, at 10:39 PM, Paul Jakma wrote:
Wrong issue. What I'm unhappy about is not the size of the
address - you'll notice that I didn't say make the whole address
space smaller. What I'm unhappy about is the exceedingly sparse
allocation policies
You can allocate to 100%
On Mon, 2005-10-17 at 02:52 +, Christopher L. Morrow wrote:
On Sat, 15 Oct 2005, Tony Li wrote:
Hopefully, that will reach a point where the operators show up and
participate at IETF, rather than the IETF coming to NANOG.
agreed.
Full ack. Ops should really realize that they can
Hi David,
On Sun, 16 Oct 2005 16:49:25 -0700 (PDT)
David Barak [EMAIL PROTECTED] wrote:
snip
I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single
If we're going to do that, we may as well also start reclaiming
those 48 bit MAC addresses that come with ethernet cards. After
all, nobody would need anymore than say 12 to 13 bits to address
their LANs.
so you think that layer-2 lans scale well above 12-13 bits?
which ones in particular?
Hi Randy,
On Sun, 16 Oct 2005 23:08:49 -1000
Randy Bush [EMAIL PROTECTED] wrote:
If we're going to do that, we may as well also start reclaiming
those 48 bit MAC addresses that come with ethernet cards. After
all, nobody would need anymore than say 12 to 13 bits to address
their LANs.
Mark Smith wrote:
We didn't
get 48 bits because we needed them (although convenience is a need, if
it wasn't we'd still be hand winding our car engines to start them ). We
got them because it made doing other things much easier, such as (near)
guarantees of world wide unique NIC addresses,
From an end-user:
I dont know what I should need an /64 for but it's barf, barf anyhow.
My routing table is telling me I have got a /124 only:
The tunnel (network) *::0
The end of the tunnel *::1
Me *::2
The tunnel broadcast *::3
Right now I have the impression we are only enusers.
Right now
, 2005 5:43 AM
Subject: Re: IPv6 daydreams
--- snip ---
Sorry I have to stop now. Some policemen want to talk with me
about a major fraud done with my IPv6 tunnel.
See you later :)
no, they're just there to help out the guys in the white lab coats holding
an odd-looking jacket. better late
Mohacsi Janos wrote:
On Mon, 17 Oct 2005, Peter Dambier wrote:
From an end-user:
I dont know what I should need an /64 for but it's barf, barf anyhow.
My routing table is telling me I have got a /124 only:
The tunnel (network) *::0
The end of the tunnel *::1
Me *::2
The tunnel
--- Mark Smith
[EMAIL PROTECTED]
wrote:
Why have people, who are unhappy about /64s for
IPv6, been happy enough
to accept 48 bit addresses on their LANs for at
least 15 years? Why
aren't people complaining today about the overheads
of 48 bit MAC
addresses on their 1 or 10Gbps
On Mon, 2005-10-17 at 04:43 -0700, David Barak wrote:
What I'm unhappy
about is the exceedingly sparse allocation policies
which mean that any enduser allocation represents a
ridiculously large number of possible hosts.
See the HD ration + proposals about sizing it down to a /56 as mentioned
On Mon, 17 Oct 2005, David Barak wrote:
Wrong issue. What I'm unhappy about is not the size of the address
- you'll notice that I didn't say make the whole address space
smaller. What I'm unhappy about is the exceedingly sparse
allocation policies
You can allocate to 100% density on the
--- Randy Bush [EMAIL PROTECTED] wrote:
so, if we had a free hand and ignored the dogmas,
what would we
change about the v6 architecture to make it really
deployable
and scalable and have compatibility with and a
transition path
from v4 without massive kludging, complexity, and
long
Okay, I'll bite - If I were king, here's what I'd want
to see:
[ changes to current policies, not architecture, elided ]
let's first agree on some goals
o really big address space, not the v6 fixed 32 bit
limited game. (old dogs will now bay for variable
length, aroo!)
o a
o really big address space, not the v6 fixed 32 bit
s/32/64/
sorry
On Sun, Oct 16, 2005 at 05:20:12PM -1000, Randy Bush wrote:
Okay, I'll bite - If I were king, here's what I'd want
to see:
[ changes to current policies, not architecture, elided ]
let's first agree on some goals
o really big address space, not the v6 fixed 32 bit
limited
On 17/10/05, David Barak [EMAIL PROTECTED] wrote:
I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single IPv4-size universe,
and make the default end-customer
o a routing system which has the ability to scale really
well in the presence of fewer and fewer nodes (think
sites) where out-degree == 1
sure... maybe. is there the presumption of e2e here?
i think so, for various valies of e2e
o mobility
process mobility? latency tolerent?
19 matches
Mail list logo
