Subject: [rbridge] RBridges and SEND/CGA

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed Jan 26 14:00:18 2005

One advantage of RBridges is that, with IP optimizations, they can do proxy ARP greatly reducing ARP flooding. I was thinking about whether this also applies to signed Neighbor Discovery messages in IPv6. Seems to me that it does.

In particular, if you pass along in the link state message not only MAC addresses but also the corresponding IP addresses and ND signatures, then the RBridges can do proxy ND and greatly reduce ND flooding the same way they can reduce ARP flooding. So it seems very simple to do.

Has anyone else thought about this?

Thanks,
Donald

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed Jan 26 15:10:20 2005

Eastlake III Donald-LDE008 wrote:
> One advantage of RBridges is that, with IP optimizations, they can do
> proxy ARP greatly reducing ARP flooding. I was thinking about whether
> this also applies to signed Neighbor Discovery messages in IPv6.
> Seems to me that it does.
> 
> In particular, if you pass along in the link state message not only
> MAC addresses but also the corresponding IP addresses and ND
> signatures, then the RBridges can do proxy ND and greatly reduce ND
> flooding the same way they can reduce ARP flooding. So it seems very
> simple to do.

SeND has replay protection for solicited information (NA as a result of 
a NS, RA as result of a RS) that uses nonces if I'm not mistaken.
Since the nonce is protected by the signature, the rbridge can't replay 
a NA/RA in response to a NS/RS, since it would be detected.
(I think the unsolicited information uses a time stamp instead, which 
allows for some amount of caching and replay by an rbride).

But the packets still don't need to be flooded across the whole topology 
since the first rbridge in the path can send the packet to the last 
rbridge in the path, so that the host can respond.

   Erik

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Wed Jan 26 16:58:48 2005

It wasn't easy finding the SEND draft. I can't find it listed under 
drafts in the IPv6 group. I found
it by doing a search under internet drafts. And I couldn't find a WG 
called SEND. But
anyway, for benefit of anyone else who wants to look at the SEND draft:

http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-06.txt

And indeed it does have timestamp and nonce options. But Erik's 
suggestion nicely
avoids flooding the ND query and reply even with nonces, and also avoids 
cluttering
the LSP info with signatures.

I was wondering why they would want replay protection. In the case where
the target has changed its layer 2 address, you wouldn't want someone 
replaying the
old ND reply. Is there any other case for which SEND would want 
freshness, as in perhaps
a form of low-level ping to see if the node is actually alive? Would 
anyone use ARP
this way? If so, perhaps ARP should be handled per Erik's 
suggestion...not actually
flooding the query, but still making the target actually answer the 
query (by having the
first RBridge forward the query to the destination RBridge).

Radia

Erik Nordmark wrote:

> SeND has replay protection for solicited information (NA as a result 
> of a NS, RA as result of a RS) that uses nonces if I'm not mistaken.
> Since the nonce is protected by the signature, the rbridge can't 
> replay a NA/RA in response to a NS/RS, since it would be detected.
> But the packets still don't need to be flooded across the whole 
> topology since the first rbridge in the path can send the packet to 
> the last rbridge in the path, so that the host can respond.
>
>   Erik
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Thu Jan 27 13:48:22 2005

Radia Perlman wrote:

> this way? 

I don't know if this is done or not(but using ARP broadcast as a 
liveness test would be more expensive than using unicast ICMP echo, so 
hopefully this isn't that common).

The other thing one could be concerned about is if there are some 
non-standard extensions to arp (extra stuff at the end?) which needs to 
be carried between the hosts. I've never heard of such a thing for ARP 
over Ethernet, so I don't know if one needs to worry about this.

> If so, perhaps ARP should be handled per Erik's 

Even if we don't have the above concerns for ARP, it might still be 
simpler to say that the rbridges make the delivery of the ARP more 
efficient (no flooding when the bridges know where the target is) but 
the rbridges never proxy respond to an ARP packet.
That way we get less flooding of ARPs, yet keep the rbridges simple and 
future proof for weird ARP stuff.

    Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu Jan 27 15:14:48 2005

> Radia Perlman wrote:
...
>> If so, perhaps ARP should be handled per Erik's suggestion...not actually

IMO, choosing not to flood a broadcast packet is a bad thing. In this 
case, when the host moves, if the host is otherwise silent, there's no 
way to find it until the ARP routing tables die out (if they're 
separate, and if they ever do die out).

I.e., "never proxy respond to an ARP packet" is good.
"Never ROUTE a broadcast packet" may also be necessary.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050127/9f1f11ad/signature.bin

---

From: greg.daley at eng.monash.edu.au (Greg Daley)
Date: Thu Jan 27 16:20:51 2005

Hi Donald,

Sorry about the tardy reply,

> Has anyone else thought about this?

proxy arp is not trivial in SEND, due to the origin devices signing
information regarding their link-layer address in the ND messages.

This is incompatible with any proposals where intervening devices
need to substitute their own MAC address as the next destination
for a packet.

A short draft describing some of the issues is available at:

http://www.ietf.org/internet-drafts/draft-daley-send-spnd-prob-00.txt

This is mainly aimed at Mobile-IPv6, since there's not been much
interest in SEND and proxy ND otherwise.

Greg Daley.

---

From: greg.daley at eng.monash.edu.au (Greg Daley)
Date: Thu Jan 27 16:32:24 2005

Hi Joe,

Joe Touch wrote:
>> That way we get less flooding of ARPs, yet keep the rbridges simple 
>> and future proof for weird ARP stuff.
> 
> 

If we're talking about moving nodes (MNs), with rbridges providing
local proxy service, I guess there's two approaches:

1) Probe across the routed fabric for updated locations for MNs

    perhaps this could be done with ND, but potentially
    asynchronously.  In almost all locations in the rbridge the
    service ND needs to be proxied, only on sublinks which the MN has
    just moved to or from will this change.

2) ensure that the MN provides updated information upon arrival,
    propagate this change to the other rbridges.

    The really tricky bit here is to find a hook into the protocols
    which ensure that the MN updates the router with a unique identity
    which is able to be tied to the last location.  I can't think of
    a part of IPv6 which can be used this way off the top of my head
    (unless the MAC address moves, and we can track that... it's
    hardly secure though).

I'd guess it would be possible do #1 fairly readily though.

Greg Daley

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu Jan 27 16:47:14 2005

Greg Daley wrote:
>    asynchronously.

Why? Why not allow ARP (we were talking about ARP, i.e., IPv4, at one 
point, and I still am) to use broadcast?

> In almost all locations in the rbridge the

Broadcast services need not be proxied; if you disagree, please prove 
otherwise.

And how does one magically find the sublink to which nodes move? (again, 
in IPv4?) - assume static IP config, so you can't assume DHCP helps you 
here.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050127/c8bafbfc/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Thu Jan 27 16:58:25 2005

> separate, and if they ever do die out).

We do need to handle movement, but I think it is desirable to not flood 
*every* ARP packet across the topology. So perhaps sending the first ARP 
packet using the MAC-address routing tables, but detecting a 
retransmitted ARP and flooding that one would be a reasonable compromise.

   Erik

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Thu Jan 27 17:26:38 2005

Or perhaps in the case of routing the query, having the source's RBridge
noticing if there is a reply to the routed ARP/ND query, and if there is 
not, then
retrying with flooding.

For pure proxy (not routing the query), it might be nice if ARP/ND could 
have a flag
like DECnet did. DECnet had a flag called "tryhard" in the API to
layer 3, in which the upper layer could set it in order to tell layer 3 
to delete any
caches that might be incorrect. So if there were such a way to signal in 
the query
when communication is not working (because perhaps the MAC address in your
ARP cache is wrong), so that the RBridge should check the validity of 
the information
it is proxying...

It is unlikely this change would ever be put into ARP, and it makes 
RBridges less transparent.

But by the way, is there any way of doing the DECnet "tryhard" thing
within a node? (have the upper layer signal
that perhaps the local ARP cache is wrong and should be refreshed?)

Radia

Erik Nordmark wrote:

>> case, when the host moves, if the host is otherwise silent, there's 
>> no way to find it until the ARP routing tables die out (if they're 
> We do need to handle movement, but I think it is desirable to not 
> flood *every* ARP packet across the topology. So perhaps sending the 
> first ARP packet using the MAC-address routing tables, but detecting a

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu Jan 27 21:02:25 2005

> retransmitted ARP and flooding that one would be a reasonable compromise.

How would you know when to stop flooding ARPs, e.g., when the node moves 
on the other end?

In particular, what happens when its the second broadcast ARP that would 
have worked?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050127/e71ab44b/signature.bin

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Thu Jan 27 21:42:25 2005

Joe...I think you might have misunderstood what Erik wrote. But at any 
rate, I think
some variant of the below are possibilities:

a) always flood ARP/ND query on the spanning tree
b) always do an optimized reply (either proxy the reply or route the
query to the RBridge that claims the
destination is attached). Then if the first RBridge notices the 
optimized thing
didn't work (either because there is a retransmitted query within a 
short amount of
time or because there is no reply from the destination), then flood the 
query.
c) always route the query. (and if the destination has moved, eventually the
destination RBridge will notice and remove it from its LSP)
d) always proxy the reply (and again, the destination RBridge will 
eventually
notice the destination has moved)
e) have some timer where if there has been an ARP/ND reply from the 
destination
within some amount of time, then do the optimized thing (proxy or route 
the query)

It's all a matter of what to optimize...overhead of discovery vs 
bandwidth vs simplicity
of protocol.

Radia

Joe Touch wrote:

>
>
> Erik Nordmark wrote:
>
>> Joe Touch wrote:
>>
>>>
>>> IMO, choosing not to flood a broadcast packet is a bad thing. In 
>>> this case, when the host moves, if the host is otherwise silent, 
>>> there's no way to find it until the ARP routing tables die out (if 
>>> they're separate, and if they ever do die out).
>>
>>
>>
>> first ARP packet using the MAC-address routing tables, but detecting 
>> a retransmitted ARP and flooding that one would be a reasonable 
>> compromise.
>
>
> How would you know when to stop flooding ARPs, e.g., when the node 
> moves on the other end?
>
> In particular, what happens when its the second broadcast ARP that 
> would have worked?
>
> Joe
>
>------------------------------------------------------------------------
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Jan 28 09:01:59 2005

Radia Perlman wrote:
> Joe...I think you might have misunderstood what Erik wrote.

Hard to believe, since most of the ideas below are what I expected. 
Although I'm thinking more about correctness and the bounds of what ARP 
dests are allowed to do, rather than the 'typical' case.

> But at any 

> a) always flood ARP/ND query on the spanning tree

Works (clearly).

> time or because there is no reply from the destination), then flood the 

If you proxy the reply and the destination has moved, then you're 
polluting the client's ARP cache.

If you don't, you're necessarily waiting for the second query, which 
means a delay.

> destination RBridge will notice and remove it from its LSP)

The 'eventually' again is the issue. And how does the dest rbridge know 
things have moved? And some clients may choose to respond to some ARPs 
and not others; in that case, silence on ARPs - which is _valid_ - 
causes the rbridge routing to thrash.

> notice the destination has moved)

The destination rbridge wouldn't necessarily notice anything. You told 
the source where the dest is; packets flow, and are sent to the (now 
gone) dest. If this is UDP, nobody notices anything.

> within some amount of time, then do the optimized thing (proxy or route 

If I understand this one, it's a "positive reinforcement" version, i.e., 
routes only if valid ARPs have been seen in response. This sounds safer, 
but still has the 'timeout' problem.

> It's all a matter of what to optimize...overhead of discovery vs 

My concern is trading optimization for correctness. And the fact that 
we're optimizing for a protocol that caches anyway. Why?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050128/5967822f/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Jan 28 10:16:51 2005

> How would you know when to stop flooding ARPs, e.g., when the node moves 

The idea is that the rbridge can have a history of recent ARP packets 
(capturing a few seconds worth).
When it sees an ARP it does:
  - Is there an LSA for the mac address?
    - If not, flood (handle the case when the LSAs haven't been flooded yet)
    - If yes, is the sender and target in the recent history?
	Yes implies it could be a retransmitted ARP, so flood it
	No, no need to flood

   Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Jan 28 10:52:24 2005

> (capturing a few seconds worth).

I.e.., and ARP cache ;-)

>     Yes implies it could be a retransmitted ARP, so flood it

What's the benefit of that last case? How often is this going to happen 
that we need a special mechanism to deal with it?

Also, what does an LSA _mean_? How do you distinguish between an idle 
host and one that has moved but not sent traffic yet?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050128/abfbcee6/signature.bin

---

From: alper.yegin at samsung.com (Alper Yegin)
Date: Fri Jan 28 15:30:25 2005

> > c) always route the query. (and if the destination has moved,
eventually
> > the

In IEEE 802.11, the L2 is connection-oriented. The L2 access device (AP,
Access Point) knows the MAC address of the newly associated host. So,
the new (serving) Rbridge in that case readily knows when a new host
connects.

Disconnect is not that "prompt". A host that walks away from the AP may
not properly tear-down the link. In that case, a timeout may be needed
(or, mechanisms like IAPP may help notifying the previous AP by the new
AP).

What happens in .11 is pretty common to wireless access technologies.
Not sure how applicable this is to wired networks. Does anyone know,
like in wired Ethernet served by a switch/bridge?

Anyways, we should be able to take advantage of this information where
available.

Alper