Subject: [Roll] Dissenting technical arguments unwelcome (was: Re: trickle-mcast-04 - Clarify scope value of 3 - subnet-local)

From: Ulrich Herberg <[email-masked]>
Date: Thu, 25 Jul 2013 10:52:22 -0700

Hi,

Several people in the ROLL WG, amongst others Rob Caigie and Don
Sturek, were interested in the topic of multi-link subnets and the
related multicast scope for MPL / for IPv6 in general [1].

This is an important technical topic and deserves due discussion on
this mailing list and 6man.

I think that both discussions (multi-link subnet and IPv6 multicast
scope 0x03) are closely related; because using "subnet" for a scope
that is meant to be network-wide would imply using (even mandating)
multi-link subnets, which I think is a bad idea. So in order to
explain why I think that the "subnet" scope is a bad idea, I needed to
explain why multi-link subnets are a bad idea.

I am, however, for the time being prohibited from continued
participation on this technical matter. The ROLL WG chairs sent me a
formal warning saying that:

 o my "comments about multi-hop subnets are not welcome on the ROLL list"

 o I should "refrain repeating them yet again, it is disruptive to the
conversation, and confuses many people."

 o this was a formal warning "as per RFC2418/BCP25, and taking
RFC3683/BPC83 and RFC3934/BCP94 into account, (particularly BCP93
section 1, paragraph 3) and BCP94 section 2, paragraph 2."

I am very sad to see that technical arguments are ejected from the
discussion by the ROLL Working Group Chairs if these comments are not
in line with their personal objectives.

I have sent an appeal to the IESG regarding this formal warning,
according to RFC2026, Section 6.5., "Process Failures", as I believe
that an open exchange of technical arguments is key to the work in any
IETF working group - and that issuing formal warnings simply to
suppress dissenting technical arguments is not beneficial to the IETF,
its participants, and its protocol designs.

[1] http://www.ietf.org/mail-archive/web/roll/current/msg07951.html

Best regards
Ulrich

On Wed, Jul 24, 2013 at 8:32 AM, Ulrich Herberg <[email-masked]> wrote:
> I have pointed out two documents in my earlier email that explain in
> long detail why I believe that multi-hop subnets are a really bad
> idea. The AUTOCONF RFC 5889 presents an architecture for avoiding all
> these problems by using /128 prefixes. In that regards, a subnet wide
> flooding would be fairly uninteresting, as it would not go beyond a
> single router.
>
> Regards
> Ulrich
>
> On Wed, Jul 24, 2013 at 7:58 AM, Michael Richardson
> <[email-masked]> wrote:
>>
>> I would still like an explanation of why "subnet" is the wrong term.
>>
>> When would scope-3 would be used such that it would not correspond to the set
>> of links on which a "/64" (or other size) is used?
>>
>> --
>> Michael Richardson <[email-masked]>, Sandelman Software Works
>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
>>

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 11:03:44 -0700

Hi Ulrich,

Let me say as an implementer of ROLL RPL (and Trickle Multicast) the topic
of multi-link subnets and the general topic of multicast address scope
continues to be a major concern.  For example, we needed to extend mDNS to
cover site specific addressing for this reason as well as need to define
another draft describing ULA prefix delegation rules and forwarding rules
for border routers (yet to be done).

While our current profile (ZigBee IP)  will continue to use multi-link
subnets, it would be fantastic to have a discussion on how multi-link
subnets might be avoided in the future (if that is even possible).  I have
to say after your last reference to the AUTOCONF RFC, I still have doubts
a /128 prefix solves the problems we are having (though interested in
seeing if I am wrong.....)

I for one am in favor of having a *technical* discussion on the topic on
the ROLL reflector.  I also think this topic applies to MANET as well.

 I did not see any discussion on this thread that was not focused on a
relevant technical topic.  Hopefully, the WG chairs/vice-chairs will
reconsider.

Don

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2013 15:40:15 -0400

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.

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 13:09:05 -0700

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-masked]> wrote:

>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 13:35:12 -0700

Hi Tim,

Don Sturek, chair for the ZigBee Alliance Core Stack Group which developed
ZigBee IP in support of Smart Energy Profile 2.0.

Here is a synopsis of the requirements:
1)  Support Resource Discovery over a topology that includes Wi-Fi,
HomePlug AV and GP and ZigBee IP (ZigBee IP is a multi-hop solution using
ROLL RPL) connected via border routers
2)  No device vendor wanted responsibility for a centralized DNS or uPNP
repository that would be guaranteed to exist in all deployment scenarios.
 Ideally then services (resources) are self describing and locate-able
through client directed queries (DNS-SD was a great solution for this)
3)  mDNS was a great choice then for discovery, however, due to the use of
ROLL RPL (or really any multi-hop route over solution), the use of link
locals would not guarantee discovery of all services (resources).  Hence,
the extension of mDNS with this now outdated draft (captured in the
requirements Kerry created for mdnsext I believe):
http://tools.ietf.org/html/draft-lynn-dnsext-site-mdns-01

The DNS-SD draft (RFC 6763) was used in our application without change.
We would have welcomed the use of mDNS (RFC 6762) but that would not work
with ULAs (which we had to use due to the multi-hop subnet)

Again, in some settings there could be a box doing DNS (as long as that
platform was good with other vendor solutions posting DNS records into
it!).   In some settings (where say the electricity meter is the only
common platform), most utilities don't want responsibility (or the risk)
in having untrusted devices posting anything to them.   I like the ideas
in Homenet around gathering service information into centralized DNS
repositories where such a service exists.

By the way, if ULA's continue to be the addressing mechanism, then there
are a couple of additional issues:
1)  In a border router, clear rules on the propagation of ULA prefixes
(eg, which interfaces, ideally those that face inward in the site topology
and not to the ISP!)
2)  What to do if a border router discovers the existance of other ULA
prefixes
I think these topics were detailed in this old draft presented in V6OPS
sometime ago:  
http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00

Don

On 7/25/13 1:11 PM, "Tim Chown" <[email-masked]> wrote:

>On 25 Jul 2013, at 19:03, Don Sturek <[email-masked]> wrote:
>
>> Hi Ulrich,
>> 
>It would be great to get requirements for this - hopefully this can be
>raised in the dnssdext BoF next week, and contributed into the
>draft-lynn-mdnsext-requirements-02 work by Kerry and Stuart. Currently
>the dnssdext charter includes this use case.
>
>Tim

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2013 23:33:13 +0200

> issue I have is that it precludes the use of mDNS (which operate off of

It would be easy to run mDNS in a larger multicast scope than link-local.
(I'm ignoring scaling limitations here, which are not that relevant in a home as long as you have enough power for everyone.  If you don't, mDNS wasn't the right answer in the first place.)

But first, you would need to run a multicast routing protocol.
That appears to be the larger problem with running mDNS in a multi-subnet network domain.

I happen to believe that running a DNS-SD style service discovery protocol across subnets is significantly easier than running multicast routing across subnets and then running mDNS on that multicast routing.

I'm not sure the RFC 5889 model is creating any problem here that we didn't already have as soon as we started to do routing.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2013 17:36:13 -0400

> Note I changed the title on the thread......

Thank you.
I would like to know what a multi-link subnet via /128 means.

    > issue I have is that it precludes the use of mDNS (which operate off of

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.

    > having all devices using globals

Yes to ULAs or to NCN's GUAs... but I understand the question.

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

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

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

---

From: Tim Chown <[email-masked]>
Date: Thu, 25 Jul 2013 21:11:45 +0100

Hi,

It would be great to get requirements for this - hopefully this can be raised in the dnssdext BoF next week, and contributed into the draft-lynn-mdnsext-requirements-02 work by Kerry and Stuart. Currently the dnssdext charter includes this use case.

Tim

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 15:01:24 -0700

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

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 15:05:18 -0700

Hi Carsten,

Actually, we have done quite a bit of testing using site scoped multicast
and the Extended version of mDNS and it seems to work quite well (mainly
since we changed little in mDNS and only addressed the issues of using a
multicast scope other than link local)

Don

On 7/25/13 2:33 PM, "Carsten Bormann" <[email-masked]> wrote:

>(I'm ignoring scaling limitations here, which are not that relevant in a
>home as long as you have enough power for everyone.  If you don't, mDNS
>wasn't the right answer in the first place.)
>
>I happen to believe that running a DNS-SD style service discovery
>protocol across subnets is significantly easier than running multicast
>routing across subnets and then running mDNS on that multicast routing.
>
>I'm not sure the RFC 5889 model is creating any problem here that we
>didn't already have as soon as we started to do routing.
>
>Grüße, Carsten
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2013 18:07:38 -0400

> local operation.   Here are a few (from RFC 6762):

Ah, I understand now, and I agree.
I thought you were saying that mDNS replies could not have ULAs in their
answer sections.

I agree that all of the things you mention have to be adjusted in order to
permit mDNS to work over MPL.

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 15:50:53 -0700

Hi Michael,

I mispoke on the last point.  Should have read:    multi-link subnets
versus allocating a /128

Don

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 26 Jul 2013 10:50:25 +0200

Hi Michael,

actually, MANET protocols have been working for years to provide mesh-over
routing, without multi-link subnets.

To understand better the "link" properties you have to deal with, you could
take a look at this draft
http://tools.ietf.org/html/draft-baccelli-manet-multihop-communication-02

As Ulrich mentioned, the conclusion of AUTOCONF was that IP links as we
know them do *not* make sense in a spontaneous wireless multi-hop
environment.

This conclusion was documented in RFC 5889, which essentially bans the use
of subnet prefixes in this environment. And without subnet prefixes, what
is the purpose of an IP link? Not much...

Best,

Emmanuel

---

From: Don Sturek <[email-masked]>
Date: Fri, 26 Jul 2013 10:25:15 -0700

Hi Emmanuel,

I think if route over protocols are to adhere to RFC 5889, much more work
needs to go into making ULAs useful.

For our project we used:    6LoWPAN (RFC 4944), 6LoWPAN-ND (RFC 6775), ROLL
RPL (RFC 650), mDNS (RFC 6762) with some extensions to use ULAs (among
others) and I can say that simply not using link locals with RFC 5889 would
not yield a robust IoT solution (at least this is my opinion having worked
on this for 4 years now)

Don

From:  Emmanuel Baccelli <[email-masked]>
Date:  Friday, July 26, 2013 1:50 AM
To:  Routing Over Low power and Lossy networks <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Roll] Dissenting technical arguments unwelcome

Hi Michael,

As Ulrich mentioned, the conclusion of AUTOCONF was that IP links as we know
them do *not* make sense in a spontaneous wireless multi-hop environment.

This conclusion was documented in RFC 5889, which essentially bans the use
of subnet prefixes in this environment. And without subnet prefixes, what is
the purpose of an IP link? Not much...

Best,

Emmanuel

On Thu, Jul 25, 2013 at 9:40 PM, Michael Richardson <[email-masked]>
wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]> >,
> Sandelman Software Works
> 
> 
> 

-------------------------------------------------------------------- IETF
IPv6 working group mailing list [email-masked] Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 26 Jul 2013 13:55:02 +0000

From: Emmanuel Baccelli [[email-masked]]
Sent: Friday, July 26, 2013 4:50 AM

> As Ulrich mentioned, the conclusion of AUTOCONF was that IP links as
> we know them do *not* make sense in a spontaneous wireless multi-hop
> environment.
> 
> This conclusion was documented in RFC 5889, which essentially bans
> the use of subnet prefixes in this environment. And without subnet
> prefixes, what is the purpose of an IP link? Not much...

Hi Emmanuel,

While I generally agree with what RFC 5889 says, its focus is on
autoconfiguration.  For example, the statement

   o  There is no mechanism to ensure that IPv6 link-local addresses
      are unique across multiple links, hence they can not be used to
      reliably identify routers.

is true only if restricted to autoconfiguration mechanisms.

To the extent that RFC 5889, which is informational, bans anything,
it bans using autoconfiguration to configure addresses with subnet
prefixes in this sort of network.  It says nothing one way or the
other about using, say, DHCPv6 or 6LoWPAN ND to do so.

The whole multi-link subnet discussion is difficult because the term
'subnet' has different implications in different contexts.  For
example, RFC 5889 says:

   Subnet prefix configuration on such interfaces must thus not make any
   promises in terms of direct (one hop) IP connectivity to IP addresses
   other than that of the interface itself.  This suggests the following
   principle:

   o  no two such interfaces in the network should be configured with
      the same subnet prefix.

An equally valid principle would have been:

   o  subnet prefixes should not be used for on-link determination
      for such interfaces.

Which you prefer depends on how much you consider on-link determination
to be a fundamental aspect of subnet prefixes.  For autoconfiguration
it is a fundamental aspect; for routing, perhaps not.

I think it makes sense to follow RFC 5889's recommendation and assign
only /128 subnet prefixes to interfaces in an ad-hoc radio network.  I
also think it makes sense to arrange for those subnet prefixes to share
a single /64 prefix and to use that fact at the routing layer.  Whether
or not this is a multi-link subnet depends on who you ask.

-Richard Kelsey

This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product.  If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and  destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.  
Thank you.