Subject: ND-proxy applicability and loop-prevention

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 13:54:49 +0200 (EET)

Hi,

We've discussed ND-proxy applicability in home networks for "informal 
prefix sharing" (see draft-ietf-v6ops-unmaneval-01.txt).  I thought it 
might be good idea to try to move some of the discussion on IPv6 WG 
list where ND-proxy is being specified.

Below...

On Tue, 16 Mar 2004, Erik Nordmark wrote:
[Erik quoting me:]
> > Another angle here is how are you going to deal with the case where 
> > you have to have stacked gateways.  E.g., the home gateway is doing 
> > prefix delegation, and advertising /64's on its links.  One of the 
> > nodes at home is also a router, and behind it is a host.  How do you 
> > get v6 to that host behind the node?  That's a very common scenario 
> > today.  I think it in most cases you could probably move that node to 
> > the same link, but in some cases (e.g., mismatching media) it might 
> > not be possible.
>
[...] 
> The solution you want in this space is something which allows plug&play of
> the devices that glue together the stacking. And since you don't know how
> the customer will plug things together, I think you must deal with loops.

I have a fundamental disagreement with this.  Any scenario where you 
would plug these in any other mode than in series should be strictly 
out of scope.  IMHO, we don't want to deal with that.

If the user plugs three ND-proxies in a triangle or two (or 
more) ND-proxies in a loop, the everything breaks -- and the customer 
fixes the set-up or calls someone to fix it.  Immediate failure, 
immediate fix.  I see no problem with this.  As it is, ND-proxy should 
never be enabled by default in any case.

> It is true that ndproxy as written can handle this, but it handles
> it by running IEEE 802.1D spanning tree protocol over all media - including
> non-IEEE 802 media - without specifying the details of how to carry IEEE 802 
> bridge PDUs over Avian Carriers, bluetooth, etc.
> That doesn't seem like the best approach.
> An approach like draft-perlman-zerouter-rbridge-00.txt, which builds
> a (very thin) overlay above the link layer between the rbridges look
> a lot more interesting to me; no need to carry bridge PDUs around etc.

No comment about this because I strongly believe we should get rid of 
the whole IEEE 802.1D spanning tree protocol hack from the protocol in 
the first place.

-- 
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: Mon, 22 Mar 2004 21:13:57 -0800 (PST)

I'd sure be interested in hearing what others in the WG think
on this issue.

> never be enabled by default in any case.

Pekka,

elsewhere (in a mail on v6ops) you stated the concern that IPv6 might end
up with consumer-class "routers" (devices that sit between different types of
L2) that do v6-to-v6 NAT because that would be more plug and play 
than the alternatives hence we need an alternative like ndproxy
(at least I think you made that argument).

Saying that ndproxy needs to be manually enabled and can't be enabled
by default doesn't match this concern.

I also don't see how one can prevent consumers from connecting such
devices in ways that form loops.
It *might* be sufficient if the solution could detect loops and sound the alarm
(and stop forwarding frames), but ndproxy can't even detect loops and shut
itself off. Thus when loops are formed the result is that the consumer will
see their network die (100% link utilization due to frames looping around
forever; ndproxy doesn't decrement the hop count).

This doesn't satisfy what I think you say you want to solution to do.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Mar 2004 08:50:21 +0200 (EET)

> (at least I think you made that argument).

Right.

> by default doesn't match this concern.

Oh, sorry -- I meant that ND-proxying would not be manually enabled on
*hosts* (naturally not) -- and if a router has some routing
information, ND proxy could be disabled in any case.  As a matter of
fact, as push-button on the side of the box, "proxy/router", might be
doable.
 
> devices in ways that form loops.

They cannot be prevented, yes.  (And I don't think this is a serious
problem, but more of a kind of support FAQ to show to the users.)

> forever; ndproxy doesn't decrement the hop count).

I don't personally think 100% link utilization is that bad a signal.  
It rather simply conveys that "oops-- I've done something wrong when I
added the box there." and after it's removed all starts to work again
-- intuitive.  What would be worse is that some packets would work but
some others not.  Total connectivity loss is a good indicator of a
problem :).

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

For example, the ND proxy could send in ND solicitation for its own IP
address.  If it hears back that solicitation on some other interface,
it can conclude that someone is looping those packets and it should
e.g. shut down completely.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Mar 2004 12:56:50 +0200

I agree with Erik and Hesham that loop preventation
is something that we may wish to have. A couple of

> to do that.  That might just lead to reinvention of the spanning tree 

This is a danger, yes.

> e.g. shut down completely.

Right. Or add an ND option to a proxied query, and detect when you
receive an option which you inserted by yourself.

--Jari

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Mar 2004 15:52:45 +0000

> I'd sure be interested in hearing what others in the WG think

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

publishing a specification for ND proxy with support for a restricted
topology (multiple routers) without handling loops is just
irresponsible.

/ot

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 23 Mar 2004 18:43:08 +0100

> topology (multiple routers) without handling loops is just

The same applies to the current MLD proxy document (MAGMA WG).

I heared a report of some person who setup ecmh on 4 different
routers which then collapsed as it didn't prevent a routing loop.

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 'trace' of where the packet passed
to aid in further diagnosis. When a router gets a packet containing
it's own ID it can use the link field contained in the packet to
see where it sent the packet too and then simply disable that link
from being used for forwarding packets too, notifying the admin
in some way or another. This at least prevents the loop from
happening for too long and thus minimizes damage.

This could then also be used in traceroute scenarios later on.
Though mtrace is probably more suited for that situation.

Greets,
 Jeroen

---

From: Fred Templin <[email-masked]>
Date: Tue, 23 Mar 2004 10:59:31 -0800

>topology (multiple routers) without handling loops is just

In light of Pekka's suggested NDproxy caveats (e.g., put a warning label
on the box, expect users to correctly interpret livelock due to looping as
a configuration issue, etc.), I have to agree with this. I think the 
terminology
may be getting a bit confusing here as well. When we say: "ND proxy", or
"Multilink subnet router", we are really referring to a device that acts 
as an
L2 bridge in some instances and inspects/modifies/responds to L3 message
contents in other instances - some have even called this "L2.5", and I 
recall
seeing the term "Brouter" used in days gone by.

In any case, I really believe such devices will require mechanisms to
support zero configuration and automatic topology discovery. A user
should be able to just plug it in and have it work without needing a
degree in network engineering to diagnose any number of esoteric
problems that might crop up. This means that we need some form of
loop prevention that is agile in terms of adapting to dynamic topology
changes, doesn't unnecessarily disable interfaces as a means for loop
prevention, and allows for neighbors to be reachable over possibly
multiple interfaces.

In other words, we need something like the experimental protocols
coming from the MANET wg (e.g., AODV, DSR, OLSR, TBRPF).
Even better would be a unified mechanism that combines the best
aspects of on-demand and reactive protocols.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Mar 2004 21:05:10 +0200 (EET)

>  2. Multilink subnet routing. Handles arbitrary topologies. Must

You cannot restrict (in protocol) that two boxes would not be 
deployed -- so what is the technical background to option 1)?

Actually that's pretty close to what I'm saying: recommend against 
deploying more than one box (or even forbid it completely), but if the 
user deploys two boxes in any case, this would still work just as long 
as you don't build topologies in which routing loops would exist.
I don't see that happening in the home networks.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Mar 2004 13:58:53 -0800 (PST)

> I agree with Erik.

Good :-)

>  2. Multilink subnet routing. Handles arbitrary topologies. Must

Agreed.

But furthermore I actually don't see the utility of #1.

First of all, based on RFC 3177 an ISP needs to be capable of handing of
/48 prefixes to customers. The issue here is when the ISP doesn't do that.
The unstated assumption for #1 seems to be that an ISP (that uses a form
service differentiation I disagree with but that is beside the point) can not
assign a single IPv6 address to one of their customers but is somehow
forced to at least hand out a /64 because it needs to assign a /64 to
the link between the ISP and the customer.
I think this assumption is false. An router does not need to advertise an
on-link prefix for the link between it and the client.
The client machine does need to be able to allocate an IP address
which is easy without an on-link prefix when using DHCPv6,
and a bit more subtle using stateless address autoconfiguration.
(The issue is how the host autoconfiguring an address effects the routing
on the ISP side.)

Thus I think the ISP that wants to charge differently for one IPv6 address
per customer compared to a /64 or /48 prefix can do this as easily as it
can in IPv4.
This implies that ISPs that want to hand out /64 or /48 prefixes
should use an explicit prefix delegation mechanism which explicitly
delegates the prefix to the customer and not implicitly does this
by assigning a /64 to the link between the ISP and the customer.

Hence ndproxy at the router the customer has on the link to the ISP
isn't necessary.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Mar 2004 08:35:12 +0200 (EET)

> /48 prefixes to customers. The issue here is when the ISP doesn't do that.

Precisely.

[...]
> (The issue is how the host autoconfiguring an address effects the routing

Stateless address autoconfig mode you're talking about is about 
advertising a /64 prefix on the link, with addrconfig flag set, and 
onlink flag not set --right?  While the onlink flag gives no 
information how the hosts could communicate between themselves, it 
still gives the ability to connect multiple hosts on a link -- so it 
cannot be used by the ISPs to force "1 user/prefix" -model, right?  
So, this doesn't seem to have practical benefits to just advertising a 
/64 on the link.

(The difference is just that without on-link flag, the hosts should 
communicate between themselves through the default router.)

> per customer compared to a /64 or /48 prefix can do this as easily as it

I don't know how this relates to the above, but this seems obvious.  
The point, however, is whether that /64 is really restricted to that 
link or not.  I.e., whether this is a weak form of "one host only" 
model or not. (Assuming the subnet can't be extended, the customer 
can't use his own proxies, firewalls, or the like, but would have to 
plug all the devices in parallel.)

> by assigning a /64 to the link between the ISP and the customer.

This is indeed a "should".  But the point is -- do we want to provide 
a solution for the case where this "should" does not hold?

Note that the ND-proxy case is rather strong in 3GPP environments as 
well: the nodes are given a /64 per PDP context.  If you want to hook 
up your laptop to your mobile (which has v6 PDP context), the mobile 
either has to do ND proxying, or you'll have to open a new PDP context 
on your laptop (e.g., of PPP type).  And those 3GPP guys always start 
screaming when you want to open more PDP contexts.. :)

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 25 Mar 2004 15:55:12 -0800 (PST)

> cannot be used by the ISPs to force "1 user/prefix" -model, right?  

Not if the link to the ISP is a pt-pt link, and all the case I've seen,
even if the L2 is broadcast capable such as in cable networks, the topology
visible to IP seems to be pt-pt.

The ISP can also do strict enforcement if they'd like on top of this.
For instance, by just letting the first IPv6 address they see coming over the
link from the subscriber as the only IPv6 address that can be used;
packets to/from other addresses could be filtered out by the ISP.

Thus in this tussle between the ISP (and its, IMHO misinformed, desire
to charge per host) and the user's desire to share the bandwidth they
are buying across multiple devices, it is not fruitful to try to use
protocols to try to force the ISP to change their thinking; it isn't hard
for them to do filters as a last resort to prevent what they think they
need to prevent.

What we can do from a protocol perspective (and implementation perspective)
is to make it easy for the ISP to do the right thing - explicitly delegate
a prefix (/48 by default as well as /64) to the customer.

> I don't know how this relates to the above, but this seems obvious.  

The basis for needing ndproxy in this case is that the ISP doesn't want to
explicitly delegate a prefix to their customer. I see two possible reasons
for this behavior (and there might be more)
 - the ISP wants to provide tiered services with a single device service
   at the bottom i.e. only allow one host/IPv6 address
 - it is too hard for them to explicitly delegate prefixes

What else might make then not do this?

  Erik

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 28 Mar 2004 20:31:48 -0500

At 12:56 PM +0200 3/23/04, Jari Arkko wrote:
>>  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, though.
>
>This is a danger, yes.

Why is this a danger?

IMO, the ND proxy mechanism effectively does bridging at layer 3. 
What makes you think it will be any easier here than at layer 2?  If 
layer 3 bridging is something that we need, then why not run STP?

There was some discussion of this general concept (zero-configuration 
routing and/or layer 3 bridging) in the Zerouter BOF and on the 
zerouter mailing list...  Does anyone know if that effort is still 
active?

Margaret

---

From: Greg Daley <[email-masked]>
Date: Mon, 29 Mar 2004 17:06:05 +1000

Hi Margaret,

>>>  lead to reinvention of the spanning tree protocol, though.

I think there's only a danger if we end up doing more work than
we need to, or work on something covered by other standards
bodies.

> IMO, the ND proxy mechanism effectively does bridging at layer 3. What 
> makes you think it will be any easier here than at layer 2?  If layer 3 
> bridging is something that we need, then why not run STP?

I think that using the spanning tree algorithm may be OK,
if we can work out appropriate root brouter selection, metrics
etc.

I'd suggest that extending the coverage of a bridged network with
802.1d/w spanning tree protocols is not a good idea though,
for a number fo reasons.

Firstly, the computational/message complexity of STP is such that
the convergence times will increase greatly by connecting
disparate bridged networks. (Even just running a separate
spanning tree amongst the proxies for a level of hierarchy would
work better, as area 0 does in OSPF).

Secondly, there are several issues in 802.1d/w networks
which are constraints due to the transparent nature of the
bridging in these networks (no modification to L2 frames).

In a proxied network, we can get much more control of the forwarding
plane by changing the L2 headers.
This may allow us to avoid the lack of redundancy present
in spanning trees (for example using DAGs or shortest paths
instead for unicast forwarding).

So L3 spanning trees may be one way to create a routing topology
for ND/MLD proxies, but it may not be the best way.

> routing and/or layer 3 bridging) in the Zerouter BOF and on the zerouter 
> mailing list...  Does anyone know if that effort is still active?

I'm not sure where zerouter work is at the moment.

The bof chair (Aidan Williams) was working at motorola
labs in Sydney which has closed down. I've had difficulty
tracking him down (mail bounces).

Radia Perlman and Aidan were working on this before.
in a (now expired) draft.

http://www.watersprings.org/pub/id/draft-perlman-zerouter-rbridge-00.txt

Greg

---

From: Brian Haberman <[email-masked]>
Date: Mon, 29 Mar 2004 06:41:35 -0500

> mailing list...  Does anyone know if that effort is still active?

I have not seen any activity on the zerouter mailing list for a LONG
time.  That does not mean that people aren't working on it under the
radar though...

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Mar 2004 15:15:17 +0300 (EEST)

> visible to IP seems to be pt-pt.

Counterexamples include bridged xDSL and Ethernet to the Home (without
PPP framing, or advertising the /64 on top of the PPP session).
 
> packets to/from other addresses could be filtered out by the ISP.

Of course -- there is no stopping that.
 
>    at the bottom i.e. only allow one host/IPv6 address

I might reword this slightly, to: "wants to provide tiered services
simply: a) with a /48 delegation, or with either b) /64 link or just
c) one address".  We of course hope that c) would not happen, but have
no power to stop an ISP if they do it in any case.

>  - it is too hard for them to explicitly delegate prefixes

Note that this is not a binary decision, i.e., the ISP might decide
that "OK, it's not too hard for us to delegate the prefixes, but if we
do that, we want some extra payment from the user for the trouble".  
In that kind of environment, ensuring that the users have tools to
cope with a /64 prefix as well would seem to be really important.

For these two basic cases, I think ND-proxy would be applicable in
1.b) (of my own proposition, above) and 2).

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Mar 2004 10:35:13 -0800 (PST)

> do that, we want some extra payment from the user for the trouble".  

So then you end up with a single IPv6 address, right?

> cope with a /64 prefix as well would seem to be really important.

But the /64 isn't delegated to the subscriber - it is merely assigned
to the link between ISP and the subscriber.

I think RFC 3177 is quite clear on its recommendation.
Why can't we simplify the message and avoid developping additional protocols
(which are as likely to slow down IPv6 deployment as speeding it up) by saying
that ISPs which don't delegate at least a /64 (using a protocol/mechanism
which delegates it to the *subscriber* and not just assigning it to the link
from the ISP and the subscriber) doesn't follow the implications of the
recommendation in 3177?

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Mar 2004 22:00:05 +0300 (EEST)

> So then you end up with a single IPv6 address, right?

Not necessarily.  If you don't run something like PPPv6 on the link to 
the customer, just advertising a /64 on the customer link seems to be 
the simplest thing the ISP can do.  (Even simpler than just a single 
IPv6 address.)

Without ND-proxy or bridging, that's one IPv6 address.

> to the link between ISP and the subscriber.

Sure, but with ND-proxy this distinction is irrelevant, which was the 
the point to begin with.
 
> from the ISP and the subscriber) doesn't follow the implications of the

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.

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

This takes no stance on the other "subnet extending" scenarios where
ND-proxy could be desirable, like a gadget on firewire connected to
your PC.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Mar 2004 12:09:13 -0800 (PST)

> have simple enough means available.

My worry is that ISPs would end up doing nothing because of the existance
of nd proxy.
Hence I conclude we should make prefix delegation work and make the
implementations of it as easy as possible to use.
Then the ISP can decide whether to delegate nothing (and customer gets
a single address) or delegate /64, /48.

> delegated /48.  If that is not possible, advertising a /64 on the link

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.

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Mar 2004 16:06:42 -0500

> > have simple enough means available.

I know that there are service providers in Japan that plan to
use DHCP PD to provide /48 prefixes to customers.  Therefore,
DHCP PD is apparently "simple enough" that some ISPs do not
consider it a barrier to deployment.

Do we have any examples of ISPs that have reviewed DHCP PD
and rejected it as not simple enough?

>a single address) or delegate /64, /48.

I agree that we should continue to work on improving prefix delegation
(if, indeed., it needs improvement).

>In the big picture this is a distraction and not a help.

I agree here, as well ... we have a solution that works, has been
accepted as a standard and is being deployed.

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Mon, 29 Mar 2004 23:47:28 +0100

Pekka, et al,

>> I think RFC 3177 is quite clear on its recommendation.  Why can't
>> we simplify the message and avoid developping additional protocols
>> (which are as likely to slow down IPv6 deployment as speeding it
>> up) by saying that ISPs which don't delegate at least a /64 (using
>> a protocol/mechanism which delegates it to the *subscriber* and not
>> just assigning it to the link from the ISP and the subscriber)
>> doesn't follow the implications of the recommendation in 3177?
>
> 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.
>

seems to me that we're trying to engineer a solution to a problem
which we _think_ may exist, but only because we don't trust the ISPs
to do the right thing. the IETF has already given the recommendation
that each user should get a /48, as long as we make protocols, so that
it is a cheap to delegate a /48 as a /64 we've done out job. the
market should sort the rest out.

if that turns out to be wrong, then we have enough alternatives we can
work on then.

 - ND proxy
 - RA proxy
 - MLSR
 - bridging
 - longer prefixes than /64
 - NAT
 - ...

/ot