Hi,
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]
Or "A number of other features currently in development, o
> I am not sure if this is the reason as this only applies to the link
> local IP address. One could still assign a global IPv6 address. So,
> why does basic IPv6 (ND process, etc) break if i use a netmask of say
> /120?
As long as you assign addresses statically, IPv6 works just fine with a
netma
Ok. So does SLAAC break with masks > 64?
Glen
On Sat, Dec 24, 2011 at 12:38 PM, wrote:
>> I am not sure if this is the reason as this only applies to the link
>> local IP address. One could still assign a global IPv6 address. So,
>> why does basic IPv6 (ND process, etc) break if i use a netmask
On Sat, 2011-12-24 at 15:37 +0530, Glen Kent wrote:
> Ok. So does SLAAC break with masks > 64?
"Break" is not the right word. SLAAC only works with /64, But that is by
design.
Regards, K.
--
~~~
Karl Auer (ka...@biplane.com.au)
Le 24/12/2011 11:58, Karl Auer a écrit :
On Sat, 2011-12-24 at 15:37 +0530, Glen Kent wrote:
Ok. So does SLAAC break with masks> 64?
"Break" is not the right word. SLAAC only works with /64, But that is
by design.
SLAAC only works with /64 - yes - but only if it runs on Ethernet-like
Interf
>
> SLAAC only works with /64 - yes - but only if it runs on Ethernet-like
> Interface ID's of 64bit length (RFC2464).
Ok, the last 64 bits of the 128 bit address identifies an Interface ID
which is uniquely derived from the 48bit MAC address (which exists
only in ethernet).
> SLAAC could work ok
it only breaks the auto configure crap which you don't want to use anyway.
(unless you want to have any computer on your network be able to tell any
other computer "oh hai i'm a router, please route all your packets through
me so i can intercept them" and/or flood its route table ;)
we use al
On Sat, Dec 24, 2011 at 6:48 AM, Glen Kent wrote:
> >
> > SLAAC only works with /64 - yes - but only if it runs on Ethernet-like
> > Interface ID's of 64bit length (RFC2464).
>
> Ok, the last 64 bits of the 128 bit address identifies an Interface ID
> which is uniquely derived from the 48bit MAC
things that -do- break on ipv6 a lot (not nessesarily related to the /64
thing) are premature protocols like ospf6 and ripng that for some magic
reason refuse to work on point-to-point (as opposed to putting the
interface in broadcast mode, like ethernet) interfaces without
(additional) link-lo
Your understanding of IPv6 is poor if you think by not using a 64-bit
prefix you will be protected against rogue RA.
The prefix length you define on your router will have no impact on a
rogue RA sent out. IPv6 hosts can have addresses from multiple
prefixes on the same link. Choosing to make use
Hi Ray,
> prefixes on the same link. Choosing to make use of a 120-bit prefix
> (for example) will do nothing to protect against a rogue RA announcing
> its own 64-bit prefix with the A flag set.
>
I could not find any "A flag" in the RA. Am i missing something?
>From http://www.iana.org/assign
> > prefixes on the same link. Choosing to make use of a 120-bit prefix
> > (for example) will do nothing to protect against a rogue RA announcing
> > its own 64-bit prefix with the A flag set.
> >
>
> I could not find any "A flag" in the RA. Am i missing something?
It's part of the Prefix Infor
Sven,
> also various bgp implementations will send the autoconfigure crap ip as the
> next-hop instead of the session ip, resulting in all kinds of crap in your
> route table (if not fixed with nasty hacks on your end ;) which doesn't
> exactly make it easy to figure out which one belongs to which
It seems ISIS and OSPFv3 use the link local next-hop in their route
advertisements.
We discussed that SLAAC doesnt work with prefixes > 64 on the ethernet
medium (which i believe is quite, if not most, prevalent). If thats
the case then how are operators who assign netmasks > 64 use ISIS and
OSPF,
On Wed, 28 Dec 2011 04:58:19 +0530, Glen Kent said:
> I had assumed that nodes derive their link local address from the
> Route Advertisements. They derive their least significant 64 bytes
> from their MACs and the most significant 64 from the prefix announced
> in the RAs.
No, on Ethernet-ish ne
On Dec 27, 2011, at 4:28 PM, Glen Kent wrote:
> I had assumed that nodes derive their link local address from the
> Route Advertisements. They derive their least significant 64 bytes
> from their MACs and the most significant 64 from the prefix announced
> in the RAs.
No, link local addresses ar
On Wed, Dec 28, 2011 at 04:58:19AM +0530, Glen Kent wrote:
> It seems ISIS and OSPFv3 use the link local next-hop in their route
> advertisements.
>
> We discussed that SLAAC doesnt work with prefixes > 64 on the ethernet
> medium (which i believe is quite, if not most, prevalent). If thats
> the
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 statele
On Wed, Dec 28, 2011 at 6:23 AM, Iljitsch van Beijnum
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 that IPv6 is cla
> 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 t
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
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 n
> 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 ex
> > 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 "m
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 implemen
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 b
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 ne
> 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 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
On Dec 28, 9:44 am, Ray Soucy 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 of prefixes
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 Inp
> 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 sp
On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy 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 associations
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), whi
On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy 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 extreme. If yo
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 t
On Thursday, December 29, 2011 03:46:48 AM sth...@nethelp.no
wrote:
> And there are other platforms, e.g. Juniper M/MX/T, where
> there is no concept of "punt a packet to software to
> perform a forwarding decision". The packet is either
> forwarded in hardware, or dropped. IPv6 prefixes > 64
> b
On (2011-12-29 16:56 +0800), Mark Tinka wrote:
> On Thursday, December 29, 2011 03:46:48 AM sth...@nethelp.no
> wrote:
>
> > And there are other platforms, e.g. Juniper M/MX/T, where
> > there is no concept of "punt a packet to software to
> > forwarded in hardware, or dropped. IPv6 prefixes > 6
Iljitsch van Beijnum wrote:
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
Le 28/12/2011 16:45, sth...@nethelp.no a écrit :
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",
:-) yes agree, except that it's not
On Thursday, December 29, 2011 05:10:15 PM Saku Ytti wrote:
> Of course this isn't strictly true,...
Of course, not "strictly".
What I meant was the CRS and ASR9000 don't operate like the
6500/7600 and other Cisco switches that punted packets to
CPU if, for one reason or another, a bug or mis
Le 28/12/2011 13:13, Ray Soucy a écrit :
On Wed, Dec 28, 2011 at 6:23 AM, Iljitsch van Beijnum
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 th
On Thu, Dec 29, 2011 at 2:03 PM, Kevin Loch wrote:
> The 64 bit "mattress tag"
This phrase made my year.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
On Dec 24, 2011, at 6:48 AM, Glen Kent wrote:
>>
>> SLAAC only works with /64 - yes - but only if it runs on Ethernet-like
>> Interface ID's of 64bit length (RFC2464).
>
> Ok, the last 64 bits of the 128 bit address identifies an Interface ID
> which is uniquely derived from the 48bit MAC addre
On Dec 27, 2011, at 3:28 PM, Glen Kent wrote:
> It seems ISIS and OSPFv3 use the link local next-hop in their route
> advertisements.
>
> We discussed that SLAAC doesnt work with prefixes > 64 on the ethernet
> medium (which i believe is quite, if not most, prevalent). If thats
> the case then h
On Tue, 2012-01-03 at 15:45 -0800, Owen DeLong wrote:
> Technically, link local is fe80::/10, though many implementations erroneously
> treat it as fe80::/64. In most cases, since the 54 bits between fe80 and the
> IID are almost always 0, this error has no impact.
Yes, well, I'm a bit confused ab
On 12/28/11 07:30 , Ryan Malayter wrote:
> Except nowhere in there is the prefix length for the test indicated,
> and the exact halving of forwarding rate for IPv6 leads one to believe
> that there are two TCAM lookups for IPv6 (hence 64-bit prefix lookups)
> versus one for IPv4.
A cam (assuming
Le 03/01/2012 23:36, Owen DeLong a écrit :
On Dec 24, 2011, at 6:48 AM, Glen Kent wrote:
SLAAC only works with /64 - yes - but only if it runs on
Ethernet-like Interface ID's of 64bit length (RFC2464).
Ok, the last 64 bits of the 128 bit address identifies an Interface
ID which is uniquely
sth...@nethelp.no writes:
> And yes, we know equipment that cannot *filter* on full IPv6 + port
> number headers exists (e.g. Cisco 6500/7600 with 144 bit TCAMs) - my
> original point was that I still haven't seen equipment with forwarding
> problems for prefixes > 64 bits.
Depends on what you c
> "Note: An IPv4 route requires only one TCAM entry. Because of the
> hardware compression scheme used for IPv6, an IPv6 route can take
> more than one TCAM entry, reducing the number of entries forwarded
> in hardware. For example, for IPv6 directly connected IP addresses,
> the d
51 matches
Mail list logo
