Erik,
FWIW it also support a single proxy having multiple downstream interfaces.
I don't know if that is an interesting case when multiple L2 technologies
are being used.
Good point. I can think of a device with more than two interfaces (for
example, GPRS, WLAN, BT, and USB).
I think people ar
Bob Hinden wrote:
Hi,
I like Erik's suggestion as a simple default mechanism to deal with the
looping case. It's not perfect, but would provide a default mechanism
that would prevent people from hurting themselves. It does support the
scenario I am interested in (/64 advertised from upstream,
Hi,
I like Erik's suggestion as a simple default mechanism to deal with the
looping case. It's not perfect, but would provide a default mechanism that
would prevent people from hurting themselves. It does support the scenario
I am interested in (/64 advertised from upstream, router/proxy, sing
Dave Thaler wrote:
Ok I understand what you mean now. Once you start trying to prevent all
the corner cases, I suspect you end up with something closer to STP, in
which case either you don't solve the corner cases and hope for the
best, or you do the safe thing which is more complex.
Not so, becau
> -Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 18, 2005 12:45 PM
> To: Dave Thaler
> Cc: Margaret Wasserman; ipv6@ietf.org
> Subject: Re: [NDProxy#16] Loop prevention, revisited
>
> Dave Thaler wrote:
>
> >
Dave Thaler wrote:
I agree this may be interesting, but it would be good to start a new
thread,
since it is for a very different scenario than a proxy, which has the
constraint that it must be completely transparent to the router.
What I sketched would be completely transparent to the router.
It is
Pekka Savola wrote:
With this, the ISP could prevent the user from running ND proxy, so
implementations will likely have a knob which would ignore this bit, but
still..
Since such an ISP would violate the "assign a /48 by default"
recommendation, it might as well go all the way and only assign a
On Fri, 18 Feb 2005, Erik Nordmark wrote:
With this, the ISP could prevent the user from running ND proxy, so
implementations will likely have a knob which would ignore this bit, but
still..
Since such an ISP would violate the "assign a /48 by default" recommendation,
it might as well go all the
On Thu, 17 Feb 2005, Dave Thaler wrote:
[Erik's proposal where ND-proxies add "P"-bit to RAs]
I agree this may be interesting, but it would be good to start a new
thread, since it is for a very different scenario than a proxy,
which has the constraint that it must be completely transparent to
th
> -Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 17, 2005 6:26 PM
> To: Margaret Wasserman
> Cc: Dave Thaler; ipv6@ietf.org
> Subject: Re: [NDProxy#16] Loop prevention, revisited
>
> Margaret Wasserman wrote:
>
Margaret Wasserman writes:
> >Point taken. How about:
> >A proxy MUST ensure that loops are prevented, either by running
> >the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all
> >proxy interfaces as described below, or by being deployable only in
> >an environment where physical loo
Margaret Wasserman wrote:
My understanding of the current ND Proxy work (and why I grudgingly
agreed to leave it on the most recent IPv6 charter despite the fact that
we had not managed to reach consensus on this proposal for several
years) was that we were planning to trim down the original ND
Hi Dave,
Point taken. How about:
A proxy MUST ensure that loops are prevented, either by running
the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all
proxy interfaces as described below, or by being deployable only in
an environment where physical loops cannot occur. For example, in
On Wed, 2005-02-16 at 14:57, Pekka Savola wrote:
> > For example, in a
> > cell phone which proxies between a PPP dialup link and a local Ethernet
> > interface, it is typically safe to assume that physical loops are not
> > possible and hence there is no need to support the Spanning Tree
> > Prot
On Wed, 16 Feb 2005, Dave Thaler wrote:
Point taken. How about:
A proxy MUST ensure that loops are prevented, either by running
the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all
proxy interfaces as described below, or by being deployable only in
an environment where physical loops
Pekka Savola writes:
> > Proposed replacement text:
> >> An implementation MUST have some means of preventing loops.
> >> Loop prevention SHOULD be done by having the proxy implement the
> >> Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all
> >> proxy interfaces, as described belo
On Tue, 15 Feb 2005, Dave Thaler wrote:
Proposed replacement text:
An implementation MUST have some means of preventing loops.
Loop prevention SHOULD be done by having the proxy implement the
Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all
proxy interfaces, as described below.
Is
Summary (from Erik Nordmark):
> I still think the document should say "MUST prevent loops;
> SHOULD run IEEE 802.1D to prevent loops" and then talk about
> cases when the protocol is not needed. The one example we have
> is the case of PPP (e.g. to a GGSN) where the probability of a
> loop would
18 matches
Mail list logo
