[pim] Comments on draft-ietf-pim-ipv6-zeroconf-assignment-06

Stig Venaas <[email protected]>
Newsgroups gmane.ietf.pim
Message-ID <CAHANBtK45XezmSLDXqJy8hHeKkswKL=ue4Yk8iD2ajE+caooJg@mail.gmail.com>
Hi

I believe this draft is mostly ready for WGLC. If anyone else has
thoughts on this, please chime in.

I have a few review comments.

The draft uses ff32:00ff:a12:34ff:fe56:7890:9abc:def0 as an example.
But I don't think should set the bit for unicast-prefix based address
here. It's better to set the flags to just 1, using ff12.

In section 2:

   Because this protocol is focused specifically on allocating IPv6
   multicast addresses, mDNS records MUST be published using IPv6, but
   MAY also be published using IPv4.

What exactly does this mean? That MUST use IPv6 transport? Maybe this
can be clarified.

In section 2:

   The host may optionally monitor the bus for traffic that uses the
   same destination multicast Ethernet address, but a different
   destination multicast IPv6 address.  If this is detected, then the
   application responds the same as a collision.

It's unclear to me what "bus" means here. Should applications somehow
detect other packets for the same group? Internally in the host and/or
on the wire? This may be difficult unless the same port number is used
or application is able to use raw sockets.

In section 2:

   While intended primarily for allocating IPv6 multicast addresses on
   the same subnet (link-local scope), the same technique could also
   apply to a larger network as long as mDNS traffic is routed between
   subnets (for any scope excluding global scope).

In order to avoid collisions where applications use different scope,
and also to avoid registering multiple records if using multiple
scopes, should the application always register in mDNS using scope 2,
even if it uses the same with higher scope addresses? Or do we want
the application to register for all scopes?

In section 3:

   It is a greater concern on networks where multicast streams may be
   established at any time.  Deployments on these networks may consider
   engaging a detection mechanism and prompting hosts to send
   unsolicited mDNS response messages when the partition is repaired.

Should GAAP be recommended for such applications?

In  section 5 Security Considerations

Although not an efficient attack, I guess malicious applications could
also register a bunch of addresses in mDNS.

Regards,
Stig

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.