> Why would they do nothing? Do you mean that they just advertise /64
> on the link and tell their customers, "just use ND-proxy, we don't
> bother with prefix delegation"?
>
> The ISPs would actually do something, though: they'd provide an
> advertised /64. One could wish for PD, but if that wouldn't
> happen....
Let's take you logic and apply it to something else to show that the
logic leads to suboptimal results:
One could wish for IPv6, but if that wouldn't happen ...
Such a logic would lead to further discord which I don't think
serves the IETF or the users of the standards that the IETF produces.
The stated direction (which I think has WG rough consensus) is
to use "prefix delegation" when delegating prefixes and the
protocol for doing so that is defined is DHCPv6 prefix delegation.
So instead of grumbling how broken this is and proposing half-measures
like ND-proxy as an alternative, why can't we use the energy on making
it better; implementing DHCPv6 PD, testing it, writing informational
documents urging implementors to create admin interfaces that hides
the complexity, implementation guides, operational experience documents, etc?
> Another option that hasn't been explicitly mentioned which I just
> thought of could be reusing ND code. The ND proxy would send a NS
> message for an RFC3041 randomized address out on all its interfaces,
> and wait for a short period of time. If the same NS probe is heard
> back from any other interface, there is a reason to believe there is a
> loop somewhere. (This assumes that in this very short time frame,
> nobody else would be NS'ing specifically that address.)
Put N of those boxes in a house, connect them in a loop, and turn of the
power at the circuit breaker. When you power on they will first not forward
frames (since if they did the detection doesn't prevent the loop)
hence the loop detection will not detect the loop that is there, and then
they will all enable forwarding of frames.
I think you will step by step end up implementing something which
is close to the complexity of IEEE Spanning Tree Protocol if you want
this to be robust.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
