On Sep 12, 2010, at 4:01 AM, Mark Smith wrote:
> What I said was, and I'll highlight the key word,
>
> "Layer 2 devices inspecting traffic isn't *architecturally* acceptable
> because it's a layer violation"
>
> The best place to fix IPv6 issues in in IPv6.
well, yes, but...
let me give you
On Sun, 12 Sep 2010, Mark Smith wrote:
So I accept layer violations to perform some of these functions, but I
think it'd be preferable if they could be avoided.
Of course it is preferrable if they can be avoided.
Problem is that the method you're suggesting to solve this with, is not
economi
On Sun, 12 Sep 2010 12:57:48 +0200 (CEST)
sth...@nethelp.no wrote:
> > >> Serious disconnect between map and reality here, Mark.
> > >
> > > If you think that, then I don't think you've read my emails
> > > properly.
> >
> > ... or there is a serious disconnect between your reality and my reality
On Sun, 12 Sep 2010 11:58:45 +0200 (CEST)
Mikael Abrahamsson wrote:
> On Sun, 12 Sep 2010, Mark Smith wrote:
>
> > On Sun, 12 Sep 2010 07:29:10 +0200 (CEST)
> > Mikael Abrahamsson wrote:
> >
> >> On Sun, 12 Sep 2010, Mark Smith wrote:
> >>
> >>> So my question was how would you solve it (archit
> >> Serious disconnect between map and reality here, Mark.
> >
> > If you think that, then I don't think you've read my emails
> > properly.
>
> ... or there is a serious disconnect between your reality and my reality.
>
> By saying that L2 devices doing L3 inspection is a layer violation and
>
On Sun, 12 Sep 2010, Mark Smith wrote:
On Sun, 12 Sep 2010 07:29:10 +0200 (CEST)
Mikael Abrahamsson wrote:
On Sun, 12 Sep 2010, Mark Smith wrote:
So my question was how would you solve it (architecturally)?
Layer 2 devices inspecting traffic isn't architecturally acceptable
because it's a
On Sun, 12 Sep 2010 07:29:10 +0200 (CEST)
Mikael Abrahamsson wrote:
> On Sun, 12 Sep 2010, Mark Smith wrote:
>
> > So my question was how would you solve it (architecturally)?
> >
> > Layer 2 devices inspecting traffic isn't architecturally acceptable
> > because it's a layer violation,
>
> +1
On Sun, 12 Sep 2010, Brian E Carpenter wrote:
So, indeed, those who market layer 2 solutions relying on layer
violation will have to update their products when a new layer 3 arrives.
That is perfectly understandable and that's not something anyone is
opposing as far as I can see.
--
Mikael
On Sun, 12 Sep 2010, Mark Smith wrote:
So my question was how would you solve it (architecturally)?
Layer 2 devices inspecting traffic isn't architecturally acceptable
because it's a layer violation,
+1 on what Steinar Haug wrote.
Serious disconnect between map and reality here, Mark.
--
Mi
On 2010-09-12 15:22, sth...@nethelp.no wrote:
How would you solve the problem? If you give end-nodes the ability to
>>> Exactly the way it has been done for IPv4 with the mechanisms I've given
>>> examples of before.
>> Your criticisms seemed to be architectural ones - that the IETF hadn't
>>
> > > How would you solve the problem? If you give end-nodes the ability to
> >
> > Exactly the way it has been done for IPv4 with the mechanisms I've given
> > examples of before.
>
> Your criticisms seemed to be architectural ones - that the IETF hadn't
> designed a protocol that addressed the
On Sat, 11 Sep 2010 08:06:39 +0200 (CEST)
Mikael Abrahamsson wrote:
> On Sat, 11 Sep 2010, Mark Smith wrote:
>
> > How would you solve the problem? If you give end-nodes the ability to
>
> Exactly the way it has been done for IPv4 with the mechanisms I've given
> examples of before.
Your crit
On Sep 11, 2010, at 3:06 PM, Mikael Abrahamsson wrote:
> On Sat, 11 Sep 2010, Mark Smith wrote:
>
>> How would you solve the problem? If you give end-nodes the ability to
>
> Exactly the way it has been done for IPv4 with the mechanisms I've given
> examples of before. L2 devices look at DHCPv
On Sat, 11 Sep 2010, Mark Smith wrote:
How would you solve the problem? If you give end-nodes the ability to
Exactly the way it has been done for IPv4 with the mechanisms I've given
examples of before. L2 devices look at DHCPv6 etc and then enforce policy
accordingly. The thing here is that
On 2010-09-11 12:24, Mark Smith wrote:
> On Fri, 10 Sep 2010 07:34:42 +0200 (CEST)
> Mikael Abrahamsson wrote:
>
>> On Fri, 10 Sep 2010, Brian E Carpenter wrote:
>>
I'm sure there are a lot in the IETF that agrees with you that they
don't understand why it's a problem, because the IETF
On Fri, 10 Sep 2010 07:34:42 +0200 (CEST)
Mikael Abrahamsson wrote:
> On Fri, 10 Sep 2010, Brian E Carpenter wrote:
>
> >> I'm sure there are a lot in the IETF that agrees with you that they
> >> don't understand why it's a problem, because the IETF has historically
> >> been totally unintereste
On 2010-09-10 17:13, Fred Baker wrote:
> On Sep 10, 2010, at 6:44 AM, Brian E Carpenter wrote:
>
>>> SLAAC is fine for home networks (and some enterprise networks).
>> That's exactly what (IMHO) we need to preserve, which has the side effect
>> that it's going to be the default mechanism for IPv
On Fri, 10 Sep 2010, Brian E Carpenter wrote:
I'm sure there are a lot in the IETF that agrees with you that they
don't understand why it's a problem, because the IETF has historically
been totally uninterested in security in development.
That really hasn't been true for many years now. But as
On Sep 10, 2010, at 6:44 AM, Brian E Carpenter wrote:
>> SLAAC is fine for home networks (and some enterprise networks).
>
> That's exactly what (IMHO) we need to preserve, which has the side effect
> that it's going to be the default mechanism for IPv6 nodes shipped out into
> the SOHO marke
On 2010-09-09 17:43, Mikael Abrahamsson wrote:
> On Thu, 9 Sep 2010, Brian E Carpenter wrote:
>
>> I can't see why that would be a problem for an operator who uses
>> DHCPv6 as their supported mechanism.
>
> I'm sure there are a lot in the IETF that agrees with you that they
> don't understand wh
20 matches
Mail list logo
