Note I changed the title on the thread...... 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).
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 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) 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....) 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. Don On 7/25/13 12:40 PM, "Michael Richardson" <[email protected]> wrote: > > >Ulrich, thank for starting a new thread on this topic as I asked. > >I am looking forward to understanding how we can do mesh-over networking >without creating multi-link subnets. > >It might just be that we need to always auto-configure /128 addresses on >the >interfaces, and use /128 routes everywhere. >That's what my code does in order to implement multi-link subnets. > >-- >Michael Richardson <[email protected]>, Sandelman Software Works > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >[email protected] >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
