On Sat, 11 Sep 2010, Fred Baker wrote:
If I may make a humble request - could we get back to work, please?
Good post.
I guess I've been part of the bashing. It's a fine line between saying
that things haven't been done to solve current problems and there is a lot
of improvement to do, and g
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 Sep 11, 2010, at 2:00 PM, Randy Bush wrote:
>>> So the onus is on operators to turn their good business reasons into
>>> engineering problems, eg as a requirements RFC, that the IETF will
>>> then solve.
>
> no. it is the duty of operators to turn their business plans into
> operational prac
>> So the onus is on operators to turn their good business reasons into
>> engineering problems, eg as a requirements RFC, that the IETF will
>> then solve.
no. it is the duty of operators to turn their business plans into
operational practice, deliver packets, and charge the customers.
and it i
On Sep 11, 2010, at 1:06 AM, t.petch wrote:
> So the onus is on operators to turn their good business reasons into
> engineering problems, eg as a requirements RFC, that the IETF will then solve.
Thanks. I gather the operators have gotten a lot of bashing from IETF
participants in the past; I'm
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
Hi Doug,
Just clarifying one technical point that you raised.
On 10-09-10 03:04 PM, Doug Barton wrote:
Two responses. If we can't expect the hosts to be changed in order for
this to work, how do we expect them to send clever new RS messages even
if the draft is adopted (or perhaps I'm misun
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
Hi Suresh,
Suresh Krishnan wrote:
>
> Hi Julien,
>
> On 10-09-08 07:43 PM, Laganier, Julien wrote:
> > Thomas Narten wrote:
> >> [...]
> >>
> >> RAs/SLAAC work very well when RAs can be multicast to *all* nodes on
> >> a link, and *all* nodes receive exactly the same information about
> >> prefi
I agree that connecting non-DHCPv6 hosts directly to the proposed architecture
is problematic. It's good to ask about alternatives to solve the problem, to
understand how big the problem is and to understand whether the alternatives
are effective solutions.
I disagree that it's always better t
On 2010-09-10 20:21, Rémi Després wrote:
> Le 9 sept. 2010 à 23:51, Brian E Carpenter a écrit :
>
>> Rémi,
>>
>> This is quite similar to one possible version of
>> draft-carpenter-6man-flow-update-04 that is spinning
>> around on my hard disk. But I really want to get clarity
>> (if not rough con
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 9/10/2010 5:59 AM, Jari Arkko wrote:
Some of the discussion has gone into the history of IPv6 design, what
configuration model was intended by the original designers as the
right one, and so on. I would suggest that while that's interesting,
it may be secondary to what we are discussing here.
Hi, Rémi,
>> As for keeping track of flows, as I've just noted to Steven, this
>> is a refinement. But you could probably live assuming that all
>> flows terminate in a period equal to the duration of the flow label
>> space (i.e., when the flowlabel space wraps and you'd reuse a
>> flowlabel valu
Hi, Remi,
Thanks so much for your comments! -- Please find my responses inline
> As far as I understand, the attack in §2.1 requires that the victim processes
> an IPv4 packets whereby both source and destination are equal to a local
> assigned address. Any sane IPv4 stack will reject such
On 9/10/2010 7:13 AM, Wojciech Dec wrote:
3. Set a bar on the minimum _CPE_ requirements that will be supported by
the network (ensuring connectivity) within the given scenarios, along
with potentially having a single configuration/provisioning method? An
example of this would be requiring a rout
- Original Message -
From: "Christopher Morrow"
To: "Mikael Abrahamsson"
Cc:
Sent: Thursday, September 09, 2010 4:17 PM
>
> this is a case where 'listen to how the network is operated today,
> please.' is required I think. There are business reasons that things
> are done as they are in
Le 10 sept. 2010 à 15:18, Pascal Thubert (pthubert) a écrit :
> Hi Brian and Rémi:
>
> This set of rules recognizes that the flow label can be overridden to be used
> locally in a network according to the rules and policies that apply to this
> network. I'm all for it.
> OTOH, the proposal as
On 10 September 2010 12:52, wrote:
> >
> > > PPP is not used here. There are numerous different
> > deployment models, PPP
> > > is an expensive one that should be avoided unless there is
> > serious use for
> > > it.
> >
> > While it is true that PPP is not used here, I won't say that
> > PPP sh
On Fri, 10 Sep 2010, Jari Arkko wrote:
Host support is important because that is an area where neither the
IETF, any single vendor, or the DSL operators have any easy way to
change the situation. But it is of course by no means the only
constraint. The operators have their issues as well. Even
Hi Brian and Rémi:
This set of rules recognizes that the flow label can be overridden to be used
locally in a network according to the rules and policies that apply to this
network. I'm all for it.
OTOH, the proposal assumes that the rules in place in that network are
necessarily related to loa
Some of the discussion has gone into the history of IPv6 design, what
configuration model was intended by the original designers as the right
one, and so on. I would suggest that while that's interesting, it may be
secondary to what we are discussing here.
Suresh wants to support a particular
>
> > PPP is not used here. There are numerous different
> deployment models, PPP
> > is an expensive one that should be avoided unless there is
> serious use for
> > it.
>
> While it is true that PPP is not used here, I won't say that
> PPP should be avoided.
> PPP is a valid and widely deplo
> > PPP is not used here. There are numerous different deployment models, PPP
> > is an expensive one that should be avoided unless there is serious use for
> > it.
>
> While it is true that PPP is not used here, I won't say that PPP should be
> avoided.
> PPP is a valid and widely deployed model
-Original Message-
From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
Sent: venerdì 10 settembre 2010 12.10
To: Maglione Roberta
Cc: Mark Smith; ipv6@ietf.org; Fred Baker
Subject: RE: New version available
On Fri, 10 Sep 2010, Maglione Roberta wrote:
>> PPP is not used here. There are n
On Fri, 10 Sep 2010, Tina TSOU wrote:
Some operators have serious use for PPPoE in large scale. It is a tradeoff
for them to decide whether it is expensive or not from the whole picture
point of view.
Yes. I don't see where I said they shouldn't. I said it was expensive, I
didn't deny there
On Fri, 10 Sep 2010, Maglione Roberta wrote:
PPP is not used here. There are numerous different deployment models, PPP
is an expensive one that should be avoided unless there is serious use for
it.
While it is true that PPP is not used here, I won't say that PPP should
be avoided. PPP is a va
B. R.
Tina
http://tinatsou.weebly.com
On Sep 10, 2010, at 11:52 AM, Maglione Roberta wrote:
PPP is not used here. There are numerous different deployment
models, PPP
is an expensive one that should be avoided unless there is serious
use for
it.
While it is true that PPP is not used he
> PPP is not used here. There are numerous different deployment models, PPP
> is an expensive one that should be avoided unless there is serious use for
> it.
While it is true that PPP is not used here, I won't say that PPP should be
avoided.
PPP is a valid and widely deployed model in DSL Broadb
Le 9 sept. 2010 à 23:51, Brian E Carpenter a écrit :
> Rémi,
>
> This is quite similar to one possible version of
> draft-carpenter-6man-flow-update-04 that is spinning
> around on my hard disk. But I really want to get clarity
> (if not rough consensus) on the immutability thread before
> being
Hi Fernando,
Thanks for the fast reaction.
More below.
Le 9 sept. 2010 à 20:31, Fernando Gont a écrit :
> Hi, Remi,
>
>> Draft-gont-6man-flowlabel-security is based on the assumption that FL
>> values are set as currently specified in RFC 3697, i.e. with a
>> *stateful* algorithm that needs to
32 matches
Mail list logo
