On 5/7/12, William Herrin wrote:
> On 5/6/12, Matthew Petach wrote:
>> Which way do *you* vote?
> Hi Matthew,
> Cisco routers forward packets for 127.0.0.0/8 unless explicitly
> configured not to, treating it like any other unicast address.
The difference with IPv4, is the RFC1122 requirement i
On 7. May 2012, at 12:56 , William Herrin wrote:
> I vote for the Cisco approach. It has occasionally quirky results but
> it's also flexible enough to handle situations the protocol designers
> didn't conceive of.
Isn't it a simple scope violation in IPv6 and thus a bug and with that end of
sto
On 5/6/12, Matthew Petach wrote:
> Which way do *you* vote?
Hi Matthew,
Cisco routers forward packets for 127.0.0.0/8 unless explicitly
configured not to, treating it like any other unicast address.
Linux load balancers require a special kernel patch to also use them
as routers because the kern
On 5/6/12, Matthew Petach wrote:
> I'm curious about what people's perception of valid link-local
> addresses is; that is, what specifically makes a valid link-local
> address?
> The top portion of RFC 4291 lists the link-local prefix as:
[snip]
> Link-Local unicast 111010 F
Once upon a time, Randy Bush said:
> > Any address withing FE80::/10 is a link local address
>
> said with great authority. shame the rfc does not do the same. matt
> points out a spec and implementation problem.
Well, the prefix length of 10 vs. 64 is hardly relevant when major
routers ignore
In message , Randy Bush writes:
> > Any address withing FE80::/10 is a link local address
>
> said with great authority. shame the rfc does not do the same. matt
> points out a spec and implementation problem.
>
> randy
Zero is there to remove the "what do I set these bits to" problem
for aut
> Any address withing FE80::/10 is a link local address
said with great authority. shame the rfc does not do the same. matt
points out a spec and implementation problem.
randy
Any address withing FE80::/10 is a link local address, however when
you are constructing a link local address you sent bits [11..64]
to zero. It's quite common for a specification to only use a subset
of the reserved space which is what happens here.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dun
On Sun, May 06, 2012 at 08:25:06AM -0700, Matthew Petach wrote:
> So...operators...what do *you* think the correct
> definition is? And which way would you prefer
> your router vendors to read RFC4291?
I would expect them to follow 2.4, even if the current spec says that
the 54 bits between /10 a
(tl;dr -- IPv6 link-local definition is ambiguous and inconsistent
across vendors)
I'm curious about what people's perception of valid link-local
addresses is; that is, what specifically makes a valid link-local
address?
The top portion of RFC 4291 lists the link-local prefix as:
2.4. Address T
On 4/30/12 2:36 PM, "Justin M. Streiner" wrote:
>On Fri, 27 Apr 2012, Chris Adams wrote:
>
>> I don't think that will work, because there's an automatic direct route
>> for fe80::/64 to all interfaces with family inet6 configured. The only
>> way I see around it is to apply a firewall filter to
On Fri, 27 Apr 2012, Chris Adams wrote:
I don't think that will work, because there's an automatic direct route
for fe80::/64 to all interfaces with family inet6 configured. The only
way I see around it is to apply a firewall filter to all IPv6 interfaces
that blocks anything with a source in f
We kind of needed them in IPv4, though not universally.
At least in IPv6, we have them.
Owen
On Apr 27, 2012, at 12:16 PM, Christopher Morrow wrote:
> you know what I love? address selection rules, or rather the fact that
> we have to have them in this new ip protocol :(
>
> bugs and code prob
you know what I love? address selection rules, or rather the fact that
we have to have them in this new ip protocol :(
bugs and code problems and operational headaches and filters and ... :(
On Fri, Apr 27, 2012 at 12:31 PM, Jack Bates wrote:
> On 4/27/2012 11:20 AM, Chris Adams wrote:
>>
>> Onc
On 4/27/2012 11:20 AM, Chris Adams wrote:
Once upon a time, Jack Bates said:
fe80::/65 discard
fe80:0:0:0:8000::/65 discard
More specifics rule out over connected any day.
That would also kill any legitimate link-local traffic though.
Perhaps. I'm actually curious on that, as the rules for
Once upon a time, Jack Bates said:
> fe80::/65 discard
> fe80:0:0:0:8000::/65 discard
>
> More specifics rule out over connected any day.
That would also kill any legitimate link-local traffic though.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for
Just since I had everything hooked up I did a quick test on IOS-XR 4.2.0
on an ASR9000 and found it also forwards v6 traffic with a link-local
source address and a global destination address. The destination was a
Juniper box which I tried to DoS using ICMPv6 echo requests. The
200:11ff:fe00:0 is
On 4/27/2012 9:26 AM, Chris Adams wrote:
I don't think that will work, because there's an automatic direct
route for fe80::/64 to all interfaces with family inet6 configured.
The only way I see around it is to apply a firewall filter to all IPv6
interfaces that blocks anything with a source in
Once upon a time, Jack Bates said:
> On 4/27/2012 8:56 AM, Chris Adams wrote:
> >I found out by accident yesterday that JUNOS routers will forward IPv6
> >packets with a link-local source address, in direct opposition of RFC
> >4291. To me, this seems to be a security hole that would be useful fo
On 4/27/2012 8:56 AM, Chris Adams wrote:
I found out by accident yesterday that JUNOS routers will forward IPv6
packets with a link-local source address, in direct opposition of RFC
4291. To me, this seems to be a security hole that would be useful for
DDoS attackers, giving them a way to send t
I found out by accident yesterday that JUNOS routers will forward IPv6
packets with a link-local source address, in direct opposition of RFC
4291. To me, this seems to be a security hole that would be useful for
DDoS attackers, giving them a way to send traffic that is difficult to
trace back to t
21 matches
Mail list logo
