Re: [Roll] Multi-Link Subnets via /128

[Don Sturek <[e-mail]>]

Hi Michael,

We did a good bit of work on the mDNS topic and there are quite a few
subtleties in the mDNS draft that are really focused only on correct link
local operation.   Here are a few (from RFC 6762):
1)  Section 3.1
Any DNS query for a name ending with ".local." MUST be sent to the
   mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
   equivalent FF02::FB)

2)  Section 4
Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
      be sent to the mDNS IPv4 link-local multicast address 224.0.0.251
      or the mDNS IPv6 multicast address FF02::FB.
3)  Section 11
All Multicast DNS responses (including responses sent via unicast)
   SHOULD be sent with IP TTL set to 255.  This is recommended to
   provide backwards-compatibility with older Multicast DNS queriers
   (implementing a draft version of this document, posted in February
   2004) that check the IP TTL on reception to determine whether the
   packet originated on the local link.  These older queriers discard
all packets with TTLs other than 255.
4)  Also Section 11
 A host sending Multicast DNS queries to a link-local destination
   address (including the 224.0.0.251 and FF02::FB link-local multicast
   addresses) MUST only accept responses to that query that originate
from the local link, and silently discard any other response packets.
5)  Again in Section 11
The test for whether a response originated on the local link is done
   in two ways:

      * All responses received with a destination address in the IP
        header that is the mDNS IPv4 link-local multicast address
        224.0.0.251 or the mDNS IPv6 link-local multicast address
        FF02::FB are necessarily deemed to have originated on the local
        link, regardless of source IP address.  This is essential to
        allow devices to work correctly and reliably in unusual
        configurations, such as multiple logical IP subnets overlayed on
        a single link, or in cases of severe misconfiguration, where
        devices are physically connected to the same link, but are
        currently misconfigured with completely unrelated IP addresses
        and subnet masks.

      * For responses received with a unicast destination address in the
        IP header, the source IP address in the packet is checked to see
        if it is an address on a local subnet.  An IPv4 source address
        is determined to be on a local subnet if, for (one of) the
        address(es) configured on the interface receiving the packet, (I
        & M) == (P & M), where I and M are the interface address and
        subnet mask respectively, P is the source IP address from the
        packet, '&' represents the bitwise logical 'and' operation, and
        '==' represents a bitwise equality test.  An IPv6 source address
        is determined to be on the local link if, for any of the on-link
        IPv6 prefixes on the interface receiving the packet (learned via
        IPv6 router advertisements or otherwise configured on the host),
        the first 'n' bits of the IPv6 source address match the first
        'n' bits of the prefix address, where 'n' is the length of the
prefix being considered.


Don


On 7/25/13 2:36 PM, "Michael Richardson" <[e-mail]> wrote:

>
>
>Don Sturek <[e-mail]> wrote:
>
>    > Note I changed the title on the thread......
>
>Thank you.
>I would like to know what a multi-link subnet via /128 means.
>
>    > My problem with RFC 5889 (http://tools.ietf.org/html/rfc5889) is
>that it
>    > solves the problem simply by saying "don't allocate link locals".
>The
>    > issue I have is that it precludes the use of mDNS (which operate
>off of
>    > link locals).
>
>1) mDNS doesn't have to use link locals, it can, and does distribute ULAs
>and
>   GUAs v6 addresses just fine.
>
>2) sdnsext might well fix mDNS to run across multiple subnets, not just
>   a multi-link subnet.
>
>    > Some questions:
>    > 1)  Would you recommend then the allocation of ULA's with a /128 (as
>    > opposed to globals).  There are a lot of applications that really
>only
>    > need to communicate within a residence and don't really have a need
>in
>    > having all devices using globals
>
>Yes to ULAs or to NCN's GUAs... but I understand the question.
>
>    > 2)  If we use ULA's, there does not seem to be guidance around which
>    > interfaces to perform prefix delegation on and which should not
>    > (specifically, I am thinking of rules that a border router would
>use as to
>    > where to issue PIOs in a RPL sense)
>
>My reading/understanding/coding is that a border router which thinks it is
>grounded (G=1) should issue PIOs.
>
>    > 3)  And of course if there ended up being more than one border
>router,
>    > there is also not guidance on how to combine or proxy ULA prefixes
>(maybe
>    > this topic could be a Homenet solution....)
>
>homenet might provide a solution outside of the RPL space for deciding who
>will be the root ULA provider and how that might get distributed, but that
>won't help many RPL/LLN deployments.
>
>    > In case anyone is wondering, our initial application deployment
>using
>    > ZigBee IP was Smart Energy Profile 2.0 (SEP 2.0).   There was a
>    > requirement to perform service discovery without a centralized
>repository
>    > (since it was a multivendor deployment where no device manufacturer
>wanted
>    > responsibility for a centralized DNS).  mDNS (extended to use ULAs)
>was
>    > our choice.  It would seem with a /128, we would still need the same
>    > extensions to mDNS.   We plan to support Wi-Fi, HomePlug Power Line
>    > Carrier and ZigBee IP in a combined network topology within the
>home.
>
>I assume you used trickle-mcast to propogate the mDNS.
>Across those three links types, did you have a single ULA/64?
>How did the gateways between the media types know that they were not at a
>scope-3 boundary?
>
>--
>Michael Richardson <[e-mail]>, Sandelman Software Works
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[e-mail]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------