=0A

Guangqing =0ADeng<= /div>=0A

CNNIC

&= nbsp;

From: Henning Rogge

Date: 2014-04= -11 14:41

To: Douglas Otis

CC: dnssd; HOMENET; Don Sturek; Dave Taht

Subject: Re: [dnssd] [ho= menet] IETF-89 WG meeting minutes

On Fri, Apr = 11, 2014 at 1:53 AM, Douglas Otis <doug.mtview@gmail.com> wrote:=0A

> mDNS is not easily deployed at large scale over wireless wi= thout filtering. Wifi has improved by offering mitigation strategies= like multicast queuing per N beacons and multicast specific filters. = ; Even so, these strategies are unlikely needed at home. I make exte= nsive use of mDNS within a dense wireless spectrum containing dozens of ne= arby access points without difficulty while transferring multiple HD+ stre= ams. I would be interested in knowing what problems you are experien= cing within your home.

=0A

Its not only mDNS,= its also ARP, ICMPv6 and other "linklocal

=0A

multicast" protoco= ls that work badly over large Wifi linklayer

=0A

domains. Linkloc= al normally means "fast, cheap, atomic, in-order"...

=0A

if you r= eplace it with a large wireless layer-2 domain, it becomes

=0A

so= mething very different.

=0A

Henning Rogge=0A

=0A

____________________________________________= ___

=0A

dnssd mailing list

=0A

dnssd@ietf.org

=0Ahttps://www.ietf.org/mailman/listinfo/dnssd

=0A

= =0A ------=_001_NextPart402471715224_=------ From nobody Mon Apr 21 07:33:40 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3281A01FB for ; Mon, 21 Apr 2014 07:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku22LXsoAv8Y for ; Mon, 21 Apr 2014 07:33:36 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 91BF51A0215 for ; Mon, 21 Apr 2014 07:33:32 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7E48723E27FE for ; Mon, 21 Apr 2014 14:33:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub4vsW_ZdyjF for ; Mon, 21 Apr 2014 16:33:25 +0200 (CEST) Received: from kopoli (g225116173.adsl.alicedsl.de [92.225.116.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 2C07623E27FC for ; Mon, 21 Apr 2014 16:33:25 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Mon, 21 Apr 2014 16:33:23 +0200 Message-ID: <001c01cf5d6e$a6be0350$f43a09f0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9dbqXLIMkM5gguQ2Kez4ZEbFSpPg== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/QO_l8wl-DJXKCkL-6lb8DgjPHRw Subject: [dnssd] Comments on the current mDNS/DNS-SD drafts X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour $mDNS and DNS-SD$ for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 14:33:38 -0000 Hello, I finally finished writing a threat model for mDNS, I will post the link after my co-author and the 3 other volunteer contributors have a chance to review this document. Since I needed to read all the RFCs and document related to mDNS and DNS-SD, I found a few typos or have a few comments that the authors might find them useful to consider. -------------------------------------------------------- draft-bhandari-dnssd-mdns-gateway-00 section 3.2 : applied repeated twice section 3.8.1 responseas -> responses section 3.8.1 Does wireless devices mean the devices with constraint resources? So, mDNS does not work for a laptop or similar devices without any movement? I am asking this question because a person can use a laptop at work while he is sitting at his desk at his office without the need to move from one place to another but he might use WLAN to connect to the office network. I guess while someone is moving, he would never consider the use of, a printer or most of available resources during his movement, I cannot myself move and type or click on something even on my mobile phone. But he might consider using a WLAN. However, in this scenario, he prefers not to change his service from one WLAN to another. In other words, he'd like to receive continuous service without any disconnection. If this is true, then mDNS really does not work for mobility scenario or is not useful ( I might be wrong but I guess considering mobility is only extra effort without any special benefit). Probably the authors can show otherwise by adding more useful mobility scenario that shows the usefulness of service discovery during mobility. In other words, for the mDNS gateway or devices, it is not really important whether the node is in subnet A or subnet B or moving from subnet A to B. I do not also think that you move a server or printer from one place to another place while other nodes are using their resources... other physical limitation like electricities, etc. avoids such scenario. This is why again, IMHO, considering mobility does not make sense in mDNS. Section 3.8.2 The first sentence is not true. Again the example of laptop in my last paragraph or the example of looking up for a printer while you're moving.. you will never do it. You first find a place to take a sit and then you try to lookup resources on the network. Another comment: Where is the location of mDNS device? How it knows which client is not in this network anymore? Isn't it by actively sending something like keep alive message? If this is true, then this process might lead to large network traffic. If not, then how it knows when the client is leaving? Two dots at the end of sentence after "network" Section 3.8.3 Again a node that provides a service usually doesn't move and it might be a client that moves. -------------------------------------------------- Draft-ietf-dnssd-requirements Section 1.2 terminology Is mDNS a transport layer protocol? I guess the authors mean mDNS is an application layer protocol that uses UDP like DNS as a transport layer. Section 2.3 For low power nodes there should be more requirements since they cannot load a large service discovery lists (memory constraints) and they need to only rely on the two first entry of the list . They cannot also wait for a long time since it consumes a lot of energy. --------------------------------------------------- draft-otis-dnssd-mdns-xlink-02 section 2.5 second paragraph: The solution for automation is only windows-based and not compatible to 90% of DNS servers. Best, Hosnieh From nobody Tue Apr 22 12:44:23 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B371A0259 for ; Tue, 22 Apr 2014 12:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-3SAYv9BlMH for ; Tue, 22 Apr 2014 12:44:16 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B0C4B1A0226 for ; Tue, 22 Apr 2014 12:43:58 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id uo5so5317385pbc.32 for ; Tue, 22 Apr 2014 12:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9XP99nhBxd+VlOljOxCNc75BsM60BbFPZiyKRdRcyys=; b=xNKiOzwMNl2ol3eFkVhsvuJRi6G2GqkMdBTmRuF96Z8T/ca97o4O3GguQMh9gS4Orn DGZyb5KCOtxx1hf+usylEDkVx0ibgNgjYYMaxzpzXhYpfDGVZSpW1HFvs7RdJYUaoDWd MMT2SDv+iI8j2naV3mZj2rhQXEBvw+LOh6j0NThsqw6jEDpj6VVvKy3BF1fQvGe6H0ey lQaMRsHdecl6ahrnfQ+AwM6zWX3mWRSk3mE+KArp1OQoKdcbvpAMdo3vgykxpW9hXCLh 4t75pPZx7aqGAV4Ps5o5wVBQuKpHvn3GVQqGe4llDdxTBQltShxBy1dHhm/omp921S2/ mnUw== X-Received: by 10.68.113.5 with SMTP id iu5mr46411760pbb.60.1398195833347; Tue, 22 Apr 2014 12:43:53 -0700 (PDT) Received: from ?IPv6:2601:9:7680:203:d8c0:cace:fb07:8e82? ([2601:9:7680:203:d8c0:cace:fb07:8e82]) by mx.google.com with ESMTPSA id nx12sm206226886pab.6.2014.04.22.12.43.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 12:43:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 $1874$) From: Douglas Otis In-Reply-To: <001c01cf5d6e$a6be0350$f43a09f0$@rozanak.com> Date: Tue, 22 Apr 2014 12:44:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30AD935A-CB0C-49B4-BA2A-6BF7BDA6FC9F@gmail.com> References: <001c01cf5d6e$a6be0350$f43a09f0$@rozanak.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/I8cI4jHmlYRjc49Qb92l6n3RIDQ Cc: dnssd@ietf.org Subject: Re: [dnssd] Comments on the current mDNS/DNS-SD drafts X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour $mDNS and DNS-SD$ for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 19:44:21 -0000 Dear Hosnieh, Thank you for your feedback. I am about to finish my draft regarding = mDNS as well. While many directly assign keys to systems rather than = utilizing Kerberos, neither Kerberos or LDAP are primarily used by = Windows. The goal of the document was to assist in efforts at moving a = link-local scheme into either a multi-link home or corporate. In these = environments, distributed keys would be fairly risky. Regards, Douglas Otis On Apr 21, 2014, at 7:33 AM, Hosnieh Rafiee wrote: > Hello, >=20 > I finally finished writing a threat model for mDNS, I will post the = link > after my co-author and the 3 other volunteer contributors have a = chance to > review this document.=20 > Since I needed to read all the RFCs and document related to mDNS and = DNS-SD, > I found a few typos or have a few comments that the authors might find = them > useful to consider.=20 >=20 > -------------------------------------------------------- > draft-bhandari-dnssd-mdns-gateway-00 >=20 > section 3.2 : applied repeated twice >=20 > section 3.8.1 responseas -> responses >=20 > section 3.8.1 > Does wireless devices mean the devices with constraint resources? So, = mDNS > does not work for a laptop or similar devices without any movement? I = am > asking this question because a person can use a laptop at work while = he is > sitting at his desk at his office without the need to move from one = place to > another but he might use WLAN to connect to the office network. > I guess while someone is moving, he would never consider the use of, a > printer or most of available resources during his movement, I cannot = myself > move and type or click on something even on my mobile phone. But he = might > consider using a WLAN. However, in this scenario, he prefers not to = change > his service from one WLAN to another. In other words, he'd like to = receive > continuous service without any disconnection. If this is true, then = mDNS > really does not work for mobility scenario or is not useful ( I might = be > wrong but I guess considering mobility is only extra effort without = any > special benefit). Probably the authors can show otherwise by adding = more > useful mobility scenario that shows the usefulness of service = discovery > during mobility. > In other words, for the mDNS gateway or devices, it is not really = important > whether the node is in subnet A or subnet B or moving from subnet A to = B. I > do not also think that you move a server or printer from one place to > another place while other nodes are using their resources... other = physical > limitation like electricities, etc. avoids such scenario. This is why = again, > IMHO, considering mobility does not make sense in mDNS. >=20 >=20 > Section 3.8.2 > The first sentence is not true. Again the example of laptop in my last > paragraph or the example of looking up for a printer while you're = moving.. > you will never do it. You first find a place to take a sit and then = you try > to lookup resources on the network. >=20 > Another comment: > Where is the location of mDNS device? How it knows which client is = not in > this network anymore? Isn't it by actively sending something like keep = alive > message? If this is true, then this process might lead to large = network > traffic. If not, then how it knows when the client is leaving? >=20 > Two dots at the end of sentence after "network" >=20 > Section 3.8.3 > Again a node that provides a service usually doesn't move and it might = be a > client that moves. >=20 > -------------------------------------------------- >=20 > Draft-ietf-dnssd-requirements >=20 > Section 1.2 terminology > Is mDNS a transport layer protocol? I guess the authors mean mDNS is = an > application layer protocol that uses UDP like DNS as a transport = layer. >=20 > Section 2.3 For low power nodes there should be more requirements = since they > cannot load a large service discovery lists (memory constraints) and = they > need to only rely on the two first entry of the list . They cannot = also wait > for a long time since it consumes a lot of energy.=20 > --------------------------------------------------- >=20 > draft-otis-dnssd-mdns-xlink-02 >=20 > section 2.5 >=20 > second paragraph: The solution for automation is only windows-based = and not > compatible to 90% of DNS servers.=20 >=20 >=20 > Best, > Hosnieh >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Tue Apr 22 22:54:41 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6531A0073 for ; Tue, 22 Apr 2014 22:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgjyG7o4HAg5 for ; Tue, 22 Apr 2014 22:54:35 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 81EA51A030C for ; Tue, 22 Apr 2014 22:54:35 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 8B12F23E27FE; Wed, 23 Apr 2014 05:54:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YbavZpCVuHk; Wed, 23 Apr 2014 07:54:27 +0200 (CEST) Received: from kopoli (g225186211.adsl.alicedsl.de [92.225.186.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 60A3823E27FC; Wed, 23 Apr 2014 07:54:27 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Douglas Otis'" References: <001c01cf5d6e$a6be0350$f43a09f0$@rozanak.com> <30AD935A-CB0C-49B4-BA2A-6BF7BDA6FC9F@gmail.com> In-Reply-To: <30AD935A-CB0C-49B4-BA2A-6BF7BDA6FC9F@gmail.com> Date: Wed, 23 Apr 2014 07:54:25 +0200 Message-ID: <000701cf5eb8$7b59f480$720ddd80$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGeT6mIZBexUe6eSSMIYiopkafpxwKQSQdqm2xPG8A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/mk1NudrLchoAYAQjPp0DStAWbyg Cc: dnssd@ietf.org Subject: Re: [dnssd] Comments on the current mDNS/DNS-SD drafts X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour $mDNS and DNS-SD$ for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 05:54:37 -0000 Dear Douglas, > > Thank you for your feedback. I am about to finish my draft regarding mDNS as > well. While many directly assign keys to systems rather than utilizing > Kerberos, neither Kerberos or LDAP are primarily used by Windows. The goal > of the document was to assist in efforts at moving a link-local scheme into > either a multi-link home or corporate. In these environments, distributed > keys would be fairly risky. > Yes, I understand. Thanks for the clarification. Best, Hosnieh From nobody Mon Apr 28 12:03:03 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303D01A7D82; Mon, 28 Apr 2014 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiUW-_RQsZJW; Mon, 28 Apr 2014 12:02:55 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DEFE11A6FB1; Mon, 28 Apr 2014 12:02:54 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id z10so5221185pdj.5 for ; Mon, 28 Apr 2014 12:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mG4OkNkH/pkWZgi9h1bVG9s5XsMoeKt+zvoc5ld1UDo=; b=gTE0gFp+a6olmyYUxHRFLXGkFsxZ0dfqQYZrl1Qm60ozUMFaDAQ2O2oEV6XRVr2LKv dPlYWL9KA8PKxF/Eg+3NYo6f+kiOBVhWpoY+Te5ybk9pTUuyM2atNMzYjtFzGlT26AWg BfO1w5sVpZtDlsyDjkJUs45L0w5FD9An9ktIzEQuLyoTuDN9yisZZsa9DY3OFnzmyjAo kL3a7qpy7CQItOnzUGgkFE8BTcZTfBPiPchldhxvdIDnjZiDUfiwmQLSo/37I3EHZaQl jLrvUo/KSrq/WFL/vDv05b+8eYiJL+sDJIFuxqgXky2vKN0gZ873AXITv4aQbL7RnD5z Vs8A== X-Received: by 10.68.202.230 with SMTP id kl6mr27449542pbc.55.1398711773168; Mon, 28 Apr 2014 12:02:53 -0700 (PDT) Received: from [192.168.2.225] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id cz3sm36679464pbc.9.2014.04.28.12.02.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 12:02:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A" Mime-Version: 1.0 (Mac OS X Mail 7.2 $1874$) From: Douglas Otis In-Reply-To: Date: Mon, 28 Apr 2014 12:02:52 -0700 Message-Id: References: To: Pierre Pfister X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/RwMcpctwjkEcSz537BP0AKWS00Y Cc: "homenet@ietf.org Group" , dnssd@ietf.org Subject: Re: [dnssd] [homenet] Homenet multicast support X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour $mDNS and DNS-SD$ for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:02:59 -0000 --Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 28, 2014, at 6:10 AM, Pierre Pfister = wrote: > Hello group, >=20 > I=92m working on the homenet experimental implementation = http://www.homewrt.org/ and have been thinking on multicast support for = homenet. Encountering a few design issues, comments from the working = group could be helpful. >=20 > This is a short version of my thoughts about the problem. I=92m = thinking about writing a draft about it. But I would like some feedbacks = from the group. >=20 >=20 > 1) Why supporting multicast. >=20 > I think homenet should support: > - Hosts in the home should be able to join a group and receive traffic = from inside the home and from ISPs if they provide traffic for it (and = the scope allows it) > - SSM should be supported. > - It should work with multi-homing. >=20 > Do you think these are reasonable requirements ? >=20 >=20 > 2) Scope considerations. >=20 > A basic home router supports =AB internal =BB and =AB external =BB = interfaces. So for each multicast scope, we should define the default = behavior for each case. Possibly, improved routers may support tunnels = between homes or home administration areas.=20 > One possible default behavior could be: > - Admin-local: Block from external (optionally block from tunnels and = other home sub-areas) (Might be used to create sub-areas in the home = network). > - Site-Local: Block from external (optionally block from tunnels) = (Local to geographically localized area, for connexion between multiple = sites like VPNs between homes, use a bigger scope) > - 6, 7 and 8 (Organization Local): Block from external (Organization = Local being the bigger Home-local scope, in case you own multiple homes = for instance, or distant servers connected through VPNs, etc...) > - 9 to E (global scope): Accept from internal and external links >=20 > I think multicast packets originated inside the home must never leave = the home network. >=20 > Are these definitions reasonable to you ? >=20 >=20 > 3) Using PIM SM. >=20 > I=92ve been looking at PIM as a solution candidate (If you think = another MRP could be used, please tell ! :-) ). I don=92t consider DM as = a possible solution. SM and BIDIR could be used. > SM would work out of the box if there was no issues with multi-homing. = Indeed, border routers have to subscribe to groups on external = interfaces when some host inside the home has interest for the group. So = border routers needs to be aware of the subscriptions inner hosts made. >=20 > So either: > - Only a single ISP sends traffic from the outside for each group. In = which case we can use a group-to-rp mapping where every border router is = a RP for its own group. That is supported by PIM. We would need = configuration (e.g. DHCP, static) from ISPs to create that mapping. > - We want multiple ISPs to be able to send traffic for some group, in = which case a single RP should send subscription control messages to all = border routers in order to control home multicast subscriptions (That = would require modifications to PIM). >=20 > Another issue comes when using SSM. The path (S, G) subscriptions = follow is dictated by routers=92 routing tables. That works well when = the source is inside the routing domain (the home), or when there is a = single border router (and that router is the RP). When there are = multiple border routers, there are multiple default routes. We need do = decide which border router to use, and that must be consistent. We could = use a group-to-rp mapping as well here. Or a single RP could send = control unicast packets to border routers (like previously). I have a = more precise description of that possibility, but I want to keep that = mail =91=92short=92=92. >=20 >=20 > 4) Using PIM BIDIR. >=20 > I personally prefer the BIDIR possibility. With a single RP which = sends subscription control messages to border routers (that would = require protocol specs). (*,G) would flow toward the RP and (S,G) would = flow toward the source when it is inside the home, or toward the RP when = the source is outside the home. By default, this architecture would not = support path optimization when the source is outside the home.=20 > But: > - I imagine future home networks to be organized around high-bandwidth = link(s) (e.g. wired) attached to CPE border routers and less efficient = links (wifi, sensor networks, =85). So in BIDIR, it=92s not a problem = receiving more traffic on the central link, and path optimization would = often not optimize anything. > - In general, it could be useful to have a way for ISPs to say =91I do = own these addresses=92. For instance, RA=92s RIOs could be used. In = which case the routes would be injected in the routing protocol, and = (S,G) messages could flow toward the correct home exit. >=20 > The good news about BIDIR being that it works even when you don=92t = really know how to route (S,G) subscriptions. Which we don=92t in = general when S is outside the home. >=20 > Does anybody know about some IPv6 BIDIR implementation we could = use/patch ? That would be very helpful !! >=20 >=20 > 5) For autoconf > PIM makes use of its own bootstrapping extension. HNCP could be used = as well for the exactly same purpose (election is pretty obvious in = HNCP). An extension would be really easy do define. What do you think ? Dear Pierre, Adding service filters to RBridge (now deployed supporting PPP) seems to = represent an alternative having security advantages since it does not = depend on layer 3. Using routable IP addresses means publishing is not = without significant risk. An update to mdns-xlink offers an alternative Security Consideration = section from that of draft-ietf-dnssd-requirements. http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03 As an experiment, a test was made using a new popular brand of an IPv6 = enabled printer. Discovery by name resolution and not by address = probing for the printer allowed Internet access without any logs = created. This is a problem not easily resolved using routable IP = addresses. Regards, Douglas Otis --Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Apr 28, 2014, at 6:10 AM, Pierre = Pfister <pierre.pfister@darou.fr> = wrote:

Hello group,

I=92m working on the = homenet experimental implementation http://www.homewrt.org/ and have = been thinking on multicast support for homenet. Encountering a few = design issues, comments from the working group could be = helpful.

This is a short version of my thoughts about = the problem. I=92m thinking about writing a draft about it. But I would = like some feedbacks from the group.

1) Why supporting multicast.

I = think homenet should support:
- = Hosts in the home should be able to join a group and receive traffic = from inside the home and from ISPs if they provide traffic for it (and = the scope allows it)
- SSM should = be supported.
- It should work with = multi-homing.

Do you think these are reasonable = requirements ?

2) = Scope considerations.

A basic home router = supports =AB internal =BB and =AB external =BB = interfaces. So for each multicast scope, we should define the default = behavior for each case. Possibly, improved routers may support = tunnels between homes or home administration areas.
One possible default behavior could = be:
- Admin-local: Block from = external (optionally block from tunnels and other home sub-areas) (Might = be used to create sub-areas in the home network).
- Site-Local: Block from external (optionally = block from tunnels) (Local to geographically localized area, for = connexion between multiple sites like VPNs between homes, use a bigger = scope)
- 6, 7 and 8 (Organization = Local): Block from external (Organization Local being the bigger = Home-local scope, in case you own multiple homes for instance, or = distant servers connected through VPNs, etc...)
- 9 to E (global scope): Accept from internal = and external links

I think multicast packets originated inside = the home must never leave the home network.

Are these definitions = reasonable to you ?

3) = Using PIM SM.

I=92ve been looking at PIM as a solution = candidate (If you think another MRP could be used, please tell ! :-) ). = I don=92t consider DM as a possible solution. SM and BIDIR could be = used.
SM would work out of the box = if there was no issues with multi-homing. Indeed, border routers have to = subscribe to groups on external interfaces when some host inside the = home has interest for the group. So border routers needs to be aware of = the subscriptions inner hosts made.

So either:
- Only a single ISP sends traffic from the = outside for each group. In which case we can use a group-to-rp mapping = where every border router is a RP for its own group. That is supported = by PIM. We would need configuration (e.g. DHCP, static) from ISPs to = create that mapping.
- We want = multiple ISPs to be able to send traffic for some group, in which case a = single RP should send subscription control messages to all border = routers in order to control home multicast subscriptions (That would = require modifications to PIM).

Another issue comes = when using SSM. The path (S, G) subscriptions follow is dictated by = routers=92 routing tables. That works well when the source is inside the = routing domain (the home), or when there is a single border router (and = that router is the RP). When there are multiple border routers, there = are multiple default routes. We need do decide which border router to = use, and that must be consistent. We could use a group-to-rp mapping as = well here. Or a single RP could send control unicast packets to border = routers (like previously). I have a more precise description of that = possibility, but I want to keep that mail =91=92short=92=92.

4) Using PIM = BIDIR.

I personally prefer the BIDIR possibility. = With a single RP which sends subscription control messages to border = routers (that would require protocol specs). (*,G) would flow toward the = RP and (S,G) would flow toward the source when it is inside the home, or = toward the RP when the source is outside the home. By default, this = architecture would not support path optimization when the source is = outside the home.
But:
- I imagine future home = networks to be organized around high-bandwidth link(s) (e.g. wired) = attached to CPE border routers and less efficient links (wifi, sensor = networks, =85). So in BIDIR, it=92s not a problem receiving more traffic = on the central link, and path optimization would often not optimize = anything.
- In general, it could be = useful to have a way for ISPs to say =91I do own these addresses=92. For = instance, RA=92s RIOs could be used. In which case the routes would be = injected in the routing protocol, and (S,G) messages could flow toward = the correct home exit.

The good news about = BIDIR being that it works even when you don=92t really know how to route = (S,G) subscriptions. Which we don=92t in general when S is outside the = home.

Does anybody know about some IPv6 BIDIR = implementation we could use/patch ? That would be very helpful = !!

5) For = autoconf
PIM makes use of its own = bootstrapping extension. HNCP could be used as well for the exactly same = purpose (election is pretty obvious in HNCP). An extension would be = really easy do define. What do you think = ?

Dear = Pierre,

Adding service filters to RBridge (now = deployed supporting PPP) seems to represent an alternative having = security advantages since it does not depend on layer 3. Using = routable IP addresses means publishing is not without significant = risk.

An update to mdns-xlink offers an = alternative Security Consideration section from that = of draft-ietf-dnssd-requirements.

http://= tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03

As an experiment, a test was made using a new popular brand of an = IPv6 enabled printer. Discovery by name resolution and not by = address probing for the printer allowed Internet access without any logs = created. This is a problem not easily resolved using routable IP = addresses.

Regards,

Douglas = Otis

= --Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A--