Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt

From: Joshua Graessley <[email-masked]>
Date: Tue, 3 Sep 2002 17:09:11 -0700

On Tuesday, September 3, 2002, at 04:57  PM, Daniel Senie wrote:

> At 07:46 PM 9/3/2002, you wrote:
>> I'm not sure I understand how the scope of the two could differ. Both 
>> are defined as link-local scope. In the case of ethernet, an ethernet 
>> broadcast and an ethernet multicast should be just as effective in 
>> reaching all nodes, right? I think that any equipment that handles 
>> the two differently would break many applications. Is there another 
>> media where the definition of link-local changes if an address is 
>> multicast?
>
> Ethernet controllers treat Multicast and Broadcast differently. In a 
> simple environment with hubs, the multicast packets get to each 
> station, but STILL are handled differently. Broadcast packets are 
> received by the Ethernet driver. Multicast packets are discarded 
> before being handed to the driver, unless the driver has asked for the 
> multicast group the packet is in.
>
> In the event of better Ethernet switches, they will monitor which 
> Multicast groups a particular port needs, and only send those to that 
> port (read up on IGMP snooping).

Still, this should not limit the effective scope of an IPv4LL multicast 
versus an IPv4LL unicast, right? The broadcast address used for ARP 
should get to all of the nodes on the "local link", allowing an IPv4LL 
address to be used for communication with any other node on that link. 
In the case of DNS sent to a link-local address, the multicast packet 
should only be received by other devices on that local link. With the 
exception of some switches that may try to be smart and filter out 
multicast traffic, the broadcast and multicast traffic will be seen by 
the same devices. In the case where there is "smart" hardware filtering 
multicast, the nodes to receive the multicast would be a subset of the 
nodes that would receive the broadcast.

On Tuesday, September 3, 2002, at 01:52  PM, Keith Moore wrote:

> concrete example: if the scope of LL v4 addresses and LL v4 multicast
> are not the same (and they could easily differ) then an mDNS/LLMNR 
> lookup
> can easily return an address that isn't usable by the client.   of 
> course
> if you put such addresses in DNS then you have even more problems.

If the nodes receiving the multicast are a subset of the nodes 
receiving broadcasts, wouldn't it be impossible for an mDNS/LLMNR reply 
to make it to a node where the IPv4LL address would be inaccessible? I 
suppose you could have nodes that knew about mDNS/LLMNR that did not 
know about IPv4LL addresses and therefore did not have a route to those 
addresses.

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Sep 2002 20:59:34 -0400

> to make it to a node where the IPv4LL address would be inaccessible?

I'm not sure that the LL multicast hosts are necessarily a strict subset of
the hosts capable of receiving broadcasts, because of the various kinds of
L2 switching and bridging technologies out there that treat broadcast and
multicast differently.  It seems like a dubious assumption.

just as one example, is CGMP aware of broadcast boundaries?

note for that for the purposes of the requirements document it isn't
necessary to actually answer the question - just to determine whether
there's a requirement  that the scope of name lookup results be 
(able to be) bounded by the local link (in unicast LL terms) scope.  

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Sep 2002 09:04:57 -0400

> just as one example, is CGMP aware of broadcast boundaries?

	CGMP is an interesting practical case, but is irrelevant to the IETF
and this conversation, since it is cisco's proprietary protocol.  CGMP 
was
designed to compensate for the absence of IGMP support in cisco's 
Ethernet
switches.  In effect, networks that require CGMP are broken with respect
to the IP Multicast specifications.

Most modern Ethernet switches are IGMP-aware and don't need or use CGMP.

Ran
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Sep 2002 10:41:36 -0400

> and this conversation, since it is cisco's proprietary protocol. 

I disagree that it's irrelevant - if an assumption held by this group 
(or one that is implicit in the zeroconf architecture) doesn't hold
true in practice, that can affect the reliability and deployability
of the zeroconf technologies.  

Which is not to say that every kind of vendor-brokenness should be accomodated,
or that any specific vendor's brokenness should be accomodated.

I cite this only as one concrete real-world example of why it may be unrealistic
to expect that LL multicast is supported even on media that are supposed to
support it, and why it may be unrealistic to expect that LL multicast and LL 
unicast have the same scope.  Given the inherent nature of L2 switches and L2 
bridges between dissimilar media, it would not surprise me if there are other 
examples - though I don't know of any offhand.

The real point here is to raise the questions

- given that LL addresses are inherently of limited scope, is there an expectation 
  that the zeroconf name lookup protocol needs to be able to limit its answers 
  to include only addresses which are usable by the host making the query?

- if so, is there an expectation that using LL multicast to do such queries 
  provides an effective mechanism for limiting the results in this way?

- and in particular, is there an expectation that LL multicast and LL unicast
  have the same scope?

if so, it seems like such expectations should be stated explicitly.

and if none of these are the case, then it begs the question - given that LL
unicast addresses are ambiguous and only usable within a limited scope,
how do hosts that obtain such addresses from other hosts (whether by LLMNR
or other means) know whether such LL addresses should be valid for them? 

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Sep 2002 11:40:27 -0400

> examples - though I don't know of any offhand.

Keith,

Several different IETF and IEEE standards require Ethernet switches to 
properly
accomodate IP multicasting.  Deployments of broken equipment don't 
justify
any changes to IETF or IEEE standards or requirements.  And in my 
experience
most Ethernet switches handle IP multicasting properly.  The broken 
implementations
are limited to one particular vendor (not Extreme) to the best of my 
knowledge

(If you continue to take the position quoted above, I'll also ask you to
quit complaining about NAT since it is widely deployed and breaks 
various
other things.   By the logic above, NAT-tolerance should be an IETF 
design
requirement -- something which you often argue vocally against.  :-)

Ran
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Sep 2002 11:47:35 -0400

Ran,

read my messages again.

this discussion is about trying to get the zeroconf requirements and 
assumptions made explicit.

Keith

> properly accomodate IP multicasting.  Deployments of broken equipment 
> don't justify any changes to IETF or IEEE standards or requirements.  
> And in my experience most Ethernet switches handle IP multicasting 
> properly.  The broken implementations are limited to one particular 
> vendor (not Extreme) to the best of my knowledge
>