Hi Ralph,
Ralph Droms wrote:
I reread draft-thaler-ipv6-ndproxy-02.txt, and wonder if it might be
time to
revisit the need for ND proxies.
Yes, I have been wondering the same thing - perhaps not for exactly
the same reasons.
It seems the primary motivation for ND proxies is to avoid the need
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : Optimistic Duplicate Address Detection
Author(s) : N. Moore
Filename: draft
I reread draft-thaler-ipv6-ndproxy-02.txt, and wonder if it might be time to
revisit the need for ND proxies.
It seems the primary motivation for ND proxies is to avoid the need for L3
devices that require configuration, prefix assignment and configuration. I
read the two scenarios in section 1, a
Jari Arkko wrote:
Christian Huitema wrote:
The routing or spanning tree solution is the most transparent to the
hosts, since it does not change any byte in the ND packets. However,
transparency may not be entirely desired, since SEND requires being
fairly explicit about relays.
Yes. In fact,
Christian Huitema wrote:
The routing or spanning tree solution is the most transparent to the
hosts, since it does not change any byte in the ND packets. However,
transparency may not be entirely desired, since SEND requires being
fairly explicit about relays.
Yes. In fact, an explicit marker tel
On Tue, 23 Mar 2004, Soliman Hesham wrote:
> > The user knows that all of his communication attempts fail.
> > That's a
> > good signal that there's something wrong. If the user knows nothing
> > more of this, he calls helpdesk or some support, which may
> > be able to
> > identify the pr
On Tue, 23 Mar 2004, Ole Troan wrote:
> I see two alternatives:
>
> 1. ND proxy. Limited to single router, proxy from uplink to
> downlink. No need for loop detection.
>
> 2. Multilink subnet routing. Handles arbitrary topologies. Must
> handle loops.
You cannot restrict (in protocol)
Ole Troan wrote:
I'd sure be interested in hearing what others in the WG think
on this issue.
I agree with Erik.
I see two alternatives:
1. ND proxy. Limited to single router, proxy from uplink to
downlink. No need for loop detection.
2. Multilink subnet routing. Handles arbitrary topolo
> One easy way to do this would be define a special multicast group,
> to which all routers will listen, thus parse and forward these
> packets to their uplinks. The packet would contain the primary
> identification of that host and the uplink over which the packet
> gets sent, one could include a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ole Troan wrote:
> > I'd sure be interested in hearing what others in the WG think
> > on this issue.
>
> I agree with Erik.
>
> I see two alternatives:
>
> 1. ND proxy. Limited to single router, proxy from uplink to
> downlink. No need for lo
[snipped other parts as I trivially agree with them]
On Tue, 23 Mar 2004 [EMAIL PROTECTED] wrote:
> > OK -- I'm fine with putting it in as MAY, with some
> > additional text to describe its inherent problems,
> > e.g. like:
> >
> > Note that setting up Security Associations to deal with all t
> I'd sure be interested in hearing what others in the WG think
> on this issue.
I agree with Erik.
I see two alternatives:
1. ND proxy. Limited to single router, proxy from uplink to
downlink. No need for loop detection.
2. Multilink subnet routing. Handles arbitrary topologies. Must
Pekka,
comments inline..
> Well, if we conclude that those are required, maybe we have to use
> draft-ietf-ipsec-rfc2402bis instead -- that's already been at IESG
> evaluation so might not end up blocking the document.
I think, we should use the latest drafts instead of the old RFCs.
I will u
> > => I think it's a bad signal, _if_ detected. I.e. An average
> > user is not even going to know that they have 100% link
> > utilisation. And _if_ they do, I actually think that neither
> > the user, nor the help desk first line of support will
> > have the faintest idea (having been a r
On Tue, 23 Mar 2004, Soliman Hesham wrote:
> > I don't personally think 100% link utilization is that bad a
> > signal.
>
> => I think it's a bad signal, _if_ detected. I.e. An average
> user is not even going to know that they have 100% link
> utilisation. And _if_ they do, I actually think
I agree with Erik and Hesham that loop preventation
is something that we may wish to have. A couple of
comments on what Pekka wrote about detection:
I think it would be possible to detect loops if we wanted really hard
to do that. That might just lead to reinvention of the spanning tree
protocol
16 matches
Mail list logo
