Subject: Re: ND-proxy applicability and loop-prevention

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Apr 2004 22:24:45 +0300 (EEST)

Replying to an old message..

On Mon, 29 Mar 2004, Erik Nordmark wrote:
> > The problem is that with the same trouble it takes to fully delegate a
> > /64, the ISP could do a /48 as well.  That is a good thing also, of
> > course.  My worry is that the ISPs end up doing nothing unless they
> > have simple enough means available.
> 
> My worry is that ISPs would end up doing nothing because of the existance
> of nd proxy.

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....

Or did you mean that the ISPs would do nothing because they could no 
longer trust (to an extent) that the /64 they'd advertise on the P-t-P 
link would be used by one node only, and then would not offer any IPv6 
service at all?

> > I mean, the message could also be "just give every customer a
> > delegated /48.  If that is not possible, advertising a /64 on the link
> > is better than nothing."
> 
> Yes, but that requires a non-robust against loops nd-proxy complexity
> to be added to the architecture.
> In the big picture this is a distraction and not a help.

As said, I don't think we absolutely need loop-free properties.  We 
disagree on the deployment scenarios, I think.  

But as discussed, rather light-weight loop detection mechanism could
be added with relative ease: e.g., an ND option that would be added to
identify the proxy (would increase the ND message size though == bad).

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.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 8 Apr 2004 18:36:52 -0700 (PDT)

> advertised /64.  One could wish for PD, but if that wouldn't 

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?

> 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