Subject: [rbridge] Updated charter

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Thu Jan 27 17:52:37 2005

Based on the feedback from the BoF in August and some preliminary 
feedback from IESG/IAB members, I've edited the charter.

There are additions about supporting clouds which contain different L2 
technologies (something folks asked about at the BoF, but we didn't talk 
about) and we can have technical discussions about that on the list.

There is also some more flushing out of details.

And editorial changes to make the description more positive.

Hopefully this can be used to get a BoF and start the WG chartering 
discussion.

    Erik

-------------- next part --------------
While IEEE 802 bridges are attractive due to not needing explicit 
configuration and allowing hosts to move within the bridged topology,
they are more limited than IP routers since bridges 
only support IEEE 802 technologies, and the most common layer 2 
interconnection method (dynamically created spanning tree 
formation using bridges) is not as flexible and robust as layer 3 routing. 

The WG will design a hybrid solution that combines the simplicity of 
configuration while taking full advantage of complex topologies.

The design should have the following properties:
 - zero configuration of the hybrid devices
 - ability for hosts to move without changing their IP address
 - it should be possible to forward packets using pair-wise shortest paths,
   and exploit the redundant paths through the network for increased
   aggregate bandwidth
 - ARP and Neighbor Discovery packets should be optimized and not necessarily
   be flooded everywhere
 - support Secure Neighbor Discovery
 - the packet header should have a hop count for robustness in the presence
   of temporary routing loops
 - nodes should be able to have multiple attachments to the network
 - no delay when a new node is attached to the network
 - multicast should work (and after a re-charter it might make sense to 
   look at optimizations for IP multicast)

The working group will look into solutions that can interconnect different
layer 2 technologies, and also look at providing support for non-IP protocols,
even though one can not combine those two features together; the 
interconnection of different layer 2 technologies (with different layer 2
address formats) will most likely only work for the IP family of protocols.

The WG will design a protocol that combines the benefits of bridges 
and routers in a way that will co-exist with existing hosts, IP routers
and bridges. The design should support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
 - Optimizations so that ARP and ND packets are not always
   flooded everywhere
 - Being able to carry IP multicast packets using flooding (which will
   presumably fall out by being able to flood L2 multicast packets, so there
   might not be any specific work needed here).
 - Defining the L3 operations needed to interconnect different L2 technologies

The work consists of several, separable pieces:
 - Defining what information should be carried in routing protocols in order
   to support this concept. The encoding of this information within the
   routing protocol will be left as an action item for the specific routing
   protocol WG. 
 - Defining what information must be carried in an encapsulation header for
   data packets, and how to map that information to various link types (e.g.,
   IEEE LAN, Fibrechannel, MPLS)
 - Defining how address resolution (ARP and Neighbor Discovery) is performed,
   taking into account the desire to be compatible with Secure Neighbor 
   Discovery.
 - Defining how the solution extends to the case when multiple layer 2
   technologies, that have different address format/length, are interconnected.

Deliverables
 - A short draft on the problem statement and goals
 - A document defining what information needs to be carried in routing
   protocols to support the rbridge concept.
 - Encapsulation draft specifying what needs to be carried in general
   and the specific format to use on IEEE LANs
 - ARP and ND draft
 - Draft on interconnecting different types of layer 2 technologies

---

---

From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Fri Jan 28 02:10:54 2005

Hi Erik,

just one comment,
the charter is silent w.r.t security and during the BoF there were many 
concerns about this (some of them, like Gab's comments, made a lot of 
sense to me). Shouldn't the draft explicitly state that a threat 
analysis need to be delivered and that no vulnerabilities can be 
introduced? (perhaps this is obvious and there is no need to mention 
it, but anyway...)

Regards, marcelo

El 28/01/2005, a las 2:50, Erik Nordmark escribi?:

> technologies (something folks asked about at the BoF, but we didn't 
> talk about) and we can have technical discussions about that on the 
> list.
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Fri Jan 28 02:18:22 2005

Hi,

On Fri, 28 Jan 2005, marcelo bagnulo braun wrote:
> concerns about this (some of them, like Gab's comments, made a lot of sense 
> to me). Shouldn't the draft explicitly state that a threat analysis need to 
> be delivered and that no vulnerabilities can be introduced? (perhaps this is 
> obvious and there is no need to mention it, but anyway...)

Well, there are _always_ new vulnerabilities.

Maybe it is worth saying that the security must not get worse than it 
is currently with LANs (or heavily bridged LANs), or the like (a la 
multi6)?

-- 
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 at sun.com (Erik Nordmark)
Date: Fri Jan 28 11:04:29 2005

marcelo bagnulo braun wrote:
> introduced? (perhaps this is obvious and there is no need to mention it, 
> but anyway...)

Good point. Perhaps the deliverable should be an applicability statement 
that points out things like filtering being harder than a routed network 
etc, so you don't want to think a rbridged network is a replacement for 
a routed network.

There might be non-security AS type things we should cover as well, such 
as recommending that the size of the rbridge cloud be limited due to 
broadcasts being flooded.

    Erik

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Fri Jan 28 20:09:47 2005

> broadcasts being flooded.

Also: it would be very desirable if the behavior seen by hosts in the presence
of other misconfigured hosts should be the same or better than what you get
with a traditional network.

As a specific example, when two or more nodes assert ownership over the same
address with arp, all nodes should see all the traffic (since hosts can ring
alarm bells/log/audit/etc. when they're being spoofed).

							- Bill

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Jan 28 21:18:24 2005

> alarm bells/log/audit/etc. when they're being spoofed).

I think you are stating a potential goal for rbridges that when multiple 
hosts claim the same MAC address, they should all receive a copy of 
packets to such a MAC address.
Do folks agree that this would be reasonable?

I don't think a solution can guarantee this when there is a mixture of 
802.1D bridges and rbridges, because 802.1D bridges don't provide this, 
but as long as the hosts are attached to different rbridges I think it 
would be possible.

    Erik

---

From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Sat Jan 29 02:12:27 2005

El 29/01/2005, a las 6:15, Erik Nordmark escribi?:

> I think you are stating a potential goal for rbridges that when 
> multiple hosts claim the same MAC address, they should all receive a 
> copy of packets to such a MAC address.

but, wouldn't this render trivial to sniff any communication across the 
whole bridged cloud?
i mean, i don't think it would acceptable to substitute routers by 
rbridges if one of the costs is that anyone can sniff any 
communication....

Perhaps we need to define link-layer CGA addresses to properly address 
this issue?

Regards, marcelo

> 802.1D bridges and rbridges, because 802.1D bridges don't provide 
> this, but as long as the hosts are attached to different rbridges I 
> think it would be possible.
>
>    Erik

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Sat Jan 29 06:26:52 2005

> packets to such a MAC address.

not quite; one way to accomplish what I was suggesting is to ensure that all nodes
see all ARP/ND traffic mentioning their IPv4/IPv6 address so that host based passive
duplicate address detection schemes can work.

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Sat Jan 29 06:42:53 2005

> but, wouldn't this render trivial to sniff any communication across the 

Seems to me like the existing properties in the charter (allow nodes 
to move at will; zero delay on new node connection, etc) will already allow for
relatively trivial traffic hijacking, which, if anything, is worse than 
passive sniffing.

With both nodes getting the traffic you at least prevent that denial-of-service.

> rbridges if one of the costs is that anyone can sniff any 

I want it to be acceptable to replace bridges with rbridges; I don't think it will
be acceptable to do that if you can spoof arp undetectably.

And nothing prevents the rbridge from locking down certain addresses when
local policy says to.

							- Bill

---

From: michsmit at cisco.com (Michael Smith)
Date: Sat Jan 29 09:08:30 2005

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bill Sommerfeld
> Sent: Saturday, January 29, 2005 6:41 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Updated charter
> 
> > but, wouldn't this render trivial to sniff any communication across 
> > the whole bridged cloud?
> 
> Seems to me like the existing properties in the charter 
> (allow nodes to move at will; zero delay on new node 
> connection, etc) will already allow for relatively trivial 
> traffic hijacking, which, if anything, is worse than passive sniffing.
> 

Today, this is addressed in bridges using features such as 802.1X and
Cisco's Dynamic ARP Inspection.  Sending the ARP reponses to all hosts
claiming a particular IP address (in other words, replicating the "bad"
traffic) looks to open a wide possibility of DDoS attacks to both the hosts
involved and especially the rbridges performing the replication.  IMHO, this
is functionality much better performed within the ingress rbridge rather
than the egress host. 

Michael

> I want it to be acceptable to replace bridges with rbridges; 
> I don't think it will be acceptable to do that if you can 
> spoof arp undetectably.
> 
> And nothing prevents the rbridge from locking down certain 
> addresses when local policy says to.
> 
> 							- Bill
> 
> 
> 
> 
>

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Sat Jan 29 09:40:26 2005

On Sat, 2005-01-29 at 12:07, Michael Smith wrote:

> Sending the ARP reponses to all hosts
> traffic) 

If the rbridge has a reliable way to tell a "good arp" from a "bad arp", it
should definitely not forward the "bad" ones.  

What should it do when it can't tell?   If you allow for mobility 
and unmanaged operation, you're going to have to allow for addresses to pop
up at perhaps unexpected places, and *that* is what will cause DoS potential.

> IMHO, this

perhaps if all switches and hosts are under the same administration and
the network admins are good enough to tell host admins that their switches detected this anomalous behavior....

but that presumes a state of organizational and operational harmony between
network and host administrators that i have rarely encountered in the
production networks I'm familiar with.

						- Bill

---

From: michsmit at cisco.com (Michael Smith)
Date: Mon Jan 31 08:58:37 2005

> From: Bill Sommerfeld [mailto:[email-masked]] 
> Sent: Saturday, January 29, 2005 9:39 AM
> To: [email-masked]; Developing a hybrid router/bridge.
> 
> If the rbridge has a reliable way to tell a "good arp" from a 
> "bad arp", it should definitely not forward the "bad" ones.  
> 
> and unmanaged operation, you're going to have to allow for 
> addresses to pop up at perhaps unexpected places, and *that* 
> is what will cause DoS potential.

Assuming the hosts are using DHCP, DHCP snooping at the ingress bridge can
be used to verify the MAC-to-IP binding ensuring that the DHCP policy is
enforced.  If static addressing is used, then there should probably be a
static entry in the MAC-IP binding table.  That said, static addressing and
mobility usually don't mix.
> 
> > IMHO, this
> > is functionality much better performed within the ingress rbridge 
> > rather than the egress host.
> 
> perhaps if all switches and hosts are under the same 
> administration and the network admins are good enough to tell 
> host admins that their switches detected this anomalous behavior....
> 
> but that presumes a state of organizational and operational 
> harmony between network and host administrators that i have 
> rarely encountered in the production networks I'm familiar with.

My understanding is that host addressing is usually in the domain of the
networking folks.  But in general, I agree, there are sometimes
organizational issues which in this case is probably between the network and
the security admins.  Typically, administrators have a much better idea of
the networking gear attached to their network than the hosts they have
attached. Relying on the rbridge to enforce MAC-IP binding seems much more
manageable than leaving it to the wide multitude of host devices on the
network.  

Michael

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon Jan 31 09:08:34 2005

> mobility usually don't mix.

That didn't actually answer my question. 

I repeat: what should rbridges do when they can't tell whether the MAC-IP binding is
authorized?

My suggestion regarding mirroring the arps is not intended to replace enforcement 
when such mechanisms exist.

Instead, it is an attempt to get an out-of-the-box, unmanaged rbridge net to behave 
at least as well as a broadcast ethernet domain behaves -- the host being spoofed 
will quickly become aware that spoofing is going on!

						- Bill

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon Jan 31 10:32:59 2005

> Do folks agree that this would be reasonable?

I'm not sure that an rbridge should behave differently from a bridged 
system (below) in this regard.

-------------- 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/20050131/100a898d/signature.bin

---

From: michsmit at cisco.com (Michael Smith)
Date: Mon Jan 31 11:22:36 2005

> Sent: Monday, January 31, 2005 9:08 AM
> Subject: RE: [rbridge] Updated charter
> 
> > > and unmanaged operation, you're going to have to allow 
> for addresses 
> > > to pop up at perhaps unexpected places, and *that* is what will 
> > > cause DoS potential.
> > 
> > Assuming the hosts are using DHCP, DHCP snooping at the 
> ingress bridge 
> > can be used to verify the MAC-to-IP binding ensuring that the DHCP 
> > policy is enforced.  If static addressing is used, then 
> there should 
> > probably be a static entry in the MAC-IP binding table.  That said, 
> > static addressing and mobility usually don't mix.
> 
> I repeat: what should rbridges do when they can't tell 
> whether the MAC-IP binding is authorized?

Ok, to be more concise, IMHO, an out-of-the-box rbridge should do nothing
(today's behaviour).  The requestor will potentially receive multiple ARP
responses from the different hosts and can flag this behaviour if desired.  

I'm assuming by mirroring you are referring to replicating the ARP response
and unicasting it to each of the devices claiming the IP address.  To mirror
the ARP responses, the rbridges would potentially need to know all of the
MAC-IP bindings of all devices in the subnet.   This raises questions of how
long to remember the bindings, what happens when DHCP leases expire, etc.
Also, it's unclear which rbridge would do the mirroring as it would have to
be done in such a way that every rbridge in the path is not mirroring
(replicating) the packet and creating a giant DOS attack.

Michael

> 
> My suggestion regarding mirroring the arps is not intended to 
> replace enforcement when such mechanisms exist.
> 
> Instead, it is an attempt to get an out-of-the-box, unmanaged 
> rbridge net to behave at least as well as a broadcast 
> ethernet domain behaves -- the host being spoofed will 
> quickly become aware that spoofing is going on!
> 
> 						- Bill
> 

From: "Michael Smith" <[email-masked]>
To: "'Bill Sommerfeld'" <[email-masked]>
Subject: RE: [rbridge] Updated charter
Date: Mon, 31 Jan 2005 11:20:52 -0800
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2151

> Sent: Monday, January 31, 2005 9:08 AM
> Subject: RE: [rbridge] Updated charter
> 
> > > and unmanaged operation, you're going to have to allow 
> for addresses 
> > > to pop up at perhaps unexpected places, and *that* is what will 
> > > cause DoS potential.
> > 
> > Assuming the hosts are using DHCP, DHCP snooping at the 
> ingress bridge 
> > can be used to verify the MAC-to-IP binding ensuring that the DHCP 
> > policy is enforced.  If static addressing is used, then 
> there should 
> > probably be a static entry in the MAC-IP binding table.  That said, 
> > static addressing and mobility usually don't mix.
> 
> I repeat: what should rbridges do when they can't tell 
> whether the MAC-IP binding is authorized?

Ok, to be more concise, IMHO, an out-of-the-box rbridge should do nothing
(today's behaviour).  The requestor will potentially receive multiple ARP
responses from the different hosts and can flag this behaviour if desired.  

I'm assuming by mirroring you are referring to replicating the ARP response
and unicasting it to each of the devices claiming the IP address.  To mirror
the ARP responses, the rbridges would potentially need to know all of the
MAC-IP bindings of all devices in the subnet.   This raises questions of how
long to remember the bindings, what happens when DHCP leases expire, etc.
Also, it's unclear which rbridge would do the mirroring as it would have to
be done in such a way that every rbridge in the path is not mirroring
(replicating) the packet and creating a giant DOS attack.

Michael

> 
> My suggestion regarding mirroring the arps is not intended to 
> replace enforcement when such mechanisms exist.
> 
> Instead, it is an attempt to get an out-of-the-box, unmanaged 
> rbridge net to behave at least as well as a broadcast 
> ethernet domain behaves -- the host being spoofed will 
> quickly become aware that spoofing is going on!
> 
> 						- Bill
> 

Date: Mon, 31 Jan 2005 10:31:03 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1770

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig304A8D840E124B432512C0C7
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> but as long as the hosts are attached to different rbridges I think it 

--------------enig304A8D840E124B432512C0C7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig304A8D840E124B432512C0C7--

Subject: RE: [rbridge] Updated charter
From: Bill Sommerfeld <[email-masked]>
To: [email-masked]
Date: Mon, 31 Jan 2005 12:08:06 -0500
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1123

						- Bill

From: "Michael Smith" <[email-masked]>
To: "'Bill Sommerfeld'" <[email-masked]>, "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: RE: [rbridge] Updated charter
Date: Mon, 31 Jan 2005 08:56:18 -0800
Cc: 
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2104

Michael

> 						- Bill

Subject: RE: [rbridge] Updated charter
From: Bill Sommerfeld <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Date: Sat, 29 Jan 2005 12:38:38 -0500
Cc: 
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1025

						- Bill

From: "Michael Smith" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: RE: [rbridge] Updated charter
Date: Sat, 29 Jan 2005 09:07:35 -0800
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1838

Michael

Subject: Re: [rbridge] Updated charter
From: Bill Sommerfeld <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Sat, 29 Jan 2005 09:41:10 -0500
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 894

							- Bill

Subject: Re: [rbridge] Updated charter
From: Bill Sommerfeld <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Sat, 29 Jan 2005 09:24:40 -0500
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 453

From: marcelo bagnulo braun <[email-masked]>
Subject: Re: [rbridge] Updated charter
Date: Sat, 29 Jan 2005 11:08:49 +0100
To: "Developing a hybrid router/bridge." <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1485

Regards, marcelo

> think it would be possible.

Date: Fri, 28 Jan 2005 21:15:41 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 900

    Erik

Subject: Re: [rbridge] Updated charter
From: Bill Sommerfeld <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Fri, 28 Jan 2005 23:08:05 -0500
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 638

							- Bill

Date: Fri, 28 Jan 2005 15:29:59 -0800
From: Alper Yegin <[email-masked]>
Subject: RE: [rbridge] RBridges and SEND/CGA
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Importance: Normal
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 876

> > c) always route the query. (and if the destination has moved,
eventually
> > the
> > destination RBridge will notice and remove it from its LSP)

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

Date: Fri, 28 Jan 2005 11:03:22 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 862

    Erik

Date: Fri, 28 Jan 2005 10:51:50 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1875

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBBFDE7CB2822746BB28D598A
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Erik Nordmark wrote:
> Joe Touch wrote:
> 
>>> 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.
>>
>>
>>
>> How would you know when to stop flooding ARPs, e.g., when the node 
>> moves on the other end?
> 
> 
> The idea is that the rbridge can have a history of recent ARP packets 
> (capturing a few seconds worth).

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

> 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

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

--------------enigBBFDE7CB2822746BB28D598A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigBBFDE7CB2822746BB28D598A--

Date: Fri, 28 Jan 2005 10:14:30 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1147

Joe Touch wrote:

>> 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.
> 
> 
> How would you know when to stop flooding ARPs, e.g., when the node moves 
> on the other end?

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

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

Date: Fri, 28 Jan 2005 08:58:24 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3036

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig24366EEBBA6C28E9764E7C44
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 
> rate, I think
> some variant of the below are possibilities:

Some have problems:

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

Works (clearly).

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

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.

> c) always route the query. (and if the destination has moved, eventually 
> the
> 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.

> d) always proxy the reply (and again, the destination RBridge will 
> eventually
> 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.

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

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 
> bandwidth vs simplicity
> of protocol.

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

Joe

--------------enig24366EEBBA6C28E9764E7C44
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig24366EEBBA6C28E9764E7C44--

Date: Fri, 28 Jan 2005 12:17:54 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 816

Hi,

From: marcelo bagnulo braun <[email-masked]>
Subject: Re: [rbridge] Updated charter
Date: Fri, 28 Jan 2005 11:08:39 +0100
To: "Developing a hybrid router/bridge." <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4872

Hi Erik,

just one comment,

Regards, marcelo

>  - Draft on interconnecting different types of layer 2 technologies

Date: Thu, 27 Jan 2005 21:40:53 -0800
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
To: "Developing a hybrid router/bridge." <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2133

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

Date: Thu, 27 Jan 2005 21:01:06 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1498

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD8602CCF40929EA28D980445
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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

--------------enigD8602CCF40929EA28D980445
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigD8602CCF40929EA28D980445--

Date: Thu, 27 Jan 2005 17:50:04 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4467

This is a multi-part message in MIME format.
--------------080801050205030601090804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

    Erik

--------------080801050205030601090804
Content-Type: text/plain;
 name="rbridge-charter"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rbridge-charter"

Deliverables

---

--------------080801050205030601090804--

Date: Thu, 27 Jan 2005 17:24:43 -0800
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
To: "Developing a hybrid router/bridge." <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1732

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:

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

Date: Thu, 27 Jan 2005 16:55:33 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 572

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

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

Date: Thu, 27 Jan 2005 16:45:38 -0800
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Cc: 
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3387

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBF9F9523959E56E09C0EB7EC
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greg Daley wrote:
> Hi Joe,
> 
> Joe Touch wrote:
> 
>>
>>
>> Erik Nordmark wrote:
>>
>>> Radia Perlman wrote:
>>>
>> ...
>>
>>>> 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).
>>>
>>>
>>>
>>> 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.
>>
>>
>>
>> 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.
> 
> 
> 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.

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
>    service ND needs to be proxied, only on sublinks which the MN has
>    just moved to or from will this change.

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.

> 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

--------------enigBF9F9523959E56E09C0EB7EC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigBF9F9523959E56E09C0EB7EC--

Date: Fri, 28 Jan 2005 11:30:40 +1100
From: Greg Daley <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
To: "Developing a hybrid router/bridge." <[email-masked]>
Organization: Monash University
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2088

Hi Joe,

Joe Touch wrote:
> 
> 
> Erik Nordmark wrote:
> 
>> Radia Perlman wrote:
>>
> ...
> 
>>> 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).
>>
>>
>> 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.
> 
> 
> 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.

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

Date: Fri, 28 Jan 2005 11:19:17 +1100
From: Greg Daley <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
To: "Developing a hybrid router/bridge." <[email-masked]>
Organization: Monash University
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1170

Hi Donald,

Sorry about the tardy reply,

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

Date: Thu, 27 Jan 2005 15:12:52 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1743

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7BF5F7D401DB1B1F363A4700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Erik Nordmark wrote:
> Radia Perlman wrote:
...
>> 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).
> 
> 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.

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

--------------enig7BF5F7D401DB1B1F363A4700
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7BF5F7D401DB1B1F363A4700--

Date: Thu, 27 Jan 2005 13:47:22 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1448

Radia Perlman wrote:

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

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

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: Eastlake III Donald-LDE008 <[email-masked]>
To: [email-masked]
Subject: RE: [rbridge] RBridges and SEND/CGA
Date: Thu, 27 Jan 2005 00:09:42 -0500
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1650

Ahhh, you are correct. All the secured messages use a nonce or
Timestamp.

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Wednesday, January 26, 2005 6:09 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] RBridges and SEND/CGA

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

Date: Wed, 26 Jan 2005 16:57:16 -0800
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
To: "Developing a hybrid router/bridge." <[email-masked]>
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2486

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:

> 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

Date: Wed, 26 Jan 2005 15:08:55 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1174

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: Eastlake III Donald-LDE008 <[email-masked]>
To: [email-masked]
Date: Wed, 26 Jan 2005 16:59:12 -0500
Subject: [rbridge] RBridges and SEND/CGA
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 569

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