On Fri, 14 Oct 2005, John Payne wrote:
I'm also undecided about how I feel about the extra packets caused by the (I
forget the official term) discovery packets for shim6 for an end site with
say a hundred machines each with thousands of short lived TCP sessions.
The shim6 capability
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
On 16.10 16:04, Simon Leinen wrote:
Kevin Loch writes:
Does anyone have reachability data for c-root during this episode?
The RIPE NCC DNSMON service has some:
http://dnsmon.ripe.net/dns-servmon/server/plot?server=c.root-servers.nettype=dropststart=1128246543tstop=1128972253
If there
A top AS and top prefix talkers would be really useful.
Flowscan will do the top AS, out of the box.
It could be hacked to go further.
And guess what we find elsewhere on that nifty set
of pages referred to by Bill Manning?
http://www.caida.org/tools/
--Michael Dillon
RFC 3068 also has another problem -- not enough relays, or at least not
enough in logical locations. From my home in Texas, a traceroute shows
the
topologically closest instance of 192.88.99.1 to be in France. Nice
to
see that GBLX's native IPv6 network doesn't have any 6to4 relays in
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.
Paul Jakma wrote:
And 6to4 obviously won't fly for long after the 4 tank runs dry.
Hopefully it won't need to at that point as it is only intended as
a transitional step.
I like the simplicity of 6to4 and the way it preserves end-to-end
addresses. If only there was a way to adapt it's
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
This seems like a problem that could be solved in the
style of the CIDR report. Regular weekly reports of
v6 relays and locations as seen from various major ASes.
From my tr website I can see a few 6to4 gateways:
http://tr.meta.net.nz/output/2005-10-17_22:41_192.88.99.1.png
(beware, the
there is no hope in having operators explain to ietf that the current
path
is fruitless? certainly they can be made to see the light, yes?
you have not spent much time with the ivtf, have you?
In case you have never heard of the IVTF, Randy eloquently
summarizes it here:
- Original Message -
From: Peter Dambier [EMAIL PROTECTED]
To: Jeroen Massar [EMAIL PROTECTED]
Cc: Suresh Ramasubramanian [EMAIL PROTECTED]; Tony Li
[EMAIL PROTECTED]; Daniel Roesen [EMAIL PROTECTED]; Christoper L. Morrow
[EMAIL PROTECTED]; nanog@merit.edu
Sent: Monday, October 17,
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
man, 17,.10.2005 kl. 07.17 +0200, skrev Mikael Abrahamsson:
Both MPLS and any tunneled VPN over IP means the core won't have to know
about all those prefixes (think aggregation of addresses regionally in the
IP case and outer label in the MPLS case).
Hope you don't imply NAT and private
Another alternative is to force-align allocation and topology in some
way /other/ than by Providers (geographical allocation in whatever
hierarchy, IX allocation, whatever), such that networks were easily
aggregatable. Lots of objections though (the providers and geography
don't align
Just my 5 cents to the topic:
Don't you all think that IPv6 would not be so neccessary for the very
long time yet, if the IPv4 allocation scheme would be done right from
the very very beginning?
If the allocation policies would be something like the ones for ASn's.
I.e. when you ask for IP
On Mon, 17 Oct 2005, Per Heldal wrote:
man, 17,.10.2005 kl. 07.17 +0200, skrev Mikael Abrahamsson:
Both MPLS and any tunneled VPN over IP means the core won't have to know
about all those prefixes (think aggregation of addresses regionally in the
IP case and outer label in the MPLS case).
They've been asking for that as well I think. I certainly don't want to
have 1M+ routes for JUST the Internet to worry about anytime soon, I'd
hate to see over 300k for real Internet routes anytime soon :( Much of
today's hardware doesn't seem so happy around that number :( Operators
and
On Sun, 16 Oct 2005, Tony Li wrote:
This is completely orthogonal to a real identifier/locator split,
which would divide what we know of as the 'address' into two
separate spaces, one which says where the node is, topologically,
and one which says who the node is.
Hmm, no idea whether it's
On Mon, 17 Oct 2005, [EMAIL PROTECTED] wrote:
I agree that the end state is *NOT* 100% multihoming. It is too
complex for most people and there is no business justification for
it. But an awful lot of business customers will be able to justify
multihoming. That is part and parcel of the
--- 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
[EMAIL PROTECTED] wrote:
Another alternative is to force-align allocation and topology in some
way /other/ than by Providers (geographical allocation in whatever
hierarchy, IX allocation, whatever), such that networks were easily
aggregatable. Lots of objections though (the providers and
On Mon, Oct 17, 2005 at 12:08:38PM +0100,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 28 lines which said:
There are 437 cities of 1 million or more population. There are
roughly 5,000 cities of over 100,000 population. And there are
3,047,000 named communities in the world.
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 [EMAIL PROTECTED] wrote:
I agree that the end state is *NOT* 100% multihoming. It is
too complex for most people and there is no business
justification for it. But an awful lot of business customers
will be able to justify multihoming. That is part and parcel
of the
On Mon, 2005-10-17 at 11:39 +0100, [EMAIL PROTECTED] wrote:
Another alternative is to force-align allocation and topology in some
way /other/ than by Providers (geographical allocation in whatever
hierarchy, IX allocation, whatever), such that networks were easily
aggregatable. Lots of
On Tue, 2005-10-18 at 01:07 +1300, Simon Lyall wrote:
My son tells me that is what I want so I setup a payment of $5 per month
to him. In 10 minutes from start to finish my house's /54 is multi-homed,
whatever that means.
You cover the payment part, partially. But now the fun parts:
- which
Is VJ compression considered a violation of the end-to-end principle?
VJ compression happens in the middle of the network, between
two routers/gateways. End-to-end refers to the hosts, i.e.
the computers which host the end users' applications. Of
course, in the old days, many of these hosts
Many people pick this up and twist it into ~the network has to be
application agnostic~ and then use this against NATs or firewalls,
which is simply a misuse of the principle.
Personally, I think that NAT's interference with the
communication between hosts is similar to the way in
which
On Mon, 17 Oct 2005, Per Heldal wrote:
Well, let's try to turn the problem on its head and see if thats
clearer; Imagine an internet where only your closest neighbors know you
exist. The rest of the internet knows nothing about you, except there
are mechanisms that let them track you down when
I think we need a researcher to sit down and
figure out exactly what this would look like
in a sample city and a sample national provider.
especially:
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt
will be quite of your liking.
Not at all. This proposal is all about allocating
man, 17,.10.2005 kl. 14.22 +0200, skrev Jeroen Massar:
On Tue, 2005-10-18 at 01:07 +1300, Simon Lyall wrote:
My son tells me that is what I want so I setup a payment of $5 per month
to him. In 10 minutes from start to finish my house's /54 is multi-homed,
whatever that means.
You
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 term
cost?
Isn't that GENI already out of the
is that anything like using, in Cisco terms, a fast-switching cache
vs a FIB?
On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote:
Well, let's try to turn the problem on its head and see if thats
clearer; Imagine an internet where only your closest neighbors
know you exist. The rest of
On Sat, 15 Oct 2005, Paul Vixie wrote:
...the necessary evil called CIDR. evil because it locked customers
into their providers, entrenched the existing large providers
against future providers, and made it hard or impossible for the
average endusing company to
man, 17,.10.2005 kl. 07.25 -0700, skrev Fred Baker:
is that anything like using, in Cisco terms, a fast-switching cache
vs a FIB?
I'll bite as I wrote the paragraph you're quoting;
Actually, hanging on to the old concepts may be more confusing than
trying to look at it in completely new
Paul,
This is completely orthogonal to a real identifier/locator split,
which would divide what we know of as the 'address' into two
separate spaces, one which says where the node is,
topologically, and one which says who the node is.
Hmm, no idea whether it's a good idea or not, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
well, if the existing discussion is not enough, cisco has an interesting
article out...see /. for more information.
http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html
wearing my flame suite :-)
regards,
/virendra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yo Michael!
On Mon, 17 Oct 2005, [EMAIL PROTECTED] wrote:
Here, the suggestion is that netblocks should
be allocated to cities, not to providers. Within
a city, providers would get a subset of the city
address block to meet their local
That reminds me of anycasting or routing issues.
Hackers did use this technique to make use of ip addresses not
really allocated. There would be no need for IPv6 if this was
more widespread.
How about claiming to be f.root-servers.net and setting up our
own root :)
Regards,
Peter and Karin
On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote:
I'm not sure I agree that the end state is 100% multihoming. I can
certainly agree that more multihoming is coming. Many more people are
pushing for multihoming today than in previous years, apparently telco
instability (financial not
OK. What you just described is akin to an enterprise network with a
default route. It's also akin to the way DNS works.
The big question becomes not only who knows what I need to know,
but how do I know that they actually know it?. For example, let's
postulate that the concept is that
man, 17,.10.2005 kl. 15.47 +, skrev Mikael Abrahamsson:
On Mon, 17 Oct 2005, Per Heldal wrote:
Well, let's try to turn the problem on its head and see if thats
clearer; Imagine an internet where only your closest neighbors know you
exist. The rest of the internet knows nothing about
man, 17,.10.2005 kl. 19.16 +0200, skrev Peter Dambier:
That reminds me of anycasting or routing issues.
Hackers did use this technique to make use of ip addresses not
really allocated. There would be no need for IPv6 if this was
more widespread.
How about claiming to be
Imagine a situation with no access to any means of direct communication
(phone etc). You've got a message to deliver to some person, and have no
idea where to find that person. Chances are there's a group of people
nearby you can ask. They may know how to find the one you're looking
for. If
On Mon, Oct 17, 2005 at 09:03:45AM -1000, Randy Bush wrote:
Imagine a situation with no access to any means of direct communication
(phone etc). You've got a message to deliver to some person, and have no
idea where to find that person. Chances are there's a group of people
nearby you
mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker:
OK. What you just described is akin to an enterprise network with a
default route. It's also akin to the way DNS works.
No default, just one or more *potential* routes.
Your input is appreciated, and yes I'm very much aware that many people
who
check out The Landmark Hierarchy: A New Hierarchy for Routing in Very
Large Networks; Paul Tsuchiya; 1989.
great stuff... i have a hardcopy. is it online yet?
dunno if i would say great. but certainly good.
http://portal.acm.org/citation.cfm?id=52329
randy
--bill (checking citesear...)
does that only yield rare papers :-)
and citeseer does not have the paper, only a few cites to it
randy
That is an assumption that I haven't found it necessary to make. I
have concluded that there is no real debate about whether the
Internet will have to change to something that gives us the ability
to directly address (e.g. not behind a NAT, which imposes some
interesting requirements at
Fred,
If we are able to reduce the routing table size by an order of
magnitude, I don't see that we have a requirement to fundamentally
change the routing technology to support it. We may *want* to (and
yes, I would like to, for various reasons), but that is a different
assertion.
works for me - I did say I'd like to change the routing protocol -
but I think the routing protocol can be changed asynchronously, and
will have to.
On Oct 17, 2005, at 1:51 PM, Tony Li wrote:
Fred,
If we are able to reduce the routing table size by an order of
magnitude, I don't
It doesn't look like were talking about the same thing.
A. Address conservation and aggregation (IPv4 and IPv6) is very
important to get the most out of what we've got. Read; limit the
combined routing-table to a manageable size whatever that may be.
B. There seems to be widespread fear that
works for me - I did say I'd like to change the routing protocol -
but I think the routing protocol can be changed asynchronously, and
will have to.
and that is what the other v6 ivory tower crew said a decade ago.
which is why we have the disaster we have now.
randy
There is a fundamental difference between a one-time reduction in the
table and a fundamental dissipation of the forces that cause it to
bloat in the first place. Simply reducing the table as a one-off
only buys you linearly more time. Eliminating the drivers for bloat
buys you technology
At 04:51 PM 10/17/2005, Tony Li wrote:
Fred,
If we are able to reduce the routing table size by an order of
magnitude, I don't see that we have a requirement to fundamentally
change the routing technology to support it. We may *want* to (and
yes, I would like to, for various reasons), but
Daniel,
If we're going to put the world thru the pain of change, it seems
that we should do our best to ensure that it never, ever has to
happen again.
That's the goal here? To ensure we'll never have another protocol
transition? I hope you realize what a flawed statement that is. We
we agree that at least initially every prefix allocated should belong
to a different AS (eg, no AS gets more than one); the fly in that is
whether there is an ISP somewhere that is so truly large that it
needs two super-sized blocks. I don't know if such exists, but one
hopes it is very
On Oct 17, 2005, at 2:24 PM, Tony Li wrote:
To not even *attempt* to avoid future all-systems changes is
nothing short of negligent, IMHO.
On Oct 17, 2005, at 2:17 PM, Randy Bush wrote:
and that is what the other v6 ivory tower crew said a decade ago.
which is why we have the disaster we
On Mon, 17 Oct 2005 14:24:08 -0700
Tony Li [EMAIL PROTECTED] wrote:
Dear Tony et al.;
This is beginning to sound like an IETF or IRTF mail list, and, lo!, I get an
email today
from Leslie Daigle :
A new mailing list has been created to provide a forum for general
discussion of Internet
- Original Message -
From: Fred Baker [EMAIL PROTECTED]
To: Per Heldal [EMAIL PROTECTED]
Cc: nanog@merit.edu
Sent: Monday, October 17, 2005 15:12
Subject: Re: And Now for Something Completely Different (was Re: IPv6 news)
That is an assumption that I haven't found it necessary to
Thus spake Fred Baker [EMAIL PROTECTED]
The RIRs have been trying pretty hard to make IPv6 allocations be one
prefix per ISP, with truly large edge networks being treated as
functionally equivalent to an ISP (PI addressing without admitting it is
being done). Make the bald assertion that
What we need is an interdomain routing system that can either (a)
drastically reduce the incremental cost of additional prefixes in the DFZ,
or (b) move the exist cost out of the DFZ to the people who want to
multihome. Both probably mean ditching BGP4 and moving to some sort of
Fred,
So the routing problem was looked at, and making a fundamental
routing change was rejected by both the operational community and
the routing folks.
No, IPv6 doesn't fix (or even change) the routing of the system,
and that problem will fester until it becomes important enough to
[EMAIL PROTECTED] (Tony Li) writes:
Specifically, the IAB should call for a halt to IPv6 deployment until
consensus is reached on a scalable routing architecture. I realize
that this is painful, but continuing to deploy is simply creating a
v6 mortgage that we cannot afford to pay
On Mon, 17 Oct 2005, Tony Li wrote:
True. Even better, you get to change this binding (mobility) or
have multiple bindings (multihoming).
Indeed.
True enough, but unfortunately, it's not done in a way that we can
make use of the identifier in the routing subsystem or in the
transport
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
On Mon, 17 Oct 2005, Mikael Abrahamsson wrote:
Also, if everybody got their equal size subnet delegation from each
ISP then it shouldnt be that much of a problem to run two
networks side-by-side by using the subnet part of the delegation
equal to both networks, but keep the prefix separate.
On Mon, 17 Oct 2005, Andre Oppermann wrote:
We all know how well carrier phone number routing and number
portability works, don't we?
EWORKSFORME (and everyone else here). Took a good bit of very firm
pressure from ComReg, the telecoms wathdog/regulator here, to
overcome negative reaction
71 matches
Mail list logo
