Subject: RE: [NDProxy#16] Loop prevention, revisited

From: "Dave Thaler" <[email-masked]>
Date: Thu, 17 Feb 2005 18:30:42 -0800

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Thursday, February 17, 2005 6:26 PM
> To: Margaret Wasserman
> Cc: Dave Thaler; [email-masked]
> Subject: Re: [NDProxy#16] Loop prevention, revisited
> 
> 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 Proxy
> > proposal to a one-hop prefix delegation mechanism (perhaps with a
flag
> > to indicate whether the prefix has already been delegated, in which
case
> > it mustn't be delegated again) to provide a non-DHCP alternative for
> > one-hop prefix delegation.  I've never been quite sure why a
non-DHCP
> > mechanism is needed, but I'm also not religiously against the idea
of
> > standardizing an alternative.
> 
> I think this should be explored further.
> 
> It might not be that hard to come up with something which is is
limited
> to a single hop.
> Here is a straw-man:
>   - add something to the RA which indicates that the sender is a
proxy.
> Could be just a single 'P' bit I think.
>   - a proxy can take an RA which arrives without the P bit, and send
it
> out as a RA with the P-bit.
>   - a proxy must not redistribute an RA with the P-bit set; if it
> receives any (or only?) RAs with the P-bit set, that interface can not
> be an upstream interface from a proxy perspective.
> 
> I haven't worked through the cases to see if this will avoid all
loops;
> perhaps there can be (at least multicast) packet duplication if two
such
> proxies are connected in parallel.
> 
>    Erik

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.

Hence, this is not in any way competing with the ND Proxy draft,
but it is a competitor to Prefix Delegation.

-Dave

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Feb 2005 08:38:59 +0200 (EET)

On Thu, 17 Feb 2005, Dave Thaler wrote:
[Erik's proposal where ND-proxies add "P"-bit to RAs]
> 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.

I don't understand.  ND-proxies adding and checking for "P-bit" in RAs 
does not require changes to the router because routers send the RAs 
without P-bit?  It only requires modifications in ND-proxies but 
that's OK.

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 Feb 2005 12:45:18 -0800

> constraint that it must be completely transparent to the router.

What I sketched would be completely transparent to the router.

It is merely a mechanism to prevent a large class of loops by ensuring 
that a proxy can not be a child of another proxy.

Thus this can NOT happen:

	Router
	   |
	------------------------
	   |                 |
	Proxy1             Proxy2
	   |                 |
	   ---- Proxy3 --------

Proxy3 will not enable its proxy capability because it receives RAs with 
the P bit set.

While this CAN happen:

	Router
	   |
	------------------------
	   |                 |
	Proxy1             Proxy2
	   |                 |
	   -------------------
            |
	  Host

But perhaps this can be prevented as well, by having the proxy disable 
itself it it receives a RA (P bit or not?) on its downstream interface 
(Could still have a temporary loop, unless we require that the proxy 
send its P-bit RA on the downstream interface for a while before 
enabling the proxying/flooding.

    Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Feb 2005 22:55:25 +0200 (EET)

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 way and only assign a /128 to the subscriber.
> So why would the ISP use the more cumbersome approach of 1) assiging a /64, 
> and 2) lying by setting the P-bit in its RA?

Because if such an ISP used RAs for address assignment, it couldn't 
restrict to /128.  (Well, maybe such ISP's would require stateful 
DHCPv6 assignment..)

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 Feb 2005 12:50:47 -0800

> implementations will likely have a knob which would ignore this bit, but 

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 /128 
to the subscriber.
So why would the ISP use the more cumbersome approach of 1) assiging a 
/64, and 2) lying by setting the P-bit in its RA?

We can't solve the tussle that some ISPs might want to charge per host, 
while users might want to pay per "wire" and have lots of hosts. Given 
that the /128 is an option for the ISP, we can avoid entangling the 
protocol standards with this tussle, which is the best we can do IMHO.

    Erik