Just to clear up a few misconceptions:
begin explanation current situation
Router advertisements are exactly what the name suggests, routers advertising
their presence. The first function of router advertisements is to tell hosts
where the routers are, so the hosts can install a
On 24 Dec 2011, at 6:32 , Glen Kent wrote:
I am trying to understand why standards say that using a subnet
prefix length other than a /64 will break many features of IPv6,
including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND)
[RFC3971], .. [reference RFC 5375]
For stateless
valdis.kletni...@vt.edu wrote:
IPv6 does not work well in many environments.
Feel free to try to deprecate *everything* that doesn't work well in many
environments.
Why not?
Heck, SMTP doesn't work well in many environments (it's done in
cleartext unless you deploy STARTTLS, it's subject
Your straw man argument (which is what this has become) is just
dancing around the real issue. You're going to have to back up and
make your case for us, rather than trying to respond to one-liners
made (most of which were sarcastic, by the way).
You have yet to identify who (beyond yourself) is
On Wed, Dec 28, 2011 at 6:23 AM, Iljitsch van Beijnum
iljit...@muada.com wrote:
Also somehow the rule that all normal address space must use 64-bit interface
identifiers found its way into the specs for no reason that I have ever been
able
to uncover. On the other hand there's also the rule
Iljitsch van Beijnum wrote:
Just to clear up a few misconceptions:
Only to add yet another misconception without any clearing up?
Router advertisements are exactly what the name suggests,
routers advertising their presence.
The first function of router advertisements is to tell
hosts where
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
Granted that the notion of default router of IPv4 is no better
than that of IPv6.
Please present a reasonable alternative.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University
Ray Soucy wrote:
Your straw man argument (which is what this has become) is just
dancing around the real issue.� You're going to have to back up and
make your case for us, rather than trying to respond to one-liners
made (most of which were sarcastic, by the way).
No counter argument possible
Ray Soucy wrote:
Granted that the notion of default router of IPv4 is no better
than that of IPv6.
Please present a reasonable alternative.
According to the end to end argument, the only possible solution
to the problem, with no complete or correct alternatives, is to
let hosts directly
On 28 Dec 2011, at 13:26 , Ray Soucy wrote:
Granted that the notion of default router of IPv4 is no better
than that of IPv6.
Please present a reasonable alternative.
Obviously reducing down the entire DFZ to a single default route is a bad case
of premature optimization, which we all know
Iljitsch van Beijnum wrote:
Granted that the notion of default router of IPv4 is no better
than that of IPv6.
Please present a reasonable alternative.
Obviously reducing down the entire DFZ to a single default route
is a bad case of premature optimization,
Stop confusing default router
On the other hand there's also the rule that IPv6 is classless and therefore
routing on any prefix length must be supported, although for some
implementations forwarding based on /64 is somewhat less efficient.
Can you please name names for the somewhat less efficient part? I've
seen this
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
According to the end to end argument, the only possible solution
to the problem, with no complete or correct alternatives, is to
let hosts directly participate in IGP activities.
See the paper by Saltzer et. al.
So your entire
On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
No counter argument possible against such abstract nonsense.
Yes. That was my point.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of
Most vendors have a TCAM that by default does IPv6 routing for netmasks =64.
They have a separate TCAM (which is usually limited in size) that does
routing for masks 64 and =128.
TCAMs are expensive and increase the BOM cost of routers. Storing
routes with masks 64 takes up twice the number of
On Dec 28, 7:10 am, sth...@nethelp.no wrote:
On the other hand there's also the rule that IPv6 is classless and
therefore routing on any prefix length must be supported, although for some
implementations forwarding based on /64 is somewhat less efficient.
Can you please name names for
Most vendors have a TCAM that by default does IPv6 routing for netmasks =64.
They have a separate TCAM (which is usually limited in size) that does
routing for masks 64 and =128.
Please provide references. I haven't seen any documentation of such an
architecture myself.
TCAMs are expensive
Can you please name names for the somewhat less efficient part? I've
seen this and similar claims several times, but the lack of specific
information is rather astounding.
Well, I do know if you look at the specs for most newer L3 switches,
they will often say something like max IPv4
I mean no disrespect.
What I meant by that post was that I look forward to reading something
along the lines of:
8
1. I believe RA should be moved to HISTORICAL status because of the
following concerns:
2. A better way to provide routing information to host systems would be:
8
It's fairly common knowledge that most of our systems work on 64-bit
at best (and more commonly 32-bit still).
If every route is nicely split at the 64-bit boundary, then it saves a
step in matching the prefix. Admittedly a very inexpensive step.
I expect that most hardware and software
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
valdis.kletni...@vt.edu wrote:
SNIP
In this case, the following statement in RFC1883:
If the minimum time for rebooting the node is known (often more than
6 seconds),
is the wrong assumption which made RA annoying.
On Dec 28, 8:50 am, sth...@nethelp.no wrote:
It might lead you to believe so - however, I believe this would be
commercial suicide for hardware forwarding boxes because they would no
longer be able to handle IPv6 at line rate for prefixes needing more
than 64 bit lookups. It would also be
For what its worth I haven't stress tested it or anything, but I
haven't seen any evidence on any of our RSP/SUP 720 boxes that would
have caused me to think that routing and forwarding isn't being done
in hardware, and we make liberal use of prefixes longer than 64
(including 126 for every link
If every route is nicely split at the 64-bit boundary, then it saves a
step in matching the prefix. Admittedly a very inexpensive step.
My point here is that IPv6 is still defined as longest prefix match,
so unless you *know* that all prefixes are = 64 bits, you still need
the longer match.
In a message written on Wed, Dec 28, 2011 at 08:33:23PM +0900, Masataka Ohta
wrote:
However, assuming you change the cells every 100m in average
and you are moving at 100km/h, you must change the cells every
3.6 seconds in average, which means you must be able to change
the cells frequently,
On Wed, Dec 28, 2011 at 7:28 AM, TJ trej...@gmail.com wrote:
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
valdis.kletni...@vt.edu wrote:
SNIP
In this case, the following statement in RFC1883:
If the minimum time for rebooting the node is known (often more than
6
In a message written on Wed, Dec 28, 2011 at 10:19:54AM -0500, Ray Soucy wrote:
If every route is nicely split at the 64-bit boundary, then it saves a
step in matching the prefix. Admittedly a very inexpensive step.
I expect that most hardware and software implementations store IPv6 as
So a typical forwarding step is already a two step process:
Look up variable length prefix to get next hop.
Look up 128 bit next hop to get forwarding information.
Wrong.
You only do a lookup once.
You look up a TCAM or a hash table that gives you the next hop for a route.
You DONT need
On Dec 28, 9:44 am, Ray Soucy r...@maine.edu wrote:
For what its worth I haven't stress tested it or anything, but I
haven't seen any evidence on any of our RSP/SUP 720 boxes that would
have caused me to think that routing and forwarding isn't being done
in hardware, and we make liberal use
On Wed, 28 Dec 2011 21:56:19 +0900, Masataka Ohta said:
According to the end to end argument, the only possible solution
to the problem, with no complete or correct alternatives, is to
let hosts directly participate in IGP activities.
That's only for hosts that are actively trying to
I did look into this a bit before.
To be more specific:
IPv6 CEF appears to be functioning normally for prefixes longer than
64-bit on my 720(s).
I'm not seeing evidence of unexpected punting.
The CPU utilization of the software process that would handle IPv6
being punted to software, IPv6
IPv6 CEF appears to be functioning normally for prefixes longer than
64-bit on my 720(s).
I'm not seeing evidence of unexpected punting.
The CPU utilization of the software process that would handle IPv6
being punted to software, IPv6 Input, is at a steady %0.00 average
(with spikes up
On Fri, Dec 23, 2011 at 10:13 AM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
If you want to understand the issue in detail, check out the report from
MIT this year, written by Steve Bauer and available at
http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measurem
On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy r...@maine.edu wrote:
There are a few solutions that vendors will hopefully look into. One
being to implement neighbor discovery in hardware (at which point
table exhaustion also becomes a legitimate concern, so the logic
should be such that known
Anyone using ASM (versus SSM) for IPTV? If so why?
thanks,
mike
Dear Mike;
On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com wrote:
Anyone using ASM (versus SSM) for IPTV? If so why?
From what I understand, the answer is likely to be yes and the
reason is likely to be deployed equipment only
supports IGMP v2.
Regards
Marshall
thanks,
You will always be exposed to attacks if you're connected to the Internet.
(Not really sure what you were trying to say there.)
My primary concerns are attacks originated from external networks.
Internal network attacks are a different issue altogether (similar to
ARP attacks or MAC spoofing),
Marshall,
On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks
marshall.euba...@gmail.com wrote:
Dear Mike;
On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com wrote:
Anyone using ASM (versus SSM) for IPTV? If so why?
From what I understand, the answer is likely to be yes and
On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy r...@maine.edu wrote:
The suggestion of disabling ND outright is a bit extreme. We don't
need to disable ARP outright to have functional networks with a
reasonable level of stability and security. The important thing is
I don't think it's at all
Hi All,
Just a quick question for those of you running ISPs with BGP
downstreams.
If you add or remove an upstream provider to your network, do you
provide notification to your downstream customers? Likely, it would
cause a shift in their traffic. If they are peering with multiple ISPs
As much as I argue with Owen on-list, I still enjoy reading his input.
It's a little uncalled for to be so harsh about his posts. A lot of
us are strong-willed here, and many of us read things we've posted in
the past and ask what was I thinking, that's ridiculous; and perhaps
I'm just saying
On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
However, this has two issues. First, with RAs there are no risks that
incorrect default information is propagated because the default
gateway itself broadcasts its presence.
Unless you have a malicious user on the network in which case all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/28/11 17:59, Andy Susag wrote:
If you add or remove an upstream provider to your network, do you
provide notification to your downstream customers? Likely, it would
cause a shift in their traffic. If they are peering with multiple ISPs
Mike,
To my knowledge in most today's networks even if legacy equipment don't support
IGMPv3 most likely 1st hop router does static translation and SSM upstream.
The reason not to migrate to SSM is usually - ASM is already there and works
just fine :)
Cost to support RP infrastructure is
On Wed, Dec 28, 2011 at 18:16, Doug Barton do...@dougbarton.us wrote:
On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
However, this has two issues. First, with RAs there are no risks that
incorrect default information is propagated because the default
gateway itself broadcasts its
facts deleted
Second, publishing specifications, implementing them and waiting for
users to adopt them takes a very, very long time. For DHCPv6 support,
the time from first publication (2003) until wide availability (2011)
has been 8 years. Are we ready to live in a half-baked world for
SSM is also used since we *know* the IP addresses of the content
servers that are the sources - You dont need ASM. I dont think
maintaining RP infrastructure is trivial. Who wants to deal with
register packets, etc. Small routers punt all registers to CPU and
them forward them in SW.
In fact
Isn't source discovery and efficiency a big concern for ASM? If individual
streams are tied to a specific source then it's possible to live without
some of the overhead involved in ASM. Joins go straight to the source,
traffic is disseminated via direct paths instead of being replicated by the
Ray Soucy wrote:
After reading some of your work on end-to-end multihoming, I think I
understand some of what you're trying to say. My problem is that
while you seem to have a very strong academic understanding of
networking, you seem to be ignoring operational realities in
implementation.
Hi Andy,
On Wed, 2011-12-28 at 17:59 -0500, Andy Susag wrote:
If you add or remove an upstream provider to your network, do you
provide notification to your downstream customers? Likely, it would
cause a shift in their traffic. If they are peering with multiple ISPs
themselves, they may see a
I would like to understand how you think RA is broken, and how you
think that it could be improved.
You have made some bold statements, but we lack the context to
understand their meaning.
On Wed, Dec 28, 2011 at 7:11 PM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
Ray Soucy wrote:
TJ wrote:
However, assuming you change the cells every 100m in average
and you are moving at 100km/h, you must change the cells every
3.6 seconds in average, which means you must be able to change
the cells frequently, which means each cell change take a lot
less than 3.6 seconds.
To me,
Leo Bicknell wrote:
Moble networks do not today, and should not in the future expose
those handoffs to the IP layer. Even WiFi networks are moving from
the per-cell (AP) model you describe to a controller based
infrastructure that seeks to avoid exposing L3 changes to the client.
The
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
TJ wrote:
However, assuming you change the cells every 100m in average
and you are moving at 100km/h, you must change the cells every
3.6 seconds in average, which means you must be able to change
the cells frequently, which
valdis.kletni...@vt.edu wrote:
According to the end to end argument, the only possible solution
to the problem, with no complete or correct alternatives, is to
let hosts directly participate in IGP activities.
That's only for hosts that are actively trying to communicate on more than one
Most transit networks have some sort of blanket notification that they can
send to customers. Something like between 12AM and 6AM sometime next week
you may or may not have a moderate or severe impact, but we're not going to
give you details. It also depends on the peering that is being added or
TJ wrote:
RA initiated DHCPv6 is slower than RA, of course.
I am not counting the delay caused by waiting for the RA against DHCPv6.
Do you count random delay between RA and DHCPv6 solicit?
Do you count DAD delay after DHCPv6?
Isn't the stateless operation of a router providing a prefix in
On Wed, 28 Dec 2011, Marshall Eubanks wrote:
From what I understand, the answer is likely to be yes and the
reason is likely to be deployed equipment only
supports IGMP v2.
That and numerous clients which don't know anything about SSM.
Antonio Querubin
e-mail: t...@lavanauts.org
xmpp:
On Wed, Dec 28, 2011 at 6:16 PM, Doug Barton do...@dougbarton.us wrote:
On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
Second, publishing specifications, implementing them and waiting for
users to adopt them takes a very, very long time. For DHCPv6 support,
the time from first publication
On Thu, 29 Dec 2011 11:51:00 +0900, Masataka Ohta said:
valdis.kletni...@vt.edu wrote:
Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled
by
default?
Sanity check with Windows? Are you sure?
It's a quick sanity check to this statment:
According to the end to
valdis.kletni...@vt.edu wrote:
Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled
by
default?
Sanity check with Windows? Are you sure?
It's a quick sanity check to this statment:
According to the end to end argument, the only possible solution
to the
61 matches
Mail list logo
