From alejandroacostaalamo@gmail.com Sun Nov 4 07:06:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5908F21F86EB for ; Sun, 4 Nov 2012 07:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Hq1I5C6dg5 for ; Sun, 4 Nov 2012 07:06:15 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C028521F86D0 for ; Sun, 4 Nov 2012 07:06:15 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5727339vbb.31 for ; Sun, 04 Nov 2012 07:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rbNWbO/tbY6J4IWz9tYakC71tGDfOnYkzyuqGD2dZf0=; b=POV2iZtVtTHQnyMfllEKxrQ4DW2crVUEWNEqFoEUeNav5qAcsjiWiZjyrJxF94RTj8 o5S/zLkQ6WbkjmL0y/57S3DIuUz+RI9rybxCstb6NujKtGNchNI6bDHM1pRu3VQxQusY gjrk39qpCrpoLAbzcevr8q24oaitevfNgE1XtovaNQOhwxrF4kASyi8z4PqXF/ahsy46 ns6I2YJFD/YIlZaX7FFYFm4mjdT59Ry5E3t1dmy+ZwXfAsc0g0Fs2DvCYfynhCoWVI0e SAbNccwbQzKCHZbGX8XObqF7TQTZAaZVkH/C1AT4jd1WRphGn+K+xk5WU/R4E4xZ8WsX o3QA== MIME-Version: 1.0 Received: by 10.52.68.7 with SMTP id r7mr6172411vdt.96.1352041575262; Sun, 04 Nov 2012 07:06:15 -0800 (PST) Received: by 10.58.56.100 with HTTP; Sun, 4 Nov 2012 07:06:15 -0800 (PST) In-Reply-To: <1F8F6EE7-BD99-4E30-84A0-D1EAB9470F8A@nominet.org.uk> References: <1F8F6EE7-BD99-4E30-84A0-D1EAB9470F8A@nominet.org.uk> Date: Sun, 4 Nov 2012 11:06:15 -0400 Message-ID: From: Alejandro Acosta To: Ray Bellis Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] IETF85 session agenda X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:06:16 -0000 Hi All, Sorry if there is something I'm missing. Regarding the agenda at: https://datatracker.ietf.org/meeting/85/agenda/homenet/ There is a draft from E. Kline called: draft-kline-default-perimeter-01. I've been only able to find the first version (00). Am I right? Thanks, On 10/29/12, Ray Bellis wrote: > The IETF85 draft session agenda for Homenet is now online at: > > > > and shown below: > > --8<--8<-- > > Homenet Working Group > 7th November 2012 > > 09:00 - 09:10 Note Well, Jabber Relay, Note taker(s) > > 09:10 - 09:25 Homenet Architecture Update > > draft-chown-homenet-arch-06 (Tim Chown - 15m) > > 09:25 - 09:45 Naming and Service Discovery > > update from MDNSEXT BoF (TBC) > > 09:45 - 10:40 Routing and Prefix Assignment > > draft-arkko-homenet-prefix-assignment-03 (Jari Arkko - 15m) > draft-haddad-homenet-multihomed (Damien Saucez - 15m) > wider discussion on source + dest based routing (Jari / Lorenzo - 25m) > > 10:40 - 11:25 Security > > draft-kline-default-perimeter-01 (Erik Kline - 15m) > draft-boot-homenet-brdp-00 (Teco Boot - 15m) > draft-behringer-homenet-trust-bootstrap-00 (Michael Behringer - 15m) > > 11:25 Wrap-up > > 11:30 Close > > --8<--8<-- > > See you then! > > Ray > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From Ray.Bellis@nominet.org.uk Sun Nov 4 07:10:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FE121F8739 for ; Sun, 4 Nov 2012 07:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzXCDmnq-fb0 for ; Sun, 4 Nov 2012 07:10:29 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 449F621F8653 for ; Sun, 4 Nov 2012 07:10:29 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=CVHNHJvWA6H127wyoU+SGQQa7/6QRLgznNYDlXA2XNDvSjzQ64OQd0BR cpDCmeWDVV2BaoFfs0BSZ31Ot+mltRAhr8KQdZQHoIwbGNfTYayCYTkGd Z6umTJxeGuV3DVN; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352041829; x=1383577829; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20IETF85=20session=20agenda |Date:=20Sun,=204=20Nov=202012=2015:10:27=20+0000 |Message-ID:=20<59590F45-82D8-4978-840D-67ECC6EB6940@nomi net.org.uk>|To:=20Alejandro=20Acosta=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<2849e29c-f60a-46f5-a2e6-7e89f8037075> |In-Reply-To:=20|References:=20<1F8F6EE7-BD9 9-4E30-84A0-D1EAB9470F8A@nominet.org.uk>=0D=0A=20; bh=TJVO907KZH/WxtK+FSXw4WfDNPghLIhUWr069onIHv4=; b=AmMav8EVPXY1F0W0zU2mY9LY9puGnA2BYkui0qBBFzFCipgpZCCvI+9Q PYqSNC7wsHAkN30QHaPY+6D9bkmm7PvWJniImanFMDIgwzWhZfPqPnNUf MB+mh26AR0qNHEh; X-IronPort-AV: E=Sophos;i="4.80,710,1344207600"; d="scan'208";a="36521833" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 04 Nov 2012 15:10:28 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Sun, 4 Nov 2012 15:10:27 +0000 From: Ray Bellis To: Alejandro Acosta Thread-Topic: [homenet] IETF85 session agenda Thread-Index: AQHNup3wCB0Y8A+cqU+2hhnVMILUVZfZx8+A Date: Sun, 4 Nov 2012 15:10:27 +0000 Message-ID: <59590F45-82D8-4978-840D-67ECC6EB6940@nominet.org.uk> References: <1F8F6EE7-BD99-4E30-84A0-D1EAB9470F8A@nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2849e29c-f60a-46f5-a2e6-7e89f8037075> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] IETF85 session agenda X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:10:35 -0000 On 4 Nov 2012, at 10:06, Alejandro Acosta = wrote: >=20 > There is a draft from E. Kline called: draft-kline-default-perimeter-01. > I've been only able to find the first version (00). > Am I right? We are expecting a -01 from Erik when the document submission system re-ope= ns. Ray From alejandroacostaalamo@gmail.com Mon Nov 5 13:15:50 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE1D21F8665 for ; Mon, 5 Nov 2012 13:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v8fb0UiSxJZ for ; Mon, 5 Nov 2012 13:15:50 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F81921F8661 for ; Mon, 5 Nov 2012 13:15:50 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so7056286vcb.31 for ; Mon, 05 Nov 2012 13:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HYYGF4h2vAF2ZJkEg/HvKF3vDTrt56n/tsnDHUe5AhY=; b=SVD6M2sQAfAFe0XPsmPLe2ZHnZDUKpBpG90ss8luHYyu/izWV396Cw7jD66D5Sy+bO jg93wXVcavJkDS3ygqCU10PtlHdP5TqEFaYPxpn958ZtZwzeNM0beQ0lAVrninrZZGR5 HxnIpycV3kjwY2q3dsUJteHKLWZWcOWBpt8xaxLSnQtLOPobgfJOGMWkOxlwN2Kdcdbp g7qvpNmXw13Fd8H56I/mm8royUMTBJhaIqilwxOw0SGs/OmGeRUBZfRo3vWiQrkLI2yF ATlAFP+wH3Of+s0E1NLrWPdplwl5iLdLy8VFHJ0dCXiu8SDaiG8cOFYuJSZFv3SQWnbF 5SWw== MIME-Version: 1.0 Received: by 10.220.8.73 with SMTP id g9mr10731033vcg.28.1352150149720; Mon, 05 Nov 2012 13:15:49 -0800 (PST) Received: by 10.58.56.100 with HTTP; Mon, 5 Nov 2012 13:15:49 -0800 (PST) Date: Mon, 5 Nov 2012 16:15:49 -0500 Message-ID: From: Alejandro Acosta To: "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [homenet] Question/Comment about draft-arkko-homenet-prefix-assignment-03 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:15:50 -0000 Hi, Regarding draft-arkko-homenet-prefix-assignment-03.txt should (or it's mentioned and I missed it) somehow the case where the router can ran out of /64 prefixes to assign? I suppose the solution it's manual, just to me explicit. And one very small comment: In the introduccion, paragrah 3 it says OSPv3, should it be OSPFv3? Alejandro, From mark@townsley.net Mon Nov 5 16:04:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83E411E80A5 for ; Mon, 5 Nov 2012 16:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-4YUhwuKWd6 for ; Mon, 5 Nov 2012 16:04:26 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C84FD21F859B for ; Mon, 5 Nov 2012 16:04:26 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so4276952pbb.31 for ; Mon, 05 Nov 2012 16:04:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=17BE31eY4TRMynn6l3vA+dbW0QtJa0DjdLjj+UaGkTo=; b=bjByCGQsz59oWGrUar3wot+tFRvNIxJln0J1x7d0ptUA48CCrosCM26hHhvixVQ9bD WxqE4uqqkObyddn8loVzPddVMNtxNWlak4xQatwSWNGSHvcs4reUwhG+r41ozhm6Feg6 26uueyclEE94+dJZuf64RcusGW1SwGfK3kd31FBSMTrPAaP80/oENSCEP2P5WSz1SWPk HW2VFNRstr1qy9Y98taHS+nsB+UvqDMmByNCXo1TUEWP3Umw8gv+h521ab/wVRsqBDJz phRwBp3b7NEznjjJB3C0DiriXfP0Uc/UFgxDxylmN5Khr5WM9z2noB4T66ITRQW2C9LH BNaQ== Received: by 10.68.245.169 with SMTP id xp9mr35387195pbc.142.1352160266618; Mon, 05 Nov 2012 16:04:26 -0800 (PST) Received: from [10.21.167.222] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPS id nv2sm11289605pbc.44.2012.11.05.16.04.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 16:04:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_4136DD2A-99F4-4D89-8647-900F34B5B31C" From: Mark Townsley In-Reply-To: <53D63104-623F-4F61-854C-30AF7DC40294@townsley.net> Date: Mon, 5 Nov 2012 19:04:13 -0500 Message-Id: <71ED493B-C4F9-41C6-8720-12D17D2B5BB0@townsley.net> References: <53D63104-623F-4F61-854C-30AF7DC40294@townsley.net> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnyC3ZvFrxUi5N/ZziuuB/IKsAMjx7ep2hEe3GemWtesnujcfKrssMaNLZrxxQGAYxcrPEa Cc: Geoff Mulligan , Markus Stenberg , Jari Arkko Subject: [homenet] Tuesday 11:00 - 12:30, Room 301/302 - Come with your hosts and plug in X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:04:27 -0000 --Apple-Mail=_4136DD2A-99F4-4D89-8647-900F34B5B31C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jari and Markus have a homenet for you to plug into. Thanks to IPSO for = sharing workspace.=20 I think it would be interesting to have a variety of hosts plug in and = to report on what worked and what didn't - if all goes well, there will = be multiple prefixes, ULAs, source+dest routing, etc. on whatever = interface you plug into. Rather than crowding the IPSO room anytime, please try and stop by = between 11:00 and 12:30 with devices in hand tomorrow (Tuesday).=20 Thanks, - Mark On Oct 30, 2012, at 1:16 PM, Mark Townsley wrote: >=20 > Group, >=20 > When we created the homenet WG, we identified that open source code = was a critical component in the consumer home router marketplace. As = such, I thought I'd let the group know that there will be open source = coders in our midst next week carrying around some OpenWRT routers and = implementations of homenet-targeted drafts. Their work is based on the = work Jari has been leading. Jari is one of the coders, the other is = Markus Stenberg, whose company is being supported via a Cisco = "Technology Fund" project that I was a co-sponsor of within Cisco. Two = compilier-wielding Finns. =20 >=20 > The implementations are based on these drafts: >=20 > http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02 > http://www.ietf.org/id/draft-acee-ospf-ospfv3-autoconfig-03.txt >=20 > The IPSO folks have been nice enough to offer them a corner of a table = to work on, and I suspect that's where you will be able to find them = during the week when they are not doing other things. They have also = been generously offered a corner of a table at bits-n-bites in case you = miss them during the week and want to look at what they have over food = and beer.=20 >=20 > I've been cc'd on some of the emails between Jari and Markus, and = believe they will have a presentation ready showing what they hope to = have working, not working, etc. by the time we meet next week if not = before. My understanding is that Jari and Markus both consider their = work "Experimental" at this stage, and the aim is simply to learn as = much as possible this week. Assuming they get things up and running, = please come by with every kind of IPv6-enabled device you can think of = to plug into their network. Try your best to break it, and capture what = happened when the breakage occurred. If you're really bored, hack up = your own implementation and plug in ;-) >=20 > Organization of this has all been very last minute and informal thus = far. For future IETFs, the ADs have offered to work with homenet to have = our own space rather than having to camp out with others. So - if you = have some running code, let us know and we'll make sure we have some = place for you to work together.=20 >=20 > See "y'all" in Georgia next week, >=20 > - Mark >=20 >=20 >=20 >=20 --Apple-Mail=_4136DD2A-99F4-4D89-8647-900F34B5B31C Content-Type: multipart/mixed; boundary="Apple-Mail=_66DE6087-7889-475A-B4EF-65BD6DEB7092" --Apple-Mail=_66DE6087-7889-475A-B4EF-65BD6DEB7092 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii


Jari and Markus have a homenet for you to plug into. Thanks to IPSO for sharing workspace. 

I think it would be interesting to have a variety of hosts plug in and to report on what worked and what didn't - if all goes well, there will be multiple prefixes, ULAs, source+dest routing, etc. on whatever interface you plug into.

Rather than crowding the IPSO room anytime, please try and stop by between 11:00 and 12:30 with devices in hand tomorrow (Tuesday). 

--Apple-Mail=_66DE6087-7889-475A-B4EF-65BD6DEB7092 Content-Disposition: inline; filename=IMG_1259.jpeg Content-Type: image/JPG; name="IMG_1259.jpeg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////2wBDAAICAgIC AQICAgICAgIDAwYEAwMDAwcFBQQGCAcICAgHCAgJCg0LCQkMCggICw8LDA0ODg4OCQsQEQ8OEQ0O Dg7/2wBDAQICAgMDAwYEBAYOCQgJDg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg7/wAARCADwAUADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAEC AwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ 2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QA tREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaH iImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq 8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD78t4W8tQpPHWrojXcSWY+2OKkhQFk457VZKjzsfj1r4P2 lz6rlGRRAgHipRGA/b6etSKmEBwQT6VKqsW6g89annHGJB5XzdOPpTzD3x+AqyoJc5xj3pzJwflP Wnzl6me0e5cfd9KpS2/JHykj2rYKE8Y59M9KrSA57VLkUkYc1uCDnBIHAxWZLbgHgH8a6iRGOMk4 /SqEsOeMdRS5tBnKvZ5B+T9Kzp7VSPukV2DwjcwwP8KpSwDZyFz2+WmnYGcXJZZJwufQ1GbBT2X8 RXUtb/OQVBOeDjFIbUGPkd+taRmkDOXFivYGrC2IIHy9Pauh+y/KM4x2qQWgA5AHvXTCorGLVzHi sQc/L9a0I7Ec4QHnmtaO0+U8A8elXYrXAHTHWt1UMminDZYUEL9RitNLEbVG0fgK0YYenGa04rb5 sgGtHV0ItqZkFiAw45rWjsgFA2jjrV6K3G8HjmtOODI6c+1Z+0SYzHjslAAwucVxPxH0Nb/4WXzB A0ls6zr+Bwf0Jr1qKBSM4/8ArVHqGlC+0C+s2VSs0DR8+pBFZuqjSGjPgZ9M5PyZrKm0vqdv9K9Y m0sI7oVw6MQax59O68fjWPte51xZ5RcaWMfd/wAKwrrTQFPydq9cn035fu5HSsO70zr8oHr7Vm5p msWeM3emgcbDXM3dhtZuPxr2O904jPAJxzxXK3mnHecp2rJyNk3Y8hurHDEYrmLyyAB4Ar1i9sD5 jYHNcnfWPB+XFYzLTaPKLu1xknmueuIDzxXpN7Y/KRjFcnd2uCRjnnmpjKy0OiE7nDTxHbyKxLmP k12F1bkZJFYFzFyR2zXRGRqzmjGRI+V445qSKLLdDz7VoR2ktxdSpEoOwAtk4x+NacWk3JH/ACxH rmSuhyaRgnZmVHFljxVtbcnkCtqLR5gfmkg/76J/pV6PSgpG68t1HsDWLkaKaP32it8gYIP4ZxU0 luSVYdjU8KsYlxjPpgVbCqFBJHPYVx81zwrFFYn3cjIHrUojKsPY1bUDGCOPXFTbeM7fpmjndhpF bymPXC8+lOEQ2nJOR7VfRQMZUHuc04J87cMB29Krn0KsZpiBXPy4qF4Pm6YrX8sjnafypGjyO+fp SUx8pgyQ/L0qu9vmPoufauiMIKZOOvGe9RPEuMY6UcyCxzbW2WAxz3xVV7Y/NwD9a6jyAW6dR2qF 7bC5x+tCkJo5BrTByf5U0WYPYkCun+zAPyBj61F9n+bABApqYHPLaENg/wAqnWzBUkjPPpW4LbnG M1MLXB4X8a0VQzaMaO16cGr6Wefw7YrSS2xjGCe/pV6O3O0ZWtVV0IaKUVnhBxWnDa4HAOcVcity CuVyK1I7U91I9Kr22hDRnwWZJXp9cVpx2+Hxg/hV+CDbt45+tX47XL5Oc+lQ6oWM+K144AHHerJg 3E4GTWvFajBxyPapDCcFRkDPaplN2HY+UvFGjiz8dapEqgJ5xdRjjDfN/WuQmsMsflz+HSvffiHp Yj8RwXYHE8GCcd1OP5EV5fJa+orN1Tqhqjzq4sAUIxkViXOn5BBHFemz2Q2nge9YV1aDPQ8VHtDa J5TeWPX5a5W+0/ljt6+1etXlmN7YGfwrlb2z4cfyFHtLmyR4/e6fkNwPyrjtQsBhuPwr2O9tPlbj FcRqFquD161XMUr3PH7+z4PHP0rjL6z5JA/SvW9QtMEgiuMvbQEHjj6Vm9GVseU3tthDxzmuXu4O vHf1r03ULP5++PpXG3locHrWkJdDoUjJ8PWnmT6o/sic/iaydP0qKfULiSWW6aVZGGwzNtCk8cZx XoHhiy26FqE+3g3J/JVqppdkzXczFTjCjP4Z/rXUk7HM5LmdzNh0SDfzGW9csTWjHolrj/UKffFd VBp5wvyk1sw6a2MYz+FRqDqH7TQudoJBBx361fQAqM7ffNZcIPy4OeK1E3MORivMUzicdSwoVcjp 71KACoIz781FwdvOT7dqsqPk5IHPShSuFhxUFRk/lU6/LjgjmmKNyHnP0FTgEgZHP60+cdhDt64J +tJtBHA9+alwQuOacEBXjO760+cViptBXlTgVHsyw6nnpir4TJPf1zTdox0GCeOKXMBQaL5l4z7A dKR4sqcqQPStDygDznFDwgk/TPWnzCZi+QNxBGM+1KtuNo45PetHy/nwcZ+tP8vKcHGOnpSUtQZm +QCclfxzU4gG30qysfGMDJ9RUyp8mMAH3rRTIaIEth0GOlW0hAGMH+lSxphhwPpmp40xk9vrVe0R LRJFF0IArWihBVRx0qvGgwvIPNacSgAY54p+0IaHwxAEDb0q8sY3t04qNByvPNXVjJJA7+9RKoKw 6NPk4zj1zUoXDZ561KqERjv7VJswNuM5NTKowR514/svP8KRXIGWhn7+jcfzxXizQjBOOc9K+l9f sTeeDtQhwC3lFlA9Rz/SvAntvmbjnP5VDkzppNWOTng5OVrDuLcj+En0Oa7i4t8kAD8RWJd254yO RUuZvE89u7U7zhT9a5a9teG4P4V6bc2zEnI5I71y97aHacggGnzmqPLLy1Jz8uK4vUbP5+R1r129 tPlPoDXF6jbDngVqncaZ5DqNmcN69q4u9s8AjGK9d1C1GD8oBrib+0O48VaehTPKb+zPIAx7Vx17 Z/M2Fr1W+tOTwc1yF9afunIXoDSS1C+pR0ex8n4cPIQPmEj59ck0mj6aRbzMQQGl4z3GABXcx6d5 Pw2sk2gFoE/8eNGi6d/xKITj7xLfma9G3Q5XO7KNvpxJGF+ma3oNOAj5Xmt2300NEyNuAYEEqcH8 62o7AJbhcEgDqeTVKKsNSP00i2+VnqfpVuM/J941QiJMXpirCErznI69K+c5ybFwOcAZGD1zVgOc E5YCqEbHceRweCRVlCRjnnv0pqRVi6pOMDd+NWkJCc447Z61RVsZA/HJqyPujqefwpqYmifDb8/K Pw60/J29wD6U0NyAf51Jj5CcgA9MU+boSxqr+FLgkHGOnSlXr6fXvT0Bw33frTuIYVJTqF+tTAAw jJppGVPT8qkQc4PT60KYrELRgnkEn1xStH8mMfjU57jI98Chk4JX070cwkVVTD47fWrIjLZB549a bjJ+bnj1qwFIUdelHMgsIiAY4q0sY29R7Y71EowF9asIGCfyo5ybFqNMICTnPvWnCo8odvYVRjAy MdfetGIbY88e9O5LVy5EgO3k496uID5mAapxN9zk49auLgc5596fMQWAOffHrTwpOB3zUKOAcmpA 4I7nmk5IlpkrBWiKHDAgg/Q14Xe2fkancW5/gcr+te3+YGHXH1rzTxLbhPE87jOJAHHHtzUyka0d GefzQDzM4yPWsie3BZs5rqZYiWOQayLiLlhgc+1ZuR2JHG3MAO4gYGK5m8i+UjH0ruLmE4b+EVzN 3CSh6ZpqZokcHeRfIeATXGX8BO4YHX0r0u5tcDnBrk762UM3TpW8ZaFHlt/anBwAK42+tcliQPrX qeoW+N2QMVxt5ACfu8etaxkVc8vvrXLMcdq5G+tP9GmIXnaRxXqF7CPm+Xqc1zxsRPf20GAfMmRM fVgK13ZEtNS7q+n/AGXwzZw7fuRKCP8AdXP9KfpWmBNJtV2j/Vgn8q0PGr6Ul5BZ6w0i6fIjiUxs VPAGORyKj8N694Rh8L6daHWoRJHEA29JCM+mSOfrmuyeLhGpyPTS5yqLaua8Nl8vTFaAsx5f3RxV 631Lw3KAU1zTPxlAz+daSnTZlIt9S0+Y5/huFJ/nVxrQezGrrc+3Y5TtBxk/TirIYkgnaFPSsaOY qAMksD0HatCGckDCj3NfOJ3N2jSDAdcE1aRiQDj8e1UYpQep5zxxWzpTwHWoTP5YiQ7m3/d49faq V27Exi27IoyXKxO+Enn2DL+RC0m32OO/tVabxNpdpbl5TfuRHulAgAEGTgF8ngZ9jXMX3xl8O6b4 v1a3N/FPmcR2cUGGM3AJbBHXJPHAArF8U+P93ha4lbmGePcFbbsVc9W5J4+gqHfoe7Ty2MV76O+0 rxTp93o9m891brNM2xSrAq5z2wa6pXxnnIJ4zXwL8O3udX+Iera1b67o8OlW2StpafKJOSd+4gbj wBz619uaLffbvDFldIzMJIlPzdTV3PPx+DVK0l1OhD4fril8w7ccc9cVQLcg8DB71Iz5bO40Nnmt FwOSvfpzmplf5evNZgfBIyealD7cdPrikpCsXUkwxyc57U9SS/8AhWd5mHOQBmp1lwcDAB/GmmHK WeMjG76irKspXGcEjrWYZSTknJ9qnWTAweOPShSCxoqeAM5qQEbiOpFZ6yoADnP0FPEoOTn8BS5h cpso/wAoO4g5q8kowB82BXPJN9cg5rQim3RcbgKakS4m1FL83XjPFTmYAHJ71hCQ5BGanaUZBJ4x 6UruwKJsLP3ySakE5xnp9axY5sN1GM1I0/U/jU8zSHymqZjn5RXMeIk3/Z5zyRlT/T+taPnkY5xW bqTifS5M5+U7qnm0KirM4113Enmsq5UfMcc1rO4DnAH1rKuGG1uKVzYwZ4wc1z13FjPcda6S4bg9 K5+8fAwTVJmhy96oEZx1xXH3yZdu55rsrs70OP0rlpbaS4u1ghUvNI2xVHcmuiJSOEvoxnnPX865 K8gHzcfnX3b4W+F/gvw9pSax4jRPE2oeQsqxuwFrGW7BerkercH0ru9RTwDp/g91uPB/h670edCZ zNZoGUHqQQBjHoMEdq9OGDb+KVjGVSavaDZ+VN5BkNwcd6g0TTvP8aacpBOJtx/AE19CfF7w58OL V4Na+HmsRS2k7lbjSzN5jQH1Qnkr7HkZ615T4Tt0fxiJcH91Cz0o0+WqkxOpeFzl/HXge38X35tZ ryW0SMZJjQEkEnI5qsnwu8ICzih/sW2wiBQygqTgYzwa9RlhVtYupAo3YRSfwJ/rThEM+/1rulCD ldowVSSVrnkx+EvhYk+XBe23/XK7daE+EuhW7vJHd68SwwP9MOVr2FIfl55pkiYOM5xU+xg9eVFK rLufTEcjE/ebr0FX0dwCQRzWZHLyNoOcc1b835fy718wdLZqRyOBg5z7VxfxNutat/gN4ovPD2ow 6Zq9rYvPBNLKI0OwZZCW4ywyB7kV0Zk4U9s8nNUNX0+11vwpqWjX4Mlle27QTL7MCMj3HWqjJJq5 VGUY1E5bXPzJ0LUtV8WWl3r0eoWguSqYsydwdwMYf8q9BtJPE/iyCLT/ABDeyabpMZ/eW1uoR5AD 93IGQDVq5+G8vww+06NALa6m817i1luJ95nVidpcqMqSBjBHbvXJweJPG9t4ksrbVNG03TLK7uVg jkM5J5OMgEV9RhMDRcbxVz62nUVR913Poq0i0nT/AIdXdjY6THZQLbsVeM/O5A4yevavpn4fTXMP wX8Mfa4/IumsI5JI26oWGcH3Ga+QfAen+Mbj4jGDxJq2mHSPtCpDb2aZaTkDa5YcD1xX2tGVjjRR tVAAqqB2HSvOzemqTil1PIzmcm4pqxsm8JwQR7VILkjBJIyKxg2GJ/pUockgAnB7V4yZ4TRrLcje Rn8Kk+1ZQA8enNZ24Bu4pVY89aVxNGj54DZPf061YSbnJrI3kHrjNWFdSo4+tMLGh5pL5BHTnmrS yAlQWA4rJWU4HAPtVlJCADkU7hYv78HA55qcMpXJJ+mazfN+Xqfr6UqyDnnn1pJhY2A4IAHWrsUm ExwMVhrOoOC35VeFwuBg8mqQmjXjkORnr7imvIS5bJAzVAXC+YBkk+tOaUnncOtN7CSL0cvPWgzZ Xkis/wAzGTkfnVV5+OGJHbArNlJGo90MdTj61Umux5ToTwwIrIeVt2ASaqs5Lnd6etK9ylEqG4y7 DjOcHms25mzwGxSTvtu5c8HOarNb3c2lz3kcTNawECWTcAFJ6fWklcvRbmZcSYU/Nk96wLhgz/Mf 1q7cXAA5Ofxrnbm4USk5zk9KuJRWupFGccZrCtdS0u08WWZ1XUbbTbdi5Ms0gQABSc8+nFWLy66k HP4Vw+uatb6bod/f3Gj22thYGVrSZeJkOMqT1x3IHpXdhYqVWKezZpSb516o9juvGml3WqWsa+Ld BWyuEAtnNyAJVHGRzjAPHFee/E3WZ9D+FXiG/hv7u8tEt2dvJuw0CqBksOw/CvFNeuvhkkGjQ2vh BLuz0qzMd1AZDEtu7OZWaBixVhubG3nIxzkV3Hh6/wDAF14fF/Y2r3lo2ZUtr2Nmt0GPuqjkjPXn H5V9ViaVOjFSPq3B1fcsrNb3PlPwHrGu+IvEa6vfWATSpbVjb3SyriVg20sFzuwemSMZ75r6O8GQ A3moT4+7CFH4n/61cl4l8bfDH/hY/wDwiXhzU4bHxDJAt7caPIvlJAj9PJzwVbAJA9BxXf8Ag1Y/ +EcvZkdH3ThDtYHGB0/WvMqQl7dO1j5TM6dGjN06cr2tf16olxm4umPUzEflgf0pyjnpUaN+5LZ5 Z2Y/iTTw4z7V0cp5KkWVAxnHFVpj155A61MrYUHNVLlsRyH/AGaVikfQiyrhSCTnnrV1HVwMZOfQ 1z6yttXOMUl3qlrpmkXOo3kwitbeJpJnJ+6oHNfKRTbsdr7nS+YGUqTXlnjX4y+BvA6yR6lqi3uo KD/olnh2z/tHoP5+1fDPxN/aS1nUb28todRfT9EMph8uym2mHJ+XzyPm59ema+V77Xbi7lE89wJL iRmGxmz0r7bAcJX97ES+S/V/16nkVszW0EfUz/GHwP4u/aA+JGrXetz+HvEmrw6dFoOk3bboLqOE TpLh8YWXLRkLxkE9SKwtV8a63BrlhKILO+jtXyIbtNyhvXPUH3HNfBvjiCxuNGmvT500sT5Ecb4e Fsn5x6j1H41keEvjB4t0a/tNOvL221nT2YKg1GUgxj3kHOB75r6CWW046U/JfcduU8TfVvcqrQ/V a7+Mum+Abzwv488W28sq3l6IVsLWQRlhsLF8Y6KQOozX1r4K/aG+FvjaC2XT/Eltp17MPltNRIgc n0BJ2t+Br+efV/H2u+MvHzXuv3AS1hjZLW2jY+TCD/dHqccnqa1o/Fd/ojwXsLNJp7OFu7Zmyrej j0NcmI4eoYiN5tqXl/kceZ8Ryr4pzgvd6XP6b450lRZY5FljYZV1YMG+hHFS+dgjkjAr8Nfg1+0x 4g+HfxF00Jqdxf8AhOdlGpWErl1MZPLICflcDkEfQ1+zuk6zZ654V0/WNLu4r3TL63Se2uIzlZI2 AZWB+hr4nOMoqYCaTd4vZnTg8ZDEJ20aOuW59WwamS6XLZaueWUgg8HjNWo5GbJyCfevHudlka73 I3fexTzcfNwB05rF3P5gJOB71bVl8sHPP1oTCxcF3IAo9R3q1HfSeUAAMZrHzgld3fvVhCAMq276 Ur6lJGity5HGevSn/aGDkZPToDWcHYRZAwfel3HJAHNFx8pt2ZlubyK3hiknldgqqgJLH2FbUiwW RZLi6Mt0jlWtrRBKyHuGbO1T7Zrw742fFkfBH9mU6jpsiDx34oaSz0aTILWduoxNcD0bJ2r7nPav yot/id4ttDObbXdWhSVy8u27cbiepPPUmvawmUzrUlPmtc9nKshqY+EqnNyxWi0vfv8ALp6n7aXX ivwJaa7Do83jfS9P8QSpvTTdSBgd/ZX5Qn2zmtIzlxw4YdipyD+NfgleeJdSvNTku57yaeZzuZ3c k5+vWvvT9lz4232qs3gDxFObp0Tfpl1I+XwMAxEnqBwR+NaY/KvZU+ePTf8AzOnM+GJYSj7WE+e2 +lvmj79jlBUAnnuaa8gDHBGKy47gnOc/nUTTMR6fjXgt6HzNjQMwzxjp3qlLL37dzXld38aPhhZf FbUfBGpeONB0jxVYlBPp+oz/AGZzvUMpUvhXBBHIJrvFu47ixiuYJo7i1kGYp4nDxyD1VhwR9DWt ShVhFSlFpPy0FCcW7JlDUrgpcK3OGXrVR/EEkXhe50xLdWE8gZpi5yuMcAY9vWvFf2j/AIoa18I/ 2bL3xzonh6y8SS2l5DDNb3UrokUchK+Z8nPDbRjp81flnr37dPxz1pXXSLPw34eUnhrLTPNZR6Zl Lgn3xXXg8BWrR5oWtsW4KW5+xM00jttUO7E9AM1yOsazpelwyS6pqum6bGn32urpItv13EV+J2r/ ABe/aE8cabNNdeLPGl5YqcTLbTmGGMHuVTAUe+AK4/SPAvibxlr5i1jWVsCELm51KaaZeBk8xq54 AJ54wOtd8MmSa55m3sny83Q/Wfxl+0f8IPCeg3t0/jbSdZvoIyY7LSpftDzN2UMgKj6kgV+UPxV/ aX8beP8A4vaVrK6hPomkaVerPp+n2chCxkODlz/G2F6nj2FeL6+BYXMthb3EV1FDKw8+LO2XtuGQ DtI6ZArgJJTJcnPrzX2WW5NRwsea15Pv0PkcfmMqk3GD0X4n7gL+0J8G/GfhO41rwjp0uoXioi3l u2kgfZ3Zc4bjGchsfSoPBV14q+I/jPS9OsIH0vQlkSOZm5klGQAigcAmvzJ+GHjW78BfAXxPrlpa 2+oo3iGztbqzlmKiWOSC4bOB3DRghu3I7mvvf4F/tJQ6B8BfGXxTHhW0sNM8N27JZx6hfDddXhTj ywoBYIzQr15Mnbaa66eSSxFRU46+r0SR9BS4ohToKVR+8uiR8G/HLxfca1+3F471WGS2uIrHVZtN sGVSI/JgYwpgccHYW/GvTfhJ+0R4r+Hs72tpcx6ppcs/m3lncW8aQu+0KSrKu/dgAZzjjoa+QbrU brVfEl7qN05kvby5eed89XdizH8ya2ra8EUYXgAcbiev0HpXoxp0uT2bjeJ8dVxFSVV1G9Xqfq3p H7Vvga6SCPV7HU9JlKDGCsoY9zn5Rj8a9U0r41fDjVHHleIUtV4+e8t5IU/Byuw/gxr8jdD8R3tl pdx9ktftijDSKY1YhADk4YH9K7LS/FfhS/iNlKmtWN9McFzqGyAg9tqJjHsRXzmNyycJNwWh9Bgc XQmoqrKz/rrqfsJp/iLQdUiDaZrOlX4PT7Pdo5P4A5qxdvi3cnIPuMV+TNnouo29nKLPUfCs1suW Eb7Fl+oLKH/lXZeCPEnivSJxFH4h1G2tmQ4kutckW1Puqn5SR6DP0rx58sd2e5PLqluaLuj9llnJ jyWr59/ae8RT6L+ybqht52ikuruGDKkgkHLEf+O/pXucasUycA5718mftkxzt+zrorRswRNVZmUD qRA+D+HNeDk8FLHU15o5sZpRkfmhqfipL3WpLXxE6RCUlLC+jTBA7xyDncpHrkH2PNZOm6gI9TFp cSlpbZyi/PncuMg+/Heua1KZjZzabqmIrS4wbW8A4jk64b+6c1yNvqOpJr6QX0qWs8eEZ3XaMDjP uCDnNfrF9T49yPWNR+zzRy3Cy7Y1+/u5FeSaxpaWl39piU/ZidwIGMe1dub6LXdWS0tn26XB+Hms OrMfSqXi2W2g8Li0hILM4bgdap7ES1MO7i0wahcNpn2yXTwFKfagvmqNoyTt4656dsUtvco1pLZX Ega1kXCuedp7VBe6hpD6Posujafc2F9bWYXUmmu/NW6m3HMiqQNilSo25PQnPNdB4M8PaL4l8Zpb atrE2h6K4QyzRWUlyyFnVNoCjg/NkE8cY68U0zI5nT9RudNWeFpMTwttTdzlen/6q/an9g74jP4j /Zkv/Bt7O0l/4bugLcMcn7LKCyjnsHEgr8XvHel6NoXxZv8ASfD2oXupaZAQiT3QQOxB5JCkjHGR z3r7B/Ye+IEnhr9sjTNDluVWx8RW0lhMrkAb8eZHj33IB/wI+teHnuG9vgprqtV8v+Ad+XVvZ14+ eh+5PmqcEVKJT5hxgA/rWarnywQG696eCxcc1+WO59eaJkwR8x4q5Gy+Vkk/SsfkYPP4VbWYCPbg 57HrmkmVcuM4ZupJz61YjkwgyOnrXh/xr+K0fwd+AWoeOpdIk1v7PcwwrarN5e4yPtzuwcflya+O bT/gpN4ICgal8PfEkHzBWaC7jkGe/XH+RXo4XKMViafPSjdX7r/M5q2No0pcs3Zn6ZtcqZmUOhYd VzzUgmJzwelfzz/Ff4y3vj39rHxF8R/h/wDE7V/CMOpSRmDTr55I2gCRqu0bSVPKnt0qTwn+3T8f /BmofYbnxHaeJ7SFyGXUYVlLYPUMCCa9mXCdf2aakrvo9P8AM4P7bp8zTjp3Pv79sfV7/U/jX4G0 8NK8UegslvH/ALRupQwH4jFfHt0lzZX7W13G8Eyn5kfrX0n4z8RWXxf+GHwh8fi60+bU7maJNVgs Js/YReIZPLOeVZZlkOCTjzFGT1r5Aj8enxP4v13SL2ziivdDuWtGu0yPtIV2QMRk4OUJ445r0srh y4bke8dH959/k2eck8PhktJJ+qa1/I6j7Scgr1xnk16h8F9Snsv2lPCMkUhj33wjZgcfKwIP4c14 vb3VtdXDxW97p0l1GcPB9rjWVfqpIP6d67LwJPqdh8Z9LuntL6OO2E0jSRISEYQuUyRwMtitsTSk 6MrrdM+gxuZ4V0KkVUTdmrXXY/dWa9isdNS81G5tdMtWUMZ7yZYY+n95yB+teR+I/wBoX4K+FUlO ufEnw/HJGMtFayNcP+SA5/A1+EsyfGTxvqjS6vc+KtWknbmS6uHWM5PGWYgYHuauL8EfFzTSx391 pVtKkpjkjW6EuOM7gyZDD3B614FLIlJ7t+h+fVaVKjFSqytfbp+Z2H7aXxL+HHxQ/aZ0vxh8OLvV LhW0lLTVLi4tfJWWWJjsZOSSNhA5APFeC+Dfjj8U/h5eiXwf458Q6MARuihu38p8dmQnaw9mBFdv 43+Dsvh/4Qanrf8AaQurmxCSeUkRwV3AMcn2NfMpky/XFfb4Ch7PDqm1tofF5jUpvEOVJ6H25qv7 bPxF8ZeCF8NfESSXWdKdAk8ujXTaZPKM5/eeWNknrhkIyBxVTwZ4k/Z1vL0rq+qeJrDzFwLfW9yr HxztubVDkn/atwB618VuXUZIIGagMnNaSwdBq3Lb00/IilmOIp7SP1L0X4b+GNd1K0ufhFe3niG9 vLiO1Flbi11giSQkIh+66qSB85UY6HBr9Zf2cP2XPDPwT0BvHPxP0nwtdfEu8tni8m3gBt9PgcbW QBiQ0jKSGYcYJUcZJ/B79gD4ij4df8FVfhVqNxci30/UtQOk3jMcLsuUMWT9GKmv6CP2tvi54Y8O /CC+FvcmXXLEjbskAUFyAFJ98g14eLwUKMueMnfpc+gwOLqY3loyjZPdrf07fqfi/wDtvfsmaH4X +J974z+BsiX3h3UbrM/hZWzcWErnpbZ5kiJPCfeXOBkdPzm8QfDnxh4V1NLLWdHvbXU9m+4svKJn tgcY8xPvLx3xj3r9AvE2p+J9f1qTxFqfi/Tr2JSSLKS6MIKZyU2nGQRwfmya+JfjdqkN78f7m7sb K30ofY4AY7WeV03BeWBkZmGfTOB2rtwOYTrVFDoluTneTUsLTc7NO607frr9xiaPYXl38D/HksKu 1vp1zpt1cjH3VLzwg/8AfUij8a9U+LniJvDXwY8F/BfTpI0g0u1j1HXvKx895MnmFGI6ld5z9F9K 8a0v4i+L9K0LV9Lg1d7jTdVhjh1K2u4knW7SOQSIrlgWIV1DAZGCKivde0nW9Vur/V9LuodRuZTJ NdWN2cOzclmjkDA/RWQV9HSxXJBpbtW+V7nyUqabT7GHYxtPfOqn7q9Acda3UtymPklJ7Fug/wAa +4v2MNZ/Yh0OTX4v2kbfUNW1m8vEGlT6jYXAsLWAIMiTyHPzls84Ixj3r9XIvgH/AME9/il4Re58 BaL8O9WDR7g/h/xBItxGPUoJdyn/AHlrzqmOjSb5ov1PRw2WzxDSjJXZ+KnwL8CWfiXwf8UfEurX E1npHhzw5LPNIjYG9lYrn6bSRXzPaXbeXDJkB0OT9a+m/jb4k0j4VfEL43fB74USzzeCdS1O2s76 8vJC9zGtvl3gDDAKGQ43EZITHc5+VrEFo5PrXSpqST7nPWg6c3Te60PcfA2uDWNeHh+/gN9JLLix O0s4OcbAB19hX1Pp2heL7WzhtdE8WWOmKPlbS9alNu6+wjmG3Ffn/YTz2uqefbu0VxG+5HU8qeoP 519/eAdJ+NXjb9njR/E3h/XE8Q6XfWrCfTYNRimuICpKOGjlJ8v7ueMcGvm87wyUo1L2v+Z9hw3m V4ujNJ21Xp6qz/E/U6ObjANfKn7YFzHF+zppcssvloupN1IGSYXr6cR2yMYxXz7+0P8AEG1+G3gH RvEt54E8MePEhvWFrFraySRWdwFDJMIlIEvAZSjHBBOMGvksi1x9O/f9CMc7UJH5Ha3BaX+mrJeK YIpOXixh2OMAg45P6V45fwz2uomKZixj+UEnOV7V7v4n8e6V4v8AGmr+I5NJu47zUJ2nuILCMW1t EzEkqi4O1Mnhc8CvH/EILxiePTru0hPyqZiWLH/eIFfqc7M+RlG+pb0jxVBpmnrbnT45cfxqcEn1 qnqmp/2pMJ9rR552HnFc1DExkBI+UdT7V9UfDL4K+CfFPw5sPEfinxtrWnNdlyun6VpiSNGisVBa SRwCTjOAvHqaUZN6MzabPmWIbJmDDMbjGQOVqWK5vbGZkjmurVXwHaJ2AfByOnXkA/hX6A2fwq/Z /wBNgjjl0Hxf4gkj6Pea4sMcnuyRRBvwD12+j2fwi0ORTofwk8CQuP47+2k1FifX/Snkx+GK05dN yHZH5bW6XF3rckEUUt1clvuW6l2P4Dmvpj4JfCT4s+I/jn4JuvDXgHxi0VtrlrPNfLp8kccKpMjM 7yuFRFAB5JAr9DtH+Id9Z2og0m10jRoOMR2FhDAF+mxRityb4ga1eRj7Xql3cYGB5kxbH50nRTTV yPbKLuj7qmMFrK327V9Gswpw2++jcg/7qFm/SsqXxN4UtW/e+Iop2Ha2t3YH8W218Qf8JPKxJe4d vq1O/wCEjGAPMzXzcOFMFDe79X/kelPPcTLZJH2O/wASvBjaybP7edPiWFpHutSlihjOCBtX5skn PQc8VxWt/tGfBjw4WW+8c2N3J2jsUaU59COGB/CvgD402s/iTw3pBX+0X0+1meS4WytmmkkYgBEG PlXPPzMQB7nivE9M8LiG8UX9na+H5dxxZ3Ngt3cYHeRp2WME54CrnFeVi8jwsKnM/dXRK7b+Su/v a8j67J4xrYZVKs9euyS+b/S59W/tDftSfDT4lfs/a54C8PWWvSXV1PDJDfuiKIjFIr7gD1PBxkjm vy5uvEfgqzSc2/hTWdbllfJutY1EorMO4SIDPXu5r6V+IVh4U0XwZILi5udU3tF5r2OhQwxIhlXd iQRrh8A+vWviLUbyaa6MLSM0ELMIkzwozXv5VQhQo8sE7X6pr87nhZ+6Xtl7OV1bo763/A7Wb4ia lFbrDpWleHNDUAfPYaXEkh+rkF8+4YUngXwvdfEj46WejMzoLgma8lhjG4IoyxHbJ6ZPc152zAOp PIwOpr2DTfE+peH/AIY6dfeFdSs7DUJMwXMtpHLHcquCdrOW2sOf4R6c16m+5882fX3hSWw8CeFP HdjoAM2k2DW5SCa5DuJrdi5G4fefIHTpnnHSvi+Px9e6F8VfEutaVZ2UkOo6jLO8F/biQMjSMygj PB+bqCD717z4F8O/EvUfg7/bvhSLSp/Cs9wI7u5uJrYlbjGGVlkbcPXOOnNeH/FjwxceEfHEmk3v 9ivfWtzLBNNpl0k0Vx92QSoU+UoRIACOPlI7Vz0ssjR56i+07noVs2q1ORLRw0ut9rb+hebxJ8PP Eksj6pD4j8FanIxd59Lm+12jMepMMjAqPZSaxNWl1XwtbQ3Og+N7XXdOnfKT2SywyRH0dXVdpOOx I4riNH0jVvEGvxaXoemX+salMcQ2tnA0sj/QDt79K9gk/Z7+KieGbe4Xw0s2pyTyLJpMV9Ab2JVC kM0O/cAdxA4z8p4pzxNKnpOSXq7GNPDYiu3KMXL0TZ2vwN8Z+Lda+IV/a6p4huLuyWy/dJqDNIgk 3LgLlhg4z0r6yg1O6huvJvYE87HyPAxG/wDA9PzNeEfsst4N8MeI/iN4Q+LfgC+vLye3gaA3Algu 9OOWVnRMqrZ4PzAg4r6L8RfCC+069t9R+Hz2Pi3w3eGWfRNWhuEhlkjjG598MjB0dB99SCBg4JHN bJKSujlk3GTTMDXXt9Y8Kappkk0cCXVo8L+cMgBlxn04r8418Pa9c63eafZaZd3lxazmGUQx7huB 6A989R619W69quqvHLp2ueZM6HDNboqq4x3UEZPTkHB7CvM/HfhTS9Y8SDRdMuQsumwqotXBQhio Z3weuSev0rKfMmox3Z34OhSdGpXq35YtKy0bcr2V2nZWi3ez2S63XgU/2mz1Ce2uo5re5hcxywyo VZGHBBB5BFRNNvYEgA4wTnrXrnjbwvrmsfC7RfFkoa71XTSuk6vKBlpkVc2s7HudgaIt38tM8k14 pJ50D7Z4njIPORThK61IxmGVGaSd00mn5P8AVbPzTOo8OaxNoXjzRdat3ZJ7G+iuY2U4IKOGH8q/ o/l/Zq8LfG/456Z8WvEfxE15fAGu+HtPvl8J6dcFDaEwoA8rncm18ZyAWye3Wv5prK3vNQcrY2l3 euv3ltoWkI+oUGv3l/ZC+Hv7Q/jT9hTwn4i+Get+HdFSNLmwkXXBLC+n3MThfOdcAsNgBUYYDJJx WWIo+01ja525XWjTv7VtQfVdz7Z139ij9mO+MC2Nvr+hXyplVsdYEzHAwTtnWQj36c9q/n7/AG7f hronw2/4KOeI/BvhObUL7TbbSbGYNeeWJd0kCsRhAAevYZr9Z9JuvH3wQ1K+j8U/Gj4M6/4/166U 6xrS6hPfai8EZJEKW8QCquONqEZI5BNfjz+2z4ptvGP/AAUI8Ta7Z6jcapby6fYLHdy6cbMybbWM ErGSSFznBJye+K4cJhJU67bS2PXzSpUeXpqUnCT63tdLv3XqfKHTPGPWjdUZJJozmvVPk0yTew6E 1Ytr27sr2O6s7m5s7qM5SaCUxyKfUMCCKp5oPTvmgZ0q+LNXkllN/NFq/nH999uiErSc5OX+9knv nPvXr3gPSvAt58C/iVF4maPS/F++zHhy+ubkpb2wDs9wrIuXd2QKowrYz25NfPi/NKvXk11V7KZb iC6IJ3ptZvdf/rYrSLJvZkVzL9nZ5EOCUyGHrmvs39m3wp4q8U/BLU7zwomj3F/Y6jJEUlkX7SgI DZRSfuncecdjXxjqKj+zIHPO4EY/KvsT9kR/Cs/hjxvp2vWF/c6iHhlsLmK9MMdvneGLAKSx4GK8 fPYt4RtdLH0HDDvmEI/zXR+wwkLRjb1xxWD4u8A6P458GrpPi7R5LvRzKJU824e1UuAQCJAy+p4B r8yta/bM+MWqRGLT9TsPD0B+6unwCN1+jrhvzJFeK698ZPibrk8z6l451pzL/rFhm8kP/vbAM/jX yVDKJRnzc9n5f5n0c8LK3vWsf0C/sh/C39m7wBr/AIjsdP0fwyfHk94HVdQK3UlrDsXbHE0pYjOS x5yc9cV9CfH79kX4QftE/Cqbw14lsbrQC0yzwahoJjgljlUEK2CpVupyMc561/MT4V+O3xJ+Etlp OseHd8kdxMztPcTF/tG1jkHPII9TX2R4U/4KR/GSdbe2shdR3rAf6IbV5S59RtU5FfU0lWowipR5 l0fX5ni1KNGtUahW5JbNPZry8vI2/Gv/AARs+Mdt8RbmHwJ8QvA2t+Fi/wDo11q8s1pdKp7SRpE6 5Hqrc+g6V4F40+Fevfs9+Obj4SeJdS0nU9b0OONbm5013a3cyKJRtLqrdHA5Uc1+1f7M3xV/am+M uiaV4xvLX4cWHgqK8a11K21GSaPUJApUsVREOx8HjfgHOa/Kr9vK7nb/AIKgfEozW7Wcm60/ds4Y 4+yxYOQcc16VKq5WbVjxcXRVJuPMn6Hze+tHzCQ/SnRa+yzBt/61wEl0VYZI3fWovtZAByc/WuxS PLZ9PfDPS/HXxO+Itt4S8BaFdeIdcljaT7Pb4GyNcbpHYkBVGQMk45HrXo3xw8FeKvgL8U7Lwj4p vdOu9Rn0yG+DWr5ChwQVIznhgw5xnGcDNfNvwj+OHj74I/FNvGPw81SDTNaezks5WntknjlhcqSr I3B5VWHoVFJ8UvjX8QvjL8QYvFHxE8QS69rEdsttC5iSJIolJIREQBVGSSeOSa6VUioGTSudOfHU +eGGaePHFwwHzAfj1rw4XrbuCatw3oVhvfA9zXPKdx6H2p8LfivaeHopZr/T9UjnkuA0Or6Nq0lr eQDGCm1t0M0fcpInPrg16ZrvwU8WeOPFk3jbUNI0Xw94M8q3e3u7Lw5PZyaujhneZrZAwjdBgSMg CdCoIOTxPgLxn8Ifhr+z/wCCfEE7W/xH+JKS/brXRpdGxYaZLvk/d3c6589SPLcRnBDD7wGQfOfj T8ePHPxf+LNt4t8S6qkOpW0fk6bbWcZSCwjzkJFHyOpyS24k9yMAY4rB1qlBqnVUH3sm/u1381Y6 KVSKkuZXR7Lon7Ovwf8Aij8AfF9u+o/FPxb47sYBLa2Gi+H7jS45mjZy0dt9tjAumAA3cglTlUr8 UNasb/TfEGp2OoaXeabdQXDLNDd27RSwnP3XUgFT7GvtPWvEnxBnhdLbxv4+nvZAzQpHrlxCqOf4 vlcflXeahfXn7TPwn07wv8XGsfC/jfw7ZgQ/EARSyQ3hDqkaXyIN0YYNsMq5UMFbaCXLeNSji8NP nqvnTaT1WmtrpKKW71122vaz3lKlU0jpv0/4LPzhgtUvUlRJgl0qgwwbeZfUA56j0711ul6/4j07 wxb3MH2AafEZLeMNZQlsvG0bgnbuJ2scZPB56ivVvGv7MfxJ8DeM7fSdc0K4t3uFWTT7qJxLb30Z +7LbyoSssZ7MpP4Hivqn9m/4GfCL/hY934l+M3jj+1f7Ptm+1aba20Mumw3Eytb26XlxMwjM7yPl EQEfuyzuoBr0cfiY4ahKrLZfj2XzehOEpKvWjTva737eZ80fDT4QfEjxd8A9X+I/gfX4bXUNG1IW S6aLsxyzReXv3Ku0qw3ZBDHn0rzvxdN45vfEVrpnjdzb3c6Mbe3Uxq0TjgZRem48cnvn2r7I0LwZ 4N8Ha5rPhjwR+07P8PdQkuHF74b8e+DrvSLq3lPO0SxLcQkgcBgQpHI4xXHXf7IWteJfFDalqfxy +CouLycMLmTxV58sxY8Hy0Qvk8YAGfau7mhKCaMZRcZcrWp88+JLrWfh/wCDdN8A6VdHR9Vv9Phv vE7xOYrq6knUSR27vwREkbJ+7B5YsWB4wz4bfDjQfE1nr914v1fUfDdraW263lt9NeeRps5GQF+7 jnINfb3xL+EXw4tf2gviLdePfjH8L5fCZdIAmmaXfaprdvLFaxW2IYljRdwaLPzyBR69a4r4Zf8A DN2keKn0fw/o/wC0l4suLhdttYarqNnpltqLHjpbLJKoYAnaDnH8Qrhy+m40YysnKVm/V7667dPk juzOpGpWlDmajHSOl7W20ut+r3u29Wc58BvAXxc+IXw8vUvUOm+E9KvIQvirxTOLOz022YMZVNzM NxQ/K6xISSw+UHJr1jxr440m/wDFVpo/gPUbzTvD3hK587Sri5mYXl9HBiNL4SNxuYAYhCpt3ADc STWl8QbTx/8AEe4s9K8Q6L4f0XwpaPu0bQoNYFtFZMQFYmMSNNLKQozLKrOcHntXmniX4KfFWx8K CwsPA2tT+G55gzz6TBNeSXLqAQHdkDKq8ELgKevJ6duGoeyi792/6/re7PHx+Kq15L2aadkruz26 /otOiWyMjWvGN14q8e6jql5a6dZalOUW405NMQCEpGsagh1JBwgzjgHPArZ1Xw5p2q+Hx4yvf+JW 0NpA7ajaQEz+ez/Z/KKgqqjK53ArhccHNeut4e1Lwvc2nhXxf4F8Q+M9XbSbeW41WW2jmntmeBXM XlBAz+UCEwz5yh5HblfD7Xmr6Be6JdJa+Jfh3czq040PSv8Aiao4dfL2xIPMjKMAW3IynbjceKnF OUY8yf8AXl5ns8N4ahXxH1apT+JXTbsuaKbTk7p8u9+ttTxzTxLpUt5FHczalot5G0V7E0KMzjOQ 24gvuUjI+bHHoa8y17wmh1edJ7S3vLdsmC5RgqsvqVC8474PFe6+JDe+GvHGoeF9O0LSxJay7kuG ha5edSAQQWx68rtGCCKvaJYan4kGo6dq2g2GlSvYTTW99DB5eySONnBkQ/KVO3aflyAeOa5ozqW5 7ev+Z7dXB4SdZ4N1PeTfLZS0fWPvWbTe17Wd31Z4z4x8K/2f4lufCWi3ep6bp2lzm2tobe7FtGzj hp32nLO55y3PIA4Aro/CUvxh8PaOPD8PxA8UeHPDsjMzx2V66ykSBQx8wknkKPu44+pr0Sy8Fx3D re6tcy6hfkLvKLsUbQFUfgoA966uPS3hs4lhYx+W5YRyO0iMCckEMeM+2D711UqCUFda9Tw8yzip UxdSdGpJQu+XpaN9FZPSy6LY5e08HaRMY5Jr/wAT6zdsflubvUJHYf7Q5xn614td/A3xb8Yvj344 tPCPiLwtdaro1tb+XY6/4ihsru9Hl7fKg84qJHUL93dnkAZJxX0LrF3qFhp7vb2MYuCP3Tx3W7fg 527GQYz0+8TXC6b4803SfGc+v2/h/TdB1wmNodU1HTY76MlTnbNC3yMvbcDkDPXpWVZezfuwv6WO 7LIf2hBrE4xR12k5O7to1py36Xk4pdWfC1/oWr6VqFza6np15Y3NvI0c0c0RVkYHBBBrHbIY1+yd z8cvhd420C0tP2hPgXpNxbXCYg8Y+AHVlI7sbZjxjglEaPHp0ri7/wDY2+CPxhikvf2d/i94f1i+ cZXQdSlNpfK39zyptrlvZTJWqipK6Z5FelUozcJxs0fk93FLmvp34lfsl/GX4aalcx614T1Iww53 SRxFsD1IHIHuQBXCeA/hK3izxfpljq3iGw8OWc7ypdyTL++tioO0iNivm5YoMISQGyRUzjyQc5aJ atvZdP1MlK7S7nmvh6yXUvHmi6fIGMdzfRROBwcM4B/Q190+Kf2V9Gu0LeFfE99YyIxZLfUlE0f0 3Lgj64NeQaT8Hrj4f/th/Cuw1jU7LXtH1LxBCEewdoZmRJF3bldTsbBGOGH1r9Uda8AeHb+NtQ8O ePZdMlVmP9ma3Z+VPJjsNu4H8Sp5GQM104OmqsHJO6IruUZJH5I+MvgX8R9B0aPGhSa3DExJm0s+ eMeu3AYfiK7z9lVtHsvit4l0bxbFfaaJdPXyyUaOWGRZV67sBRgnJYV9XeLfHFz4B8X6b9l8SeGr /WGbyotFe3W7a7LEYDRYzGw7PkAdwRXrHiH4m6lq2naZPoPwh8I+FtWht/LudR/tWBpJ1wNyny7Q fKSM4PXpXLmGAdajOknZs7ssx31XFQrSV7HxbqX7Nuu6X8Fbbx1LrVjqmkyKjummgkoj9GJbAIB4 PpXD2ng3Qo1Xfb/aZgcjzZCf0GBXuPiXWfFXh1tV+H93bHR4LCR7aWxa4kk2nPzYycYJ5GBXngs2 iBln82NmHCupyfw96+CpYuty+8z9Fjh+bV6n13+w/wDs/eCfi5+1nbX2qNoGpReG1ivn8P6xGZra 4gDlHKw42uwJ/iOBwa/Z74jfsu+DviJqOm3ct+3huaxtPssS6PpsEEZjByilQvReQMYwDX83Pwy+ PHiv4GftOWvj3wI9m2sWVo8Jtb+JmgnjkXaySIrKSOc9RgqD2r7ftv8AgoT+09rvgZNal8UfDvw9 aMpdv7L8N+bMg9D5zuM/QGvtsJd0opvp1Pz/AB0/9om49z9Z/g18BNS+CPjrV7zTvG8mt+F9ThC3 mm3Fh5bLKp/dzBg5G4AlTxyCP7or8Of+CgDAf8FS/iW27ndaDH/bpFWl4n/b3+N1/oc0DfELxjcv ICHa1soLIEexjRcCvjr4h+KPHXxb8bXvjrV9d/ta+ukiivLmaIfaCYo1iXfjqdqDLY56nrW7jY4Z Xauci8mSckH+lU5b+0hGZZ4k47sBWLLod/8Afku3nP8AEDLt/QV2Fh8H/G134QsfEUPh7ztIu5CL d/PTzrhVbDsked7KCCCwGM07MxXkc8dds2YrbrPdSBSxEUZbgdTVJ/EVwzbYLPYfWVuP0r7q+BHi j4eeGvDk+la0ltYXC3MypBDZQC7IeMJKjyuhkCMpA2g4PPGa8M+Iuh/DnQviT4g0y38OXtpDen7Z pEklxcQzQRyNhEEPlETINp2n5MnPzHjG/s3y3uJroeBG/wBUmYg3CQ56CJM/qafsJ+a8urqc/wB3 zCAPyp8ESSaubK3WRpiT5asuGkUfxAeldPZ+GdSvHWPy1jB9axsTsdl4Z168l8NrZ72RYlxGT2Ha tS4mvxdq9xK3klgWkHJHpXSfDn4L+PPGPi+30Xwjomp+INSlICwWcJcqPU9lX3OBX2XafAL4WfB6 Jrz49eMV8S+IowHTwJ4PulllJ6hLq7P7uLnghctg8HvSk1FXkOMZN6HxNHqcUcJMDiRRwHA798+/ 413ngGa91fwx8S/CGmq1z4i17Qoo9KSWRIg7xXcM0kas5ALmNH2qPmJGBzX1hB+05FptlNpvhf4H fB7RvAUKFF8OahpVvcLIf78kxfz5JD3YflXJ+C/FX7LP7Q2oa1aeJPgT48+D2o6bYm51XxB4X1lR o8Y3rGD5NyynBd1AVRnntg15+JjHF0nTi7NNO9tLxaavtdXWquro6o0ZUpKTR5LYaF8Z9I+Hz+Et b+Itn8OvAUrmS5t/EOqxhY2/jMNvh5wzc58oDOcHrXlnxN1Hwvqnwss/hj4KttY/4RaK4+3aprl3 CYZtcuwu1ZnhTJihjUssUeS2HZj8zYH2LN+w54Z1/Wba0+DnxS0jxq144kGj3jTWOoLHtL+YEc7C uAF3htpzwTmvnbx/4K8R/CP4nTeCPEXhmDQPEESKzxTyJfTlGyVbcu5MHHYAj1rqo5VOo41cXWTS d0kml62vJtro20r7arTGpVUVaCt/XyPCPCvjTxqmh2Wjaw+jeM/D9tH5VhbeILBLuSNF/gjlcecg GPuh8D0Fer2XjGTTru0vvDPgTwnoevxfNDqcGnSySWrdnjErsisOx28HBFZFrc+K0uSEu7q2TONq hV4Ppxmrhk12BjeXN3qFwBkKs95Iy8+wNdLy3Ltd7PsrJ+qUrfeaf2tibL3ttm7Nr0bV18jBtdKm urhk1Cf7E11ON+oakzNHEzNzKwAJYcknuea6z/hBdP8AD3iPQte0/wCOngdPElxGblGsS2bcZKYc rCQhOCNpHTtg1ct5tZuI0CxSBGwWMkvmRkehV8j9K15LLQXtlfUrS30uc8NdxJutc/7Y+9H/ALw3 L67R07lh6c9Kctez0+7p+R5/Pvc3/Dt88Gjz6Xqlv4dv7B7j7U+p+GPGkel3MrgBSZIvOjEi4Gdh VRnJ7mt7/hG/hjqnhnxHp/8Awll/pup6rBCjy3l21/5CRyiUsRGGQHKIuVmY7WYAHmuDn0a1S5Ky WMDTLgEyqH4/kRjuK04IsW6gKsag/wCrVcL+ArBwlFtPSw1VNSHVfhQvxX1/xjrOsxeIvF8mum6h 0ix067kt/Nd97yqTsLqD9yIsFXPzNgAGpr+rW2oeIJr3R/D7WUwne4tzdXbwxxyMxZpBbW2wFyWJ /ezS9agEMcbmVYIkY9WCgZ/Gl34bfhME460nFNalQrzhJSg7NHOW2p+JbO1t7GeCx1aOF3J326xK 25ixJZcOvJJ4JHJrqZtR0n/hHPLt1bRpZ4tuoyAi6MoznYrnZtTIBxsycDJOKjBjYsWAY9T8tPIh ADLGgOcrlRmsHhoP4dPy+7Y9ujxLi439oozbTV5L3rPR++rT20+LRabMXTJ9HuQQseuSQIoCutqq B/ozsM/UA1LNdQIxVNBZl5w0mtYb9LfA/WoxcBoiVPPcio2dXB3fLk4z3Naql3b/AK9DklmkUrU6 EI/Jy/8AS3L8DF1WTTrvTXW7tdSsZM5AjkjuUz0+8fLP/jteU3VtpVvdS/6XqZjOSQdPDBj+D/0r 2G5gSaIodrHpgiuPvtCySY5MEE4XtT9m39p/h/kVTzKkviw8G/8At9flJL8DjPD1pp97rMulaPNc 2N3fHy4Y3jURzydlIGQrk8BhyCeawp/Dt3qN80mmw2Wq6jGSAsSmC+gI7YjKliD35H0roZbO90nx RaahGFjnWVXhlTgpIpBU/mK3/Ftjp0/jq61O0hiistS/021UAYG/76fVH3L+APesVTnGpZS3/T7j 3o4zD4rLb1KP8N/ZbTUZbWvzaKV7preStZtt9R4L/aN/ab8EW9p4fR9X8X+HITtbQvGlidSgI9IZ WjEkY9lbI7Gq/jD4hN4o+OVn4p8R/Cf4OeF9Dhtd9xomt7rm3mkZcSNtD+ed/JGcFcD5gQK4dUmn U2vn6hLaYwUeZtn0xmsmfw5pBj2tYQsn8SgHH5ZroVOptzWTPNhiMshr7OU35ySX4RbfyaOZ8Q+N vAeg/tkaZ4h0bRdc0uw0SZLjT/DGl6hNcWNrP5YDiGaaSSVUdvmC5+QHAzivX9X8QfEn4w6HcyeB tWHg2xhTN9okcOy9kQ9ZEuCT5gHUj5XAOdpwTXNaJYWNpqaGO3szDuBeN4VZT9eM17TZy29tqFrc 6ehs5YWV4fs4+VT1HFTKiqLkqLajd2Tt+NkvwSFHNqNZqNahFR/up3Xmm22/STa/M8y8IfBbQtFn TUdZll1LUWO538xixb1ZzyT+Ve6R4itlhjQ+WBhRnIHtU2vqlt4xvRax+XbttcwjpGzIGdP+AsSP wrNF5t5EZUEcqx6U6clKKa6nm47Czw2JqUZu7g2vudj530nxxqlz4za51m/mvbi+kH2i8uPnmJxg Eu2W+tes/D3U9LHxP1zwp42W3ubDWrQw2+oXIDPbnB24kI4Uj8iBXzZZ6Tqt/rcdtpkdqZChYtM3 Tjt602S21S4vH/tbUrmdkk8to9+No9MdhX5pPC05O7klf7z9tnN/2Xyywzu5e7U0S2XNFvrbRrtr 3OE8Zomm/GXX9Pt7lb6K1u5IUuEPyzBSQGH1xmum8Ma6ml3ZtL0NJplwDG67sYz0P4ZrynWboReP 9V2DCpM6ovsCRXQ+Z52i20oON0YwCO4r7eMeSMT8dqy5pyb6s+jpfG1vp2lCyudO1TU7uJMRyW1r vjnT+Fi5IUHscnqDXnV7qV9qXip9Rj02PRbZ4Qs8PnCRpSCcNhRgHnHXoKy/C2sHU449JuZHEo4j Axl/bHevQtQ8MGJYLNLqAajeyLFFbiUAwhgfnkbogABPUk44FdNNJnM3LY5DTbia21vw9r2paNeJ 4dvNSNuLoW+VnZRnYNw25IxnByBXpnxJ+MGpaV8JJrbwzY3XhC5iuI4ZZBAsJlQqeI8ZLEEAk54y elbfx51208QfAnwv4W0kadBY6LdobWC2ZS0f7gxs2V67iNx9Sc18Cai7rbsbiW6mmViAZZCwUegB re/KrEOPdHfeALvxprHxB1DWdG8Yah4ZbYF1TVI7to5TGzBiMg5YkoCAO4Fe0v8ADuTS/GuneM/C njLxTreovLlLm9h85hLjlXkLZB5zkjHNeCfDLVGtNTkjmmEOkxRO94AOXz/DntkDk+mfU19AN+0N pXhTRr7TLHSbfVLW4sykUMK+VJZOQCrNIcqHVgcoEYEHlgciiEorc0VO6u3ZFLSUm1TxT4Y07SrP zNUtZSNTbaMQ7gyeUT0LEkcdsZr9aPBH7Eo8K/BtviR8S49V8Z26KZE8J+BSlzPIcZImuQdiKMfN sDEepr8X9F+KuoeIviNaG3mudA1ZpA8NzayhN7qp+YkAAP0O72Ne+W3xj+MXgjRWsPh94zlg1aWV W1K6gXEd0oKuIniOYpVyBueRCW6AY6pyuYckU22ffPjD4va3Z+Ej4N0TUvC37Ovg9ov3XhjR7O4n v7tSPle8ukTJJ75fPPKnrXyVoj61q3jW8s9Ea7uNdihkltDaKZGldRnaOOSwzj1OPWvozwp+2V8T fiz4DfQ/jP8AAHwT458MQRQQS+KbO3Syu7eUBPtCw+blDIFD7ShUAlc9QD5t8V7b4Y/21Y+IPhrp HjbwLZXN2biFnu0lgtTx5MYHMhbIDbi23J2gcBjhVw8ptNHVSqxijymT4ma3Lq39leKtBsPFbpJ5 L22p2bJeo33dizR7ZlYHopJGeqmvs34Z/s3eR4euvF3j7Vrv4WfD7xRoklnPoWutnW2fzBIn2WLa DOP3QcHaGxkbTjJ0/h/8SvCHhr7F48HgQeIvizdRvBfeINatYry50w4/d3MFuHAlwMgjc0gAHzY+ U8L8V7H44al47+FPivStS1n4z+LYdWe61DUNVtxAunQXkylHWOMbIbZIoUBAClSTuGSczTwji7yH LEXVkdboXxm0/S1lX4N+Fpvgb8E/DYay1Dx/4l1AnWvEFxc4SOCOLcBEXwX5ZfLC7vkxg/M2s+Bd F1H4hatb6P42tv8AhKp7x5P7F8U6yYLyQ9dvmzovmScjChmB4w3IB7b46+E9FuPAHhv4c+JYfFeg +C/Dks+uNrFrNGkOtXdzIw8hrdofmeKIBAokG0EZYE1jr4U0D4lfBHSrG81yHU9Q0NY10TxKkZjZ IIyClrqkf+si2gBUuBkKPlLMMEdqb5UuxyyjzM8zTQ9Sspov7Z0/UtKmkQnybqNo244PXqPpxVlY xbRoLeBQB2PJ575NffXjmx8DXP7J0fxE0/X9UvpxqUsnifwyYbRpdJR8tFhAgQQx4wZZPMWTcGDD OR8ovY+GPEGlre6bNZWul3TBdK1+2fGlXkh58i4DsWs5iOm4mNiOCAQ1EWjnnSaPNkQtIHdyzoe/ cfStK2he5uUtbePzZZWCxxpyWJ7VFqWn3emapdWV9Z3NndW7bJYJkKujdwQf881o6Jq+kafpHiU3 lle3OrXGjSQaJNBsEdvcsQN0uSCF255X5gexzXTQjTlViqjtG+r8jCxlxXdu8r2diyzWVh/o6TqP llbczNs/2FLbQe+30xUrzrGu5wBk9R0qhYRRWenQWiqqxRxhc9fxquDBIkyZlcZJ2OOPzp4qv7aq 52t/VgWhpCUu2zzNhK5ODnFQyLI8RXzdmTz8vNQQsHgZSiRyLztB49uabcalawq2Q93L/chyeaws PqXQfKtgAzvgE52ZBp6yljjY3/Aj2rJW6mbTYXVREGfC+Ycn3BHf61faEqCd7OR75Bp2BoZIlw8j AmOOMfdVDgke9MblVSJv3mMoSc5HepodxXEjeY4GRtGMD0qEMXgLAyQMXxs4B+vuKEgYNC7PhpJV I5ABypqU8hVUDr82eoFV2ZHURTzOuTnbnlqV4yLcNEeSeSw/rVWFcrajp0F5p0iCIFiMqT2PbpXM r9usnjtrjTV1TT2fdLbuvzI2MB43H3W9wee4OMV277vKUBsehHaqq3B+0mM7g2MhhyDUygmrM68L i6uHnzU3Z/emuzT0a8mcLu0iScx+dremyk/cvNPkkQDv+8iDE/8AfFXTp1oUJXW9GI/25XjP5OgN dZLbxzod67vfpWVPpiuxVQqoBwuOT9TU8k+kvwPTjmWDl/Ewyv3jKS/NyX3JIz7LS9KjlEl14n8P WQ4yfMklf/vlIzmu/wBN1vQ9MgjTQJLjVLpCD9uu4hDHEfWJMkk+hJ/AVwi2cqBT5Tg90PI/OtWy WNWxLDHwfTrUulJr3pX8i1nFKi+bDUVGXSTbk16X91Ps+W63TTOra8WaJp4pnupixMh5JJPUn3pz vJuR1eMqRzv7VUSWMWxMaJEvcAYFRNdL5R2YmP8AssP51aitkeLKbcrtnzpDHremxw6o1pfQxxSo fMm+RXb0x6EA1ja1q93qHiSa507SpLVnI3h5ANzdM+pz+VfQ97oVpqujSRvM94Xj3xSTSl8HGQQO mK8Ov1WAXQki2SwoxkI656f0FfmWGq+97yTZ/V/GXB2c8O5fSoV6qdGq+b3dVzJW3aunZ9N16HzL qU/m+I75ycuZmz+ddfYys/hm35yUOD9K83uH8y9mkduWc/zruNCm8zRpkByoAxxX3jXun8wJtyue y/A2D4fz/tGaZ/wtDxjF4E8Fqkjahqn2Z5ptoXPlwqitiR/uhiMLnJ6V+2Hwvvv2J9c/ai8MWnha 4+Eh8C+HPBXnPNe30byajqN9K0Q89rna8rRQQuWGPla4HHSv5xvEN0UvRDvIwmSPXOa2PBuuNo/i VJ1CyRvGqyIeh4/+vVRslrsaOolFqx/U/wDFn9nv9mzxF8BrvSPDem+HfDya45ht7zwrpq3ryTdU YNEc/KfmALAHBAB6V+EH7S37NngT4B69f6HB8V9L+JPxAhceb4estCmhjslliEiy3ErnaGCspES5 bJ+bGCK5eCU3VjbXtpd3FuSwkja2mMZH0I6UrWTyzzXM0k13dzNumnuHMryH1LHr+Naxp04xtBWP Pi1G9lY+QrGS/wBJh1OJoIGW7jVJC45iIcMHX0PBH0JrISxa4aV3uI12n5vmyTX1LqHw/ttW1LzZ bmO0jYEyJEoJP07Cr+m/D3wvpW6SOxbUpRzvnG8g+w6CmqbZbqo+dfBuipP4z0+6vba7k0uGdTcN EShK9lDfw7ume1fa1hB8OotCe+t7rxSkSLzpt1Fa2xAx13rJI7r7iIA9cisOWwgTS4o44IEgUb2j KDaR6ECufubF7YC5traGxhDqZQhKoyAjOQB0I44FXGNiee7Mnxf8V/EPgP41alH4Ykn0nw7NHCw0 S7jeSBcwplvn+dGk5fIP8XIr2/wv8efh14z8IJo3iGVfCF7FD/x7353QuoXkpJjDD2IB+teYePb7 4Z+N/EfiTxPqN94ls3vrtriKCHSVkdNwzsWQyBGVfujocAcDpXJnRvhvbaTp5vLbxlrWnxqQ8I1e yhQMeSNotnZB7569DxVRqSizRxTVme2eFfirbeLfjJa+DvCeryaX4YtEku9c8T3luZbaxsYRukkC sN3IG1ckZdlGDmt/wZ8VvE3if9oD4neOobyKK7/sTU7nQYbYlktreNFht4g4ILBYtoIODkZ4r5uf Ubf/AIQ+98P6boEvhbwLOyS3llo16Wu9TdTmP7RcSruZF6hcFQeQvp6p8G5rOxt/GeuRRSW9tZ+F m8+1fZtCPdwR4JJLMdpPJwOSMDiiU5S3BJJ6Hmfx++LHxIX9qPxPb6jreqxRRiGEw3a+ahZYUDsu 8E4Zgxz36mub8K/tEeK9C1aK9WK1a7RcefZStayn05XIH4DmvffHPiHTrzxt4w0rxx4Gj1XSv7Xn l0fUreOWe7uraWRpY5In2EPGVb5SG44GOK8u1T4BaDq2krr+mPrfw+0j70svjiOPTIwvrEXYPL9E RjSlCy0Y1J9j6I+B3xvtfGfjfU38S3C6XdWNjKdTfTVMEBtZHVPtUfl4ZJ7eRoncJtSaIyArkZb1 DU/iVY+EPGEuhyfD2zvJLeyWDW2t5khg1RWyySoFXyJoZEKuCYhg8jBr408M+Fra10XWfC/w107X deF2qQ6140nszbwiIMH+z2sGS7RsVUtISGbAG0DOfpeTwV4itP2OvCmseIrwX01trVxYabfwMS8l l5ayeW+RkLFKXAz08xh2pxiyKknY9Ol+K3wG8U/CL+xb3SPGPg3xFp8LR6M93aPcNk5KW/nBmWSA H5RuIMYIxgDFeQRCORN8WVBH3Wrh4Ntw0lparLMrblaaRfkUHg4Hc12dsfJmdfmcABQxHHH9apaH NJ3dyyWVZdodVBA4b/CmymMllBUORgOeM1WnurWSTbu3OByR0+hqKVpPLAYsilvlAAb/ADzT0JsU 1gaDUJTNJNsK8KzZXOc1pQCNYQ1q5CZ5HQGstoJpQPPIYLknD98+lXPMH2JQFZMDknjn3GapCNAI gQO8K5zkAcAn1+tMaR942syoOV2rnIqokrvKIYs4APLnB/CpmlQCOOTLuw5PehMC2kqjMiAO38W3 g0oEE8xcoyzKOCwIIFUwzBepY+hPPNKCfOR3aXOMEdcU0IsyRlODGrIpBVsjNO2qjh9wLHqTyaar 8AkkbhjpzTj5gl3MEMY7ryaoeiJVKtGcDB7A9qY204To2Pwqo0qRKRGNwzg85571XM/mKrKTCA23 BHWjWwFtpjDIRvwCPk3Hge2aaJmETliWJPJ7CoJZonKLKGyemP60xYlRiGdip6qTxRzMLl9mxCux VnPRucEUipG6ZYMDj0x+tU18uIM+WTdgEjv6U+WQhItjlc4JGOv4VNxovkDf8gGO59KhZUQOQqxk nlh1/CqnnLgnkEnk9DTHmjPc7evPepH1Oi+H+hp4r07Vm07WLDT9B067ZEvNSm2y+SSTGxjHAJXr 83BB9K8v+K2i6HpevXkPhzxXZa8s1puuruCIBI5ckMuRkY6dz1qO08R6YtlJbw3V09uSFUWoZ1Ho NiZUj8MVn+JPDF9P4WTxFFYzxWMyssjNbPCr84DbWAAB5Bx3FfF4jhythLVvacyXS39XP3XFeJ+Y 55h6eXYqo/ZwVoJ2srKyvZJ3t1bZ8M3TbZCp4+fkV0ugSkBlztDDoO9cvqqmPW54jxsmZcfQ1s6L LsukxwMivo07xPxzaRl+IhIfE8i8tlV24p2iyBb4xysPMDj5c9QBg1Y1yVh4gk2tyIeAe3B5FYNg GOrxMCBj5iTT6BJO56x4Z8b3cMhsprkwxm5Cru+ZVU9gK+krO8jfTYkL792CMNx09a+Ht5hghkHD m43A/Q19FfDzxIt5pn9nXJDXMX+qZjwR6VtTdjCcdND2BigQkKgxg8HJP1pq3DNEQiAODnA7/wCc 0wBBHudlIbrmmyXG2cAqAuPvg81t0MbXLW5riJVhQN6oeCDUD28wuSMyt8oPLAKPUDNSW0oMkrg7 EH3SPzzVuUK0OfMOCOCP4vTijzCxz174T06/06SGWKJIps+agXrzwcjGSPese38Cw2lwi21yz7cb BcEuE+mc4/DFdfGoRwJJWYHI4OCfrV1mhSzkbhQO789qduo7nLDwu3mbZxPdYbIAuNqA444GOa6T wXpWlaa3irw7qGoW2nWniXR20+O5uLny4o5vNjmjR5DwgZ4gu48AtyQMmkiuGaQq6ADHyuD+tWxD FdRgyiKTqNpAwfrRyoFJp6nNw/DH9ojRr1tF8I6n8R/CujHLrbWury21oi55k3bwgX1bIB9awG+G Hgzw/rjXfxA1vWvin4kkVnks9NviLSN/SW8fc8vuIwB6P3rsb7Q9NuYI1mtcRxjiPcQijPYA4qk2 hFYIhbs8a5ySJCeCemDmp9n3L9p2Mez+PGt/DXw7/Zvgf4Z/DTwZqcEzTwan/ZbX0gi242BrppHM hOMfNt68CmX37SvjjWtP1nw5q66rdePLp2tp9UuL5Hi06InE0dvEihIyehI6c+tbc/he3v7OWK4l EhAxukhUsB7HtUekfD/w7pN7HfpEk8ynJCqAueuTjmnHmT0YSqJrU77RJZp9LtnEIhGwfKwwx4H6 1shkO5pGHbOwYx75rGilWOBU3gYPROTzVtZljUfuyR09MnFWjn0RNLJA0/leUXXbktj9alWU4MYB RepJ+Yj6GscXnmxyABo4zJtQhcY+tXkmKqrMfn4yegP+FFrBY0EMMdmwRpHGc/N1Nc+9+Lm6kWKL IU7CpOCeM7gfatX7QDC+2RipzkEZ/DNZkkOn3DpJGjJKo3JtfDAj0q0LqaUU0jQZkVsjgDPJ96aJ swlgiZjJySTnPqKzHnPmrvOOdoJOCBTHluBer5It2bZliDk4pXsgsbcVxCFIZgrAg7s4U/Wr3mqF +6eR0B4NYa7TBndHlRn73PrQhkLfIq7UxtCnkH+tCYWNoOVQFoyuecE9M02abyrZymHO7lS2Kz4b p2YBwSw4YbelPmlDIQqh2x8g4GfbmncLEnnotyGJCswzndSuXe3cI4yR1xz+VU441VmLbvmO7a2M DnoKfM7r+8RkYYwFDYIFMRZDMYUFx5fmIPvKM7h9ai8xzK6BS0Y/jY5x7GoDvaFf32AwwQF5pjCU WpRAFxjDIMn6kUmxliOc5MRwQO/Y08zKsgxksOoxyPesyNgoLF0dw3y44ApGlZI1JBwX65z/ACpM Ea/n5Q72DHpn0qo6J5p3u0i44T3qg10FtGZiAFPeuC1/xhb6essdu+6UgAYbpzUN+ZcYts6vRLm2 m8ONDFBBbLEwLLCgUbejZ/Ak/hX0p8P7a08X/BfxJ4E1gsqxlgh3fMm7+Ie4bn8a+TPCEitPKjZE bAqQB2IxXs3hHxLL4e+IWnarI6pDexeVc+m9G8ts+/yq3416Fe0oandSbjNH5yfEjwzf+EPjJrnh 7Uo2W5tLt13Ef6xc/K49iMGsLTXxOOufWvu79sv4ei/s9L+JOkwq21BDqJQdVOCjH6ZxXwXYHEq5 NeJOPLoDT5ncs68n/E3klZk2mAYBPJ4pJJFbVUVJIpFjWT7hBxl8DOOOmK1teMT+EdPlTSljnMpR 743BYzdMJs6KBzzjJzz2rmrcSNcs5j8tT8qYGAeeaVrdbmspPqrev5/MhvWwIU/uj+ua6HStRm0/ VYLiF2R1fOQcVzV82btz2B4q9G/zRn1ANCZgj640LVY9c8PpdI6E7cNjqprZSIiMSFnd+4bvXzj4 K8QtpWtiCeT/AEaU4OTwCa+iEvIpIVkSXg4IC98961jPQxcbFyRliUbWCZ65GAKthmd1DqcAcZPF Zf2hXkYkDK9QRkGpfP8AMVAJdwIztDc4q0ybF55FQYbDdgOOKj85JI2VyxUjpnGKyxOpJ8xAXUjA J6CrjSIttGHYrnqOlNyQrFi3mwrmFR8vA39s0ln9oN4WkkjMOc/IMYPcYqOKbMByqbj1XPI96khc SIuUDFCenf3ougsa+JAcb1dQemKnRsfxBcDjA5qnHMjOcRhSTyfXFOWX/SdyHK7fm4pppisXYxzt AYDOWB6gU6B9lwSdpQr2681WduQwJPAzj17Gms0n2c7wQDwM9BTuFtDT3x+dkooB53dKe8qpErbQ /wA2Qc8e1YztMNzb1BK8Z69OlMSWWWRd8qqmdpG3nP49KaetwaN4SsT85ycjKse9NMoMzb2cRBcH dyuarB4xaoCGLZxkn9ajkkKBsKGYcHBwT36UXJsXPNhljWKFlGDlhEcfiacqlMBpPNOfkaQ8gema qWVxDPO4hLEHqCuPwxVsSOVPKZDZUY5FUr2E0XRMTGwaISyemen41XeHDea0aKSCATgH6Cog5RWk YZBPGO1TrfI8BkXcwU8oRkA0XFbQpQNv1CWKWNWUDIzwfx7GtRI1TcQfl42kHtUaSedH50Z3+tQP Kuw5PlHOWx/nii9w3LIaTftZgQRlGIx+FNMcpXeMEAcA89v0qsl2G3p5gYjrgA4BqTLhBtIU59c0 nIYpnZViXAWTB+Tg7vpUyyAQYK+WegOKrSTxKuHAWUDPzD9aghuGCMgLYPbGaHIb2NU248sG5lRy rZURHnHoagubttuI9sYHUAZ4+tZ0t15cmCNw7LmqEt6sRJlQqNpPzdMUX0JSL+9XPnB1VcY56E1j 3+uwWEEhmYbwcccHNcjrvjG2gtWt4W8xiOMdBXjupeILi5kbfMzc4HPaplUSZtCk2zuvEHji4nVo rctGp6jNeXXV9LO5aRycmqEtw8jHcfzNQ/M7BicJ9a55Tu7nVGCR/9k= --Apple-Mail=_66DE6087-7889-475A-B4EF-65BD6DEB7092 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The implementations are based on these = drafts:


The IPSO folks have been nice enough to offer = them a corner of a table to work on, and I suspect that's where you will = be able to find them during the week when they are not doing other = things. They have also been generously offered a corner of a table at = bits-n-bites in case you miss them during the week and want to look at = what they have over food and beer. 

I've = been cc'd on some of the emails between Jari and Markus, and believe = they will have a presentation ready showing what they hope to have = working, not working, etc. by the time we meet next week if not = before. My understanding is that Jari and Markus both consider = their work "Experimental" at this stage, and the aim is simply to learn = as much as possible this week. Assuming they get things up and running, = please come by with every kind of IPv6-enabled device you can think of = to plug into their network. Try your best to break it, and capture what = happened when the breakage occurred. If you're really bored, hack up = your own implementation and plug in = ;-)

Organization of this has all been very last = minute and informal thus far. For future IETFs, the ADs have offered to = work with homenet to have our own space rather than having to camp out = with others. So - if you have some running code, let us know and we'll = make sure we have some place for you to work = together. 

See "y'all" in Georgia next = week,

- = Mark





= --Apple-Mail=_66DE6087-7889-475A-B4EF-65BD6DEB7092-- --Apple-Mail=_4136DD2A-99F4-4D89-8647-900F34B5B31C-- From Ray.Bellis@nominet.org.uk Tue Nov 6 09:36:50 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC6A21F887F for ; Tue, 6 Nov 2012 09:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwh9CueZr7Kw for ; Tue, 6 Nov 2012 09:36:49 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 58C3021F8738 for ; Tue, 6 Nov 2012 09:36:49 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=dJug+GHG47S96isQv5ZSWRYWMgd+tsaCHlJ55Av3MBKltPSn0oR/00YE XHCRjJR2Nfou5N2aNzaZwrOxeKa9bc1cAALqnl7TXS/OAsiGE633VDymX 9ACgNz9eoeqoLIa; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352223409; x=1383759409; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Session=20preparation|Date:=20Tue,=206=20Nov =202012=2017:36:47=20+0000|Message-ID:=20<919D9AA5-5760-4 DCD-986A-733C18CA1059@nominet.org.uk>|To:=20"homenet@ietf .org=20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<1011c75f-d68d-4f3f-88d6-6d9c66d37c78>; bh=vx/LiVwD8MWeQbP26t1PtZhLrDZm/7nIPRadZnD4lkM=; b=4rGgbaKvkykF1xYVVrDCp3hdAyWC5dv5ImM2SvUT4gfOCENtUjCLTPE+ JzKn17x13TlbGhcOA9DlgOz/owWz0XV4dp7dz5RPl7mpAGO0Ir+sJhSyY qAOpZ/VJ0GyvoSa; X-IronPort-AV: E=Sophos;i="4.80,723,1344207600"; d="scan'208";a="36559550" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 06 Nov 2012 17:36:47 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Tue, 6 Nov 2012 17:36:46 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Session preparation Thread-Index: AQHNvEVLIWrPkYhezkea9jtxYXvQ9w== Date: Tue, 6 Nov 2012 17:36:47 +0000 Message-ID: <919D9AA5-5760-4DCD-986A-733C18CA1059@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <1011c75f-d68d-4f3f-88d6-6d9c66d37c78> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Session preparation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:36:50 -0000 Would all those presenting tomorrow who didn't already do so please get you= r slides to the Chairs ASAP. If at all possible, please include slide numbe= rs to aid remote participation! We'd like to extend our thanks to Hassan Zaheer for volunteering to take mi= nutes for the meeting. We still need a couple of Jabber scribes and would appreciate volunteers pu= tting themselves forward in advance of the session. thanks, Ray From alejandroacostaalamo@gmail.com Tue Nov 6 09:42:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A7321F8A81 for ; Tue, 6 Nov 2012 09:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpsC5iWJixZL for ; Tue, 6 Nov 2012 09:42:45 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A043C21F8A5A for ; Tue, 6 Nov 2012 09:42:45 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so714697vbb.31 for ; Tue, 06 Nov 2012 09:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XTDNd0nj/ls8ex9Cv8dnWhpF41PRf2xUToONHNXbJtc=; b=ysL5LUAdkznjg3177j+EesxoyloDN7QSIaKATr1c64J/apeplBg3SKcKzPAzQK/EUw F8KGLMSQknlzaO8At8UzUm1zw2pdYCeoLx2cpiyfEY4t5EiyJHcnyaUhPcW1GY98Z+U8 QLZgzEXPyUgSbYS+9Xe6BYKYzYiqM0VkSKShiMxeCFiZYPk5CRXRqmyBYFJ6ggtB2QNL XPzxgdYn3FHJjA6Qe121NEvTTZeFaKGC+cFXucNJh78CR0PedXRAtc9pZa9sYbaUjXE/ 5H3MN7SccV7ZFCDuzICRHANKhVHBd8KERS+UvfMfRY4+hUcY7pafX6Ruahr/p2e5CgHe IA1g== MIME-Version: 1.0 Received: by 10.59.1.232 with SMTP id bj8mr1693165ved.22.1352223765095; Tue, 06 Nov 2012 09:42:45 -0800 (PST) Received: by 10.58.56.100 with HTTP; Tue, 6 Nov 2012 09:42:44 -0800 (PST) In-Reply-To: <919D9AA5-5760-4DCD-986A-733C18CA1059@nominet.org.uk> References: <919D9AA5-5760-4DCD-986A-733C18CA1059@nominet.org.uk> Date: Tue, 6 Nov 2012 12:42:44 -0500 Message-ID: From: Alejandro Acosta To: Ray Bellis Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Session preparation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:42:46 -0000 Hi Ray, Count on meet as jabber scriber. Alejandro, On 11/6/12, Ray Bellis wrote: > Would all those presenting tomorrow who didn't already do so please get your > slides to the Chairs ASAP. If at all possible, please include slide numbers > to aid remote participation! > > We'd like to extend our thanks to Hassan Zaheer for volunteering to take > minutes for the meeting. > > We still need a couple of Jabber scribes and would appreciate volunteers > putting themselves forward in advance of the session. > > thanks, > > Ray > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From ek@google.com Tue Nov 6 15:58:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF1121F85A8 for ; Tue, 6 Nov 2012 15:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUWCIorJFFbH for ; Tue, 6 Nov 2012 15:58:32 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8621F8595 for ; Tue, 6 Nov 2012 15:58:31 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so742962qaa.10 for ; Tue, 06 Nov 2012 15:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=fyxWzZq4Rwj3qxIX0FwwJCEJJKT9+dBW6xm/ocWbEjA=; b=koAGIxeQKG8jxSXZ1k5Q1AuW3J2Ah0THGmFB2o4n2FXxjJ7WH7bYjc78Krx3Sam+Dk 0PG/O8CLiQS3f/9lWPmf09pkWz8+P6l/YQKi4FbhjFGDs0bW1lFBtQDoIL/d9vRTpXBO 3sZJdgM+aziuADFLOaT/6b8EaNLXCmkC07QyqwfKOYu8NKoVb5BtoSzcWmTIANded7P1 USuwGzxyKMKa75/QFpoxaW3FJR+KFa7xbEWGAty3mhvXrPrioeYVJaMUMDepS17aaVZP FRXMJBRxnp/9fQytdhmrTjMIU/GhA8NEgNF67YUbMiPNi3gx7EpdNE4SwJrxmvJBd/QW CdWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=fyxWzZq4Rwj3qxIX0FwwJCEJJKT9+dBW6xm/ocWbEjA=; b=MMYJadmWFLtkZo6nK7ACISHw40HcE8Hl7gd4L9kKlCXd3n1niHdq8QydyaWBn1hbh1 DURryHM3Vz0aD3Ye7CVTRIx0XfThd8AS//Ae+kFBA2KyMvcM835+RJr7QWP1eBerqWqm ge//d7GyQL3lN+Yf0zetLsSpxBiUzCRb7AaL4vyc8E65frWeEQ+moc6oUCqhPomH0mK2 66JzUFPnjPUtTdsA05qbjUSNVCb231Zd151RjPFXKrU8kUdHmgnJBh659Tc8+IQzLQBx EG5i5Q2YcBUy/cnP2NPwSpTxVl/xtt7WTueu7NBTNrEbf2Dd3uDqHMGGCFT8SEKDWpZK hvbw== Received: by 10.224.27.3 with SMTP id g3mr4264860qac.44.1352246310691; Tue, 06 Nov 2012 15:58:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.192.76 with HTTP; Tue, 6 Nov 2012 15:58:10 -0800 (PST) In-Reply-To: <20121106235507.24362.96807.idtracker@ietfa.amsl.com> References: <20121106235507.24362.96807.idtracker@ietfa.amsl.com> From: Erik Kline Date: Wed, 7 Nov 2012 08:58:10 +0900 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnDk68UbibMyKx5rMfQ+6ScH8X2qdkUPVjFBFN7URHnWi3c/wWD/QlaPDuWxamyt8f19wBwdPOKn4tsAay4waUCRQoftOiDyXuPvPN3Y0Mz+BuQ0fleeGw0ZnQGAkprOS7/Y61Cqj0Yt6edxBzKOiWszk4i/jdb/+PE0RPd288eLVTvHJDKNWo+zoeEA4m4nrNhKgNB Subject: [homenet] Fwd: New Version Notification for draft-kline-default-perimeter-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:58:32 -0000 All, My sincere apologies for not completing this sooner. ---------- Forwarded message ---------- From: Date: 7 November 2012 08:55 Subject: New Version Notification for draft-kline-default-perimeter-01.txt To: ek@google.com A new version of I-D, draft-kline-default-perimeter-01.txt has been successfully submitted by Erik Kline and posted to the IETF repository. Filename: draft-kline-default-perimeter Revision: 01 Title: Default Border Definition Creation date: 2012-11-06 WG ID: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-kline-default-perimeter-01.txt Status: http://datatracker.ietf.org/doc/draft-kline-default-perimeter Htmlized: http://tools.ietf.org/html/draft-kline-default-perimeter-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kline-default-perimeter-01 Abstract: Automatic, simple identification of when traffic is crossing a perimeter is highly desirable for a variety of home network uses. This document describes how to use homenet routing protocol adjacencies as the primary signal of a common administrative domain (e.g. "the home"). Classification of interfaces et cetera as internal or external follow from this, as do various policy and implementation implications. One fundamental implication is that the active definition of a home network's interior is no more secure than its policy for forming homenet routing protocol adjacencies. The IETF Secretariat From mglt.ietf@gmail.com Tue Nov 6 20:21:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E311721F8BD7 for ; Tue, 6 Nov 2012 20:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWT5ZTdyXM5J for ; Tue, 6 Nov 2012 20:21:16 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8B021F8B69 for ; Tue, 6 Nov 2012 20:21:15 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so1243262vcb.31 for ; Tue, 06 Nov 2012 20:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=iC2UWWoXi2BZjcSEsVi6rBtTJTvhEwpWbeJThyoXkxs=; b=ZAlCJtJkwdt/bzOQrCIp2XJtt15um+uubdpulzSLJfGRjsDJkIE8HNEDyLgRGWtnUG QpFztV91hFEEbiNe3pvNsUqEED/MTQUEhmz46J2UQ9GkuuqxOotbsxi9UumyWWEYR+7Q 90pXnKdyFKJDGOwq4TDrqQp4nJ4qmWCmM5AzeJbDxBs9dcp4K6J6ftemz9+g+tY08HR1 i8u4mQ4GSuRwUoZVCT0SxLczxhWCY+pZBWg9Md2bR8MTeLH37btWcaw8+2PceZD01uEm fyJKaulBpF1fiDv3N4u8u6IaP+K58im/25KdOQXGrkxmD91kFRB8gtDeLefB/jXDxhA8 pL4w== MIME-Version: 1.0 Received: by 10.58.15.227 with SMTP id a3mr3128554ved.38.1352262075442; Tue, 06 Nov 2012 20:21:15 -0800 (PST) Received: by 10.58.155.69 with HTTP; Tue, 6 Nov 2012 20:21:15 -0800 (PST) In-Reply-To: <20121106161009.16166.30597.idtracker@ietfa.amsl.com> References: <20121106161009.16166.30597.idtracker@ietfa.amsl.com> Date: Tue, 6 Nov 2012 23:21:15 -0500 Message-ID: From: Daniel Migault To: homenet@ietf.org Content-Type: multipart/alternative; boundary=047d7b5daf50a6667f04cde00c7f Subject: [homenet] Fwd: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 04:21:17 -0000 --047d7b5daf50a6667f04cde00c7f Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find the updated version of the draft. Sorry for for the late posting. Best Regard, Daniel ---------- Forwarded message ---------- From: Date: Tue, Nov 6, 2012 at 11:10 AM Subject: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-01.txt To: mglt.ietf@gmail.com Cc: chris_griffiths@cable.comcast.com, wouter.cloetens@softathome.com, philippe.lemordant@orange.com A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-homenet-front-end-naming-delegation Revision: 01 Title: IPv6 Home Network Front End Naming Delegation Creation date: 2012-11-06 WG ID: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-01.txt Status: http://datatracker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delegation Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-front-end-naming-delegation-01 Abstract: CPEs are designed to provide IP connectivity to the Home Network. Most of the CPEs are also providing the IP addresses of the nodes of the Home Network. This makes CPEs good candidates for hosting the Naming Service that would make devices reachable from the Home Network but also from the Internet. CPEs have not been designed to host a Naming Service reachable from the Internet. This would expose the CPEs and the Home Network to resource exhaustion which would result in making the Home Network unreachable, and most probably would also affect the Home Network inner communications. This document describes an Front End Naming Architecture where the CPEs manage the DNS(SEC) zone for its Home Network, and outsource the zone to Public Server for resolution coming from the Internet. The goal of the document is first to describe a Naming Architecture that fulfills Home Network Naming requirements without exposing the CPE to resource exhaustion. Then we intend the CPEs to be easily configured by the End Users, and describe the necessary information the End User is expect to provide to the CPE. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b5daf50a6667f04cde00c7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=A0

Please find the updated version of the draft. Sorry for= for the late posting.

Best Regard,=A0
D= aniel

---------- Forwarded message ------= ----
From: <internet-drafts@ietf.org<= /a>>
Date: Tue, Nov 6, 2012 at 11:10 AM
Subject: New Version Notification for draft-mglt-homenet-front-end-naming-d= elegation-01.txt
To: mglt.ietf@gmail.com
Cc: chris_griffiths@cable.comcast.com, wouter.clo= etens@softathome.com, philippe.lemordant@orange.com



A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-01.txt=
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-front-end-naming-delegation
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 IPv6 Home Network Front End Naming Delegation Creation date: =A0 2012-11-06
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 17
URL: =A0 =A0 =A0 =A0 =A0 =A0 h= ttp://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-dele= gation-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatra= cker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delegation
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.= org/html/draft-mglt-homenet-front-end-naming-delegation-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-front-end-naming-delegation= -01

Abstract:
=A0 =A0CPEs are designed to provide IP connectivity to the Home Network. =A0 =A0Most of the CPEs are also providing the IP addresses of the nodes of=
=A0 =A0the Home Network. =A0This makes CPEs good candidates for hosting the=
=A0 =A0Naming Service that would make devices reachable from the Home
=A0 =A0Network but also from the Internet.

=A0 =A0CPEs have not been designed to host a Naming Service reachable from<= br> =A0 =A0the Internet. =A0This would expose the CPEs and the Home Network to<= br> =A0 =A0resource exhaustion which would result in making the Home Network =A0 =A0unreachable, and most probably would also affect the Home Network =A0 =A0inner communications.

=A0 =A0This document describes an Front End Naming Architecture where the =A0 =A0CPEs manage the DNS(SEC) zone for its Home Network, and outsource th= e
=A0 =A0zone to Public Server for resolution coming from the Internet.

=A0 =A0The goal of the document is first to describe a Naming Architecture<= br> =A0 =A0that fulfills Home Network Naming requirements without exposing the<= br> =A0 =A0CPE to resource exhaustion. =A0Then we intend the CPEs to be easily<= br> =A0 =A0configured by the End Users, and describe the necessary information<= br> =A0 =A0the End User is expect to provide to the CPE.




The IETF Secretariat




--
Daniel Migault
Orange = Labs -- Security
+33 6 70 72 69 58
--047d7b5daf50a6667f04cde00c7f-- From mark@townsley.net Wed Nov 7 06:08:31 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C169021F8836 for ; Wed, 7 Nov 2012 06:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtfvvJVX6tsQ for ; Wed, 7 Nov 2012 06:08:31 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 419A821F880A for ; Wed, 7 Nov 2012 06:08:31 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1242426pad.31 for ; Wed, 07 Nov 2012 06:08:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state; bh=NPPBnhcnbmK0aOvnjoh0CWvfL9Umd7fRiGu9Paq9EIM=; b=NakCncfQ28YJdUleDE3YDA2hdParF0XF+Xv3RhWpXvZ/dZ5WcEF8pH03HqjLBE4wgp qr28uk4pPxosPerzK/jzTbop7110rMVMSv0qoktvnT+7z95G2rp3q31n/0cO9TU0VIxV vE51LP7G+lUugCgA8KGw9EY3i9uGAmM38xArSdVc9cOPHI02JtubPoiiLBOlkIxrSBTP aTFt0psVSOip/+PPbIeeAHscjvCni7ovVyZr0JSpBYf72Qwg6ZKOxTDR8p6Cpn3iskac vjDTK7w2/M06rqniwJWdKyD2yH1Jc8CJb0xvS2Sx1TIUnoZILdomtLjbUiv3g5Wi2FHL cYnQ== Received: by 10.68.189.233 with SMTP id gl9mr13692481pbc.166.1352297311049; Wed, 07 Nov 2012 06:08:31 -0800 (PST) Received: from [10.21.166.138] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id e9sm14337251paz.28.2012.11.07.06.08.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:08:30 -0800 (PST) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_230ED30E-CFD4-4B6C-97E8-211FA98BF8CC" Date: Wed, 7 Nov 2012 09:08:28 -0500 Message-Id: <1BEA6117-8936-49F3-B4DF-8D713AC0EE59@townsley.net> To: Ray Bellis , "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmqRx2DyxGPqYDAXw3GwpLglXjZ9/fSLBcZKUK5wMmZVHnLHgHakftVmtK2LU/MMXHDgyyO Subject: [homenet] Revised Homenet Agenda for Today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:08:31 -0000 --Apple-Mail=_230ED30E-CFD4-4B6C-97E8-211FA98BF8CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Assuming I made no bugs in the reordering: =20 IETF 85 Homenet Working Group 7th November 2012 =20 09:00 - 09:10 Note Well, Jabber Relay, Note taker(s) =20 09:10 - 09:25 Homenet Architecture Update =20 draft-chown-homenet-arch-06 (Tim Chown - 15m) =20 09:25 - 10:10 Security and Border Discovery =20 draft-kline-default-perimeter-01 (Erik Kline - 15m) draft-boot-homenet-brdp-00 (Teco Boot - 15m) draft-behringer-homenet-trust-bootstrap-00 (Michael = Behringer - 15m) 10:10 - 11:00 Routing and Prefix Assignment =20 draft-arkko-homenet-prefix-assignment-03 (Jari Arkko - 15m) draft-haddad-homenet-multihomed (Damien Saucez - 15m) source + dest based routing (Jari Arkko - 20m) =20 =20 11:00 - 11:25 Naming and Service Discovery =20 update from MDNSEXT BoF (Tim Chown - 10m) draft-mglt-homenet-front-end-naming-delegation-01 (D. = Migault - 10m) draft-troan-homenet-naming-and-sd (Ole Troan - time = permitting) =20 11:25 Wrap-up =20 11:30 Close =20 =20 --Apple-Mail=_230ED30E-CFD4-4B6C-97E8-211FA98BF8CC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Assuming I made no bugs in the reordering:
   
          IETF 85
          Homenet Working Group
          7th November 2012
          
          09:00 - 09:10  Note Well, Jabber Relay, Note taker(s)
          
          09:10 - 09:25  Homenet Architecture Update
          
             draft-chown-homenet-arch-06 (Tim Chown - 15m)
          

          09:25 - 10:10  Security and Border Discovery
          
            draft-kline-default-perimeter-01 (Erik Kline - 15m)
            draft-boot-homenet-brdp-00 (Teco Boot - 15m)
            draft-behringer-homenet-trust-bootstrap-00 (Michael Behringer - 15m)

          10:10 - 11:00  Routing and Prefix Assignment
          
            draft-arkko-homenet-prefix-assignment-03 (Jari Arkko - 15m)
            draft-haddad-homenet-multihomed (Damien Saucez - 15m)
            source + dest based routing (Jari Arkko - 20m)
          
          
          11:00 - 11:25  Naming and Service Discovery
          
             update from MDNSEXT BoF (Tim Chown - 10m)
             draft-mglt-homenet-front-end-naming-delegation-01 (D. Migault - 10m)
             draft-troan-homenet-naming-and-sd (Ole Troan - time permitting)
          
          11:25  Wrap-up
          
          11:30  Close

--Apple-Mail=_230ED30E-CFD4-4B6C-97E8-211FA98BF8CC-- From mark@townsley.net Wed Nov 7 06:36:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022AF21F8B4A for ; Wed, 7 Nov 2012 06:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Cja3SwnYfu for ; Wed, 7 Nov 2012 06:36:50 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2FC21F8B19 for ; Wed, 7 Nov 2012 06:36:50 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1259248pad.31 for ; Wed, 07 Nov 2012 06:36:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state; bh=jLmitwR4i5AybhJbuR3cjV/7M7eMV+sUYbSEimjdE5M=; b=jM642jsFoYmCKyyFtgeq59MluE4pBooCC9z8Yyq2ZOzja+mGmn8Fu7vf/txoLESrtY pTHrYn2Bibwqs/vVbz4gS+Nnsbha2c8d8LBZbniDCBYvQ7kd6V0zTeirAsesz9txsX8c ZXsq27rQKYf7dAs4CK3o93qK4GV02PCjT9yoKyKfCJBcy4YQMV+33eUysiFJffSgsx79 Lm+ZPWNxt0UM5HC434bN9RZyHsNCgDasmhJXlgYStrdhWV37zmCwmF36rK6OjnLBwL5u uAhNnd++hvo+t2i/Ik8FZWN6uvYIDNHXFh9ymc1pVd72z2uF2C7j8W/cDZMwZv6pyNa2 W6Fg== Received: by 10.69.1.8 with SMTP id bc8mr14593700pbd.9.1352299010261; Wed, 07 Nov 2012 06:36:50 -0800 (PST) Received: from [10.21.166.138] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id n6sm14375189pav.18.2012.11.07.06.36.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:36:49 -0800 (PST) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_20D3FECD-55B7-4B6C-B6B0-A3D6D2555981" Date: Wed, 7 Nov 2012 09:36:46 -0500 Message-Id: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk6a9jCV55Ot8VyD+Z22A/+IxpyD2ZJU0nxTBXbdMpZpHPCwzL2lF3Ez5zaxIB14XkXyQKj Subject: [homenet] Revised Homenet Agenda (again) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:36:51 -0000 --Apple-Mail=_20D3FECD-55B7-4B6C-B6B0-A3D6D2555981 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IETF 85 Homenet Working Group 7th November 2012 =20 09:00 - 09:10 Note Well, Jabber Relay, Note taker(s) =20 09:10 - 09:25 Homenet Architecture Update =20 draft-chown-homenet-arch-06 (Tim Chown - 15m) =20 09:25 - 10:10 Security and Border Discovery =20 9:25 draft-kline-default-perimeter-01 (Erik Kline - 15m) 9:40 draft-boot-homenet-brdp-00 (Teco Boot - 15m) 9:55 draft-behringer-homenet-trust-bootstrap-00 (Michael = Behringer - 15m) 10:10 - 11:00 Routing and Prefix Assignment =20 10:10 draft-arkko-homenet-prefix-assignment-03 (Jari Arkko - = 15m) 10:25 draft-haddad-homenet-multihomed (Damien Saucez - 15m) 10:40 source + dest based routing (Jari Arkko, Lorenzo Colitti = - 20m) =20 =20 11:00 - 11:25 Naming and Service Discovery =20 11:00 update from MDNSEXT BoF (Tim Chown - 10m) 11:10 draft-mglt-homenet-front-end-naming-delegation-01 (D. = Migault - 10m) 11:20 Wrap-up - (Arch Doc Questions) 11:25 draft-troan-homenet-naming-and-sd (Ole Troan - time = permitting) 11:30 Close =20 =20 --Apple-Mail=_20D3FECD-55B7-4B6C-B6B0-A3D6D2555981 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii IETF = 85
          Homenet Working Group
          7th November 2012
         =20
          09:00 - 09:10  Note Well, Jabber Relay, Note taker(s)
         =20
          09:10 - 09:25  Homenet Architecture Update
         =20
             draft-chown-homenet-arch-06 (Tim Chown - =
15m)     =20

          09:25 - 10:10  Security and =
Border Discovery
         =20
          9:25  draft-kline-default-perimeter-01 (Erik =
Kline - 15m)
          9:40  draft-boot-homenet-brdp-00 (Teco Boot - =
15m)
          9:55            10:10 - 11:00  =
Routing and Prefix Assignment
         =20
         10:10  draft-arkko-homenet-prefix-assignment-03 =
(Jari Arkko - 15m)
         10:25  draft-haddad-homenet-multihomed (Damien =
Saucez - 15m)
         10:40  source + dest based routing (Jari Arkko, Lorenzo Colitti =
- 20m)
         =20
         =20
          11:00 - 11:25  Naming and Service Discovery
         =20
         11:00 update from MDNSEXT BoF (Tim Chown - 10m)
         11:10 	 =
11:20  Wrap-up - (Arch Doc Questions)
         11:25 draft-troan-homenet-naming-and-sd (Ole =
Troan - time permitting)
         11:30  Close
         =20

= --Apple-Mail=_20D3FECD-55B7-4B6C-B6B0-A3D6D2555981-- From mcr@sandelman.ca Wed Nov 7 06:41:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9BD21F8B4A for ; Wed, 7 Nov 2012 06:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNN4i27NP2-Z for ; Wed, 7 Nov 2012 06:41:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDBF21F8735 for ; Wed, 7 Nov 2012 06:41:59 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 813B181AA for ; Wed, 7 Nov 2012 09:33:50 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 49796CA0BC for ; Wed, 7 Nov 2012 09:41:56 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-reply-to: References: <20121106235507.24362.96807.idtracker@ietfa.amsl.com> Comments: In-reply-to Erik Kline message dated "Wed, 07 Nov 2012 08:58:10 +0900." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 07 Nov 2012 09:41:56 -0500 Message-ID: <13581.1352299316@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Fwd: New Version Notification for draft-kline-default-perimeter-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:42:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I think that draft-kline-default-perimeter is good, and I'd like to see it become a WG document.=20 =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmnMzAAoJEKD0KQ7Gj3P2rKwH/AxBG9nwWKXK+WewLszxrmFl lbxLs0Yjz/FbWMlApD4KkrrusBwHp3v94w2tglJ6Y/Zkv0v4XwKa9LVIDaWlqxCB 7Q+h2VnU74jAtXDm7BQ9rKc1IyJRMsamNJ6kkGJCyBPDi+U308nS5Yb7YNpdyAhM P5FE31OEn6vfzdyoxmyNeTxq6UM8COVSg2PfouwJEfpEpC/XgeDX3AY88uf8O3BW 8+XRsJ3TiH+1MoecERJ15MzEEksWBXGqZ+yek2rCsVsjXRAIVaZZqp2QmxUrV8/C eTYpS8g9bS+ma+vewyDAJVB0qlBSjEYf3Bex5Qmk1GWORM8zf1WljLf9G8LxWXw= =9V2J -----END PGP SIGNATURE----- --=-=-=-- From jari.arkko@piuha.net Wed Nov 7 06:51:53 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C54E21F8BD4 for ; Wed, 7 Nov 2012 06:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAzVd650jzvl for ; Wed, 7 Nov 2012 06:51:53 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CE20421F8BD0 for ; Wed, 7 Nov 2012 06:51:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2B1CE2CC43 for ; Wed, 7 Nov 2012 16:51:52 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7CFwdWc1AHi for ; Wed, 7 Nov 2012 16:51:51 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id C1F972CC3B for ; Wed, 7 Nov 2012 16:51:50 +0200 (EET) Message-ID: <509A7585.2070600@piuha.net> Date: Wed, 07 Nov 2012 09:51:49 -0500 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] additional presentations X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:51:53 -0000 The presentations that me, Markus, and Lorenzo are soon doing are available at http://arkko.com/ietf/homenet/ietf85_homenet_ospf.pdf http://arkko.com/ietf/homenet/ietf85_homenet_source_routing.pdf (not available on the proceedings page yet) Jari From tjc@ecs.soton.ac.uk Wed Nov 7 07:09:31 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9D421F8C03 for ; Wed, 7 Nov 2012 07:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNGwTpYxCrLb for ; Wed, 7 Nov 2012 07:09:31 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 86BEE21F8C02 for ; Wed, 7 Nov 2012 07:09:30 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qA7F9QVT031680 for ; Wed, 7 Nov 2012 15:09:26 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qA7F9QVT031680 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1352300967; bh=gTe+YmGtsSI77tOfXeyj4Fqusss=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=rBtoIqzlvLF41iHNQedSr1+6GdDxw5GTf0F4mYdkv/5M3IDcE1ol1TMJZNc6oQuvL BKa/WbuAnc4OJM49hw8dcRhbnwcoI8Lito+ZhgucXrnX0/T3NijiGGXmj7rteAuxH/ ETWhnqwsgClCMjLpvZ4YBVKxVVZ1hs7cFDAQjiPA= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id oA6F9Q0430610027yL ret-id none; Wed, 07 Nov 2012 15:09:26 +0000 Received: from dhcp-1343.meeting.ietf.org (dhcp-1343.meeting.ietf.org [130.129.19.67]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qA7F84CA015530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 7 Nov 2012 15:08:05 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_E2335E7D-EA1F-432D-A450-37F3569E87F2" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Wed, 7 Nov 2012 15:08:05 +0000 References: To: "homenet@ietf.org Group" In-Reply-To: X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oA6F9Q043061002700; tid=oA6F9Q0430610027yL; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qA7F9QVT031680 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] Revised Homenet Agenda (again) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:09:32 -0000 --Apple-Mail=_E2335E7D-EA1F-432D-A450-37F3569E87F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Nov 2012, at 14:36, Mark Townsley wrote: > IETF 85 > Homenet Working Group > 7th November 2012 > =20 > 09:00 - 09:10 Note Well, Jabber Relay, Note taker(s) > =20 > 09:10 - 09:25 Homenet Architecture Update > =20 > draft-chown-homenet-arch-06 (Tim Chown - 15m)=20 To be clear, that's draft-ietf-homenet-arch-06. http://tools.ietf.org/html/draft-ietf-homenet-arch-06 tim > =20 > 09:25 - 10:10 Security and Border Discovery > =20 > 9:25 draft-kline-default-perimeter-01 (Erik Kline - 15m) > 9:40 draft-boot-homenet-brdp-00 (Teco Boot - 15m) > 9:55 draft-behringer-homenet-trust-bootstrap-00 (Michael = Behringer - 15m) > 10:10 - 11:00 Routing and Prefix Assignment > =20 > 10:10 draft-arkko-homenet-prefix-assignment-03 (Jari Arkko - = 15m) > 10:25 draft-haddad-homenet-multihomed (Damien Saucez - 15m) > 10:40 source + dest based routing (Jari Arkko, Lorenzo = Colitti - 20m) > =20 > =20 > 11:00 - 11:25 Naming and Service Discovery > =20 > 11:00 update from MDNSEXT BoF (Tim Chown - 10m) > 11:10 draft-mglt-homenet-front-end-naming-delegation-01 (D. = Migault - 10m) >=20 > 11:20 Wrap-up - (Arch Doc Questions) > 11:25 draft-troan-homenet-naming-and-sd (Ole Troan - time = permitting) > 11:30 Close > =20 > =20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_E2335E7D-EA1F-432D-A450-37F3569E87F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii mark@townsley.net> = wrote:
IETF 85
     =
     Homenet Working Group
          7th November 2012
         =20
          09:00 - 09:10  Note Well, Jabber Relay, Note taker(s)
         =20
          09:10 - 09:25  Homenet Architecture Update
         =20
             draft-chown-homenet-arch-06 (Tim Chown - =
15m)
To be clear, that's = draft-ietf-homenet-arch-06.

ti= m
=20 
draft-kline-default-perimeter-01 (Erik =
Kline - 15m)
          9:40  draft-boot-homenet-brdp-00 (Teco Boot - =
15m)
          9:55            10:10 - 11:00  =
Routing and Prefix Assignment
         =20
         10:10  draft-arkko-homenet-prefix-assignment-03 =
(Jari Arkko - 15m)
         10:25  draft-haddad-homenet-multihomed (Damien =
Saucez - 15m)
         10:40  source + dest based routing (Jari Arkko, Lorenzo Colitti =
- 20m)
         =20
         =20
          11:00 - 11:25  Naming and Service Discovery
         =20
         11:00 update from MDNSEXT BoF (Tim Chown - 10m)
         11:10 	 =
11:20  Wrap-up - (Arch Doc Questions)
         11:25 draft-troan-homenet-naming-and-sd (Ole =
Troan - time permitting)
         11:30  Close
         =20

________________________= _______________________
homenet mailing list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail=_E2335E7D-EA1F-432D-A450-37F3569E87F2-- From dan-ietf@danyork.org Wed Nov 7 07:39:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C179321F8BAC for ; Wed, 7 Nov 2012 07:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BMgrDl795E1 for ; Wed, 7 Nov 2012 07:39:04 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E10BC21F8BE2 for ; Wed, 7 Nov 2012 07:39:03 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so2882668iec.31 for ; Wed, 07 Nov 2012 07:39:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state; bh=dkVDqAHEzXp3TXwAFF88Qv+9R/t+31yNq0BBZT2WOus=; b=nZ/6BlQfAqlXvMzrY/oPYfdTEDhqS9aLDTzTTh9T+8VyXHTDgwaAR0ZQrty+COuBed 09+ptdzBfKRrSXNnWCOBnbtmRPzqq8c/p31wDWJJFPZojBJ02DPMiyW6kPyVFNcR8fjT oI5Sry7hGM5i33grmaBXz4JRHGQr10lePRjqMNwP/FLRJfHi45AQO1WtkQWK7IeaYt9w EB9QZx/MMzw5z9EfNmDdiAVFMLcPyc/aC054lkRwLymascoRY8qZpi6DsaNeJD5699WU x0tfous/vYe0JAI9b1uEtF8NZ7khECEMN6QYG8u3NH6SgMBmhVhd0rnMA7vB2FbW+4MG 46LA== Received: by 10.50.7.234 with SMTP id m10mr4973943iga.43.1352302743534; Wed, 07 Nov 2012 07:39:03 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id xn10sm2157824igb.4.2012.11.07.07.39.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:39:03 -0800 (PST) From: Dan York Content-Type: multipart/alternative; boundary="Apple-Mail=_7FAA3901-0182-4E8D-A77E-807B779430B4" Date: Wed, 7 Nov 2012 10:39:00 -0500 Message-Id: <13AB4EA2-9BC0-4994-BCB0-B1D382AA3C6D@danyork.org> To: homenet@ietf.org, teco@inf-net.nl Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnowLfqFDWe58o3Y9+CnZOrJeC/THitkRy9Z+JNAGBztqKBx4YsD8jvswd3JGBX06SiUAxz Subject: [homenet] Security question related to draft-boot-homenet-brdp-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:39:04 -0000 --Apple-Mail=_7FAA3901-0182-4E8D-A77E-807B779430B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Teco, I am participating in IETF 85 remotely and Lee Howard went to the mic in = today's session to relay this question (thanks, Lee!). However, I did = not hear any answer. My question is: ---- Has any security analysis been done on the approach suggested in = draft-boot-homenet-brdp? Is any security analysis planned? I see the = Security Considerations section of the draft is "TBD" but on a brief = read of the draft I worry an attacker could misuse it. ---- For instance, an immediate question in my mind was whether an attacker = could somehow inject an advertisement with the "D" flag off and causing = internal routers to believe that the Border Router is NOT acting as a = DHCP server? Could an attacker inject modified BRIOs to, for instance, = modify the cost of routes? Are these valid concerns? Or are they protected against by other = mechanisms? I don't know. For someone new to reading this draft, it would be helpful to have some = commentary in "Security Considerations" about how secure this proposal = is. Just my 2 cents, Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_7FAA3901-0182-4E8D-A77E-807B779430B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
----

For instance, = an immediate question in my mind was whether an attacker could somehow = inject an advertisement with the "D" flag off and causing internal = routers to believe that the Border Router is NOT acting as a DHCP = server?  Could an attacker inject modified BRIOs to, for instance, = modify the cost of routes?

Are these valid = concerns?  Or are they protected against by other mechanisms? I = don't know.

For someone new to reading this = draft, it would be helpful to have some commentary in "Security = Considerations" about how secure this proposal = is.

Just my 2 = cents,
Dan

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork

= --Apple-Mail=_7FAA3901-0182-4E8D-A77E-807B779430B4-- From Ted.Lemon@nominum.com Wed Nov 7 07:46:25 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A7821F8C2B for ; Wed, 7 Nov 2012 07:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTjT1PCwSy4X for ; Wed, 7 Nov 2012 07:46:25 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id BAEFB21F8C11 for ; Wed, 7 Nov 2012 07:46:24 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUJqCUERVIe7sa+rWJR4Xa3IpQsUpIJ1B@postini.com; Wed, 07 Nov 2012 07:46:24 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CDC3A1B8300 for ; Wed, 7 Nov 2012 07:46:23 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C3F4B190043 for ; Wed, 7 Nov 2012 07:46:23 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 7 Nov 2012 07:46:23 -0800 From: Ted Lemon To: "homenet@ietf.org Group" Thread-Topic: DHCP PD for homenets. Thread-Index: AQHNvP8JQL/Ls7zAx02Oe7JzI9Fc2w== Date: Wed, 7 Nov 2012 15:46:23 +0000 Message-ID: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0A02AAE1A9C8C845A89B5F26CF785933@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 07 Nov 2012 07:51:06 -0800 Subject: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:46:25 -0000 I don't have a particular preference for DHCP-PD over OSPF in homenets, but= I just wanted to quickly contradict what's been said by several people at = the mic: that figuring out what prefix to delegate is hard. It's not hard= , actually=97it's dead easy. The reason folks think it's hard is because = they're solving the wrong problem. The problem that needs to be solved is how we number each home subnet. Th= e answer to this question is, "with a /64." There is no other answer. Y= ou never want to number a subnet with a /52. Therefore, the delegating ro= uter should never delegate anything but a /64. Problem solved. I think the disconnect here is that people are thinking the routers to whic= h prefixes are delegated need to themselves be delegating routers, but this= is incorrect. What they need to do is _relay_ prefix delegation requests= to the delegating router from which they got their own delegation. This scales to multi-homing with multiple delegating routers=97you just rel= ay every PD request upstream to all delegating routers. I'd be happy to write a draft that describes how this works if someone actu= ally wants it; I get the sense that people are pretty in love with the OSPF= solution and would prefer not to be distracted, and I have no argument wit= h that if that's the working group consensus. From rdroms.ietf@gmail.com Wed Nov 7 07:51:57 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CF821F8BCA for ; Wed, 7 Nov 2012 07:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJn1FdsGoPba for ; Wed, 7 Nov 2012 07:51:55 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3A421F8BAD for ; Wed, 7 Nov 2012 07:51:55 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id c4so1121796qae.10 for ; Wed, 07 Nov 2012 07:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=qPd5r8ahFzGQcMZMRoTt7sABNBpoBkW8RNl12UMY7QU=; b=o8UBD6/GtyaEcXb9ZVWpSSabE+ragCsDS7yTVv0IDXfcsCu5ks6DZPv0c7FHXJ3XJq 8PsZuph5cx/R5M9rkeK0E38wf3SZdk04jTpiCIR6fCCSk4t3OkEVSwLIrJKfKlDjrQh3 CHU1lvTX0ul/Vo+bNyn1QCL1VxrfK/B36ITbt1MrpkC8SHAyuXpEJBgk3/ax+ZV1xry5 Jg5qQn48DeycWZ5gMd/56fERJYxM8oWef9aRlA/4iUuXxnptsECCCI0EFi+JlFDQ9RLR YsuS2UO2L5l/7hDRfHK1SWiMMRbjefIBpX1JO+vmlFfvOFwRSfKxF35Kv7kccQ3wRMbd 3zuA== Received: by 10.49.59.115 with SMTP id y19mr6637706qeq.59.1352303514773; Wed, 07 Nov 2012 07:51:54 -0800 (PST) Received: from [10.86.253.248] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id q14sm7181190qaa.15.2012.11.07.07.51.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:51:54 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Nov 2012 10:51:51 -0500 Message-Id: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:51:57 -0000 Clarifying my remarks at the mic... Using PD in a home network isn't hard. Use a single delegating router; = most obvious choice is the device that received the prefix from the = external source. Every other router acts as a requesting router, and asks for a single = /64 for each of its interfaces from the delegating router. draft-baker-homenet-prefix-assignment-01 has more details. Read it = before you flame me. *Recursive* PD is, indeed, harder. Don't do it. - Ralph From rdroms.ietf@gmail.com Wed Nov 7 07:53:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7E921F8C31 for ; Wed, 7 Nov 2012 07:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD-nNDHQ+QTG for ; Wed, 7 Nov 2012 07:53:10 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8E921F8BAD for ; Wed, 7 Nov 2012 07:53:10 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so1262462qca.31 for ; Wed, 07 Nov 2012 07:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zvIURb0upMfwbxWV9ZgpssOItB2wuT5rQVEeTHDrAiQ=; b=Of8F7hDfSewKvDOg024GiJcQdMFDJ8HlXhHGt5mJizcSvSKVvXTMG65qHY3lpSVXkQ R4yHeL+WC5WHj5b3tRs9ObzMW3WmzMJeCzGDnD5dmIO8idIWwxNYeB1zGcTBPclD5Epa qmKI9d55OyTdk6EbwRjqiMWdp2SObtYXyd/M6v+Kwa5fA+8zVm2/wRu+y76/h76gJ2Hy s90FXmalhGSwbgtn4gfC00zmhHhg2Pnc9TChexSvX/DAWWb7i9f6tkuoUl3opwERcx0y 7vhwYLpi/ZN4BDIANWMqijPdYy44t6/sCvxF2tmZcKJWYNVoNS+pKAth0byOGgWbqP/T 00IQ== Received: by 10.49.63.104 with SMTP id f8mr8754629qes.29.1352303589004; Wed, 07 Nov 2012 07:53:09 -0800 (PST) Received: from [10.86.253.248] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id jt10sm12439166qeb.4.2012.11.07.07.53.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:53:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Ralph Droms In-Reply-To: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> Date: Wed, 7 Nov 2012 10:53:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9F52EFEF-8F63-465B-A599-FAF8C4701A04@gmail.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:53:11 -0000 On Nov 7, 2012, at 10:46 AM 11/7/12, Ted Lemon wrote: > I don't have a particular preference for DHCP-PD over OSPF in = homenets, but I just wanted to quickly contradict what's been said by = several people at the mic: that figuring out what prefix to delegate is = hard. It's not hard, actually=97it's dead easy. The reason folks = think it's hard is because they're solving the wrong problem. >=20 > The problem that needs to be solved is how we number each home subnet. = The answer to this question is, "with a /64." There is no other = answer. You never want to number a subnet with a /52. Therefore, the = delegating router should never delegate anything but a /64. Problem = solved. >=20 > I think the disconnect here is that people are thinking the routers to = which prefixes are delegated need to themselves be delegating routers, = but this is incorrect. What they need to do is _relay_ prefix = delegation requests to the delegating router from which they got their = own delegation. >=20 > This scales to multi-homing with multiple delegating routers=97you = just relay every PD request upstream to all delegating routers. +1; see my e-mail that passed this e-mail in flight. >=20 > I'd be happy to write a draft that describes how this works draft-baker-homenet-prefix-assignment-01 > if someone actually wants it; I get the sense that people are pretty = in love with the OSPF solution and would prefer not to be distracted, = and I have no argument with that if that's the working group consensus. - Ralph >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Wed Nov 7 07:53:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96821F8BAC for ; Wed, 7 Nov 2012 07:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V8j+Znczrz7 for ; Wed, 7 Nov 2012 07:53:51 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74B21F8863 for ; Wed, 7 Nov 2012 07:53:51 -0800 (PST) Received: from [192.168.1.2] (62.sub-70-193-130.myvzw.com [70.193.130.62]) by toccata.fugue.com (Postfix) with ESMTPSA id A30BD2381D72; Wed, 7 Nov 2012 10:53:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> Date: Wed, 7 Nov 2012 10:53:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:53:51 -0000 On Nov 7, 2012, at 10:51 AM, Ralph Droms wrote: > draft-baker-homenet-prefix-assignment-01 has more details. Read it = before you flame me. Oh. Yay! I don't have to write a draft. Thanks, Ralph! (And = thanks, Fred!) From otroan@employees.org Wed Nov 7 07:59:33 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D13821F8BE7 for ; Wed, 7 Nov 2012 07:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiYP56FU6Frn for ; Wed, 7 Nov 2012 07:59:33 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id AF68021F8B12 for ; Wed, 7 Nov 2012 07:59:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA6FmlCQ/khL/2dsb2JhbABEw2CBCIIeAQEBAwEBAQEPAVsLBQsLRicwBhMbB4diBgucMaAiBJFzYQOIWpt6gWuDDQ X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="9400704" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 07 Nov 2012 15:59:30 +0000 Received: from dhcp-10-61-103-79.cisco.com (dhcp-10-61-103-79.cisco.com [10.61.103.79]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA7FxSfP015363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Nov 2012 15:59:29 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> Date: Wed, 7 Nov 2012 10:59:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <07098242-84C5-4F72-BB86-405E081ABC15@employees.org> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) X-Mailman-Approved-At: Wed, 07 Nov 2012 08:04:21 -0800 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:59:33 -0000 Ted, this has been proposed a few times. the problems that I see with it are: - in an arbitrary topology how do you decide which interfaces you are a = client on and which interfaces you relay on - how do you handle the case where multiple routers try to assign a = prefix to a link - how do you discover the DHCPv6 servers - how do you handle the case with multiple sources of information = (multi-homing) the OSPF based prefix assignment handle all of these, "out of the = starting blocks". cheers, Ole > I don't have a particular preference for DHCP-PD over OSPF in = homenets, but I just wanted to quickly contradict what's been said by = several people at the mic: that figuring out what prefix to delegate is = hard. It's not hard, actually=97it's dead easy. The reason folks = think it's hard is because they're solving the wrong problem. >=20 > The problem that needs to be solved is how we number each home subnet. = The answer to this question is, "with a /64." There is no other = answer. You never want to number a subnet with a /52. Therefore, the = delegating router should never delegate anything but a /64. Problem = solved. >=20 > I think the disconnect here is that people are thinking the routers to = which prefixes are delegated need to themselves be delegating routers, = but this is incorrect. What they need to do is _relay_ prefix = delegation requests to the delegating router from which they got their = own delegation. >=20 > This scales to multi-homing with multiple delegating routers=97you = just relay every PD request upstream to all delegating routers. >=20 > I'd be happy to write a draft that describes how this works if someone = actually wants it; I get the sense that people are pretty in love with = the OSPF solution and would prefer not to be distracted, and I have no = argument with that if that's the working group consensus. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From andrewmcgr@gmail.com Wed Nov 7 08:05:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2354B21F8C4C for ; Wed, 7 Nov 2012 08:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDoBnEEJJkIn for ; Wed, 7 Nov 2012 08:05:55 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E7F3A21F8903 for ; Wed, 7 Nov 2012 08:05:53 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1366912pbb.31 for ; Wed, 07 Nov 2012 08:05:53 -0800 (PST) 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:x-mailer; bh=r3juZBVMYd6mVmDg6fLt26/IOYrPDAgIqM2owpXtEww=; b=xmtrI7CP1F70fKOolHgPrDFZAKIYf8f7VXj1BmEPvDhRmGPbHHydbQXWRDn5J90TiT VvmGH8JKFhx0mo3Sa0qNyr4nDNjOupZ9jk7SUs9+L7+t6rrXWGz6iFZiIeLZnf5TN9L6 iSvskGfGDMqQ2ENoOnGpb9HwZoAeRt0fjpKsuSy8OhorVrhV7+oQTFPrwawrrax010sm LfRfhRDtmFdeGhXi0hXbulK+AK5gESAaxrt9wAD848GAeLyeBGeXniPAgQNyHWFpQWYH AwpxVkIJWu6Mll5EPby9cK4s3WBboOIbnXWiy3O2OyUYT8m+DN9C0hZH6qyOorRDyUg6 E6KQ== Received: by 10.66.84.40 with SMTP id v8mr13625741pay.47.1352304353663; Wed, 07 Nov 2012 08:05:53 -0800 (PST) Received: from dhcp-6425.meeting.ietf.org (dhcp-6425.meeting.ietf.org. [130.129.100.37]) by mx.google.com with ESMTPS id hs1sm14328131pbc.33.2012.11.07.08.05.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 08:05:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> Date: Wed, 7 Nov 2012 11:05:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:05:56 -0000 Nice. Yes, that's a reasonable way to do that. Recursive PD seems to inherently need some administrative input. BTW, = our switch implementation can do either. Andrew On 7/11/2012, at 10:51 AM, Ralph Droms wrote: > Clarifying my remarks at the mic... >=20 > Using PD in a home network isn't hard. Use a single delegating = router; most obvious choice is the device that received the prefix from = the external source. >=20 > Every other router acts as a requesting router, and asks for a single = /64 for each of its interfaces from the delegating router. >=20 > draft-baker-homenet-prefix-assignment-01 has more details. Read it = before you flame me. >=20 > *Recursive* PD is, indeed, harder. Don't do it. >=20 > - Ralph >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From alejandroacostaalamo@gmail.com Wed Nov 7 08:06:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6602821F8C5E for ; Wed, 7 Nov 2012 08:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RtoVuzv7ULc for ; Wed, 7 Nov 2012 08:06:54 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 110E721F8C0A for ; Wed, 7 Nov 2012 08:06:52 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id l13so368310yen.31 for ; Wed, 07 Nov 2012 08:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uKfrcXht4RqfMjH9Qjhph/R9GdvCL4Ys30yXJAR9cMM=; b=zyy6U7x4rOPv1xFEmkjzJdPAhz00VUjIUGzYbda18fCIbOnuDXreRR1qfwq5hM7rss 2VQKt30xib8vpHT1qI9FTYpLDWmpcnRU2GgYJvcikqHzv5XqwooUQDy5JTwMj+byGcis O/ZX1afKLwPyl12bNBQpwwiPvDoXKxcx3q18kMMNZfWdkmcT75Wcxz0BGv4Wl7hNcJDC OR8M/zL0eQ9T3HRk7S32AK8HQaAqGxDFC5xErIK4PDjjl12BgrUHF3/6GOhvIXu8uQgP wrPcgwtQCuCOH2SNBbc4y3ZDOcqB9IqGYA2nVB8GtOe2inVrRHHXnPN6GbnnuYv66PAz R7Jg== MIME-Version: 1.0 Received: by 10.59.1.232 with SMTP id bj8mr4670025ved.22.1352304412409; Wed, 07 Nov 2012 08:06:52 -0800 (PST) Received: by 10.58.56.100 with HTTP; Wed, 7 Nov 2012 08:06:51 -0800 (PST) In-Reply-To: <506C21B1.9080100@globis.net> References: <201210010121.q911Lsbp031067@gateway1.orleans.occnc.com> <2C25872F-9E9D-49B4-BEDA-C82E0EBC485F@gmail.com> <506C21B1.9080100@globis.net> Date: Wed, 7 Nov 2012 11:06:51 -0500 Message-ID: From: Alejandro Acosta To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Cc: Damien Saucez , "homenet@ietf.org Group" , Wassim Haddad , curtis@occnc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:06:55 -0000 Hi All, I support Ray position. Maybe this drafts solves some situation but I believe it might bring more problems than solutions. regards, Alejandro, On 10/3/12, Ray Hunter wrote: > I have read the draft and don't see how it advances Homenet. > > IMHO If an MSP wants to deploy some tunnel brokers on the Internet to > terminate what boils down to a pair of GRE tunnels, they can do so > without the IETF providing any new standards work, and it'll all work > just fine. > > I'd prefer it if people concentrated on > http://www.ietf.org/id/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > > regards, > RayH > > Damien Saucez wrote: >> Curtis, >> >> Thank you for the comments. >> >> Our target in this document is to raise the question of multihoming >> in personal and/or small/medium enterprise networks, so for now >> we were not looking at the mobile device such as smartphones >> connected to both 4g and wifi (for this, the multihoming solution >> must be implemented directly on the device). We believe that >> SOHO would be interested being multihomed but can't afford the >> cost of operating multihoming themselves. This is why we suggest >> the MSP which is a way to outsource multihoming complexity. >> >> Now, let's go to the technical part. We didn't want to provide >> solution so far but we had in mind the following: >> >> 1. traffic is tunnelled between the network and the MSP. >> >> 2. addresses assigned to devices in the network belong to >> the MSP (or at least are advertised by the MSP in BGP) and >> then they never change. >> >> 3. the MSP box has one "wire" (possibly vie wifi or 3/4G) per >> ISP to which the network is connected and each NIC connected >> to this "wire" receives addresses dynamically. >> >> Putting these three points together, it means that the gw are >> invisible to the devices in the network, that addresses of devices >> never change during communications and that traffic always go >> through the MSP (even though it is possible to avoid this). >> >> I agree that there is no such thing as the MSP so far, but there >> is a bunch of very big service providers that exist today, that are >> peering with virtually every significant network and that would >> certainly be happy to be the "first hop" for all the communications. >> >> >> Thank you, >> >> Damien Saucez >> >> On 01 Oct 2012, at 03:21, Curtis Villamizar wrote: >> >>> In message<08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> >>> Wassim Haddad writes: >>> >>>> Dear all, >>>> >>>> We have submitted a problem statement for multihoming in homenet. >>>> Comments appreciated! >>>> >>>> Regards, >>>> >>>> Wassim H. >>> Wassim, >>> >>> You are proposing a solution, not submitting a problem statement. >>> >>> A problem with your solution is that the most common multihoming is >>> the mobile device having IP access through both WiFi (via DSL or cable >>> or hotspot) and 4G mobile. In this case the "MSP middlebox" you >>> propose would have to be inside the mobile device, which is already >>> both one of the gateways and the end host. >>> >>> Another problem is the current non-existance of a Multihoming Service >>> Provider (MSP)" somewhere out "in the cloud" to replace the source >>> address of packets. >>> >>> No where in your document does the principle issue with multihoming >>> get addressed. The source address used by the host must be chosen >>> somehow by the host or replaced somewhere. The function of the "MSP >>> middlebox" as described is only to redirect outgoing packets. If the >>> source address reflect going through ISP2, and that link goes away, >>> then the packets can now go out through ISP1 but the problem of using >>> the wrong source address remains. >>> >>> If the source address is somehow provided by the MSP, then the traffic >>> has to be tunnelled from MSP middlebox to MSP as might be implied by >>> the last paragraph in section 4 where it says "In addition, if Gw1 and >>> Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the >>> MSPMB will be configured automatically as well". The word "address" >>> barely appears in the draft except for the prior statement and one in >>> the intro saying why Shim6 or MPTCP should not be used. The word >>> "tunnel" doesn't appear at all. The word "source" (as in "source >>> address") doesn't appear at all. >>> >>> So you don't seem to be proposing a viable solution or perhaps you had >>> something to do with tunnelling in mind that you didn't describe at >>> all clearly. >>> >>> Curtis >>> >>> >>>> Begin forwarded message: >>>> >>>>> From: "internet-drafts@ietf.org" >>>>> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt >>>>> Date: September 25, 2012 10:55:38 AM PDT >>>>> To: "i-d-announce@ietf.org" >>>>> Reply-To: "internet-drafts@ietf.org" >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : Multihoming in Homenet >>>>> Author(s) : Wassim Haddad >>>>> Damien Saucez >>>>> Joel Halpern >>>>> Filename : draft-haddad-homenet-multihomed-00.txt >>>>> Pages : 7 >>>>> Date : 2012-09-25 >>>>> >>>>> Abstract: >>>>> So far, multihoming in Homenet must be supported by the hosts as >>>>> there is no mean to use simultaneously the different Internet >>>>> Service >>>>> Providers of the "Homenet" without risking flow disruption. In this >>>>> memo, we describe the problem statement for multihoming in Homenet. >>>>> We also propose a high level solution that answers this particular >>>>> problem. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From ot@cisco.com Wed Nov 7 08:14:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224B321F8C1C for ; Wed, 7 Nov 2012 08:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3tC4wi3J5D6 for ; Wed, 7 Nov 2012 08:14:55 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 541BD21F8BBE for ; Wed, 7 Nov 2012 08:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2083; q=dns/txt; s=iport; t=1352304895; x=1353514495; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kHNeI6z8b8rmXALXoMcuXgnuYX7UwvIZT1MBil/1e+A=; b=jbLeSKfYyrD3WueZnflNot+GlUXM8dVvgpYbo4I//fCy6C53izT+CsRd OzBhewxTc7uyg9FPBMrx9osx7jheGzt91QlHTlc5h2BtYJSwQRSLXP9G/ 4yOg90ONt1dYb3gYkXpSBjEQsgfwimkJElTHVQK+4EVLnvjEIT/qomtTr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALyImlCQ/khR/2dsb2JhbABEw2CBCIIeAQEBAwEBAQEPAVsLBQsLRicwBhMbB4diBgucJqAhBJFzYQOIWo0hjlmBa4MN X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="78063256" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 07 Nov 2012 16:14:53 +0000 Received: from dhcp-10-61-103-79.cisco.com (dhcp-10-61-103-79.cisco.com [10.61.103.79]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA7GEqBh015557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Nov 2012 16:14:53 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> Date: Wed, 7 Nov 2012 11:14:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:14:56 -0000 Ted, this has been proposed a few times. the problems that I see with it are: - in an arbitrary topology how do you decide which interfaces you are a = client on and which interfaces you relay on - how do you handle the case where multiple routers try to assign a = prefix to a link - how do you discover the DHCPv6 servers - how do you handle the case with multiple sources of information = (multi-homing) the OSPF based prefix assignment handle all of these, "out of the = starting blocks". cheers, Ole > I don't have a particular preference for DHCP-PD over OSPF in = homenets, but I just wanted to quickly contradict what's been said by = several people at the mic: that figuring out what prefix to delegate is = hard. It's not hard, actually=97it's dead easy. The reason folks = think it's hard is because they're solving the wrong problem. >=20 > The problem that needs to be solved is how we number each home subnet. = The answer to this question is, "with a /64." There is no other = answer. You never want to number a subnet with a /52. Therefore, the = delegating router should never delegate anything but a /64. Problem = solved. >=20 > I think the disconnect here is that people are thinking the routers to = which prefixes are delegated need to themselves be delegating routers, = but this is incorrect. What they need to do is _relay_ prefix = delegation requests to the delegating router from which they got their = own delegation. >=20 > This scales to multi-homing with multiple delegating routers=97you = just relay every PD request upstream to all delegating routers. >=20 > I'd be happy to write a draft that describes how this works if someone = actually wants it; I get the sense that people are pretty in love with = the OSPF solution and would prefer not to be distracted, and I have no = argument with that if that's the working group consensus. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Wed Nov 7 08:20:22 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CCB21F8C34 for ; Wed, 7 Nov 2012 08:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BijnGi3Fbeyi for ; Wed, 7 Nov 2012 08:20:22 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 07AD221F8C32 for ; Wed, 7 Nov 2012 08:20:22 -0800 (PST) Received: from [192.168.1.2] (62.sub-70-193-130.myvzw.com [70.193.130.62]) by toccata.fugue.com (Postfix) with ESMTPSA id DFB322381D72; Wed, 7 Nov 2012 11:20:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Wed, 7 Nov 2012 11:20:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> To: Andrew McGregor X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:20:22 -0000 On Nov 7, 2012, at 11:05 AM, Andrew McGregor = wrote: > Recursive PD seems to inherently need some administrative input. BTW, = our switch implementation can do either. I don't see what admin input it requires. The CPE edge router knows = it's got a delegation, and signals to adjacent routers that it can act = as a delegating router. Routers that get /64 delegations know that = they can't act as delegating routers, and instead act as relays to the = CPE edge router. This can all be done automatically. From mcr@sandelman.ca Wed Nov 7 08:20:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE6B21F8BB5 for ; Wed, 7 Nov 2012 08:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYkuKZAVUKTG for ; Wed, 7 Nov 2012 08:20:54 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 022D121F8B75 for ; Wed, 7 Nov 2012 08:20:53 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 401CC81AA for ; Wed, 7 Nov 2012 11:12:46 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 373F4CA0BC for ; Wed, 7 Nov 2012 11:20:53 -0500 (EST) From: Michael Richardson To: homenet@ietf.org X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 07 Nov 2012 11:20:53 -0500 Message-ID: <16245.1352305253@sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] making homenet-source-routing work with 6204 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:20:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable If the 6204 CPE router is one of GW1/GW2 (lets say GW1), then it won't be participating in the routing protocol and prefix distribution system, so the host that is behind R won't get an address from GW1, only GW2. That means that we only have to worry about hosts on the link (call it H2) that has GW1 (the 6204 only one), which will get an address directly From=20GW1. Such a host will also get an address from GW2. As pointed out by Barbara Stark, LAN requirement L-3 says: L-3: An IPv6 CE router MUST advertise itself as a router for the delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) using the "Route Information Option" specified in Section 2.3 of [RFC4191]. This advertisement is independent of having or not having IPv6 connectivity on the WAN interface. so, a host on that link will get poor service when it uses the prefix From=20GW1. Happy Eyeballs will solve that for browsers. However, the worse problem is that if host H2 uses GW1 for traffic to GW2, it won't get relayed, but will get dropped. This, I think is the major problem we will have. If the 6204 CPE router is not GW1 or GW2, but rather R, then what happens depends upon whether we distribute prefixes via DHCPv6 or OSPFv3. If DHCPv6, it will get one or more prefixes from one or more GW1/GW2. (likely it's been programmed to talk to one upstream ISP) If we distribute prefixes via OSPFv3, then 6204 CPE router R fails to get a prefix, and fails to work, and it is thrown out. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmopkAAoJEKD0KQ7Gj3P2ThAH/i0h17Q0Vs/62PyYri4e+oFu 5W3NemScdkqzeMfsXFg0KrHXgW+dqASBYo+dSfWhK7PPt1U/RHdAZvArBognnb3J INp7Dl6aO2pW7hDh4ARtO7dWzxjBIEVH1TmnfKNVZ+4rA0IWm6iSFTbtoud3r3d5 fk0O5vNMzl9MXKjHjrxgDmsb5q77UaJTZ0IqUqUJPb5o0aNbwHML8+IVODlwF5cR 16Uiyza6Ec8iRFadDt+AZLywzpUvklRBmT9J635zFSK598nNt4AhlACNPxC2p0N3 nbt4XMFw12dpofB/Y4GfKSocWHiOkMACp64oXgK641x+qOU96/f+whh2eDSQXNc= =g8FX -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Wed Nov 7 08:23:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5065221F8C30 for ; Wed, 7 Nov 2012 08:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pEJhp2GZOcw for ; Wed, 7 Nov 2012 08:23:50 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7521F8B54 for ; Wed, 7 Nov 2012 08:23:43 -0800 (PST) Received: from [192.168.1.2] (62.sub-70-193-130.myvzw.com [70.193.130.62]) by toccata.fugue.com (Postfix) with ESMTPSA id BC3E623815D6; Wed, 7 Nov 2012 11:23:41 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <07098242-84C5-4F72-BB86-405E081ABC15@employees.org> Date: Wed, 7 Nov 2012 11:23:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B880244-6C6F-44CD-9635-0E7A0E683E2F@fugue.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <07098242-84C5-4F72-BB86-405E081ABC15@employees.org> To: =?windows-1252?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:23:51 -0000 On Nov 7, 2012, at 10:59 AM, Ole Tr=F8an wrote: > the OSPF based prefix assignment handle all of these, "out of the = starting blocks". I'm under the impression that a number of issues you mentioned as solved = by OSPF and not solved by PD are actually not solved by OSPF. To = respond individually: > - in an arbitrary topology how do you decide which interfaces you are = a client on and which interfaces you relay on If you got a /64, you are not a delegating router for that prefix. > - how do you handle the case where multiple routers try to assign a = prefix to a link Take them all. > - how do you discover the DHCPv6 servers The same way you always do=97by multicasting a solicit. > - how do you handle the case with multiple sources of information = (multi-homing) As above, for each delegated prefix, either act as a delegating router = for it or not, depending on whether it is a /64 or larger. From andrewmcgr@gmail.com Wed Nov 7 08:23:53 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7376221F8C34 for ; Wed, 7 Nov 2012 08:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGeOjltCo7Cw for ; Wed, 7 Nov 2012 08:23:53 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9C21F8C28 for ; Wed, 7 Nov 2012 08:23:50 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1330024pad.31 for ; Wed, 07 Nov 2012 08:23:50 -0800 (PST) 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:x-mailer; bh=KjLHxmfpHm7ibtM3Q4lfa4hNaro98HMPQGePTI4kJ/w=; b=lpHBkJO0VlQyYSD0dft7fy465L6iERfr5r0aHXdERxTt8vOU9r5dALxTBh8TVw84ah XlTUckyKda2iPWPVk8sa7Zso39tURfVtHg1WjXSDAoYpcgozdeCIK75jgskKd/Fihxrt Ct/v3+/WBQheIIN5NuO066ZF6k5xUCLPOuP97tCdGCEbg4qA1PrSBUSNIqUiQGyK3PIo bOShiqqTfSnw6gcr9teBQZD8Lp8j06+ZXL0ctxJvFJ06IaeCP8Bxu2QBDfOZH9awYFNv oRotycdWeFzIIuRyB5jNxBiKDJo4VhFJ+UZ1jIjyMBgaDYVvKp7KbgiQ3UVmeTgZgARM I85g== Received: by 10.66.76.98 with SMTP id j2mr13694728paw.65.1352305430601; Wed, 07 Nov 2012 08:23:50 -0800 (PST) Received: from ?IPv6:2001:df8::96:4c24:95b1:2b4c:123c? ([2001:df8:0:96:4c24:95b1:2b4c:123c]) by mx.google.com with ESMTPS id g1sm14503732pax.21.2012.11.07.08.23.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 08:23:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> Date: Wed, 7 Nov 2012 11:23:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:23:53 -0000 On 7/11/2012, at 11:20 AM, Ted Lemon wrote: > On Nov 7, 2012, at 11:05 AM, Andrew McGregor = wrote: >> Recursive PD seems to inherently need some administrative input. = BTW, our switch implementation can do either. >=20 > I don't see what admin input it requires. The CPE edge router knows = it's got a delegation, and signals to adjacent routers that it can act = as a delegating router. Routers that get /64 delegations know that = they can't act as delegating routers, and instead act as relays to the = CPE edge router. This can all be done automatically. >=20 But that's single-delegating-router, not recursive. The problem with = recursive is figuring out what prefix length a sub-delegating router is = going to ask for from its upstream. For a single-delegating-router = setup, you just ask for either a bunch of /64s or something that just = contains enough of those to cover all your downstream interfaces. In a = recursive situation, you don't know what you will need further = downstream. Andrew= From ajs@anvilwalrusden.com Wed Nov 7 08:31:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A655121F8BBE for ; Wed, 7 Nov 2012 08:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilmr-FlbOcYv for ; Wed, 7 Nov 2012 08:31:38 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18921F8B4D for ; Wed, 7 Nov 2012 08:31:38 -0800 (PST) Received: from mx1.yitter.info (dhcp-13cd.meeting.ietf.org [130.129.19.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BD97E8A031 for ; Wed, 7 Nov 2012 16:31:27 +0000 (UTC) Date: Wed, 7 Nov 2012 11:31:20 -0500 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20121107163120.GN74706@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:31:38 -0000 Dear colleagues, While I was delighted to notice that draft-mglt-homenet-front-end-naming-delegation-01 had been modified in response to previous suggestions, such that it removed some of the more controversial parts of its predecessor, the core remark I made about the -00 is still true: I think it is way, way too complicated. I also think it's a nearly solved problem in shipping product to-day. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From mellon@fugue.com Wed Nov 7 09:33:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B9D21F8C81 for ; Wed, 7 Nov 2012 09:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUA-0xfTevD9 for ; Wed, 7 Nov 2012 09:33:04 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id DF9AD21F8C80 for ; Wed, 7 Nov 2012 09:33:04 -0800 (PST) Received: from [192.168.1.5] (171.sub-70-193-142.myvzw.com [70.193.142.171]) by toccata.fugue.com (Postfix) with ESMTPSA id C6D4323815D6; Wed, 7 Nov 2012 12:33:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> Date: Wed, 7 Nov 2012 18:32:59 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> To: Andrew McGregor X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:33:05 -0000 On Nov 7, 2012, at 5:23 PM, Andrew McGregor wrote: > But that's single-delegating-router, not recursive. What is a "recursive delegating router," and why do you want one? From mellon@fugue.com Wed Nov 7 09:46:03 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E544221F8C56 for ; Wed, 7 Nov 2012 09:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjteCO73acFa for ; Wed, 7 Nov 2012 09:46:02 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 520B821F8B8E for ; Wed, 7 Nov 2012 09:46:02 -0800 (PST) Received: from [192.168.1.5] (171.sub-70-193-142.myvzw.com [70.193.142.171]) by toccata.fugue.com (Postfix) with ESMTPSA id 6A6C623815D6; Wed, 7 Nov 2012 12:45:46 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Wed, 7 Nov 2012 18:45:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54B35744-B936-46AB-B120-4EE21ADA683B@fugue.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> To: Andrew McGregor X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:46:03 -0000 On Nov 7, 2012, at 6:32 PM, Ted Lemon wrote: > What is a "recursive delegating router," and why do you want one? So just in case this is a simple misunderstanding and not a new protocol = proposal, what I said in my earlier message is that you don't need any = sort of recursive setup. The requesting router on the CPE, which gets = a prefix that can be subdivided (i.e., not a /64) only ever gives out = /64s downstream. Any router on the net, regardless of where they are = in the topology, gets prefixes from the CPE device with the big prefix, = not from intermediate routers. Intermediate routers that get /64 = prefixes (which is how they know they are intermediate routers!) do not = delegate=97they relay to their delegating router if they get a PD from = downstream. I don't think there are actually any problems with this topology that = require new protocol specs=97I think this is purely an ops decision. = IOW, you could do this now with RFC3633. From chris_griffiths@cable.comcast.com Wed Nov 7 09:46:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D61421F8C50 for ; Wed, 7 Nov 2012 09:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.606 X-Spam-Level: X-Spam-Status: No, score=-103.606 tagged_above=-999 required=5 tests=[AWL=1.310, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIBzVGlfZY1A for ; Wed, 7 Nov 2012 09:46:34 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A136121F8B76 for ; Wed, 7 Nov 2012 09:46:34 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.40860977; Wed, 07 Nov 2012 10:21:50 -0700 Received: from PACDCEXMB15.cable.comcast.com ([169.254.2.78]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 12:46:22 -0500 From: "Griffiths, Chris" To: Andrew Sullivan Thread-Topic: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 Thread-Index: AQHNvQVlzq/K7ni1TECdGRleJAaEuJfe+V+A Date: Wed, 7 Nov 2012 17:46:20 +0000 Message-ID: References: <20121107163120.GN74706@mx1.yitter.info> In-Reply-To: <20121107163120.GN74706@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E53512E4B983148B5735E7821DBC320@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:46:35 -0000 On Nov 7, 2012, at 11:31 AM, Andrew Sullivan wrote= : > While I was delighted to notice that > draft-mglt-homenet-front-end-naming-delegation-01 had been modified in > response to previous suggestions, such that it removed some of the > more controversial parts of its predecessor, the core remark I made > about the -00 is still true: I think it is way, way too complicated. > I also think it's a nearly solved problem in shipping product to-day. Andrew, As one of the newer co-authors on this draft, I am happy to see that the ch= anges we made to the draft have resolved some of the more contentious issue= s previously brought up. I would like to understand further if you or othe= r folks in the WG have any suggestions on how we could make this less compl= ex and address naming both in and out of the home. As an operator who is d= eploying home network platforms to millions of customers today, I politely = disagree that this problem is nearly solved today in shipping products, but= could be solved with existing platforms and protocols which desperately ne= eds documentation.. Given the proposed architecture for Homenet, and the a= bility to have multiple layers of networks, there is going to be a need for= a scaled approach to deal with internal and external naming which will nee= d to include service discovery and publishing naming to outside the home. Thanks Chris From victor.kuarsingh@gmail.com Wed Nov 7 09:54:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0B921F8BE1 for ; Wed, 7 Nov 2012 09:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ5Z-Zqs22Gf for ; Wed, 7 Nov 2012 09:54:04 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A70D621F88DE for ; Wed, 7 Nov 2012 09:54:04 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1439500pbb.31 for ; Wed, 07 Nov 2012 09:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=0nUQbRtNTAEAI5STGKD6W0YTWi0r6ficp4DTvwJrZeA=; b=KjQn54cj0J9s/Q3Gkzi4q3sn0hb6xUNLVcWXSFsVYY6Crx14PaXjYJGy3BmlBSd9cC MBlS/F1adyEtJoqnAjKLZXW+6WU8i/wZ1Fs7VlWJo2URQlveqHe/8wALVs6gWWm7JHDI DY5LCoP632JqiuIzZQ+CukicTP3bh1WA4qJO5EnzxQIKefETrpVNREJCN9uWJF/4IBIz oWgVCCwZLxcIJuZCMAW3q1jvP5DvS9Ow6+Sz0mWjyzM1Ru+92P3YXAmIc93bsiqEBdJZ fornu17egX+QOrP+yoN5ueyymT2cPU+OzWCtd5cgdvXLXSf75g9K719UzMo8VWlvo/Yz NZBw== Received: by 10.68.234.229 with SMTP id uh5mr15743447pbc.123.1352310844446; Wed, 07 Nov 2012 09:54:04 -0800 (PST) Received: from [130.129.17.203] (dhcp-11cb.meeting.ietf.org. [130.129.17.203]) by mx.google.com with ESMTPS id d2sm14610821paw.19.2012.11.07.09.54.01 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:54:03 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 07 Nov 2012 12:53:59 -0500 From: Victor Kuarsingh To: Ted Lemon Message-ID: Thread-Topic: [homenet] regarding recursive DHCPv6-PD In-Reply-To: <54B35744-B936-46AB-B120-4EE21ADA683B@fugue.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:54:05 -0000 > Intermediate routers that get /64 prefixes (which is how they know they >are intermediate routers!) I am not sure I would agree that getting a /64 would inherently mean a router knows is an intermediate router. There are potential scenarios where an edge router may get a /64 and be the ISP edge router (not the best case scenario, but potential). I know this subtle point is somewhat outside the context of this thread, but just wanted to make the point. Regards, Victor Kuarsingh > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From simon@thekelleys.org.uk Wed Nov 7 10:05:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB3221F8B17 for ; Wed, 7 Nov 2012 10:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0qE6eQuFTVK for ; Wed, 7 Nov 2012 10:05:12 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id F376321F8B54 for ; Wed, 7 Nov 2012 10:03:57 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:47081 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TW9ym-0002Fg-4O for homenet@ietf.org; Wed, 07 Nov 2012 18:03:56 +0000 Received: from dhcp-16fb.meeting.ietf.org ([130.129.22.251]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TW9yl-0001CR-22 for homenet@ietf.org; Wed, 07 Nov 2012 18:03:55 +0000 Message-ID: <509AA288.30802@thekelleys.org.uk> Date: Wed, 07 Nov 2012 18:03:52 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> In-Reply-To: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:05:13 -0000 On 07/11/12 15:46, Ted Lemon wrote: > I think the disconnect here is that people are thinking the routers > to which prefixes are delegated need to themselves be delegating > routers, but this is incorrect. What they need to do is _relay_ > prefix delegation requests to the delegating router from which they > got their own delegation. > ... and once the delegating routers are relaying DHCP-PD requests, they can also relay DHCP address-lease requests to the DHCP server in the CPE router. This puts all the information about DHCP leases and associated names in one place, and greatly simplifies the naming problem. Simon. From swmike@swm.pp.se Wed Nov 7 10:06:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97A21F8BBE for ; Wed, 7 Nov 2012 10:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r1NMZQ0znru for ; Wed, 7 Nov 2012 10:06:34 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 61AFB21F8B54 for ; Wed, 7 Nov 2012 10:06:34 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B513A9C; Wed, 7 Nov 2012 19:06:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AF3099A; Wed, 7 Nov 2012 19:06:32 +0100 (CET) Date: Wed, 7 Nov 2012 19:06:32 +0100 (CET) From: Mikael Abrahamsson To: Andrew McGregor In-Reply-To: <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> Message-ID: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org Group" , Ted Lemon , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:06:35 -0000 On Wed, 7 Nov 2012, Andrew McGregor wrote: > But that's single-delegating-router, not recursive. The problem with > recursive is figuring out what prefix length a sub-delegating router is > going to ask for from its upstream. For a single-delegating-router > setup, you just ask for either a bunch of /64s or something that just > contains enough of those to cover all your downstream interfaces. In a > recursive situation, you don't know what you will need further > downstream. For me, I've always taken for granted that the ISP CPE gets a /56 or something, and then it's fine to subdelegate /64s out of that as needed, and subdelegating routers request a /64 at a time as needed, and relay for sub-sub-delegating routers (as OP suggested). The hard part is to get the source based routing to work so that packets flowing upstream exit via the correct ISP CPE (if the home is multihomed to multiple ISPs) depending on what source address they have, so as to avoid getting dropped by uRPF filters. I'm surprised the subnet allocation size is still being discussed, I haven't followed the working group as closely as I should, but I hope we can get through this quickly. -- Mikael Abrahamsson email: swmike@swm.pp.se From otroan@employees.org Wed Nov 7 10:19:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD421F8B8C for ; Wed, 7 Nov 2012 10:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NtvY4Xi0Kj0 for ; Wed, 7 Nov 2012 10:19:41 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 210FC21F8724 for ; Wed, 7 Nov 2012 10:19:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAmmmlCQ/khR/2dsb2JhbABEw2OBCIIeAQEBAwESAWYQCw44VwYuB4diBpxFoDGRc2EDiFqbeoFrgw0 X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208";a="146412648" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2012 18:19:40 +0000 Received: from dhcp-10-61-99-39.cisco.com (dhcp-10-61-99-39.cisco.com [10.61.99.39]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA7IJcPb008673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Nov 2012 18:19:39 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: <0B880244-6C6F-44CD-9635-0E7A0E683E2F@fugue.com> Date: Wed, 7 Nov 2012 13:19:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <750CD9C0-2695-4F17-A139-7A5D26348A88@employees.org> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <07098242-84C5-4F72-BB86-405E081ABC15@employees.org> <0B880244-6C6F-44CD-9635-0E7A0E683E2F@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:19:42 -0000 Ted, >> the OSPF based prefix assignment handle all of these, "out of the = starting blocks". >=20 > I'm under the impression that a number of issues you mentioned as = solved by OSPF and not solved by PD are actually not solved by OSPF. = To respond individually: which ones? >> - in an arbitrary topology how do you decide which interfaces you are = a client on and which interfaces you relay on >=20 > If you got a /64, you are not a delegating router for that prefix. I can't grok your reply. how does a CPE determine which interface to = relay on and which one to be a client on? or does it do both? >> - how do you handle the case where multiple routers try to assign a = prefix to a link >=20 > Take them all. it is a wanted property of the mechanism to have only one prefix per = link. >> - how do you discover the DHCPv6 servers >=20 > The same way you always do=97by multicasting a solicit. there are multiple DHCPv6 servers, aka sources of information in the = network. how does a CPE build the tree of relays to get to all the servers? or are you suggesting that multicast routing is required in the home = network? >> - how do you handle the case with multiple sources of information = (multi-homing) >=20 > As above, for each delegated prefix, either act as a delegating router = for it or not, depending on whether it is a /64 or larger. can't grok this. to ask this another way. how does DHCPv6 work with multiple servers = having different information? that's what a flooding solution solves elegantly, that a discover - = request/reply protocol doesn't. cheers, Ole= From equinox@diac24.net Wed Nov 7 10:21:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68121F8C84 for ; Wed, 7 Nov 2012 10:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LY7sGEGbv3K for ; Wed, 7 Nov 2012 10:21:43 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 346DC21F8C80 for ; Wed, 7 Nov 2012 10:21:41 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TWAFu-0001Ba-Mo; Wed, 07 Nov 2012 19:21:38 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1TWAFi-00A5QH-3h; Wed, 07 Nov 2012 19:21:28 +0100 Date: Wed, 7 Nov 2012 13:21:26 -0500 From: David Lamparter To: Simon Kelley Message-ID: <20121107182125.GQ1927048@jupiter.n2.diac24.net> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <509AA288.30802@thekelleys.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: homenet@ietf.org Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:21:43 -0000 On Wed, Nov 07, 2012 at 06:03:52PM +0000, Simon Kelley wrote: > On 07/11/12 15:46, Ted Lemon wrote: > > > I think the disconnect here is that people are thinking the routers > > to which prefixes are delegated need to themselves be delegating > > routers, but this is incorrect. What they need to do is _relay_ > > prefix delegation requests to the delegating router from which they > > got their own delegation. > > > > ... and once the delegating routers are relaying DHCP-PD requests, they > can also relay DHCP address-lease requests to the DHCP server in the CPE > router. This puts all the information about DHCP leases and associated > names in one place, and greatly simplifies the naming problem. This really falls apart when I'm using 2 ISPs with 2 exit routers. a-k-a, "Where's up?" -David From simon@thekelleys.org.uk Wed Nov 7 10:29:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B7821F8C4F for ; Wed, 7 Nov 2012 10:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUe3De0kqaHh for ; Wed, 7 Nov 2012 10:29:57 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id B5D8621F8C24 for ; Wed, 7 Nov 2012 10:29:57 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:47106 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TWANw-0002MV-QB for homenet@ietf.org; Wed, 07 Nov 2012 18:29:56 +0000 Received: from dhcp-16fb.meeting.ietf.org ([130.129.22.251]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TWANw-0001w3-1X for homenet@ietf.org; Wed, 07 Nov 2012 18:29:56 +0000 Message-ID: <509AA8A2.8070102@thekelleys.org.uk> Date: Wed, 07 Nov 2012 18:29:54 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> In-Reply-To: <20121107182125.GQ1927048@jupiter.n2.diac24.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:29:58 -0000 On 07/11/12 18:21, David Lamparter wrote: > On Wed, Nov 07, 2012 at 06:03:52PM +0000, Simon Kelley wrote: >> On 07/11/12 15:46, Ted Lemon wrote: >> >>> I think the disconnect here is that people are thinking the routers >>> to which prefixes are delegated need to themselves be delegating >>> routers, but this is incorrect. What they need to do is _relay_ >>> prefix delegation requests to the delegating router from which they >>> got their own delegation. >>> >> >> ... and once the delegating routers are relaying DHCP-PD requests, they >> can also relay DHCP address-lease requests to the DHCP server in the CPE >> router. This puts all the information about DHCP leases and associated >> names in one place, and greatly simplifies the naming problem. > > This really falls apart when I'm using 2 ISPs with 2 exit routers. > a-k-a, "Where's up?" and be put back together by noting that 2 exit routers doesn't have to mean 2 DHCPv6 servers. A single DHCP server can take PDs from 2 or more upstream ISPs. If the problem is that exit routers come with DHCPv6 servers, then adding the ability to disable all but one (automatically or manually) would be worth considering. Simon. From swmike@swm.pp.se Wed Nov 7 10:36:29 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318CC21F8C8A for ; Wed, 7 Nov 2012 10:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqn9nlwALPMM for ; Wed, 7 Nov 2012 10:36:28 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 97FAE21F8BF9 for ; Wed, 7 Nov 2012 10:36:28 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4223C9F; Wed, 7 Nov 2012 19:36:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3BDD59A; Wed, 7 Nov 2012 19:36:27 +0100 (CET) Date: Wed, 7 Nov 2012 19:36:27 +0100 (CET) From: Mikael Abrahamsson To: David Lamparter In-Reply-To: <20121107182125.GQ1927048@jupiter.n2.diac24.net> Message-ID: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Simon Kelley , homenet@ietf.org Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:36:29 -0000 On Wed, 7 Nov 2012, David Lamparter wrote: > This really falls apart when I'm using 2 ISPs with 2 exit routers. > a-k-a, "Where's up?" I believe source based routing is needed somewhere. Either it's done between the ISP routers and that's it, or we expand the standards so all routers in the home understands this. ISP1 router says it's the default router for ISP1 PD prefix, ISP2 router says it's the default router for ISP2 PD prefix, and then they understand each other and if one happens to get traffic sourced from the others prefix, it's now properly forwarded to that ISP CPE. I remember the discussion from a year ago, hasn't anything progressed since that? Hm, that might have been in v6ops though. -- Mikael Abrahamsson email: swmike@swm.pp.se From mellon@fugue.com Wed Nov 7 10:43:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4121F8C65 for ; Wed, 7 Nov 2012 10:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piFqygHetT9q for ; Wed, 7 Nov 2012 10:43:33 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 213C921F8533 for ; Wed, 7 Nov 2012 10:43:32 -0800 (PST) Received: from dhcp-5438.meeting.ietf.org (dhcp-5438.meeting.ietf.org [130.129.84.56]) by toccata.fugue.com (Postfix) with ESMTPSA id 6ECF623815D6; Wed, 7 Nov 2012 13:43:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Wed, 7 Nov 2012 19:43:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:43:34 -0000 On Nov 7, 2012, at 6:53 PM, Victor Kuarsingh = wrote: > I am not sure I would agree that getting a /64 would inherently mean a > router knows is an intermediate router. There are potential scenarios > where an edge router may get a /64 and be the ISP edge router (not the > best case scenario, but potential). >=20 > I know this subtle point is somewhat outside the context of this = thread, > but just wanted to make the point. Such a router has no prefixes to delegate, so the distinction is = immaterial. There can only be one non-translating router on this = network. From equinox@diac24.net Wed Nov 7 10:45:25 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DAC21F8B3A for ; Wed, 7 Nov 2012 10:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3IjZKA-ngZ3 for ; Wed, 7 Nov 2012 10:45:24 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id B262F21F8A8F for ; Wed, 7 Nov 2012 10:45:24 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TWAct-0003d6-UB; Wed, 07 Nov 2012 19:45:24 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1TWAcg-00A6ly-E7; Wed, 07 Nov 2012 19:45:13 +0100 Date: Wed, 7 Nov 2012 13:45:10 -0500 From: David Lamparter To: Simon Kelley Message-ID: <20121107184510.GT1927048@jupiter.n2.diac24.net> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <509AA8A2.8070102@thekelleys.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <509AA8A2.8070102@thekelleys.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: homenet@ietf.org Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:45:25 -0000 On Wed, Nov 07, 2012 at 06:29:54PM +0000, Simon Kelley wrote: > On 07/11/12 18:21, David Lamparter wrote: > > On Wed, Nov 07, 2012 at 06:03:52PM +0000, Simon Kelley wrote: > >> On 07/11/12 15:46, Ted Lemon wrote: > >> > >>> I think the disconnect here is that people are thinking the routers > >>> to which prefixes are delegated need to themselves be delegating > >>> routers, but this is incorrect. What they need to do is _relay_ > >>> prefix delegation requests to the delegating router from which they > >>> got their own delegation. > >>> > >> > >> ... and once the delegating routers are relaying DHCP-PD requests, they > >> can also relay DHCP address-lease requests to the DHCP server in the CPE > >> router. This puts all the information about DHCP leases and associated > >> names in one place, and greatly simplifies the naming problem. > > > > This really falls apart when I'm using 2 ISPs with 2 exit routers. > > a-k-a, "Where's up?" > > and be put back together by noting that 2 exit routers doesn't have to > mean 2 DHCPv6 servers. A single DHCP server can take PDs from 2 or more > upstream ISPs. If the problem is that exit routers come with DHCPv6 > servers, then adding the ability to disable all but one (automatically > or manually) would be worth considering. Yes, and now we need some protocol to decide which of the routers serves as DHCPv6/PD server, that needs to work while crossing intermediate routers possibly... (assuming we want to do it automatically) So that's heading for another information propagation/flooding/election protocol, at which point I don't see why we shouldn't just use OSPFv3. -David From victor.kuarsingh@gmail.com Wed Nov 7 10:52:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233DD21F8C89 for ; Wed, 7 Nov 2012 10:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mygoHkbW1Grc for ; Wed, 7 Nov 2012 10:52:07 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 854A821F8C4F for ; Wed, 7 Nov 2012 10:52:07 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1428141pad.31 for ; Wed, 07 Nov 2012 10:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=tdu9HBY5Qos+q4f8UYrvU03c6UyAQ4fYf4Z/Xe8lAP8=; b=WKgkOhZPl+rStAWf3xvuzQcx66T4sdOLPGKuf0OrvbYnYjWQodCMXqZk9sJq31IhKX QFx7e6e7UWW468TpP/u80FyTaBh+IQyW0f7YH5nCqXUp2DCKgXFmNhCwADvi61eTiY2g iWGShrgvsugzfo4lTdAd5R/hfnoJ7Dm9upZOi+fjhySsRzJxno4SkOfcPeIs8/jM0wmF 7ovc3jIOR39VskzIb40u3l1ZxyjsfxD8KtF7mhPpM49uGI8k99bTJMXyvr6bVxFqN/7N lOfcVRQiPWylx1lZIgrLfCLsZxAi67GvQ+aZ/qadCKHn/X1aiZceps3bzyTF+p5lAB/t v6tg== Received: by 10.69.0.10 with SMTP id au10mr16554687pbd.18.1352314327356; Wed, 07 Nov 2012 10:52:07 -0800 (PST) Received: from [130.129.17.203] (dhcp-11cb.meeting.ietf.org. [130.129.17.203]) by mx.google.com with ESMTPS id ug6sm6410610pbc.4.2012.11.07.10.52.04 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 10:52:06 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 07 Nov 2012 13:52:02 -0500 From: Victor Kuarsingh To: Ted Lemon Message-ID: Thread-Topic: [homenet] regarding recursive DHCPv6-PD In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:52:08 -0000 On 2012-11-07 1:43 PM, "Ted Lemon" wrote: >On Nov 7, 2012, at 6:53 PM, Victor Kuarsingh >wrote: >> I am not sure I would agree that getting a /64 would inherently mean a >> router knows is an intermediate router. There are potential scenarios >> where an edge router may get a /64 and be the ISP edge router (not the >> best case scenario, but potential). >> >> I know this subtle point is somewhat outside the context of this thread, >> but just wanted to make the point. > >Such a router has no prefixes to delegate, so the distinction is >immaterial. There can only be one non-translating router on this >network. This is why I said it's a point outside the context of the main discussion (addressing within the homenet). My point was more around what assumptions may be made by routers which do in fact get a /64. Assuming that routers in the homenet will likely be using similar code (both those that show up on the edge and those which are intermediate ones), other router functions may be automated, including what mode of operation the router takes (edge vs. IR). An example may be security and/or filtering policy. It's the assumption related to those other instances that had me worried. Regards, Victor Kuarsingh > From mellon@fugue.com Wed Nov 7 10:54:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE2B21F8AB5 for ; Wed, 7 Nov 2012 10:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP64UvfYaCbX for ; Wed, 7 Nov 2012 10:54:13 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1281E21F8A17 for ; Wed, 7 Nov 2012 10:54:11 -0800 (PST) Received: from dhcp-5438.meeting.ietf.org (dhcp-5438.meeting.ietf.org [130.129.84.56]) by toccata.fugue.com (Postfix) with ESMTPSA id C6E8F23815D6; Wed, 7 Nov 2012 13:54:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <20121107182125.GQ1927048@jupiter.n2.diac24.net> Date: Wed, 7 Nov 2012 19:54:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1499) Cc: Simon Kelley , homenet@ietf.org Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:54:14 -0000 On Nov 7, 2012, at 7:21 PM, David Lamparter wrote:=3D= > This really falls apart when I'm using 2 ISPs with 2 exit routers. > a-k-a, "Where's up? Why does it fail? The system I described will wind up relaying to both = delegating routers. From mellon@fugue.com Wed Nov 7 10:58:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4255B21F8AB8 for ; Wed, 7 Nov 2012 10:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHTOABs9ImKu for ; Wed, 7 Nov 2012 10:58:41 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id DE1A421F8A8F for ; Wed, 7 Nov 2012 10:58:41 -0800 (PST) Received: from dhcp-5438.meeting.ietf.org (dhcp-5438.meeting.ietf.org [130.129.84.56]) by toccata.fugue.com (Postfix) with ESMTPSA id 53F2523815D6; Wed, 7 Nov 2012 13:58:36 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Wed, 7 Nov 2012 19:58:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3155E3E1-3D25-4C55-B141-5434F0134E4D@fugue.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:58:42 -0000 On Nov 7, 2012, at 7:52 PM, Victor Kuarsingh = wrote: > Assuming that routers in the homenet will likely be > using similar code (both those that show up on the edge and those = which > are intermediate ones), other router functions may be automated, = including > what mode of operation the router takes (edge vs. IR). An example may = be > security and/or filtering policy. In the solution I'm talking about, you don't use similar code=97you use = the _same_ code. Realistically, CPE routers are all going to be = essentially the same=97there isn't going to be enough customer = understanding to give rise to a market for second-hop homenet routers = with different software. From equinox@diac24.net Wed Nov 7 11:00:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C321F8C12 for ; Wed, 7 Nov 2012 11:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrmkbIkfhuSM for ; Wed, 7 Nov 2012 11:00:36 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1283521F8A8F for ; Wed, 7 Nov 2012 11:00:34 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TWArU-0005Cy-EL; Wed, 07 Nov 2012 20:00:28 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1TWArD-00A7fv-A4; Wed, 07 Nov 2012 20:00:14 +0100 Date: Wed, 7 Nov 2012 14:00:11 -0500 From: David Lamparter To: Ted Lemon Message-ID: <20121107190011.GU1927048@jupiter.n2.diac24.net> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Simon Kelley , homenet@ietf.org, David Lamparter Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:00:37 -0000 On Wed, Nov 07, 2012 at 07:54:09PM +0100, Ted Lemon wrote: > On Nov 7, 2012, at 7:21 PM, David Lamparter wrote:= > > This really falls apart when I'm using 2 ISPs with 2 exit routers. > > a-k-a, "Where's up? > > Why does it fail? The system I described will wind up relaying to both delegating routers. I was only saying that this doesn't create a central point for naming information, not that it wouldn't work at all. As I've said in my other mail, you end up going back to some election mechanism, and from there it's easier to just stick with OSPFv3 (and apply the nicer solutions provided by that across all areas) instead of creating a new protocol. -David From mellon@fugue.com Wed Nov 7 11:08:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7698D21F86A1 for ; Wed, 7 Nov 2012 11:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYWbuF7-QJIX for ; Wed, 7 Nov 2012 11:08:16 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 869E821F8B8E for ; Wed, 7 Nov 2012 11:08:13 -0800 (PST) Received: from dhcp-5438.meeting.ietf.org (dhcp-5438.meeting.ietf.org [130.129.84.56]) by toccata.fugue.com (Postfix) with ESMTPSA id C60E523815D6; Wed, 7 Nov 2012 14:08:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <20121107190011.GU1927048@jupiter.n2.diac24.net> Date: Wed, 7 Nov 2012 20:08:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1499) Cc: Simon Kelley , homenet@ietf.org Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:08:19 -0000 On Nov 7, 2012, at 8:00 PM, David Lamparter wrote: > As I've said in my other mail, you end up going back to some election > mechanism, and from there it's easier to just stick with OSPFv3 (and > apply the nicer solutions provided by that across all areas) instead = of > creating a new protocol. Just to be clear here, my original point was never that we should switch = and use DHCP PD within the homenet. It was simply that DHCP PD would = work for delegating prefixes in the homenet, and that the sub-delegation = problem isn't actually a problem. If OSPF in fact solves the name = aggregation problem, that's great, but I don't think it's quite and cut = and dried as you are saying, and so I wanted to make sure that the = limitations of DHCP PD were not being misunderstood. I suspect that there might be some value in a combination of DHCP PD and = OSPF, but if OSPF really delivers all the functionality of DHCP PD, then = maybe I'm wrong. From teco@inf-net.nl Wed Nov 7 11:45:10 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC021F8AB5 for ; Wed, 7 Nov 2012 11:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0ZYCB-guiQg for ; Wed, 7 Nov 2012 11:45:05 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5FB21F8C08 for ; Wed, 7 Nov 2012 11:45:05 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1510632pbb.31 for ; Wed, 07 Nov 2012 11:45:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=88c2fwLQZ1+lUK8m/JFPqji4r3U0xYqRr2sMX3kyeNs=; b=a6JeHu5knpBIjXfgccXcWMnIfNA5SHJ7OAyBcMYtmeGOoaV5W8TupMm5uOLWEA1yLC PYoodqlI6gWr1/LACgptPak19Hx71S7ltdgJL4MfhCvWpQcIZB6xUnBLcaXVwrwShf3g dD9A39/WaEFmgZdh5NPM2JR5EteBdg0jE23KfiiisJdWy5Lu+TPzTJ/UAv9CNt6521u/ vZeBGNgT93zR/i7ZTkV4YcLRqVU6VC3K/yx8NbW9qOjAzrA5HF+QqE8tg8jCQsDFZzaG LQ2HERLSxYiMyQ4mqJC79YmaZ2z8woJvdH+SlBq6f+TvWKV9URLqp3xJ7YtacEIM2UOf bxrQ== Received: by 10.68.217.201 with SMTP id pa9mr16777424pbc.45.1352317505336; Wed, 07 Nov 2012 11:45:05 -0800 (PST) Received: from ?IPv6:2001:df8::16:3d5a:8112:356:3b91? ([2001:df8:0:16:3d5a:8112:356:3b91]) by mx.google.com with ESMTPS id k9sm14734232paz.22.2012.11.07.11.45.03 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 11:45:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E48FE3B-9249-49A1-8062-22F26859A56A" From: Teco Boot In-Reply-To: <13AB4EA2-9BC0-4994-BCB0-B1D382AA3C6D@danyork.org> Date: Wed, 7 Nov 2012 20:45:02 +0100 Message-Id: <50FCA48B-D03D-40F1-9FB8-C420E41E0E32@inf-net.nl> References: <13AB4EA2-9BC0-4994-BCB0-B1D382AA3C6D@danyork.org> To: Dan York X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm4xEVWv2TOpG/idnp5yzPVUyM2JNBdGuHLiLDfAcZsue2Cmggl+P9rUWrL5TiCnMU42GJw Cc: homenet@ietf.org Subject: Re: [homenet] Security question related to draft-boot-homenet-brdp-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:45:10 -0000 --Apple-Mail=_3E48FE3B-9249-49A1-8062-22F26859A56A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Op 7 nov. 2012, om 16:39 heeft Dan York het volgende geschreven: > Teco, >=20 > I am participating in IETF 85 remotely and Lee Howard went to the mic = in today's session to relay this question (thanks, Lee!). However, I = did not hear any answer. My question is: > ---- > Has any security analysis been done on the approach suggested in = draft-boot-homenet-brdp? Not in detail. BRDP runs on ND RA, and inherits much of it. That said, BRIO is = dissemination is multi-hop. This has impact. > Is any security analysis planned? I see the Security Considerations = section of the draft is "TBD" but on a brief read of the draft I worry = an attacker could misuse it. There are mechanisms protecting roque RAs. Or have security at sub-IP. > ---- >=20 > For instance, an immediate question in my mind was whether an attacker = could somehow inject an advertisement with the "D" flag off and causing = internal routers to believe that the Border Router is NOT acting as a = DHCP server? Could an attacker inject modified BRIOs to, for instance, = modify the cost of routes? Yes, thinks can happen. I do not see much difference with other attacks = on RA. >=20 > Are these valid concerns? Or are they protected against by other = mechanisms? I don't know. >=20 > For someone new to reading this draft, it would be helpful to have = some commentary in "Security Considerations" about how secure this = proposal is. Agreed. As said, cleanup is needed. A next version will have the = Security Considerations. Hopefully the -01. Teco >=20 > Just my 2 cents, > Dan >=20 > --=20 > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork >=20 >=20 >=20 --Apple-Mail=_3E48FE3B-9249-49A1-8062-22F26859A56A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
 Is any security analysis planned? =  I see the Security Considerations section of the draft is "TBD" = but on a brief read of the draft I worry an attacker could misuse = it.
There are mechanisms protecting roque = RAs. Or have security at sub-IP.

Yes, thinks can happen. I do not see = much difference with other attacks on RA.


Are = these valid concerns?  Or are they protected against by other = mechanisms? I don't know.

For someone new to = reading this draft, it would be helpful to have some commentary in = "Security Considerations" about how secure this proposal = is.
Agreed. As said, cleanup is needed. A next = version will have the Security Considerations.  Hopefully the = -01.

Teco



Just = my 2 cents,
Dan

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork


= --Apple-Mail=_3E48FE3B-9249-49A1-8062-22F26859A56A-- From teco@inf-net.nl Wed Nov 7 11:50:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820521F8BBE for ; Wed, 7 Nov 2012 11:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i7u8--hIMcX for ; Wed, 7 Nov 2012 11:50:26 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6462721F8C00 for ; Wed, 7 Nov 2012 11:50:26 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1465544pad.31 for ; Wed, 07 Nov 2012 11:50:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qn82zfZ4C59daQrPfQtc5EWEch3ZsBC7yRLPElJWwqs=; b=m3CiGR9M8NBlID6PPVuU0uTXhUzHAwIwl4yj71575Yph1UE2bqRnerdeoLmIrNkjGB RnPUC0yTtXkjTlsd8fE2IyUurYeXIZGzMFYb9/N0tvShhg7le74K4N8LI9niuZntyv9c eS+XP1fpL8Cr54BsV28SCagV19aJeKb5ja7Esq2flogHQ8edPwXT0k01AguUKfdc7Syf LB9NExj8xUye05IY9k2A82PD0FwPLvurS1azzLQhjmITStRudUzTW/SPeNYzX1ElaXdE 1CM/Q48VYsHnD215lrFQ1kosN4B0JCPFYcrKfxl8uxtW8xlPjo7BXsIQ9Ae/3p9W0QDQ PNIw== Received: by 10.68.191.1 with SMTP id gu1mr16809717pbc.150.1352317826150; Wed, 07 Nov 2012 11:50:26 -0800 (PST) Received: from ?IPv6:2001:df8::16:3d5a:8112:356:3b91? ([2001:df8:0:16:3d5a:8112:356:3b91]) by mx.google.com with ESMTPS id nd6sm14572675pbc.68.2012.11.07.11.50.24 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 11:50:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> Date: Wed, 7 Nov 2012 20:50:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl2MqeavTeQtz9KQyjundzcR9hNfswD8e5zmuTNDBufqvOil30xaVr/pYvGhFtoP2eUWZae Cc: "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:50:27 -0000 This should be in the homenet-arch, I think. It sounds so obvious to me, that I described this in a short text in = BRDP: A Router should request a prefix for attached subnetworks, with DHCP-PD [RFC3633], where there is at that moment no on-link prefix for a selected Border Router. I could make the should a MUST. Teco Op 7 nov. 2012, om 16:46 heeft Ted Lemon het volgende geschreven: > I don't have a particular preference for DHCP-PD over OSPF in = homenets, but I just wanted to quickly contradict what's been said by = several people at the mic: that figuring out what prefix to delegate is = hard. It's not hard, actually=97it's dead easy. The reason folks = think it's hard is because they're solving the wrong problem. >=20 > The problem that needs to be solved is how we number each home subnet. = The answer to this question is, "with a /64." There is no other = answer. You never want to number a subnet with a /52. Therefore, the = delegating router should never delegate anything but a /64. Problem = solved. >=20 > I think the disconnect here is that people are thinking the routers to = which prefixes are delegated need to themselves be delegating routers, = but this is incorrect. What they need to do is _relay_ prefix = delegation requests to the delegating router from which they got their = own delegation. >=20 > This scales to multi-homing with multiple delegating routers=97you = just relay every PD request upstream to all delegating routers. >=20 > I'd be happy to write a draft that describes how this works if someone = actually wants it; I get the sense that people are pretty in love with = the OSPF solution and would prefer not to be distracted, and I have no = argument with that if that's the working group consensus. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Wed Nov 7 11:54:10 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD321F8C92 for ; Wed, 7 Nov 2012 11:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwMDb9YDlU5x for ; Wed, 7 Nov 2012 11:54:09 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9B3821F8C90 for ; Wed, 7 Nov 2012 11:54:09 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so869422dan.31 for ; Wed, 07 Nov 2012 11:54:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ElJEYtMEYGZ0sgW+um+ojrnDExwxzd9ttytPn8ZtHDE=; b=c6DJU0aBVZAHzMSkdiIDMTmxLKmRmPYA1IdP2LAerbmco2Z3Hg7H/afCR3RRf2hzUi +anqkYjhrLP1HSsYWL9PPZkjlUlAJuu7R+i4lNWQ9ltw1DsrlsPgBQFLczBJwvajpVCF sFXLwY4UHF8raxA+cKQff7sjHm23ANDAUf/vk0xTo+Dc83jjZ/72Ez8xgnd4r+RRlueF q/w3/EOTVTd5Cd8ExYUSlmagB7L8BBWO4fqU7jzheMLejqXmxq1ycfUpDKEfahGTFdjs ZZT1uekhZwmg7aJqCQgYAJpdfB8HjOPHrN+9NGIPUszph3IMqANifzETTPIc661Z3jSy dGtg== Received: by 10.66.86.101 with SMTP id o5mr15478711paz.15.1352318049011; Wed, 07 Nov 2012 11:54:09 -0800 (PST) Received: from dhcp-1616.meeting.ietf.org (dhcp-1616.meeting.ietf.org. [130.129.22.22]) by mx.google.com with ESMTPS id mt15sm14581070pbc.49.2012.11.07.11.54.07 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 11:54:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <07098242-84C5-4F72-BB86-405E081ABC15@employees.org> Date: Wed, 7 Nov 2012 20:54:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9FD57629-21EB-4660-9121-2BA1F044C56C@inf-net.nl> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <07098242-84C5-4F72-BB86-405E081ABC15@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlbuUQRBASfrH4570e7785toHojtSxoGygVNBbyOyAIO6LntjEKecxtpHaf0xHBWYiFQcd7 Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:54:10 -0000 Op 7 nov. 2012, om 16:59 heeft Ole Tr=F8an het volgende geschreven: > Ted, >=20 > this has been proposed a few times. the problems that I see with it = are: > - in an arbitrary topology how do you decide which interfaces you are = a client on and which interfaces you relay on > - how do you handle the case where multiple routers try to assign a = prefix to a link > - how do you discover the DHCPv6 servers > - how do you handle the case with multiple sources of information = (multi-homing) >=20 > the OSPF based prefix assignment handle all of these, "out of the = starting blocks". It has little to do with OSPF. It is about the flooded TLV with info on = border routers. BRDP does exactly the same here.=20 Teco >=20 > cheers, > Ole >=20 >> I don't have a particular preference for DHCP-PD over OSPF in = homenets, but I just wanted to quickly contradict what's been said by = several people at the mic: that figuring out what prefix to delegate is = hard. It's not hard, actually=97it's dead easy. The reason folks = think it's hard is because they're solving the wrong problem. >>=20 >> The problem that needs to be solved is how we number each home = subnet. The answer to this question is, "with a /64." There is no = other answer. You never want to number a subnet with a /52. = Therefore, the delegating router should never delegate anything but a = /64. Problem solved. >>=20 >> I think the disconnect here is that people are thinking the routers = to which prefixes are delegated need to themselves be delegating = routers, but this is incorrect. What they need to do is _relay_ prefix = delegation requests to the delegating router from which they got their = own delegation. >>=20 >> This scales to multi-homing with multiple delegating routers=97you = just relay every PD request upstream to all delegating routers. >>=20 >> I'd be happy to write a draft that describes how this works if = someone actually wants it; I get the sense that people are pretty in = love with the OSPF solution and would prefer not to be distracted, and I = have no argument with that if that's the working group consensus. >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Wed Nov 7 12:01:53 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B4621F8CD6 for ; Wed, 7 Nov 2012 12:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsuuN-wiA2-N for ; Wed, 7 Nov 2012 12:01:53 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id E891221F8CC2 for ; Wed, 7 Nov 2012 12:01:52 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1473760pad.31 for ; Wed, 07 Nov 2012 12:01:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9YOWjutbjXgh077CrT/76/cw8RbTMys3euWRIPN5C8E=; b=bx/5t1hZ9HRtr1RXgBmFbgszZz74urm1m4PGh5BHhW+ZLLRQILmPed+vjb19RQElJK OK6oov9j+vAYs+i//YZvqOfOAKdT5hB512E/3gEGvHzpbP2iHTt1ijn2SBDGKfs8LCEp QhSynBj3Hgh3o05YR1zcmgXWmpGzPSz1aZ7v9cTFpdWgH2KXaYBocTomCjYp+KcFc77X uzr37s57r1bocnqR+JrVdPIz6hY6OkO2sGcXfqeyraDqlhZENWS3Uqs5CVQScKz3Pynh 01mcYnzCrtVGhnSoeSzciBLQyKggdE11ngIBDOMoq4d3cMGW8g1hMHudqxit5Zins6gD a11w== Received: by 10.66.84.40 with SMTP id v8mr15391646pay.47.1352318512577; Wed, 07 Nov 2012 12:01:52 -0800 (PST) Received: from dhcp-1616.meeting.ietf.org (dhcp-1616.meeting.ietf.org. [130.129.22.22]) by mx.google.com with ESMTPS id kc4sm14595536pbc.23.2012.11.07.12.01.50 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 12:01:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <509AA8A2.8070102@thekelleys.org.uk> Date: Wed, 7 Nov 2012 21:01:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68EF256B-297C-414C-9609-E854D5B15CB4@inf-net.nl> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <509AA8A2.8070102@thekelleys.org.uk> To: Simon Kelley X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnzMcl7LoVZvdU7gYP3JGt7/TCqZjEXcAdXA9B3bPW8tAMZHVxleaR/b8HGvGU2r6ScRBf9 Cc: homenet@ietf.org Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:01:53 -0000 Op 7 nov. 2012, om 19:29 heeft Simon Kelley het volgende geschreven: > On 07/11/12 18:21, David Lamparter wrote: >> On Wed, Nov 07, 2012 at 06:03:52PM +0000, Simon Kelley wrote: >>> On 07/11/12 15:46, Ted Lemon wrote: >>>=20 >>>> I think the disconnect here is that people are thinking the routers >>>> to which prefixes are delegated need to themselves be delegating >>>> routers, but this is incorrect. What they need to do is _relay_ >>>> prefix delegation requests to the delegating router from which they >>>> got their own delegation. >>>>=20 >>>=20 >>> ... and once the delegating routers are relaying DHCP-PD requests, = they >>> can also relay DHCP address-lease requests to the DHCP server in the = CPE >>> router. This puts all the information about DHCP leases and = associated >>> names in one place, and greatly simplifies the naming problem. >>=20 >> This really falls apart when I'm using 2 ISPs with 2 exit routers. >> a-k-a, "Where's up?" >=20 > and be put back together by noting that 2 exit routers doesn't have to = mean 2 DHCPv6 servers. A single DHCP server can take PDs from 2 or more = upstream ISPs. If the problem is that exit routers come with DHCPv6 = servers, then adding the ability to disable all but one (automatically = or manually) would be worth considering. Multi-homing could be used for redundancy. Having a single DHCP server = would not be the preferred choice here.=20 Teco >=20 > Simon. >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From ajs@anvilwalrusden.com Wed Nov 7 12:51:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9162621F8C3E for ; Wed, 7 Nov 2012 12:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx97yqO5hlOS for ; Wed, 7 Nov 2012 12:51:48 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1907A21F8C27 for ; Wed, 7 Nov 2012 12:51:47 -0800 (PST) Received: from crankycanuck.ca (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 262BF8A031 for ; Wed, 7 Nov 2012 20:51:47 +0000 (UTC) Date: Wed, 7 Nov 2012 15:51:34 -0500 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20121107205133.GE75182@crankycanuck.ca> References: <20121107163120.GN74706@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:51:48 -0000 Out of order: On Wed, Nov 07, 2012 at 05:46:20PM +0000, Griffiths, Chris wrote: > As an operator who is deploying > home network platforms to millions of customers today, I politely > disagree that this problem is nearly solved today in shipping > products, but could be solved with existing platforms and protocols > which desperately needs documentation. Yeah, that's probably a fairer description of what I was trying to say, and I appreciate the correction. > which desperately needs documentation.. Given the proposed > architecture for Homenet, and the ability to have multiple layers of > networks, there is going to be a need for a scaled approach to deal > with internal and external naming which will need to include service > discovery and publishing naming to outside the home. This I strongly agree with. Mostly, I am worried that this proposal is a cure worse than the disease. I've read the draft several times, and I just don't get why it isn't better to put all this DNS data out in a public DNS server somewhere, and have everything (including the nodes inside the homenet boundary) query that. If you want to reduce traffic, put a DNS cacheing resolver on the CPE. Use a simple-minded http-based injection protocol for DNS data that the CPE can use (we have several of those deployed, although none is an IETF protocol). The proposal as it stands includes support for different views; for mixed-mode authoritative and recursive services in the same resolver, something we regularly say is a bad thing; and three options for securing zone transfers, one of which we heard in mdnsext is the barrier to adoption of unicast DNS DNS-SD. Many of these tricks -- views in particular -- work only most of the time when careful administrators set the whole thing up, and so I'm worried that we're not going to be able to build automatic tools that allow this all to work completely reliably, _especially_ when inside the homenet most of the time people will actually get mDNS answers anyway and so there'll be a mismatch between the name spaces. It's mostly the complexity of all of this that troubles me. How much of it is necessary? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From andrewmcgr@gmail.com Wed Nov 7 13:25:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7700421F8AF0 for ; Wed, 7 Nov 2012 13:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfYQU5i-CBrd for ; Wed, 7 Nov 2012 13:25:58 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 137DA21F8889 for ; Wed, 7 Nov 2012 13:25:58 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so902861dan.31 for ; Wed, 07 Nov 2012 13:25:57 -0800 (PST) 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:x-mailer; bh=7trA11jX3u050IQv8A9VCyB16BhlgmI/JN6+D2SDuac=; b=nHJ4AsmkaLVeKrUlelZYMQurIxAQXyw3C10YkLVjXk3S6wH/nZ4VJuf+FjM7XHFRcx H6re5FA19xDNRxP/509qe6mbGM6LEVpI73SrL/ygrBh2RJJwdsFuY6nqEErq8t2EMwgA UOs+0YN9zMDgh4fPxX4USBSNbZqhh6DuL3znxauDD4UZV7uKrtauDziVEx6jI928+pp9 CpefB8v58TIs429jPrth7gK9zigfSJKguIyOMoTZ4VYmLUQUys7tKCCXIcL7F6EvcPJq lksKYg0Bp+DKY7zAX0auF+O78ZRr05v2Z9iJVTyShDD2dq71AgGc6B/Lz6mQW0DUDbMc 9vwg== Received: by 10.66.85.138 with SMTP id h10mr16000098paz.40.1352323557754; Wed, 07 Nov 2012 13:25:57 -0800 (PST) Received: from ?IPv6:2001:df8::64:8134:abdb:c93a:91d6? ([2001:df8:0:64:8134:abdb:c93a:91d6]) by mx.google.com with ESMTPS id v9sm14852997paz.6.2012.11.07.13.25.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 13:25:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: Date: Wed, 7 Nov 2012 16:25:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0E274AE2-7037-4AD4-A018-06D00EB95320@gmail.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:25:58 -0000 On 7/11/2012, at 12:32 PM, Ted Lemon wrote: > On Nov 7, 2012, at 5:23 PM, Andrew McGregor = wrote: >> But that's single-delegating-router, not recursive.=20 >=20 > What is a "recursive delegating router," and why do you want one? >=20 In general, I don't think you do. A recursive delegating router is one that will request a prefix, then = load that as configuration into its own DHCP server and accept = delegation requests from downstream, allocating out of that prefix. = It's feasible, but awkward. You could instead, as I understood you were = intending, run as a relay and forward downstream delegations instead. I still think the OSPF solution is better for homenet. Andrew= From mglt.ietf@gmail.com Wed Nov 7 14:33:47 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1320F21F8431 for ; Wed, 7 Nov 2012 14:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJvFyEclX86y for ; Wed, 7 Nov 2012 14:33:46 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0590521F8232 for ; Wed, 7 Nov 2012 14:33:45 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2394059oag.31 for ; Wed, 07 Nov 2012 14:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=15ngTDKNHvCHyfGyC4yvegB4FrSjnxtu5K7onBcc9TM=; b=HBk77q9YLaYILGBkm4a0SQjT3bH53mOLCAj19c4JKcefaBRMTzvh9gwxHeEBgHjsp+ nU5bvw9LBj9IuGPv8TBoSUpaJ7hzSxWiGWs0XvXe6b8fIh8GTdiPVGpOkUZbFz9KSpSc XYA+O0ipUSUGbDUTO/qxFOplrWrdnjL4zYnhxNTzDu4HkwJfkVFwuYg0iuKve5bR8R3U sw53T1+mC9R81oo3J71Iy+bmOH2fl+YEyPthtmiCsbBbWVhDy1GyC7lZFwksebjl0U/F dGSrYxVHSAx3Ye3dvqTRSAbRMjez4A94zjWaPo+wmQZFhmqES74kRXidBSHOMqKeXTd0 VUlg== MIME-Version: 1.0 Received: by 10.60.7.6 with SMTP id f6mr3304079oea.138.1352327625375; Wed, 07 Nov 2012 14:33:45 -0800 (PST) Received: by 10.76.153.130 with HTTP; Wed, 7 Nov 2012 14:33:45 -0800 (PST) In-Reply-To: <20121107205133.GE75182@crankycanuck.ca> References: <20121107163120.GN74706@mx1.yitter.info> <20121107205133.GE75182@crankycanuck.ca> Date: Wed, 7 Nov 2012 17:33:45 -0500 Message-ID: From: Daniel Migault To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e89a8fb2017abb010504cdef4f9b Cc: homenet@ietf.org Subject: Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:33:47 -0000 --e89a8fb2017abb010504cdef4f9b Content-Type: text/plain; charset=ISO-8859-1 Hi Andrew, Thank you for your comments, we are considering them for the next version. I am answering in the text. Mostly, I am worried that this proposal is a cure worse than the > disease. I've read the draft several times, and I just don't get why > it isn't better to put all this DNS data out in a public DNS server > somewhere, and have everything (including the nodes inside the homenet > boundary) query that. The architecture document recommends not to outsource everything in a server outside the homenet. 3.7.3 . Name spaces It is desirable that only one name space is in use in the homenet, and that this name space is served authoritatively by a server in the homenet, most likely resident on the CER. This is actually the only way to provide the Service Naming resolution in case the connectivity of the homenet to the Internet is down. 3.7.5 . Independent operation Name resolution and service discovery for reachable devices must continue to function if the local network is disconnected from the global Internet, e.g. a local media server should still be available even if the Internet link is down for an extended period. > If you want to reduce traffic, put a DNS > cacheing resolver on the CPE. The goal is not to reduce the traffic but to avoid exposing the CPE to resource exhaustion by hosting a DNS service on the CPE. However caching the Resolver may be in some case be a way to replace the what we designated as the Homenet Authoritative Server. Of course the diagram should be considered as a functional diagram. We will clarify this in the next version thanks for the remark. > Use a simple-minded http-based > injection protocol for DNS data that the CPE can use (we have several > of those deployed, although none is an IETF protocol). > If I understand correctly, you use an http-base protocol to fill the CPE with the appropriated DNS data. In fact we are doing the reverse. The CPE has the data and injects the DNS Data to the Public Server, so that it can properly perform the DNS authoritative service. Then filling may not be appropriated, since we need to properly manage the Public Server with appropriated data (updating information checking versions...). These requirements are addressed by IETF defined protocols, benefit from multiple implementations and a lot of experience. We do not see any reasons to do something different. On the other hand, we may also provide some alternatives, for specific use cases. We will do that in the next version, feel free to send these use cases on the Mailing list. The proposal as it stands includes support for different views; for > mixed-mode authoritative and recursive services in the same resolver, > something we regularly say is a bad thing; In the most common case, the DNS zone hosted by the CPE is only requested by the Resolver. The diagram should be considered as a functional diagram. In most common cases, the Authoritative Server will be more like a file or cached in the resolving server. Thanks for the remark, we will clarify this in the next version. However you are right that in some case the Authoritative Server will be hosted by the CPE. We still believe it is more realistic to host the Resolving Server and the Authoritative Server on a same device, than to ask the End User to have an additional box for their Authoritative Server. Port binding, firewall rules on that boxe probably match the BCP. The main advantage of having this configured in the box is that most of the misconfiguration issues may be avoided. and three options for > securing zone transfers, one of which we heard in mdnsext is the > barrier to adoption of unicast DNS DNS-SD. Many of these tricks -- > views in particular -- work only most of the time when careful > administrators set the whole thing up, and so I'm worried that we're > not going to be able to build automatic tools that allow this all to > work completely reliably, _especially_ when inside the homenet most of > the time people will actually get mDNS answers anyway and so there'll > be a mismatch between the name spaces. It's mostly the complexity of > all of this that troubles me. > Views are optional. Can you provide specific scenarios we need to address? > > How much of it is necessary? > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --e89a8fb2017abb010504cdef4f9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew,=A0

Thank you for your comments, we are considering them for the next ver= sion. I am answering in the text.=A0

Mostly, I am worried that this proposal is a cure worse than the
disease. =A0I've read the draft several times, and I just don't get= why
it isn't better to put all this DNS data out in a public DNS server
somewhere, and have everything (including the nodes inside the homenet
boundary) query that. =A0

The architecture = document recommends not to outsource everything in a server outside the hom= enet.
=


3.7.3.  Name spaces


   It is desirable that only one name space is in use in the homenet,
   and that this name space is served authoritatively by a server in the
   homenet, most likely resident on the CER.

This is actually the only way to provide the Service Naming resolution in = case the connectivity of the homenet to the Internet is down.=A0



3.7.5.  Independent operation


   Name resolution and service discovery for reachable devices must
   continue to function if the local network is disconnected from the
   global Internet, e.g. a local media server should still be available
   even if the Internet link is down for an extended period.

=A0
If you want to reduce traffic, put a DNS
cacheing resolver on the CPE.

The goal is n= ot to reduce the traffic but to avoid exposing the CPE to resource=A0exhaus= tion=A0by hosting a DNS service on the CPE. However caching the Resolver ma= y be in some case be a way to replace the what we designated as the Homenet= Authoritative Server. Of course the diagram should be considered as a func= tional diagram. We will clarify this in the next version thanks for the rem= ark.
=A0=A0
=A0=A0
=A0Use a simple-minde= d http-based
injection protocol for DNS data that the CPE can use (we have several
of those deployed, although none is an IETF protocol).
=A0
If I understand correctly, you use an http-base protocol to = fill the CPE with the appropriated DNS data. In fact we are doing the rever= se. The CPE has the data and injects the DNS Data to the Public Server, so = that it can properly perform the DNS authoritative service.=A0

Then filling may not be appropriated, since we need to = properly manage the Public Server with appropriated data (updating=A0inform= ation=A0 checking versions...). These requirements are addressed by IETF de= fined protocols, benefit from multiple implementations and a lot of experie= nce. We do not see any reasons to do something different. On the other hand= , we may also provide some alternatives, for specific use cases. We will do= that in the next version, feel free to send these use cases on the Mailing= list.=A0
=A0

The proposal as it stands includes support for different views; for
mixed-mode authoritative and recursive services in the same resolver,
something we regularly say is a bad thing;

= In the most common case, the DNS zone hosted by the CPE is only requested b= y the Resolver. The diagram should be considered as a functional diagram. I= n most common cases, the Authoritative Server will be more like a file or c= ached in the resolving server. Thanks for the remark, we will clarify this = in the next version.

However you are right that in some case the Authoritati= ve Server will be hosted by the CPE. We still believe it is more realistic = to host the Resolving Server and the Authoritative Server on a same device,= than to ask the End User to have an additional box for their Authoritative= Server. Port binding, firewall rules on that boxe probably match the BCP. = The main advantage of having this configured in the box is that most of the= misconfiguration issues may be avoided.
=A0

and three options for
securing zone transfers, one of which we heard in mdnsext is the
barrier to adoption of unicast DNS DNS-SD. =A0Many of these tricks --
views in particular -- work only most of the time when careful
administrators set the whole thing up, and so I'm worried that we'r= e
not going to be able to build automatic tools that allow this all to
work completely reliably, _especially_ when inside the homenet most of
the time people will actually get mDNS answers anyway and so there'll be a mismatch between the name spaces. =A0It's mostly the complexity of=
all of this that troubles me.

Views are= optional. Can you provide specific scenarios we need to address?
=A0

How much of it is necessary?

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
___________________________________= ____________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



--
= Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--e89a8fb2017abb010504cdef4f9b-- From ajs@anvilwalrusden.com Wed Nov 7 15:11:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF0421F86D4 for ; Wed, 7 Nov 2012 15:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BWWae-75vFV for ; Wed, 7 Nov 2012 15:11:36 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96921F8508 for ; Wed, 7 Nov 2012 15:11:36 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 13FE98A031 for ; Wed, 7 Nov 2012 23:11:35 +0000 (UTC) Date: Wed, 7 Nov 2012 18:11:26 -0500 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20121107231126.GB75372@mx1.yitter.info> References: <20121107163120.GN74706@mx1.yitter.info> <20121107205133.GE75182@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:11:36 -0000 On Wed, Nov 07, 2012 at 05:33:45PM -0500, Daniel Migault wrote: > The architecture document recommends not to outsource everything in a > server outside the homenet. Well, yes, but note also that it says that you want only one name space. This requirement is _certainly_ going to be violated in the medium term, because everyone is using mDNS and there's no evidence that anyone is ready to back off their plans (the zigbee guys are cleaving to it). The draft as it stands seems to imagine that what people will use is one namespace, and it'll be DNS. Ten years ago, I might have said, "Could happen." Today, it's impossible. We are going to have two namespaces here. (Yes, a complete review of -arch- is on my TODO. After today's meeting, at least I've moved it higher in the list.) > This is actually the only way to provide the Service Naming resolution in > case the connectivity of the homenet to the Internet is down. That is a good point. It might be emphasised more strongly in the draft, unless I'm just missing it (which is possible). > The goal is not to reduce the traffic but to avoid exposing the CPE to > resource exhaustion by hosting a DNS service on the CPE. However caching > the Resolver may be in some case be a way to replace the what we designated > as the Homenet Authoritative Server. Yeah, that's pretty much what I had in mind. But such a cache wouldn't solve your "disconnected operation" problem. > If I understand correctly, you use an http-base protocol to fill the CPE > with the appropriated DNS data. In fact we are doing the reverse. The CPE > has the data and injects the DNS Data to the Public Server, so that it can > properly perform the DNS authoritative service. Actually, Dyn (for instance -- full disclosure, they paid for my trip here) takes updates from many end points via an http-based API. This is for information that goes into global DNS servers. Yes, we could do this with Dynamic Update, but that involves a more complicated security model that is poorly understood by the sort of developers who often work on the end point code. Telling them, "use TLS and HTTP" allows them to pick up libraries that we are reasonably confident are well-developed as opposed to writing code to do TSIG. > In the most common case, the DNS zone hosted by the CPE is only requested > by the Resolver. The diagram should be considered as a functional diagram. > In most common cases, the Authoritative Server will be more like a file or > cached in the resolving server. Thanks for the remark, we will clarify this > in the next version. Well, it's like a file that is interpreted by a server that can send DNS responses. I agree the uses aren't manifold, but it's still a mixed authoritative/recursive server as far as the client is concerned. Maybe we've decided that for this case, that's good enough, but since it's at odds with some experience we've had with the DNS more generally, it's worth noting it. > Views are optional. Can you provide specific scenarios we need to address? My personal view is that views are hateful, but many people seem to think it's important to hide names when one isn't authorized to use them. In any case, you're undoubtedly going to need views wherever there's a NAT and v4. A -- Andrew Sullivan ajs@anvilwalrusden.com From teco@inf-net.nl Wed Nov 7 15:14:29 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D829B21F84FC for ; Wed, 7 Nov 2012 15:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4dlUwg+m-qc for ; Wed, 7 Nov 2012 15:14:25 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2A2821F89A3 for ; Wed, 7 Nov 2012 15:14:25 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so940257dan.31 for ; Wed, 07 Nov 2012 15:14:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QFFF6ky28La0GaeEVMVqM763LwaXJSlkPK+fJ186KxA=; b=YP+QPbNSSXOR8WaBwCMdGKZETpCm7NvO6L3wZiczP0+xbOfQ6r6jzgDtXS67NS1qc7 N1Ukibus9KcbxVovGBRSW7nBiX64ZJNSocplCkOwwtpBVSQu5mrQX22BjSdajJsR/QKi Gq+EVzvkqL4ceFYoBy9ogM9SyC3ATG6d0m61wbtnRFCvkQiXpeggC3sohYYxpGmCbkFd 8Se919DX8jaJTKkOkYfZeL8JwyWGr8aa1TZxJfxaGizf6rJ80JJtwd+VB90kEaj/kv1r k+JGpJwzSaewfulinx5GgjvXP1hFACHUykyQAcTbPPiaeOGbQvMpa7pj6/g/4bAXxMyW ESpQ== Received: by 10.68.227.162 with SMTP id sb2mr18602870pbc.4.1352330065344; Wed, 07 Nov 2012 15:14:25 -0800 (PST) Received: from ?IPv6:2001:df8::16:a4f2:ad12:226c:fd0c? ([2001:df8:0:16:a4f2:ad12:226c:fd0c]) by mx.google.com with ESMTPS id az8sm14973414pab.24.2012.11.07.15.14.23 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 15:14:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Teco Boot In-Reply-To: <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> Date: Thu, 8 Nov 2012 00:14:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com>, <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> To: "Ole Troan (otroan)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlv3GMg/Z6dWiJAp4V6ocrX9q70y9VqqKzcnv0GcpDK14wLe8n4B76H/1r+43uBv0V6EdFh Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:14:30 -0000 Op 7 nov. 2012, om 23:33 heeft Ole Troan (otroan) het volgende = geschreven: >=20 >=20 > On 7 Nov 2012, at 14:50, "Teco Boot" wrote: >=20 >> This should be in the homenet-arch, I think. >>=20 >> It sounds so obvious to me, that I described this in a short text in = BRDP: >> A Router should request a prefix for attached subnetworks, with >> DHCP-PD [RFC3633], where there is at that moment no on-link prefix >> for a selected Border Router. >>=20 >> I could make the should a MUST. >=20 > Disagree. Hierarchical or flat PD (with relays) don't work for = multihomed sites, have problems with arbitrary topplogies etc.=20 I do not suggest hierarchical PD, nor flat PD with relays. Leaves open = flat PD without relay. Can you explain why this doesn't work? My thoughts were driving me to a more manageable situation, where the = CPE router manages all delegated prefixes for that ISP. CPE router can = be multi-homed, then the task is for each ISP. HW for deterministic = prefix configuration can be implemented on CPE router, or somewhere on = ISPs network. For ULA, one router is to be elected as "homenet manager". Here, a more = distributed approach could make sense. Still I think management of such = is unneeded complex and adds unneeded HW requirements on all routers = (need for non-volatile memory, for deterministic behavior). Related topic: IMHO non-CPE routers need a configuration for relaying = DHCP requests to the CPE routers. PD from CPE router doesn't add = complexity. Teco =20 >=20 > Cheers, > Ole >=20 >=20 >>=20 >> Teco >>=20 >> Op 7 nov. 2012, om 16:46 heeft Ted Lemon het volgende geschreven: >>=20 >>> I don't have a particular preference for DHCP-PD over OSPF in = homenets, but I just wanted to quickly contradict what's been said by = several people at the mic: that figuring out what prefix to delegate is = hard. It's not hard, actually=E2=80=95it's dead easy. The reason = folks think it's hard is because they're solving the wrong problem. >>>=20 >>> The problem that needs to be solved is how we number each home = subnet. The answer to this question is, "with a /64." There is no = other answer. You never want to number a subnet with a /52. = Therefore, the delegating router should never delegate anything but a = /64. Problem solved. >>>=20 >>> I think the disconnect here is that people are thinking the routers = to which prefixes are delegated need to themselves be delegating = routers, but this is incorrect. What they need to do is _relay_ prefix = delegation requests to the delegating router from which they got their = own delegation. >>>=20 >>> This scales to multi-homing with multiple delegating routers=E2=80=95y= ou just relay every PD request upstream to all delegating routers. >>>=20 >>> I'd be happy to write a draft that describes how this works if = someone actually wants it; I get the sense that people are pretty in = love with the OSPF solution and would prefer not to be distracted, and I = have no argument with that if that's the working group consensus. >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet From chris_griffiths@cable.comcast.com Wed Nov 7 15:30:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C7521F8B95 for ; Wed, 7 Nov 2012 15:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfZ9syI6IYVQ for ; Wed, 7 Nov 2012 15:30:09 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 84DF921F88FA for ; Wed, 7 Nov 2012 15:30:04 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.33353205; Wed, 07 Nov 2012 18:22:02 -0500 Received: from PACDCEXMB15.cable.comcast.com ([169.254.2.78]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 18:29:58 -0500 From: "Griffiths, Chris" To: Daniel Migault , Andrew Sullivan Thread-Topic: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 Thread-Index: AQHNvQVlzq/K7ni1TECdGRleJAaEuJfe+V+AgAAzvwCAAByNgIAAD7aA Date: Wed, 7 Nov 2012 23:29:57 +0000 Message-ID: References: <20121107163120.GN74706@mx1.yitter.info> <20121107205133.GE75182@crankycanuck.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.55.72] Content-Type: multipart/alternative; boundary="_000_FC97784E1B4396449E619F58B1738C1A2074A56DPACDCEXMB15cabl_" MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:30:16 -0000 --_000_FC97784E1B4396449E619F58B1738C1A2074A56DPACDCEXMB15cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 7, 2012, at 5:33 PM, Daniel Migault > wrote: Use a simple-minded http-based injection protocol for DNS data that the CPE can use (we have several of those deployed, although none is an IETF protocol). If I understand correctly, you use an http-base protocol to fill the CPE wi= th the appropriated DNS data. In fact we are doing the reverse. The CPE has= the data and injects the DNS Data to the Public Server, so that it can pro= perly perform the DNS authoritative service. Then filling may not be appropriated, since we need to properly manage the = Public Server with appropriated data (updating information checking versio= ns...). These requirements are addressed by IETF defined protocols, benefit= from multiple implementations and a lot of experience. We do not see any r= easons to do something different. On the other hand, we may also provide so= me alternatives, for specific use cases. We will do that in the next versio= n, feel free to send these use cases on the Mailing list. The way I read this was to use something similar to the several free / comm= ercial ASP services to publish to northbound public DNS platforms via HTTP = (I assume Dyn and others fall into this bucket). I don't disagree with thi= s approach currently, but am curious why we wouldn't simply leverage the DN= S protocol to perform these actions. Either of these components could be p= rimed to the Homenet gateway via configuration and/or automated. That bein= g said, would providing both options (DNS or HTTP) meet your thoughts here?= Certainly something we could add to the next version of the draft and I d= on't have a preference either way. The proposal as it stands includes support for different views; for mixed-mode authoritative and recursive services in the same resolver, something we regularly say is a bad thing; In the most common case, the DNS zone hosted by the CPE is only requested b= y the Resolver. The diagram should be considered as a functional diagram. I= n most common cases, the Authoritative Server will be more like a file or c= ached in the resolving server. Thanks for the remark, we will clarify this = in the next version. However you are right that in some case the Authoritative Server will be ho= sted by the CPE. We still believe it is more realistic to host the Resolvin= g Server and the Authoritative Server on a same device, than to ask the End= User to have an additional box for their Authoritative Server. Port bindin= g, firewall rules on that boxe probably match the BCP. The main advantage o= f having this configured in the box is that most of the misconfiguration is= sues may be avoided. I think something like mDNS and DNS-SD are an alternative to this approach.= I know Stuart Cheshire and team have wide area bonjour working quite nice= ly and could certainly fill this role and remove some complexity for design= . I am curious if the proposed work in MDNSEXT might help with this. and three options for securing zone transfers, one of which we heard in mdnsext is the barrier to adoption of unicast DNS DNS-SD. Many of these tricks -- views in particular -- work only most of the time when careful administrators set the whole thing up, and so I'm worried that we're not going to be able to build automatic tools that allow this all to work completely reliably, _especially_ when inside the homenet most of the time people will actually get mDNS answers anyway and so there'll be a mismatch between the name spaces. It's mostly the complexity of all of this that troubles me. Views are optional. Can you provide specific scenarios we need to address? How much of it is necessary? Agreed on multiple views, and curious how we can leverage mDNS and other se= rvice discovery mechanisms to generate and publish northbound. Something w= e certainly want to update the next draft with. --_000_FC97784E1B4396449E619F58B1738C1A2074A56DPACDCEXMB15cabl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <256EFA4C5777134EA04243D2C85F6F32@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On Nov 7, 2012, at 5:33 PM, Daniel Migault <mglt.ietf@gmail.com> wrote:

  
 Use a simple-minded http-based
injection protocol for DNS data that the CPE can use (we have several
of those deployed, although none is an IETF protocol).
 
If I understand correctly, you use an http-base protocol to fill the C= PE with the appropriated DNS data. In fact we are doing the reverse. The CP= E has the data and injects the DNS Data to the Public Server, so that it ca= n properly perform the DNS authoritative service. 

Then filling may not be appropriated, since we need to properly manage= the Public Server with appropriated data (updating information  = checking versions...). These requirements are addressed by IETF defined pro= tocols, benefit from multiple implementations and a lot of experience. We do not see any reasons to do something differe= nt. On the other hand, we may also provide some alternatives, for specific = use cases. We will do that in the next version, feel free to send these use= cases on the Mailing list. 

The way I read this was to use something similar to the several free / comm= ercial ASP services to publish to northbound public DNS platforms via HTTP = (I assume Dyn and others fall into this bucket).  I don't disagree wit= h this approach currently, but am curious why we wouldn't simply leverage the DNS protocol to perform these actions.=  Either of these components could be primed to the Homenet gateway vi= a configuration and/or automated.  That being said, would providing bo= th options (DNS or HTTP) meet your thoughts here?  Certainly something we could add to the next version of the dr= aft and I don't have a preference either way.



The proposal as it stands includes support for different views; for
mixed-mode authoritative and recursive services in the same resolver,
something we regularly say is a bad thing;

In the most common case, the DNS zone hosted by the CPE is only reques= ted by the Resolver. The diagram should be considered as a functional diagr= am. In most common cases, the Authoritative Server will be more like a file= or cached in the resolving server. Thanks for the remark, we will clarify this in the next version.

However you are right that in some case the Authoritative Server will = be hosted by the CPE. We still believe it is more realistic to host the Res= olving Server and the Authoritative Server on a same device, than to ask th= e End User to have an additional box for their Authoritative Server. Port binding, firewall rules on that b= oxe probably match the BCP. The main advantage of having this configured in= the box is that most of the misconfiguration issues may be avoided. <= /div>

I think something like mDNS and DNS-SD are an alternative to this appr= oach.  I know Stuart Cheshire and team have wide area bonjour working = quite nicely and could certainly fill this role and remove some complexity = for design. I am curious if the proposed work in MDNSEXT might help with this.


and three options for
securing zone transfers, one of which we heard in mdnsext is the
barrier to adoption of unicast DNS DNS-SD.  Many of these tricks -- views in particular -- work only most of the time when careful
administrators set the whole thing up, and so I'm worried that we're
not going to be able to build automatic tools that allow this all to
work completely reliably, _especially_ when inside the homenet most of
the time people will actually get mDNS answers anyway and so there'll
be a mismatch between the name spaces.  It's mostly the complexity of<= br> all of this that troubles me.

Views are optional. Can you provide specific scenarios we need to addr= ess?
 

How much of it is necessary?


Agreed on multiple views, and curious how we can leverage mDNS and oth= er service discovery mechanisms to generate and publish northbound.  S= omething we certainly want to update the next draft with.

--_000_FC97784E1B4396449E619F58B1738C1A2074A56DPACDCEXMB15cabl_-- From otroan@cisco.com Wed Nov 7 14:33:49 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E1021F8451 for ; Wed, 7 Nov 2012 14:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9rX7RPwcTEv for ; Wed, 7 Nov 2012 14:33:48 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8844C21F8232 for ; Wed, 7 Nov 2012 14:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2386; q=dns/txt; s=iport; t=1352327628; x=1353537228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9zbMa60i4oVOFHgn7dy9+CAyJB6Kh38TBzZdcpQPWjM=; b=V4bYrtNxFKdAzRIjEiRR0SCVvDHqxZiS00bnLCylc+X7QcUPKYPaFfZO 0w/iFkRtHEgO6vDGMiEasv90FF72TO+p1hXjY5udgycbXlp4luyb+6Fhv AVr+Z4nKv/P0sQNz/haP9YxLvhTv1wq7GFYFlJUn3AHp+39iJKQppL8c8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPLgmlCtJV2c/2dsb2JhbABEgmzAf4EIgh4BAQEDAQEBAQ8BWwsFCwIBCEYnCyUCBA4FGweHYgYBCpxBoDAEjA2FZmEDlXuOWYFrgm8 X-IronPort-AV: E=Sophos;i="4.80,732,1344211200"; d="scan'208";a="139915585" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2012 22:33:48 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA7MXmKf003064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 22:33:48 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 16:33:47 -0600 From: "Ole Troan (otroan)" To: Teco Boot Thread-Topic: [homenet] DHCP PD for homenets. Thread-Index: AQHNvSEu9dn07q5qA0G6K0eNrUJrupfe9aR7 Date: Wed, 7 Nov 2012 22:33:47 +0000 Message-ID: <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com>, <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> In-Reply-To: <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--44.397200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 07 Nov 2012 17:01:55 -0800 Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:33:49 -0000 On 7 Nov 2012, at 14:50, "Teco Boot" wrote: > This should be in the homenet-arch, I think. >=20 > It sounds so obvious to me, that I described this in a short text in BRDP= : > A Router should request a prefix for attached subnetworks, with > DHCP-PD [RFC3633], where there is at that moment no on-link prefix > for a selected Border Router. >=20 > I could make the should a MUST. Disagree. Hierarchical or flat PD (with relays) don't work for multihomed s= ites, have problems with arbitrary topplogies etc.=20 Cheers, Ole >=20 > Teco >=20 > Op 7 nov. 2012, om 16:46 heeft Ted Lemon het volgende geschreven: >=20 >> I don't have a particular preference for DHCP-PD over OSPF in homenets, = but I just wanted to quickly contradict what's been said by several people = at the mic: that figuring out what prefix to delegate is hard. It's not h= ard, actually=AFit's dead easy. The reason folks think it's hard is becau= se they're solving the wrong problem. >>=20 >> The problem that needs to be solved is how we number each home subnet. = The answer to this question is, "with a /64." There is no other answer. = You never want to number a subnet with a /52. Therefore, the delegating= router should never delegate anything but a /64. Problem solved. >>=20 >> I think the disconnect here is that people are thinking the routers to w= hich prefixes are delegated need to themselves be delegating routers, but t= his is incorrect. What they need to do is _relay_ prefix delegation reque= sts to the delegating router from which they got their own delegation. >>=20 >> This scales to multi-homing with multiple delegating routers=AFyou just = relay every PD request upstream to all delegating routers. >>=20 >> I'd be happy to write a draft that describes how this works if someone a= ctually wants it; I get the sense that people are pretty in love with the O= SPF solution and would prefer not to be distracted, and I have no argument = with that if that's the working group consensus. >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Wed Nov 7 18:03:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2955121F8A55 for ; Wed, 7 Nov 2012 18:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3rBtUCovVCj for ; Wed, 7 Nov 2012 18:03:18 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B3BEC21F86E4 for ; Wed, 7 Nov 2012 18:03:18 -0800 (PST) Received: from dhcp-47bf.meeting.ietf.org (dhcp-47bf.meeting.ietf.org [130.129.71.191]) by toccata.fugue.com (Postfix) with ESMTPSA id 9A15923814F1; Wed, 7 Nov 2012 21:03:11 -0500 (EST) Content-Type: text/plain; charset=windows-1253 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> Date: Wed, 7 Nov 2012 21:03:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72D1D555-D465-4C90-8D6E-D402A4BFEFC2@fugue.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com>, <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> To: "Ole Troan (otroan)" X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Teco Boot , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 02:03:19 -0000 On Nov 7, 2012, at 5:33 PM, "Ole Troan (otroan)" = wrote: > Disagree. Hierarchical or flat PD (with relays) don't work for = multihomed sites, have problems with arbitrary topplogies etc.=20 You said this before, but you didn't describe any arbitrary topology in = which PD wouldn't work. Could you do that, please? To be clear, although a PD topology is always hierarchical with respect = to the relationship between any given requesting router and its = delegating router(s), this does not mean that the topology of the = homenet is a hierarchy. Let me give you an example. Suppose you have a CPE router, A, at the = customer edge. And you have two homenet routers, B and C, each with an = interface connected to A. And you have a fourth homenet router, D, = with an interface connected to B and one connected to C (I'm assuming = direct twisted-pair ethernet links for simplicity). I think you are supposing that because D has two paths to A, it will = appear twice in the PD topology, even though it exists only once. But = that is not so. It is only attempting to configure one interface=97its = downstream interface. So the DUID and IAID will be the same in both = copies of the DHCP solicit that A gets. And so A will assign a single = prefix, not two. Suppose D is also a edge router. We are now multihomed; A will be a = requesting router with respect to D for the prefix that D got from its = ISP; D will still be a requesting router with respect to A for the = prefix that A got from its ISP. The relationships between B and C and = A, and between B and C and D, are likewise straightforward. I can diagram this out for you if you want, but hopefully that = illustrates the point I'm making. Are you thinking of an even more = contorted topology than this one? From teco@inf-net.nl Wed Nov 7 19:25:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B228821F8A91 for ; Wed, 7 Nov 2012 19:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpXLo6wz5fwz for ; Wed, 7 Nov 2012 19:25:03 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB221F8A8F for ; Wed, 7 Nov 2012 19:25:03 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id g10so528561ghb.31 for ; Wed, 07 Nov 2012 19:25:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2N4zXbmW9dd5iQfI5iqpzv0duHxGlyONzLfzV2/2jbc=; b=ZkIdg9tjq+OdW2IKiz61JO1/gSf3VMaM0FTh304dV0+PMpMPaLYblopy6WPkx9P8uF B3SCfZk36Bi0tFSBnCY6ncCaCQc6CiRyFW62tuiiFzbGqQQxH+yOIsU2L0UFNNxftv1y JIcO+g1/xAiIp4h8B0qs5gsciSkHNrqD0BNGwvUt/WP269wv/ZmmTzdLGHZ7H8D6Tdac Ohjg9WPtKbNA0yEyjIopq/1LOcVjQJvyNppI+Mcsqf7Y/1QCc80gwSvw5LsgbFcp/EEj n3ctNok8POOiJsnOVXkEa0gT1wTVxTCNGIyHY8Z/Lu0jyzrD8PPfkBRYTyUK2/KT8xd6 2R9w== Received: by 10.236.128.141 with SMTP id f13mr7152865yhi.52.1352345103342; Wed, 07 Nov 2012 19:25:03 -0800 (PST) Received: from dhcp-116a.meeting.ietf.org (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id g4sm8228346anj.3.2012.11.07.19.25.02 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 19:25:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <72D1D555-D465-4C90-8D6E-D402A4BFEFC2@fugue.com> Date: Thu, 8 Nov 2012 04:24:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2FB9BCF5-0D95-48DC-9709-96F52546DA9D@inf-net.nl> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com>, <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> <72D1D555-D465-4C90-8D6E-D402A4BFEFC2@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmUzIgrU75X52YRWl8rpihLc3RkXNJz3Gwx1mgP0mBy8eHtNSGkUsjODcdAuDtkLvYA1VHs Cc: "homenet@ietf.org Group" , "Ole Troan \(otroan\)" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 03:25:04 -0000 Op 8 nov. 2012, om 03:03 heeft Ted Lemon het volgende geschreven: > On Nov 7, 2012, at 5:33 PM, "Ole Troan (otroan)" = wrote: >> Disagree. Hierarchical or flat PD (with relays) don't work for = multihomed sites, have problems with arbitrary topplogies etc.=20 >=20 > You said this before, but you didn't describe any arbitrary topology = in which PD wouldn't work. Could you do that, please? >=20 > To be clear, although a PD topology is always hierarchical with = respect to the relationship between any given requesting router and its = delegating router(s), this does not mean that the topology of the = homenet is a hierarchy. >=20 > Let me give you an example. Suppose you have a CPE router, A, at the = customer edge. And you have two homenet routers, B and C, each with an = interface connected to A. And you have a fourth homenet router, D, = with an interface connected to B and one connected to C (I'm assuming = direct twisted-pair ethernet links for simplicity). >=20 > I think you are supposing that because D has two paths to A, it will = appear twice in the PD topology, even though it exists only once. But = that is not so. It is only attempting to configure one interface=97its = downstream interface. So the DUID and IAID will be the same in both = copies of the DHCP solicit that A gets. And so A will assign a single = prefix, not two. I would say that in case D doesn't have an additional interface, it = doesn't request a prefix. It just autoconfigures one global address, = although it may configure addresses on both links (to B and C). And I suggest that if D requests a prefix, for an additional interface, = it uses unicast to A, with an autoconfigured address. So A receives only = one request. Teco >=20 > Suppose D is also a edge router. We are now multihomed; A will be a = requesting router with respect to D for the prefix that D got from its = ISP; D will still be a requesting router with respect to A for the = prefix that A got from its ISP. The relationships between B and C and = A, and between B and C and D, are likewise straightforward. >=20 > I can diagram this out for you if you want, but hopefully that = illustrates the point I'm making. Are you thinking of an even more = contorted topology than this one? >=20 From teco@inf-net.nl Wed Nov 7 20:18:50 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7799921F89E5 for ; Wed, 7 Nov 2012 20:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0ipg6FImaAd for ; Wed, 7 Nov 2012 20:18:50 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E669921F89B5 for ; Wed, 7 Nov 2012 20:18:49 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so519504yhq.31 for ; Wed, 07 Nov 2012 20:18:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=S14cBtU8oaGF7iWWeJD0bekm5jSSosc3jZO/Vg4WxHQ=; b=hbrtJJuoDWKJF5+h2x4Vfbn7IKWGqLYGkty1mcInI5+v4mwiJXl32UHkQ0lnw8vkwq pGDH3h9ADcZOm/t7n1oDcPcGhtRac1lC1nSKCdkaJB2AK4N52VfCiXgENrcWmsgG9r69 sX19wNjT03fFo+3Oj6Si63c8R3nJuONZEBLjR4SH4EoKEKuHNpcTCVZHxXJz9gUCX8qg gQVhmuEzoRULjmKFGV7pzs8DSsiyyPJKldY+6d4cE7XmjxsJUP6M51KAslyQgAgcPjDP 13V8vt7tbc5TN2ruYGdkTwTUb2eayET9+M13HKaU5Za5t/1IVHJou6arkj9PsReuO2D6 3J2Q== Received: by 10.236.76.132 with SMTP id b4mr7047912yhe.106.1352348329224; Wed, 07 Nov 2012 20:18:49 -0800 (PST) Received: from dhcp-116a.meeting.ietf.org (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id k63sm25890376yhj.20.2012.11.07.20.18.48 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 20:18:48 -0800 (PST) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 05:18:46 +0100 Message-Id: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmRg7y2Mmrlvd3GUVRXNwaLiO/BDe83pz0ivTuoLkK9uM8+2Z/rszmao8mYSXIT7o+4Fzrn Subject: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 04:18:50 -0000 I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the proposal = doesn't meet expectations of users, with regard of protocol convergence. = The default timers are far too conservative. First reconfig on OSPF = router in my hands is adjust timers on high speed interfaces to hello=3D1 = and dead=3D4. This is a bit better than what old days bridges with STP = do. Minor: the timers are not defaults. These are sample values. I have seen = routers with different defaults than RFC 5340, for certain interface = types. For autoconfig OSPF, I prefer removal of the restriction that all = routers on a link MUST use same timers. That provides flexibility like = OLSR. If this is not possible because of reasons for DR selection, I = suggest removal of DR completely and configure all interfaces in P2MP. = Or MANET interface type, if we want to. Question is: which MANET = extension. [posted here, because requirements come from Homenet] Teco= From Carl.Wuyts@technicolor.com Thu Nov 8 00:35:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C58021F88EE for ; Thu, 8 Nov 2012 00:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRoPAm0wQPTC for ; Thu, 8 Nov 2012 00:35:16 -0800 (PST) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id C75C821F88E9 for ; Thu, 8 Nov 2012 00:35:11 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKUJtusxGcSkXBpFdAc6rfMn3W8n3hzs7V@postini.com; Thu, 08 Nov 2012 00:35:15 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 09:34:20 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.89]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Thu, 8 Nov 2012 09:34:31 +0100 From: Wuyts Carl To: Mikael Abrahamsson , Andrew McGregor Date: Thu, 8 Nov 2012 09:34:31 +0100 Thread-Topic: [homenet] regarding recursive DHCPv6-PD Thread-Index: Ac29EqRFKi7yM/2yRB+HVcC5dgLX1QAeRZHw Message-ID: <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Ted Lemon , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 08:35:16 -0000 Well, being a residential CPE vendor, I can confirm some of our customers d= eploy /64 only to the CPE. Not recommended by us, but being a managed CPE, it's the customer making th= e final decision on this. Regs Carl -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Mikael Abrahamsson Sent: woensdag 7 november 2012 19:07 To: Andrew McGregor Cc: homenet@ietf.org Group; Ted Lemon; Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD On Wed, 7 Nov 2012, Andrew McGregor wrote: > But that's single-delegating-router, not recursive. The problem with=20 > recursive is figuring out what prefix length a sub-delegating router=20 > is going to ask for from its upstream. For a single-delegating-router=20 > setup, you just ask for either a bunch of /64s or something that just=20 > contains enough of those to cover all your downstream interfaces. In=20 > a recursive situation, you don't know what you will need further=20 > downstream. For me, I've always taken for granted that the ISP CPE gets a /56 or someth= ing, and then it's fine to subdelegate /64s out of that as needed, and subd= elegating routers request a /64 at a time as needed, and relay for sub-sub-= delegating routers (as OP suggested). The hard part is to get the source based routing to work so that packets fl= owing upstream exit via the correct ISP CPE (if the home is multihomed to m= ultiple ISPs) depending on what source address they have, so as to avoid ge= tting dropped by uRPF filters. I'm surprised the subnet allocation size is still being discussed, I haven'= t followed the working group as closely as I should, but I hope we can get = through this quickly. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From Carl.Wuyts@technicolor.com Thu Nov 8 00:46:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E7D21F88F4 for ; Thu, 8 Nov 2012 00:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rja+eRTy+JWX for ; Thu, 8 Nov 2012 00:46:07 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3D21F888C for ; Thu, 8 Nov 2012 00:45:27 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUJtxIDlBH88JcNvys6L/R1R7uv34KAPu@postini.com; Thu, 08 Nov 2012 00:46:07 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 09:40:43 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.89]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 8 Nov 2012 09:40:50 +0100 From: Wuyts Carl To: Ted Lemon , David Lamparter Date: Thu, 8 Nov 2012 09:40:49 +0100 Thread-Topic: [homenet] DHCP PD for homenets. Thread-Index: Ac29G0P6at+fmV6QRWuXbfnbqddMDgAcPvoA Message-ID: <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> In-Reply-To: <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Kelley , "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 08:46:08 -0000 Well, I've not followed all of the homenet discussions on this PD-story, bu= t I see a lot of referral to OSPF (v3), so it seems to be assumed that all = these CPEs must "talk" OSPF ? I think lots of them in the field today are low-end, low memory devices, he= nce probably 1. no OSPF will be present and 2. Calculating SP might put qui= te some pressure on its capabilities, no ? I might be wrong on this one, so please disregard if this comment is not ap= plicable. Regs Carl -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Ted Lemon Sent: woensdag 7 november 2012 20:08 To: David Lamparter Cc: Simon Kelley; homenet@ietf.org Subject: Re: [homenet] DHCP PD for homenets. On Nov 7, 2012, at 8:00 PM, David Lamparter wrote: > As I've said in my other mail, you end up going back to some election=20 > mechanism, and from there it's easier to just stick with OSPFv3 (and=20 > apply the nicer solutions provided by that across all areas) instead=20 > of creating a new protocol. Just to be clear here, my original point was never that we should switch an= d use DHCP PD within the homenet. It was simply that DHCP PD would work f= or delegating prefixes in the homenet, and that the sub-delegation problem = isn't actually a problem. If OSPF in fact solves the name aggregation pro= blem, that's great, but I don't think it's quite and cut and dried as you a= re saying, and so I wanted to make sure that the limitations of DHCP PD wer= e not being misunderstood. I suspect that there might be some value in a combination of DHCP PD and OS= PF, but if OSPF really delivers all the functionality of DHCP PD, then mayb= e I'm wrong. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From swmike@swm.pp.se Thu Nov 8 01:48:07 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720D821F8892 for ; Thu, 8 Nov 2012 01:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mciImeoNMIv for ; Thu, 8 Nov 2012 01:48:07 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 928AC21F869E for ; Thu, 8 Nov 2012 01:48:05 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63C659C; Thu, 8 Nov 2012 10:48:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5D2AE9A; Thu, 8 Nov 2012 10:48:02 +0100 (CET) Date: Thu, 8 Nov 2012 10:48:02 +0100 (CET) From: Mikael Abrahamsson To: Wuyts Carl In-Reply-To: <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> Message-ID: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org Group" , Ted Lemon , Ralph Droms , Andrew McGregor Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 09:48:07 -0000 On Thu, 8 Nov 2012, Wuyts Carl wrote: > Well, being a residential CPE vendor, I can confirm some of our > customers deploy /64 only to the CPE. Not recommended by us, but being a > managed CPE, it's the customer making the final decision on this. If they only give the end user a /64, then the end customer won't be able to have a multi-LAN routed home. Hopefully the end customer will switch ISPs to one that isn't so restrictive. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 8 01:50:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C188E21F88E9 for ; Thu, 8 Nov 2012 01:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r-bvPstpXy6 for ; Thu, 8 Nov 2012 01:50:36 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 45C6921F878D for ; Thu, 8 Nov 2012 01:50:36 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C65E9C; Thu, 8 Nov 2012 10:50:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7FA199A; Thu, 8 Nov 2012 10:50:35 +0100 (CET) Date: Thu, 8 Nov 2012 10:50:35 +0100 (CET) From: Mikael Abrahamsson To: Wuyts Carl In-Reply-To: <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> Message-ID: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Simon Kelley , "homenet@ietf.org" , Ted Lemon , David Lamparter Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 09:50:36 -0000 On Thu, 8 Nov 2012, Wuyts Carl wrote: > I think lots of them in the field today are low-end, low memory devices, > hence probably 1. no OSPF will be present and 2. Calculating SP might > put quite some pressure on its capabilities, no ? We're talking tens or at max, hundreds of routes (/56 means 256 routes, times a few ISPs). This worked on hardware deployed in the field in the middle of 90ties, shouldn't devices produced today (or tomorrow) be able to do the same thing? I don't see current devices being able to be sw upgraded to handle the demands we're talking about here anyway. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Thu Nov 8 03:41:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C1A21F8B51 for ; Thu, 8 Nov 2012 03:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrzXfNSjkZBs for ; Thu, 8 Nov 2012 03:41:19 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3272E21F8B50 for ; Thu, 8 Nov 2012 03:41:19 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2058641pad.31 for ; Thu, 08 Nov 2012 03:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YLieHGP3jO3xj2BdT4O/SUfX8s2LoSfEVpXgbv6dVeQ=; b=NuDGp2H8irkUbkmPGwv3MgOGRgTmoTKgCq1NF8KtSfR2cTI9wnlQVVFWOwu6ZnetmH 0pATjcM8squ2sl/0CzuwJI3yXWAMGBrxGp/pSFOuyOv0nZmV8mAzIhqY8lsamzGktbVM 7R5Vw2mdT0C6j9UJPRHiNJNmAbU1rH4vnlWo9PA4hljNj60zhPlteBZ55L2YZ30xx/ad M71ECR0y1bdfKtgikHWQk21DQKrpO6gkevoQ6KagFIEAm1czWRD0XcpIP96Z0j/r5KFj LmeqMwwT0vIf0tiznil7uPDB3Fx9qxIGUNKZPpKK+f3YL2a1cNdTtb8rOlIKPSP85ynB 4a6w== Received: by 10.68.83.68 with SMTP id o4mr23500135pby.25.1352374878915; Thu, 08 Nov 2012 03:41:18 -0800 (PST) Received: from [130.129.67.234] (dhcp-43ea.meeting.ietf.org. [130.129.67.234]) by mx.google.com with ESMTPS id vs3sm15819709pbc.61.2012.11.08.03.41.16 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 03:41:17 -0800 (PST) Message-ID: <509B9A66.1060903@gmail.com> Date: Thu, 08 Nov 2012 11:41:26 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Andrew McGregor , Ted Lemon , Wuyts Carl , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 11:41:20 -0000 On 08/11/2012 09:48, Mikael Abrahamsson wrote: > On Thu, 8 Nov 2012, Wuyts Carl wrote: > >> Well, being a residential CPE vendor, I can confirm some of our >> customers deploy /64 only to the CPE. Not recommended by us, but being >> a managed CPE, it's the customer making the final decision on this. > > If they only give the end user a /64, then the end customer won't be > able to have a multi-LAN routed home. Hopefully the end customer will > switch ISPs to one that isn't so restrictive. Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says "Please find a new ISP"? This is not intended as a frivolous question. Brian From Carl.Wuyts@technicolor.com Thu Nov 8 03:48:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0643921F88EF for ; Thu, 8 Nov 2012 03:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYEjrq17l8g4 for ; Thu, 8 Nov 2012 03:48:19 -0800 (PST) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37321F8ACD for ; Thu, 8 Nov 2012 03:48:15 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKUJub0sOQCXwhv09jg77exnRADhQeIw3l@postini.com; Thu, 08 Nov 2012 03:48:19 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 12:45:20 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.89]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Thu, 8 Nov 2012 12:45:31 +0100 From: Wuyts Carl To: Mikael Abrahamsson Date: Thu, 8 Nov 2012 12:45:30 +0100 Thread-Topic: [homenet] DHCP PD for homenets. Thread-Index: Ac29loSLI+KVD05LS2mzWX8oUeODpgAAGglw Message-ID: <867F4B6A1672E541A94676D556793ACD1B66C8EA96@MOPESMBX01.eu.thmulti.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Kelley , "homenet@ietf.org" , Ted Lemon , David Lamparter Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 11:48:21 -0000 Well, indeed things have been running for a long time, even in the 90's, bu= t (for some reason) in today's world, the CPE should be as low cost as poss= ible, resulting in cheaper chipsets and restricted memory. On top of the 9= 0's content, they also now have to include lots of extra's like samba shari= ng etc, so hard to compare. I'm not saying that it is not possible on today's hardware, I only say that= most of the (residential devices at least) today, have no OSPF support inc= luded anyway. Changing them might be an option, but contradicts a little w= ith the fact that no-one wants to pay for it. It's the same for IPv6-intro= in fact. Some CPE hardware must be replaced, but who will take the bill ?= ? It was already a discussion in this year's IPv6 world congress, still seems= to be an issue as far as I can see. Maybe the attitude might change due t= o homenet architecture, but not sure it will. Regs Carl -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Mikael Abrahamsson Sent: donderdag 8 november 2012 10:51 To: Wuyts Carl Cc: Simon Kelley; homenet@ietf.org; Ted Lemon; David Lamparter Subject: Re: [homenet] DHCP PD for homenets. On Thu, 8 Nov 2012, Wuyts Carl wrote: > I think lots of them in the field today are low-end, low memory=20 > devices, hence probably 1. no OSPF will be present and 2. Calculating=20 > SP might put quite some pressure on its capabilities, no ? We're talking tens or at max, hundreds of routes (/56 means 256 routes, tim= es a few ISPs). This worked on hardware deployed in the field in the middle= of 90ties, shouldn't devices produced today (or tomorrow) be able to do th= e same thing? I don't see current devices being able to be sw upgraded to handle the dema= nds we're talking about here anyway. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Thu Nov 8 03:57:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAF21F8B6C for ; Thu, 8 Nov 2012 03:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGHrW+3Oa-Is for ; Thu, 8 Nov 2012 03:57:16 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D591921F8B6A for ; Thu, 8 Nov 2012 03:57:14 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id i4so550897ggn.31 for ; Thu, 08 Nov 2012 03:57:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=VBvy68CIftDjO3z6MVSVFfJthi0jq7GJ5gThH6waY+0=; b=mVA45Nyii+I/msizYH414McYdRJNPkxn4XG9Tr/T2DOENzrSIlxZrf9cTeCkeQhN8o VwhNvQs5uOUvqpnb1QdZGowSWmXNyH08Rt1ChPhCLYDhTAEgTzwH21SIPg3rmSqQjLhe fkBz4Tq8QlzuZOx5iipN/aJUPUoI+9a3SFQOiXzScunA3TRVl150OTTVpXFH3pRDWcZW EBqTm6h7VxyWAthQr7M5/ZU7GVsvu36IscgyJlfuPSdzTvtOyjfOslYXq9nZoTsEIqcJ Dj4JZSRqVlDmyToD0Os0ysi4Cza8w7jMxJ9Zo3NwMes2UX8YGEsTiAxyxNf1nmEmIE94 dp4Q== Received: by 10.236.86.43 with SMTP id v31mr8113948yhe.62.1352375833963; Thu, 08 Nov 2012 03:57:13 -0800 (PST) Received: from [10.71.9.248] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id s1sm24277023anj.1.2012.11.08.03.57.13 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 03:57:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Thu, 8 Nov 2012 12:57:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3016E3D9-476A-4266-A1A4-81B811989C13@inf-net.nl> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQk1Lp2SDsEoZzb9M8lvvDD1hdskR2ewSs8kXrn7fzSCpBTZtJ/afnfsEPYuhi4OPUFOkq9y Cc: Simon Kelley , "homenet@ietf.org" , Ted Lemon , Wuyts Carl , David Lamparter Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 11:57:16 -0000 Op 8 nov. 2012, om 10:50 heeft Mikael Abrahamsson het volgende = geschreven: > On Thu, 8 Nov 2012, Wuyts Carl wrote: >=20 >> I think lots of them in the field today are low-end, low memory = devices, hence probably 1. no OSPF will be present and 2. Calculating SP = might put quite some pressure on its capabilities, no ? >=20 > We're talking tens or at max, hundreds of routes (/56 means 256 = routes, times a few ISPs). This worked on hardware deployed in the field = in the middle of 90ties, shouldn't devices produced today (or tomorrow) = be able to do the same thing? >=20 > I don't see current devices being able to be sw upgraded to handle the = demands we're talking about here anyway. I hope I misunderstand. If current CPE router and WiFi AP cannot be = upgraded to what we are talking about, we are on a dead end. Teco >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From Carl.Wuyts@technicolor.com Thu Nov 8 04:03:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6A521F8B57 for ; Thu, 8 Nov 2012 04:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXo4R1Pzk3ka for ; Thu, 8 Nov 2012 04:03:03 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id DB48321F8B75 for ; Thu, 8 Nov 2012 04:02:18 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUJufSvEPmaWsMrRv9gIWjhindx6fKcQl@postini.com; Thu, 08 Nov 2012 04:03:03 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 13:00:58 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.89]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Thu, 8 Nov 2012 13:01:09 +0100 From: Wuyts Carl To: Teco Boot , Mikael Abrahamsson Date: Thu, 8 Nov 2012 13:01:08 +0100 Thread-Topic: [homenet] DHCP PD for homenets. Thread-Index: Ac29qDLL00OJzVWvQmW64rQOvSCcXQAAE5nQ Message-ID: <867F4B6A1672E541A94676D556793ACD1B66C8EAAD@MOPESMBX01.eu.thmulti.com> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> <3016E3D9-476A-4266-A1A4-81B811989C13@inf-net.nl> In-Reply-To: <3016E3D9-476A-4266-A1A4-81B811989C13@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Kelley , "homenet@ietf.org" , Ted Lemon , David Lamparter Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:03:04 -0000 Well, define "current". The ones deployed today and last year or so probably will not have a proble= m getting upgraded, and as we're managed CPE, this is well under control. = But there is a massive number of CPE devices in the field today which are i= ndeed not upgradable to an IP-capable firmware. Regs Carl p 8 nov. 2012, om 10:50 heeft Mikael Abrahamsson het volgende geschreven: > On Thu, 8 Nov 2012, Wuyts Carl wrote: >=20 >> I think lots of them in the field today are low-end, low memory devices,= hence probably 1. no OSPF will be present and 2. Calculating SP might put = quite some pressure on its capabilities, no ? >=20 > We're talking tens or at max, hundreds of routes (/56 means 256 routes, t= imes a few ISPs). This worked on hardware deployed in the field in the midd= le of 90ties, shouldn't devices produced today (or tomorrow) be able to do = the same thing? >=20 > I don't see current devices being able to be sw upgraded to handle the de= mands we're talking about here anyway. I hope I misunderstand. If current CPE router and WiFi AP cannot be upgrade= d to what we are talking about, we are on a dead end. Teco >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Thu Nov 8 04:05:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9C221F8B67 for ; Thu, 8 Nov 2012 04:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN944pwJj+su for ; Thu, 8 Nov 2012 04:05:17 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9021F8B61 for ; Thu, 8 Nov 2012 04:05:17 -0800 (PST) Received: from dhcp-5438.meeting.ietf.org (dhcp-5438.meeting.ietf.org [130.129.84.56]) by toccata.fugue.com (Postfix) with ESMTPSA id AFAAB2380477; Thu, 8 Nov 2012 07:05:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <509B9A66.1060903@gmail.com> Date: Thu, 8 Nov 2012 07:05:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: Ralph Droms , "homenet@ietf.org Group" , Andrew McGregor , Wuyts Carl , Mikael Abrahamsson Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:05:18 -0000 On Nov 8, 2012, at 6:41 AM, Brian E Carpenter = wrote: > Fine, but when such an end customer buys a second router and plugs it = in, > will she get an error message that says "Please find a new ISP"? In this case I think our only option is to fall back to bridging. From mellon@fugue.com Thu Nov 8 04:06:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AA421F8B67 for ; Thu, 8 Nov 2012 04:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qu6OjAOdl-j for ; Thu, 8 Nov 2012 04:06:18 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3B07421F8B61 for ; Thu, 8 Nov 2012 04:06:18 -0800 (PST) Received: from dhcp-5438.meeting.ietf.org (dhcp-5438.meeting.ietf.org [130.129.84.56]) by toccata.fugue.com (Postfix) with ESMTPSA id 2B43C238067D; Thu, 8 Nov 2012 07:06:17 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <2FB9BCF5-0D95-48DC-9709-96F52546DA9D@inf-net.nl> Date: Thu, 8 Nov 2012 07:06:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com>, <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> <72D1D555-D465-4C90-8D6E-D402A4BFEFC2@fugue.com> <2FB9BCF5-0D95-48DC-9709-96F52546DA9D@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , "Ole Troan \(otroan\)" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:06:18 -0000 On Nov 7, 2012, at 10:24 PM, Teco Boot wrote: > And I suggest that if D requests a prefix, for an additional = interface, it uses unicast to A, with an autoconfigured address. So A = receives only one request. No, it doesn't, because that's not what RFC3315 and RFC3633 say to do, = and it would badly break them to specify this behavior. There's no = harm in the duplicate packet, so no reason to break the protocol to = avoid it. From brian.e.carpenter@gmail.com Thu Nov 8 04:25:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2081521F8B6E for ; Thu, 8 Nov 2012 04:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t2-RAA5zcKp for ; Thu, 8 Nov 2012 04:25:13 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 417D421F8B17 for ; Thu, 8 Nov 2012 04:25:13 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2130968pbb.31 for ; Thu, 08 Nov 2012 04:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mu0RnKIGm266TFIqjenxpls3bBshOlsAhRLB9BnVeNY=; b=ynq0pnjVWrRxOl16kY7HBGgIGht7a34CVKOgA9yF1qWoFSM1Af0XSEjozqKHpsPUQF gZW6Rt5QAutpcCwQiPRTus08zAlv/Mopv4W8OiqNkRVvXcUfXxZj3XelZFRumX5FTyIw KIarH106SDCpo4i4/aqKWrMszO6GsHqe7hxy+JMc0QgU7xaR6OVHWoN2aUfsTAE3EiDm ndSwdM0o39n3qMEs+tTwsmoUwuLeXj0gCFIkkF5xaBXGKO1/iM3BNRWPHyW2+M92qNfb 0P9ZqXmG5ANAKjzWNmMyAErF/0K7liB4XFVe0ebBKNdAPFMQpnWqOnx2P1cL+F/KnI21 oHSw== Received: by 10.68.218.97 with SMTP id pf1mr23339658pbc.96.1352377513015; Thu, 08 Nov 2012 04:25:13 -0800 (PST) Received: from [130.129.67.234] (dhcp-43ea.meeting.ietf.org. [130.129.67.234]) by mx.google.com with ESMTPS id pq9sm15004047pbc.1.2012.11.08.04.25.09 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 04:25:10 -0800 (PST) Message-ID: <509BA4AF.2080308@gmail.com> Date: Thu, 08 Nov 2012 12:25:19 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ralph Droms , "homenet@ietf.org Group" , Andrew McGregor , Wuyts Carl , Mikael Abrahamsson Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:25:14 -0000 On 08/11/2012 12:05, Ted Lemon wrote: > On Nov 8, 2012, at 6:41 AM, Brian E Carpenter wrote: >> Fine, but when such an end customer buys a second router and plugs it in, >> will she get an error message that says "Please find a new ISP"? > > In this case I think our only option is to fall back to bridging. Without some fundamental surgery on the IPv6 specs, I fear that is true, so does it have to become (gulp) a feature of the homenet architecture? I would hate that but at the moment I see no alternative. There is another alternative, routed ULA within the homenet and NPTv6 at the border, but we've already said we don't want to recommend that. I think the following paragraph of the architecture document needs to be revised accordingly: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. Something like: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. Brian Brian From swmike@swm.pp.se Thu Nov 8 04:31:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B88E21F8802 for ; Thu, 8 Nov 2012 04:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfV0fwxyNF6k for ; Thu, 8 Nov 2012 04:31:35 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7547C21F87F7 for ; Thu, 8 Nov 2012 04:31:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 784659C; Thu, 8 Nov 2012 13:31:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7396B9A; Thu, 8 Nov 2012 13:31:33 +0100 (CET) Date: Thu, 8 Nov 2012 13:31:33 +0100 (CET) From: Mikael Abrahamsson To: Teco Boot In-Reply-To: <3016E3D9-476A-4266-A1A4-81B811989C13@inf-net.nl> Message-ID: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> <3016E3D9-476A-4266-A1A4-81B811989C13@inf-net.nl> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:31:36 -0000 On Thu, 8 Nov 2012, Teco Boot wrote: > I hope I misunderstand. If current CPE router and WiFi AP cannot be > upgraded to what we are talking about, we are on a dead end. I have zero illusion that any devices that have been purchased with minimum requirements for IPv4 only, giving the deal to whoever cuts the cost that last 10 cents, is going to be upgraded to do ANYTHING more than what was initially specified. I am however fairly confident that any CPE that was purchased in a way that assured that future functionality could be brought in, or is a premium product, will be able to support OSPF as well. Do you believe that we could even get DHCPv6-PD into such devices. I have been in contact with CPE manufacturers who make products that are actually mid-range, who say they do not have flash and memory to do what I feel is very basic IPv6 functionality. I think we should aim higher do what's best in the long run, and then CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 more than current generation, initially, but as these requirements spread and more people/ISPs buy, it'll be the new lowest standard and cost will drop. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 8 04:32:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A811F21F884C for ; Thu, 8 Nov 2012 04:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7h7zgjS8ZHt for ; Thu, 8 Nov 2012 04:32:16 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2D30E21F87F7 for ; Thu, 8 Nov 2012 04:32:16 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7C71F9C; Thu, 8 Nov 2012 13:32:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 778969A; Thu, 8 Nov 2012 13:32:15 +0100 (CET) Date: Thu, 8 Nov 2012 13:32:15 +0100 (CET) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: Message-ID: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Wuyts Carl , "homenet@ietf.org Group" , Ralph Droms , Andrew McGregor Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:32:16 -0000 On Thu, 8 Nov 2012, Ted Lemon wrote: > On Nov 8, 2012, at 6:41 AM, Brian E Carpenter wrote: >> Fine, but when such an end customer buys a second router and plugs it in, >> will she get an error message that says "Please find a new ISP"? > > In this case I think our only option is to fall back to bridging. Yes, doing protocol based brinding (L2 bridge 0x86dd packets) is the only way to go as far as I can tell. -- Mikael Abrahamsson email: swmike@swm.pp.se From mellon@fugue.com Thu Nov 8 04:56:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC85321F8B6C for ; Thu, 8 Nov 2012 04:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR+5IeqSPckU for ; Thu, 8 Nov 2012 04:56:26 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0721F8B6A for ; Thu, 8 Nov 2012 04:56:26 -0800 (PST) Received: from dhcp-47bf.meeting.ietf.org (dhcp-47bf.meeting.ietf.org [130.129.71.191]) by toccata.fugue.com (Postfix) with ESMTPSA id 24300238067D; Thu, 8 Nov 2012 07:56:24 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <509BA4AF.2080308@gmail.com> Date: Thu, 8 Nov 2012 07:56:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D2AD5A6-D7B6-4117-8275-0ADE47BAB5F3@fugue.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: Wuyts Carl , "homenet@ietf.org Group" , Mikael Abrahamsson , Ralph Droms , Andrew McGregor Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:56:26 -0000 On Nov 8, 2012, at 7:25 AM, Brian E Carpenter = wrote: > Without some fundamental surgery on the IPv6 specs, I fear that is = true, > so does it have to become (gulp) a feature of the homenet = architecture? I think it does, or the architecture becomes irrelevant because no-one = will be brave enough to ship boxes that implement it. And so we need = to specify how it happens. You are probably already aware that I strongly favor a routed ULA in the = homenet (as opposed to the "keep using the ISP prefix after it expires = kludge), but that doesn't solve this problem without NPTv6, which I = think is a terrible idea. Bridging preserves end-to-end; I think = that's far more important than preserving subnetting. That said, it would be nice if devices flashed a big red light or = something if the ISP-delegated prefix is a /64. I don't know of a way = to specify that in the document, though. Aside from the disagreement about ULA, I think your suggested = modification to the text is right=97the text as it is now recommends the = wrong workaround to brokenness. From dave.taht@gmail.com Thu Nov 8 04:57:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59221F8B7D for ; Thu, 8 Nov 2012 04:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bbwn1C-aA3D for ; Thu, 8 Nov 2012 04:57:40 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFE4B21F8B6E for ; Thu, 8 Nov 2012 04:57:39 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1744151eek.31 for ; Thu, 08 Nov 2012 04:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Oo5yI0lsRMUVi7WqrlZAslAgISLEyrNxsnzXNyUEIf8=; b=D1VKBKrqS2Hlxj4Aj7lgOjByc6mF8o1sqN97kBkHDczkdr6eF0i/deneDPyHzl0LEK Blu+1Hmx03WoqyBwQTqxilicfFz1VfPF6x6JZiHnByFxSIQUD7G4f4dJk2HiEc85A2qz 8a+YjRchog/z/52z0t2eYQM6Ihijg1J1xCnSq10aqo+4F+UHEdhNArsqloKbo1tzgJ77 E/qz/LkEM1mJyOfQ9tBISON3rnLp+3E3apJIbY6hFtgJoAW4oF++tOfymgYV7hNTPC7/ WO543uiIMVO8w/XctOIwNQhPZe5tp4EvjFCJv3M8K1LYD4Z6DNyA8LczJh9ArH1ulbPO wnvA== MIME-Version: 1.0 Received: by 10.14.174.194 with SMTP id x42mr27333919eel.22.1352379458843; Thu, 08 Nov 2012 04:57:38 -0800 (PST) Received: by 10.223.180.10 with HTTP; Thu, 8 Nov 2012 04:57:38 -0800 (PST) In-Reply-To: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> Date: Thu, 8 Nov 2012 13:57:38 +0100 Message-ID: From: Dave Taht To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , Andrew McGregor , Ted Lemon , Wuyts Carl , Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 12:57:41 -0000 On Thu, Nov 8, 2012 at 1:32 PM, Mikael Abrahamsson wrote= : > On Thu, 8 Nov 2012, Ted Lemon wrote: > >> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter >> wrote: >>> >>> Fine, but when such an end customer buys a second router and plugs it i= n, >>> will she get an error message that says "Please find a new ISP"? >> >> >> In this case I think our only option is to fall back to bridging. > > > Yes, doing protocol based brinding (L2 bridge 0x86dd packets) is the only > way to go as far as I can tell. Um, er, ah, no, for many years now there has been the AHCP + babeld, which routes /128s out of a /64 across any sort of wired/wireless network over as many hops as needed. I've been doing my best to ignore this discussion, and work on improving that code. You guys can beat your brains out over dhcp's approaches all you want, and expect your ISPs in a cloudy future to deliver something bigger than a /64 ... and bridge low speed wifi over high speed ethernet all you want - - but me, I kind of like being able to move transparently from AP to AP and from wired to wireless and back again, and to not need anything bigger than a /64 to do it. Given the trends towards excessive dynamicism throughout the IPv6 deployment, and the naming issues, and various ways proposed to monetize/make scarce /sub 64 allocations by the ISPS. I think the market will pick ipv6 nat and something like AHCP. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From acee.lindem@ericsson.com Thu Nov 8 05:03:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910EA21F87DE for ; Thu, 8 Nov 2012 05:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOAj0pRFAokd for ; Thu, 8 Nov 2012 05:03:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 071A921F87D4 for ; Thu, 8 Nov 2012 05:03:45 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA8D90UA031729; Thu, 8 Nov 2012 07:09:02 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 08:03:42 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 08:03:42 -0500 From: Acee Lindem To: Teco Boot Thread-Topic: [homenet] OSPFv3 timers Thread-Index: AQHNvWgxke9hRLx+j0u6WnNdeH5Ji5fgO/AA Date: Thu, 8 Nov 2012 13:03:41 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> In-Reply-To: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-70-410464002"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:03:46 -0000 --Apple-Mail-70-410464002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 7, 2012, at 11:18 PM, Teco Boot wrote: > I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the = proposal doesn't meet expectations of users, with regard of protocol = convergence. The default timers are far too conservative. First reconfig = on OSPF router in my hands is adjust timers on high speed interfaces to = hello=3D1 and dead=3D4. This is a bit better than what old days bridges = with STP do. This was not considered a requirement in the home. Refer to the section = 3.5 in the homenet architecture document.=20 > Minor: the timers are not defaults. These are sample values. I have = seen routers with different defaults than RFC 5340, for certain = interface types. I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >=20 > For autoconfig OSPF, I prefer removal of the restriction that all = routers on a link MUST use same timers. That provides flexibility like = OLSR. If this is not possible because of reasons for DR selection, I = suggest removal of DR completely and configure all interfaces in P2MP. = Or MANET interface type, if we want to. Question is: which MANET = extension. I'm not sure if there is a real requirement. Routers on the link need to = agree on the timer values lest we impact more of the protocol than = necessary. Hence, if this is required, the way forward would be for = routers on shared links to adopt the timers from their neighbor(s). For = simplicity, the same rules used for DR preference could be used.=20 Thanks, Acee >=20 > [posted here, because requirements come from Homenet] >=20 > Teco > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-70-410464002 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwODEzMDMzOVowIwYJKoZI hvcNAQkEMRYEFHh5E30x4H3dvUbt6WPFuTPtWI31MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgIPAI1WYr45s64A+EtxkUcKjR+c1JSjKMiiYkiL1ZOmkZ1+U0Z3tsKSakMZ6iIK7 rGEZs36nwsm7rT9F+F3Rt+TyonB7JntJO9e66WxfaTbikFgyT2MWudqS2OYUNTx6dClIHl94znZ3 ZcoNXvI5h88wYBV/IOhXExmEIZMrZAWZAAAAAAAA --Apple-Mail-70-410464002-- From Carl.Wuyts@technicolor.com Thu Nov 8 05:06:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5141621F8B77 for ; Thu, 8 Nov 2012 05:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB7fiXCzqgjM for ; Thu, 8 Nov 2012 05:06:34 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7058521F8B06 for ; Thu, 8 Nov 2012 05:06:34 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUJuuU4i+t64DTcZ7oRitnjzmQT7ONkKA@postini.com; Thu, 08 Nov 2012 05:06:34 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 14:03:45 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.89]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 8 Nov 2012 14:03:56 +0100 From: Wuyts Carl To: Brian E Carpenter , Mikael Abrahamsson Date: Thu, 8 Nov 2012 14:03:55 +0100 Thread-Topic: [homenet] regarding recursive DHCPv6-PD Thread-Index: Ac29pgmLauNgIHgbRBm+rZnKSReiIwAAsEyg Message-ID: <867F4B6A1672E541A94676D556793ACD1B66C8EAF2@MOPESMBX01.eu.thmulti.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> In-Reply-To: <509B9A66.1060903@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Ted Lemon , Ralph Droms , Andrew McGregor Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:06:35 -0000 Well of course not. Do you think they will be bothered by the fact that a = second router (from another ISP) is not working properly ? Please note, I'= m talking about managed CPE, not retail, that's another model. I do understand what you mean, but it is not that simple. It is also very = different in different countries. Competition is different, price is key a= nd some of them were told 20 years ago that the IPv4 address space was neve= r going to be an issue, still they are hit with v4-shortage, so handle from= a "safe" perspective. And no, you don't have to convince me that there ar= e plenty of v6 addresses, even when deploying /56 or something :-). They o= ften make a comparison: deploying IPv4, you get a single public IPv4 addre= ss on the box, while doing nat and private IP's, typically some /24 in the = LAN vs getting a /64 prefix for you own usage.... -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Brian E Carpenter Sent: donderdag 8 november 2012 12:41 To: Mikael Abrahamsson Cc: homenet@ietf.org Group; Andrew McGregor; Ted Lemon; Wuyts Carl; Ralph D= roms Subject: Re: [homenet] regarding recursive DHCPv6-PD On 08/11/2012 09:48, Mikael Abrahamsson wrote: > On Thu, 8 Nov 2012, Wuyts Carl wrote: >=20 >> Well, being a residential CPE vendor, I can confirm some of our=20 >> customers deploy /64 only to the CPE. Not recommended by us, but=20 >> being a managed CPE, it's the customer making the final decision on this= . >=20 > If they only give the end user a /64, then the end customer won't be=20 > able to have a multi-LAN routed home. Hopefully the end customer will=20 > switch ISPs to one that isn't so restrictive. Fine, but when such an end customer buys a second router and plugs it in, w= ill she get an error message that says "Please find a new ISP"? This is not intended as a frivolous question. Brian _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Thu Nov 8 05:20:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067E721F8BA5 for ; Thu, 8 Nov 2012 05:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db8uKAYlDQLb for ; Thu, 8 Nov 2012 05:20:45 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2154021F8BA4 for ; Thu, 8 Nov 2012 05:20:44 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2165071pbb.31 for ; Thu, 08 Nov 2012 05:20:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=fIT8oNkA30IqJYx93YOZ/sNyah/+nk1Q48vHOvvkmwk=; b=cAWsg3evzQjlBGO1ff6m2++zwwih9lFKwaLL8EbknoFKcyWBYLyKrBezTRVi7UV/38 dLiFfz52gWp1hme/2ly7p8uCbnZI7I47ZmxE1GsyX+nkn5NPi9+GGYSmLDvFGxzuTSGz oBdo3gJi3uozsZxV7cXgZrszjJV7OyMf/Dc0Lbs8AuY4AXn6zLmCoS/bEZFcI9Fdc/TQ l8GoQC+7WX8eOjA5UJB11tK6QFmbPazeAhMQ6wnMKZknfhPKp1Kl9SYMSBUoQaCFrBSn OsPXFh2KDKT6chICo/Ook+Q3s8IbBQlGehoMS+p9+FCjQE5/4DM3hX/2nGQuHciRqACt Ll4Q== Received: by 10.68.135.101 with SMTP id pr5mr23693893pbb.140.1352380844233; Thu, 08 Nov 2012 05:20:44 -0800 (PST) Received: from ?IPv6:2001:df8::16:5032:c5ae:6e5e:acc8? ([2001:df8:0:16:5032:c5ae:6e5e:acc8]) by mx.google.com with ESMTPS id g10sm16136010pav.9.2012.11.08.05.20.42 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 05:20:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Thu, 8 Nov 2012 14:20:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com>, <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> <72D1D555-D465-4C90-8D6E-D402A4BFEFC2@fugue.com> <2FB9BCF5-0D95-48DC-9709-96F52546DA9D@inf-net.nl> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkDtpUzM6U+bMT9f+WjMWEAN1A01chEzGBCzQ7VDGLCR6CtXe44kil/RH/L4PSeYap8eo1i Cc: "homenet@ietf.org Group" , "Ole Troan \(otroan\)" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:20:46 -0000 Op 8 nov. 2012, om 13:06 heeft Ted Lemon het volgende geschreven: > On Nov 7, 2012, at 10:24 PM, Teco Boot wrote: >> And I suggest that if D requests a prefix, for an additional = interface, it uses unicast to A, with an autoconfigured address. So A = receives only one request. >=20 > No, it doesn't, because that's not what RFC3315 and RFC3633 say to do, = and it would badly break them to specify this behavior. There's no = harm in the duplicate packet, so no reason to break the protocol to = avoid it. >=20 I read 3315 different. Intro: Once the client has determined the address of a server, it may under some circumstances send messages directly to the server using unicast. With BRDP, the client is informed of addresses of servers. It can decide = which server to use. This is a *required* feature for better = multi-homing support.=20 I agree the actual mechanism needs to be spelled out, e.g. when client = needs to add a Relay Agent option in its messages. Teco From robert.cragie@gridmerge.com Thu Nov 8 05:30:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1421F8997 for ; Thu, 8 Nov 2012 05:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v944q4sCqF7W for ; Thu, 8 Nov 2012 05:30:57 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5F36D21F878E for ; Thu, 8 Nov 2012 05:30:57 -0800 (PST) Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TWSC7-0001NE-BG for homenet@ietf.org; Thu, 08 Nov 2012 13:30:55 +0000 Message-ID: <509BB451.3020901@gridmerge.com> Date: Thu, 08 Nov 2012 13:32:01 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> In-Reply-To: <509BA4AF.2080308@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090601040507010405060409" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:30:58 -0000 This is a cryptographically signed message in MIME format. --------------ms090601040507010405060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I don't think bridging should be considered for homenet. Don't forget=20 the following in the charter: "Also, link layer networking technology is poised to become more=20 heterogeneous, as networks begin to employ both traditional Ethernet=20 technology and link layers designed for low-powered sensor networks." In a lot of these conversations, the "lightswitch guys" (as someone=20 called the LLN proponents) seem to get forgotten. Robert On 08/11/2012 12:25 PM, Brian E Carpenter wrote: > On 08/11/2012 12:05, Ted Lemon wrote: >> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter wrote: >>> Fine, but when such an end customer buys a second router and plugs it= in, >>> will she get an error message that says "Please find a new ISP"? >> In this case I think our only option is to fall back to bridging. > Without some fundamental surgery on the IPv6 specs, I fear that is true= , > so does it have to become (gulp) a feature of the homenet architecture?= > > I would hate that but at the moment I see no alternative. There is > another alternative, routed ULA within the homenet and NPTv6 at the > border, but we've already said we don't want to recommend that. > > I think the following paragraph of the architecture document needs > to be revised accordingly: > > The home network needs to be adaptable to such ISP policies, and thus= > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if= > only a /64 is offered by the ISP, the homenet may be severely > constrained (with IPv6 not reaching all devices in the home, or use > of some form of IPv6 NAT being forced), or even unable to function. > While it may be possible to operate a DHCPv6-only network with > prefixes longer than /64, doing so would break SLAAC, and is thus not= > recommended. > > Something like: > > The home network needs to be adaptable to such ISP policies, and thus= > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if= > only a /64 is offered by the ISP, the homenet may be severely > constrained. Attempting to use subnet prefixes longer than /64 > would break SLAAC, and is thus not recommended. Using ULA prefixes > internally with NPTv6 at the boundary would be possible, but is not > recommended for reasons given elsewhere. The least damaging solution > would be for the internal routers to revert to bridging mode, > even though this would destroy the benefits of subnetting. > > Brian > > > > > > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms090601040507010405060409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDgxMzMyMDFaMCMGCSqGSIb3DQEJBDEWBBQe2McyO89YTPxlR9wYTf0JQSvC6zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAAw7YwS3ApPToLtwqeV1REAd9GXKSvLZ+IHBG67wB0eILRA7 iL6lwbXZ6D4qPQS1DnYkQLGqvB5Vb+C4nf5C/Y+bKH5pqk8s+p95U4QjZrLX8Q1dsmdJMvAY XtWj7X2U221TWeAtmthfqV9gIcjJwZKrGFBan871zbV8ahy+X2yadHgCagKX0fJ87SXXRoXd swHaurNVaNpN0D4HZj/7+T5Ax330PiFVtIbqir4IDw8lSJJiH2kMEKipBm1xrwP6HbZ+lt8j +r2To/umxvanF861gAEUfMydpgbubKUHMagqnrZMipJfir92PuU1UlhjuzIjgJHlkrZNNxfa Uh1daVsAAAAAAAA= --------------ms090601040507010405060409-- From swmike@swm.pp.se Thu Nov 8 05:42:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2696621F898A for ; Thu, 8 Nov 2012 05:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2+YOj5EUMCs for ; Thu, 8 Nov 2012 05:42:00 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49121F8A69 for ; Thu, 8 Nov 2012 05:41:56 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8B92D9C; Thu, 8 Nov 2012 14:41:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8719A9A; Thu, 8 Nov 2012 14:41:48 +0100 (CET) Date: Thu, 8 Nov 2012 14:41:48 +0100 (CET) From: Mikael Abrahamsson To: Robert Cragie In-Reply-To: <509BB451.3020901@gridmerge.com> Message-ID: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:42:01 -0000 On Thu, 8 Nov 2012, Robert Cragie wrote: > In a lot of these conversations, the "lightswitch guys" (as someone > called the LLN proponents) seem to get forgotten. So let's just say that giving a single /64 to the home is incompatible with homenet architecture, and we need more addresses. I'm fine with that. I see little reason to support /64 for homenet, because if there is only a single subnet, there is not much to network with within the home, there is only a single subnet. -- Mikael Abrahamsson email: swmike@swm.pp.se From mattia.rossi.mailinglists@gmail.com Thu Nov 8 05:45:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C96321F8AEF for ; Thu, 8 Nov 2012 05:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhoCe8vZmbL2 for ; Thu, 8 Nov 2012 05:45:14 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2F221F8B0C for ; Thu, 8 Nov 2012 05:45:10 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jc3so1244913bkc.31 for ; Thu, 08 Nov 2012 05:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mRF8WcA1YyHQUdBvTvorqDscBv1hrEYd6FgtXsp90nY=; b=sd9/QxdaN0ChUFo3ImHbTdQnh7yJVspdZZOb7Q8fPDw9e6dn8xwBHw7nBRPuam9/yH H2kXXDcfHYgtgkM+SP3DCwsGLMvMEsbsJvjcVmlmOsFLzNmxSolCopJDGi0W06gjucko Z3xH53UYmfvazA3d1ANIH4zpnONqdlX4XlNNOk8xTX/zAa53c4HUj2KEZCbAkwqZx+UP KENa+Lptcs43pgLKi6pj474J2lZ6dCnpWd2TgjlutqqGKa6EwcpYH6YRxSXfOTGRGswS JRoTHF4CD0wdk2NORb/DE6ZEwdzBG/hfif0LRVOtCjQDCAr7RIW3iV77YzjjF0QY0DLc T5Ug== Received: by 10.204.148.214 with SMTP id q22mr2013334bkv.128.1352382309385; Thu, 08 Nov 2012 05:45:09 -0800 (PST) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id s20sm16949545bkw.15.2012.11.08.05.45.07 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 05:45:08 -0800 (PST) Message-ID: <509BB762.8080304@gmail.com> Date: Thu, 08 Nov 2012 14:45:06 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> In-Reply-To: <509BB451.3020901@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:45:16 -0000 > On 08/11/2012 12:25 PM, Brian E Carpenter wrote: >> On 08/11/2012 12:05, Ted Lemon wrote: >>> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter >>> wrote: >>>> Fine, but when such an end customer buys a second router and plugs >>>> it in, >>>> will she get an error message that says "Please find a new ISP"? >>> In this case I think our only option is to fall back to bridging. >> Without some fundamental surgery on the IPv6 specs, I fear that is true, >> so does it have to become (gulp) a feature of the homenet architecture? >> >> I would hate that but at the moment I see no alternative. There is >> another alternative, routed ULA within the homenet and NPTv6 at the >> border, but we've already said we don't want to recommend that. >> >> I think the following paragraph of the architecture document needs >> to be revised accordingly: >> >> The home network needs to be adaptable to such ISP policies, and thus >> make no assumptions about the stability of the prefix received from >> an ISP, or the length of the prefix that may be offered. However, if >> only a /64 is offered by the ISP, the homenet may be severely >> constrained (with IPv6 not reaching all devices in the home, or use >> of some form of IPv6 NAT being forced), or even unable to function. >> While it may be possible to operate a DHCPv6-only network with >> prefixes longer than /64, doing so would break SLAAC, and is thus not >> recommended. >> >> Something like: >> >> The home network needs to be adaptable to such ISP policies, and thus >> make no assumptions about the stability of the prefix received from >> an ISP, or the length of the prefix that may be offered. However, if >> only a /64 is offered by the ISP, the homenet may be severely >> constrained. Attempting to use subnet prefixes longer than /64 >> would break SLAAC, and is thus not recommended. Using ULA prefixes >> internally with NPTv6 at the boundary would be possible, but is not >> recommended for reasons given elsewhere. The least damaging solution >> would be for the internal routers to revert to bridging mode, >> even though this would destroy the benefits of subnetting. >> > I don't think bridging should be considered for homenet. Don't forget > the following in the charter: > > "Also, link layer networking technology is poised to become more > heterogeneous, as networks begin to employ both traditional Ethernet > technology and link layers designed for low-powered sensor networks." > > In a lot of these conversations, the "lightswitch guys" (as someone > called the LLN proponents) seem to get forgotten. > So what happens if the "lightswitch guys" want to plug-in a router, which they have to, as they can't bridge, but there's only one exit router from one ISP which is managed and gets a /64 only? SLAAC relay? I think in this case a /64 is simply not acceptable. Mat From teco@inf-net.nl Thu Nov 8 05:52:39 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7E21F8B71 for ; Thu, 8 Nov 2012 05:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asmj1b-5jgEn for ; Thu, 8 Nov 2012 05:52:39 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36D1221F8B6E for ; Thu, 8 Nov 2012 05:52:39 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1277695dan.31 for ; Thu, 08 Nov 2012 05:52:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9l9D6DlA63XLnQUmsa/QRezGg/SQQx+xZ+K257UopJE=; b=erBUxHd5h0t/2C0f6KzyG5tNo0Gk/4fl2OdMpnqNgKbKT0ef3i6BaX4vr/NFeZ7QBz ShKM+iyN9NicMQxRpoHF7pJU/CHj7Q5D/ZNomY2X+CMDwDBn81nGHnAbdG2A9Dt1Kxcr jv4aQVKUdFVPESwNO2AEVl2qSt/VdG3aKgZFCKcTiQwPNJAq3T1hzcU2GrAJzJxA821b JHkV+wE5cyoyAdjr9X+qE2Tpuw7WRV+zDuIRzg+aC936CIGg3DwkrjE+rbsNjgpNvgcK df1eHfNbkpqMFjIqEmqgaRmWZJfXcg3kyXhQBDGAbhXuWtu02P6MXFm6mKpjOJ78SjdS yYrA== Received: by 10.68.137.234 with SMTP id ql10mr17522107pbb.158.1352382754908; Thu, 08 Nov 2012 05:52:34 -0800 (PST) Received: from ?IPv6:2001:df8::16:5032:c5ae:6e5e:acc8? ([2001:df8:0:16:5032:c5ae:6e5e:acc8]) by mx.google.com with ESMTPS id f2sm16166069paz.25.2012.11.08.05.52.32 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 05:52:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Thu, 8 Nov 2012 14:52:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <904D155D-5EAF-4AC3-AC74-966A09A68CB2@inf-net.nl> References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com> <509AA288.30802@thekelleys.org.uk> <20121107182125.GQ1927048@jupiter.n2.diac24.net> <20121107190011.GU1927048@jupiter.n2.diac24.net> <0E289D6E-33F3-4E34-83CC-2E7FBA41A9E2@fugue.com> <867F4B6A1672E541A94676D556793ACD1B66C8E97E@MOPESMBX01.eu.thmulti.com> <3016E3D9-476A-4266-A1A4-81B811989C13@inf-net.nl> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm60+FHMI+bMW8UWiABr17J3wQQ/2OCKi9QUdwR6DQdtDHghWT2eicvF2/qESE3wqdhB/1D Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:52:39 -0000 Op 8 nov. 2012, om 13:31 heeft Mikael Abrahamsson het volgende = geschreven: > On Thu, 8 Nov 2012, Teco Boot wrote: >=20 >> I hope I misunderstand. If current CPE router and WiFi AP cannot be = upgraded to what we are talking about, we are on a dead end. >=20 > I have zero illusion that any devices that have been purchased with = minimum requirements for IPv4 only, giving the deal to whoever cuts the = cost that last 10 cents, is going to be upgraded to do ANYTHING more = than what was initially specified. We cold turn IPv4 off. Or turn off a feature in data plane, and stop address sharing :-)=20 >=20 > I am however fairly confident that any CPE that was purchased in a way = that assured that future functionality could be brought in, or is a = premium product, will be able to support OSPF as well. Sure.=20 OLSR runs quite well on old days CPE devices, 100ths of routers, 1000ths = of links. >=20 > Do you believe that we could even get DHCPv6-PD into such devices. Sure. What is the problem? > I have been in contact with CPE manufacturers who make products that = are actually mid-range, who say they do not have flash and memory to do = what I feel is very basic IPv6 functionality. I cannot response, other than that competition will make the products = available for us. >=20 > I think we should aim higher do what's best in the long run, and then = CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 more = than current generation, initially, but as these requirements spread and = more people/ISPs buy, it'll be the new lowest standard and cost will = drop. If we drop IPv4, and have full Homenet compliancy, CPEs might be USD5-10 = cheaper:-) Teco >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Thu Nov 8 06:09:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3621F8B57 for ; Thu, 8 Nov 2012 06:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNUTs-MTrEnG for ; Thu, 8 Nov 2012 06:09:59 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 151BA21F8AEF for ; Thu, 8 Nov 2012 06:09:59 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2196298pbb.31 for ; Thu, 08 Nov 2012 06:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GGN1Dg0FKBEHnADUbF9X+d8IvVil2TD+pu782957XIc=; b=BKnOcZXtfTG00eakdN/5SSCmO53+GuII67JgOsjhoHVuFO7DPYwwOUzKt/fwaXLqvU gAM+bDPgfTQiwSyr4K8oOMYSBiH6tfmp4UTu5PmrT93rQl2Zn8fuPICBhCY+6J4+kuZ4 TPVx5AtqxCUAS6BevltduclJc1HK6RKAKdef+jBRsR8k68Z6wtAVFIaWWrLVWHBpLAbU UykGETWXC3cmwY+New4Kfhl3KdMEqRtDcT+EWJx6kBxqRiEPQ1ahhDWmyG3rOFSyb+5N u+gY5OkmXzff8wbufl6vz6ICFmGo+IUdTiR36jdr7vDHR8g8f24JzJOgtKdIep8UaP8K IT/g== Received: by 10.66.87.105 with SMTP id w9mr22849260paz.5.1352383798742; Thu, 08 Nov 2012 06:09:58 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id c8sm16195741pav.4.2012.11.08.06.09.51 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 06:09:52 -0800 (PST) Message-ID: <509BBD36.4080601@gmail.com> Date: Thu, 08 Nov 2012 14:09:58 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mattia Rossi References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> In-Reply-To: <509BB762.8080304@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:09:59 -0000 On 08/11/2012 13:45, Mattia Rossi wrote: > >> On 08/11/2012 12:25 PM, Brian E Carpenter wrote: >>> On 08/11/2012 12:05, Ted Lemon wrote: >>>> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter >>>> wrote: >>>>> Fine, but when such an end customer buys a second router and plugs >>>>> it in, >>>>> will she get an error message that says "Please find a new ISP"? >>>> In this case I think our only option is to fall back to bridging. >>> Without some fundamental surgery on the IPv6 specs, I fear that is true, >>> so does it have to become (gulp) a feature of the homenet architecture? >>> >>> I would hate that but at the moment I see no alternative. There is >>> another alternative, routed ULA within the homenet and NPTv6 at the >>> border, but we've already said we don't want to recommend that. >>> >>> I think the following paragraph of the architecture document needs >>> to be revised accordingly: >>> >>> The home network needs to be adaptable to such ISP policies, and thus >>> make no assumptions about the stability of the prefix received from >>> an ISP, or the length of the prefix that may be offered. However, if >>> only a /64 is offered by the ISP, the homenet may be severely >>> constrained (with IPv6 not reaching all devices in the home, or use >>> of some form of IPv6 NAT being forced), or even unable to function. >>> While it may be possible to operate a DHCPv6-only network with >>> prefixes longer than /64, doing so would break SLAAC, and is thus not >>> recommended. >>> >>> Something like: >>> >>> The home network needs to be adaptable to such ISP policies, and thus >>> make no assumptions about the stability of the prefix received from >>> an ISP, or the length of the prefix that may be offered. However, if >>> only a /64 is offered by the ISP, the homenet may be severely >>> constrained. Attempting to use subnet prefixes longer than /64 >>> would break SLAAC, and is thus not recommended. Using ULA prefixes >>> internally with NPTv6 at the boundary would be possible, but is not >>> recommended for reasons given elsewhere. The least damaging solution >>> would be for the internal routers to revert to bridging mode, >>> even though this would destroy the benefits of subnetting. >>> >> I don't think bridging should be considered for homenet. Don't forget >> the following in the charter: >> >> "Also, link layer networking technology is poised to become more >> heterogeneous, as networks begin to employ both traditional Ethernet >> technology and link layers designed for low-powered sensor networks." >> >> In a lot of these conversations, the "lightswitch guys" (as someone >> called the LLN proponents) seem to get forgotten. >> > So what happens if the "lightswitch guys" want to plug-in a router, > which they have to, as they can't bridge, but there's only one exit > router from one ISP which is managed and gets a /64 only? > SLAAC relay? I think in this case a /64 is simply not acceptable. OK, so there are failure cases and that too needs to be stated in the architecture. Send text. Brian From brian.e.carpenter@gmail.com Thu Nov 8 06:17:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0098F21F859A for ; Thu, 8 Nov 2012 06:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPW3s79D8c1o for ; Thu, 8 Nov 2012 06:17:34 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C298821F856E for ; Thu, 8 Nov 2012 06:17:29 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2156037pad.31 for ; Thu, 08 Nov 2012 06:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jrEc0eWiDVNvstG422PFetV8mAAx2Z/gluW7j5HXx44=; b=kiOh1jA8Bf4t3YGybYwxY+eOfwiQCDAi1ElDHI2WHex2Cdba3oX0RdfO4u9bqqjxvv 2x07I/vNw8jkpDkfzPutAa7kqrekuVYjw2O880I0b5fjJEcMRU4ktvQcv8RyNeUk0lzD vJKHsnzUSHOGXX+SiEs433A4wqhnVNYx+GTxdPmCTfXT3e/NKEjL5a6g3k7ILGHjcqTs KVuPw+1wAj7ZQFVUUdpeb61vqUSX1dkLt5u+AkdcWVy3xzcNHsSbK4Q6TkFhUCXGhWhH VvsEY/Wri/jFErfTY2h6HhZwRy7uK2ygcDjLbQ6F5jUzDXWQFXHB3vDj13Y0XjhtwJB9 VXiQ== Received: by 10.68.193.228 with SMTP id hr4mr17924674pbc.95.1352384249581; Thu, 08 Nov 2012 06:17:29 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id ug6sm7904288pbc.4.2012.11.08.06.17.28 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 06:17:29 -0800 (PST) Message-ID: <509BBF02.507@gmail.com> Date: Thu, 08 Nov 2012 14:17:38 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Robert Cragie , homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:17:35 -0000 On 08/11/2012 13:41, Mikael Abrahamsson wrote: > On Thu, 8 Nov 2012, Robert Cragie wrote: > >> In a lot of these conversations, the "lightswitch guys" (as someone >> called the LLN proponents) seem to get forgotten. > > So let's just say that giving a single /64 to the home is incompatible > with homenet architecture, and we need more addresses. I'm fine with that. > > I see little reason to support /64 for homenet, because if there is only > a single subnet, there is not much to network with within the home, > there is only a single subnet. I wish I could agree. But if we don't provide for this situation in the architecture, we are simply ignoring a segment of the real world, and that is unrealistic. We need to design things so that if a homenet user switches between a /56 ISP and a /64 ISP, stuff just reconfigures itself to bridging mode (and any boxes that can't do that report the problem in an intelligible way). Also consider a dual-homed homenet where one ISP gives a /64 and the other gives a /56. I guess that has to revert to bridging mode too. Brian From teco@inf-net.nl Thu Nov 8 06:24:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E18221F8B4B for ; Thu, 8 Nov 2012 06:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMY9kOa-6I6V for ; Thu, 8 Nov 2012 06:24:46 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC71C21F8B1C for ; Thu, 8 Nov 2012 06:24:45 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1289820dan.31 for ; Thu, 08 Nov 2012 06:24:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=AottNRpPhNSW0PJ2OTAoc6LX6AWqiGwJZ7zrtTTT+8g=; b=C+T0ZpDQNrSfYHTLYFwxw/nSsPpmA9iRq+4vGCwECtpF01hyjPGUhzOsaGoNlgkAPd CS7bi/dMC5JZ6xQ6HrCo25Ur9jmCks96hMcoOgv6qd4HRzwpkTlSsgQnGrI+RN/ylXWO b9zbemYjZ5v0EZkSJR+MmK9liQuAyFxE00r97oV2drtvy1fuTFMaY1RIt/hzhknZaNLw gsfxmAyADLa5nFNWu8mlqNXMj8yjdtI2QQhW3G8oHVj9Ft/W/NdJIOz91WvFyMUexIWJ i0CZqmTs/VWicHWJp4JS2iKzXo9r034rWQ3tKqvV+3hiVH3DQchDyH8eFo7vtvd200Nw KqLQ== Received: by 10.68.135.101 with SMTP id pr5mr24216381pbb.140.1352384684653; Thu, 08 Nov 2012 06:24:44 -0800 (PST) Received: from ?IPv6:2001:df8::16:3927:53bd:6d0a:29e3? ([2001:df8:0:16:3927:53bd:6d0a:29e3]) by mx.google.com with ESMTPS id qj6sm16010069pbb.69.2012.11.08.06.24.43 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 06:24:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> Date: Thu, 8 Nov 2012 15:24:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48E9ED8D-FD29-45C7-B45D-4E470EC0DEE9@inf-net.nl> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnmgpB/Xy2mAqVExoFJIyL/OWpL7Ke6lgtuWIjrllWcA0uaJS27ovD3YRDrIghsrO5OYjbz Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:24:51 -0000 Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >=20 > On Nov 7, 2012, at 11:18 PM, Teco Boot wrote: >=20 >> I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the = proposal doesn't meet expectations of users, with regard of protocol = convergence. The default timers are far too conservative. First reconfig = on OSPF router in my hands is adjust timers on high speed interfaces to = hello=3D1 and dead=3D4. This is a bit better than what old days bridges = with STP do. >=20 > This was not considered a requirement in the home. Refer to the = section 3.5 in the homenet architecture document.=20 Right. Dead=3D40 does *not* meet the requirement. See also = http://www.ietf.org/mail-archive/web/homenet/current/msg01245.html Teco >=20 >> Minor: the timers are not defaults. These are sample values. I have = seen routers with different defaults than RFC 5340, for certain = interface types. >=20 > I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >=20 >>=20 >> For autoconfig OSPF, I prefer removal of the restriction that all = routers on a link MUST use same timers. That provides flexibility like = OLSR. If this is not possible because of reasons for DR selection, I = suggest removal of DR completely and configure all interfaces in P2MP. = Or MANET interface type, if we want to. Question is: which MANET = extension. >=20 > I'm not sure if there is a real requirement. Routers on the link need = to agree on the timer values lest we impact more of the protocol than = necessary. Hence, if this is required, the way forward would be for = routers on shared links to adopt the timers from their neighbor(s). For = simplicity, the same rules used for DR preference could be used.=20 >=20 > Thanks, > Acee >=20 >>=20 >> [posted here, because requirements come from Homenet] >>=20 >> Teco >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From robert.cragie@gridmerge.com Thu Nov 8 06:27:47 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F308B21F8AD7 for ; Thu, 8 Nov 2012 06:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbqlIXOi3opU for ; Thu, 8 Nov 2012 06:27:45 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9D35C21F86AD for ; Thu, 8 Nov 2012 06:27:44 -0800 (PST) Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TWT53-0000fb-Vp for homenet@ietf.org; Thu, 08 Nov 2012 14:27:43 +0000 Message-ID: <509BC1A0.5030509@gridmerge.com> Date: Thu, 08 Nov 2012 14:28:48 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> In-Reply-To: <509BA4AF.2080308@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050208050409050100090602" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:27:48 -0000 This is a cryptographically signed message in MIME format. --------------ms050208050409050100090602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Comment inline. Robert On 08/11/2012 12:25 PM, Brian E Carpenter wrote: > On 08/11/2012 12:05, Ted Lemon wrote: >> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter wrote: >>> Fine, but when such an end customer buys a second router and plugs it= in, >>> will she get an error message that says "Please find a new ISP"? >> In this case I think our only option is to fall back to bridging. > Without some fundamental surgery on the IPv6 specs, I fear that is true= , > so does it have to become (gulp) a feature of the homenet architecture?= > > I would hate that but at the moment I see no alternative. There is > another alternative, routed ULA within the homenet and NPTv6 at the > border, but we've already said we don't want to recommend that. > > I think the following paragraph of the architecture document needs > to be revised accordingly: > > The home network needs to be adaptable to such ISP policies, and thus= > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if= > only a /64 is offered by the ISP, the homenet may be severely > constrained (with IPv6 not reaching all devices in the home, or use > of some form of IPv6 NAT being forced), or even unable to function. > While it may be possible to operate a DHCPv6-only network with > prefixes longer than /64, doing so would break SLAAC, and is thus not= > recommended. > > Something like: > > The home network needs to be adaptable to such ISP policies, and thus= > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if= > only a /64 is offered by the ISP, the homenet may be severely > constrained. Attempting to use subnet prefixes longer than /64 > would break SLAAC, and is thus not recommended. Using ULA prefixes > internally with NPTv6 at the boundary would be possible, but is not > recommended for reasons given elsewhere. The least damaging solution > would be for the internal routers to revert to bridging mode, > even though this would destroy the benefits of subnetting. I think it is arguable whether bridging is the least damaging=20 solution. It fundamentally does not work with route-over multi-link=20 subnets and would therefore require some extra L2 weirdness at a LLN=20 border router. If ISPs are going to hobble us with /64s then I think you = will find NPTv6 solutions appearing for the same reason NAT is used=20 today. There are alternatives but, as noted in the architecture draft,=20 these break SLAAC. So I think the onus is to push back on ISPs ofering=20 /64s if we want to avoid any kludges. > > Brian > > > > > > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms050208050409050100090602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDgxNDI4NDhaMCMGCSqGSIb3DQEJBDEWBBTUHW0yOqldgxr+pcQ3MY5YS17bwDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBACB6BQKr37Lb+0sgRRYi5GJ6Tt+g0zMYqjJ4qPpWJsSWhLCQ TNXvCy7YeG6L0evukpuuyNO84H6P7V3Oy5GpyMYnNCyfE94rG5nMxvCbLjR2Xyei+zqfe2By zH/mnQR4boWlXdsfI9UntSKiIQRF3ym4+HZrCHa7E8aPNzvcYgeEqHoi0OX6bTXDxdxnQwHo k837mngZbRgjN2v++EFGH4PraILWo9QJ8gH7nFKRpKXM0sG6ZtgTZXzrnIjUvzy/AF1q1dSQ rXy6H20/whQ1IG4Q+ImbEWDGZEyP2alm81McQb28LCvHwGwhlOSgUlVogQB4HYqEeRYHvP3Q EBD8ORcAAAAAAAA= --------------ms050208050409050100090602-- From brian.e.carpenter@gmail.com Thu Nov 8 06:30:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8210421F8B49 for ; Thu, 8 Nov 2012 06:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQrcAMKa1Eds for ; Thu, 8 Nov 2012 06:30:52 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0338421F8B32 for ; Thu, 8 Nov 2012 06:30:51 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1291982dan.31 for ; Thu, 08 Nov 2012 06:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o9ULT+2LF1Ntf7r2r5VNsKvlAlN32djS2gJa8aloX5U=; b=v3d9JWQXKPU/KsqQDUjzY0dkGMEGj/O+ZfxjdbFiAxRWHjN3ojYSNQsSOUCUY+AyXh h313c69ZWm3EUcgN9bAAsZ7Bnqqct5knj/4GyQxLUQi+p5baCq5mwi3rRtlPpKGCHrVZ jzHn1PNazelFossF4HMYg69ulFmTKLwJFB4Wt5FQo1wu0i2fzd2jO2IL0Ye2M9dk8L+7 qDRuhuXY0BdcTFIdkeK/TqHxBdjQ/6tX1NsinM2qja86uzZ7SRruFQPDL7sJURnhpy96 SekIFCVe1ASTPWe+p3EpY7cvLNmrIocpJWwSQJM3vu/LrygogyEb5M6UEkkboQ5XE6NU 1hTw== Received: by 10.66.85.138 with SMTP id h10mr22812505paz.40.1352385051768; Thu, 08 Nov 2012 06:30:51 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id os5sm1006259pbc.15.2012.11.08.06.30.49 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 06:30:50 -0800 (PST) Message-ID: <509BC223.7060406@gmail.com> Date: Thu, 08 Nov 2012 14:30:59 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Taht References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Andrew McGregor , Ted Lemon , Wuyts Carl , Ralph Droms , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:30:52 -0000 Dave, On 08/11/2012 12:57, Dave Taht wrote: > On Thu, Nov 8, 2012 at 1:32 PM, Mikael Abrahamsson wrote: >> On Thu, 8 Nov 2012, Ted Lemon wrote: >> >>> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter >>> wrote: >>>> Fine, but when such an end customer buys a second router and plugs it in, >>>> will she get an error message that says "Please find a new ISP"? >>> >>> In this case I think our only option is to fall back to bridging. >> >> Yes, doing protocol based brinding (L2 bridge 0x86dd packets) is the only >> way to go as far as I can tell. > > Um, er, ah, no, for many years now there has been the AHCP + babeld, > which routes /128s out of a /64 across any sort of wired/wireless > network over as many hops as needed. > > I've been doing my best to ignore this discussion, and work on > improving that code. Code is good, but where is the spec that we can refer to? As far as I can tell there's only an expired draft: http://tools.ietf.org/id/draft-chroboczek-ahcp-00.txt and RFC 6126, which is Experimental. > > You guys can beat your brains out over dhcp's approaches all you want, > and expect your ISPs in a cloudy future to deliver something bigger > than a /64 ... Some ISPs will do that much sooner. Brian > > and bridge low speed wifi over high speed ethernet all you want - > > - but me, I kind of like being able to move transparently from AP to > AP and from wired to wireless and back again, and to not need anything > bigger than a /64 to do it. > > Given the trends towards excessive dynamicism throughout the IPv6 > deployment, and the naming issues, and various ways proposed to > monetize/make scarce /sub 64 allocations by the ISPS. I think the > market will pick ipv6 nat and something like AHCP. > > > > From dave.taht@gmail.com Thu Nov 8 06:47:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABDC21F8B2F for ; Thu, 8 Nov 2012 06:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY0t-0V0dxkQ for ; Thu, 8 Nov 2012 06:47:41 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0141E21F8536 for ; Thu, 8 Nov 2012 06:47:40 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1820719eek.31 for ; Thu, 08 Nov 2012 06:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bN9F4qDPo2GjvoveGyq99wy31mCHn6gLEwBcZlhePZk=; b=ZsZGdOrChMVWaB58Wmv0QeC39R3n4F42otC/xVxyI3ImfNEPMjyR2WxOis3CqhG8XU Dj3WgiOzEli2bNx0VLHc9mPY/SUJdNNUJBtaHideVm6y8y5GIGOPWxim1qcPotZr+5DO PUrDqiu4fH4EUYBGwU9MYGkbB55g3YQAFzNu6AwJA+Se17I2BPPwS11PSwIbSjHuhEjN op+54fCi9aj+0A0U7UoYdnAg7X4vqppwKaewJhA3cnlK7sz4VLr6ws4km1rgHEgGDiZn heEBlaB9yq1kJf1tWchIWx20L9ztuQKGUar23Qim+j2gPGYUi87Corm2ZdSttdbgWGgn wauQ== MIME-Version: 1.0 Received: by 10.14.182.5 with SMTP id n5mr28120608eem.5.1352386060243; Thu, 08 Nov 2012 06:47:40 -0800 (PST) Received: by 10.223.180.10 with HTTP; Thu, 8 Nov 2012 06:47:40 -0800 (PST) In-Reply-To: <509BC223.7060406@gmail.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BC223.7060406@gmail.com> Date: Thu, 8 Nov 2012 15:47:40 +0100 Message-ID: From: Dave Taht To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew McGregor , Ted Lemon , Wuyts Carl , Ralph Droms , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] regarding recursive DHCPv6-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:47:42 -0000 On Thu, Nov 8, 2012 at 3:30 PM, Brian E Carpenter wrote: > Dave, > > On 08/11/2012 12:57, Dave Taht wrote: >> On Thu, Nov 8, 2012 at 1:32 PM, Mikael Abrahamsson wr= ote: >>> On Thu, 8 Nov 2012, Ted Lemon wrote: >>> >>>> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter >>>> wrote: >>>>> Fine, but when such an end customer buys a second router and plugs it= in, >>>>> will she get an error message that says "Please find a new ISP"? >>>> >>>> In this case I think our only option is to fall back to bridging. >>> >>> Yes, doing protocol based brinding (L2 bridge 0x86dd packets) is the on= ly >>> way to go as far as I can tell. >> >> Um, er, ah, no, for many years now there has been the AHCP + babeld, >> which routes /128s out of a /64 across any sort of wired/wireless >> network over as many hops as needed. >> >> I've been doing my best to ignore this discussion, and work on >> improving that code. > > Code is good, but where is the spec that we can refer to? As far as > I can tell there's only an expired draft: > http://tools.ietf.org/id/draft-chroboczek-ahcp-00.txt > and RFC 6126, which is Experimental. In both cases the current open source code reflects the drafts, and has been in production use for several years. Since the initial babel rfc, two interoperable implementations of the babel protocol have arisen in quagga-RE and quagga mainline, in addition to the standalone babeld daemon. Additionally, cryptographic authentication of selected routes is now available both as running code in quagga AND as ietf draft, updating but not superceding rfc 6126, draft was posted in august: http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-00 This makes it possible to withdraw certain networks from routing and reduces the need for complex firewalling setups for ipv4 (natted or non-natted) and ipv6. Work is progressing on extending AHCP to do prefix distribution with a similar algorithm to what is in the ospf version, but as noted, shipping routed /128s around is simpler, and the default mechanism. > >> >> You guys can beat your brains out over dhcp's approaches all you want, >> and expect your ISPs in a cloudy future to deliver something bigger >> than a /64 ... > > Some ISPs will do that much sooner. > > Brian > >> >> and bridge low speed wifi over high speed ethernet all you want - >> >> - but me, I kind of like being able to move transparently from AP to >> AP and from wired to wireless and back again, and to not need anything >> bigger than a /64 to do it. >> >> Given the trends towards excessive dynamicism throughout the IPv6 >> deployment, and the naming issues, and various ways proposed to >> monetize/make scarce /sub 64 allocations by the ISPS. I think the >> market will pick ipv6 nat and something like AHCP. >> >> >> >> --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From lee.howard@twcable.com Thu Nov 8 06:48:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16F21F8B4B for ; Thu, 8 Nov 2012 06:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxYdAwfR-G2U for ; Thu, 8 Nov 2012 06:48:12 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 745B221F8536 for ; Thu, 8 Nov 2012 06:48:12 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,738,1344225600"; d="scan'208";a="467105919" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 08 Nov 2012 09:47:04 -0500 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 8 Nov 2012 09:47:48 -0500 From: "Howard, Lee" To: Mikael Abrahamsson , Teco Boot Date: Thu, 8 Nov 2012 09:47:48 -0500 Thread-Topic: [homenet] DHCP PD for homenets. Thread-Index: Ac29wAUeZBIw5itySySi1IsmIysJaw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:48:13 -0000 > >I think we should aim higher do what's best in the long run, and then CPE >manufacturers will adapt. Yes, these new CPEs might be USD5-10 more than >current generation, initially, but as these requirements spread and more >people/ISPs buy, it'll be the new lowest standard and cost will drop. It's very generous of you to spend other people's money this way. Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From sander@steffann.nl Thu Nov 8 07:03:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5D521F8B79 for ; Thu, 8 Nov 2012 07:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.976 X-Spam-Level: X-Spam-Status: No, score=0.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t-GufzcgY39 for ; Thu, 8 Nov 2012 07:03:01 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 5D22B21F8B6C for ; Thu, 8 Nov 2012 07:03:01 -0800 (PST) Received: from [172.20.10.3] (unknown [62.140.137.123]) by mail.sintact.nl (Postfix) with ESMTP id 8DA9D2024; Thu, 8 Nov 2012 16:02:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Thu, 8 Nov 2012 16:02:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97BFA9CC-9761-4A06-9113-072CCB03DF28@steffann.nl> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: Robert Cragie , homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:03:02 -0000 HI, > So let's just say that giving a single /64 to the home is incompatible = with homenet architecture, and we need more addresses. I'm fine with = that. Yes please. I think some ISPs *need* to get a signal like this. Sander From swmike@swm.pp.se Thu Nov 8 07:07:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7221F8B6E for ; Thu, 8 Nov 2012 07:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcUT5AIC7IPM for ; Thu, 8 Nov 2012 07:07:17 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id B285D21F8B6C for ; Thu, 8 Nov 2012 07:07:17 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D488D9C; Thu, 8 Nov 2012 16:07:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CE5E29A; Thu, 8 Nov 2012 16:07:16 +0100 (CET) Date: Thu, 8 Nov 2012 16:07:16 +0100 (CET) From: Mikael Abrahamsson To: "Howard, Lee" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:07:18 -0000 On Thu, 8 Nov 2012, Howard, Lee wrote: >> I think we should aim higher do what's best in the long run, and then >> CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 more >> than current generation, initially, but as these requirements spread >> and more people/ISPs buy, it'll be the new lowest standard and cost >> will drop. > > It's very generous of you to spend other people's money this way. What is your suggestion? New requirements mean higher spec hw, I don't really see a way around that. Do you? For ISPs who want to save those few dollars, they can offer NAT444 and then do not need to require more functionality in their CPEs. In the areas where customers have a choice, let them choose. -- Mikael Abrahamsson email: swmike@swm.pp.se From victor.kuarsingh@gmail.com Thu Nov 8 07:09:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D0E21F85B2 for ; Thu, 8 Nov 2012 07:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbaU83fCcYJL for ; Thu, 8 Nov 2012 07:09:13 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7978021F85A1 for ; Thu, 8 Nov 2012 07:09:13 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1306013dan.31 for ; Thu, 08 Nov 2012 07:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=Tyz2TchTulg62ku7SIFM0M8iDLE0usJIDsGW5QcTrpk=; b=e65vbStjDDgixA18eAp7rPZI53hB2U+zw9agVH92Szl9xNP9c5CP7G8dIWzkmyTSnt Z/OuXGQFo1gGFWOPvPNF8JUDiqcIryTiqP07Qg17S99ZODvMfN2hVMQnWYzztXa0zhrE NwOLnWwNhtyCwhQ+X8t9OZwNqMjZ+d91is1sAU1Segj3x11NLE0V7Z9Hth9FUSdhIcUF hCDaYEdiNn+gCesCXMLJAO4BR8sUeMcOdFGtN625EHU0ZmCMSaNpNKsscIt56/ZJT/yP Z0Bkh8w/Jm5BlyS2DNZLq39+wrOrdjxybS0M7ydGQsibMxNYFtIbVsCf2aWwhK6KbZPh pvvA== Received: by 10.66.85.10 with SMTP id d10mr16944795paz.52.1352387353270; Thu, 08 Nov 2012 07:09:13 -0800 (PST) Received: from [130.129.65.139] (dhcp-418b.meeting.ietf.org. [130.129.65.139]) by mx.google.com with ESMTPS id uk9sm16064833pbc.63.2012.11.08.07.09.10 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 07:09:12 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 08 Nov 2012 10:09:07 -0500 From: Victor Kuarsingh To: , Message-ID: Thread-Topic: [homenet] regarding recursive DHCPv6-PD (and architecture document) In-Reply-To: <509BC1A0.5030509@gridmerge.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:09:14 -0000 >> even though this would destroy the benefits of subnetting. >I think it is arguable whether bridging is the least damaging >solution. It fundamentally does not work with route-over multi-link >subnets and would therefore require some extra L2 weirdness at a LLN >border router. If ISPs are going to hobble us with /64s then I think you >will find NPTv6 solutions appearing for the same reason NAT is used >today. There are alternatives but, as noted in the architecture draft, >these break SLAAC. So I think the onus is to push back on ISPs ofering >/64s if we want to avoid any kludges. >> Just to further some of the comments I made yesterday. I understand the we don=B9t want a /64 to show up, but this may occur for reasons other then the primary intention of the ISP. Many things occur in a network - IP depletion/low avail blocks, errors, mis-configuration etc. No matter why it occurs, ignoring this case is likely not a good idea. I agree with earlier comments that this can be considered as a failure mode. It still needs to be considered for good engineering on how CPEs and homenet gear will behave. Regards, Victor Kuarsingh >> From john_leddy@cable.comcast.com Thu Nov 8 07:11:12 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF32921F85F4 for ; Thu, 8 Nov 2012 07:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=-3.043, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XHzWFoek4it for ; Thu, 8 Nov 2012 07:11:12 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id D80F121F8460 for ; Thu, 8 Nov 2012 07:11:11 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.33413502; Thu, 08 Nov 2012 10:03:07 -0500 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.212]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 10:11:05 -0500 From: "Leddy, John" To: Victor Kuarsingh , "robert.cragie@gridmerge.com" , "homenet@ietf.org" Thread-Topic: [homenet] regarding recursive DHCPv6-PD (and architecture document) Thread-Index: AQHNvcMH87DT/X8zv0yEl/7EdX4CApff+j+A Date: Thu, 8 Nov 2012 15:11:04 +0000 Message-ID: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="euc-kr" Content-ID: <3E0B337EE8BA574884BFEB412A38C56A@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:11:12 -0000 V2hhdCB3b3VsZCBoYXBwZW4gdG9kYXkgaWYgYSAvNjQgc2hvd2VkIHVwPyAgV2h5IGNoYW5nZSB0 aGF0IGJlaGF2aW9yPw0KDQpPbiAxMS84LzEyIDEwOjA5IEFNLCAiVmljdG9yIEt1YXJzaW5naCIg PHZpY3Rvci5rdWFyc2luZ2hAZ21haWwuY29tPiB3cm90ZToNCg0KPg0KPj4+ICAgZXZlbiB0aG91 Z2ggdGhpcyB3b3VsZCBkZXN0cm95IHRoZSBiZW5lZml0cyBvZiBzdWJuZXR0aW5nLg0KPj48UkND PkkgdGhpbmsgaXQgaXMgYXJndWFibGUgd2hldGhlciBicmlkZ2luZyBpcyB0aGUgbGVhc3QgZGFt YWdpbmcNCj4+c29sdXRpb24uIEl0IGZ1bmRhbWVudGFsbHkgZG9lcyBub3Qgd29yayB3aXRoIHJv dXRlLW92ZXIgbXVsdGktbGluaw0KPj5zdWJuZXRzIGFuZCB3b3VsZCB0aGVyZWZvcmUgcmVxdWly ZSBzb21lIGV4dHJhIEwyIHdlaXJkbmVzcyBhdCBhIExMTg0KPj5ib3JkZXIgcm91dGVyLiBJZiBJ U1BzIGFyZSBnb2luZyB0byBob2JibGUgdXMgd2l0aCAvNjRzIHRoZW4gSSB0aGluayB5b3UNCj4+ d2lsbCBmaW5kIE5QVHY2IHNvbHV0aW9ucyBhcHBlYXJpbmcgZm9yIHRoZSBzYW1lIHJlYXNvbiBO QVQgaXMgdXNlZA0KPj50b2RheS4gVGhlcmUgYXJlIGFsdGVybmF0aXZlcyBidXQsIGFzIG5vdGVk IGluIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQsDQo+PnRoZXNlIGJyZWFrIFNMQUFDLiBTbyBJIHRo aW5rIHRoZSBvbnVzIGlzIHRvIHB1c2ggYmFjayBvbiBJU1BzIG9mZXJpbmcNCj4+LzY0cyBpZiB3 ZSB3YW50IHRvIGF2b2lkIGFueSBrbHVkZ2VzLjwvUkNDPg0KPj4+DQo+DQo+SnVzdCB0byBmdXJ0 aGVyIHNvbWUgb2YgdGhlIGNvbW1lbnRzIEkgbWFkZSB5ZXN0ZXJkYXkuICBJIHVuZGVyc3RhbmQg dGhlDQo+d2UgZG9uqfZ0IHdhbnQgYSAvNjQgdG8gc2hvdyB1cCwgYnV0IHRoaXMgbWF5IG9jY3Vy IGZvciByZWFzb25zIG90aGVyIHRoZW4NCj50aGUgcHJpbWFyeSBpbnRlbnRpb24gb2YgdGhlIElT UC4gIE1hbnkgdGhpbmdzIG9jY3VyIGluIGEgbmV0d29yayAtIElQDQo+ZGVwbGV0aW9uL2xvdyBh dmFpbCBibG9ja3MsIGVycm9ycywgbWlzLWNvbmZpZ3VyYXRpb24gZXRjLiAgTm8gbWF0dGVyIHdo eQ0KPml0IG9jY3VycywgaWdub3JpbmcgdGhpcyBjYXNlIGlzIGxpa2VseSBub3QgYSBnb29kIGlk ZWEuDQo+DQo+SSBhZ3JlZSB3aXRoIGVhcmxpZXIgY29tbWVudHMgdGhhdCB0aGlzIGNhbiBiZSBj b25zaWRlcmVkIGFzIGEgZmFpbHVyZQ0KPm1vZGUuICBJdCBzdGlsbCBuZWVkcyB0byBiZSBjb25z aWRlcmVkIGZvciBnb29kIGVuZ2luZWVyaW5nIG9uIGhvdyBDUEVzDQo+YW5kIGhvbWVuZXQgZ2Vh ciB3aWxsIGJlaGF2ZS4NCj4NCj5SZWdhcmRzLA0KPg0KPlZpY3RvciBLdWFyc2luZ2gNCj4NCj4N Cj4+Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+aG9tZW5ldCBtYWlsaW5nIGxpc3QNCj5ob21lbmV0QGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lbmV0DQoNCg== From mattia.rossi.mailinglists@gmail.com Thu Nov 8 07:36:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6012621F8A78 for ; Thu, 8 Nov 2012 07:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBmFdfI4ulFV for ; Thu, 8 Nov 2012 07:36:32 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A810F21F8450 for ; Thu, 8 Nov 2012 07:36:31 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jc3so1312811bkc.31 for ; Thu, 08 Nov 2012 07:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vzNlNBTztIDY6pueYKIOJe8lZOepiQ1e829Z4yAVZmg=; b=LSf6Fe+4td4dY7DtnFsiK6x9EucJhsHYicdYyMdy2EmMo68RBpXP+Zk8+cNcDW6k2U FsjO6fjK6daFcHGkkoerc9qxWqLqSGw0kHrHQfnmJB8XrtTg0p+Ld/2ABDsoNfITuG0P +AmuA6eVRwSatRSIIjT52pYKJUfiNzyV2yDSeTmbWngcSHwCLJ8k1ms0AwhBPXlJW91R Mv6VF5/fZ0st40j2q3/gtIHpxZEh96IzNzzjsxg/RJ38sr2rg5AkfLl7MsDHjAJevbCF Z6q85DZArOe947l+MQDrbMwVJbBBdrDwVMcD31P9hjrmTahkSpdD+jhMRnYf0C/24ZZ5 04Dg== Received: by 10.204.130.204 with SMTP id u12mr2284482bks.17.1352388990542; Thu, 08 Nov 2012 07:36:30 -0800 (PST) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id v14sm17223222bkv.10.2012.11.08.07.36.28 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 07:36:29 -0800 (PST) Message-ID: <509BD17C.4020609@gmail.com> Date: Thu, 08 Nov 2012 16:36:28 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BBF02.507@gmail.com> In-Reply-To: <509BBF02.507@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:36:32 -0000 > > Also consider a dual-homed homenet where one ISP gives a /64 and the > other gives a /56. I guess that has to revert to bridging mode too. > > I was going to suggest a solution, where the router within the homenet simply asks for a DHCP-PD, and if it gets one it keeps routing, otherwise it reverts to bridging. But if the homenet is dual-homed with a /64 and a /56, this would automatically exclude the /64 prefix from being used, ass the router would get a DHCP-PD from the /56 but not from the /64 and wouldn't even know that that /64 exists. But maybe that's a good thing unless the /56 points to a walled garden.... In that case a reachability test to a specific test router in the Internet could tell about the walled garden, and eventually force the router to put itself in bridging mode. Mat From lee.howard@twcable.com Thu Nov 8 07:44:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC46921F8A69 for ; Thu, 8 Nov 2012 07:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSqMfXVmumcF for ; Thu, 8 Nov 2012 07:44:55 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB5921F894E for ; Thu, 8 Nov 2012 07:44:55 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,738,1344225600"; d="scan'208";a="448192088" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 08 Nov 2012 10:43:27 -0500 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 8 Nov 2012 10:44:10 -0500 From: "Howard, Lee" To: Mikael Abrahamsson Date: Thu, 8 Nov 2012 10:44:09 -0500 Thread-Topic: [homenet] DHCP PD for homenets. Thread-Index: Ac29x+RmMwwvIIr9QwuIHJk7vL/H2w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:44:55 -0000 On 11/8/12 10:07 AM, "Mikael Abrahamsson" wrote: >On Thu, 8 Nov 2012, Howard, Lee wrote: > >>> I think we should aim higher do what's best in the long run, and then >>> CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 >>>more >>> than current generation, initially, but as these requirements spread >>> and more people/ISPs buy, it'll be the new lowest standard and cost >>> will drop. >> >> It's very generous of you to spend other people's money this way. > >What is your suggestion? > >New requirements mean higher spec hw, I don't really see a way around >that. Do you? Stop solving non-existent problems in the most complex way possible. Stop defining "what's best in the long run" as "support Jari and Mark's infinitely complex home networks without configuration." I've made this point to the WG several times. Complexity leads to unpredictability. > >For ISPs who want to save those few dollars, they can offer NAT444 and >then do not need to require more functionality in their CPEs. In the >areas >where customers have a choice, let them choose. Is anyone choosing the Homenet model? Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From brian.e.carpenter@gmail.com Thu Nov 8 07:51:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3467E21F8786 for ; Thu, 8 Nov 2012 07:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zaLo-h04RMl for ; Thu, 8 Nov 2012 07:51:53 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4156321F8595 for ; Thu, 8 Nov 2012 07:51:53 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2264123pbb.31 for ; Thu, 08 Nov 2012 07:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8BN6ThunsAhp+lH7VP1yqQX2YT6XG4Uuj5nbvXmAgCo=; b=XCmXXDVybppeHaZZxN+jhYUaZ9E/CRpq1qJW11mcA547gZQ/8SqwVL5vX+DEdhrt8n CsJk7M7EbmCW+lWt+H1zDr5ckYFkOpvLdD/mFsqwPZnv13CDsWiagUksxAyECTJhZpQx z2TbMQ4e39u7laXDI8bMSobosLxhBfAMAZa0UsARPEnF+GTyw041UoVco6JtiDlqGwI0 whPDQoN+oIXcBPnbFdSMWQ8CoXi2JLpMZKb2jCtQnGHzqU28MyXVlXznjDnnzC7nbNX2 PAByTkpuf92G1HySykoGBMwrhR5d/vRgCDtxUyqrQyeCMK+DaiSUOvNvzvz2XlzodZg6 LYcA== Received: by 10.68.224.138 with SMTP id rc10mr25176099pbc.34.1352389913068; Thu, 08 Nov 2012 07:51:53 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id v9sm16318520paz.6.2012.11.08.07.51.46 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 07:51:47 -0800 (PST) Message-ID: <509BD51D.1090101@gmail.com> Date: Thu, 08 Nov 2012 15:51:57 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: robert.cragie@gridmerge.com, homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:51:54 -0000 On 08/11/2012 15:09, Victor Kuarsingh wrote: >>> even though this would destroy the benefits of subnetting. >> I think it is arguable whether bridging is the least damaging >> solution. It fundamentally does not work with route-over multi-link >> subnets and would therefore require some extra L2 weirdness at a LLN >> border router. If ISPs are going to hobble us with /64s then I think y= ou >> will find NPTv6 solutions appearing for the same reason NAT is used >> today. There are alternatives but, as noted in the architecture draft,= >> these break SLAAC. So I think the onus is to push back on ISPs ofering= >> /64s if we want to avoid any kludges. >=20 > Just to further some of the comments I made yesterday. I understand th= e > we don=C2=B9t want a /64 to show up, but this may occur for reasons oth= er then > the primary intention of the ISP. Many things occur in a network - IP > depletion/low avail blocks, errors, mis-configuration etc. No matter w= hy > it occurs, ignoring this case is likely not a good idea. >=20 > I agree with earlier comments that this can be considered as a failure > mode. It still needs to be considered for good engineering on how CPEs= > and homenet gear will behave. Exactly. It would be very bad for the end users to ignore this reality. On 08/11/2012 15:02, Sander Steffann wrote: >> > So let's just say that giving a single /64 to the home is incompatib= le with homenet architecture, and we need more addresses. I'm fine with t= hat. >=20 > Yes please. I think some ISPs *need* to get a signal like this. Sure, but that does *not* excuse us from specifying how the end user gets service in such a situation. Brian From acee.lindem@ericsson.com Thu Nov 8 07:56:33 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197DB21F8B06 for ; Thu, 8 Nov 2012 07:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuoR-BHeHgoF for ; Thu, 8 Nov 2012 07:56:32 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED0921F8522 for ; Thu, 8 Nov 2012 07:56:32 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA8G1mX0000418; Thu, 8 Nov 2012 10:01:49 -0600 Received: from EUSAAHC008.ericsson.se (147.117.188.96) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 10:56:24 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 10:56:24 -0500 From: Acee Lindem To: Teco Boot Thread-Topic: [homenet] OSPFv3 timers Thread-Index: AQHNvWgxke9hRLx+j0u6WnNdeH5Ji5fgO/AAgAAWogCAABmegA== Date: Thu, 8 Nov 2012 15:56:24 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47019348@EUSAAMB101.ericsson.se> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <48E9ED8D-FD29-45C7-B45D-4E470EC0DEE9@inf-net.nl> In-Reply-To: <48E9ED8D-FD29-45C7-B45D-4E470EC0DEE9@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-74-420824713"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:56:33 -0000 --Apple-Mail-74-420824713 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I noticed it had been reduced from minutes to 30 seconds in this = version. I guess that rules out RIPng. Since this is a new = specification we'll take lower hello/dead under advisement. However, I = doubt we go as low as 1 and 4.=20 Acee=20 On Nov 8, 2012, at 9:24 AM, Teco Boot wrote: >=20 > Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >=20 >>=20 >> On Nov 7, 2012, at 11:18 PM, Teco Boot wrote: >>=20 >>> I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the = proposal doesn't meet expectations of users, with regard of protocol = convergence. The default timers are far too conservative. First reconfig = on OSPF router in my hands is adjust timers on high speed interfaces to = hello=3D1 and dead=3D4. This is a bit better than what old days bridges = with STP do. >>=20 >> This was not considered a requirement in the home. Refer to the = section 3.5 in the homenet architecture document.=20 >=20 > Right. Dead=3D40 does *not* meet the requirement. >=20 > See also = http://www.ietf.org/mail-archive/web/homenet/current/msg01245.html >=20 > Teco >=20 >>=20 >>> Minor: the timers are not defaults. These are sample values. I have = seen routers with different defaults than RFC 5340, for certain = interface types. >>=20 >> I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >>=20 >>>=20 >>> For autoconfig OSPF, I prefer removal of the restriction that all = routers on a link MUST use same timers. That provides flexibility like = OLSR. If this is not possible because of reasons for DR selection, I = suggest removal of DR completely and configure all interfaces in P2MP. = Or MANET interface type, if we want to. Question is: which MANET = extension. >>=20 >> I'm not sure if there is a real requirement. Routers on the link need = to agree on the timer values lest we impact more of the protocol than = necessary. Hence, if this is required, the way forward would be for = routers on shared links to adopt the timers from their neighbor(s). For = simplicity, the same rules used for DR preference could be used.=20 >>=20 >> Thanks, >> Acee >>=20 >>>=20 >>> [posted here, because requirements come from Homenet] >>>=20 >>> Teco >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >=20 --Apple-Mail-74-420824713 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwODE1NTYxOVowIwYJKoZI hvcNAQkEMRYEFJPPMIcTjsYbvWYe3HFN+1Wg8/MhMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgEaKX5T7Lh7+jgg6LnTVV1l7L/BQgF8X2x+yUI81Op2wvXWbt9hSpbpNaDFDmMm4 UKDdmSpSbbYhbSZEZ1MIZhDc687ZUK/P12Zr6WpZ3BSiHPIL/1a0I+I//x4+/Ws2ynMWVUqqsfOF CfGCou29bQ1pp/q3pNBnUkOZZ6i9yMsjAAAAAAAA --Apple-Mail-74-420824713-- From mattia.rossi.mailinglists@gmail.com Thu Nov 8 08:15:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6389C21F88EF for ; Thu, 8 Nov 2012 08:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKP1wdXRyFxs for ; Thu, 8 Nov 2012 08:15:54 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3FE21F87E5 for ; Thu, 8 Nov 2012 08:15:54 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so2514167lbo.31 for ; Thu, 08 Nov 2012 08:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jzIJInq8/R6y3cDWyonS7i4C8XNlbzw2SXjdnM/NAqI=; b=JmRvq2HvfotBVO9ODi3Bvnx74v2BRDH/J4KI2LdkuZSBzIasL3gX95kRooEyLJvwtr bRCtWuDnI0gO5ki7lKqEuRdOU5ML9A68VaZ4puW1togH5Q+/hUFuELWt1KHKrAdJ9Xqc VjVF2GcWBgpGForWFlRlVy5UP+3okR5Xsrg52OocsmnPEM+/vFWQHSYOoRQPzN+s+XK3 HTEGo1fEEQO7+2cY884gkQZ2RCbnPThl3PBzfSJGj1TLl33ZQuoidU6sX1hDYnbUrdH0 IHGvIuNHcw8opGBCneXyfmmWmNKzq8NX9Q3lXPToWzDSX8drQzEXYeLJ70s62/3qvsuJ rq6Q== Received: by 10.112.36.200 with SMTP id s8mr3549454lbj.92.1352391353446; Thu, 08 Nov 2012 08:15:53 -0800 (PST) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id ts2sm9270033lab.10.2012.11.08.08.15.51 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:15:52 -0800 (PST) Message-ID: <509BDAB6.3010508@gmail.com> Date: Thu, 08 Nov 2012 17:15:50 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <509BBD36.4080601@gmail.com> In-Reply-To: <509BBD36.4080601@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:15:55 -0000 >>> I don't think bridging should be considered for homenet. Don't forget >>> the following in the charter: >>> >>> "Also, link layer networking technology is poised to become more >>> heterogeneous, as networks begin to employ both traditional Ethernet >>> technology and link layers designed for low-powered sensor networks." >>> >>> In a lot of these conversations, the "lightswitch guys" (as someone >>> called the LLN proponents) seem to get forgotten. >>> >> So what happens if the "lightswitch guys" want to plug-in a router, >> which they have to, as they can't bridge, but there's only one exit >> router from one ISP which is managed and gets a /64 only? >> SLAAC relay? I think in this case a /64 is simply not acceptable. > OK, so there are failure cases and that too needs to be stated in the > architecture. Send text. > So your text: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. might become: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. There are cases where neither bridging mode nor NPTv6, nor DHCPv6 are feasible, e.g. if there are LLN subnets within the homenet which require remote access. In such cases a /64 assignment from an ISP will break the home network, and should therefore be avoided. Feel free to rewrite it. Mat From teco@inf-net.nl Thu Nov 8 08:18:00 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3095221F87E5 for ; Thu, 8 Nov 2012 08:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nhCl1NBmGF7 for ; Thu, 8 Nov 2012 08:17:59 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFD21F8A5E for ; Thu, 8 Nov 2012 08:17:59 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1331026dan.31 for ; Thu, 08 Nov 2012 08:17:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DoZ8/WEoSsdbzWSejucSGsgLVMVpMZauoDhfvQTL/84=; b=Gy8gWyBSS3VVjr3mX4159obU2NggFC/1UWzxlqfki3TnWXJhORMk6aqJmgZP95Jk+w I5LLioeK1jlQ2fKAZXGvDQnqmStL52gHrVmwa59sWn83uTE5uH/v21DpQero+5CjHM/J z2Qqh9vVWA/LRJCxISehwzkXz46oD9lpyju8QJrN/xswfNRl6kl7lo2gPy3j98ephsLG ScqBpogSdIIP3L47ZdW4EsxYXA2+9KTE7HD/g/2syH5SIqQWm230eUxVfd320VEsL6kl KT1+89VdrlXY1oPv6lEl2A8UaaBI0c59oF4uTpE/BTTwjzL2Hd/8Lq879hVZ6X883A38 UnhQ== Received: by 10.66.79.198 with SMTP id l6mr17447876pax.43.1352391479385; Thu, 08 Nov 2012 08:17:59 -0800 (PST) Received: from dhcp-1616.meeting.ietf.org (dhcp-1616.meeting.ietf.org. [130.129.22.22]) by mx.google.com with ESMTPS id x6sm16341142pav.29.2012.11.08.08.17.57 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:17:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47019348@EUSAAMB101.ericsson.se> Date: Thu, 8 Nov 2012 17:17:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7183ACAE-3BC0-4616-B9BD-944928D85756@inf-net.nl> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <48E9ED8D-FD29-45C7-B45D-4E470EC0DEE9@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE47019348@EUSAAMB101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl5Hvzz5KUqMyfvMzrO0FIUAM63G6MYK4gX+EKpkapXUYKPeopo922/XvfyxTJB3QmiILqs Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:18:00 -0000 Op 8 nov. 2012, om 16:56 heeft Acee Lindem het volgende geschreven: > I noticed it had been reduced from minutes to 30 seconds in this = version. I guess that rules out RIPng. Since this is a new = specification we'll take lower hello/dead under advisement. However, I = doubt we go as low as 1 and 4.=20 Values similar to RSTP would be fine; hello=3D2, dead=3D6. Dead=3D8 would be more robust, for lost or delayed hello. Wait doesn't need an adjustment if we go for less slow hellos. Teco > Acee=20 > On Nov 8, 2012, at 9:24 AM, Teco Boot wrote: >=20 >>=20 >> Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >>=20 >>>=20 >>> On Nov 7, 2012, at 11:18 PM, Teco Boot wrote: >>>=20 >>>> I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the = proposal doesn't meet expectations of users, with regard of protocol = convergence. The default timers are far too conservative. First reconfig = on OSPF router in my hands is adjust timers on high speed interfaces to = hello=3D1 and dead=3D4. This is a bit better than what old days bridges = with STP do. >>>=20 >>> This was not considered a requirement in the home. Refer to the = section 3.5 in the homenet architecture document.=20 >>=20 >> Right. Dead=3D40 does *not* meet the requirement. >>=20 >> See also = http://www.ietf.org/mail-archive/web/homenet/current/msg01245.html >>=20 >> Teco >>=20 >>>=20 >>>> Minor: the timers are not defaults. These are sample values. I have = seen routers with different defaults than RFC 5340, for certain = interface types. >>>=20 >>> I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >>>=20 >>>>=20 >>>> For autoconfig OSPF, I prefer removal of the restriction that all = routers on a link MUST use same timers. That provides flexibility like = OLSR. If this is not possible because of reasons for DR selection, I = suggest removal of DR completely and configure all interfaces in P2MP. = Or MANET interface type, if we want to. Question is: which MANET = extension. >>>=20 >>> I'm not sure if there is a real requirement. Routers on the link = need to agree on the timer values lest we impact more of the protocol = than necessary. Hence, if this is required, the way forward would be for = routers on shared links to adopt the timers from their neighbor(s). For = simplicity, the same rules used for DR preference could be used.=20 >>>=20 >>> Thanks, >>> Acee >>>=20 >>>>=20 >>>> [posted here, because requirements come from Homenet] >>>>=20 >>>> Teco >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>=20 >>=20 >=20 From andrewmcgr@gmail.com Thu Nov 8 08:29:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28F921F852C for ; Thu, 8 Nov 2012 08:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inb6wW7VTxlc for ; Thu, 8 Nov 2012 08:29:10 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C211F21F8471 for ; Thu, 8 Nov 2012 08:28:59 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1335224dan.31 for ; Thu, 08 Nov 2012 08:28:59 -0800 (PST) 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:x-mailer; bh=oalyfkiNB3c8qVVeniD5DaBtBmIq4LTTkKBI3tGnhSk=; b=kqte3+AESZXq4jBDY8354ZxetFxzn5zljbVqsL7I9HCDEsU8k4fUC472qytWt1NMFg /oJaSle/7VAyRmhvX3FBLqoVi3ag4as03rf8IDZDzgY/tdiRulMqUVaUgK2h6E/6Hm6r XIo7ZHb8erSoORjTmw+NoeYKht41Spu/IGFw3lYgz6gdvQbPNGo1cp10H0rJxQwETp5c rJoasMB424OAsvEjdBEaLL2ux6vBgefKpRLWm0XC9lc2SZleShpnfxSaSjXDYBUpJFCh RNPw6VXggOO4aTbfgG8cGqsWr/0DrvwIpIbzt5CWAsydR/uT3KdAAguiDQM3lxn3paa/ VHMQ== Received: by 10.68.225.73 with SMTP id ri9mr1314081pbc.124.1352392139435; Thu, 08 Nov 2012 08:28:59 -0800 (PST) Received: from dhcp-6425.meeting.ietf.org (dhcp-6425.meeting.ietf.org. [130.129.100.37]) by mx.google.com with ESMTPS id pw2sm16161099pbb.59.2012.11.08.08.28.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:28:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <7183ACAE-3BC0-4616-B9BD-944928D85756@inf-net.nl> Date: Thu, 8 Nov 2012 11:28:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2CF0362E-53D3-4BF7-9BD0-190117BA812F@gmail.com> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <48E9ED8D-FD29-45C7-B45D-4E470EC0DEE9@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE47019348@EUSAAMB101.ericsson.se> <7183ACAE-3BC0-4616-B9BD-944928D85756@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1499) Cc: Acee Lindem , "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:29:11 -0000 On 8/11/2012, at 11:17 AM, Teco Boot wrote: >=20 > Op 8 nov. 2012, om 16:56 heeft Acee Lindem het volgende geschreven: >=20 >> I noticed it had been reduced from minutes to 30 seconds in this = version. I guess that rules out RIPng. Since this is a new = specification we'll take lower hello/dead under advisement. However, I = doubt we go as low as 1 and 4.=20 >=20 > Values similar to RSTP would be fine; hello=3D2, dead=3D6. > Dead=3D8 would be more robust, for lost or delayed hello. > Wait doesn't need an adjustment if we go for less slow hellos. >=20 > Teco If you end up running this on wireless, remember that wireless multicast = tends to be horribly unreliable. So hello=3D2 dead=3D10 is more to the = point, that lets you get the false positive dead router rate down quite = a bit. Andrew= From teco@inf-net.nl Thu Nov 8 08:40:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E0C21F894D for ; Thu, 8 Nov 2012 08:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXfiPykb+gEb for ; Thu, 8 Nov 2012 08:40:19 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B54721F89F5 for ; Thu, 8 Nov 2012 08:39:48 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2252580pad.31 for ; Thu, 08 Nov 2012 08:39:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+pVJ09VpIficFUq9EGgrPfc8fUHTwGqe/CFKv2tzA2c=; b=eqal5D8yx1I/8LuJFqkg/xktHSdOE3XgUHkMx7+meZLIpAZMZyb60fxtEL/5/3PtWl 1POqGSh13O/f+06/CNXPyxSUCAter9nkbFqPSNa2HIvsXnFyiQlpdwIELcrCtjbUzPUJ zZzOZEaddtHjfy6XWuqV9H+beGasFriC8FgOcWeJeXvh9tg2xew9XOcN//e5byKoOqpW MsWKuAZadkR+/u0LOaACyL1motMGgW0CNidp+8vTMzOe8l4Se2tiuSY4Mukzmoc37L5N C4sZlXVxAeuRLywxXsKwHl1prNfZT2DbM8abJPFLjVM+5amY+DqUqOu/mduntVbQiNHY E+8w== Received: by 10.66.87.73 with SMTP id v9mr23964113paz.1.1352392787970; Thu, 08 Nov 2012 08:39:47 -0800 (PST) Received: from dhcp-1616.meeting.ietf.org (dhcp-1616.meeting.ietf.org. [130.129.22.22]) by mx.google.com with ESMTPS id ve6sm16173902pbc.58.2012.11.08.08.39.46 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:39:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2CF0362E-53D3-4BF7-9BD0-190117BA812F@gmail.com> Date: Thu, 8 Nov 2012 17:39:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <045BC28F-51D6-47BA-A674-2E443E54B3EF@inf-net.nl> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <48E9ED8D-FD29-45C7-B45D-4E470EC0DEE9@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE47019348@EUSAAMB101.ericsson.se> <7183ACAE-3BC0-4616-B9BD-944928D85756@inf-net.nl> <2CF0362E-53D3-4BF7-9BD0-190117BA812F@gmail.com> To: Andrew McGregor X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkOgtavZYywWWuI8OwJwTOZSUFUhEROupTku++p6Xe85HZy/y7pmshlA87tRa2AazpRRbnx Cc: Acee Lindem , "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:40:19 -0000 Op 8 nov. 2012, om 17:28 heeft Andrew McGregor het volgende geschreven: >=20 > On 8/11/2012, at 11:17 AM, Teco Boot wrote: >=20 >>=20 >> Op 8 nov. 2012, om 16:56 heeft Acee Lindem het volgende geschreven: >>=20 >>> I noticed it had been reduced from minutes to 30 seconds in this = version. I guess that rules out RIPng. Since this is a new = specification we'll take lower hello/dead under advisement. However, I = doubt we go as low as 1 and 4.=20 >>=20 >> Values similar to RSTP would be fine; hello=3D2, dead=3D6. >> Dead=3D8 would be more robust, for lost or delayed hello. >> Wait doesn't need an adjustment if we go for less slow hellos. >>=20 >> Teco >=20 > If you end up running this on wireless, remember that wireless = multicast tends to be horribly unreliable. So hello=3D2 dead=3D10 is = more to the point, that lets you get the false positive dead router rate = down quite a bit. Yes. This brings us to auto-costs and ETX / ETT.=20 Teco > Andrew From brian.e.carpenter@gmail.com Thu Nov 8 08:57:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2487D21F84DF for ; Thu, 8 Nov 2012 08:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5if19wqJKTH for ; Thu, 8 Nov 2012 08:57:25 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8821F84DC for ; Thu, 8 Nov 2012 08:57:25 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2264696pad.31 for ; Thu, 08 Nov 2012 08:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dmvzJWX5iXTig6CyA/093AldkcueCxg0+CwVcJeOSqI=; b=WT823cz/eOawVRji1GYhTIC0I0XJs47H/qZRGc0ekxkpCTSXKsXepnSQPLS9b/4vAa TuKT+KNmR7v3VM3UXvsJ6KxENa6urfFkrBQC409Uf72eCH14Eo8oD1IV6wfR7DdRb5DK lvdWGfuCTyegqphKGYG22gt2fFr2Ipiylcoq8Ensss6VNPwiIlX5HsCpd/b4rMvdjcZz 9GLn9sRMJj1eArqW2RcfNki+w88GxpHPihlT1zb+97hFMjACuT1Qz9U0R2AeBtBsbUdj LYXbYluAr9jO9HHWOVMLCVqIMmx8wiWis3tj3Yu4rCgdDIWLKM2qepgNOLI8qj7mib9H o0Pw== Received: by 10.68.143.106 with SMTP id sd10mr4432884pbb.62.1352393845293; Thu, 08 Nov 2012 08:57:25 -0800 (PST) Received: from [130.129.67.234] (dhcp-43ea.meeting.ietf.org. [130.129.67.234]) by mx.google.com with ESMTPS id c1sm16390571pav.23.2012.11.08.08.57.19 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:57:22 -0800 (PST) Message-ID: <509BE47A.1030207@gmail.com> Date: Thu, 08 Nov 2012 16:57:30 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mattia Rossi References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <509BBD36.4080601@gmail.com> <509BDAB6.3010508@gmail.com> In-Reply-To: <509BDAB6.3010508@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:57:26 -0000 Mat, That looks good to me, I hope the architecture authors will pick it up. Brian On 08/11/2012 16:15, Mattia Rossi wrote: >>>> I don't think bridging should be considered for homenet. Don't forget >>>> the following in the charter: >>>> >>>> "Also, link layer networking technology is poised to become more >>>> heterogeneous, as networks begin to employ both traditional Ethernet >>>> technology and link layers designed for low-powered sensor networks." >>>> >>>> In a lot of these conversations, the "lightswitch guys" (as someone >>>> called the LLN proponents) seem to get forgotten. >>>> >>> So what happens if the "lightswitch guys" want to plug-in a router, >>> which they have to, as they can't bridge, but there's only one exit >>> router from one ISP which is managed and gets a /64 only? >>> SLAAC relay? I think in this case a /64 is simply not acceptable. >> OK, so there are failure cases and that too needs to be stated in the >> architecture. Send text. >> > So your text: > > The home network needs to be adaptable to such ISP policies, and thus > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if > only a /64 is offered by the ISP, the homenet may be severely > constrained. Attempting to use subnet prefixes longer than /64 > would break SLAAC, and is thus not recommended. Using ULA prefixes > internally with NPTv6 at the boundary would be possible, but is not > recommended for reasons given elsewhere. The least damaging solution > would be for the internal routers to revert to bridging mode, > even though this would destroy the benefits of subnetting. > > might become: > > The home network needs to be adaptable to such ISP policies, and thus > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if > only a /64 is offered by the ISP, the homenet may be severely > constrained. Attempting to use subnet prefixes longer than /64 > would break SLAAC, and is thus not recommended. Using ULA prefixes > internally with NPTv6 at the boundary would be possible, but is not > recommended for reasons given elsewhere. The least damaging solution > would be for the internal routers to revert to bridging mode, > even though this would destroy the benefits of subnetting. > There are cases where neither bridging mode nor NPTv6, nor DHCPv6 > are feasible, e.g. if there are LLN subnets within the homenet > which require remote access. In such cases a /64 assignment from > an ISP will break the home network, and should therefore be avoided. > > > Feel free to rewrite it. > > Mat > > From swmike@swm.pp.se Thu Nov 8 08:58:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F821F8511 for ; Thu, 8 Nov 2012 08:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL6aXQ8HjJ2u for ; Thu, 8 Nov 2012 08:58:39 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 82A6921F8508 for ; Thu, 8 Nov 2012 08:58:39 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A785E9C; Thu, 8 Nov 2012 17:58:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A092A9A; Thu, 8 Nov 2012 17:58:38 +0100 (CET) Date: Thu, 8 Nov 2012 17:58:38 +0100 (CET) From: Mikael Abrahamsson To: "Howard, Lee" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:58:40 -0000 On Thu, 8 Nov 2012, Howard, Lee wrote: > I've made this point to the WG several times. Complexity leads to > unpredictability. Could you please point me to where you have done this. I went back a year and read posts by you, and couldn't really find any such point (not a clear one anyway). > Is anyone choosing the Homenet model? Well, personally I work in a market where people have the option to choose between several ISPs, and competition is quite intense. We plan to offer /56 and we want customers who so choose, to choose us plus another ISP for redundancy. I see more and more people going for home automation and running into RFC1918 related trouble to access this from the outside, so I believe something along the lines of homenet is needed long-term to sort out this mess. Perhaps it'll be more clear to me what you see as the homenet goal after I get the answer to my above question. -- Mikael Abrahamsson email: swmike@swm.pp.se From mcr@sandelman.ca Thu Nov 8 10:58:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD6221F8654 for ; Thu, 8 Nov 2012 10:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1h2LbciNmLM for ; Thu, 8 Nov 2012 10:58:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB2621F85C5 for ; Thu, 8 Nov 2012 10:58:59 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 080C981A9 for ; Thu, 8 Nov 2012 13:50:50 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5C6D3CA0BC for ; Thu, 8 Nov 2012 13:58:58 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org Group" In-reply-to: <509BA4AF.2080308@gmail.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 08 Nov 2012 12:25:19 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Nov 2012 13:58:58 -0500 Message-ID: <14721.1352401138@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:59:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable An ISP that gives out a single /64 is broken. As long as we have a way to indicate "out of /64s" (because that could happen, even if you are given a /48, and have some pathology...), then we are good.=20=20 A home may have multiple ISPs, and people are gonna notice that some of them work better than others. Further, routing in the home is gonna work even if the ISP is lame. The market will notice, and will decide. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnADxAAoJEKD0KQ7Gj3P2TZgIAJg7N8sroeSSyX5+HnAc8uZc 02NLfuX3n8jFQjxuLnGZMTuji3et9MyRrXOMNhdJga12JIjGe1qeU/WOUULbI3GJ I0+W/l+gh1OSjwHrPGVhwm2qhrBQFjXTBwhcjgPLOdyX1ADyf5QN5dsyvYzYXqRo 2TOADTuIY0lCfLh5ePa4wmO6NR7fthtIuRiLAra0CvCZRPMYGaOlKNTzYi06egTJ ePpVknXDCrMadfejzmwzfESelPONBGpVc51ES8aZD6HM73YEKZnm9amvYm3W0ITN IYKKQMreQwlOvv0SZKREOZpO65ja7EeibZndoYRhdA8CdB12I9hqsnOizSkpkR8= =cJc3 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Nov 8 11:00:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5F21F85C5 for ; Thu, 8 Nov 2012 11:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdQcnZqQ3uLH for ; Thu, 8 Nov 2012 11:00:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D3F4821F85D5 for ; Thu, 8 Nov 2012 11:00:58 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 62B0681A9 for ; Thu, 8 Nov 2012 13:52:49 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DF3FDCA0BC for ; Thu, 8 Nov 2012 14:00:57 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-reply-to: <509BBF02.507@gmail.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BBF02.507@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 08 Nov 2012 14:17:38 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Nov 2012 14:00:57 -0500 Message-ID: <14889.1352401257@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:00:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> Also consider a dual-homed homenet where one ISP gives a /64 Brian> and the other gives a /56. I guess that has to revert to Brian> bridging mode too. no. Let's let the /56 work well, and let the /64-ISP break. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnAFpAAoJEKD0KQ7Gj3P272kH/RQ+5DBOSJqVoRzeUr05pEU6 COeodgPP/02L1B6ieCOvvRU7tWgJQjK1cAs0ZG7XgKNpED7G5vUxAAk5eCk0ppOU r+92XvUhp2EiowogF/QYfQuAqLuEL5QzPL7Yzq/tOh9eCiXC9y39VrSLxxDtSXog vkPfyunpKpC4MKQ97VQGUrkesMF+iYbMiZ9Jq8eU7LBjF6qOYsQyEbHXqhq/8oHd R95jV+s++ei2u4DontMVnuF7Z9MT8Wu8FDtuZAHqyouLQHJygsSfHvoYLOyBt9WW kavPJmDRM6xzMhg21JWo5YatuCW2Iwk/MTo+PNIkKOdj0qOklVllOU63zcU2oRY= =3n1j -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Nov 8 11:04:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A8421F84DC for ; Thu, 8 Nov 2012 11:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFc9ZxvpE8sX for ; Thu, 8 Nov 2012 11:04:23 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3263421F84A8 for ; Thu, 8 Nov 2012 11:04:23 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id B1C4381A9; Thu, 8 Nov 2012 13:56:13 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 60DFFCA0BC; Thu, 8 Nov 2012 14:04:22 -0500 (EST) From: Michael Richardson To: Mattia Rossi In-reply-to: <509BB762.8080304@gmail.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> Comments: In-reply-to Mattia Rossi message dated "Thu, 08 Nov 2012 14:45:06 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Nov 2012 14:04:22 -0500 Message-ID: <15116.1352401462@sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:04:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mattia" =3D=3D Mattia Rossi wr= ites: >> In a lot of these conversations, the "lightswitch guys" (as >> someone called the LLN proponents) seem to get forgotten. Mattia> So what happens if the "lightswitch guys" want to plug-in a Mattia> router, which they have to, as they can't bridge, but Mattia> there's only one exit router from one ISP which is managed Mattia> and gets a /64 only? SLAAC relay? I think in this case a Mattia> /64 is simply not acceptable. The lights work in the home (because routing of ULA works fine) Possibly, you can't control them from outside the home. So, ISP that gives out /56 has an obvious way to demonstrate why they suck less than /64-only ISP. It is not clear that all LLNs will even want globally routable address space. Some will. Some won't know what to do with it. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnAI2AAoJEKD0KQ7Gj3P2t6sH/jX75oSeFzCcZ2zgVKKrDi58 bPwDZa2AkTUe30EEYvrSC/NkyjYKWodhiF7pGM+RvK/OPRCcZQK+kuSzBI3hk7IS PE2W7TR1z2Cl2+KbHy52Y94CZzsZomYOARBSL+bPWDO24t88atpckiIFG7ydjqYI M5dQxERJfqR05hj20Hhge61qM8RqdCqMdv+Axt6gk8e6Frn7oeTdjc4OK8oQiEV6 rG7cuzNKnSEjjlgW2iLGmZrrSWkjR5taWA7SHJgb3LQ02CV51QQLN2KmuBEzwT74 rS763mDp5YuIs9wxsQWWvXj+aE2QrFWgl6vXw5S17GTSU8qxJIWBC8qzvgtFvE8= =L/78 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Nov 8 11:07:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9E921F8B99 for ; Thu, 8 Nov 2012 11:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Rt3+emalxR for ; Thu, 8 Nov 2012 11:07:08 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4B121F8AF2 for ; Thu, 8 Nov 2012 11:07:08 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 4DB3381A9 for ; Thu, 8 Nov 2012 13:58:59 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E4873CA0BC for ; Thu, 8 Nov 2012 14:07:07 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-reply-to: <509BDAB6.3010508@gmail.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <509BBD36.4080601@gmail.com> <509BDAB6.3010508@gmail.com> Comments: In-reply-to Mattia Rossi message dated "Thu, 08 Nov 2012 17:15:50 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Nov 2012 14:07:07 -0500 Message-ID: <15237.1352401627@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:07:09 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mattia" =3D=3D Mattia Rossi wr= ites: Mattia> might become: Mattia> The home network needs to be adaptable to such ISP Mattia> policies, and thus make no assumptions about the stability Mattia> of the prefix received from an ISP, or the length of the Mattia> prefix that may be offered. However, if only a /64 is Mattia> offered by the ISP, the homenet may be severely Mattia> constrained. Attempting to use subnet prefixes longer than Mattia> /64 would break SLAAC, and is thus not recommended. Using Mattia> ULA prefixes internally with NPTv6 at the boundary would be Mattia> possible, but is not recommended for reasons given Mattia> elsewhere. The least damaging solution would be for the Mattia> internal routers to revert to bridging mode, even though Mattia> this would destroy the benefits of subnetting. There are I am opposed to this text. Mattia> cases where neither bridging mode nor NPTv6, nor DHCPv6 are Mattia> feasible, e.g. if there are LLN subnets within the homenet Mattia> which require remote access. In such cases a /64 assignment Mattia> from an ISP will break the home network, and should Mattia> therefore be avoided. please remember that multicast is hostile to plain wifi, and regularly breaks it, if you bridge wired to wireless. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnALaAAoJEKD0KQ7Gj3P2dG4H/iJGVhyhe9XedFh53Ssz78ky lI/CGTCeDfVOxdbTfMa2MfS58wycE3x4RgMi2Ix0RGnQiXNHs7Mm5NQ8fsUoxrTY d39BwfJKwojc3pwmhNVe6SvVTtSfoqiF51/OKu+szO9qCM+zuhc72lrWYzW81bXe UOnVp6yT/BEDWXZuWJJGhTW4kMojRpC9dRKrROz8KLoB1l6SLfSTVQk/IZ+5CEzL SqBHVrraiuFfGQqZIsEgT5pkbsF2Lj8EwQssSea0n9VTr9SuyVttSUuQWGbNvg/W kd0qiuFh/k5rU39OpcA4cFIv0xn2DBzBVKsRHk189FMGpzF6t5tl1N2FnAdyIOM= =wMyM -----END PGP SIGNATURE----- --=-=-=-- From teco@inf-net.nl Thu Nov 8 11:08:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179E121F8202 for ; Thu, 8 Nov 2012 11:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkSoVs8fJsTB for ; Thu, 8 Nov 2012 11:08:27 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4B21F8B01 for ; Thu, 8 Nov 2012 11:08:27 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1394243dan.31 for ; Thu, 08 Nov 2012 11:08:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JxGh446N/fcxrHOcOspyAuqLrc77DJhX7oiOIWnjIQo=; b=B3KoKZ/fKQ9o7qMWrqKLnWbk0o9DEzw5s/BjzUyXdvGUQbxuGSGSv6gToOW9wH+tH/ 72O1suovwCN7IG2z8e+MmSmZ2yPXbCOqO0IppSE3fWwUkL4yJ249r0swmMObhVxafbkG Jv2mj2JC7YHKrdn8TgYeFzObd27PaiWVw1VobMjT8/1Vi1xyKJBBFT/LP62LS7np1cVA og8ZQE/KtoX3feWbUXRxzJCzO+j7pm1SKR80PPq1r0mDXLANSxFvXOlzNPWvmbt8Zuo1 iplO0AGxba0hu2KmqBBKvRSNFnMurqNfrfC1GV4vKX+McKlSBHGd/JlKzYVbszAGJhGv XQgA== Received: by 10.68.235.2 with SMTP id ui2mr20041788pbc.163.1352401706752; Thu, 08 Nov 2012 11:08:26 -0800 (PST) Received: from ?IPv6:2001:df8::16:470:15af:a373:35d6? ([2001:df8:0:16:470:15af:a373:35d6]) by mx.google.com with ESMTPS id rk17sm4958252pbb.3.2012.11.08.11.08.25 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 11:08:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> Date: Thu, 8 Nov 2012 20:08:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkMlzqClHJVRMsXLDgBKVOfxlV4U6RM4473cpQBBwfy68e5edehDC9qTJ/wLT+45uQ7703Q Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:08:28 -0000 Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >=20 > I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 Then, we cannot have costs per neighbor, correct? By experience I've became aware this is a bad idea on wireless networks, = like WiFi. What options do we have to fix this? Teco From mcr@sandelman.ca Thu Nov 8 11:11:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90F521F841C for ; Thu, 8 Nov 2012 11:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylnhpS2ebRvJ for ; Thu, 8 Nov 2012 11:11:20 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6651721F8417 for ; Thu, 8 Nov 2012 11:11:20 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 0044081A9; Thu, 8 Nov 2012 14:03:11 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EC165CA0BC; Thu, 8 Nov 2012 14:11:18 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org" In-reply-to: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> Comments: In-reply-to "Leddy, John" message dated "Thu, 08 Nov 2012 15:11:04 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Nov 2012 14:11:18 -0500 Message-ID: <15353.1352401878@sandelman.ca> Sender: mcr@sandelman.ca Cc: "Leddy, John" Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:11:20 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Leddy," =3D=3D Leddy, John writes: Leddy> What would happen today if a /64 showed up? Why change that Leddy> behavior? An RFC6204 router with a single LAN interface is perfectly happy getting a /64. An RFC6204 router with more than one LAN interface that doesn't get enough address space: WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. it doesn't tell us to start bridging. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnAPWAAoJEKD0KQ7Gj3P2lBQIAI4G6Jl04HjtWyAo+fVyRHUo xgKDiz7sy2nSQzrDhxUlUJCZhMjv2sHfE1p4C8Dk2nUUaC8lyEH7IduhsO85vlkW V24unAq8tmoT7yOg4hkf7iK4gBFkMW0RnVABhikg30Idfcrq8VhJktqmNRAkbdhE Ysh84yUxCcZsuDuRMZNm8rwmuox8yngwCAiyD9BrQ3+Psq/g27t5sqpp6JOYhgBT r1Q3FWkVlUSUThy3nkO4UnNZ9ebgCRXWzfQQ4plMrEIAIZCTn38esxSeFeybNsqj 2h5+y2FUczqPXwbc7C7fAssnA4E/QlwXmr9T6P/ovxxctSK8vyFq9eNMIayu2L4= =S0wF -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Nov 8 11:17:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5921F878C for ; Thu, 8 Nov 2012 11:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2e8hAk70xrG for ; Thu, 8 Nov 2012 11:17:25 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id A08C221F8B66 for ; Thu, 8 Nov 2012 11:17:25 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 36F2D81A9 for ; Thu, 8 Nov 2012 14:09:16 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D6276CA0BC for ; Thu, 8 Nov 2012 14:17:24 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-reply-to: <509BD51D.1090101@gmail.com> References: <509BD51D.1090101@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 08 Nov 2012 15:51:57 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Nov 2012 14:17:24 -0500 Message-ID: <15461.1352402244@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:17:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: >> Yes please. I think some ISPs *need* to get a signal like this. Brian> Sure, but that does *not* excuse us from specifying how the Brian> end user gets service in such a situation. so, lets' say you come home with a new fancy router... and you discover that haven't got an electrical outlet to plug it into. Should we solve that problem too? (as homework: are power bars NAT's, Routers, or Bridges?) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnAVEAAoJEKD0KQ7Gj3P2gzEH/js9UuydB2oT5neBIhiCyahY pSH18qb84KgO6P2amDqf5R0x++0OsdHV36q2Qc/aIfsOSVPLHCtdRYyz6gAX28qP bbvGWREyttZxB4yuOZd9c0oVb4HqY42qzbjX+j5Wnrg5rFAMWn36ra/3Kw83wYT1 tA8QuAlCvpUKmYUZfhX/UfJtZi2sF3iQCnG+1pgtfhCG/7PeiOxDZAeIKqNrJCax AW24ti92kLL/pAQNCiq3p7dbAOzyYmHb+sVZ7x63X4XEneqaFCN2Bzf9iQRtq1qR 6vIhRbjTpDj+cuN51pHKTEIkp5BxdyyZ+QQjKKKN/sfbf7zyAXB5MXL5Q39pi/U= =KGDk -----END PGP SIGNATURE----- --=-=-=-- From acee.lindem@ericsson.com Thu Nov 8 11:27:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D70B21F898A for ; Thu, 8 Nov 2012 11:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SfP1pB37+rl for ; Thu, 8 Nov 2012 11:27:13 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A55F821F84C4 for ; Thu, 8 Nov 2012 11:27:13 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qA8JR9m0005349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 13:27:12 -0600 Received: from EUSAAHC008.ericsson.se (147.117.188.96) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 14:27:06 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 14:26:51 -0500 From: Acee Lindem To: Teco Boot Thread-Topic: [homenet] OSPFv3 timers Thread-Index: AQHNvWgxke9hRLx+j0u6WnNdeH5Ji5fgO/AAgABl6YCAAAUngA== Date: Thu, 8 Nov 2012 19:26:51 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4701973A@EUSAAMB101.ericsson.se> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-90-433454874"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:27:14 -0000 --Apple-Mail-90-433454874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You'd have to do this through manual configuration.=20 Thanks, Acee On Nov 8, 2012, at 2:08 PM, Teco Boot wrote: >=20 > Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >>=20 >> I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >=20 > Then, we cannot have costs per neighbor, correct? > By experience I've became aware this is a bad idea on wireless = networks, like WiFi. > What options do we have to fix this? >=20 > Teco >=20 >=20 --Apple-Mail-90-433454874 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwODE5MjY0OVowIwYJKoZI hvcNAQkEMRYEFLnKc/sXkPE09qbvGUrw4cHTnXO4MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFsZzpF0yIhK/RfpNGhvAty8GLTe/Q0OjOPngLnSqEddD3Wm7qN9Br5TcGQQ8ht2 7qmDolRwE1/f6NYO54sqOijKBcbonkHIS2FfMnQ9C+4793W2CA+fbqQlJ0soV3IsXFj6sth9B2lQ 1pppaMtEr5Lts1r/OJmCyYXyGGFXA1NoAAAAAAAA --Apple-Mail-90-433454874-- From mellon@fugue.com Thu Nov 8 11:28:50 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3735821F84E1 for ; Thu, 8 Nov 2012 11:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsmT8rBFqRkT for ; Thu, 8 Nov 2012 11:28:49 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4D21421F84D2 for ; Thu, 8 Nov 2012 11:28:24 -0800 (PST) Received: from dhcp-47bf.meeting.ietf.org (dhcp-47bf.meeting.ietf.org [130.129.71.191]) by toccata.fugue.com (Postfix) with ESMTPSA id DAAB0238067D; Thu, 8 Nov 2012 14:28:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <15353.1352401878@sandelman.ca> Date: Thu, 8 Nov 2012 14:28:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" , "Leddy, John" Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:28:50 -0000 On Nov 8, 2012, at 2:11 PM, Michael Richardson = wrote: > interfaces, the IPv6 CE router SHOULD log a system = management > error. >=20 > it doesn't tell us to start bridging. Sure, but "log a system management error" is not something that a home = router vendor can meaningfully implement, unless it puts a speaker in = the home router and has it start bellowing "out of addresses" in every = known language. But the real problem is that this signal, even if received, will be = misinterpreted as "router is broken, return to Home Despot and replace = with one that isn't broken." From mellon@fugue.com Thu Nov 8 11:36:22 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B0C21F84E9 for ; Thu, 8 Nov 2012 11:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oplva0KaYzGs for ; Thu, 8 Nov 2012 11:36:21 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EDF2921F8453 for ; Thu, 8 Nov 2012 11:36:21 -0800 (PST) Received: from dhcp-47bf.meeting.ietf.org (dhcp-47bf.meeting.ietf.org [130.129.71.191]) by toccata.fugue.com (Postfix) with ESMTPSA id 727BA238067D; Thu, 8 Nov 2012 14:36:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Thu, 8 Nov 2012 14:36:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94B2FA02-9DC5-41C4-840A-D33D903C51F2@nominum.com>, <88DD568A-3D68-419E-ADCC-23A195331078@inf-net.nl> <9CEF28F9-C982-449F-B14B-586B788F8A4E@cisco.com> <72D1D555-D465-4C90-8D6E-D402A4BFEFC2@fugue.com> <2FB9BCF5-0D95-48DC-9709-96F52546DA9D@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , "Ole Troan \(otroan\)" , Ted Lemon Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:36:22 -0000 On Nov 8, 2012, at 8:20 AM, Teco Boot wrote: > Once the client has determined the address of a server, it may under > some circumstances send messages directly to the server using > unicast. The document then goes on to describe under what circumstances the = client may unicast, and they do not include your use case. From Ray.Bellis@nominet.org.uk Thu Nov 8 11:40:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09F221F872E for ; Thu, 8 Nov 2012 11:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbiHpUIwzcne for ; Thu, 8 Nov 2012 11:40:21 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id D91FD21F85B1 for ; Thu, 8 Nov 2012 11:40:20 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=5wIxLuNsmfX8RldQwgcZJLY0d+cEuQk+qNAK+dQwiP8mhH9ViPYgclrR kgyq3UZw9Y3YWvg9WdCsdrV5pRycBTmQFdw/pp0K67lYki88CVZ51pjqc sw01uUZbfyXa/8l; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352403621; x=1383939621; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20regarding=20recursive=20DHC Pv6-PD=20(and=20architecture=0D=0A=09document)|Date:=20Th u,=208=20Nov=202012=2019:40:17=20+0000|Message-ID:=20|To:=20T ed=20Lemon=20|CC:=20"homenet@ietf.org =20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<75d98adc-eb2d-4af5-b37b-f156437e9cbe> |In-Reply-To:=20<534ED16F-6A85-4CBA-991A-614170CDAD40@fug ue.com>|References:=20<9FB60CE5849B194190DC0CDAD4825AEC2F 903245@PACDCEXMB13.cable.comcast.com>=0D=0A=20<15353.1352 401878@sandelman.ca>=0D=0A=20<534ED16F-6A85-4CBA-991A-614 170CDAD40@fugue.com>; bh=mV+t5Pt8JCdBYoaHTGmvniR1YD7z+ftH0uQ5i9C0xkg=; b=ankmMZDIWermIJUirSyDOCKNvlr0BtgxQhAKsuegYpCuuTkpfXPkbsJI ifaWvKfEtqstwaYw6yXfPHRgvxNte1Rm34OiySw9B/n56suMKfqx+Gxlp KmvNbdvlKduTgLE; X-IronPort-AV: E=Sophos;i="4.80,739,1344207600"; d="scan'208";a="36608996" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 08 Nov 2012 19:40:19 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Thu, 8 Nov 2012 19:40:19 +0000 From: Ray Bellis To: Ted Lemon Thread-Topic: [homenet] regarding recursive DHCPv6-PD (and architecture document) Thread-Index: AQHNveTc2kLd9JLQNUiGBk/OLANWP5fgUqQAgAADVIA= Date: Thu, 8 Nov 2012 19:40:17 +0000 Message-ID: References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> In-Reply-To: <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <75d98adc-eb2d-4af5-b37b-f156437e9cbe> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:40:21 -0000 On 8 Nov 2012, at 14:28, Ted Lemon wrote: >=20 > Sure, but "log a system management error" is not something that a home ro= uter vendor can meaningfully implement, unless it puts a speaker in the hom= e router and has it start bellowing "out of addresses" in every known langu= age. >=20 > But the real problem is that this signal, even if received, will be misin= terpreted as "router is broken, return to Home Despot and replace with one = that isn't broken." I note that the Apple Airport Utility pops up warnings about various errors= , some of which relate to sub-optimal network configuration, rather than mi= sconfiguration. In particular, they warn you if you try to use double NAT. Users can acknowledge those warnings, so they no longer appear. I can envisage a box issuing a similar warning if it only gets a /64 from i= ts upstream. It would be nice if there was a generic method for doing this that was vend= or independent, but I guess that's unlikely to happen. Ray From mellon@fugue.com Thu Nov 8 11:56:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8345D21F866B for ; Thu, 8 Nov 2012 11:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60q-80k-QSCq for ; Thu, 8 Nov 2012 11:56:22 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A109D21F85D5 for ; Thu, 8 Nov 2012 11:56:22 -0800 (PST) Received: from dhcp-47bf.meeting.ietf.org (dhcp-47bf.meeting.ietf.org [130.129.71.191]) by toccata.fugue.com (Postfix) with ESMTPSA id 7F9D7238067D; Thu, 8 Nov 2012 14:56:19 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Thu, 8 Nov 2012 14:56:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> To: Ray Bellis X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:56:23 -0000 On Nov 8, 2012, at 2:40 PM, Ray Bellis = wrote: > I note that the Apple Airport Utility pops up warnings about various = errors, some of which relate to sub-optimal network configuration, = rather than misconfiguration. In particular, they warn you if you try = to use double NAT. This is very cool, but even people I know who have Airport base stations = frequently have no idea what to do about these warnings, and most people = don't have Airport base stations=97they have stupidly cheap Linsky = routers. From hansliu@gmail.com Thu Nov 8 12:03:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23C21F843F for ; Thu, 8 Nov 2012 12:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFGdDB1m1UZb for ; Thu, 8 Nov 2012 12:03:22 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2199621F84F2 for ; Thu, 8 Nov 2012 12:03:21 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so2650241lam.31 for ; Thu, 08 Nov 2012 12:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wb3hCM/Jnm4QUkibGJi4kUwi2WvxX4XQXMRjMtrAYH8=; b=oBRb936baPfVNE3xU6xsoMI+uusRxxAD3PVwPsvpJ/0XdD3TCV/EH3MeT7OgNVVklm PA4u7aoOGE77JsvACeiQWYplzgDyqT9HFrh7jsor56oP5c55tKul+meuDxrkN8TI1N29 UK2E7kBPb8PdbR13Zedg2TPk0d/q3Zd0kpXeTqPZ4HKUlORAkjW2D2v/kds+wPKef1FA VoHrXhPXDqmxiGGUwvbfpapl1fEZGeDU6BdVXW4nL3iwuXwb76dnYpIJZbsG6CpqVWV8 hoz0D3lVfl9ErMRA8ctknUYzHN1PTVJJ2nyNLyn/4zYrsLmRUZxVFv44mTDpkhoSdMoo F9+g== MIME-Version: 1.0 Received: by 10.112.17.234 with SMTP id r10mr3755737lbd.72.1352405000753; Thu, 08 Nov 2012 12:03:20 -0800 (PST) Received: by 10.112.42.226 with HTTP; Thu, 8 Nov 2012 12:03:20 -0800 (PST) In-Reply-To: References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> Date: Fri, 9 Nov 2012 04:03:20 +0800 Message-ID: From: Hans Liu To: Ray Bellis Content-Type: text/plain; charset=UTF-8 Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:03:23 -0000 On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis wrote: > > On 8 Nov 2012, at 14:28, Ted Lemon wrote: >> >> Sure, but "log a system management error" is not something that a home router vendor can meaningfully implement, unless it puts a speaker in the home router and has it start bellowing "out of addresses" in every known language. >> >> But the real problem is that this signal, even if received, will be misinterpreted as "router is broken, return to Home Despot and replace with one that isn't broken." > > > > I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration. In particular, they warn you if you try to use double NAT. > > Users can acknowledge those warnings, so they no longer appear. > > I can envisage a box issuing a similar warning if it only gets a /64 from its upstream. As a CPE vendor, I don't think I'd design my product this way. I won't have my router to issue a warning if it only gets a /64 from its upstream. The reason? Users see a warning in either log or LED, they call either the operator or my customer service. I really don't want to say so but the one that will face a problem is the downstream router, and that's not my problem. Sincerely, Hans > > It would be nice if there was a generic method for doing this that was vendor independent, but I guess that's unlikely to happen. > > Ray > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Instead of following the fashion, we lead it through. From andrewmcgr@gmail.com Thu Nov 8 12:21:22 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECC821F8755 for ; Thu, 8 Nov 2012 12:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydPqzK1ndRpb for ; Thu, 8 Nov 2012 12:21:21 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5DA21F86DB for ; Thu, 8 Nov 2012 12:21:21 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2442006pbb.31 for ; Thu, 08 Nov 2012 12:21:21 -0800 (PST) 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:x-mailer; bh=Hhyob9PBrNon6gf6wRKqFI7vVLIwfyYN4jlWieMf2dI=; b=ntMplrMMZpOGtM3oXIjNSpa+DRRWTq9aRdV76E+B8iu30tWFzu2qxu9JXIFKaL8rsP ASUc7t/2BuYU91hWS72pwcIUMT3f2XG/wo4lqUHqtjhqBpObh2caSrdvkcQLat7aWYkL WWEPEqD7/p9D3L1kqrUjmMc46QV0HLUZCssLa3rsTiQxoXSLxq6s1cpcGY1sQU1FTKtu +N1ZLvwqHKnLE6BC42juw05gvUYjU9MEG0EXX4d54OrdVvheZh4JZGvVM90er8dKSrCB 8gkV8Zhz7wmErovjyvIjoExld+dhm+n2rfmGk1nWD4x9EYoxY8NIQwf5Bj501ieb7zLU 0GJw== Received: by 10.68.243.70 with SMTP id ww6mr12617785pbc.108.1352406081002; Thu, 08 Nov 2012 12:21:21 -0800 (PST) Received: from ?IPv6:2001:df8::96:41cc:832f:4228:6f4d? ([2001:df8:0:96:41cc:832f:4228:6f4d]) by mx.google.com with ESMTPS id kb3sm5012966pbc.27.2012.11.08.12.21.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 12:21:14 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <509BD51D.1090101@gmail.com> Date: Thu, 8 Nov 2012 15:21:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <509BD51D.1090101@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: robert.cragie@gridmerge.com, homenet@ietf.org, Victor Kuarsingh Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:21:22 -0000 This whole thread is making me think that specifying that we use either = babel (with attention to getting it documented properly) or one of the = OSPFv4 MANET extensions, in the case where we have only a /64 and = perhaps any time we find we have an 802.11s, ad-hoc or NBMA interface in = play. That way we introduce /128 routes, and everything continues to = work. Andrew On 8/11/2012, at 10:51 AM, Brian E Carpenter = wrote: > On 08/11/2012 15:09, Victor Kuarsingh wrote: >>>> even though this would destroy the benefits of subnetting. >>> I think it is arguable whether bridging is the least damaging >>> solution. It fundamentally does not work with route-over multi-link >>> subnets and would therefore require some extra L2 weirdness at a LLN >>> border router. If ISPs are going to hobble us with /64s then I think = you >>> will find NPTv6 solutions appearing for the same reason NAT is used >>> today. There are alternatives but, as noted in the architecture = draft, >>> these break SLAAC. So I think the onus is to push back on ISPs = ofering >>> /64s if we want to avoid any kludges. >>=20 >> Just to further some of the comments I made yesterday. I understand = the >> we don=B9t want a /64 to show up, but this may occur for reasons = other then >> the primary intention of the ISP. Many things occur in a network - = IP >> depletion/low avail blocks, errors, mis-configuration etc. No matter = why >> it occurs, ignoring this case is likely not a good idea. >>=20 >> I agree with earlier comments that this can be considered as a = failure >> mode. It still needs to be considered for good engineering on how = CPEs >> and homenet gear will behave. >=20 > Exactly. It would be very bad for the end users to ignore this = reality. >=20 > On 08/11/2012 15:02, Sander Steffann wrote: >=20 >>>> So let's just say that giving a single /64 to the home is = incompatible with homenet architecture, and we need more addresses. I'm = fine with that. >>=20 >> Yes please. I think some ISPs *need* to get a signal like this. >=20 > Sure, but that does *not* excuse us from specifying how the end user > gets service in such a situation. >=20 > Brian >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From robert.cragie@gridmerge.com Thu Nov 8 12:39:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B1221F8685 for ; Thu, 8 Nov 2012 12:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5k19VJ7-sop for ; Thu, 8 Nov 2012 12:39:53 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id C953321F8683 for ; Thu, 8 Nov 2012 12:39:52 -0800 (PST) Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TWYtB-0001BF-Tp for homenet@ietf.org; Thu, 08 Nov 2012 20:39:51 +0000 Message-ID: <509C18D1.6010901@gridmerge.com> Date: Thu, 08 Nov 2012 20:40:49 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <509BBD36.4080601@gmail.com> <509BDAB6.3010508@gmail.com> In-Reply-To: <509BDAB6.3010508@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020403010009070903090705" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:39:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020403010009070903090705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Just to be clear - using a /64 will not necessarily break a home network = with a LLN. It's just that some kludge will be needed and the least=20 preferable IMHO for LLNs is bridging. So I would suggest something like: "The home network needs to be adaptable to such ISP policies, and thus=20 make no assumptions about the stability of the prefix received from an=20 ISP, or the length of the prefix that may be offered. However, if only a = /64 is offered by the ISP, the homenet may be severely constrained.=20 Attempting to use subnet prefixes longer than /64 would break SLAAC, and = is thus not recommended. Using ULA prefixes internally with NPTv6 at the = boundary would be possible, but is not recommended for reasons given=20 elsewhere. Another solution would be for the internal routers to revert=20 to bridging mode, even though this would destroy the benefits of=20 subnetting and has serious limitations with regard to heterogeneous link = layer technologies and LLNs." Robert On 08/11/2012 4:15 PM, Mattia Rossi wrote: >>>> I don't think bridging should be considered for homenet. Don't forge= t >>>> the following in the charter: >>>> >>>> "Also, link layer networking technology is poised to become more >>>> heterogeneous, as networks begin to employ both traditional Ethernet= >>>> technology and link layers designed for low-powered sensor networks.= " >>>> >>>> In a lot of these conversations, the "lightswitch guys" (as someone >>>> called the LLN proponents) seem to get forgotten. >>>> >>> So what happens if the "lightswitch guys" want to plug-in a router, >>> which they have to, as they can't bridge, but there's only one exit >>> router from one ISP which is managed and gets a /64 only? >>> SLAAC relay? I think in this case a /64 is simply not acceptable. >> OK, so there are failure cases and that too needs to be stated in the >> architecture. Send text. >> > So your text: > > The home network needs to be adaptable to such ISP policies, and thus= > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if > only a /64 is offered by the ISP, the homenet may be severely > constrained. Attempting to use subnet prefixes longer than /64 > would break SLAAC, and is thus not recommended. Using ULA prefixes > internally with NPTv6 at the boundary would be possible, but is not > recommended for reasons given elsewhere. The least damaging solution > would be for the internal routers to revert to bridging mode, > even though this would destroy the benefits of subnetting. > > might become: > > The home network needs to be adaptable to such ISP policies, and thus= > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if > only a /64 is offered by the ISP, the homenet may be severely > constrained. Attempting to use subnet prefixes longer than /64 > would break SLAAC, and is thus not recommended. Using ULA prefixes > internally with NPTv6 at the boundary would be possible, but is not > recommended for reasons given elsewhere. The least damaging solution > would be for the internal routers to revert to bridging mode, > even though this would destroy the benefits of subnetting. > There are cases where neither bridging mode nor NPTv6, nor DHCPv6 > are feasible, e.g. if there are LLN subnets within the homenet > which require remote access. In such cases a /64 assignment from > an ISP will break the home network, and should therefore be avoided. > > > Feel free to rewrite it. > > Mat > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms020403010009070903090705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDgyMDQwNDlaMCMGCSqGSIb3DQEJBDEWBBSYiknpb+vQOtXyfpaNY3iGDmtHFzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAIhmtn1Pg4VonLnHoVe2hIWlpTFe6kw96+d7PwTdwigJG7f0 oFI0BD0d06lnsVCw3wtw6TG6UBg31WizDJA7CTcE+3Waw16qADyR44bomlxxKwvweLUyXHlZ IQ9YK3ygtiCZdVsKJoKs3URwad8xiDK1T3dTniVreGPVWat7TTBty1gK4VEMGkTJITDCwePx NfpBrA9wQ9XRqLbkAv4bVQpMbFseJTIFr1KnlQMhydRPFJK75Y7JC18rm/U57JqWliqs/TTW nqe6tWIrAHoNBqQmLravkTFq5tBoeVX4EpebzdLFIPkn/KDCiIW8/bjdVHuuln3cZaf99hzs e+CeSOQAAAAAAAA= --------------ms020403010009070903090705-- From john_leddy@cable.comcast.com Thu Nov 8 12:48:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EC821F898A for ; Thu, 8 Nov 2012 12:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.709 X-Spam-Level: X-Spam-Status: No, score=-103.709 tagged_above=-999 required=5 tests=[AWL=1.522, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POkGHqnt4RhD for ; Thu, 8 Nov 2012 12:48:58 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 344A421F894E for ; Thu, 8 Nov 2012 12:48:58 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.41089573; Thu, 08 Nov 2012 13:24:15 -0700 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.212]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:48:50 -0500 From: "Leddy, John" To: "robert.cragie@gridmerge.com" , "homenet@ietf.org" Thread-Topic: [homenet] regarding recursive DHCPv6-PD (and architecture document) Thread-Index: AQHNvfJ0l9q0Uz81Xk2JgGgeg9SX4A== Date: Thu, 8 Nov 2012 20:48:49 +0000 Message-ID: <9FB60CE5849B194190DC0CDAD4825AEC2F903908@PACDCEXMB13.cable.comcast.com> In-Reply-To: <509C18D1.6010901@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <50076A0463216543BF249621C741743C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:48:59 -0000 Can this be generalized for anytime a prefix offered is not large enough to cover the number of interfaces? On 11/8/12 3:40 PM, "Robert Cragie" wrote: >Just to be clear - using a /64 will not necessarily break a home network >with a LLN. It's just that some kludge will be needed and the least >preferable IMHO for LLNs is bridging. > >So I would suggest something like: > >"The home network needs to be adaptable to such ISP policies, and thus >make no assumptions about the stability of the prefix received from an >ISP, or the length of the prefix that may be offered. However, if only a >/64 is offered by the ISP, the homenet may be severely constrained. >Attempting to use subnet prefixes longer than /64 would break SLAAC, and >is thus not recommended. Using ULA prefixes internally with NPTv6 at the >boundary would be possible, but is not recommended for reasons given >elsewhere. Another solution would be for the internal routers to revert >to bridging mode, even though this would destroy the benefits of >subnetting and has serious limitations with regard to heterogeneous link >layer technologies and LLNs." > >Robert > >On 08/11/2012 4:15 PM, Mattia Rossi wrote: >>>>> I don't think bridging should be considered for homenet. Don't forget >>>>> the following in the charter: >>>>> >>>>> "Also, link layer networking technology is poised to become more >>>>> heterogeneous, as networks begin to employ both traditional Ethernet >>>>> technology and link layers designed for low-powered sensor networks." >>>>> >>>>> In a lot of these conversations, the "lightswitch guys" (as someone >>>>> called the LLN proponents) seem to get forgotten. >>>>> >>>> So what happens if the "lightswitch guys" want to plug-in a router, >>>> which they have to, as they can't bridge, but there's only one exit >>>> router from one ISP which is managed and gets a /64 only? >>>> SLAAC relay? I think in this case a /64 is simply not acceptable. >>> OK, so there are failure cases and that too needs to be stated in the >>> architecture. Send text. >>> >> So your text: >> >> The home network needs to be adaptable to such ISP policies, and thus >> make no assumptions about the stability of the prefix received from >> an ISP, or the length of the prefix that may be offered. However, if >> only a /64 is offered by the ISP, the homenet may be severely >> constrained. Attempting to use subnet prefixes longer than /64 >> would break SLAAC, and is thus not recommended. Using ULA prefixes >> internally with NPTv6 at the boundary would be possible, but is not >> recommended for reasons given elsewhere. The least damaging solution >> would be for the internal routers to revert to bridging mode, >> even though this would destroy the benefits of subnetting. >> >> might become: >> >> The home network needs to be adaptable to such ISP policies, and thus >> make no assumptions about the stability of the prefix received from >> an ISP, or the length of the prefix that may be offered. However, if >> only a /64 is offered by the ISP, the homenet may be severely >> constrained. Attempting to use subnet prefixes longer than /64 >> would break SLAAC, and is thus not recommended. Using ULA prefixes >> internally with NPTv6 at the boundary would be possible, but is not >> recommended for reasons given elsewhere. The least damaging solution >> would be for the internal routers to revert to bridging mode, >> even though this would destroy the benefits of subnetting. >> There are cases where neither bridging mode nor NPTv6, nor DHCPv6 >> are feasible, e.g. if there are LLN subnets within the homenet >> which require remote access. In such cases a /64 assignment from >> an ISP will break the home network, and should therefore be avoided. >> >> >> Feel free to rewrite it. >> >> Mat >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > From acee.lindem@ericsson.com Thu Nov 8 12:50:25 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AA321F85D6 for ; Thu, 8 Nov 2012 12:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7MYHdR8QJD6 for ; Thu, 8 Nov 2012 12:50:24 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1357F21F849D for ; Thu, 8 Nov 2012 12:50:24 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qA8Knw6J014733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 14:50:09 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 15:49:57 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:49:57 -0500 From: Acee Lindem To: Andrew McGregor Thread-Topic: [homenet] regarding recursive DHCPv6-PD (and architecture document) Thread-Index: AQHNve6VIIyx+gTKW0+yD1dOZP8fOpfgvSoA Date: Thu, 8 Nov 2012 20:49:56 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470198F6@EUSAAMB101.ericsson.se> References: <509BD51D.1090101@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-97-438440100"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" , "" , Victor Kuarsingh Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:50:25 -0000 --Apple-Mail-97-438440100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Independent of the routing protocol, I don't think we want to inject a = /128 advertisement for every device in the homenet into the homenet = routing domain. Acee=20 On Nov 8, 2012, at 3:21 PM, Andrew McGregor wrote: > This whole thread is making me think that specifying that we use = either babel (with attention to getting it documented properly) or one = of the OSPFv4 MANET extensions, in the case where we have only a /64 and = perhaps any time we find we have an 802.11s, ad-hoc or NBMA interface in = play. That way we introduce /128 routes, and everything continues to = work. >=20 > Andrew >=20 > On 8/11/2012, at 10:51 AM, Brian E Carpenter = wrote: >=20 >> On 08/11/2012 15:09, Victor Kuarsingh wrote: >>>>> even though this would destroy the benefits of subnetting. >>>> I think it is arguable whether bridging is the least damaging >>>> solution. It fundamentally does not work with route-over multi-link >>>> subnets and would therefore require some extra L2 weirdness at a = LLN >>>> border router. If ISPs are going to hobble us with /64s then I = think you >>>> will find NPTv6 solutions appearing for the same reason NAT is used >>>> today. There are alternatives but, as noted in the architecture = draft, >>>> these break SLAAC. So I think the onus is to push back on ISPs = ofering >>>> /64s if we want to avoid any kludges. >>>=20 >>> Just to further some of the comments I made yesterday. I understand = the >>> we don=B9t want a /64 to show up, but this may occur for reasons = other then >>> the primary intention of the ISP. Many things occur in a network - = IP >>> depletion/low avail blocks, errors, mis-configuration etc. No = matter why >>> it occurs, ignoring this case is likely not a good idea. >>>=20 >>> I agree with earlier comments that this can be considered as a = failure >>> mode. It still needs to be considered for good engineering on how = CPEs >>> and homenet gear will behave. >>=20 >> Exactly. It would be very bad for the end users to ignore this = reality. >>=20 >> On 08/11/2012 15:02, Sander Steffann wrote: >>=20 >>>>> So let's just say that giving a single /64 to the home is = incompatible with homenet architecture, and we need more addresses. I'm = fine with that. >>>=20 >>> Yes please. I think some ISPs *need* to get a signal like this. >>=20 >> Sure, but that does *not* excuse us from specifying how the end user >> gets service in such a situation. >>=20 >> Brian >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-97-438440100 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwODIwNDk1NVowIwYJKoZI hvcNAQkEMRYEFISSN9B91TdxVjQVAF7sy9SQwfaQMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgCr4usFa3jPyRSLoWt/WyyDq4GZpBDA1UzaL8BjUVaiatBvOy91P+L/YhRflei13 b1ZwcEwWANdq6BtTceI9OZXvIpEyxQ8im2IxT/4h9Zkaw2QkQvPM+723QBsJLChXNRVPOj59+KHR CzGOF4zvMDlaeYzpPZ1JHxkZeeIERFasAAAAAAAA --Apple-Mail-97-438440100-- From andrewmcgr@gmail.com Thu Nov 8 13:40:45 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5BE21F8786 for ; Thu, 8 Nov 2012 13:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRIFYk6ReQeY for ; Thu, 8 Nov 2012 13:40:45 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1278021F86AD for ; Thu, 8 Nov 2012 13:40:45 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2487252pbb.31 for ; Thu, 08 Nov 2012 13:40:44 -0800 (PST) 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:x-mailer; bh=0GS/QnXxrVFP9DN3Yexoyt6VjeY2sh65lcvniCUshJg=; b=U2h0mN4YCJajR6RneV94uNkMrokpN8xWRCLGm+xFS93eziZVVGKQLaTVp21kQXdwFz qi2GX5h91K1g3SPMIC2FFflAA1nrKxRNdjNai+Zf9LUSTRyW64Rg637psKq1WJso4Q0p amKcR8wWAZ91CxESsvqupsRLh/Bdnps3/PrOZM8NyUmbiiIfTRopBv4X9LJl7oU3xSRl XKKIvIZ0XaG8sboD3YctXU732XQsaVeiKj1TfpANYxmkew91HFmaXx5jt3Mk5lObQPsc QG/PpO6Y5TEB9L5TldYWwZ98JD5yM6Ry770wJS8UYfujSLb17yyQaMZ3KsHp10ukb953 Ivsg== Received: by 10.66.85.10 with SMTP id d10mr19747957paz.52.1352410844871; Thu, 08 Nov 2012 13:40:44 -0800 (PST) Received: from ?IPv6:2001:df8::96:3404:bcae:4e6b:5533? ([2001:df8:0:96:3404:bcae:4e6b:5533]) by mx.google.com with ESMTPS id vk5sm15195917pbc.34.2012.11.08.13.40.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 13:40:43 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470198F6@EUSAAMB101.ericsson.se> Date: Thu, 8 Nov 2012 16:40:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <668C136C-58D3-41BB-9488-1DA58C768258@gmail.com> References: <509BD51D.1090101@gmail.com> <94A203EA12AECE4BA92D42DBFFE0AE470198F6@EUSAAMB101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1499) Cc: "" , "" , Victor Kuarsingh Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:40:45 -0000 Oops, meant to reply to the list the first time... I see no reason not to do this... we'd have to have just about as much = information to bridge successfully, and a few hundred routes is no big = deal. Andrew On 8/11/2012, at 3:49 PM, Acee Lindem wrote: > Independent of the routing protocol, I don't think we want to inject a = /128 advertisement for every device in the homenet into the homenet = routing domain. > Acee=20 > On Nov 8, 2012, at 3:21 PM, Andrew McGregor wrote: >=20 >> This whole thread is making me think that specifying that we use = either babel (with attention to getting it documented properly) or one = of the OSPFv4 MANET extensions, in the case where we have only a /64 and = perhaps any time we find we have an 802.11s, ad-hoc or NBMA interface in = play. That way we introduce /128 routes, and everything continues to = work. >>=20 >> Andrew >>=20 >> On 8/11/2012, at 10:51 AM, Brian E Carpenter = wrote: >>=20 >>> On 08/11/2012 15:09, Victor Kuarsingh wrote: >>>>>> even though this would destroy the benefits of subnetting. >>>>> I think it is arguable whether bridging is the least damaging >>>>> solution. It fundamentally does not work with route-over = multi-link >>>>> subnets and would therefore require some extra L2 weirdness at a = LLN >>>>> border router. If ISPs are going to hobble us with /64s then I = think you >>>>> will find NPTv6 solutions appearing for the same reason NAT is = used >>>>> today. There are alternatives but, as noted in the architecture = draft, >>>>> these break SLAAC. So I think the onus is to push back on ISPs = ofering >>>>> /64s if we want to avoid any kludges. >>>>=20 >>>> Just to further some of the comments I made yesterday. I = understand the >>>> we don=B9t want a /64 to show up, but this may occur for reasons = other then >>>> the primary intention of the ISP. Many things occur in a network - = IP >>>> depletion/low avail blocks, errors, mis-configuration etc. No = matter why >>>> it occurs, ignoring this case is likely not a good idea. >>>>=20 >>>> I agree with earlier comments that this can be considered as a = failure >>>> mode. It still needs to be considered for good engineering on how = CPEs >>>> and homenet gear will behave. >>>=20 >>> Exactly. It would be very bad for the end users to ignore this = reality. >>>=20 >>> On 08/11/2012 15:02, Sander Steffann wrote: >>>=20 >>>>>> So let's just say that giving a single /64 to the home is = incompatible with homenet architecture, and we need more addresses. I'm = fine with that. >>>>=20 >>>> Yes please. I think some ISPs *need* to get a signal like this. >>>=20 >>> Sure, but that does *not* excuse us from specifying how the end user >>> gets service in such a situation. >>>=20 >>> Brian >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From mellon@fugue.com Thu Nov 8 13:44:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A898A21F8860 for ; Thu, 8 Nov 2012 13:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JTUYmP1rCsV for ; Thu, 8 Nov 2012 13:44:40 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CC26D21F8738 for ; Thu, 8 Nov 2012 13:44:40 -0800 (PST) Received: from dhcp-47bf.meeting.ietf.org (dhcp-47bf.meeting.ietf.org [130.129.71.191]) by toccata.fugue.com (Postfix) with ESMTPSA id 5E4E9238067D; Thu, 8 Nov 2012 16:44:39 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <668C136C-58D3-41BB-9488-1DA58C768258@gmail.com> Date: Thu, 8 Nov 2012 16:44:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <509BD51D.1090101@gmail.com> <94A203EA12AECE4BA92D42DBFFE0AE470198F6@EUSAAMB101.ericsson.se> <668C136C-58D3-41BB-9488-1DA58C768258@gmail.com> To: Andrew McGregor X-Mailer: Apple Mail (2.1499) Cc: "" , Acee Lindem , "" , Victor Kuarsingh Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:44:41 -0000 On Nov 8, 2012, at 4:40 PM, Andrew McGregor = wrote: > I see no reason not to do this... we'd have to have just about as much = information to bridge successfully, and a few hundred routes is no big = deal. +1 I realize that I've been arguing for a different solution, but I agree = that this is better. From acee.lindem@ericsson.com Thu Nov 8 14:09:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA0221F84A5 for ; Thu, 8 Nov 2012 14:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHlQPGFmvAjb for ; Thu, 8 Nov 2012 14:09:20 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5A56321F8B4F for ; Thu, 8 Nov 2012 14:09:19 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA8MEX18024117; Thu, 8 Nov 2012 16:14:34 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 17:09:09 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 17:09:09 -0500 From: Acee Lindem To: Ted Lemon Thread-Topic: [homenet] regarding recursive DHCPv6-PD (and architecture document) Thread-Index: AQHNve6VIIyx+gTKW0+yD1dOZP8fOpfgvSoAgAAOKgCAAAEfgIAABtcA Date: Thu, 8 Nov 2012 22:09:08 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47019A04@EUSAAMB101.ericsson.se> References: <509BD51D.1090101@gmail.com> <94A203EA12AECE4BA92D42DBFFE0AE470198F6@EUSAAMB101.ericsson.se> <668C136C-58D3-41BB-9488-1DA58C768258@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-99-443192390"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" , "" , Victor Kuarsingh , Andrew McGregor Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 22:09:21 -0000 --Apple-Mail-99-443192390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 8, 2012, at 4:44 PM, Ted Lemon wrote: > On Nov 8, 2012, at 4:40 PM, Andrew McGregor = wrote: >> I see no reason not to do this... we'd have to have just about as = much information to bridge successfully, and a few hundred routes is no = big deal. Is a few hundred enough to meet the present and future homenet = requirements?=20 >=20 > +1 >=20 > I realize that I've been arguing for a different solution, but I agree = that this is better. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-99-443192390 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwODIyMDkwN1owIwYJKoZI hvcNAQkEMRYEFNWSHzjKjrAD3pI5VajU0bGtab/MMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgGYAPoVOGserc+lAifS7SuZ1PXiNu7jNuyIOiDEm8M2MvQGr6oazuUC0evfWu/dQ KAe/PZNdGkokjyF2iIKb/YRsiErU7n0ApudltqjP2bbN2jLR+QltttV3Hx6aaQ/3MYqKfLYxP1bL Xp2DprpXixpIesbZb3MV5zd4/6SSramHAAAAAAAA --Apple-Mail-99-443192390-- From simon@thekelleys.org.uk Thu Nov 8 14:51:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33621F85E8 for ; Thu, 8 Nov 2012 14:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEzfAtJ65wYQ for ; Thu, 8 Nov 2012 14:51:37 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 2B63B21F85DA for ; Thu, 8 Nov 2012 14:51:35 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:49001 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TWawe-0000Rm-K8 for homenet@ietf.org; Thu, 08 Nov 2012 22:51:32 +0000 Received: from dhcp-16fb.meeting.ietf.org ([130.129.22.251]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TWawd-0003y6-Tb for homenet@ietf.org; Thu, 08 Nov 2012 22:51:32 +0000 Message-ID: <509C3771.2030700@thekelleys.org.uk> Date: Thu, 08 Nov 2012 22:51:29 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <509BD51D.1090101@gmail.com> <94A203EA12AECE4BA92D42DBFFE0AE470198F6@EUSAAMB101.ericsson.se> <668C136C-58D3-41BB-9488-1DA58C768258@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 22:51:37 -0000 On 08/11/12 21:44, Ted Lemon wrote: > On Nov 8, 2012, at 4:40 PM, Andrew McGregor wrote: >> I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal. > > +1 > > I realize that I've been arguing for a different solution, but I agree that this is better. > For the stragglers, is this backwards compatible with existing devices? Will my Android phone, which expects to do DHCPv4 and SLAAC in one or more IPv6 /64s, connect unmodified to such a network? Simon. From mattia.rossi.mailinglists@gmail.com Fri Nov 9 00:00:39 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FABD21F8BA0 for ; Fri, 9 Nov 2012 00:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hbrf7R2EKoK for ; Fri, 9 Nov 2012 00:00:39 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0AB921F8B84 for ; Fri, 9 Nov 2012 00:00:38 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jg9so22724bkc.31 for ; Fri, 09 Nov 2012 00:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SJbmLozp6KRCpkgNPuX5hotd/VDAkVHO3Z+jPIEd0n0=; b=zG+cJOesFWHvkd4CebH0ypvz+eWO3euwjwmnnt6dHUd4Nfg6zM9mLfkZaG5KKD42X6 2HoPN5zZm6RyTvsC2XmgSj/PKR36nxtfB6kBRHrVaz3yc7dgvDDm56saFXi53a0ogbeZ JhPIwwqJ85wSneVD2n5i7kAclcBc91pO+RkRMidNSyeKKf+aUaVaz6hxTkkrYjEqZsvJ 8u2YLSh7Tzj+vuIAtEDILvqycVFspzkfqBpmwdAguod5kZAzWoliNO8rFtSbM7yznFAn xQ008Usq/0VjcGj9iTPox0v19afWbGklI9C8z4qWLm5AAIoxDVO5Cig+eqD17tD2xcLI uS/Q== Received: by 10.204.13.9 with SMTP id z9mr3160877bkz.132.1352448037589; Fri, 09 Nov 2012 00:00:37 -0800 (PST) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id j24sm18228000bkv.0.2012.11.09.00.00.35 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 00:00:36 -0800 (PST) Message-ID: <509CB822.50209@gmail.com> Date: Fri, 09 Nov 2012 09:00:34 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Michael Richardson References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <15116.1352401462@sandelman.ca> In-Reply-To: <15116.1352401462@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:00:39 -0000 Am 08.11.2012 20:04, schrieb Michael Richardson: >>>>>> "Mattia" == Mattia Rossi writes: > >> In a lot of these conversations, the "lightswitch guys" (as > >> someone called the LLN proponents) seem to get forgotten. > > Mattia> So what happens if the "lightswitch guys" want to plug-in a > Mattia> router, which they have to, as they can't bridge, but > Mattia> there's only one exit router from one ISP which is managed > Mattia> and gets a /64 only? SLAAC relay? I think in this case a > Mattia> /64 is simply not acceptable. > > The lights work in the home (because routing of ULA works fine) > Possibly, you can't control them from outside the home. So, ISP that > gives out /56 has an obvious way to demonstrate why they suck less than > /64-only ISP. This is exactly the message that should be conveyed by the draft > > It is not clear that all LLNs will even want globally routable address > space. Some will. Some won't know what to do with it. I agree on that. That's why I took the case where they want globally routable addresses to remote control each single light (or sensor - which might sound more plausible to some folks). If the lights just need to communicate within the homenet, ULA's do the job. And as you say, they might even be the better solution. From mattia.rossi.mailinglists@gmail.com Fri Nov 9 00:10:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C521F8B80 for ; Fri, 9 Nov 2012 00:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcyVLdLCpyX4 for ; Fri, 9 Nov 2012 00:10:57 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 775B421F8B7E for ; Fri, 9 Nov 2012 00:10:57 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jg9so26114bkc.31 for ; Fri, 09 Nov 2012 00:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=84iV0Hzs0MM1UqfPLcb+JNJb9x+JbZw7IfajaH1otQ8=; b=NUAVEh1gccJea8IWaX4c4tDO4F80nJAUyl1Rg+9JmYzUu3FB/7gBzbKSwItbBEK1x+ To6No4aYCuBDwF+xczanAIhFn5SaSNorNx+Jnr0AHtadTj2eO55qrREd+B13WAmEml2v sfDyAxSLfQoOXgJ242eITwyxxWiblHiCRQp1b5KorqUshudkQPDQtoNK2iX6YWx/7C3k RIUR7oLR5Yl9RYEWKpdDQrtS7jj3ZqD/BR5/1ze8Bytg+vDZ0xxoXyT85ENPa1hPw0gy PsHncRzwRKeUwqxvHVu2Y62YZRRuY49II+BLuPZBzvT4u0uNV+mVBQ6+l0lIJ9bkIQU8 C2sw== Received: by 10.204.156.81 with SMTP id v17mr3221907bkw.49.1352448656254; Fri, 09 Nov 2012 00:10:56 -0800 (PST) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id g8sm18281679bkv.6.2012.11.09.00.10.54 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 00:10:55 -0800 (PST) Message-ID: <509CBA8E.9000107@gmail.com> Date: Fri, 09 Nov 2012 09:10:54 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <509BBD36.4080601@gmail.com> <509BDAB6.3010508@gmail.com> <509C18D1.6010901@gridmerge.com> In-Reply-To: <509C18D1.6010901@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:10:58 -0000 Am 08.11.2012 21:40, schrieb Robert Cragie: > Just to be clear - using a /64 will not necessarily break a home > network with a LLN. It's just that some kludge will be needed and the > least preferable IMHO for LLNs is bridging. > Yes, I agree, and you can't force the LLN routers to be some high-end routers able to do all the necessary magic to work around the problems due to the assignment of a /64 from the ISP. > So I would suggest something like: > > "The home network needs to be adaptable to such ISP policies, and thus > make no assumptions about the stability of the prefix received from an > ISP, or the length of the prefix that may be offered. However, if only > a /64 is offered by the ISP, the homenet may be severely constrained. > Attempting to use subnet prefixes longer than /64 would break SLAAC, > and is thus not recommended. Using ULA prefixes internally with NPTv6 > at the boundary would be possible, but is not recommended for reasons > given elsewhere. Another solution would be for the internal routers to > revert to bridging mode, even though this would destroy the benefits > of subnetting and has serious limitations with regard to heterogeneous > link layer technologies and LLNs." > I prefer your text :-) Mat From mattia.rossi.mailinglists@gmail.com Fri Nov 9 00:20:00 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C791821F8B8B for ; Fri, 9 Nov 2012 00:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QylxctIYz1QV for ; Fri, 9 Nov 2012 00:20:00 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8A321F8B7A for ; Fri, 9 Nov 2012 00:19:59 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jg9so29099bkc.31 for ; Fri, 09 Nov 2012 00:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Jgo9jhAx02PCyGr2Y1rsV7CXrUvbgbacac5tXT5KVxs=; b=ZesWByNMzAi/633Z4ZlNwOE30YlPWvWxPBQ1IlwtFULZwGU1Nfhr+VSj1DhD8Xv9kY kyDr8ZMFUio4FkwFdPXzaEMktbEa5GV4BeoddVQul9LA/WLVZEFCRfto2K+iJ5lV6tR2 0hyVSuO2nO94oKUUXrZOtErg8iP9XB4/B6TrOjwD/zAWQQKpkGzDJ+92VUc19uoEKlkQ YSrAHOpwu8R4V4qwI4H7EXIHk5XyOTk/TZhHMk3v9vgHJJCPLPQCL9Rg+pisgp0z2zIR eosK4reydTuCDgK1EKz5Dbgpt3r3htjkkDPTk/W3NPAX7M/1t1vtQh9fS0RLTOUyfodr 9Mhg== Received: by 10.204.146.13 with SMTP id f13mr3284904bkv.29.1352449199139; Fri, 09 Nov 2012 00:19:59 -0800 (PST) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id fm5sm18290470bkc.5.2012.11.09.00.19.57 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 00:19:58 -0800 (PST) Message-ID: <509CBCAD.5010503@gmail.com> Date: Fri, 09 Nov 2012 09:19:57 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:20:00 -0000 Am 08.11.2012 21:03, schrieb Hans Liu: > On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis wrote: >> On 8 Nov 2012, at 14:28, Ted Lemon wrote: >>> Sure, but "log a system management error" is not something that a home router vendor can meaningfully implement, unless it puts a speaker in the home router and has it start bellowing "out of addresses" in every known language. >>> >>> But the real problem is that this signal, even if received, will be misinterpreted as "router is broken, return to Home Despot and replace with one that isn't broken." >> >> >> I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration. In particular, they warn you if you try to use double NAT. >> >> Users can acknowledge those warnings, so they no longer appear. >> >> I can envisage a box issuing a similar warning if it only gets a /64 from its upstream. > As a CPE vendor, I don't think I'd design my product this way. I won't > have my router to issue a warning if it only gets a /64 from its > upstream. The reason? Users see a warning in either log or LED, they > call either the operator or my customer service. I really don't want > to say so but the one that will face a problem is the downstream > router, and that's not my problem. > > Your CPE router could be the downstream router. The user buys it, plugs it in, doesn't work. No warning, nothing. He throws it out, even if it's not your fault, and never buys anything from your company again. How's that for a scenario? Mat From Hans_Liu@dlink.com.tw Fri Nov 9 02:16:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF4921F8629 for ; Fri, 9 Nov 2012 02:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TW=1.335] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsZ1iA7A2K8F for ; Fri, 9 Nov 2012 02:16:34 -0800 (PST) Received: from smtp-tp2.dlink.com.tw (smtp-tp2.dlink.com.tw [60.248.210.36]) by ietfa.amsl.com (Postfix) with ESMTP id 91E1121F8625 for ; Fri, 9 Nov 2012 02:16:30 -0800 (PST) Received: from HCB-HUB2.dlink.com.tw (localhost.localdomain [127.0.0.1]) by smtp-tp2.dlink.com.tw (Postfix) with ESMTP id 485E38742D; Fri, 9 Nov 2012 18:16:20 +0800 (CST) Received: from MBS-HQ1.dlink.com.tw ([fe80::d145:65e8:91b9:88a0]) by HCB-HUB2.dlink.com.tw ([::1]) with mapi id 14.01.0289.001; Fri, 9 Nov 2012 18:16:27 +0800 From: Hans Liu To: Mattia Rossi Thread-Topic: [homenet] regarding recursive DHCPv6-PD (and architecture document) Thread-Index: AQHNvewmJ4GI6LN7lka2BCKZbBFa+ZfgpA2AgACmpzg= Date: Fri, 9 Nov 2012 10:16:25 +0000 Message-ID: <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> , <509CBCAD.5010503@gmail.com> In-Reply-To: <509CBCAD.5010503@gmail.com> Accept-Language: zh-TW, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 10:16:34 -0000 Sent from Hans' iPad2 On Nov 9, 2012, at 4:20 PM, "Mattia Rossi" wrote: > Am 08.11.2012 21:03, schrieb Hans Liu: >> On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis w= rote: >>> On 8 Nov 2012, at 14:28, Ted Lemon wrote: >>>> Sure, but "log a system management error" is not something that a home= router vendor can meaningfully implement, unless it puts a speaker in the = home router and has it start bellowing "out of addresses" in every known la= nguage. >>>>=20 >>>> But the real problem is that this signal, even if received, will be mi= sinterpreted as "router is broken, return to Home Despot and replace with o= ne that isn't broken." >>> >>>=20 >>> I note that the Apple Airport Utility pops up warnings about various er= rors, some of which relate to sub-optimal network configuration, rather tha= n misconfiguration. In particular, they warn you if you try to use double = NAT. >>>=20 >>> Users can acknowledge those warnings, so they no longer appear. >>>=20 >>> I can envisage a box issuing a similar warning if it only gets a /64 fr= om its upstream. >> As a CPE vendor, I don't think I'd design my product this way. I won't >> have my router to issue a warning if it only gets a /64 from its >> upstream. The reason? Users see a warning in either log or LED, they >> call either the operator or my customer service. I really don't want >> to say so but the one that will face a problem is the downstream >> router, and that's not my problem. > Your CPE router could be the downstream router. The user buys it, plugs i= t in, doesn't work. No warning, nothing. > He throws it out, even if it's not your fault, and never buys anything fr= om your company again. > How's that for a scenario? If I'm the downstream router, I can't get a prefix, of course I issue warni= ng message. However, if I'm the one who still get an /64 and works fine as = a leaf, I won't issue an warning message for a fore-coming downstream route= r attached to me. >=20 > Mat > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Fri Nov 9 04:37:29 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DFB21F8640 for ; Fri, 9 Nov 2012 04:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVlYv2Ejovuv for ; Fri, 9 Nov 2012 04:37:29 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DECAC21F862B for ; Fri, 9 Nov 2012 04:37:28 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so804318yhq.31 for ; Fri, 09 Nov 2012 04:37:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jTSF77oWCJ9JkaSSwbtwbzmmIuIJtnLpdAZWI4FmwEY=; b=HHpVJxCDH9BaVUKTkAzhduHPtlJuXt2dgAHjWnXs04583Eo9AZVrRDqaLoV031LMm1 VPyBpi7t6tjHFWwkCmwJhBwowVqPR+3m/Cyo0UWi4v8b1V3FMXuNN+bWWBCLwTRgYZay 6ysmMTfK2GcztT1ZNSs+vC4U3gWiHw44xSRNzitk7fAHyvKbC/MJ7tRL6J1EXHAOALhD AoH4q/e7demxDk/EMlnLkapY8F+VQKxVp+GK64J6CTa1m8ngPejtXas6yTqgfclgkd0H 0Aix+rotCREVcD9ECZWz/CZNSDd7KR0h3JOKMBpNs5RbzYZe3OIKH4p/W0CpP0418T2P u8EQ== Received: by 10.236.126.196 with SMTP id b44mr11723103yhi.21.1352464647871; Fri, 09 Nov 2012 04:37:27 -0800 (PST) Received: from [10.71.11.63] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id m26sm29699004yhc.17.2012.11.09.04.37.26 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 04:37:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <509CB822.50209@gmail.com> Date: Fri, 9 Nov 2012 13:37:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <15116.1352401462@sandelman.ca> <509CB822.50209@gmail.com> To: Mattia Rossi X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQn5UrRHvVjQiMwFNxnhehAeRnv8qT3TLnDU3X8aZ3G/+SArP+yyqZ5wPpOe/AatqjtwdSFI Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:37:29 -0000 Op 9 nov. 2012, om 09:00 heeft Mattia Rossi het volgende geschreven: > Am 08.11.2012 20:04, schrieb Michael Richardson: >>>>>>> "Mattia" =3D=3D Mattia Rossi = writes: >> >> In a lot of these conversations, the "lightswitch guys" (as >> >> someone called the LLN proponents) seem to get forgotten. >>=20 >> Mattia> So what happens if the "lightswitch guys" want to plug-in = a >> Mattia> router, which they have to, as they can't bridge, but >> Mattia> there's only one exit router from one ISP which is = managed >> Mattia> and gets a /64 only? SLAAC relay? I think in this case a >> Mattia> /64 is simply not acceptable. >>=20 >> The lights work in the home (because routing of ULA works fine) >> Possibly, you can't control them from outside the home. So, ISP that >> gives out /56 has an obvious way to demonstrate why they suck less = than >> /64-only ISP. > This is exactly the message that should be conveyed by the draft >>=20 >> It is not clear that all LLNs will even want globally routable = address >> space. Some will. Some won't know what to do with it. > I agree on that. That's why I took the case where they want globally = routable addresses to remote control each single light (or sensor - = which might sound more plausible to some folks). If the lights just need = to communicate within the homenet, ULA's do the job. And as you say, = they might even be the better solution. I expect a controller, with global address. This enables control from = outside.=20 Other solution: VPN for back to my home. Teco >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Fri Nov 9 05:54:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4BD21F866E for ; Fri, 9 Nov 2012 05:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9ZRXMWtnthV for ; Fri, 9 Nov 2012 05:54:50 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB6921F866C for ; Fri, 9 Nov 2012 05:54:49 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so3013618pad.31 for ; Fri, 09 Nov 2012 05:54:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Cy/sDX19lYH+RSJFEiYQ06ykbAlIuAjWR5VziQkog+4=; b=E13rnGTDk4JgjU2FAxiIN6zn++CZvRifnxWw33VN/3E9okGQJQmvEZmgd4tb8y2vpX zlXHOPEWjowWGHtDsRgdSfpO8m9WB3fDlYPMKkpVSMQOmvRlDTOSIK/adkQsMDBD/seP VA7qR/xulJkgkNKIt5Yvdy5N2/TGA3Yr7/UC865xWSHf+Mtj4VpyCdoz15kA5mvGrxCQ y8ZPhVEXVH0u9qFrHFPK9/tZNo3yAN72pOI9I4nTJNh/j9ERR5VDqw1VUdect73PIC1Q KEZPzRSTdOk/3oeBcNVtddrxBKdZ82mem4ETXSWTUTlEcQhUqSjNQ6kHDwsESuCD7/8O TyEQ== Received: by 10.66.73.230 with SMTP id o6mr31923430pav.45.1352469282035; Fri, 09 Nov 2012 05:54:42 -0800 (PST) Received: from dhcp-1616.meeting.ietf.org (dhcp-1616.meeting.ietf.org. [130.129.22.22]) by mx.google.com with ESMTPS id a4sm17997147pax.12.2012.11.09.05.54.40 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 05:54:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4701973A@EUSAAMB101.ericsson.se> Date: Fri, 9 Nov 2012 14:49:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97D832B5-39C8-4BAE-8996-A449BCB4C49B@inf-net.nl> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE4701973A@EUSAAMB101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkEhWpstjpphSk4kD+A4FMyLjEo84F5Xb6fw5Os4X8nlWtTiatlwoqacsGgefhInQVOrGy+ Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:54:51 -0000 So this disqualifies OSPFv3 with DR? Support for wireless is=20 a main reason to route in the homenet. This brings us to P2MP=20 or in the MANET arena. There is a lot of code out there gathering link metrics for dynamic links. MANET wg is working on a std track protocol for=20 it, called DLEP. This is for transfer of data between radio=20 and router devices. MANET protocols support link metrics quite well now. OLSRv2 is=20 near to std track RFC. Teco Op 8 nov. 2012, om 20:26 heeft Acee Lindem het volgende geschreven: > You'd have to do this through manual configuration.=20 > Thanks, > Acee > On Nov 8, 2012, at 2:08 PM, Teco Boot wrote: >=20 >>=20 >> Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >>>=20 >>> I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >>=20 >> Then, we cannot have costs per neighbor, correct? >> By experience I've became aware this is a bad idea on wireless = networks, like WiFi. >> What options do we have to fix this? >>=20 >> Teco >>=20 >>=20 >=20 From acee.lindem@ericsson.com Fri Nov 9 06:10:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5F721F86C5 for ; Fri, 9 Nov 2012 06:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PliLYw7IcW3 for ; Fri, 9 Nov 2012 06:10:20 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3983021F8671 for ; Fri, 9 Nov 2012 06:10:20 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA9EFihw025177; Fri, 9 Nov 2012 08:15:45 -0600 Received: from EUSAAHC004.ericsson.se (147.117.188.84) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 9 Nov 2012 09:10:13 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 09:10:12 -0500 From: Acee Lindem To: Teco Boot Thread-Topic: [homenet] OSPFv3 timers Thread-Index: AQHNvWgxke9hRLx+j0u6WnNdeH5Ji5fgO/AAgABl6YCAAAUngIABNB8AgAAFvoA= Date: Fri, 9 Nov 2012 14:10:12 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47019CB3@EUSAAMB101.ericsson.se> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE4701973A@EUSAAMB101.ericsson.se> <97D832B5-39C8-4BAE-8996-A449BCB4C49B@inf-net.nl> In-Reply-To: <97D832B5-39C8-4BAE-8996-A449BCB4C49B@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-100-500856967"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:10:21 -0000 --Apple-Mail-100-500856967 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Home Wireless Routing !=3D MANET=20 Acee=20 On Nov 9, 2012, at 8:49 AM, Teco Boot wrote: > So this disqualifies OSPFv3 with DR? Support for wireless is=20 > a main reason to route in the homenet. This brings us to P2MP=20 > or in the MANET arena. >=20 > There is a lot of code out there gathering link metrics for > dynamic links. MANET wg is working on a std track protocol for=20 > it, called DLEP. This is for transfer of data between radio=20 > and router devices. >=20 > MANET protocols support link metrics quite well now. OLSRv2 is=20 > near to std track RFC. >=20 > Teco >=20 > Op 8 nov. 2012, om 20:26 heeft Acee Lindem het volgende geschreven: >=20 >> You'd have to do this through manual configuration.=20 >> Thanks, >> Acee >> On Nov 8, 2012, at 2:08 PM, Teco Boot wrote: >>=20 >>>=20 >>> Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >>>>=20 >>>> I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >>>=20 >>> Then, we cannot have costs per neighbor, correct? >>> By experience I've became aware this is a bad idea on wireless = networks, like WiFi. >>> What options do we have to fix this? >>>=20 >>> Teco >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-100-500856967 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwOTE0MTAxMlowIwYJKoZI hvcNAQkEMRYEFIbtgIbeKVpY/FfDDz37bxnga1X3MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgA0mms87bTVsL9DwatcC7gpRSjRSFmLHY/XCdnnRZIynUs54XUOqPYptee094bOC aR3aSBQ9h46YOxpsP0qMYUWzWavzP4GcwwKZkSECgw5s+X38n23JcpQulnYlSEuTYhSj2h0q7DjA d0L2bIV4pHDnLmFGkjflXxk4rziHqdVMAAAAAAAA --Apple-Mail-100-500856967-- From teco@inf-net.nl Fri Nov 9 07:05:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB93B21F886D for ; Fri, 9 Nov 2012 07:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxd+WiInFEJa for ; Fri, 9 Nov 2012 07:05:42 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 502B121F886B for ; Fri, 9 Nov 2012 07:05:41 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3087579pbb.31 for ; Fri, 09 Nov 2012 07:05:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8Ko2ygJUCX3skkWBsybaG12nZBsYNvM7iyq6TKlICTY=; b=ITjfSkm2mw0AaSnboG0BEMP3TNRR6PvDKzheiJa9wXKt8iSW5r+rrGqCZVgV+u3Prz Qt/AAE5phuAR6GKO9KAW/aJewnuXY2Gd8TsL57edd6vf7emM9RyDtjT/JllOumNDTVYS XZYu+IoVX7EQvyetL0Id1pR28w3Dt/OpgoW/S8FKjxog9rAbOTZ6C3NaqerLznei+KnG BPfRBW+K2pkYme1pk6K3qu5yiboSYuhX0Ia8/s1iaOwM02aPQ9Xpyw1HwCUXocOjhjB4 IvUAG6xgVYBgesGfoLzleP6IhwashwwdboRn3QfIrmZLf/8jGwTHXdf9kMthsvk2V74/ Sn/Q== Received: by 10.68.191.200 with SMTP id ha8mr34278418pbc.51.1352473536680; Fri, 09 Nov 2012 07:05:36 -0800 (PST) Received: from ?IPv6:2001:df8::16:b168:d230:a7f4:f3a9? ([2001:df8:0:16:b168:d230:a7f4:f3a9]) by mx.google.com with ESMTPS id gv9sm17852095pbc.21.2012.11.09.07.05.35 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 07:05:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47019CB3@EUSAAMB101.ericsson.se> Date: Fri, 9 Nov 2012 16:05:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D0A69B2-C841-4E5E-8830-D70227BE9EA2@inf-net.nl> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE4701973A@EUSAAMB101.ericsson.se> <97D832B5-39C8-4BAE-8996-A449BCB4C49B@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE47019CB3@EUSAAMB101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQktdEWlAulfpuh20nktYSYE/vMSdNb3bi8Zo0CYsPHz8a9ZKRqk1t0rdSCsu/c+yAVkJX/w Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:05:42 -0000 Yes, it is More Adhoc NETwork and called Homenet. You could be surprised = how well MANET protocols work in homenets. This is not my point. Wireless links need per neighbor link costs, a requirement for the = Homenet routing protocol: The inclusion of the PHY layer characteristics including bandwidth, loss, and latency in path computation should be considered for optimising communication in the homenet. Can be done with OSPFv3, so use it. Please suggest how to deal with it. Teco Op 9 nov. 2012, om 15:10 heeft Acee Lindem het volgende geschreven: > Home Wireless Routing !=3D MANET=20 >=20 > Acee=20 >=20 > On Nov 9, 2012, at 8:49 AM, Teco Boot wrote: >=20 >> So this disqualifies OSPFv3 with DR? Support for wireless is=20 >> a main reason to route in the homenet. This brings us to P2MP=20 >> or in the MANET arena. >>=20 >> There is a lot of code out there gathering link metrics for >> dynamic links. MANET wg is working on a std track protocol for=20 >> it, called DLEP. This is for transfer of data between radio=20 >> and router devices. >>=20 >> MANET protocols support link metrics quite well now. OLSRv2 is=20 >> near to std track RFC. >>=20 >> Teco >>=20 >> Op 8 nov. 2012, om 20:26 heeft Acee Lindem het volgende geschreven: >>=20 >>> You'd have to do this through manual configuration.=20 >>> Thanks, >>> Acee >>> On Nov 8, 2012, at 2:08 PM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >>>>>=20 >>>>> I'd expect homenet ethernet and WiFi interfaces to default to the = broadcast type.=20 >>>>=20 >>>> Then, we cannot have costs per neighbor, correct? >>>> By experience I've became aware this is a bad idea on wireless = networks, like WiFi. >>>> What options do we have to fix this? >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From dave.taht@gmail.com Fri Nov 9 07:47:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E2C21F8682 for ; Fri, 9 Nov 2012 07:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks0U0dek9sn6 for ; Fri, 9 Nov 2012 07:47:43 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A33B21F85EA for ; Fri, 9 Nov 2012 07:47:43 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so2569914eek.31 for ; Fri, 09 Nov 2012 07:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=h2CPpbuUTeJ8bImmGbeMFKPeP7sZHp212X6YkvJPgbQ=; b=D7M/fMdOZHHruuRsl8mhoRLrlzmMRqWb8TQoDS2+t5yauRaeAqNHEvBVnZaRM8r+Uc 3NHgN6jAolgc+zJP16P0iH7LvNcvNYh81ttUsHLnRwJaKY4EcTUyMf6m+P1i1w8IwW+j WiGw9NPzXxtScbAe/JOS0lCIK04FXAoLF1YWtfi8LwMzpRhqDyoJIdZAIhaE6AoUn8Tp FtB84vie+DdElozhZFcE4tr2DEDR7SHzUjRj9OvKEwJ3+RujzntX68yoQ6HBsbFGjniY 1FEd5VRrVTNt3Uye9edj6uDDYY1HG4YZ3RogSfHFa62YmvlhCBCMngqnqMH2Dw772Cjy 92Ug== MIME-Version: 1.0 Received: by 10.14.182.5 with SMTP id n5mr38725000eem.5.1352476062475; Fri, 09 Nov 2012 07:47:42 -0800 (PST) Received: by 10.223.180.10 with HTTP; Fri, 9 Nov 2012 07:47:42 -0800 (PST) In-Reply-To: <0D0A69B2-C841-4E5E-8830-D70227BE9EA2@inf-net.nl> References: <98BF7014-399D-405A-AE44-CD7C49B44F94@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE4701807C@EUSAAMB101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE4701973A@EUSAAMB101.ericsson.se> <97D832B5-39C8-4BAE-8996-A449BCB4C49B@inf-net.nl> <94A203EA12AECE4BA92D42DBFFE0AE47019CB3@EUSAAMB101.ericsson.se> <0D0A69B2-C841-4E5E-8830-D70227BE9EA2@inf-net.nl> Date: Fri, 9 Nov 2012 16:47:42 +0100 Message-ID: From: Dave Taht To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Acee Lindem , "homenet@ietf.org Group" Subject: Re: [homenet] OSPFv3 timers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:47:46 -0000 On Fri, Nov 9, 2012 at 4:05 PM, Teco Boot wrote: > Yes, it is More Adhoc NETwork and called Homenet. You could be surprised = how well MANET protocols work in homenets. This is not my point. > > Wireless links need per neighbor link costs, a requirement for the Homene= t routing protocol: > The inclusion of the PHY layer > characteristics including bandwidth, loss, and latency in path > computation should be considered for optimising communication in the > homenet. > Can be done with OSPFv3, so use it. Please suggest how to deal with it. Can be done with olsr, babel, 802.11s, batman, and BMX. There is a large amount of operational data in the field regarding doing routing well on wireless networks, and a regular conference dedicated to exploring how well they actually work in the real world. http://guifi.net/en/node/17714/view/map please pack up your favorite ospfv3 and manet extensions and wifi hardware and go to one. http://battlemesh.org/ None of the metrics work particularly well, and are functioning badly in our increasingly bufferbloated universe. > > Teco > > Op 9 nov. 2012, om 15:10 heeft Acee Lindem het volgende geschreven: > >> Home Wireless Routing !=3D MANET >> >> Acee >> >> On Nov 9, 2012, at 8:49 AM, Teco Boot wrote: >> >>> So this disqualifies OSPFv3 with DR? Support for wireless is >>> a main reason to route in the homenet. This brings us to P2MP >>> or in the MANET arena. >>> >>> There is a lot of code out there gathering link metrics for >>> dynamic links. MANET wg is working on a std track protocol for >>> it, called DLEP. This is for transfer of data between radio >>> and router devices. >>> >>> MANET protocols support link metrics quite well now. OLSRv2 is >>> near to std track RFC. >>> >>> Teco >>> >>> Op 8 nov. 2012, om 20:26 heeft Acee Lindem het volgende geschreven: >>> >>>> You'd have to do this through manual configuration. >>>> Thanks, >>>> Acee >>>> On Nov 8, 2012, at 2:08 PM, Teco Boot wrote: >>>> >>>>> >>>>> Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven: >>>>>> >>>>>> I'd expect homenet ethernet and WiFi interfaces to default to the br= oadcast type. >>>>> >>>>> Then, we cannot have costs per neighbor, correct? >>>>> By experience I've became aware this is a bad idea on wireless networ= ks, like WiFi. >>>>> What options do we have to fix this? >>>>> >>>>> Teco >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From mike@mtcc.com Fri Nov 9 08:48:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7209821F8516 for ; Fri, 9 Nov 2012 08:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2kicMuodATp for ; Fri, 9 Nov 2012 08:48:32 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4921F84DC for ; Fri, 9 Nov 2012 08:48:31 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id qA9GmUF6024288 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 08:48:30 -0800 Message-ID: <509D33DE.7020002@mtcc.com> Date: Fri, 09 Nov 2012 08:48:30 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <14721.1352401138@sandelman.ca> In-Reply-To: <14721.1352401138@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=314; t=1352479710; x=1353343710; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20regarding=20recursive=20DHC Pv6-PD=20(and=20architecture=20document) |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=LJvegefdscJokDLPCBYR/jN1/MGQGPEBjclQmG2Or+M=; b=tyngQ+8G8b7gKlbd5MNU4y0AYkMuqRGvbJ5RSXyzXDzzi1tJXWzYZwoJbp otXwIdof2dX8Rgzn+mo9E2wc50GxaiK4qTyUbgGaOH+l0lRnJA+g9ESgrUSf RA63a7cp2SdtirZxB26l6To7na2ERGvHNANZHXc/UWEcCW/D1/o1g=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:48:39 -0000 On 11/08/2012 10:58 AM, Michael Richardson wrote: > An ISP that gives out a single /64 is broken. As long as we have a way > to indicate "out of /64s" (because that could happen, even if you are > given a /48, and have some pathology...), then we are good. Does that apply to my Android phone too? Mike From mcr@sandelman.ca Fri Nov 9 11:54:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2CE21F8680 for ; Fri, 9 Nov 2012 11:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAFXsXsvvCHq for ; Fri, 9 Nov 2012 11:54:36 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBB421F8675 for ; Fri, 9 Nov 2012 11:54:36 -0800 (PST) Received: from sandelman.ca (unknown [199.108.69.151]) by relay.sandelman.ca (Postfix) with ESMTPS id 7515D81AE for ; Fri, 9 Nov 2012 14:46:23 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69326CA0BC for ; Fri, 9 Nov 2012 14:54:34 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org Group" In-reply-to: References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> Comments: In-reply-to Ray Bellis message dated "Thu, 08 Nov 2012 19:40:17 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 09 Nov 2012 14:54:34 -0500 Message-ID: <20494.1352490874@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:54:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable > I note that the Apple Airport Utility pops up warnings about various > errors, some of which relate to sub-optimal network configuration, > rather than misconfiguration. In particular, they warn you if you try > to use double NAT.=20 it seems to me that we ought to ask Apple^WStuart how these warnings are communicated from AirPort to laptop, and ask them if they would like to contribute a document to homenet to standardized such a protocol. (are they in DHCP? RAs? mDNS? something weirder?) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnV96AAoJEKD0KQ7Gj3P2wKgH/1GHMnGdFM5nhAh+DeTNdFVW pgfEGldLIIRpXj8JhTsLzevDhaahbipQiZRXWsUouwhDY/x8iiBF9O7UVTo31QnL UaCdWFaksZS49ReaAd/FW9oSzkyrXW7W6XBkcX6o0I5u/3ynI2z8WFqfvfV7QnTO nvUctLJysy1W6r8wpVCcLs0qogCJgLBmIwIYe9Se1c++e7U9eADzGA2yGEAmiuga Zw70xJO1FTGCwkVoE+Y1ompP3Ya6TLWptP67NYEJBMSxvx4TYtr755eQD1Ri3r5O zTy8DUQ+KiYOYAxM500aEfxyrjtl/j7qkwwXkXutUa1458qilZMGQy5R/Gi9sno= =p0c0 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 9 11:56:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725C821F8680 for ; Fri, 9 Nov 2012 11:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-Qb3bG5ZNV3 for ; Fri, 9 Nov 2012 11:56:38 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 18BF921F85F0 for ; Fri, 9 Nov 2012 11:56:38 -0800 (PST) Received: from sandelman.ca (unknown [199.108.69.151]) by relay.sandelman.ca (Postfix) with ESMTPS id 32F6381AA for ; Fri, 9 Nov 2012 14:48:26 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 26EADCA0BC for ; Fri, 9 Nov 2012 14:56:37 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-reply-to: References: <509BD51D.1090101@gmail.com> Comments: In-reply-to Andrew McGregor message dated "Thu, 08 Nov 2012 15:21:08 -0500." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 09 Nov 2012 14:56:37 -0500 Message-ID: <20603.1352490997@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:56:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Andrew" =3D=3D Andrew McGregor writes: Andrew> This whole thread is making me think that specifying that we Andrew> use either babel (with attention to getting it documented Andrew> properly) or one of the OSPFv4 MANET extensions, in the case Andrew> where we have only a /64 and perhaps any time we find we Andrew> have an 802.11s, ad-hoc or NBMA interface in play. That way Andrew> we introduce /128 routes, and everything continues to work. so, great maybe, except that now either: 1) hosts have to participate in the routing protocol. (so impact on hosts) 2) we have to deploy proxy-ND. (and that's why RPL isn't on the table at homenet) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnV/0AAoJEKD0KQ7Gj3P2kBcH/38Vk21n09XPnoZNmO/mtMbp ULSbOom4lIar0Ztv7YyB9TCwe5tjdffssePNOmZsBpyz7Gw5J7VNu/pSBVqovACJ vZkN0T/ork5iWdM+s9LspvYbycOe+5WK5zbmPL3vMNsgUkH1Aw14sTFhXRtTqK8c n+80IeA0ZPP9lXaVACA7mxpv3L2z4eGHDel7qtRX1lcDBGU4lFO8jY753Pp47Gpy cMzEabwK5ZGjl0xGmNvfNUfLV++TDzXLeg913spdwO67XtQ+zWbCihi7+msCktBJ HNOypWWn9SU7khsxGB+dbrYBLJjEAyqr+Q8TJ00SR+EsLGPDS7vZe3AWzspUjQw= =h7yj -----END PGP SIGNATURE----- --=-=-=-- From mike@mtcc.com Fri Nov 9 15:03:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB6E21F8206 for ; Fri, 9 Nov 2012 15:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQbINIfRAV9Z for ; Fri, 9 Nov 2012 15:03:20 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC6F21F86FC for ; Fri, 9 Nov 2012 15:03:20 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id qA9N3Hdp025092 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 15:03:18 -0800 Message-ID: <509D8BB5.7000409@mtcc.com> Date: Fri, 09 Nov 2012 15:03:17 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=994; t=1352502199; x=1353366199; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20DHCP=20PD=20for=20homenets. |Sender:=20 |To:=20Mikael=20Abrahamsson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=0N1V9ntMQRPzd9So1xUessjGg4HhVIsrdweKLel6QG4=; b=KUpOQabu5GGPA1uYQFWBU90fSTOvr09YfQ3w9PZSWLEQsZOXWVKQ9lFJyC UF3SoVpVYMF46fSyNYmJPZtVbrh8ANdSeONkr4pn5x1hVJzHYtCiEHroWTMV VN80/PGtVXRe6p8YiYrAsEXgdkAdkbcGZgrV88BInZH7U+L8NpmdU=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "Howard, Lee" , "homenet@ietf.org" Subject: Re: [homenet] DHCP PD for homenets. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:03:21 -0000 On 11/08/2012 07:07 AM, Mikael Abrahamsson wrote: > On Thu, 8 Nov 2012, Howard, Lee wrote: > >>> I think we should aim higher do what's best in the long run, and then CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 more than current generation, initially, but as these requirements spread and more people/ISPs buy, it'll be the new lowest standard and cost will drop. >> >> It's very generous of you to spend other people's money this way. > > What is your suggestion? > > New requirements mean higher spec hw, I don't really see a way around that. Do you? > > For ISPs who want to save those few dollars, they can offer NAT444 and then do not need to require more functionality in their CPEs. In the areas where customers have a choice, let them choose. > Let's not forget that Moore's Law will make all of this rather irrelevant by the time this is rolled out and widespread. We're talking realistically years and years before this is mainstream. Mike From mcr@sandelman.ca Fri Nov 9 15:19:49 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C321F8550 for ; Fri, 9 Nov 2012 15:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv9DKHmYdi32 for ; Fri, 9 Nov 2012 15:19:48 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC5021F86E0 for ; Fri, 9 Nov 2012 15:19:47 -0800 (PST) Received: from sandelman.ca (199-7-156-133.eng.wind.ca [199.7.156.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 5AF8281AA for ; Fri, 9 Nov 2012 18:11:34 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 925A0CA0BC for ; Fri, 9 Nov 2012 18:19:39 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-reply-to: References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <509BB451.3020901@gridmerge.com> <509BB762.8080304@gmail.com> <15116.1352401462@sandelman.ca> <509CB822.50209@gmail.com> Comments: In-reply-to Teco Boot message dated "Fri, 09 Nov 2012 13:37:28 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 09 Nov 2012 18:19:39 -0500 Message-ID: <6918.1352503179@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:19:49 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Teco" =3D=3D Teco Boot writes: Mattia> So what happens if the "lightswitch guys" want to plug-in a Mattia> router, which they have to, as they can't bridge, but Mattia> there's only one exit router from one ISP which is managed Mattia> and gets a /64 only? SLAAC relay? I think in this case a Mattia> /64 is simply not acceptable. >>> The lights work in the home (because routing of ULA works fine) >>> Possibly, you can't control them from outside the home. So, ISP >>> that gives out /56 has an obvious way to demonstrate why they >>> suck less than /64-only ISP. >> This is exactly the message that should be conveyed by the draft >>> It is not clear that all LLNs will even want globally routable >>> address space. Some will. Some won't know what to do with it. >> I agree on that. That's why I took the case where they want >> globally routable addresses to remote control each single light >> (or sensor - which might sound more plausible to some folks). If >> the lights just need to communicate within the homenet, ULA's do >> the job. And as you say, they might even be the better solution. Teco> I expect a controller, with global address. This enables Teco> control from outside. Other solution: VPN for back to my home. In a simple home, the controller is on the one LAN which got the /64, and so that side of it is accessible anyway.=20=20 =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnY+LAAoJEKD0KQ7Gj3P2JbAIAJpMeQrMDAli/BF4yv0aC97f Qg+Wc/SCwHglrCMtItx3YlGGtwfDf0AIl8E9NVS1aulpH/6pq4aYWrBPVMVH0XxE y8iaD076jz8vpYXym9zLVhGkFuoLTNZ42Bc06qT8TKEzY5DC4wk6+sEW+3RGOqeX S0GOEf8qqOoel/s2A3MBNK8f+du+Cm2XQe119BopPtDbeNjkMfaXIYlikwUTc9ob 5mB3HC2c7ipkTBBaPwEUbzgw3tG/dYxjoQmj67P+pQRiuA80/b0OQJg/t2yD4qZu 777gQdoC4eXpXlstFXnEDtUekHpQH8LWPY2aJs547HHVobnuKOh6+p42CVe7xjw= =lmfH -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 9 15:22:02 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5892921F8554 for ; Fri, 9 Nov 2012 15:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7-kh0JY8zns for ; Fri, 9 Nov 2012 15:22:01 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6E521F8550 for ; Fri, 9 Nov 2012 15:22:00 -0800 (PST) Received: from sandelman.ca (199-7-156-133.eng.wind.ca [199.7.156.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 2D18E81AA; Fri, 9 Nov 2012 18:13:47 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C9834CA0BC; Fri, 9 Nov 2012 18:21:54 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org Group" In-reply-to: <509D33DE.7020002@mtcc.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <14721.1352401138@sandelman.ca> <509D33DE.7020002@mtcc.com> Comments: In-reply-to Michael Thomas message dated "Fri, 09 Nov 2012 08:48:30 -0800." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 09 Nov 2012 18:21:54 -0500 Message-ID: <7036.1352503314@sandelman.ca> Sender: mcr@sandelman.ca Cc: Michael Thomas Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:22:02 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Michael" =3D=3D Michael Thomas writes: >> An ISP that gives out a single /64 is broken. As long as we have >> a way to indicate "out of /64s" (because that could happen, even >> if you are given a /48, and have some pathology...), then we are >> good. Michael> Does that apply to my Android phone too? Are you asking if your Android phone, when it gets only /64 from LTE/3G provider, should hand that out, and then indicate "out of /64s"? Yes. The phone has a pretty clear way to indicate this problem to the user. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnZASAAoJEKD0KQ7Gj3P2HAUH/RpWuMOX6jZ7mWFhKRixaEAq tZw5wmiYmj6lpHlJrsdHcp6dZpBjFktdYw+HcP7s/tUkVsWVXxX+Mw52jwrMhaaz 1cQds+O6F0Aqbnib0uA6rMlz3Nz/+LXymYtf/85DkVQoivnHBnSL2QcGcx0HVTqH 4G01t+1fVNPFH3EayR4bL2HIqaPM2PjneQ80oUc6IkBoEfivUsY3xKs/V5zQbY0Y Ve2d/Ab8r8m6rY1Jylxexatiwa1/3j3GqvlWIh71vGVqIpmZSfwtHEyryfBtvpJj sWeH3Uc7qEuf2ZHefYTR2IYjvnBiIuOKjhOIQVfKjc2JQFnZ5BUfMP6YYZlxyko= =hO53 -----END PGP SIGNATURE----- --=-=-=-- From mike@mtcc.com Fri Nov 9 15:30:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98B221F86D5 for ; Fri, 9 Nov 2012 15:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzkBdPaYJyUn for ; Fri, 9 Nov 2012 15:30:42 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6F21F8604 for ; Fri, 9 Nov 2012 15:30:41 -0800 (PST) Received: from sjc-vpn4-614.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id qA9NUeZD001731 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 9 Nov 2012 15:30:41 -0800 Message-ID: <509D921A.6040804@mtcc.com> Date: Fri, 09 Nov 2012 15:30:34 -0800 From: mike User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <14721.1352401138@sandelman.ca> <509D33DE.7020002@mtcc.com> <7036.1352503314@sandelman.ca> In-Reply-To: <7036.1352503314@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=849; t=1352503841; x=1353367841; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20mike=20 |Subject:=20Re=3A=20[homenet]=20regarding=20recursive=20DHC Pv6-PD=20(and=20architecture=20document) |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=7neMLpUdp956eHbAWGzDPe6UgrcxI8aGzjb3SyP8a7w=; b=AGWmYaEtAYlyGg0BaND0EOPUh9DSJrtHtgEhEWFRUYM+NybrNgG//euPOF X+KFROu6PYYsKTWBsh2VaoFiX91Rg0lhgWqSURddGjk8HNoMiJSlb0FFPN/C nE6kKh7ipFhxy5u5ye8/YMrbQmX5L7lpw6z6NcA4KdvUj+wYkOHVM=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:30:43 -0000 On 11/9/12 3:21 PM, Michael Richardson wrote: >>>>>> "Michael" == Michael Thomas writes: > >> An ISP that gives out a single /64 is broken. As long as we have > >> a way to indicate "out of /64s" (because that could happen, even > >> if you are given a /48, and have some pathology...), then we are > >> good. > > Michael> Does that apply to my Android phone too? > > Are you asking if your Android phone, when it gets only /64 from LTE/3G > provider, should hand that out, and then indicate "out of /64s"? Yes. > > The phone has a pretty clear way to indicate this problem to the user. > I'm asking about whether I should expect my android phone to get a /56. My phone is, after all, capable of being a router. I'm somehow guessing that phone isp's aren't giving out /56's though. Mike From robert.cragie@gridmerge.com Fri Nov 9 17:20:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3E621F8606 for ; Fri, 9 Nov 2012 17:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15hCS2UL0BoO for ; Fri, 9 Nov 2012 17:20:11 -0800 (PST) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEE121F85D4 for ; Fri, 9 Nov 2012 17:20:11 -0800 (PST) Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TWzk1-0001d7-7k for homenet@ietf.org; Sat, 10 Nov 2012 01:20:09 +0000 Message-ID: <509DAC0B.9060108@gridmerge.com> Date: Sat, 10 Nov 2012 01:21:15 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <509BD51D.1090101@gmail.com> <20603.1352490997@sandelman.ca> In-Reply-To: <20603.1352490997@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020205070300040207050807" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 01:20:12 -0000 This is a cryptographically signed message in MIME format. --------------ms020205070300040207050807 Content-Type: multipart/alternative; boundary="------------070806030300080302070606" This is a multi-part message in MIME format. --------------070806030300080302070606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 09/11/2012 7:56 PM, Michael Richardson wrote: > (and that's why RPL isn't on the table at homenet) Why not? Again, the sort of networks which would use RPL (LLNs) are = referred to in the charter. > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --------------070806030300080302070606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 09/11/2012 7:56 PM, Michael Richardson wrote:
= 
(and that's why RPL isn't on the table at homenet)
<RCC>Why not? Again, the sort of networks which would use RPL (LLNs) are referred to in the charter.</RCC>


= 




_______________________________________________
homenet mailing list
ho=
menet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--------------070806030300080302070606-- --------------ms020205070300040207050807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMTAwMTIxMTVaMCMGCSqGSIb3DQEJBDEWBBR0A6ae/FOTJY2ZJHSHHqr9WoUjfTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAEmnjVuMbdlzKF554ilbS0DCW5oTzNx4duXFTbqRbgj+0NsO SSfgGAjS0KxVMlAuAuNDHR6fpO/XzYcB+Ew2twC5xpALZqcOprpcPdNdDsJj3crT7UWv8638 uWjFRcm9Zc+aaMZmKLOcJgmIC+CxMojKzno9wKnI5hGTaEvX3O7Liu3+GjXejMw13I9z/Bb3 TA5gywkyscLMhem1zbMj8ugD8YeuFMqPKoToxycVgoUluuRJ9tZt0X3fdxZbQj/4Qgy6rEOf bC+/5NUFFXBIk37TMADOKc8NoaevkqQ6FBHWiS1S9gzDvF/5TG6/jZOwehRTHG6GL5TLKA2f FPu69NAAAAAAAAA= --------------ms020205070300040207050807-- From cb.list6@gmail.com Sat Nov 10 06:20:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC88A21F8660 for ; Sat, 10 Nov 2012 06:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBkqdGG7Tkyj for ; Sat, 10 Nov 2012 06:20:33 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75C0B21F863B for ; Sat, 10 Nov 2012 06:20:32 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so376156lbk.31 for ; Sat, 10 Nov 2012 06:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tPGMqp2kmcwnTg3h9LyU6hh8QzMGqSoWGRHDaf1+awo=; b=oGQfr3hIQc7S5hPoKtmAMUsTExhQwyJxbpjgzM0LgFYmUrm7w7KR1gweIt0v5K5zBf Pukh1/jtYv2bhoM7FdX2IGxSB+ddJtneBF2hod5qYgomef3Jyn5C6/tdoj+07M87TwaB YfKMQJ9zt37jLh0V08Yu9HOZkITtEIMbfkm3a6Vlii+hjvi5Qi9YbO/YwrF695ufqaG1 IbkzO82/sCkYhTwPN3iTxVFEHptmOVYqV7BH8M3DBmBly1rydt3HB1vslS1FLcj4piBq N8n6shbNE0XW59Hw+lTB0JKmYp+x2RPyqJnSDJAZigfS5eXbpymiFWyBvpHznaOWRjod fVcg== MIME-Version: 1.0 Received: by 10.152.109.145 with SMTP id hs17mr13611091lab.5.1352557231302; Sat, 10 Nov 2012 06:20:31 -0800 (PST) Received: by 10.112.81.167 with HTTP; Sat, 10 Nov 2012 06:20:31 -0800 (PST) Received: by 10.112.81.167 with HTTP; Sat, 10 Nov 2012 06:20:31 -0800 (PST) In-Reply-To: <509D921A.6040804@mtcc.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <14721.1352401138@sandelman.ca> <509D33DE.7020002@mtcc.com> <7036.1352503314@sandelman.ca> <509D921A.6040804@mtcc.com> Date: Sat, 10 Nov 2012 06:20:31 -0800 Message-ID: From: Cameron Byrne To: mike Content-Type: multipart/alternative; boundary=bcaec54ee77c4f68e104ce24c55f Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 14:20:35 -0000 --bcaec54ee77c4f68e104ce24c55f Content-Type: text/plain; charset=ISO-8859-1 On Nov 9, 2012 3:30 PM, "mike" wrote: > > On 11/9/12 3:21 PM, Michael Richardson wrote: >>>>>>> >>>>>>> "Michael" == Michael Thomas writes: >> >> >> An ISP that gives out a single /64 is broken. As long as we have >> >> a way to indicate "out of /64s" (because that could happen, even >> >> if you are given a /48, and have some pathology...), then we are >> >> good. >> >> Michael> Does that apply to my Android phone too? >> >> Are you asking if your Android phone, when it gets only /64 from LTE/3G >> provider, should hand that out, and then indicate "out of /64s"? Yes. >> >> The phone has a pretty clear way to indicate this problem to the user. >> > I'm asking about whether I should expect my android phone to get a /56. > My phone is, after all, capable of being a router. I'm somehow guessing that > phone isp's aren't giving out /56's though. > > > Mike > This case is looked at in v6ops http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 The simple answer is that there is a deployment lag issue. Neither Android nor the mobile networks support PD today. But they can and will support pd in time. CB _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --bcaec54ee77c4f68e104ce24c55f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 9, 2012 3:30 PM, "mike" <mike@mtcc.com> wrote:
>
> On 11/9/12 3:21 PM, Michael Richardson wrote:
>>>>>>>
>>>>>>> "Michael" =3D=3D Michael Thomas <= mike@mtcc.com> writes:
>>
>> =A0 =A0 =A0>> An ISP that gives out a single /64 is broken. = =A0As long as we have
>> =A0 =A0 =A0>> a way to indicate "out of /64s" (bec= ause that could happen, even
>> =A0 =A0 =A0>> if you are given a /48, and have some patholog= y...), then we are
>> =A0 =A0 =A0>> good.
>>
>> =A0 =A0 =A0Michael> Does that apply to my Android phone too? >>
>> Are you asking if your Android phone, when it gets only /64 from L= TE/3G
>> provider, should hand that out, and then indicate "out of /64= s"? Yes.
>>
>> The phone has a pretty clear way to indicate this problem to the u= ser.
>>
> I'm asking about whether I should expect my android phone to get a= /56.
> My phone is, after all, capable of being a router. I'm somehow gue= ssing that
> phone isp's aren't giving out /56's though.
>
>
> Mike
>

This case is looked at in v6ops http://tools.ietf.org/html/draft-by= rne-v6ops-64share-03

The simple answer is that there is a deployment lag issue. N= either Android nor the mobile networks support PD today. But they can and w= ill support pd in time.

CB
_______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--bcaec54ee77c4f68e104ce24c55f-- From andrewmcgr@gmail.com Sat Nov 10 06:53:07 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CF421F84C4 for ; Sat, 10 Nov 2012 06:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHHDQCH0nOOR for ; Sat, 10 Nov 2012 06:53:06 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98A2121F8462 for ; Sat, 10 Nov 2012 06:53:06 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id l13so979295yen.31 for ; Sat, 10 Nov 2012 06:53:06 -0800 (PST) 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:x-mailer; bh=XNsj7FOO8TTaqNKdXBuAsLadbWUtjsOcRQJbyCPxeEg=; b=aG68rl0r6s7UB8fN7AdnmI9rsHQXYBOZ+1z/8+jHo4uc12ZhMAqj0GsRyo5HP8HtK6 oZL+aCU4EfvIVQIcw8UwpgfqZT7OZXhpMGzlv/oD4EsCADmb2pWRILgjpMnd7T9RGLDS OH7s2tnpLKUbtmiPrKs5JPqUZ8y4GnPpMjrlvKkTv3tOHjZmGui1OIaXjlAYSPHZyC2/ hBECBBxqlJhxFGMRf1lSgJzEG2exydjeQt8cod+JYDruln4o7CHKASBenkMESUgx8k8P /BQDarhee/MgajL52zOyjnjCHEMfhCo7OB17SvA+cvH9KGiy1wPxPqxyrvFXEwVN2Ii4 0C5A== Received: by 10.101.142.34 with SMTP id u34mr4217003ann.7.1352559186126; Sat, 10 Nov 2012 06:53:06 -0800 (PST) Received: from dhcp107-17-123-17.hil-atlahhh.atl.wayport.net (dhcp107-17-123-17.hil-atlahhh.atl.wayport.net. [107.17.123.17]) by mx.google.com with ESMTPS id o66sm1537716yhi.19.2012.11.10.06.53.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Nov 2012 06:53:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <20603.1352490997@sandelman.ca> Date: Sat, 10 Nov 2012 09:52:59 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <509BD51D.1090101@gmail.com> <20603.1352490997@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 14:53:07 -0000 Proxy-ND doesn't seem hard... much less evil than NAT, after all. Andrew On 9/11/2012, at 2:56 PM, Michael Richardson wrote: > >>>>>> "Andrew" == Andrew McGregor writes: > Andrew> This whole thread is making me think that specifying that we > Andrew> use either babel (with attention to getting it documented > Andrew> properly) or one of the OSPFv4 MANET extensions, in the case > Andrew> where we have only a /64 and perhaps any time we find we > Andrew> have an 802.11s, ad-hoc or NBMA interface in play. That way > Andrew> we introduce /128 routes, and everything continues to work. > > so, great maybe, except that now either: > 1) hosts have to participate in the routing protocol. (so impact on > hosts) > > 2) we have to deploy proxy-ND. > > (and that's why RPL isn't on the table at homenet) > > -- > Michael Richardson > -on the road- > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Sat Nov 10 07:04:02 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1221F85F3 for ; Sat, 10 Nov 2012 07:04:02 -0800 (PST) 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=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14wMPZRfz87E for ; Sat, 10 Nov 2012 07:03:58 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id AF83221F8488 for ; Sat, 10 Nov 2012 07:03:58 -0800 (PST) Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id qAAF3tEs019436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Nov 2012 07:03:56 -0800 Message-ID: <509E6CD7.5030601@mtcc.com> Date: Sat, 10 Nov 2012 07:03:51 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Cameron Byrne References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <14721.1352401138@sandelman.ca> <509D33DE.7020002@mtcc.com> <7036.1352503314@sandelman.ca> <509D921A.6040804@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=828; t=1352559836; x=1353423836; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20regarding=20recursive=20DHC Pv6-PD=20(and=20architecture=09document) |Sender:=20 |To:=20Cameron=20Byrne=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=nlsVWDINkkbNvpkBhovCOLcwXOKfk4dE+XMFgCSwKVg=; b=NBlq0aHuVw3ITvN7IxH8b5E+wv2UN4ApCSPZYus+wpX4ztor15Jn9DkX26 Fss0hlVYGlqBhDnTRHG1zT1AzeKtY7jhXu2UT/Fp7bTO6Wp83V6uFwY2dhf3 +LQ4P3sH7LuCrOTbSNb0Rxf/vbaZ45L/4zlSX5spFkJIjv1wEIP7I=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 15:04:02 -0000 Cameron Byrne wrote: > > On Nov 9, 2012 3:30 PM, "mike" > wrote: > > This case is looked at in v6ops > http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 > > The simple answer is that there is a deployment lag issue. Neither > Android nor the mobile networks support PD today. But they can and will > support pd in time. I expect that there well may be resistance as wireline-ISP's have come to expect that there's a "router" in home. I very much doubt they view phones as anything other than hosts except when they can charge outrageous fees for "tethering". Which sort of brings up the obvious question: if ISP's don't cooperate, what will people do to route around the damage, especially in the face of all the unused space of a /64 they can poach. Mike From teco@inf-net.nl Sat Nov 10 07:26:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0088F21F8660 for ; Sat, 10 Nov 2012 07:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A21tdnxJ4Jot for ; Sat, 10 Nov 2012 07:26:10 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 068AB21F86A0 for ; Sat, 10 Nov 2012 07:26:09 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jg9so498175bkc.31 for ; Sat, 10 Nov 2012 07:26:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=XKD6N51YS3l/s2sP9U1t83UbFjpqLx2gmgsjeBKKEOw=; b=oczRKL8AdKOz185Vsv5/SdF4r4lPnjxK8WGkBN/XbflackMEGZu8JIehKpU2kZRsHN h0m1sBpzVYp8D8cHGfpkpd35vC2osev0owvKOlNaSnNUTanohJ13nH7IVpluQsQURMQj zWaCtq5Sn4THtRLJZwD1EbJGtfGUadXIJk+ZRIQvnlp6P43KVDxyolhtbgO89lfxErsK onaxz69l7Qt8qEpsCkwJKu9a1s6I81zwzitGeSc1YPN9+zX/Y+L1LXlkfJnRV29SGhoe yFT0SlvcYfyC5ftKHY5+TmLYivudRIefigdofGbrd89g0y87l8sF0KlSH/VIlyi1apLz a58Q== Received: by 10.204.9.3 with SMTP id j3mr5205535bkj.15.1352561168901; Sat, 10 Nov 2012 07:26:08 -0800 (PST) Received: from [10.87.147.120] ([80.187.201.44]) by mx.google.com with ESMTPS id gz6sm284295bkc.16.2012.11.10.07.26.06 (version=SSLv3 cipher=OTHER); Sat, 10 Nov 2012 07:26:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <509D921A.6040804@mtcc.com> Date: Sat, 10 Nov 2012 16:26:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62215C3F-976C-4090-A2B5-D86682392472@inf-net.nl> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <14721.1352401138@sandelman.ca> <509D33DE.7020002@mtcc.com> <7036.1352503314@sandelman.ca> <509D921A.6040804@mtcc.com> To: mike X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl8End22FeWogZ1iM2YZZ1VByhDhQlrmTr8dAyM3/bEUiJVG9cgRgGH0IK+N7kZKk47Yztw Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 15:26:11 -0000 Op 10 nov. 2012, om 00:30 heeft mike het volgende geschreven: > On 11/9/12 3:21 PM, Michael Richardson wrote: >>>>>>> "Michael" =3D=3D Michael Thomas writes: >> >> An ISP that gives out a single /64 is broken. As long as we = have >> >> a way to indicate "out of /64s" (because that could happen, = even >> >> if you are given a /48, and have some pathology...), then we = are >> >> good. >>=20 >> Michael> Does that apply to my Android phone too? >>=20 >> Are you asking if your Android phone, when it gets only /64 from = LTE/3G >> provider, should hand that out, and then indicate "out of /64s"? Yes. >>=20 >> The phone has a pretty clear way to indicate this problem to the = user. >>=20 > I'm asking about whether I should expect my android phone to get a = /56. > My phone is, after all, capable of being a router. I'm somehow = guessing that > phone isp's aren't giving out /56's though. Maybe. Maybe not. My phone supports three tethering interfaces already. My provider = supports=20 tethering. No IPv6 yet. Any idea how multi-interface tethering is = supported=20 with single /64, without proxy-ND, without translation? We could stop writing how /64 could work, with hacks. Better describe = the=20 clean way of doing, and publish lots on bad things that happen with /64 = PD=20 to customers. Teco >=20 > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mattia.rossi.mailinglists@gmail.com Mon Nov 12 06:05:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF3121F859C for ; Mon, 12 Nov 2012 06:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTpPc7TNmcw4 for ; Mon, 12 Nov 2012 06:05:15 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB1C921F8598 for ; Mon, 12 Nov 2012 06:05:11 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1468767lbk.31 for ; Mon, 12 Nov 2012 06:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jH4NfPiwHLTSYftgjbNEWrsuCd/RrHysh7Nc3tUTqek=; b=EIqr/B7JVPebh7SyL5bk1JAcxhPbMStaysxdj68qVOMQWd7QF3rbiS7SIlgYpVh3IH ER8xttLMXJVshq9saoqVSR3W55qqIw9YT520nwnAlDXYk7ueUzMTNJoFbkUW1NQIkNV8 OUY3YlfDSAXTseJRY/vzqp1olhrGHk/rGjJROFDcRx4Njj34WlbUYaj+J+pKkHMCztHy dUfK1N/pjDpzEPY9u5oVeNgbC0CY6jhKVtlWYIohslgirN544sT7b1mdgcHAUg5xIlxA vCJpxWk/8HuZ72RlF2j5fKoNG0dak8CldDbgWAuQjN0LWEYDAqGyvo5IvjzVvNR1h754 HnQw== Received: by 10.152.104.240 with SMTP id gh16mr18602962lab.56.1352729110671; Mon, 12 Nov 2012 06:05:10 -0800 (PST) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id gt17sm2576859lab.6.2012.11.12.06.05.04 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 06:05:05 -0800 (PST) Message-ID: <50A1020F.5060406@gmail.com> Date: Mon, 12 Nov 2012 15:05:03 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> , <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> In-Reply-To: <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hans Liu Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:05:16 -0000 > If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a fore-coming downstream router attached to me. > So you have to implement a check and some sort of warning mechanism for not getting a PD anyways in all your devices (as I suspect that all of them could eventually be used as a "downstream" router). I don't think that it's much more difficult to check whether the PD was for a /64. You have to do that anyway, as your DHCP server won't be able to create a PD from a /64 and issue a warning in any case. So actually no real extra work needed there. The problem with having just the downstream router warning you though, is that in the case of multihoming, and two prefixes being provided to the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream router might get them over the same interface, and simply issue no warning, as it's happy with the /56 from ISP2, and route everything over that ISP, without the user ever knowing. If the upstream router issues a warning about getting a /64 over an interface from an ISP, the user knows there's something wrong and can fix things, and avoid unnecessary high bills. After the input of various posts I'd like to change the text in 3.4.1: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. to the following text: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. Reverting to bridging would destroy subnetting, breaks multicast if bridged onto 802.11 wireless networks and has serious limitations with regard to heterogeneous link layer technologies and LLNs. For those reasons it is recommended that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning upon receipt of a /64 if required to assign further prefixes within the home network as described in Section 3.4.3. Mat From mcr@sandelman.ca Mon Nov 12 14:16:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3C621F866B for ; Mon, 12 Nov 2012 14:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZYzWL6dW1Ep for ; Mon, 12 Nov 2012 14:16:04 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC0A21F860F for ; Mon, 12 Nov 2012 14:16:04 -0800 (PST) Received: from sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 1B9B481A9; Mon, 12 Nov 2012 17:07:45 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 50AF0CA0C7; Mon, 12 Nov 2012 17:15:50 -0500 (EST) From: Michael Richardson To: mike In-reply-to: <509D921A.6040804@mtcc.com> References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com> <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> <509B9A66.1060903@gmail.com> <509BA4AF.2080308@gmail.com> <14721.1352401138@sandelman.ca> <509D33DE.7020002@mtcc.com> <7036.1352503314@sandelman.ca> <509D921A.6040804@mtcc.com> Comments: In-reply-to mike message dated "Fri, 09 Nov 2012 15:30:34 -0800." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Nov 2012 17:15:50 -0500 Message-ID: <9249.1352758550@sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:16:05 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "mike" =3D=3D mike writes: Michael> Does that apply to my Android phone too? >>=20 >> Are you asking if your Android phone, when it gets only /64 from LTE= /3G >> provider, should hand that out, and then indicate "out of /64s"? Yes. >>=20 >> The phone has a pretty clear way to indicate this problem to the use= r. mike> I'm asking about whether I should expect my android phone to get = a /56. mike> My phone is, after all, capable of being a router. I'm somehow gu= essing that mike> phone isp's aren't giving out /56's though. So far, they aren't giving out anything. Perhaps we can encourage 3G "terminals" to be able to be configured as to how much address space they ask for.... a nice slider :-) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQoXUVAAoJEKD0KQ7Gj3P2d88H/iaa4SxWbSY+OTv+Gu4fZW8E x5i14FxeiA1y8NsoD1A5yjE2qBgVeE9WCx/sPrE5sbnDixyX3EyHsl9ZdXqdN3qk 9mBIOB3ThifKhgo5/5VW3aSXCnfGAxqfo8QbN5Xgi1MkuToubf771KS8l39WXCZt k+yc9ryb0AL9LZFTpdODKB56NQYqY3OzPOoL5mnUtIFZbM9mZOCxyvmhY7TsCxB0 lMYIdL6CuI9Kktfm3KT1KK3bmFbXg7qrvgJ82ufP5vGRTlF/jAStnS9vgxJjZH5h mqPpUYsELvhLeC7hZGjS6an1t4mUEHH7drN3FCSnnj4FDMiOu2ZA4BzXHndMdhg= =Fwp0 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Nov 12 14:17:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B3721F860F for ; Mon, 12 Nov 2012 14:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL6IxkerXfSI for ; Mon, 12 Nov 2012 14:17:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7798F21F866B for ; Mon, 12 Nov 2012 14:17:59 -0800 (PST) Received: from sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id BFBA081AC; Mon, 12 Nov 2012 17:09:05 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A3259CA0C7; Mon, 12 Nov 2012 17:16:45 -0500 (EST) From: Michael Richardson To: Andrew McGregor In-reply-to: References: <509BD51D.1090101@gmail.com> <20603.1352490997@sandelman.ca> Comments: In-reply-to Andrew McGregor message dated "Sat, 10 Nov 2012 09:52:59 -0500." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Nov 2012 17:16:45 -0500 Message-ID: <9353.1352758605@sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:18:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Andrew" =3D=3D Andrew McGregor writes: Andrew> Proxy-ND doesn't seem hard... much less evil than NAT, after al= l. I concur. I am not sure why there has been so much concern about it. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQoXVNAAoJEKD0KQ7Gj3P2vWkH/0FWUNOyFtYAKna0gHFGK+HZ 23FvmVOAUHdvYCj9JbOAfXOg+u+sFiaVSZxmUd/UOPrem61TDxkK7rNxTNxp9XC8 xeeego+EzOmYErWHHSE32W2WsOAItxNf1FlTZVWQt1AaPDcIMkhnJsF3qvw4GZDW QdznS2seYstptjvi2YHqZ3BsVXEJQrA/kzpHrUU1IAY+1+wzN92mWZmUnanRVuS7 k7BMCT8Bm2Zmv1U8wLI4BP1qzIeQGzLYhIBBwIk6FsyIeE7b4n6YE5PXEhElrGJa egwFxZCq5oCR7juzbCHvdBV1QCPY0bRU57qOszaMn5YnrwNdWyL81GBB/NYR6eU= =xn76 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Nov 12 14:18:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649AD21F8696 for ; Mon, 12 Nov 2012 14:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wcie+eLE9xVS for ; Mon, 12 Nov 2012 14:18:50 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1B07421F860F for ; Mon, 12 Nov 2012 14:18:50 -0800 (PST) Received: from sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 6A78181A9; Mon, 12 Nov 2012 17:10:30 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1E8DECA0BC; Mon, 12 Nov 2012 17:18:38 -0500 (EST) From: Michael Richardson To: Mattia Rossi In-reply-to: <50A1020F.5060406@gmail.com> References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> , <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com> Comments: In-reply-to Mattia Rossi message dated "Mon, 12 Nov 2012 15:05:03 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 12 Nov 2012 17:18:38 -0500 Message-ID: <9399.1352758718@sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org, Hans Liu Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:18:51 -0000 >>>>> "Mattia" == Mattia Rossi writes: Mattia> to the following text: Mattia> The home network needs to be adaptable to such ISP policies, and thus Mattia> make no assumptions about the stability of the prefix received from Mattia> an ISP, or the length of the prefix that may be offered. However, if Mattia> only a /64 is offered by the ISP, the homenet may be severely Mattia> constrained. Attempting to use subnet prefixes longer than /64 Mattia> would break SLAAC, and is thus not recommended. Using ULA prefixes Mattia> internally with NPTv6 at the boundary would be possible, but is not Mattia> recommended for reasons given elsewhere. Reverting to bridging would Mattia> destroy subnetting, breaks multicast if bridged onto 802.11 wireless Mattia> networks and has serious limitations with regard to heterogeneous Mattia> link layer technologies and LLNs. For those reasons it is recommended Mattia> that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning Mattia> upon receipt of a /64 if required to assign further prefixes within Mattia> the home network as described in Section 3.4.3. +1 -- Michael Richardson -on the road- From mcr@sandelman.ca Mon Nov 12 14:26:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C7021F8769 for ; Mon, 12 Nov 2012 14:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0vmqzOpQ2vm for ; Mon, 12 Nov 2012 14:26:53 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id A99F921F86F3 for ; Mon, 12 Nov 2012 14:26:53 -0800 (PST) Received: from sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 9C61681A9 for ; Mon, 12 Nov 2012 17:18:30 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4FCCACA0BC for ; Mon, 12 Nov 2012 17:19:02 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-reply-to: <50A1020F.5060406@gmail.com> References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com> , <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com> Comments: In-reply-to Mattia Rossi message dated "Mon, 12 Nov 2012 15:05:03 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Nov 2012 17:19:02 -0500 Message-ID: <9430.1352758742@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:26:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mattia" =3D=3D Mattia Rossi wr= ites: Mattia> to the following text: Mattia> The home network needs to be adaptable to such ISP policies, an= d thus Mattia> make no assumptions about the stability of the prefix received = from Mattia> an ISP, or the length of the prefix that may be offered. Howev= er, if Mattia> only a /64 is offered by the ISP, the homenet may be severely Mattia> constrained. Attempting to use subnet prefixes longer than /64 Mattia> would break SLAAC, and is thus not recommended. Using ULA prefi= xes Mattia> internally with NPTv6 at the boundary would be possible, but is= not Mattia> recommended for reasons given elsewhere. Reverting to bridging = would Mattia> destroy subnetting, breaks multicast if bridged onto 802.11 wir= eless Mattia> networks and has serious limitations with regard to heterogeneo= us Mattia> link layer technologies and LLNs. For those reasons it is recom= mended Mattia> that DHCP-PD or OSPFv3 capable routers have the ability to issu= e a warning Mattia> upon receipt of a /64 if required to assign further prefixes wi= thin Mattia> the home network as described in Section 3.4.3. +1 =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQoXXWAAoJEKD0KQ7Gj3P2gjEH/iYQ+C1xyPmi8pDrsPb4TVCm +VEupO/TPNJFgP/zAOaMCpkEQalI1Db9SdNGuZUclnqrJ1A/4qwPnFxF0Cggy0uV IA7tEj20WoOZTxBl0ZbII/D0F2SPqLpsO4YEz0PShNUEay831YSwHU02/6ML6GqA kW7fch/1HzuhxgoMBE5bWIg842MV/OVtkHzvcBiUnWEqf2DTHWGiCeDkYlN3tKFF u9kEDtinMz0o+oF9uUQZjM8hISd/U9GwU43yweFrX8i6BwAbc7LQrOM7DkP8bToS T7Feo9atXWGu6F13H3xRwNDwOaB+RbI9vpU0zSx/Qf3EArt/wcFJtY8rgSEY5gE= =WiAP -----END PGP SIGNATURE----- --=-=-=-- From mark@townsley.net Mon Nov 12 14:34:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4B21F879C for ; Mon, 12 Nov 2012 14:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3l-RFrpWVT6 for ; Mon, 12 Nov 2012 14:34:28 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5021F8798 for ; Mon, 12 Nov 2012 14:34:22 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so3353328wey.31 for ; Mon, 12 Nov 2012 14:34:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=BNSbls4xdOwKJmJBWXVZ/I15DTXzg447DGJ0Sy8aIi4=; b=f1XSlh6JwFwihji/ysbMOsVO4MYe94KQSdg6vd/KbKLFqf91b10qgNqVRl7J37jFOP rbbBQh/EQso4mKxdJoeBP/dtctHis8zyFy4A3mOpiUb1fI5inC0PDqhbC/MGfGSdedgc gxZ7gRNM45rAcLGIyB1yb8Q7iWNYIxnFEbIA+e4muUnSSmv8DVqZU53X4me+/QIXPIuI 161fZ+dI902gjchMXfAqoF4U6dYKy8dmWX2tptOWizH8tQcukiAgIHBxgudpMMCeCjpE It2wdc6VekLWWGyluPCgQOX0wJKNgAvrRCznyK971qh1ToG5PacCTS72zzA3RXblXjRJ spXQ== Received: by 10.216.56.82 with SMTP id l60mr7875413wec.18.1352759661833; Mon, 12 Nov 2012 14:34:21 -0800 (PST) Received: from marks-mac-mini.home (AMontsouris-159-1-105-205.w82-123.abo.wanadoo.fr. [82.123.104.205]) by mx.google.com with ESMTPS id gz3sm4183191wib.2.2012.11.12.14.34.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 14:34:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FEEC0BCC-497B-45F8-B076-B51BD6C7F59F" From: Mark Townsley In-Reply-To: <509DAC0B.9060108@gridmerge.com> Date: Mon, 12 Nov 2012 12:47:59 +0100 Message-Id: <95BED18A-D44A-47D6-BEBF-D5E234B5523F@townsley.net> References: <509BD51D.1090101@gmail.com> <20603.1352490997@sandelman.ca> <509DAC0B.9060108@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm/oxpzpzmm7UifJyVNrKBLFxtiAwT01Hdigs+pBoA2xy/676QSjUY/y2D9ABj4SrjYwXup Cc: homenet@ietf.org Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:34:28 -0000 --Apple-Mail=_FEEC0BCC-497B-45F8-B076-B51BD6C7F59F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 10, 2012, at 2:21 AM, Robert Cragie wrote: >=20 > On 09/11/2012 7:56 PM, Michael Richardson wrote: >> (and that's why RPL isn't on the table at homenet) > Why not? Again, the sort of networks which would use RPL (LLNs) = are referred to in the charter. In the charter, LLNs are referred to as an example of a link-layer which = might exist in the home and would accordingly require its own routed = subnet, not that the entire home itself will be an LLN. - Mark >=20 >=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_FEEC0BCC-497B-45F8-B076-B51BD6C7F59F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
=20 =20

On 09/11/2012 7:56 PM, Michael Richardson wrote:
(and that's why RPL isn't on the table at =
homenet)
<RCC>Why not? Again, the sort of networks which would use RPL (LLNs) are referred to in the = charter.</RCC>

In the charter, = LLNs are referred to as an example of a link-layer which might exist in = the home and would accordingly require its own routed subnet, not that = the entire home itself will be an LLN.

- Mark




      

      

      

      
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.or=
g/mailman/listinfo/homenet


    

    

  


_______________________________________________
homenet mailing =
list
homenet@ietf.org
https://www.ietf.=
org/mailman/listinfo/homenet

=

--Apple-Mail=_FEEC0BCC-497B-45F8-B076-B51BD6C7F59F--

From mark@townsley.net  Mon Nov 12 14:36:01 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714E021F8790 for ; Mon, 12 Nov 2012 14:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.862
X-Spam-Level: 
X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=0.693,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpe9ecIBGazh for ; Mon, 12 Nov 2012 14:36:00 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B56A21F8782 for ; Mon, 12 Nov 2012 14:36:00 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so982139eek.31 for ; Mon, 12 Nov 2012 14:35:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=H/ZcftEb92ARRKl3VPrdIsIH7CV3kEIRpcO+OmwfgcU=; b=gtjAjO4US4UNokAmm3gUlvVdYS05SyngRvPNZjImTHlYGEnlx4MzXslnBob3qmSAcS KLSLrOqr8kPV5sgrYDii4pCbEZ2jPa8NjRpNDAzppv9yhPfqKl9RRgba0n/TiARl1C2T WuGw/7Rzf/yTtKE7ialqlksOv1sUHh1IL55MmnTKOUnsZ4fq0C8gvDBJIz7dadSff2M9 fMjdapTXrIGqxp8kRSrbnrbM7jla3hzJZYbN9vJnqaN/b1htzYDVehQfE2Ghsb9oit79 beqQm8WCjE0HgGf1lX3QDt6YGg8M1G4XK4uV2ep/5ccTH/O2AxUzSr05Glni9zf94kKX dGSQ==
Received: by 10.14.184.2 with SMTP id r2mr67248081eem.43.1352759759514; Mon, 12 Nov 2012 14:35:59 -0800 (PST)
Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id f2sm18656640eep.2.2012.11.12.14.35.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 14:35:58 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <50A1020F.5060406@gmail.com>
Date: Mon, 12 Nov 2012 18:33:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>  , <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>
To: Mattia Rossi 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQmR+cQ7dWDTtMkfPChdYTh9irncqUCUzUKx8pzwae9PAxGxzGWXWAmxuZa7iE4L4EHhkSW+
Cc: homenet@ietf.org, Hans Liu 
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2012 22:36:01 -0000

Nice to see a constructive thread with suggested text for the editors of =
the homenet arch, thank you.

I'm concerned with any "issue a warning" type suggestions though. We are =
working hard to develop automatic configuration that assumes there is no =
operator involved here. If there is no operator to configure our =
protocols, there is no operator to issue a warning to either.=20

If the homenet runs out of /64s to hand out, and we recommend not to =
route /128s, bridge, NPTv6, etc... then the final option is, simply,  =
"no IPv6" for that given link. Falling back to the user to try and =
interpret a cryptic message about IPv6 prefixes is simply not a =
realistic option for the protocols we are working on here.=20

- Mark

On Nov 12, 2012, at 3:05 PM, Mattia Rossi wrote:

>=20
>> If I'm the downstream router, I can't get a prefix, of course I issue =
warning message. However, if I'm the one who still get an /64 and works =
fine as a leaf, I won't issue an warning message for a fore-coming =
downstream router attached to me.
>>=20
> So you have to implement a check and some sort of warning mechanism =
for not getting a PD anyways in all your devices (as I suspect that all =
of them could eventually be used as a "downstream" router). I don't =
think that it's much more difficult to check whether the PD was for a =
/64. You have to do that anyway, as your DHCP server won't be able to =
create a PD from a /64 and issue a warning in any case. So actually no =
real extra work needed there.
>=20
> 
> The problem with having just the downstream router warning you though, =
is that in the case of multihoming, and two prefixes being provided to =
the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream =
router might get them over the same interface, and simply issue no =
warning, as it's happy with the /56 from ISP2, and route everything over =
that ISP, without the user ever knowing. If the upstream router issues a =
warning about getting a /64 over an interface from an ISP, the user =
knows there's something wrong and can fix things, and avoid unnecessary =
high bills.
> 
>=20
> After the input of various posts I'd like to change the text in 3.4.1:
>=20
>   The home network needs to be adaptable to such ISP policies, and =
thus
>   make no assumptions about the stability of the prefix received from
>   an ISP, or the length of the prefix that may be offered.  However, =
if
>   only a /64 is offered by the ISP, the homenet may be severely
>   constrained (with IPv6 not reaching all devices in the home, or use
>   of some form of IPv6 NAT being forced), or even unable to function.
>   While it may be possible to operate a DHCPv6-only network with
>   prefixes longer than /64, doing so would break SLAAC, and is thus =
not
>   recommended.
>=20
> to the following text:
>=20
>   The home network needs to be adaptable to such ISP policies, and =
thus
>   make no assumptions about the stability of the prefix received from
>   an ISP, or the length of the prefix that may be offered.  However, =
if
>   only a /64 is offered by the ISP, the homenet may be severely
>   constrained. Attempting to use subnet prefixes longer than /64
>   would break SLAAC, and is thus not recommended. Using ULA prefixes
>   internally with NPTv6 at the boundary would be possible, but is not
>   recommended for reasons given elsewhere. Reverting to bridging would
>   destroy subnetting, breaks multicast if bridged onto 802.11 wireless
>   networks and has serious limitations with regard to heterogeneous
>   link layer technologies and LLNs. For those reasons it is =
recommended
>   that DHCP-PD or OSPFv3 capable routers have the ability to issue a =
warning
>   upon receipt of a /64 if required to assign further prefixes within
>   the home network as described in Section 3.4.3.
>=20
>=20
> Mat
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From mcr@sandelman.ca  Mon Nov 12 16:03:18 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7315721F8740 for ; Mon, 12 Nov 2012 16:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0InbtteCia1d for ; Mon, 12 Nov 2012 16:03:12 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B027321F86E4 for ; Mon, 12 Nov 2012 16:03:12 -0800 (PST)
Received: from sandelman.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 9936F81A9 for ; Mon, 12 Nov 2012 18:54:51 -0500 (EST)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B8160CA0BC for ; Mon, 12 Nov 2012 19:03:09 -0500 (EST)
From: Michael Richardson 
To: homenet@ietf.org
In-reply-to: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>  , <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com> 
Comments: In-reply-to Mark Townsley  message dated "Mon, 12 Nov 2012 18:33:56 +0100."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 12 Nov 2012 19:03:09 -0500
Message-ID: <13972.1352764989@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 00:03:18 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Mark" =3D=3D Mark Townsley  writes:
    Mark> I'm concerned with any "issue a warning" type suggestions
    Mark> though. We are working hard to develop automatic configuration
    Mark> that assumes there is no operator involved here. If there is
    Mark> no operator to configure our protocols, there is no operator
    Mark> to issue a warning to either.=20=20

okay.
Can we define a DHCP "request", which is really a request for the ISP to
log something from that customer?  i.e. can we tunnel syslog through
dhcp?   :-)

Or shall we suggest homenet routers ask the ISP for a syslog server,
and log things there?  (do we have a dhcp option to describe syslog
server...  a grep of RFCs doesn't find one, and rfc5424 doesn't mention
one)=20

In particular, for ISP provided routers, this would make lots of sense.

=2D-=20
Michael Richardson
=2Don the road-

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJQoY49AAoJEKD0KQ7Gj3P2394H/2VPbGQDsT7L+xnP8J1u5Btb
w7cc0gZmSA1W+mUpFrxTwc9mXiqqIJhd8rEJfPWPJe75bR6NDv1k7k4cHSqkktlT
Qynt6XoYJrF5JXMRwChmrjtuI7hokdnMt9g5QVUcqGZMRSCSqHqpGI8o5bLg5S1B
MISwT4ThZk4FvMZL/pMu2QBGcGd64vlO5BXOWy8unb9bgU4MxgKX4WcRlz6foxV9
4D7xM2VndKv8Kh9IxCIIjIVhCCPORTZrUZPGTCTmXeAUayZNOf9kCq/oyTevkAQ3
uImB5s2BHPgde6GwOrJNQMQx5iwbOL9/4Qjdn/dC4vHg8pI/35oWSlIQ6BnRF74=
=TRzy
-----END PGP SIGNATURE-----
--=-=-=--

From brian.e.carpenter@gmail.com  Tue Nov 13 00:24:18 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1A721F88FB for ; Tue, 13 Nov 2012 00:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.609
X-Spam-Level: 
X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZEkIJVvi3xR for ; Tue, 13 Nov 2012 00:24:18 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1221F88F7 for ; Tue, 13 Nov 2012 00:24:17 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id u46so3512282wey.31 for ; Tue, 13 Nov 2012 00:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q6mU2m46Fm0w0lVauPX0RuTcFT9sbrFMNgiqFQ2BRvY=; b=mAUz95hJvDWH3jL4SJ+CBqWV72wjDmio2X8yvnINgZleNeWxAzX+IBsAO/sysRv7sl /Rrf+YJvC2D8Sx8ajf/wOirAMBHzMBJerfh11qKBa2oHmtdfQfX7tetqAsxbd0MpIAao 9xBZt3sWOu/WgopkFme0X9YKbzkbYslCgPN2HftgYZmd3u8FYzSErU9E/tphtIRX5ZNx wrywTdQEByzAa6NAaQxoRnBdqhu95xe7HqDKe3JQm/yWmx9nUjYyVXdSZKRaAfFuuOcJ ybzL9kFCxLvd+LizQ2DfWPAESiJjAOSKK4zkG55NAKEgzsLFKlH04JPg68BUNOX4VeWI 86vA==
Received: by 10.216.198.207 with SMTP id v57mr449965wen.51.1352795056698; Tue, 13 Nov 2012 00:24:16 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-97.as13285.net. [2.102.216.97]) by mx.google.com with ESMTPS id bn7sm15350148wib.8.2012.11.13.00.24.15 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 00:24:15 -0800 (PST)
Message-ID: <50A203B4.2070100@gmail.com>
Date: Tue, 13 Nov 2012 08:24:20 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Townsley 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>		, <509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: homenet@ietf.org, Hans Liu , Mattia Rossi 
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture	document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 08:24:18 -0000

On 12/11/2012 17:33, Mark Townsley wrote:
> Nice to see a constructive thread with suggested text for the editors of the homenet arch, thank you.
> 
> I'm concerned with any "issue a warning" type suggestions though. We are working hard to develop automatic configuration that assumes there is no operator involved here. If there is no operator to configure our protocols, there is no operator to issue a warning to either. 
> 
> If the homenet runs out of /64s to hand out, and we recommend not to route /128s, bridge, NPTv6, etc... then the final option is, simply,  "no IPv6" for that given link. Falling back to the user to try and interpret a cryptic message about IPv6 prefixes is simply not a realistic option for the protocols we are working on here. 

Which is a FAIL if there are any v6-only devices around. Ultimately I don't see
how you can avoid some kind of warning to the user, even if it's the equivalent
of the beeping from a smoke detector whose battery is fading.

   Brian

> - Mark
> 
> On Nov 12, 2012, at 3:05 PM, Mattia Rossi wrote:
> 
>>> If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a fore-coming downstream router attached to me.
>>>
>> So you have to implement a check and some sort of warning mechanism for not getting a PD anyways in all your devices (as I suspect that all of them could eventually be used as a "downstream" router). I don't think that it's much more difficult to check whether the PD was for a /64. You have to do that anyway, as your DHCP server won't be able to create a PD from a /64 and issue a warning in any case. So actually no real extra work needed there.
>>
>> 
>> The problem with having just the downstream router warning you though, is that in the case of multihoming, and two prefixes being provided to the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream router might get them over the same interface, and simply issue no warning, as it's happy with the /56 from ISP2, and route everything over that ISP, without the user ever knowing. If the upstream router issues a warning about getting a /64 over an interface from an ISP, the user knows there's something wrong and can fix things, and avoid unnecessary high bills.
>> 
>>
>> After the input of various posts I'd like to change the text in 3.4.1:
>>
>>   The home network needs to be adaptable to such ISP policies, and thus
>>   make no assumptions about the stability of the prefix received from
>>   an ISP, or the length of the prefix that may be offered.  However, if
>>   only a /64 is offered by the ISP, the homenet may be severely
>>   constrained (with IPv6 not reaching all devices in the home, or use
>>   of some form of IPv6 NAT being forced), or even unable to function.
>>   While it may be possible to operate a DHCPv6-only network with
>>   prefixes longer than /64, doing so would break SLAAC, and is thus not
>>   recommended.
>>
>> to the following text:
>>
>>   The home network needs to be adaptable to such ISP policies, and thus
>>   make no assumptions about the stability of the prefix received from
>>   an ISP, or the length of the prefix that may be offered.  However, if
>>   only a /64 is offered by the ISP, the homenet may be severely
>>   constrained. Attempting to use subnet prefixes longer than /64
>>   would break SLAAC, and is thus not recommended. Using ULA prefixes
>>   internally with NPTv6 at the boundary would be possible, but is not
>>   recommended for reasons given elsewhere. Reverting to bridging would
>>   destroy subnetting, breaks multicast if bridged onto 802.11 wireless
>>   networks and has serious limitations with regard to heterogeneous
>>   link layer technologies and LLNs. For those reasons it is recommended
>>   that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning
>>   upon receipt of a /64 if required to assign further prefixes within
>>   the home network as described in Section 3.4.3.
>>
>>
>> Mat
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

From robert.cragie@gridmerge.com  Tue Nov 13 05:08:21 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9E21F85E7 for ; Tue, 13 Nov 2012 05:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level: 
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z+twWT3qBve for ; Tue, 13 Nov 2012 05:08:20 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4349D21F8573 for ; Tue, 13 Nov 2012 05:08:19 -0800 (PST)
Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TYGDv-0004vk-KV for homenet@ietf.org; Tue, 13 Nov 2012 13:08:15 +0000
Message-ID: <50A2469B.9050703@gridmerge.com>
Date: Tue, 13 Nov 2012 13:09:47 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: homenet@ietf.org
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>		, <509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>
In-Reply-To: <50A203B4.2070100@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000404070807000306080405"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture	document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 13:08:21 -0000

This is a cryptographically signed message in MIME format.

--------------ms000404070807000306080405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

+1 to Brian. Falling back to the user left with a broken connection and=20
no feedback is not acceptable. Short cryptic messages may be terse at=20
the point of origin but there is no lack of resources on the internet to =

elucidate them.

Robert

On 13/11/2012 8:24 AM, Brian E Carpenter wrote:
> On 12/11/2012 17:33, Mark Townsley wrote:
>> Nice to see a constructive thread with suggested text for the editors =
of the homenet arch, thank you.
>>
>> I'm concerned with any "issue a warning" type suggestions though. We a=
re working hard to develop automatic configuration that assumes there is =
no operator involved here. If there is no operator to configure our proto=
cols, there is no operator to issue a warning to either.
>>
>> If the homenet runs out of /64s to hand out, and we recommend not to r=
oute /128s, bridge, NPTv6, etc... then the final option is, simply,  "no =
IPv6" for that given link. Falling back to the user to try and interpret =
a cryptic message about IPv6 prefixes is simply not a realistic option fo=
r the protocols we are working on here.
> Which is a FAIL if there are any v6-only devices around. Ultimately I d=
on't see
> how you can avoid some kind of warning to the user, even if it's the eq=
uivalent
> of the beeping from a smoke detector whose battery is fading.
>
>     Brian


--------------ms000404070807000306080405
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMTMxMzA5NDdaMCMGCSqGSIb3DQEJBDEWBBRB4WErLGJS7LQzx9m+ON/VVv8MwzBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAHxAXDN3W5CCSCbKyzHqD2gpUqCPjcK7dCsiKPjeS9cjgHDc
45eyth2kmGnJgUWQ1kLmbXfNOOvQGAbJbX7E7KkdCBU9UY+S4SrN0WFujhjtv5bpsz2llgSd
rjBChMb70Cz8YgKvepbqyymVCLIQW8wQ5Y1a3hfEFR3uuEcnnoIB7WDiSLcS5OKrS7KAMxAr
RAnRofinGkwXD84x6+nb7PzZPcG66ChUcNI4FgmroYlNmHHH+P/Tp4pjyabtErKjkeeHmhXn
80qtQ2/LcPYOdObnajzao6GbjlxxYn8WXD/KRU+4gIwSgyBdHtjDMOBpz9yMGaQR/k9TuJQC
/mkAhvwAAAAAAAA=
--------------ms000404070807000306080405--

From robert.cragie@gridmerge.com  Tue Nov 13 05:19:16 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B325B21F8450 for ; Tue, 13 Nov 2012 05:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level: 
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.287,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE7LnxTQDndB for ; Tue, 13 Nov 2012 05:19:16 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB5C21F8857 for ; Tue, 13 Nov 2012 05:19:15 -0800 (PST)
Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TYGOV-0002eh-3B; Tue, 13 Nov 2012 13:19:11 +0000
Message-ID: <50A2492B.7000607@gridmerge.com>
Date: Tue, 13 Nov 2012 13:20:43 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Mark Townsley 
References:  <509BD51D.1090101@gmail.com>  <20603.1352490997@sandelman.ca> <509DAC0B.9060108@gridmerge.com> <95BED18A-D44A-47D6-BEBF-D5E234B5523F@townsley.net>
In-Reply-To: <95BED18A-D44A-47D6-BEBF-D5E234B5523F@townsley.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060603060400040308070408"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: homenet@ietf.org
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 13:19:16 -0000

This is a cryptographically signed message in MIME format.

--------------ms060603060400040308070408
Content-Type: multipart/alternative;
 boundary="------------030803030903090201020209"

This is a multi-part message in MIME format.
--------------030803030903090201020209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Mark,

I agree with what you say but that still means RPL could be on the=20
table. It seems quite feasible to me that we could have a multi-link=20
route-over subnet using a routing protocol such as RPL with downstream=20
border routers as well. This may seem unlikely with an LLN but is more=20
feasible with broader band link layer technologies. Granted, if=20
multi-link route-over subnets are considered to exist only as "leaf=20
subnets" (i.e. without downstream border routers) then life does get=20
somewhat easier. The question is whether that is acceptable or not for=20
the general picture.

Robert

On 12/11/2012 11:47 AM, Mark Townsley wrote:
>
> On Nov 10, 2012, at 2:21 AM, Robert Cragie wrote:
>
>>
>> On 09/11/2012 7:56 PM, Michael Richardson wrote:
>>> (and that's why RPL isn't on the table at homenet)
>> Why not? Again, the sort of networks which would use RPL (LLNs)=20
>> are referred to in the charter.
>
> In the charter, LLNs are referred to as an example of a link-layer=20
> which might exist in the home and would accordingly require its own=20
> routed subnet, not that the entire home itself will be an LLN.
>
> - Mark
>
>>
>>
>>>
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org 
>> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--------------030803030903090201020209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Mark,

    

    I agree with what you say but that still means RPL could be on the
    table. It seems quite feasible to me that we could have a multi-link
    route-over subnet using a routing protocol such as RPL with
    downstream border routers as well. This may seem unlikely with an
    LLN but is more feasible with broader band link layer technologies.
    Granted, if multi-link route-over subnets are considered to exist
    only as "leaf subnets" (i.e. without downstream border routers) then
    life does get somewhat easier. The question is whether that is
    acceptable or not for the general picture.

    

    Robert

    

    
On 12/11/2012 11:47 AM, Mark Townsley
      wrote:

    

    


      

        
On Nov 10, 2012, at 2:21 AM, Robert Cragie wrote:

        

        

          
          
 

            
On 09/11/2012 7:56 PM, Michael=

              Richardson wrote:

            

            

              
(and that's why RPL isn't on the table at ho=
menet)

            

            <RCC>Why not? Again, the sort of networks which would
            use RPL (LLNs) are referred to in the charter.</RCC>
          

        

        


        

        
In the charter, LLNs are referred to as an example
            of a link-layer which might exist in the home and would
            accordingly require its own routed subnet, not that the
            entire home itself will be an LLN.

        


          

        
- Mark<=
/div>
        

        

          
 

            

            
 

              

              

              
____________________________________________=
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/li=
stinfo/homenet


            

            

          

          _______________________________________________

          homenet mailing list

          ho=
menet@ietf.org

          https://www.ietf.org/mailman/listinfo/homenet<=
/a>

        

      

      

      

      

      

      
_______________________________________________
homenet mailing list
ho=
menet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


    

    

  


--------------030803030903090201020209--

--------------ms060603060400040308070408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMTMxMzIwNDNaMCMGCSqGSIb3DQEJBDEWBBTfUq/3uALyhVT40I7P1uuzsdOUtTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBABpn0hzEDJhaZultLOPw3+lnkwJTiAJLrr9oZvsjJWZRYiac
uvxCPb8k+IEwsHIkcRGdoY7tHQtEgTX1t8g5UIYLC7VxkVls1ORRAim/uzB+xDJvFm22yowz
CXrQ+WC2P8RGZLz+p84mtVRJ8Xgd6359Hb9bJ+ULoWFAqQAnkjqiY7UZkEBui3AOBqRzv/jW
MZXgCgfv01egmYoZ/r3NxIVMbBBCXa5HsT2sHqnHhsKHdCVU1HjpakUg8gnAhPylvbEFm2ms
XD5E8TocbBMLpwY6iAIdPhnGcUt9pJQ/SDHSkS361RUx2Q/vSweQRlYtfSdhXO1YAZXhArOo
zuS/nGEAAAAAAAA=
--------------ms060603060400040308070408--

From mellon@fugue.com  Tue Nov 13 06:15:03 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59E21F868F for ; Tue, 13 Nov 2012 06:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgacefOgn4LF for ; Tue, 13 Nov 2012 06:14:58 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7B521F867C for ; Tue, 13 Nov 2012 06:14:58 -0800 (PST)
Received: from [10.0.1.108] (cpe-72-179-61-125.austin.res.rr.com [72.179.61.125]) by toccata.fugue.com (Postfix) with ESMTPSA id 423F62380435; Tue, 13 Nov 2012 09:14:53 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: <50A203B4.2070100@gmail.com>
Date: Tue, 13 Nov 2012 08:14:52 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>		, <509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1499)
Cc: homenet@ietf.org, Mark Townsley , Hans Liu , Mattia Rossi 
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture	document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 14:15:03 -0000

On Nov 13, 2012, at 2:24 AM, Brian E Carpenter =
 wrote:
> even if it's the equivalent
> of the beeping from a smoke detector whose battery is fading.

To which the typical response is to throw the damned thing through the =
window out of rage after it's been beeping for a couple of hours.

No, there are several viable solutions to this problem that don't =
involve beeping.   Beeping is not the right solution.

I would just like to point out, regarding the bufferbloat problem, that =
there are two classes of outcome if we hack around this problem instead =
of beeping.

The first class of outcome is that something works less well than it =
otherwise would have.   This is the bufferbloat problem.   If you have =
bufferbloat because you set up a bridge where ideally you shouldn't =
have, this is bad, and the customer will experience less than ideal =
outcomes.   But fundamentally, their network will function, particularly =
when loads are light.   And so this becomes a problem that they will =
either live with, or try to solve, but it is not an emergency.   It is a =
bad outcome, and the villain is clear: it's the ISP who gave out a /64.  =
 FAQs on the net can cast the blame appropriately, and the home gateway =
can provide diagnostics that explain why the situation is suboptimal.

Contrast this with NAPTv6.   In this case, the network is _broken_.   =
End to end doesn't work.   If you are not connected directly to the =
border gateway, certain protocols simply will not work.   The result of =
this will be a general expectation on the part of applications vendors =
that end-to-end isn't something that can be counted upon.   And so we =
will have got nothing for all our effort in deploying IPv6.   We'll be =
back to NAT-inspired walled gardens.

Let's at least set our sights on the better outcome: the one that =
preserves end to end.   Yes, it's not ideal.   But the blame will be =
cast on the correct villain, the end-user will at least have a chance of =
a good outcome, and it won't needlessly break end-to-end.


From mattia.rossi.mailinglists@gmail.com  Tue Nov 13 07:50:33 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B41A21F84FA for ; Tue, 13 Nov 2012 07:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIcOvBuY7Szu for ; Tue, 13 Nov 2012 07:50:32 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7A4321F84C7 for ; Tue, 13 Nov 2012 07:50:30 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id d3so2056439lah.31 for ; Tue, 13 Nov 2012 07:50:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bvULKEKmCVgqfFm4PTK66GuXrHSsDbbjMPvyM7TlgkY=; b=wGFlxaWcrIuf9A95TvH09MWsjru/GP0K9+6migN/eETsCrmxqvwAmOFaB/cPRm4SP/ dberPM8NIkQCMHzU83C9xkbTtiHMeW+BpLJiGPNh4TIRrBavuPQDD3UpA3QumLNmwo2I EkgE60NXsHKekvptDnoDueTTIzcUovVezHt38+B9c2th7NGvm4uCsaS2HDne3EX+YOQM m4bU8uwEugea7kgHLm+AhWmpW9MBL0LKvnxZU/35A2tpQGRlFKkJHzJi4tRbwUQy/aUr ZMLjzv3i73XmA+7dpDL0OQXSksNtPvbIcWAqtIvXQaLzgaKZChBwQWSA197IYxT6oM4r 7wFA==
Received: by 10.152.102.234 with SMTP id fr10mr22177916lab.28.1352821827512; Tue, 13 Nov 2012 07:50:27 -0800 (PST)
Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id sj3sm3965880lab.2.2012.11.13.07.50.25 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 07:50:26 -0800 (PST)
Message-ID: <50A26C40.8020201@gmail.com>
Date: Tue, 13 Nov 2012 16:50:24 +0100
From: Mattia Rossi 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Ted Lemon 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>		, <509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Hans Liu , homenet@ietf.org, Mark Townsley 
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 15:50:33 -0000

Am 13.11.2012 15:14, schrieb Ted Lemon:
> On Nov 13, 2012, at 2:24 AM, Brian E Carpenter  wrote:
>> even if it's the equivalent
>> of the beeping from a smoke detector whose battery is fading.
> To which the typical response is to throw the damned thing through the window out of rage after it's been beeping for a couple of hours.
>
> No, there are several viable solutions to this problem that don't involve beeping.   Beeping is not the right solution.
>
> I would just like to point out, regarding the bufferbloat problem, that there are two classes of outcome if we hack around this problem instead of beeping.
>
> The first class of outcome is that something works less well than it otherwise would have.   This is the bufferbloat problem.   If you have bufferbloat because you set up a bridge where ideally you shouldn't have, this is bad, and the customer will experience less than ideal outcomes.   But fundamentally, their network will function, particularly when loads are light.   And so this becomes a problem that they will either live with, or try to solve, but it is not an emergency.   It is a bad outcome, and the villain is clear: it's the ISP who gave out a /64.   FAQs on the net can cast the blame appropriately, and the home gateway can provide diagnostics that explain why the situation is suboptimal.
>
> Contrast this with NAPTv6.   In this case, the network is _broken_.   End to end doesn't work.   If you are not connected directly to the border gateway, certain protocols simply will not work.   The result of this will be a general expectation on the part of applications vendors that end-to-end isn't something that can be counted upon.   And so we will have got nothing for all our effort in deploying IPv6.   We'll be back to NAT-inspired walled gardens.
>
> Let's at least set our sights on the better outcome: the one that preserves end to end.   Yes, it's not ideal.   But the blame will be cast on the correct villain, the end-user will at least have a chance of a good outcome, and it won't needlessly break end-to-end.
>
I still like the idea of a led which is red if no prefix could be 
received, orange if a /64 has been assigned, and a prefix has been 
requested from a downstream router (no prefix for the downstream 
router), and green if a prefix < /64 has been assigned and a prefix has 
been requested from a downstream router and successfully provided.
This is like the leds on the smoke detector, which start blinking once 
the battery level is low. They signal a problem, but it's up to the user 
whether to ignore it, or to fix it.
Additionally, if there's no prefix request from a downstream router, no 
warning will be issued (e.g. green led) as there's no problem.
Dual homed networks with a /64 from one provider and a /56 from the 
other might actually behave the same.
As the /64 part gets a prefix request, it switches to orange led, even 
though the prefix can be provided by the /56 part, and subnetting works. 
But it's a partial bad outcome, and the user should get a hint at that.
Up to him then to leave it or fix it.

I can understand that it would be almost out of scope to put such a 
mechanism/idea should into the draft, as it should focus on how to 
magically solve issues.
I'm just afraid that even if you put in phrases like "a /64 will 
seriously limit the functioning of the homenet" twenty times in the 
draft, it might get ignored by ISPs, and thus would love to have the 
suggestion of issuing some sort of warning by the gear vendors written 
somwhere.

Just my 2c

Mat


From mike@mtcc.com  Tue Nov 13 08:01:41 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ED921F8705 for ; Tue, 13 Nov 2012 08:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltZ-mpWSb986 for ; Tue, 13 Nov 2012 08:01:36 -0800 (PST)
Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 978CF21F8703 for ; Tue, 13 Nov 2012 08:01:35 -0800 (PST)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id qADG1KZj013472 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 08:01:21 -0800
Message-ID: <50A26ED0.7090803@mtcc.com>
Date: Tue, 13 Nov 2012 08:01:20 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Brian E Carpenter 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>		, <509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>
In-Reply-To: <50A203B4.2070100@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2204; t=1352822481; x=1353686481; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20When=20things=20go=20wrong=20on=20your=20homene t |Sender:=20 |To:=20Brian=20E=20Carpenter=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=h94YFmL4ZpoqJwbZ37mX0hpkzwWIO/4/3r8o38tK0vo=; b=rvk6Lkh6wqij0zN/6WPw3bn+NwIP1r+r0Tj/wk1gmcPWsvEPSyyeCun7og 6MeR73vF6so9j6mH2H+xWfEQvwuf/pgSoshsnjrAk4ayaX7Xor6rVBEXp6uL B5NENc/vD9bEbYf8o/JI7bIa7fda04dQcivBcXwZbhhbuEtIfYfQg=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: homenet@ietf.org, Mark Townsley , Hans Liu , Mattia Rossi 
Subject: [homenet] When things go wrong on your homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 16:01:41 -0000

On 11/13/2012 12:24 AM, Brian E Carpenter wrote:
> On 12/11/2012 17:33, Mark Townsley wrote:
>> Nice to see a constructive thread with suggested text for the editors of the homenet arch, thank you.
>>
>> I'm concerned with any "issue a warning" type suggestions though. We are working hard to develop automatic configuration that assumes there is no operator involved here. If there is no operator to configure our protocols, there is no operator to issue a warning to either.
>>
>> If the homenet runs out of /64s to hand out, and we recommend not to route /128s, bridge, NPTv6, etc... then the final option is, simply,  "no IPv6" for that given link. Falling back to the user to try and interpret a cryptic message about IPv6 prefixes is simply not a realistic option for the protocols we are working on here.
> Which is a FAIL if there are any v6-only devices around. Ultimately I don't see
> how you can avoid some kind of warning to the user, even if it's the equivalent
> of the beeping from a smoke detector whose battery is fading.
>

I too am bothered quite a lot by the notion that nothing will ever go wrong
therefore we don't have to plan for it. With the complexity of networks being
contemplated here, I think the likelihood that they will self-organize and just
"work" completely unattended in all/most cases asymptotically approaches zero.
We simply have no empirical evidence that any such thing has ever been done,
and plenty of evidence that even given huge amounts of networking clue that
awful things happen awfully often.

What really bothers me is that routers are treated as "others": the notion that
normal people are not just expected to have no clue about networking, but
that they should be actively prevented from gaining clue by interacting with
their infrastructure. I really think that's wrongheaded. While I think that a
beeping box is a horrible idea, I wouldn't be adverse to my box, say, sending
me email alerting me to what is wrong, and how I might fix it. There are probably
many other ways to deal with this too, and the problem isn't limited to routers
but all headless boxen -- though routers may have some unique properties.

Mike

From dave.taht@gmail.com  Tue Nov 13 08:27:07 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BBF21F8477 for ; Tue, 13 Nov 2012 08:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SIdRYRxwKt7 for ; Tue, 13 Nov 2012 08:27:05 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B31A21F841F for ; Tue, 13 Nov 2012 08:27:03 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id k13so3267826eaa.31 for ; Tue, 13 Nov 2012 08:27:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yMkLoY7btL4BDyG7IFfDocK/PW0b/NLVTt8tu3OyJQw=; b=aCNp2dngad3bSge3LyNX12v0NUPJX2xOtiqWGmggmmzqX3dBeuhqLmK0OZIchyFGq6 ybb+sfe5W97R/k6f9+voF8v+ex7mW8Wbwg3VsH0lYP7gHs8BXu/SZ7drnob3CzmC2zdU bKj3bDftYtZbCFfGbycUJW/kIV8mOWoT71BUuVqIWMO++6ttlKtUpW6VcjwmUx5tIMKM 35Vi8flGR5nITHSiATELK3ivsPcZ3suwEof9strOgUXHdA9z3/wSpsYCA8+gXgBbwpAL DTbVR3eb+AoBNtwh8V9IsooRPttxLWosUaTs0JDXtb6EEO5JVozvxbKjuy66ev2/Upc3 Wspw==
MIME-Version: 1.0
Received: by 10.14.173.71 with SMTP id u47mr76297973eel.20.1352824021172; Tue, 13 Nov 2012 08:27:01 -0800 (PST)
Received: by 10.223.180.10 with HTTP; Tue, 13 Nov 2012 08:27:01 -0800 (PST)
In-Reply-To: <50A26ED0.7090803@mtcc.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>
Date: Tue, 13 Nov 2012 17:27:01 +0100
Message-ID: 
From: Dave Taht 
To: Michael Thomas 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Hans Liu , homenet@ietf.org, Mark Townsley , Mattia Rossi 
Subject: Re: [homenet] When things go wrong on your homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 16:27:07 -0000

On Tue, Nov 13, 2012 at 5:01 PM, Michael Thomas  wrote:
> On 11/13/2012 12:24 AM, Brian E Carpenter wrote:
>>
>> On 12/11/2012 17:33, Mark Townsley wrote:
>>>
>>> Nice to see a constructive thread with suggested text for the editors o=
f
>>> the homenet arch, thank you.
>>>
>>> I'm concerned with any "issue a warning" type suggestions though. We ar=
e
>>> working hard to develop automatic configuration that assumes there is n=
o
>>> operator involved here. If there is no operator to configure our protoc=
ols,
>>> there is no operator to issue a warning to either.
>>>
>>> If the homenet runs out of /64s to hand out, and we recommend not to
>>> route /128s, bridge, NPTv6, etc... then the final option is, simply,  "=
no
>>> IPv6" for that given link. Falling back to the user to try and interpre=
t a
>>> cryptic message about IPv6 prefixes is simply not a realistic option fo=
r the
>>> protocols we are working on here.
>>
>> Which is a FAIL if there are any v6-only devices around. Ultimately I
>> don't see
>> how you can avoid some kind of warning to the user, even if it's the
>> equivalent
>> of the beeping from a smoke detector whose battery is fading.
>>
>
> I too am bothered quite a lot by the notion that nothing will ever go wro=
ng
> therefore we don't have to plan for it. With the complexity of networks
> being
> contemplated here, I think the likelihood that they will self-organize an=
d
> just
> "work" completely unattended in all/most cases asymptotically approaches
> zero.
> We simply have no empirical evidence that any such thing has ever been do=
ne,
> and plenty of evidence that even given huge amounts of networking clue th=
at
> awful things happen awfully often.
>
> What really bothers me is that routers are treated as "others": the notio=
n
> that
> normal people are not just expected to have no clue about networking, but
> that they should be actively prevented from gaining clue by interacting w=
ith
> their infrastructure. I really think that's wrongheaded. While I think th=
at
> a
> beeping box is a horrible idea, I wouldn't be adverse to my box, say,
> sending
> me email alerting me to what is wrong, and how I might fix it. There are
> probably
> many other ways to deal with this too, and the problem isn't limited to
> routers
> but all headless boxen -- though routers may have some unique properties.

+1

One of the innovations in cerowrt is that it includes a mini-jabber
server, to which a given user could subscribe, for critical messages.

> Mike
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html

From mark@townsley.net  Tue Nov 13 09:22:37 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30E521F86A2 for ; Tue, 13 Nov 2012 09:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.166
X-Spam-Level: 
X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+5gIzE5QF9u for ; Tue, 13 Nov 2012 09:22:35 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFBD21F8484 for ; Tue, 13 Nov 2012 09:22:32 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so1515302eek.31 for ; Tue, 13 Nov 2012 09:22:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CSAbA2DDYZHHoo5xdw2dJaAT0k/FbWh7ssc1c1ENjyw=; b=V8LDZyNmjqDI9qP92lOw1cV8F8q6sF/Z+aps9ObzSPFGWhJa2d8t0Wv2RovZ9RTNW+ jABkrLvcASJVREvjdnkQg2B1y2Rk+EXFF+hE+HMJWSbtTSp5TIdyh4RAPldlk3DWS16f PKvi5I0z3up6CLuIWd9CelnjOGzHO6LuEGrNmcqbY5MOuftPqKCHyiJTghpC7v/nOywX h//pN7ancdn9wczPs+XY/zA/Qzaxadi+TLwKuYgcFeTcnh63hCr4E/W1zQ1yG+US5C5R H1zS9pifpM4O4hUI7Mg/QIWigLOlSG2DaR01B3+6fzCBeWpgQzyI7V4KNuFwqgNoRP1j a8zA==
Received: by 10.14.205.65 with SMTP id i41mr71728168eeo.2.1352827347066; Tue, 13 Nov 2012 09:22:27 -0800 (PST)
Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id f2sm23807248eep.2.2012.11.13.09.22.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 09:22:22 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 13 Nov 2012 18:22:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com> 
To: Dave Taht 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQlJSbS1bof6Uoxa02jEGACeuA/2znYSVyYkEvb/X/ID/gpfZQNxqU+GZPEAaS00r6XmimD2
Cc: Hans Liu , homenet@ietf.org, Michael Thomas , Mattia Rossi 
Subject: Re: [homenet] When things go wrong on your homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 17:22:37 -0000

On Nov 13, 2012, at 5:27 PM, Dave Taht wrote:

> On Tue, Nov 13, 2012 at 5:01 PM, Michael Thomas  wrote:
>> On 11/13/2012 12:24 AM, Brian E Carpenter wrote:
>>>=20
>>> On 12/11/2012 17:33, Mark Townsley wrote:
>>>>=20
>>>> Nice to see a constructive thread with suggested text for the =
editors of
>>>> the homenet arch, thank you.
>>>>=20
>>>> I'm concerned with any "issue a warning" type suggestions though. =
We are
>>>> working hard to develop automatic configuration that assumes there =
is no
>>>> operator involved here. If there is no operator to configure our =
protocols,
>>>> there is no operator to issue a warning to either.
>>>>=20
>>>> If the homenet runs out of /64s to hand out, and we recommend not =
to
>>>> route /128s, bridge, NPTv6, etc... then the final option is, =
simply,  "no
>>>> IPv6" for that given link. Falling back to the user to try and =
interpret a
>>>> cryptic message about IPv6 prefixes is simply not a realistic =
option for the
>>>> protocols we are working on here.
>>>=20
>>> Which is a FAIL if there are any v6-only devices around. Ultimately =
I
>>> don't see
>>> how you can avoid some kind of warning to the user, even if it's the
>>> equivalent
>>> of the beeping from a smoke detector whose battery is fading.
>>>=20
>>=20
>> I too am bothered quite a lot by the notion that nothing will ever go =
wrong
>> therefore we don't have to plan for it. With the complexity of =
networks
>> being
>> contemplated here, I think the likelihood that they will =
self-organize and
>> just
>> "work" completely unattended in all/most cases asymptotically =
approaches
>> zero.
>> We simply have no empirical evidence that any such thing has ever =
been done,
>> and plenty of evidence that even given huge amounts of networking =
clue that
>> awful things happen awfully often.
>>=20
>> What really bothers me is that routers are treated as "others": the =
notion
>> that
>> normal people are not just expected to have no clue about networking, =
but
>> that they should be actively prevented from gaining clue by =
interacting with
>> their infrastructure. I really think that's wrongheaded. While I =
think that
>> a
>> beeping box is a horrible idea, I wouldn't be adverse to my box, say,
>> sending
>> me email alerting me to what is wrong, and how I might fix it. There =
are
>> probably
>> many other ways to deal with this too, and the problem isn't limited =
to
>> routers
>> but all headless boxen -- though routers may have some unique =
properties.
>=20
> +1
>=20
> One of the innovations in cerowrt is that it includes a mini-jabber
> server, to which a given user could subscribe, for critical messages.

My mother doesn't know how to subscribe to jabber. You might reach her =
by having the router be her friend and sending a status update via =
facebook though.

I'm not against next-gen management interfaces, or sending messages or =
giving config knobs to users that understand what they mean. I think =
some of the new products that let you manage your home router from your =
iphone or android device are fantastic for the average user. When a =
guest came to my house recently, I pushed a few buttons on my iPhone =
which sent him a text message with all he needed to connect to the guest =
SSID. I could have let him take a picture of a QR code on my iPhone as =
well. Or tapped his NFC compliant device with a little card that came =
with the router. Or pressed two buttons. There are all sorts of ways to =
configure a router these days. All good.

But remember we're just one layer here. If each and every thing a router =
did thought it was so self-important that it could communicate with the =
user whenever it liked, imagine how much SPAM that might produce. Do you =
remember some of the cryptic dialog boxes you used to get from PC =
software 10 years ago? True story: I once got flooded with emails from =
random America Online users all over the world because the company that =
wrote the AOL networking stack that came on the AOL CD-ROMs threw up a =
dialog box with L2TP in the message. At the time, when you typed L2TP =
into the AOL search engine, you got the RFC and my email address. People =
sent me email asking why their AOL wasn't working.=20

Each and every part of the router must do everything it can to work =
without bugging the user. it's enough work to bother them for the =
*really* important stuff like "do I let this device on the network?", =
"do I allow connectivity with my neighbor", etc. =20

- Mark

>=20
>> Mike
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20
>=20
>=20
> --=20
> Dave T=E4ht
>=20
> Fixing bufferbloat with cerowrt: =
http://www.teklibre.com/cerowrt/subscribe.html


From mellon@fugue.com  Tue Nov 13 10:17:02 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56921F864D for ; Tue, 13 Nov 2012 10:17:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHrAcOzCxCRU for ; Tue, 13 Nov 2012 10:17:01 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 09CFC21F865B for ; Tue, 13 Nov 2012 10:17:01 -0800 (PST)
Received: from [IPv6:2600:100c:b01e:ed18:c85:68c6:b4d7:f23] (unknown [IPv6:2600:100c:b01e:ed18:c85:68c6:b4d7:f23]) by toccata.fugue.com (Postfix) with ESMTPSA id 4A0FD2380435; Tue, 13 Nov 2012 13:16:55 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: <50A26C40.8020201@gmail.com>
Date: Tue, 13 Nov 2012 12:16:53 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>		, <509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>  <50A26C40.8020201@gmail.com>
To: Mattia Rossi 
X-Mailer: Apple Mail (2.1499)
Cc: Hans Liu , Mark Townsley , homenet@ietf.org
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 18:17:02 -0000

On Nov 13, 2012, at 9:50 AM, Mattia Rossi =
 wrote:
> I still like the idea of a led which is red if no prefix could be =
received, orange if a /64 has been assigned, and a prefix has been =
requested from a downstream router (no prefix for the downstream =
router), and green if a prefix < /64 has been assigned and a prefix has =
been requested from a downstream router and successfully provided.
> This is like the leds on the smoke detector, which start blinking once =
the battery level is low. They signal a problem, but it's up to the user =
whether to ignore it, or to fix it.

I've got no argument with a notification mechanism like that, as long as =
we provide a clean mechanism for dealing with the case where the ISP =
doesn't provide as many bits of prefix as we need.



From rturner@amalfisystems.com  Tue Nov 13 10:28:16 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923AB21F8639 for ; Tue, 13 Nov 2012 10:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDfSoZpJ5isb for ; Tue, 13 Nov 2012 10:28:15 -0800 (PST)
Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9791B21F861F for ; Tue, 13 Nov 2012 10:28:15 -0800 (PST)
Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qADISEFE030748 for ; Tue, 13 Nov 2012 13:28:14 -0500
Received: (qmail 27883 invoked by uid 0); 13 Nov 2012 18:28:12 -0000
Received: from unknown (HELO ?192.168.1.104?) (98.151.18.90) by 0 with ESMTPS (AES128-SHA encrypted); 13 Nov 2012 18:28:12 -0000
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Randy Turner 
In-Reply-To: <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>
Date: Tue, 13 Nov 2012 10:28:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>
To: homenet@ietf.org
X-Mailer: Apple Mail (2.1499)
Subject: Re: [homenet] When things go wrong on your homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 18:28:16 -0000

Given the "complexity" of a potential home net, a complexity that is =
often alluded to on the mail list (including below), there will no doubt =
be "policy" that has to be introduced - a policy language or facility =
that can be described or communicated by an end user, preferably without =
technical jargon.  This policy language, or "facility" could also offer =
options for how the user(s) of the home net would want to be notified in =
the event of any exceptions.

Randy

On Nov 13, 2012, at 9:22 AM, Mark Townsley  wrote:

>=20
> On Nov 13, 2012, at 5:27 PM, Dave Taht wrote:
>=20
>> On Tue, Nov 13, 2012 at 5:01 PM, Michael Thomas  =
wrote:
>>> On 11/13/2012 12:24 AM, Brian E Carpenter wrote:
>>>>=20
>>>> On 12/11/2012 17:33, Mark Townsley wrote:
>>>>>=20
>>>>> Nice to see a constructive thread with suggested text for the =
editors of
>>>>> the homenet arch, thank you.
>>>>>=20
>>>>> I'm concerned with any "issue a warning" type suggestions though. =
We are
>>>>> working hard to develop automatic configuration that assumes there =
is no
>>>>> operator involved here. If there is no operator to configure our =
protocols,
>>>>> there is no operator to issue a warning to either.
>>>>>=20
>>>>> If the homenet runs out of /64s to hand out, and we recommend not =
to
>>>>> route /128s, bridge, NPTv6, etc... then the final option is, =
simply,  "no
>>>>> IPv6" for that given link. Falling back to the user to try and =
interpret a
>>>>> cryptic message about IPv6 prefixes is simply not a realistic =
option for the
>>>>> protocols we are working on here.
>>>>=20
>>>> Which is a FAIL if there are any v6-only devices around. Ultimately =
I
>>>> don't see
>>>> how you can avoid some kind of warning to the user, even if it's =
the
>>>> equivalent
>>>> of the beeping from a smoke detector whose battery is fading.
>>>>=20
>>>=20
>>> I too am bothered quite a lot by the notion that nothing will ever =
go wrong
>>> therefore we don't have to plan for it. With the complexity of =
networks
>>> being
>>> contemplated here, I think the likelihood that they will =
self-organize and
>>> just
>>> "work" completely unattended in all/most cases asymptotically =
approaches
>>> zero.
>>> We simply have no empirical evidence that any such thing has ever =
been done,
>>> and plenty of evidence that even given huge amounts of networking =
clue that
>>> awful things happen awfully often.
>>>=20
>>> What really bothers me is that routers are treated as "others": the =
notion
>>> that
>>> normal people are not just expected to have no clue about =
networking, but
>>> that they should be actively prevented from gaining clue by =
interacting with
>>> their infrastructure. I really think that's wrongheaded. While I =
think that
>>> a
>>> beeping box is a horrible idea, I wouldn't be adverse to my box, =
say,
>>> sending
>>> me email alerting me to what is wrong, and how I might fix it. There =
are
>>> probably
>>> many other ways to deal with this too, and the problem isn't limited =
to
>>> routers
>>> but all headless boxen -- though routers may have some unique =
properties.
>>=20
>> +1
>>=20
>> One of the innovations in cerowrt is that it includes a mini-jabber
>> server, to which a given user could subscribe, for critical messages.
>=20
> My mother doesn't know how to subscribe to jabber. You might reach her =
by having the router be her friend and sending a status update via =
facebook though.
>=20
> I'm not against next-gen management interfaces, or sending messages or =
giving config knobs to users that understand what they mean. I think =
some of the new products that let you manage your home router from your =
iphone or android device are fantastic for the average user. When a =
guest came to my house recently, I pushed a few buttons on my iPhone =
which sent him a text message with all he needed to connect to the guest =
SSID. I could have let him take a picture of a QR code on my iPhone as =
well. Or tapped his NFC compliant device with a little card that came =
with the router. Or pressed two buttons. There are all sorts of ways to =
configure a router these days. All good.
>=20
> But remember we're just one layer here. If each and every thing a =
router did thought it was so self-important that it could communicate =
with the user whenever it liked, imagine how much SPAM that might =
produce. Do you remember some of the cryptic dialog boxes you used to =
get from PC software 10 years ago? True story: I once got flooded with =
emails from random America Online users all over the world because the =
company that wrote the AOL networking stack that came on the AOL CD-ROMs =
threw up a dialog box with L2TP in the message. At the time, when you =
typed L2TP into the AOL search engine, you got the RFC and my email =
address. People sent me email asking why their AOL wasn't working.=20
>=20
> Each and every part of the router must do everything it can to work =
without bugging the user. it's enough work to bother them for the =
*really* important stuff like "do I let this device on the network?", =
"do I allow connectivity with my neighbor", etc. =20
>=20
> - Mark
>=20
>>=20
>>> Mike
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>=20
>>=20
>>=20
>> --=20
>> Dave T=E4ht
>>=20
>> Fixing bufferbloat with cerowrt: =
http://www.teklibre.com/cerowrt/subscribe.html
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>=20


From rturner@amalfisystems.com  Tue Nov 13 10:33:00 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8A021F867C for ; Tue, 13 Nov 2012 10:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w7H7jHV6ZZP for ; Tue, 13 Nov 2012 10:32:59 -0800 (PST)
Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1028B21F8660 for ; Tue, 13 Nov 2012 10:32:59 -0800 (PST)
Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qADIWvjJ003345 for ; Tue, 13 Nov 2012 13:32:57 -0500
Received: (qmail 19085 invoked by uid 0); 13 Nov 2012 18:32:57 -0000
Received: from unknown (HELO ?192.168.1.104?) (98.151.18.90) by 0 with ESMTPS (AES128-SHA encrypted); 13 Nov 2012 18:32:57 -0000
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Randy Turner 
In-Reply-To: <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>
Date: Tue, 13 Nov 2012 10:33:06 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>
To: homenet@ietf.org
X-Mailer: Apple Mail (2.1499)
Subject: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 18:33:00 -0000

Hi All,

I've been away from the list for awhile, and am trying to catch up -- is =
there a reference or quick explanation as to why a "/64" assigned to a =
home network is considered to be potentially "constrained" somehow ?

Thanks,
Randy

On Nov 13, 2012, at 10:28 AM, Randy Turner  =
wrote:

>=20
> Given the "complexity" of a potential home net, a complexity that is =
often alluded to on the mail list (including below), there will no doubt =
be "policy" that has to be introduced - a policy language or facility =
that can be described or communicated by an end user, preferably without =
technical jargon.  This policy language, or "facility" could also offer =
options for how the user(s) of the home net would want to be notified in =
the event of any exceptions.
>=20
> Randy
>=20
> On Nov 13, 2012, at 9:22 AM, Mark Townsley  wrote:
>=20
>>=20
>> On Nov 13, 2012, at 5:27 PM, Dave Taht wrote:
>>=20
>>> On Tue, Nov 13, 2012 at 5:01 PM, Michael Thomas  =
wrote:
>>>> On 11/13/2012 12:24 AM, Brian E Carpenter wrote:
>>>>>=20
>>>>> On 12/11/2012 17:33, Mark Townsley wrote:
>>>>>>=20
>>>>>> Nice to see a constructive thread with suggested text for the =
editors of
>>>>>> the homenet arch, thank you.
>>>>>>=20
>>>>>> I'm concerned with any "issue a warning" type suggestions though. =
We are
>>>>>> working hard to develop automatic configuration that assumes =
there is no
>>>>>> operator involved here. If there is no operator to configure our =
protocols,
>>>>>> there is no operator to issue a warning to either.
>>>>>>=20
>>>>>> If the homenet runs out of /64s to hand out, and we recommend not =
to
>>>>>> route /128s, bridge, NPTv6, etc... then the final option is, =
simply,  "no
>>>>>> IPv6" for that given link. Falling back to the user to try and =
interpret a
>>>>>> cryptic message about IPv6 prefixes is simply not a realistic =
option for the
>>>>>> protocols we are working on here.
>>>>>=20
>>>>> Which is a FAIL if there are any v6-only devices around. =
Ultimately I
>>>>> don't see
>>>>> how you can avoid some kind of warning to the user, even if it's =
the
>>>>> equivalent
>>>>> of the beeping from a smoke detector whose battery is fading.
>>>>>=20
>>>>=20
>>>> I too am bothered quite a lot by the notion that nothing will ever =
go wrong
>>>> therefore we don't have to plan for it. With the complexity of =
networks
>>>> being
>>>> contemplated here, I think the likelihood that they will =
self-organize and
>>>> just
>>>> "work" completely unattended in all/most cases asymptotically =
approaches
>>>> zero.
>>>> We simply have no empirical evidence that any such thing has ever =
been done,
>>>> and plenty of evidence that even given huge amounts of networking =
clue that
>>>> awful things happen awfully often.
>>>>=20
>>>> What really bothers me is that routers are treated as "others": the =
notion
>>>> that
>>>> normal people are not just expected to have no clue about =
networking, but
>>>> that they should be actively prevented from gaining clue by =
interacting with
>>>> their infrastructure. I really think that's wrongheaded. While I =
think that
>>>> a
>>>> beeping box is a horrible idea, I wouldn't be adverse to my box, =
say,
>>>> sending
>>>> me email alerting me to what is wrong, and how I might fix it. =
There are
>>>> probably
>>>> many other ways to deal with this too, and the problem isn't =
limited to
>>>> routers
>>>> but all headless boxen -- though routers may have some unique =
properties.
>>>=20
>>> +1
>>>=20
>>> One of the innovations in cerowrt is that it includes a mini-jabber
>>> server, to which a given user could subscribe, for critical =
messages.
>>=20
>> My mother doesn't know how to subscribe to jabber. You might reach =
her by having the router be her friend and sending a status update via =
facebook though.
>>=20
>> I'm not against next-gen management interfaces, or sending messages =
or giving config knobs to users that understand what they mean. I think =
some of the new products that let you manage your home router from your =
iphone or android device are fantastic for the average user. When a =
guest came to my house recently, I pushed a few buttons on my iPhone =
which sent him a text message with all he needed to connect to the guest =
SSID. I could have let him take a picture of a QR code on my iPhone as =
well. Or tapped his NFC compliant device with a little card that came =
with the router. Or pressed two buttons. There are all sorts of ways to =
configure a router these days. All good.
>>=20
>> But remember we're just one layer here. If each and every thing a =
router did thought it was so self-important that it could communicate =
with the user whenever it liked, imagine how much SPAM that might =
produce. Do you remember some of the cryptic dialog boxes you used to =
get from PC software 10 years ago? True story: I once got flooded with =
emails from random America Online users all over the world because the =
company that wrote the AOL networking stack that came on the AOL CD-ROMs =
threw up a dialog box with L2TP in the message. At the time, when you =
typed L2TP into the AOL search engine, you got the RFC and my email =
address. People sent me email asking why their AOL wasn't working.=20
>>=20
>> Each and every part of the router must do everything it can to work =
without bugging the user. it's enough work to bother them for the =
*really* important stuff like "do I let this device on the network?", =
"do I allow connectivity with my neighbor", etc. =20
>>=20
>> - Mark
>>=20
>>>=20
>>>> Mike
>>>> _______________________________________________
>>>> homenet mailing list
>>>> homenet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Dave T=E4ht
>>>=20
>>> Fixing bufferbloat with cerowrt: =
http://www.teklibre.com/cerowrt/subscribe.html
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>=20
>=20


From gettysjim@gmail.com  Tue Nov 13 11:04:42 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF19321F868F for ; Tue, 13 Nov 2012 11:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGM175jGNVq2 for ; Tue, 13 Nov 2012 11:04:42 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCC8921F8683 for ; Tue, 13 Nov 2012 11:04:41 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fl11so8551919vcb.31 for ; Tue, 13 Nov 2012 11:04:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=XJeBCxGHIn3M8MqvF3/oRL6+ixMzVfxQLL7IoAbV8qY=; b=ZB2zZnRyXHluXFfo/K51rYHVKFgVw2YlF/eqde1R4lvysUuW6dO+gHF65FXgRPjQLP AVkc6L5RezaZXZEG2XN9nuuzWyJiUf27yuCHNcrY8XF6wdoRUuYkOxj/87RnT/vgGiRq A3aKl3cTW/OJe6Lj1inBmzY/Vhr0kWZFMyW/1LrNY2eiz2r75/7PC5CQVJQeL3WqM6Kx nMfxIsgYbJrGz/wItCOTfWwjlUqyQi6Uc33B2AFo80kzxebzM2hEplCTNIbM1IX77JW2 yfyxuqGKWDpA6ssVhwmL2MseMaZMcUfp2txdU5AXIpATU89oo8E677N+M2dM7PJei7dS cAKA==
MIME-Version: 1.0
Received: by 10.52.30.39 with SMTP id p7mr29851566vdh.16.1352833478104; Tue, 13 Nov 2012 11:04:38 -0800 (PST)
Sender: gettysjim@gmail.com
Received: by 10.58.151.202 with HTTP; Tue, 13 Nov 2012 11:04:38 -0800 (PST)
Date: Tue, 13 Nov 2012 14:04:38 -0500
X-Google-Sender-Auth: RU3tHTc6U8p2HWCh2m-X2Ar6wek
Message-ID: 
From: Jim Gettys 
To: "homenet@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf3079bebae7172704ce65169b
Subject: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 19:04:43 -0000

--20cf3079bebae7172704ce65169b
Content-Type: text/plain; charset=ISO-8859-1

I've been watching the discussion about recursive DHCPv6-PD with more than
a little discomfort; I did not want to throw this bomb until the issue had
been discussed in depth (as prefix delegation is a problem we must solve).

The hardest problem I've ever had to debug in my home network (by far) was
a rogue DHCP server, which occasionally would give me a bad address.  It
was located on a tiny, size of a deck of cards, VOIP box I was no longer
using. It being on a slow processor, my main DHCP server responded much
faster, so it was a very intermittent failure, solved only by perusal of
logs, wireshark, lookup into the MAC address to vendor assignments, and
then guessing which device in my house it might be.  This is well beyond
the usual home user, at the edge of what I am capable of (I'm primarily a
designer of application network protocols, not a true 'friend of the
packet').  I dare say that most ISP's could not have debugged the problem,
even if they had access to my network (nor do I want them to have to have
access).

So the recursive DHCP-PD scheme strikes me as something possibly very
fragile. I really, really don't want to repeat the experience I had with
having extra DHCP servers, and I would guess few ISP's do either.

It seems to me much more robust to flood the key configuration information
(prefixes, DNS, NTP, and the like) via a protocol that is really designed
for the job (whether specifically for configuration, ie. ahcp
http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/, or via the hacks
on routing protocols like Ari has done with OSPF).


What is more, this configuration information should be revocable; we don't
want one upstream provider to induce problems in service to the other.

I think I goal for Homenet should be/must be robustness, and "hotplug".
 You should be able to plug in new devices and have them "just work"; that
includes networks, whether ISP networks or not.  Telling a home user to
replug all their devices isn't an option. That I often have to do this with
my cable modem and home router (and then possibly clients), I see as a
failure already happening.

We should judge alternative proposals by this touchstone.
                              - Jim

--20cf3079bebae7172704ce65169b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I've been watching the discussion about recursive DHCPv6-PD with more t=
han a little discomfort; I did not want to throw this bomb until the issue =
had been discussed in depth (as prefix delegation is a problem we must solv=
e).


The hardest problem I've ever had to debug in my home ne=
twork (by far) was a rogue DHCP server, which occasionally would give me a =
bad address. =A0It was located on a tiny, size of a deck of cards, VOIP box=
 I was no longer using. It being on a slow processor, my main DHCP server r=
esponded much faster, so it was a very intermittent failure, solved only by=
 perusal of logs, wireshark, lookup into the MAC address to vendor assignme=
nts, and then guessing which device in my house it might be. =A0This is wel=
l beyond the usual home user, at the edge of what I am capable of (I'm =
primarily a designer of application network protocols, not a true 'frie=
nd of the packet'). =A0I dare say that most ISP's could not have de=
bugged the problem, even if they had access to my network (nor do I want th=
em to have to have access).



So the recursive DHCP-PD scheme strikes me as something=
 possibly very fragile. I really, really don't want to repeat the exper=
ience I had with having extra DHCP servers, and I would guess few ISP's=
 do either.



It seems to me much more robust to flood the key config=
uration information (prefixes, DNS, NTP, and the like) via a protocol that =
is really designed for the job (whether specifically for configuration, ie.=
 ahcp=A0http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/, or via the =
hacks on routing protocols like Ari has done with OSPF). =A0

=A0

What is more, this configuration informa=
tion should be revocable; we don't want one upstream provider to induce=
 problems in service to the other.

I think I goal =
for Homenet should be/must be robustness, and "hotplug". =A0You s=
hould be able to plug in new devices and have them "just work"; t=
hat includes networks, whether ISP networks or not. =A0Telling a home user =
to replug all their devices isn't an option. That I often have to do th=
is with my cable modem and home router (and then possibly clients), I see a=
s a failure already happening.



We should judge alternative proposals by this touchston=
e.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - =
Jim



--20cf3079bebae7172704ce65169b--

From simon@thekelleys.org.uk  Tue Nov 13 12:19:34 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D252321F8650 for ; Tue, 13 Nov 2012 12:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPEXW4vmR8wX for ; Tue, 13 Nov 2012 12:19:34 -0800 (PST)
Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDD721F864D for ; Tue, 13 Nov 2012 12:19:34 -0800 (PST)
Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:55185 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TYMxB-0004z8-DN for homenet@ietf.org; Tue, 13 Nov 2012 20:19:33 +0000
Received: from spike.thekelleys.org.uk ([192.168.0.193]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TYMx8-0005Rz-UI for homenet@ietf.org; Tue, 13 Nov 2012 20:19:23 +0000
Message-ID: <50A2AB4A.3070506@thekelleys.org.uk>
Date: Tue, 13 Nov 2012 20:19:22 +0000
From: Simon Kelley 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: homenet@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD	discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 20:19:34 -0000

On 13/11/12 19:04, Jim Gettys wrote:

>
> So the recursive DHCP-PD scheme strikes me as something possibly very
> fragile. I really, really don't want to repeat the experience I had with
> having extra DHCP servers, and I would guess few ISP's do either.
>
> It seems to me much more robust to flood the key configuration information
> (prefixes, DNS, NTP, and the like) via a protocol that is really designed
> for the job (whether specifically for configuration, ie. ahcp
> http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/, or via the hacks
> on routing protocols like Ari has done with OSPF).

Given that hosts are going to want to talk RA or DHCPv6, at least 
initially, one option down this route has the flood include the unicast 
address of a single, centralised DHCPv6 server, and routers run 
DHCP-relay agents which forward to that address. That gives you DHCPv6 
functionality without recursive-PD complications. It also eliminates the 
problems of distributing the available prefixes as they traverse PD 
chains. The one-and-only DHCP server knows about all the prefixes 
delegated from the ISP and the relays know which particular prefix has 
been given to the local router by the routing protocol or AHCP.

Simon.



From simon@thekelleys.org.uk  Tue Nov 13 12:35:58 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48CD21F853C for ; Tue, 13 Nov 2012 12:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM1PJYpRAfC4 for ; Tue, 13 Nov 2012 12:35:58 -0800 (PST)
Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 3547421F849A for ; Tue, 13 Nov 2012 12:35:58 -0800 (PST)
Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:55208 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TYNDB-000537-D8 for homenet@ietf.org; Tue, 13 Nov 2012 20:35:57 +0000
Received: from spike.thekelleys.org.uk ([192.168.0.193]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TYNDA-0005sz-QY for homenet@ietf.org; Tue, 13 Nov 2012 20:35:56 +0000
Message-ID: <50A2AF2C.9000601@thekelleys.org.uk>
Date: Tue, 13 Nov 2012 20:35:56 +0000
From: Simon Kelley 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: homenet@ietf.org
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>
In-Reply-To: <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 20:35:58 -0000

On 13/11/12 18:33, Randy Turner wrote:
>
> Hi All,
>
> I've been away from the list for awhile, and am trying to catch up --
> is there a reference or quick explanation as to why a "/64" assigned
> to a home network is considered to be potentially "constrained"
> somehow ?
>


Because no IPv6 network can be smaller than /64 and have stateless 
autoconfiguration work. To have routed subnets in the homenet requires 
one /64 prefix per subnet, and a /64 prefix cannot be subnetted - it is 
already the smallest legal subnet.


Simon.



From victor.kuarsingh@gmail.com  Tue Nov 13 12:48:48 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0603021F8562 for ; Tue, 13 Nov 2012 12:48:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level: 
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwbUfMLclXsl for ; Tue, 13 Nov 2012 12:48:47 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C20E321F84C8 for ; Tue, 13 Nov 2012 12:48:46 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so2763885lbk.31 for ; Tue, 13 Nov 2012 12:48:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PuZZ4MfgBz5ZvmkiraFi4XVTGSL3u4dK5T/GbnTnIMc=; b=yOFg9a1rwO31o1amhvn1cvs47hG5vr4RotBOE3ubE3VPqDSZaU0k9G5RB45iFsDgXf tZVsAsr6MCxzcJlk8/W6Si+Ni9HVkHN3R7S01vbdZAIRz78SJ5wcQjK9ZScVs2p5jU5U gYsZbdLV/ND9PX6kybN/zwUuH6VBx2ct6mTbcAy8hDHwRCnptqm4jY6xCojTP5nJVf2Z GRbdMY3pH2rUyh1kMr6CimUuRiRZV2UXgvwU6ZIKJs99NogjpMQ3lkbVoER7/FGgO9HW vkz5y7xlwXUi6qvWZAZIf+apTbWRgG3X6lzVw4+jmW3ki6wTLZWj2BJsoUCwrM8G5YEs qMLQ==
MIME-Version: 1.0
Received: by 10.152.109.145 with SMTP id hs17mr23064244lab.5.1352839724624; Tue, 13 Nov 2012 12:48:44 -0800 (PST)
Received: by 10.112.117.170 with HTTP; Tue, 13 Nov 2012 12:48:44 -0800 (PST)
In-Reply-To: <50A2AB4A.3070506@thekelleys.org.uk>
References:  <50A2AB4A.3070506@thekelleys.org.uk>
Date: Tue, 13 Nov 2012 15:48:44 -0500
Message-ID: 
From: Victor Kuarsingh 
To: Simon Kelley 
Content-Type: multipart/alternative; boundary=bcaec54ee77c396a8d04ce668be7
Cc: homenet@ietf.org
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 20:48:48 -0000

--bcaec54ee77c396a8d04ce668be7
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 13, 2012 at 3:19 PM, Simon Kelley wrote:

> On 13/11/12 19:04, Jim Gettys wrote:
>
>
>> So the recursive DHCP-PD scheme strikes me as something possibly very
>> fragile. I really, really don't want to repeat the experience I had with
>> having extra DHCP servers, and I would guess few ISP's do either.
>>
>> It seems to me much more robust to flood the key configuration information
>> (prefixes, DNS, NTP, and the like) via a protocol that is really designed
>> for the job (whether specifically for configuration, ie. ahcp
>> http://www.pps.univ-paris-**diderot.fr/~jch/software/ahcp/
>> **, or via the hacks
>> on routing protocols like Ari has done with OSPF).
>>
>
> Given that hosts are going to want to talk RA or DHCPv6, at least
> initially, one option down this route has the flood include the unicast
> address of a single, centralised DHCPv6 server, and routers run DHCP-relay
> agents which forward to that address. That gives you DHCPv6 functionality
> without recursive-PD complications. It also eliminates the problems of
> distributing the available prefixes as they traverse PD chains. The
> one-and-only DHCP server knows about all the prefixes delegated from the
> ISP and the relays know which particular prefix has been given to the local
> router by the routing protocol or AHCP.
>

I assume in your model, hosts on the various subnets will then have access
to a centralized DHCPv6 server and other hosts can still use SLACC (which
is connected to ::/64s on the local attached router's interface).  Would
the internal routers also get the ::/64 prefixes from the central DHCPv6
server (assume so)?  If yes, would they grab a PD (with hint) for a range
large enough to cover all of its' interfaces?

regards,

Victor K




>
> Simon.
>
>
> ______________________________**_________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet
>

--bcaec54ee77c396a8d04ce668be7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tue, Nov 13, 2012 at 3:19 PM, Simon K=
elley <simon@thekelleys.org.uk> wrote:


On 13/11/12 19:04, Jim Gettys wrote:







So the recursive DHCP-PD scheme strikes me as something possibly very

fragile. I really, really don't want to repeat the experience I had wit=
h

having extra DHCP servers, and I would guess few ISP's do either.



It seems to me much more robust to flood the key configuration information<=
br>
(prefixes, DNS, NTP, and the like) via a protocol that is really designed
for the job (whether specifically for configuration, ie. ahcp

http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/=
, or via the hacks

on routing protocols like Ari has done with OSPF).





Given that hosts are going to want to talk RA or DHCPv6, at least initially=
, one option down this route has the flood include the unicast address of a=
 single, centralised DHCPv6 server, and routers run DHCP-relay agents which=
 forward to that address. That gives you DHCPv6 functionality without recur=
sive-PD complications. It also eliminates the problems of distributing the =
available prefixes as they traverse PD chains. The one-and-only DHCP server=
 knows about all the prefixes delegated from the ISP and the relays know wh=
ich particular prefix has been given to the local router by the routing pro=
tocol or AHCP.



I assume in your model, hosts on the various subnets =
will then have access to a centralized DHCPv6 server and other hosts can st=
ill use SLACC (which is connected to ::/64s on the local attached router=
9;s interface).=A0 Would the internal routers also get the ::/64 prefixes f=
rom the central DHCPv6 server (assume so)?=A0 If yes, would they grab a PD =
(with hint) for a range large enough to cover all of its' interfaces?

regards,

Victor K


=A0



Simon.





_______________________________________________

homenet mailing list

homenet@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/homenet





--bcaec54ee77c396a8d04ce668be7--

From simon@thekelleys.org.uk  Tue Nov 13 13:01:13 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18021F85D9 for ; Tue, 13 Nov 2012 13:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmzOrcOcXAj8 for ; Tue, 13 Nov 2012 13:01:12 -0800 (PST)
Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id DA43E21F8525 for ; Tue, 13 Nov 2012 13:01:11 -0800 (PST)
Received: from cpc12-cmbg15-2-0-cust111.5-4.cable.virginmedia.com ([86.30.247.112]:55090 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TYNbZ-0005CH-Rb; Tue, 13 Nov 2012 21:01:09 +0000
Received: from spike.thekelleys.org.uk ([192.168.0.193]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TYNbZ-0006Yi-9d; Tue, 13 Nov 2012 21:01:09 +0000
Message-ID: <50A2B515.7010608@thekelleys.org.uk>
Date: Tue, 13 Nov 2012 21:01:09 +0000
From: Simon Kelley 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Victor Kuarsingh 
References: 	<50A2AB4A.3070506@thekelleys.org.uk> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: homenet@ietf.org
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 21:01:13 -0000

On 13/11/12 20:48, Victor Kuarsingh wrote:
> On Tue, Nov 13, 2012 at 3:19 PM, Simon Kelleywrote:

>> Given that hosts are going to want to talk RA or DHCPv6, at least
>> initially, one option down this route has the flood include the unicast
>> address of a single, centralised DHCPv6 server, and routers run DHCP-relay
>> agents which forward to that address. That gives you DHCPv6 functionality
>> without recursive-PD complications. It also eliminates the problems of
>> distributing the available prefixes as they traverse PD chains. The
>> one-and-only DHCP server knows about all the prefixes delegated from the
>> ISP and the relays know which particular prefix has been given to the local
>> router by the routing protocol or AHCP.
>>
>
> I assume in your model, hosts on the various subnets will then have access
> to a centralized DHCPv6 server and other hosts can still use SLACC (which
> is connected to ::/64s on the local attached router's interface).  Would
> the internal routers also get the ::/64 prefixes from the central DHCPv6
> server (assume so)?  If yes, would they grab a PD (with hint) for a range
> large enough to cover all of its' interfaces?


This part of the scheme is still wooly in the extreme, but my thinking 
is that DHCP-PD would _not_ be involved. The centralized server would be 
a DHCP-PD _client_ and get a set of prefixes from the ISP(s), but the 
distribution of those prefixes over the routers would be a side-effect 
of whatever configuration system generates the routing tables and 
spanning-tree for the homenet. I think I understood the OSPF guys at 
IETF as saying that OSPF could do this, and I think I understand Dave as 
saying that AHCP can do it. More details of either or both schemes would 
be very interesting to hear.

Cheers,

Simon.



From mellon@fugue.com  Tue Nov 13 13:03:23 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0521F8540 for ; Tue, 13 Nov 2012 13:03:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF-X2ahH-M3h for ; Tue, 13 Nov 2012 13:03:18 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D921F8562 for ; Tue, 13 Nov 2012 13:03:18 -0800 (PST)
Received: from [192.168.1.3] (188.sub-70-195-201.myvzw.com [70.195.201.188]) by toccata.fugue.com (Postfix) with ESMTPSA id E2CB52381725; Tue, 13 Nov 2012 16:03:16 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 13 Nov 2012 15:03:15 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Jim Gettys 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 21:03:23 -0000

On Nov 13, 2012, at 1:04 PM, Jim Gettys  wrote:
> So the recursive DHCP-PD scheme strikes me as something possibly very =
fragile. I really, really don't want to repeat the experience I had with =
having extra DHCP servers, and I would guess few ISP's do either.

It seems to me that using bad implementations as a guideline is always a =
bad idea.   We've had sites go down as a result of OSPF routing =
mistakes, so it's not the case that any of the alternatives we are =
talking about are immune to bad implementations.


From mike@mtcc.com  Tue Nov 13 13:05:55 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D461E21F8614 for ; Tue, 13 Nov 2012 13:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCDAmSZ20Bv2 for ; Tue, 13 Nov 2012 13:05:55 -0800 (PST)
Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 4A93A21F85E1 for ; Tue, 13 Nov 2012 13:05:55 -0800 (PST)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id qADL5gEc031479 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 13:05:42 -0800
Message-ID: <50A2B626.8000207@mtcc.com>
Date: Tue, 13 Nov 2012 13:05:42 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Mark Townsley 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>
In-Reply-To: <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=801; t=1352840743; x=1353704743; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20When=20things=20go=20wrong= 20on=20your=20homenet |Sender:=20 |To:=20Mark=20Townsley=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=A+cNN2Rx6+CMOImfJGAj3DqE8hf/ceRBrhwq29vKqIY=; b=Wt6AeftbfwwUARX/WRgIfuknlgBi1R119eoY5ZYQjT4WsyKj21stFpKkTA hI5/pTT5XPdEr8s/OBvMifOcqrWpjmfIxSu6iMaHkZXG0IQrHdU6opYwadYh 4FPLiWCI/nDcHhtpZh3NGAKuFY+tLrzJIC1Jox9DQ8Zoa63TrTaZI=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: Hans Liu , homenet@ietf.org, Dave Taht , Mattia Rossi 
Subject: Re: [homenet] When things go wrong on your homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 21:05:56 -0000

On 11/13/2012 09:22 AM, Mark Townsley wrote:

> Each and every part of the router must do everything it can to work without bugging the user. it's enough work to bother them for the *really* important stuff like "do I let this device on the network?", "do I allow connectivity with my neighbor", etc.
>

That and motherhood and apple pies. But then your home network melts
down. Then what?

I'll say again: we have no experience at all with mass deployment of complex
zero-touch networks. In fact, we have no experience at all with mass deployment
of anything other than flat networks with clients only. As Jim Getty's points out,
we do have some experience with accidentally complex networks with poor to
non-existent means to whip them back into submission and it's not pretty.

Mike

From jhw@apple.com  Tue Nov 13 14:47:39 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242121F866B for ; Tue, 13 Nov 2012 14:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E680OR0cVDUE for ; Tue, 13 Nov 2012 14:47:38 -0800 (PST)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC321F8518 for ; Tue, 13 Nov 2012 14:47:38 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDG00FCO79QK9Q3@mail-out.apple.com> for homenet@ietf.org; Tue, 13 Nov 2012 14:47:35 -0800 (PST)
X-AuditID: 11807134-b7fe96d000000e2b-25-50a2ce07637b
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id 0C.3A.03627.70EC2A05; Tue, 13 Nov 2012 14:47:35 -0800 (PST)
Received: from [17.193.15.79] by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDG00GX97BAJQ80@cardamom.apple.com> for homenet@ietf.org; Tue, 13 Nov 2012 14:47:35 -0800 (PST)
From: james woodyatt 
In-reply-to: <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>
Date: Tue, 13 Nov 2012 14:47:34 -0800
Message-id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>
To: Randy Turner 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FAcp8t+blGAwYHPPBbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtuTRxkLbolUrLrfwtjAeFigi5GTQ0LARKJ1z10mCFtM4sK9 9WxdjFwcQgLTmCQOnHrOCOG0MEmsfrSZGaSKWUBHovf7NyCbg4NXQE9i0v4gkLCwgKXE769P wErYBFQkvl2GGMop4Cqx/+ApVhCbRUBVYlP/bzaIMSISWz+eZoKwtSWevLsAVsMrYCMxZ84S doi9TWwSO64fAisSAdrb9vQcC8SlshIrpvYyTWAUmIXkpFkIJ81CMnYBI/MqRsGi1JzESkMT vcSCgpxUveT83E2M4NArNNnBePAn/yFGAQ5GJR5eh8ZFAUKsiWXFlbmHGCU4mJVEeC3PAoV4 UxIrq1KL8uOLSnNSiw8xSnOwKInzWq4DSgmkJ5akZqemFqQWwWSZODilGhjZ3pxaZr7moqR6 kMABtTUzCt+Jrbx1NeSg3a1Lbw/d3vb2edZfrT8hFRHvuy/ypM1eGJYq9eHMswWpi7xn7z/h cFJYjNfY5e734j9CLWn985nSThRaMQSG1y1VXrbKL+uwzzquaSoLn3IYpC3tqH7qx3X8vEdC buPZL5L/DL6v2jBtSS3LpkvrlViKMxINtZiLihMBP9CYETkCAAA=
Cc: homenet@ietf.org
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 22:47:39 -0000

On Nov 13, 2012, at 10:33 , Randy Turner  wrote:

> I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a "/64" assigned to a home network is considered to be potentially "constrained" somehow ?

Once upon a time [RFC 3177], we believed that creating a numbering plan for subscriber networks was intolerably difficult and expensive, so we thought it would be a very good idea to make sure every new subscriber of any size would a /48 delegation, which we all thought was big enough for all but the most titanic of organizations.  The idea was you'd get enough space up front that you could take your numbering plan with you if you ever moved from one provider to another.  Space was thought to be too cheap to meter, and the benefit of number plan stability across providers was thought to be beneficial.

Since then, we have discovered two things: A) service providers guard with astonishing ferocity every last number they get from their registries even when they are too cheap to meter, and B) the problem of number plan scaling is one that only people without any money have any interest in seeing solved.  Hence, we have a new recommendation from IAB [RFC 6177], which capitulates on the one-size-fits-all recommendation. It also says this in section 2:

   However, this precludes the expectation that even home sites will
   grow to support multiple subnets going forward.  Hence, it is
   strongly intended that even home sites be given multiple subnets
   worth of space, by default.  Hence, this document still recommends
   giving home sites significantly more than a single /64, but does not
   recommend that every home site be given a /48 either.

For my part, I have a hard time foreseeing how the expectation that residential sites will always have more space to assign than a single /64 subnet is even remotely reasonable.  Far too many service providers are casting into operational concrete topologies that assign only one subnet to each billable subscriber gateway.

I don't hold out much hope that much of a market will ever exist for residential networks with multiple subnets per subscriber.  I also don't hold out much hope for the kind of coordination between service providers that will permit multihomed residential sites to work well.

That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway.


--
james woodyatt 
core os networking


From victor.kuarsingh@gmail.com  Tue Nov 13 18:09:59 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A68C21F8819 for ; Tue, 13 Nov 2012 18:09:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CIIlHoAqQrB for ; Tue, 13 Nov 2012 18:09:57 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9F21F884E for ; Tue, 13 Nov 2012 18:09:56 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so13008188iec.31 for ; Tue, 13 Nov 2012 18:09:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=4ZPA5Ta4MgS57mUzfxo8cyIBgMaJwFM7Q/Bq0ejTZOI=; b=kzEOXWM4SNLh0hgwvFUn7qu8S1d/r8YJOWoARMAUStFd8zt+9au87GDpqWj/H5u3xJ BO+M02V5xhvJQvUAkAYwz771Q+gij4vz6493nuhmgQYRiwfxDebcZTbuyPMhbmcPDlkf EqJ0cvNU/1+ioIMYyG0H5F35Z+dmuEa2tQhh9A7884il0YhNCLsdgECCRcy+sJSzVz+B JQBrGuALMHMolEjxStRYekbmxAVWT69JCk/3Hzf43hGiOAKm4t1kSSBZk9noFz5ysOcY FnXt7jq+/MebFuwMbmyA1R7nMoE/FARdWervrkWdcvaDuMFAL+QOBbRLti3F0tbz5OO5 k2sg==
Received: by 10.43.97.8 with SMTP id ci8mr23297661icc.28.1352858995656; Tue, 13 Nov 2012 18:09:55 -0800 (PST)
Received: from [192.168.100.204] ([67.224.83.162]) by mx.google.com with ESMTPS id yf6sm184864igb.0.2012.11.13.18.09.53 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 18:09:54 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.10.0.110310
Date: Tue, 13 Nov 2012 21:09:46 -0500
From: Victor Kuarsingh 
To: james woodyatt , Randy Turner 
Message-ID: 
Thread-Topic: [homenet] prefix assignment on home networks
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: homenet@ietf.org
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 02:09:59 -0000

On 2012-11-13 5:47 PM, "james woodyatt"  wrote:
>
>For my part, I have a hard time foreseeing how the expectation that
>residential sites will always have more space to assign than a single /64
>subnet is even remotely reasonable.  Far too many service providers are
>casting into operational concrete topologies that assign only one subnet
>to each billable subscriber gateway.

I can't speak for all operators, but I would say most I have dealt with do
not specifically suggest that a single /64 is the target.

That said, there are current operation considerations which factors into
the present Wireless and Wireline network prefix assignments.  This has
caused situations where a single /64 is given out or made available for
now.

In the longer term, I would think that shorter prefixes would be handed
out.  There is no guarantee how large of a prefix will be provided - This
is likely an operator to operator decision (but market demand normally
dictates the eventual outcome).


>
>I don't hold out much hope that much of a market will ever exist for
>residential networks with multiple subnets per subscriber.  I also don't
>hold out much hope for the kind of coordination between service providers
>that will permit multihomed residential sites to work well.

I don't agree that operators are not considering multi-subenet home
networks.  I know of at least one which is looking at more.  As for
co-ordination between operators, I suspect this is subject to traditional
behaviours (no reason to assume character will change for IPv6)

>
>That's why it looks to me like HOMENET will eventually converge on
>specifying single /64 links behind a single residential gateway.

I personally would not like to see HOMENET confine the work to a single
/64.  I do however think the group needs to consider the fact that a
gateway MAY get a /64 (a sad, but perfectly valid PD) for any number of
reasons- therefore it needs to be considered in how the HOMENET treats the
situation.

Regards,

Victor K



>
>
>--
>james woodyatt 
>core os networking
>
>_______________________________________________
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet



From rturner@amalfisystems.com  Tue Nov 13 18:34:14 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294C621F86D1 for ; Tue, 13 Nov 2012 18:34:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y5UXzqeYRv3 for ; Tue, 13 Nov 2012 18:34:13 -0800 (PST)
Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE7321F8703 for ; Tue, 13 Nov 2012 18:34:11 -0800 (PST)
Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAE2Y8H5014262 for ; Tue, 13 Nov 2012 21:34:08 -0500
Received: (qmail 29594 invoked by uid 0); 14 Nov 2012 02:34:08 -0000
Received: from unknown (HELO ?10.8.150.56?) (107.14.25.33) by 0 with ESMTPS (AES128-SHA encrypted); 14 Nov 2012 02:34:08 -0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Randy Turner 
In-Reply-To: 
Date: Tue, 13 Nov 2012 18:34:18 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com> 
To: "homenet@ietf.org" 
X-Mailer: Apple Mail (2.1499)
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 02:34:14 -0000

I was thinking that, in an effort to reduce scope to something we can =
deal with for now, that a /64 would be big enough - and if this prefix =
is "globally available" on the internet, I think it's much more than the =
ISPs can get their heads around, at least for now.

I understand the limitations of stateless autoconfig and other =
constraints, but I would start with something like a /64, but with a =
capability that allows multiple /64 prefixes (or other method for SLAAC) =
to be added later without a forklift upgrade or re-thinking of what we =
do first.  Each home site "could" subnet this space, so we could include =
any new work on MDNSEXT or other name resolution that is decentralized =
but can cross subnets.

I don't think we would be short-changing potential uses for home net by =
taking IPv6 "baby steps" for now=85.given that the ISPs and consumer =
home networks are not even as advanced as the multi-service IPv4 home =
network business models we were trying to sell to LECs/CLECS/ISPs when I =
was at 2Wire back in 2000.

I (for one) would be thrilled if I could get an IPv6 /64 that is =
globally visible (not NAT'd) from my ISP.  It's so much more than I have =
today.

Randy


On Nov 13, 2012, at 2:47 PM, james woodyatt  wrote:

> On Nov 13, 2012, at 10:33 , Randy Turner  =
wrote:
>=20
>> I've been away from the list for awhile, and am trying to catch up -- =
is there a reference or quick explanation as to why a "/64" assigned to =
a home network is considered to be potentially "constrained" somehow ?
>=20
> Once upon a time [RFC 3177], we believed that creating a numbering =
plan for subscriber networks was intolerably difficult and expensive, so =
we thought it would be a very good idea to make sure every new =
subscriber of any size would a /48 delegation, which we all thought was =
big enough for all but the most titanic of organizations.  The idea was =
you'd get enough space up front that you could take your numbering plan =
with you if you ever moved from one provider to another.  Space was =
thought to be too cheap to meter, and the benefit of number plan =
stability across providers was thought to be beneficial.
>=20
> Since then, we have discovered two things: A) service providers guard =
with astonishing ferocity every last number they get from their =
registries even when they are too cheap to meter, and B) the problem of =
number plan scaling is one that only people without any money have any =
interest in seeing solved.  Hence, we have a new recommendation from IAB =
[RFC 6177], which capitulates on the one-size-fits-all recommendation. =
It also says this in section 2:
>=20
>   However, this precludes the expectation that even home sites will
>   grow to support multiple subnets going forward.  Hence, it is
>   strongly intended that even home sites be given multiple subnets
>   worth of space, by default.  Hence, this document still recommends
>   giving home sites significantly more than a single /64, but does not
>   recommend that every home site be given a /48 either.
>=20
> For my part, I have a hard time foreseeing how the expectation that =
residential sites will always have more space to assign than a single =
/64 subnet is even remotely reasonable.  Far too many service providers =
are casting into operational concrete topologies that assign only one =
subnet to each billable subscriber gateway.
>=20
> I don't hold out much hope that much of a market will ever exist for =
residential networks with multiple subnets per subscriber.  I also don't =
hold out much hope for the kind of coordination between service =
providers that will permit multihomed residential sites to work well.
>=20
> That's why it looks to me like HOMENET will eventually converge on =
specifying single /64 links behind a single residential gateway.
>=20
>=20
> --
> james woodyatt 
> core os networking
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>=20


From swmike@swm.pp.se  Tue Nov 13 21:20:48 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE621F846E for ; Tue, 13 Nov 2012 21:20:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRiMnR06P0KT for ; Tue, 13 Nov 2012 21:20:47 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEAC21F845E for ; Tue, 13 Nov 2012 21:20:45 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5772A9C; Wed, 14 Nov 2012 06:20:40 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4A7979A; Wed, 14 Nov 2012 06:20:40 +0100 (CET)
Date: Wed, 14 Nov 2012 06:20:40 +0100 (CET)
From: Mikael Abrahamsson 
To: james woodyatt 
In-Reply-To: 
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com> 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: Randy Turner , homenet@ietf.org
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 05:20:48 -0000

On Tue, 13 Nov 2012, james woodyatt wrote:

> For my part, I have a hard time foreseeing how the expectation that 
> residential sites will always have more space to assign than a single 
> /64 subnet is even remotely reasonable.  Far too many service providers 
> are casting into operational concrete topologies that assign only one 
> subnet to each billable subscriber gateway.

Then those need to re-think their decisions.

> I don't hold out much hope that much of a market will ever exist for 
> residential networks with multiple subnets per subscriber.  I also don't 
> hold out much hope for the kind of coordination between service 
> providers that will permit multihomed residential sites to work well.

Why do you believe we need coordination between service providers to 
permit multihomed services to work well? I thought the whole idea was to 
handle multiple upstream prefixes and make sure everything is routed to 
the correct ISP?

> That's why it looks to me like HOMENET will eventually converge on 
> specifying single /64 links behind a single residential gateway.

I hope not.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From swmike@swm.pp.se  Tue Nov 13 21:28:40 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D5B21F862E for ; Tue, 13 Nov 2012 21:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.368
X-Spam-Level: 
X-Spam-Status: No, score=-4.368 tagged_above=-999 required=5 tests=[AWL=1.881,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv3RbbIRHJow for ; Tue, 13 Nov 2012 21:28:38 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 22B0421F8625 for ; Tue, 13 Nov 2012 21:28:38 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6DAF29C; Wed, 14 Nov 2012 06:28:15 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 66E649A; Wed, 14 Nov 2012 06:28:15 +0100 (CET)
Date: Wed, 14 Nov 2012 06:28:15 +0100 (CET)
From: Mikael Abrahamsson 
To: Mattia Rossi 
In-Reply-To: <50A26C40.8020201@gmail.com>
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>  , <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>  <50A26C40.8020201@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: homenet@ietf.org
Subject: Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 05:28:40 -0000

On Tue, 13 Nov 2012, Mattia Rossi wrote:

> I still like the idea of a led which is red if no prefix could be received, 
> orange if a /64 has been assigned, and a prefix has been requested from a 
> downstream router (no prefix for the downstream router), and green if a 
> prefix < /64 has been assigned and a prefix has been requested from a 
> downstream router and successfully provided.

This sounds like a reasonable compromise. I am not a vendor manufacturer 
though, don't know the cost of this.

> This is like the leds on the smoke detector, which start blinking once the 
> battery level is low. They signal a problem, but it's up to the user whether 
> to ignore it, or to fix it.

I don't know if it's local requirements, but my smoke detectors start 
chirping once every 5 minutes or so when they're low on battery. I don't 
want my home gateway to start doing that :P

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From joelja@bogus.com  Tue Nov 13 21:30:48 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6B21F866B for ; Tue, 13 Nov 2012 21:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.474
X-Spam-Level: 
X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNNN3xXB5Wpo for ; Tue, 13 Nov 2012 21:30:47 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A30B721F847F for ; Tue, 13 Nov 2012 21:30:40 -0800 (PST)
Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAE5UavY048876 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 14 Nov 2012 05:30:37 GMT (envelope-from joelja@bogus.com)
Message-ID: <50A32C7B.7000904@bogus.com>
Date: Tue, 13 Nov 2012 21:30:35 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Mikael Abrahamsson 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 14 Nov 2012 05:30:37 +0000 (UTC)
Cc: Randy Turner , homenet@ietf.org, james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 05:30:48 -0000

On 11/13/12 9:20 PM, Mikael Abrahamsson wrote:

> Why do you believe we need coordination between service providers to 
> permit multihomed services to work well? I thought the whole idea was 
> to handle multiple upstream prefixes and make sure everything is 
> routed to the correct ISP?

If coordination is required, it's not going to work.

>> That's why it looks to me like HOMENET will eventually converge on 
>> specifying single /64 links behind a single residential gateway.
>
> I hope not.
>


From brian.e.carpenter@gmail.com  Wed Nov 14 00:17:56 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB09621F8792 for ; Wed, 14 Nov 2012 00:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.613
X-Spam-Level: 
X-Spam-Status: No, score=-101.613 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wABDvetdjMsQ for ; Wed, 14 Nov 2012 00:17:56 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56221F86B8 for ; Wed, 14 Nov 2012 00:17:55 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id u46so62680wey.31 for ; Wed, 14 Nov 2012 00:17:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VSe2oPgPWuk/+GJTmmoYLv36yTl+McYWnuxawybk6B8=; b=H6gNiJuHICMtKPNjyhte81CxahXJ/MY+epsaPEE/doM5Gg+dQHtQRTTavxWF1aVWmH VUmg3fKRTLxFnVNmn1mR828XSgXjGlUd6Zjq9pm/7+dRYBqqjge3T2iJqDCjGC9lLeWM 8IrLGRIsjWIHgrzh69COvnTe2cfcxtMgvUs0MZDadEFrAgx2mG8d/C0g+uuZ0QjBFc6Z xylVghc2s58khHD4J8e15kplo6kfKJOZ/jWcARNTzI+axOGEMyWXJQKLMqaxFbaJzBXv n1TZ30ULXDIsBWuDhOCSGydQ7wweGnCU9zHXyVGjK2Pzf7557MwQMF6+eeej0aD2bZ/X SMPQ==
Received: by 10.180.90.78 with SMTP id bu14mr24491713wib.21.1352881072989; Wed, 14 Nov 2012 00:17:52 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-218-138.as13285.net. [2.102.218.138]) by mx.google.com with ESMTPS id en20sm1282732wid.4.2012.11.14.00.17.50 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 00:17:50 -0800 (PST)
Message-ID: <50A353B1.6080600@gmail.com>
Date: Wed, 14 Nov 2012 08:17:53 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Michael Thomas 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <50A2B626.8000207@mtcc.com>
In-Reply-To: <50A2B626.8000207@mtcc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Hans Liu , homenet@ietf.org, Mark Townsley , Dave Taht , Mattia Rossi 
Subject: Re: [homenet] When things go wrong on your homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 08:17:57 -0000

On 13/11/2012 21:05, Michael Thomas wrote:
> On 11/13/2012 09:22 AM, Mark Townsley wrote:
> 
>> Each and every part of the router must do everything it can to work
>> without bugging the user. it's enough work to bother them for the
>> *really* important stuff like "do I let this device on the network?",
>> "do I allow connectivity with my neighbor", etc.
>>
> 
> That and motherhood and apple pies. But then your home network melts
> down. Then what?
> 
> I'll say again: we have no experience at all with mass deployment of
> complex
> zero-touch networks. In fact, we have no experience at all with mass
> deployment
> of anything other than flat networks with clients only. As Jim Getty's
> points out,
> we do have some experience with accidentally complex networks with poor to
> non-existent means to whip them back into submission and it's not pretty.

Right. And we're creating a new profession here: "Home Network Guru".
I think that's inevitable, and there needs to be some way of telling
the user "Call your guru".

(It's surprising what Google finds today when you type in homenet error.)

    Brian

From brian.e.carpenter@gmail.com  Wed Nov 14 01:30:58 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1438C21F8582 for ; Wed, 14 Nov 2012 01:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.526
X-Spam-Level: 
X-Spam-Status: No, score=-101.526 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-mJ6o706v6X for ; Wed, 14 Nov 2012 01:30:57 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4D821F8581 for ; Wed, 14 Nov 2012 01:30:57 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so143766eek.31 for ; Wed, 14 Nov 2012 01:30:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yoaTbB+Wyow3Y8RZRQaU4TYjbVWVpzrvdGfrRNh9Or8=; b=OJF8Qq77g2yL6xQl8t9B0td9CO4DQGwL0o2WoMQluiiymluXmsjfvoY5wQKlGw6P0X HqdhT1prYJDbJGDMsSiFnSmAHHhoLx3dgk4h3iA7zuhAuVa9lswjGlUiXqGjf89kvEY/ Syzc++IsttBMEvdIJUebT3T6GTJBtSH5Wz0L6gYFJzuoTmmNEWDKGAtD4G4vyYPPfR8P jZSW2OUzV1FLZSUcinmRoGcS0jeVI1HqSWIcCzuWoR32Md0eZH3o3BwBS9Ytob4huRwh +rDYQ3xvGvqQ2yjuypY75/mc8c/+UrPmm9Njsxdc04+kBs9nnPbcJMN2GOE+7sx1dtSd juWg==
Received: by 10.14.215.69 with SMTP id d45mr84784382eep.16.1352885456613; Wed, 14 Nov 2012 01:30:56 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-218-138.as13285.net. [2.102.218.138]) by mx.google.com with ESMTPS id k2sm28468211eep.15.2012.11.14.01.30.54 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 01:30:55 -0800 (PST)
Message-ID: <50A364D6.8090104@gmail.com>
Date: Wed, 14 Nov 2012 09:31:02 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Randy Turner 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com>
In-Reply-To: <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 09:30:58 -0000

On 14/11/2012 02:34, Randy Turner wrote:
> I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough

It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever.

    Brian

From teco@inf-net.nl  Wed Nov 14 04:08:29 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4821F21F85E1 for ; Wed, 14 Nov 2012 04:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezbLM0icPXfi for ; Wed, 14 Nov 2012 04:08:24 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0EC021F85DB for ; Wed, 14 Nov 2012 04:08:22 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so238271eek.31 for ; Wed, 14 Nov 2012 04:08:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qhHJsKBlsK2geA3EgrRETCNeIXE77G/2qm0lG3hxUGI=; b=TK8kQpHUj00YEP8gVCqibtQWf/bVD09n57UQCbq1NJtUJp5Ar38M2nxHujjM/GEF06 Nijf1eRnK8QfpFrLrQYjyqH+LwCIG/Lmnr6jp2N/QJL1//6OO1viwdGrgQV9obgeXx4t ZK1AxIksZ2t88EbFurAQW08gbwwmQ86Hg75g48ldKISlHHXow4wAq+sZY4DErpg33cmA 7/wfKsvAEqxvS+wNH/GeGDyeBK9OmTWqM3tApYi8+ByCWRXboDESTDx7C6vu7p1B2+8h dpJpdgbuCaeN5wdwpTO3X+2gfuCAJlphh3/eC6J6M6cwUEedM9XtMqGogASlWN1co19/ 8tMQ==
Received: by 10.14.194.72 with SMTP id l48mr86857786een.9.1352894901943; Wed, 14 Nov 2012 04:08:21 -0800 (PST)
Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id e7sm29236867eep.1.2012.11.14.04.08.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 04:08:21 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot 
In-Reply-To: <50A2AB4A.3070506@thekelleys.org.uk>
Date: Wed, 14 Nov 2012 13:08:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <50A2AB4A.3070506@thekelleys.org.uk>
To: Simon Kelley 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQlIKprmBQfgGfswjwIsG9uAwrRkfNco2XWC4TBOUXQL/FwB1iRQIVhL+MOzldXyP397seKd
Cc: homenet@ietf.org
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 12:08:29 -0000

Op 13 nov. 2012, om 21:19 heeft Simon Kelley het volgende geschreven:

> On 13/11/12 19:04, Jim Gettys wrote:
>=20
>>=20
>> So the recursive DHCP-PD scheme strikes me as something possibly very
>> fragile. I really, really don't want to repeat the experience I had =
with
>> having extra DHCP servers, and I would guess few ISP's do either.
>>=20
>> It seems to me much more robust to flood the key configuration =
information
>> (prefixes, DNS, NTP, and the like) via a protocol that is really =
designed
>> for the job (whether specifically for configuration, ie. ahcp
>> http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/, or via the =
hacks
>> on routing protocols like Ari has done with OSPF).
>=20
> Given that hosts are going to want to talk RA or DHCPv6, at least =
initially, one option down this route has the flood include the unicast =
address of a single, centralised DHCPv6 server, and routers run =
DHCP-relay agents which forward to that address. That gives you DHCPv6 =
functionality without recursive-PD complications. It also eliminates the =
problems of distributing the available prefixes as they traverse PD =
chains.
Right.

> The one-and-only DHCP server knows about all the prefixes delegated =
from the ISP and the relays know which particular prefix has been given =
to the local router by the routing protocol or AHCP.
I don't like a single DHCP server for multi-homed sites. This introduces =
unneeded complexity, it needs merging of information from multiple =
sources. This is completely incompatible with what MIF is doing =
(multiple provisioning domains). It also introduces an unneeded single =
point of failure. Multi-homing could be used for redundancy. Let's use a =
DHCP server for each ISP.

In cases where a single CPE router connects to multiple ISPs, it can =
take two approaches: running multiple DHCP server instances, one for =
each ISP. Or perform the problematic integration.

BRDP takes the "per provisioning domain" approach, where each =
provisioning domain is presented with a border router address (generated =
form provided prefix), with prefix length. Problem solved :-).=20

Teco

>=20
> Simon.
>=20
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From simon@thekelleys.org.uk  Wed Nov 14 05:31:20 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55AB21F85C7 for ; Wed, 14 Nov 2012 05:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H8w81Qrj67h for ; Wed, 14 Nov 2012 05:31:20 -0800 (PST)
Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 130DB21F857A for ; Wed, 14 Nov 2012 05:31:20 -0800 (PST)
Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:56231 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TYd3l-0000lg-CH for homenet@ietf.org; Wed, 14 Nov 2012 13:31:17 +0000
Received: from guest-193-062-204-116.wtgc.org ([193.62.204.116]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TYd3i-0006Kx-Ey for homenet@ietf.org; Wed, 14 Nov 2012 13:31:14 +0000
Message-ID: <50A39D19.6010708@thekelleys.org.uk>
Date: Wed, 14 Nov 2012 13:31:05 +0000
From: Simon Kelley 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: homenet@ietf.org
References:  <50A2AB4A.3070506@thekelleys.org.uk> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 13:31:20 -0000

On 14/11/12 12:08, Teco Boot wrote:

> 
>> The one-and-only DHCP server knows about all the prefixes delegated
>> from the ISP and the relays know which particular prefix has been
>> given to the local router by the routing protocol or AHCP.
> I don't like a single DHCP server for multi-homed sites. This
> introduces unneeded complexity, it needs merging of information from
> multiple sources. This is completely incompatible with what MIF is
> doing (multiple provisioning domains). It also introduces an unneeded
> single point of failure. Multi-homing could be used for redundancy.
> Let's use a DHCP server for each ISP.
> 
> In cases where a single CPE router connects to multiple ISPs, it can
> take two approaches: running multiple DHCP server instances, one for
> each ISP. Or perform the problematic integration.
> 
> BRDP takes the "per provisioning domain" approach, where each
> provisioning domain is presented with a border router address
> (generated form provided prefix), with prefix length. Problem solved
> :-).

OK. This raises some questions about DHCPv6 to which I don't know the
answers. I hope Ted or someone else who was involved in the standard can
answer.


Simplest case first. Client and server on same link (in the RFC3315
definition of link) the server has an interface on the link which has
multiple addresses with different prefixes, and it is configured to
assign addresses on each of those prefixes. The client is unconfigured
except for a link-local address. How does the client create a SOLICIT
message which causes the server to reply with an ADVERTISE which offers
the client an address with each of the prefixes ? The client doesn't
know how many prefixes are available.

Next case. The same as above but the SOLICIT transits via a relay. The
relay can only insert one link address in the encapsulation, does the
server have to know which prefixes share links so that it can determine
which other prefixes are on the same link and reduce the problem to the
case above?

Next case. This speaks to Teco's suggestion. The same link with multiple
prefixes, directly connected to servers, but now each prefix is handled
by a different DHCP server. The client multicasts SOLICIT to all the
DHCP servers. How does it collect all the addresses for different prefixes?

Final case. Multiple DHCP server, all behind a relay. The relay has to
be configured to unicast to each server in turn?



Knowing the answers to these questions would be really useful at this point.



Simon.


From ogud@ogud.com  Wed Nov 14 06:57:40 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349721F85FF for ; Wed, 14 Nov 2012 06:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.754
X-Spam-Level: 
X-Spam-Status: No, score=-103.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZY5WO+C5cOo for ; Wed, 14 Nov 2012 06:57:39 -0800 (PST)
Received: from smtp171.iad.emailsrvr.com (smtp171.iad.emailsrvr.com [207.97.245.171]) by ietfa.amsl.com (Postfix) with ESMTP id B5F8921F85ED for ; Wed, 14 Nov 2012 06:57:39 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp27.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0821F118ED6 for ; Wed, 14 Nov 2012 09:57:39 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp27.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id DA6FE1183D3 for ; Wed, 14 Nov 2012 09:57:38 -0500 (EST)
Message-ID: <50A3B160.9090900@ogud.com>
Date: Wed, 14 Nov 2012 09:57:36 -0500
From: Olafur Gudmundsson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: homenet@ietf.org
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 14:57:40 -0000

On 13/11/2012 17:47, james woodyatt wrote:
> On Nov 13, 2012, at 10:33 , Randy Turner  wrote:
>
>> I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a "/64" assigned to a home network is considered to be potentially "constrained" somehow ?
>
> Once upon a time [RFC 3177], we believed that creating a numbering plan for subscriber networks was intolerably difficult and expensive, so we thought it would be a very good idea to make sure every new subscriber of any size would a /48 delegation, which we all thought was big enough for all but the most titanic of organizations.  The idea was you'd get enough space up front that you could take your numbering plan with you if you ever moved from one provider to another.  Space was thought to be too cheap to meter, and the benefit of number plan stability across providers was thought to be beneficial.
>
> Since then, we have discovered two things: A) service providers guard with astonishing ferocity every last number they get from their registries even when they are too cheap to meter, and B) the problem of number plan scaling is one that only people without any money have any interest in seeing solved.  Hence, we have a new recommendation from IAB [RFC 6177], which capitulates on the one-size-fits-all recommendation. It also says this in section 2:
>
>     However, this precludes the expectation that even home sites will
>     grow to support multiple subnets going forward.  Hence, it is
>     strongly intended that even home sites be given multiple subnets
>     worth of space, by default.  Hence, this document still recommends
>     giving home sites significantly more than a single /64, but does not
>     recommend that every home site be given a /48 either.
>
> For my part, I have a hard time foreseeing how the expectation that residential sites will always have more space to assign than a single /64 subnet is even remotely reasonable.  Far too many service providers are casting into operational concrete topologies that assign only one subnet to each billable subscriber gateway.
>
> I don't hold out much hope that much of a market will ever exist for residential networks with multiple subnets per subscriber.  I also don't hold out much hope for the kind of coordination between service providers that will permit multihomed residential sites to work well.
>
> That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway.
>

I think Homenet should not make the assumption that the different 
networks are from a larger block like /5x but rather a collection  /64's.
Think about the dual ISP connection case, the ISPa/xx allocated blocks 
is quite likely to be disjoint from the ISPb/yy allocated blocks,
and xx != yy is quite possible.


	Olafur



From mellon@fugue.com  Wed Nov 14 07:07:44 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5450121F85FC for ; Wed, 14 Nov 2012 07:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycV5KP1hTVxu for ; Wed, 14 Nov 2012 07:07:43 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0F121F85A2 for ; Wed, 14 Nov 2012 07:07:43 -0800 (PST)
Received: from [192.168.1.2] (42.sub-70-195-201.myvzw.com [70.195.201.42]) by toccata.fugue.com (Postfix) with ESMTPSA id 76EDB2380986; Wed, 14 Nov 2012 10:07:41 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: <50A364D6.8090104@gmail.com>
Date: Wed, 14 Nov 2012 09:07:39 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1499)
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 15:07:44 -0000

On Nov 14, 2012, at 3:31 AM, Brian E Carpenter =
 wrote:
> On 14/11/2012 02:34, Randy Turner wrote:
>> I was thinking that, in an effort to reduce scope to something we can =
deal with for now, that a /64 would be big enough
>=20
> It simply isn't, because it doesn't allow subnetting in the =
home/car/small office or whatever.

I don't see the point in working on the /64 case=97if that's all we're =
trying to accomplish, we've already accomplished it.   The interesting =
work Homenet is doing is in fact trying to solve the prefix distribution =
and automatic setup problem.   It's true that this is a hard problem.   =
It's also true that if we don't specify a solution, people will attempt =
to solve it in their own ways.   And if they do that, we will wind up in =
the situation that Jim found himself in with his broken box with its own =
built-in DHCP server.

BTW, a little more on that topic: the reason that two DHCP servers on =
the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle the multi-homing case.   IPv6 deliberately places the =
multi-homing case in-scope.   This creates a bit of a problem for legacy =
apps that do not support multi-homing, but it also creates the winning =
situation that if one device is advertising a provisioning domain that =
doesn't work, applications that do correctly handle multi-homing will =
simply use a different provisioning domain.


From teco@inf-net.nl  Wed Nov 14 07:48:20 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3C521F8629 for ; Wed, 14 Nov 2012 07:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m-dQrqJEuP5 for ; Wed, 14 Nov 2012 07:48:19 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A40121F8626 for ; Wed, 14 Nov 2012 07:48:18 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so407967eek.31 for ; Wed, 14 Nov 2012 07:48:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rlw0o72oEtnteDgp3YNPAMRd/Z9vQBMh1qRRUbgMdyc=; b=B6Jt08SR1suBgvD8+YBtgzJzNEkqlfeuF0dkrZFDTOXxcvKTzHPCuvIyeMbcUYfKjO fisnix4ZrxjbwGSnivFwy1gT0/SKng+kRF8K+R8VIMEhybGSC1yKifs6Iu8NTEENmwm7 Gfg7WckIwElv/CxrWrCZ0ob5nTrWZ/fl7OtueKWvvYfn9zsxxbd2gDtci3qtMbST9Hvq DsvcBiHPhhY3MW/sZzkarxedfEOklj/6k/WSQ9uzOIKClbCZKLeZeNswfm6bZP2RmWMo R3c11CrMQEi+lVzOI11wlCXgvs4sOmgaozllZrltQwDlodtYVKXaoIyZvfkAXC0mZLuh uaiA==
Received: by 10.14.199.134 with SMTP id x6mr88612736een.31.1352908097934; Wed, 14 Nov 2012 07:48:17 -0800 (PST)
Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id o47sm30233962eem.11.2012.11.14.07.48.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 07:48:16 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=windows-1252
From: Teco Boot 
In-Reply-To: <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>
Date: Wed, 14 Nov 2012 16:48:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQkyeYAmo33mJY3IIlAZg+HV8nW6Ch4WgvEjxYqmOoL7HPEY4CUZB9LOCP2Nz/HlTmnzVTcy
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 15:48:20 -0000

Op 14 nov. 2012, om 16:07 heeft Ted Lemon het volgende geschreven:

> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter =
 wrote:
>> On 14/11/2012 02:34, Randy Turner wrote:
>>> I was thinking that, in an effort to reduce scope to something we =
can deal with for now, that a /64 would be big enough
>>=20
>> It simply isn't, because it doesn't allow subnetting in the =
home/car/small office or whatever.
>=20
> I don't see the point in working on the /64 case=97if that's all we're =
trying to accomplish, we've already accomplished it.   The interesting =
work Homenet is doing is in fact trying to solve the prefix distribution =
and automatic setup problem.   It's true that this is a hard problem.   =
It's also true that if we don't specify a solution, people will attempt =
to solve it in their own ways.   And if they do that, we will wind up in =
the situation that Jim found himself in with his broken box with its own =
built-in DHCP server.
>=20
> BTW, a little more on that topic: the reason that two DHCP servers on =
the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle the multi-homing case.   IPv6 deliberately places the =
multi-homing case in-scope.   This creates a bit of a problem for legacy =
apps that do not support multi-homing, but it also creates the winning =
situation that if one device is advertising a provisioning domain that =
doesn't work, applications that do correctly handle multi-homing will =
simply use a different provisioning domain.

Yes, this is the use case I'm interested in. I don't think it is to hard =
to get there, as long as we don't try to hide the more complex network =
topology and DHCP facilities from hosts. We must be backward compatible, =
but should not block enhancements.

Teco

>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From mike@mtcc.com  Wed Nov 14 07:59:27 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95C21F862C for ; Wed, 14 Nov 2012 07:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFGPxqzt4psk for ; Wed, 14 Nov 2012 07:59:26 -0800 (PST)
Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 42DF821F85FF for ; Wed, 14 Nov 2012 07:59:26 -0800 (PST)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id qAEFw7f1028740 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 07:58:07 -0800
Message-ID: <50A3BF8F.40704@mtcc.com>
Date: Wed, 14 Nov 2012 07:58:07 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Ted Lemon 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>
In-Reply-To: <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1046; t=1352908687; x=1353772687; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20prefix=20assignment=20on=20 home=20networks |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3Dwindows-1252=3B= 20format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=2R8imm0UDgUfhDm6hWZTPrVsFuSL1KRb3YVWI0lnQho=; b=ROQD1gWAvvcqsInBYP2QW9nKOZNjOscC8NvYrdTBO+qLqrkSjDe4QLch/S ORHWq5QN11atkmCrvv4KUlhkbEXDIXWANADraJRDOvfVFk5TdrLnedaUmz4v hkPTt64l4O1zxOwKwS90Yb/KepKwRqceR3ge2ck7nD7JDeEqKv8tU=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 15:59:27 -0000

On 11/14/2012 07:07 AM, Ted Lemon wrote:
>
> BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case.   IPv6 deliberately places the multi-homing case in-scope.   This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain.
>

I'm guessing the main problem wasn't multihoming per se: they were both
probably giving out 192.168 addresses, which would be a problem in v6
were it to happen too. And of course even if they didn't collide, it could
still be a problem if the rogue dhc were pointing the host to a router that
doesn't have the route the dhc says it does.

But the real question I have is: what constitutes a "legacy app"? How
do I know if I've written one or not?

Mike

From teco@inf-net.nl  Wed Nov 14 08:10:03 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F7621F8574 for ; Wed, 14 Nov 2012 08:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCM7BPVDWxk6 for ; Wed, 14 Nov 2012 08:10:02 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFF921F8569 for ; Wed, 14 Nov 2012 08:10:01 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so425616eek.31 for ; Wed, 14 Nov 2012 08:10:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=P3r7ElhwUFJXYQ+JcY2nzrrdkIuAtSBY4Z0+vrLRSxE=; b=Yo9x7qze4nKfsKddTijipLxf+bWn8mALm5E6E3ZdKjwsSOQA6tHtFYr0ubIwg92rq2 EE7veJSt8PquZqL1MgVgRhsbgrG61gm833Bsho2D856LxVv6VgkNbg9c7eJ8kuKynV1S cJOkIGb/befhVqnU2Qx1S6K4HiV8b4pZmTRZRJZ8ORKbQLbEnZwUp91r73IlWBgtC/ff cUHF5Mlli7tjDLCdxkhDefUZEAt1rD2ioDzaIRmTiDyqWjPvdxZi8AuIht1Ya5CzPRt8 YEOLnf2YF8N03xCfXsbp8LRpHVjfWhjJ+C5oKolY5UHK1voMsuHX2IjE3+6OW3zQjcGx rNEw==
Received: by 10.14.194.71 with SMTP id l47mr87683480een.6.1352909401021; Wed, 14 Nov 2012 08:10:01 -0800 (PST)
Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id a44sm30346286eeo.7.2012.11.14.08.09.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 08:09:59 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot 
In-Reply-To: <50A3BF8F.40704@mtcc.com>
Date: Wed, 14 Nov 2012 17:09:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com> <50A3BF8F.40704@mtcc.com>
To: Michael Thomas 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQlggTsvMAU7vDygSJX79bfrzlGYPtvQ3TW0YgQouz6YsG+7xcdu4KzlFB76OQ149M82kcHK
Cc: Randy Turner , Ted Lemon , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 16:10:03 -0000

Op 14 nov. 2012, om 16:58 heeft Michael Thomas het volgende geschreven:

> On 11/14/2012 07:07 AM, Ted Lemon wrote:
>>=20
>> BTW, a little more on that topic: the reason that two DHCP servers on =
the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle the multi-homing case.   IPv6 deliberately places the =
multi-homing case in-scope.   This creates a bit of a problem for legacy =
apps that do not support multi-homing, but it also creates the winning =
situation that if one device is advertising a provisioning domain that =
doesn't work, applications that do correctly handle multi-homing will =
simply use a different provisioning domain.
>>=20
>=20
> I'm guessing the main problem wasn't multihoming per se: they were =
both
> probably giving out 192.168 addresses, which would be a problem in v6
> were it to happen too. And of course even if they didn't collide, it =
could
> still be a problem if the rogue dhc were pointing the host to a router =
that
> doesn't have the route the dhc says it does.

I say the routers do run a protocol that support multihoming. The =
current direction is routing based on source and destination address (or =
destination and source, order is less important here). Hosts may send =
packets to whatever router. It is important that correct interface is =
selected. This is a MIF topic.

>=20
> But the real question I have is: what constitutes a "legacy app"? How
> do I know if I've written one or not?

More important: how to write non-legacy apps that do provide the more =
enhanced robustness. Or upgrade the stack, as mptcp.

Teco=20

>=20
> Mike
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From gettysjim@gmail.com  Wed Nov 14 08:24:43 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BED321F8606 for ; Wed, 14 Nov 2012 08:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4kwuhfH6m6Q for ; Wed, 14 Nov 2012 08:24:42 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4A4921F85DA for ; Wed, 14 Nov 2012 08:24:41 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fl11so697979vcb.31 for ; Wed, 14 Nov 2012 08:24:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AoHw+lppqTgyh/qKGU84nbnC9Ce1ZVHJz0g8nz/+YVA=; b=LqOAOTAsgDnygTBjlFwnoesKTKDyVl/Wzj0OAjbF/+fSZ7EMGeNAEm1pz4I7Ov91+g 4otv884jDA0nN265T1Dx8L2gqbPb/o0TlfaKGdgIi5HsYIf42TEjJSoz36vjvots44S8 6Uti++PUIFCK8eaNu6wuSPTFOQvIm4GGh+jlkrRxbUFEin96+ORt5/c7W/WptDFOLzsi AicDDkA2dyJOfwLvNRrJCsXbWBGPYTeYZSOM/ZHO7onrhA7aPrc2QksHGpPlv2LjvoCY N+J/5Qog/bFsmNH5cMySZgk9msjqWUrx8OXJ7lKymJvigVj8wkERxq0DdtDt1HoEckjZ bPpg==
MIME-Version: 1.0
Received: by 10.58.207.196 with SMTP id ly4mr32400563vec.6.1352910281242; Wed, 14 Nov 2012 08:24:41 -0800 (PST)
Sender: gettysjim@gmail.com
Received: by 10.58.151.202 with HTTP; Wed, 14 Nov 2012 08:24:41 -0800 (PST)
In-Reply-To: <50A39D19.6010708@thekelleys.org.uk>
References:  <50A2AB4A.3070506@thekelleys.org.uk>  <50A39D19.6010708@thekelleys.org.uk>
Date: Wed, 14 Nov 2012 11:24:41 -0500
X-Google-Sender-Auth: f-_UDlgz4QRrkyAfytSjYBS_Bo4
Message-ID: 
From: Jim Gettys 
To: Simon Kelley 
Content-Type: multipart/alternative; boundary=047d7b86eab8b9f6f604ce76f8f6
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 16:24:43 -0000

--047d7b86eab8b9f6f604ce76f8f6
Content-Type: text/plain; charset=ISO-8859-1

Please, let's not OD on DHCP in this thread: while I was making a point
about DHCP, I was really making a more general point about robustness in
homenet, and how to judge various proposals, more than specifically
attacking recursive DHCP-PD as a concept.

Similarly, I think as another goal we have to accept easy debuggability as
a goal.  We need to know if a router is expected to function, and you
should be able to easily see if the router is functioning *and* if can talk
to its border routers and the rest of the Internet.  One of the things I
like about CeroWrt is that I can *always* talk to the router and from there
I have a chance to figure out if it is able to talk to the rest of the home
network, and the world (e.g. by seeing that I've got an IPv6 network
delegation).  Today, since we have to presume that you need a IPv4 address,
this implies running a DHCP server on each router: in the long run, it's
less than clear to me that this is desirable.  But one way or the other,
I've got to be able to connect and talk to the router to be able to debug
it, preferably from both upstream and downstream directions.  The CeroWrt
router I'm debugging doesn't "fate share" with other routers to the point
that you have no place to stand initially.


So I'd expand my list of how to judge proposals to the configuration
distribution problem to be:
    1) robustness
    2) hotplug
    3) debuggability

                                  - Jim





On Wed, Nov 14, 2012 at 8:31 AM, Simon Kelley wrote:

> On 14/11/12 12:08, Teco Boot wrote:
>
> >
> >> The one-and-only DHCP server knows about all the prefixes delegated
> >> from the ISP and the relays know which particular prefix has been
> >> given to the local router by the routing protocol or AHCP.
> > I don't like a single DHCP server for multi-homed sites. This
> > introduces unneeded complexity, it needs merging of information from
> > multiple sources. This is completely incompatible with what MIF is
> > doing (multiple provisioning domains). It also introduces an unneeded
> > single point of failure. Multi-homing could be used for redundancy.
> > Let's use a DHCP server for each ISP.
> >
> > In cases where a single CPE router connects to multiple ISPs, it can
> > take two approaches: running multiple DHCP server instances, one for
> > each ISP. Or perform the problematic integration.
> >
> > BRDP takes the "per provisioning domain" approach, where each
> > provisioning domain is presented with a border router address
> > (generated form provided prefix), with prefix length. Problem solved
> > :-).
>
> OK. This raises some questions about DHCPv6 to which I don't know the
> answers. I hope Ted or someone else who was involved in the standard can
> answer.
>
>
> Simplest case first. Client and server on same link (in the RFC3315
> definition of link) the server has an interface on the link which has
> multiple addresses with different prefixes, and it is configured to
> assign addresses on each of those prefixes. The client is unconfigured
> except for a link-local address. How does the client create a SOLICIT
> message which causes the server to reply with an ADVERTISE which offers
> the client an address with each of the prefixes ? The client doesn't
> know how many prefixes are available.
>
> Next case. The same as above but the SOLICIT transits via a relay. The
> relay can only insert one link address in the encapsulation, does the
> server have to know which prefixes share links so that it can determine
> which other prefixes are on the same link and reduce the problem to the
> case above?
>
> Next case. This speaks to Teco's suggestion. The same link with multiple
> prefixes, directly connected to servers, but now each prefix is handled
> by a different DHCP server. The client multicasts SOLICIT to all the
> DHCP servers. How does it collect all the addresses for different prefixes?
>
> Final case. Multiple DHCP server, all behind a relay. The relay has to
> be configured to unicast to each server in turn?
>
>
>
> Knowing the answers to these questions would be really useful at this
> point.
>
>
>
> Simon.
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

--047d7b86eab8b9f6f604ce76f8f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Please, let's not OD on DHCP in this thread: while I was making a point=
 about DHCP, I was really making a more general point about robustness in h=
omenet, and how to judge various proposals, more than specifically attackin=
g recursive DHCP-PD as a concept.


Similarly, I think as another goal we have to accept easy de=
buggability as a goal. =A0We need to know if a router is expected to functi=
on, and you should be able to easily see if the router is functioning *and*=
 if can talk to its border routers and the rest of the Internet. =A0One of =
the things I like about CeroWrt is that I can *always* talk to the router a=
nd from there I have a chance to figure out if it is able to talk to the re=
st of the home network, and the world (e.g. by seeing that I've got an =
IPv6 network delegation). =A0Today, since we have to presume that you need =
a IPv4 address, this implies running a DHCP server on each router: in the l=
ong run, it's less than clear to me that this is desirable. =A0But one =
way or the other, I've got to be able to connect and talk to the router=
 to be able to debug it, preferably from both upstream and downstream direc=
tions. =A0The CeroWrt router I'm debugging doesn't "fate share=
" with other routers to the point that you have no place to stand init=
ially.




So I'd expand my list of how to judg=
e proposals to the configuration distribution problem to be:
=A0 =
=A0 1) robustness
=A0 =A0 2) hotplug
=A0 =A0 3) debugga=
bility



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 - Jim





On Wed, Nov 14, 201=
2 at 8:31 AM, Simon Kelley <simon@thekelleys.org.uk> w=
rote:


On 14/11/12 12:08, Teco Bo=
ot wrote:



>

>> The one-and-only DHCP server knows about all the prefixes delegate=
d

>> from the ISP and the relays know which particular prefix has been<=
br>
>> given to the local router by the routing protocol or AHCP.

> I don't like a single DHCP server for multi-homed sites. This

> introduces unneeded complexity, it needs merging of information from
> multiple sources. This is completely incompatible with what MIF is

> doing (multiple provisioning domains). It also introduces an unneeded<=
br>
> single point of failure. Multi-homing could be used for redundancy.
> Let's use a DHCP server for each ISP.

>

> In cases where a single CPE router connects to multiple ISPs, it can
> take two approaches: running multiple DHCP server instances, one for
> each ISP. Or perform the problematic integration.

>

> BRDP takes the "per provisioning domain" approach, where eac=
h

> provisioning domain is presented with a border router address

> (generated form provided prefix), with prefix length. Problem solved
> :-).




OK. This raises some questions about DHCPv6 to which I don't know=
 the

answers. I hope Ted or someone else who was involved in the standard can
answer.





Simplest case first. Client and server on same link (in the RFC3315

definition of link) the server has an interface on the link which has

multiple addresses with different prefixes, and it is configured to

assign addresses on each of those prefixes. The client is unconfigured

except for a link-local address. How does the client create a SOLICIT

message which causes the server to reply with an ADVERTISE which offers

the client an address with each of the prefixes ? The client doesn't
know how many prefixes are available.



Next case. The same as above but the SOLICIT transits via a relay. The

relay can only insert one link address in the encapsulation, does the

server have to know which prefixes share links so that it can determine

which other prefixes are on the same link and reduce the problem to the

case above?



Next case. This speaks to Teco's suggestion. The same link with multipl=
e

prefixes, directly connected to servers, but now each prefix is handled

by a different DHCP server. The client multicasts SOLICIT to all the

DHCP servers. How does it collect all the addresses for different prefixes?=




Final case. Multiple DHCP server, all behind a relay. The relay has to

be configured to unicast to each server in turn?







Knowing the answers to these questions would be really useful at this point=
.








Simon.



_______________________________________________

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet





--047d7b86eab8b9f6f604ce76f8f6--

From simon@thekelleys.org.uk  Wed Nov 14 08:28:08 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C8E21F865D for ; Wed, 14 Nov 2012 08:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b04axRBYzZ1W for ; Wed, 14 Nov 2012 08:28:08 -0800 (PST)
Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id E16CA21F8620 for ; Wed, 14 Nov 2012 08:28:07 -0800 (PST)
Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:56423 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TYfor-0001Pm-SU; Wed, 14 Nov 2012 16:28:05 +0000
Received: from guest-193-062-204-116.wtgc.org ([193.62.204.116]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TYfor-0002UE-8w; Wed, 14 Nov 2012 16:28:05 +0000
Message-ID: <50A3C68E.1050606@thekelleys.org.uk>
Date: Wed, 14 Nov 2012 16:27:58 +0000
From: Simon Kelley 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jim Gettys , homenet@ietf.org
References:  <50A2AB4A.3070506@thekelleys.org.uk>  <50A39D19.6010708@thekelleys.org.uk> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 16:28:08 -0000

On 14/11/12 16:24, Jim Gettys wrote:
> Please, let's not OD on DHCP in this thread: while I was making a point
> about DHCP, I was really making a more general point about robustness in
> homenet, and how to judge various proposals, more than specifically
> attacking recursive DHCP-PD as a concept.
> 
> Similarly, I think as another goal we have to accept easy debuggability
> as a goal.  We need to know if a router is expected to function, and you
> should be able to easily see if the router is functioning *and* if can
> talk to its border routers and the rest of the Internet.  One of the
> things I like about CeroWrt is that I can *always* talk to the router
> and from there I have a chance to figure out if it is able to talk to
> the rest of the home network, and the world (e.g. by seeing that I've
> got an IPv6 network delegation).  Today, since we have to presume that
> you need a IPv4 address, this implies running a DHCP server on each
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> router: in the long run, it's less than clear to me that this is
> desirable.  But one way or the other, I've got to be able to connect and
> talk to the router to be able to debug it, preferably from both upstream
> and downstream directions.  The CeroWrt router I'm debugging doesn't
> "fate share" with other routers to the point that you have no place to
> stand initially.
> 
> 

I agree with this, except the underlined section: DHCP-relay is a
standard technique for DHCPv4.

Simon.



From rturner@amalfisystems.com  Wed Nov 14 09:27:04 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CE521F86B5 for ; Wed, 14 Nov 2012 09:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0MLtRW7rN2G for ; Wed, 14 Nov 2012 09:27:04 -0800 (PST)
Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3112521F8615 for ; Wed, 14 Nov 2012 09:27:02 -0800 (PST)
Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAEHR12n002882 for ; Wed, 14 Nov 2012 12:27:01 -0500
Received: (qmail 20175 invoked by uid 0); 14 Nov 2012 17:27:01 -0000
Received: from unknown (HELO ?192.168.1.106?) (98.151.18.90) by 0 with SMTP; 14 Nov 2012 17:27:01 -0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1283)
From: Randy Turner 
In-Reply-To: <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>
Date: Wed, 14 Nov 2012 09:27:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>
To: homenet@ietf.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 17:27:04 -0000

Have their been any ISPs that have come forward to discuss their =
consumer IPv6 allocation plans?  I don't think we should wrap ourselves =
around a model that says, "yeah, we need multiple /64s for consumers =
because that's the way a particular protocol works (SLAAC).   Maybe we =
need another method. One /64 for a home network seems like overkill =
regarding address space utilization -- A /32 would be overkill.  I know =
some folks think we have more address space than we'll ever use, but =
gee=85.

Randy


On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:

> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter =
 wrote:
>> On 14/11/2012 02:34, Randy Turner wrote:
>>> I was thinking that, in an effort to reduce scope to something we =
can deal with for now, that a /64 would be big enough
>>=20
>> It simply isn't, because it doesn't allow subnetting in the =
home/car/small office or whatever.
>=20
> I don't see the point in working on the /64 case=97if that's all we're =
trying to accomplish, we've already accomplished it.   The interesting =
work Homenet is doing is in fact trying to solve the prefix distribution =
and automatic setup problem.   It's true that this is a hard problem.   =
It's also true that if we don't specify a solution, people will attempt =
to solve it in their own ways.   And if they do that, we will wind up in =
the situation that Jim found himself in with his broken box with its own =
built-in DHCP server.
>=20
> BTW, a little more on that topic: the reason that two DHCP servers on =
the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle the multi-homing case.   IPv6 deliberately places the =
multi-homing case in-scope.   This creates a bit of a problem for legacy =
apps that do not support multi-homing, but it also creates the winning =
situation that if one device is advertising a provisioning domain that =
doesn't work, applications that do correctly handle multi-homing will =
simply use a different provisioning domain.
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>=20


From rturner@amalfisystems.com  Wed Nov 14 10:24:52 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D788F21F85FD for ; Wed, 14 Nov 2012 10:24:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64A8hEtt3sLh for ; Wed, 14 Nov 2012 10:24:52 -0800 (PST)
Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id DD7DF21F8796 for ; Wed, 14 Nov 2012 10:24:51 -0800 (PST)
Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAEIOoQQ012931 for ; Wed, 14 Nov 2012 13:24:50 -0500
Received: (qmail 15631 invoked by uid 0); 14 Nov 2012 18:24:50 -0000
Received: from unknown (HELO ?192.168.1.106?) (98.151.18.90) by 0 with SMTP; 14 Nov 2012 18:24:50 -0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1283)
From: Randy Turner 
In-Reply-To: 
Date: Wed, 14 Nov 2012 10:24:50 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com> 
To: homenet@ietf.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 18:24:52 -0000

Meant to say a 32-bit address space for the home would be more than =
enough=85:)

R.

On Nov 14, 2012, at 9:27 AM, Randy Turner wrote:

>=20
> Have their been any ISPs that have come forward to discuss their =
consumer IPv6 allocation plans?  I don't think we should wrap ourselves =
around a model that says, "yeah, we need multiple /64s for consumers =
because that's the way a particular protocol works (SLAAC).   Maybe we =
need another method. One /64 for a home network seems like overkill =
regarding address space utilization -- A /32 would be overkill.  I know =
some folks think we have more address space than we'll ever use, but =
gee=85.
>=20
> Randy
>=20
>=20
> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
>=20
>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter =
 wrote:
>>> On 14/11/2012 02:34, Randy Turner wrote:
>>>> I was thinking that, in an effort to reduce scope to something we =
can deal with for now, that a /64 would be big enough
>>>=20
>>> It simply isn't, because it doesn't allow subnetting in the =
home/car/small office or whatever.
>>=20
>> I don't see the point in working on the /64 case=97if that's all =
we're trying to accomplish, we've already accomplished it.   The =
interesting work Homenet is doing is in fact trying to solve the prefix =
distribution and automatic setup problem.   It's true that this is a =
hard problem.   It's also true that if we don't specify a solution, =
people will attempt to solve it in their own ways.   And if they do =
that, we will wind up in the situation that Jim found himself in with =
his broken box with its own built-in DHCP server.
>>=20
>> BTW, a little more on that topic: the reason that two DHCP servers on =
the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle the multi-homing case.   IPv6 deliberately places the =
multi-homing case in-scope.   This creates a bit of a problem for legacy =
apps that do not support multi-homing, but it also creates the winning =
situation that if one device is advertising a provisioning domain that =
doesn't work, applications that do correctly handle multi-homing will =
simply use a different provisioning domain.
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>=20
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>=20


From swmike@swm.pp.se  Wed Nov 14 10:28:31 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1018721F8778 for ; Wed, 14 Nov 2012 10:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erA2Ei-JhRAn for ; Wed, 14 Nov 2012 10:28:30 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 78E8A21F8776 for ; Wed, 14 Nov 2012 10:28:30 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9E55B9C; Wed, 14 Nov 2012 19:28:28 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 97B829A; Wed, 14 Nov 2012 19:28:28 +0100 (CET)
Date: Wed, 14 Nov 2012 19:28:28 +0100 (CET)
From: Mikael Abrahamsson 
To: Randy Turner 
In-Reply-To: 
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com> 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-303247271-1352917708=:27834"
Cc: homenet@ietf.org
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 18:28:31 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-303247271-1352917708=:27834
Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 14 Nov 2012, Randy Turner wrote:

> Have their been any ISPs that have come forward to discuss their 
> consumer IPv6 allocation plans?  I don't think we should wrap ourselves 
> around a model that says, "yeah, we need multiple /64s for consumers 
> because that's the way a particular protocol works (SLAAC).  Maybe we 
> need another method. One /64 for a home network seems like overkill 
> regarding address space utilization -- A /32 would be overkill.  I know 
> some folks think we have more address space than we'll ever use, but 
> gee….

Personally I don't see a way we can get anything deployed in any near time 
if we abandon or try to change SLAAC. I don't see it as productive either.

/64 is what we have to work with. /56 per household scales perfectly well 
when doing the math.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-303247271-1352917708=:27834--

From andrewmcgr@gmail.com  Wed Nov 14 10:40:56 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3321F8626 for ; Wed, 14 Nov 2012 10:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L5UkUjc4BVQ for ; Wed, 14 Nov 2012 10:40:55 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08F3921F89D3 for ; Wed, 14 Nov 2012 10:40:55 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id uo1so571217pbc.31 for ; Wed, 14 Nov 2012 10:40:54 -0800 (PST)
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:x-mailer; bh=ZFmBaeRAQxGASIH7/F6jO/a9zN7ObUvwHY2bW4dLvo0=; b=we6GvQMGH10XfWC2GEYLaEULV5nb0elBfbaE2znDNnUhLJB+4noWHhx4A90kY+jR87 OHhTxUTTJjz6AK+Ug5uEYWNzVRp+MUg86pw7t134gaCTKm7w4CJRWEOI1xY6CXZNBdvQ vb/d2D8NGy6EkxEVPLHp8hWpoSDLoAICcclk7l2+k5dYJz3iF+DsXPa65hw8Bh7esEnq Oo62HgWsIp63j/UGzK6jahNvi0ABDpAL/IOZN5H5Aw4R6wbuQW00LHrkK2GtC1yJKNTB QEtaTBVEtm204wvr4Yptyhn/0tD1WaBbRit6g+2Z1/SFybVI0I13dlJgCCcLpVDClF3q aBtA==
Received: by 10.68.219.164 with SMTP id pp4mr42154128pbc.72.1352918454783; Wed, 14 Nov 2012 10:40:54 -0800 (PST)
Received: from ?IPv6:2406:e000:607b:1:485c:d573:3b2e:88e6? ([2406:e000:607b:1:485c:d573:3b2e:88e6]) by mx.google.com with ESMTPS id vn2sm5461083pbc.31.2012.11.14.10.40.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 10:40:54 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andrew McGregor 
In-Reply-To: 
Date: Thu, 15 Nov 2012 07:40:46 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <47969290-9244-4CCF-B273-33B68F0DE52B@gmail.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com> 
To: Randy Turner 
X-Mailer: Apple Mail (2.1499)
Cc: homenet@ietf.org
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 18:40:56 -0000

I have a /48 at home, on a retail ISP, right now.  I know, one data =
point does not a trend make, but it is a proof by example that some ISP =
is doing that.

Andrew

On 15/11/2012, at 6:27 AM, Randy Turner  =
wrote:

>=20
> Have their been any ISPs that have come forward to discuss their =
consumer IPv6 allocation plans?  I don't think we should wrap ourselves =
around a model that says, "yeah, we need multiple /64s for consumers =
because that's the way a particular protocol works (SLAAC).   Maybe we =
need another method. One /64 for a home network seems like overkill =
regarding address space utilization -- A /32 would be overkill.  I know =
some folks think we have more address space than we'll ever use, but =
gee=85.
>=20
> Randy
>=20
>=20
> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
>=20
>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter =
 wrote:
>>> On 14/11/2012 02:34, Randy Turner wrote:
>>>> I was thinking that, in an effort to reduce scope to something we =
can deal with for now, that a /64 would be big enough
>>>=20
>>> It simply isn't, because it doesn't allow subnetting in the =
home/car/small office or whatever.
>>=20
>> I don't see the point in working on the /64 case=97if that's all =
we're trying to accomplish, we've already accomplished it.   The =
interesting work Homenet is doing is in fact trying to solve the prefix =
distribution and automatic setup problem.   It's true that this is a =
hard problem.   It's also true that if we don't specify a solution, =
people will attempt to solve it in their own ways.   And if they do =
that, we will wind up in the situation that Jim found himself in with =
his broken box with its own built-in DHCP server.
>>=20
>> BTW, a little more on that topic: the reason that two DHCP servers on =
the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle the multi-homing case.   IPv6 deliberately places the =
multi-homing case in-scope.   This creates a bit of a problem for legacy =
apps that do not support multi-homing, but it also creates the winning =
situation that if one device is advertising a provisioning domain that =
doesn't work, applications that do correctly handle multi-homing will =
simply use a different provisioning domain.
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>=20
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From rturner@amalfisystems.com  Wed Nov 14 10:58:14 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F88A21F8626 for ; Wed, 14 Nov 2012 10:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level: 
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9oIlLm9yGIj for ; Wed, 14 Nov 2012 10:58:13 -0800 (PST)
Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8D68821F8622 for ; Wed, 14 Nov 2012 10:58:13 -0800 (PST)
Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAEIwCib010147 for ; Wed, 14 Nov 2012 13:58:12 -0500
Received: (qmail 23415 invoked by uid 0); 14 Nov 2012 18:58:12 -0000
Received: from unknown (HELO ?192.168.1.106?) (98.151.18.90) by 0 with SMTP; 14 Nov 2012 18:58:12 -0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1283)
From: Randy Turner 
In-Reply-To: <47969290-9244-4CCF-B273-33B68F0DE52B@gmail.com>
Date: Wed, 14 Nov 2012 10:58:11 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<15353.1352401878@sandelman.ca>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>	 <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>
To: homenet@ietf.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 18:58:14 -0000

I'm not against one or more  /64 bit prefixes for a home net, if =
everyone else (including the ISPs) think that home networks should be =
able to scale up to 18,446,744,073,709,551,615 hosts, I'm completely on =
board.  It's not my resource, so I'll take all they give me.  :)  It =
would be nice to have an AT&T, Verizon, or some other major provider =
chime in to say they're on board with the assumptions we're making.  =
Maybe they already have, I've been away from the list for awhile, or =
maybe they've indicated this allocation strategy in some other forum.  =
I'm old school and I'm not used to having publicly routable address =
space to burn.

Randy

On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote:

> I have a /48 at home, on a retail ISP, right now.  I know, one data =
point does not a trend make, but it is a proof by example that some ISP =
is doing that.
>=20
> Andrew
>=20
> On 15/11/2012, at 6:27 AM, Randy Turner  =
wrote:
>=20
>>=20
>> Have their been any ISPs that have come forward to discuss their =
consumer IPv6 allocation plans?  I don't think we should wrap ourselves =
around a model that says, "yeah, we need multiple /64s for consumers =
because that's the way a particular protocol works (SLAAC).   Maybe we =
need another method. One /64 for a home network seems like overkill =
regarding address space utilization -- A /32 would be overkill.  I know =
some folks think we have more address space than we'll ever use, but =
gee=85.
>>=20
>> Randy
>>=20
>>=20
>> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
>>=20
>>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter =
 wrote:
>>>> On 14/11/2012 02:34, Randy Turner wrote:
>>>>> I was thinking that, in an effort to reduce scope to something we =
can deal with for now, that a /64 would be big enough
>>>>=20
>>>> It simply isn't, because it doesn't allow subnetting in the =
home/car/small office or whatever.
>>>=20
>>> I don't see the point in working on the /64 case=97if that's all =
we're trying to accomplish, we've already accomplished it.   The =
interesting work Homenet is doing is in fact trying to solve the prefix =
distribution and automatic setup problem.   It's true that this is a =
hard problem.   It's also true that if we don't specify a solution, =
people will attempt to solve it in their own ways.   And if they do =
that, we will wind up in the situation that Jim found himself in with =
his broken box with its own built-in DHCP server.
>>>=20
>>> BTW, a little more on that topic: the reason that two DHCP servers =
on the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle the multi-homing case.   IPv6 deliberately places the =
multi-homing case in-scope.   This creates a bit of a problem for legacy =
apps that do not support multi-homing, but it also creates the winning =
situation that if one device is advertising a provisioning domain that =
doesn't work, applications that do correctly handle multi-homing will =
simply use a different provisioning domain.
>>>=20
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>=20
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20
>=20


From jhw@apple.com  Wed Nov 14 12:49:58 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2821F84FC for ; Wed, 14 Nov 2012 12:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLC14uiHInSz for ; Wed, 14 Nov 2012 12:49:58 -0800 (PST)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id E5D5021F84E4 for ; Wed, 14 Nov 2012 12:49:57 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDH00A0EWF60NP2@mail-out.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 12:49:36 -0800 (PST)
X-AuditID: 11807130-b7fcc6d0000038e5-f8-50a403e00cfd
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id B2.FE.14565.0E304A05; Wed, 14 Nov 2012 12:49:36 -0800 (PST)
Received: from [17.193.15.79] by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDH00MG7WINUK50@spicerack.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 12:49:35 -0800 (PST)
From: james woodyatt 
In-reply-to: <50A32C7B.7000904@bogus.com>
Date: Wed, 14 Nov 2012 12:49:37 -0800
Content-transfer-encoding: quoted-printable
Message-id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>
To: "homenet@ietf.org Group" 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FCsofuAeUmAweXlKhbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoonV9gLPktWzNt2nqWB8ZJIFyMnh4SAicSZK39YIWwxiQv3 1rOB2EICM5gkmqfwdDFyAdltTBLXu86ydDFycDAL6Encv6gFYvICmZP2B4GUCwtYSvz++oQZ xGYTUJH4dvkuE0gJp4CmxJnVwSBhFgFViY3PZoKVMAtoSzx5dwFsK6+AjcSX33PZIDb1skus ndvBApIQEdCXeHrkFxvEabISK6b2Mk1g5J+FcMQshCNmIZm6gJF5FaNgUWpOYqWhoV5iQUFO ql5yfu4mRnBoFRrsYFz7k/8QowAHoxIP7+mbiwOEWBPLiitzDzFKcDArifC+OAgU4k1JrKxK LcqPLyrNSS0+xCjNwaIkznuVcUmAkEB6YklqdmpqQWoRTJaJg1OqgXHh6+2BU8rC9h8NtDtp JHr75LdV4ucZwgTabujN09/37rarVNWPl/HLZ79Otb1cxiSye5/ovNanoQaMLtN6Z07o+N/h m6jpX2t6WaJEf/fpnNeT78ut41rsJW0zf7KmtQuXcnj0kfrIokTN+w5/vBUZi6oXrsmUFku5 veVyF3vBBRufKb1l/5VYijMSDbWYi4oTAZG8RX8pAgAA
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 20:49:58 -0000

On Nov 13, 2012, at 21:30 , joel jaeggli  wrote:
> On 11/13/12 9:20 PM, Mikael Abrahamsson wrote:
>>=20
>> Why do you believe we need coordination between service providers to =
permit multihomed services to work well? I thought the whole idea was to =
handle multiple upstream prefixes and make sure everything is routed to =
the correct ISP?
>=20
> If coordination is required, it's not going to work.

Let's put on our thinking caps.  Say I have a HOMENET with two =
provider-provisioned border gateways, each from different providers.

Let's call them ALFA Broadband and BRAVO Networks.  Say that ALFA =
delegates 2001:db8:aaaa::/64 to me and BRAVO delegates =
2001:db8:bbbb::/64 to me (yes, they could delegate shorter prefixes, but =
let's say I have only one link to number, so the prefixes above are the =
ones that each gateway will be advertising in Router Advertisement =
messages on my HOMENET link).

When they're both up and running, each router is a default gateways on =
my link.  Each host gets two prefixes on the link, i.e. =
2001:db8:aaaa::/64 and 2001:db8:bbbb::/64 and a default router list =
comprising both the gateways for ALFA and BRAVO.

Given how the hosts in the field today behave, only one of the routers =
will be forwarding outbound packets.  Which is fine.  Let's say my =
gateway from ALFA is the default router all my hosts always pick, i.e. =
it's at the front of the default router list. Now let's say a host on my =
network chooses to connect to a remote destination where source address =
selection rules say that it should pick an address from the BRAVO prefix =
delegation.  The SYN packet with source address 2001:db8:bbbb::XXXXX =
goes to the ALFA router.  What does it do with that?

- Does it forward the packet?  If so, then the return path will be =
asymmetric, i.e. it will come back through my BRAVO gateway.  Asymmetric =
paths are the reason 6to4 anycast is broken.  I thought we learned our =
lesson about that.  Maybe not all of us did, but I bet we soon will if =
we keep going this road.

- Does it recognize the 2001:db8:bbbb::/64 prefix and redirect to the =
BRAVO router?  If so, then how does it know to do that?  Coordination, =
because routers don't process Router Advertisements, so the ALFA gateway =
won't have reason to know about the BRAVO prefix unless it makes an =
exception to the standard rules.  I'm not optimistic that the players =
involved will have any incentive to adopt protocols that enable that =
happen.    This all sounds very squirrelly to me, and the incentives to =
do it seem completely missing in action.

(By the way, how do you redirect a whole prefix?  You don't.  How do you =
cancel a redirection?  You don't.  How do we fix this?  By getting 6MAN =
to revise Router Advertisements and rolling out new host implementations =
everywhere.  Good luck with that.  Oh but wait: maybe, the ALFA router =
doesn't redirect, but it forwards instead.  Path asymmetry again=97 just =
not as badly asymmetric as it would otherwise be, i.e. asymmetry is =
confined to the local link.)

Maybe I'm missing something, but I think this is really an intractable =
problem, given what I know about it.


--
james woodyatt 
core os networking


From swmike@swm.pp.se  Wed Nov 14 13:34:31 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B792321F8527 for ; Wed, 14 Nov 2012 13:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU8+0R9yDRDV for ; Wed, 14 Nov 2012 13:34:31 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7D121F851A for ; Wed, 14 Nov 2012 13:34:31 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E78009C; Wed, 14 Nov 2012 22:34:29 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E015D9A; Wed, 14 Nov 2012 22:34:29 +0100 (CET)
Date: Wed, 14 Nov 2012 22:34:29 +0100 (CET)
From: Mikael Abrahamsson 
To: james woodyatt 
In-Reply-To: 
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com> 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 21:34:31 -0000

On Wed, 14 Nov 2012, james woodyatt wrote:

> Maybe I'm missing something, but I think this is really an intractable 
> problem, given what I know about it.

Having outgoing packets from ALFA prefix go out to ALFA and BRAVO prefix 
to go out via BRAVO has been on the problem description for over a year 
(afaik), so I can't imagine people aren't looking into that already.

It's not solved by ISPs coordinating, that's never going to happen. I've 
always seen it to be solved via some kind of source based routing 
automatically discovered between the ISP routers. I believe this is in the 
suggestions already. uRPF is well known problem that needs to be handled.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From jhw@apple.com  Wed Nov 14 14:44:59 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91AB21F887D for ; Wed, 14 Nov 2012 14:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOIIwA6yxg3k for ; Wed, 14 Nov 2012 14:44:59 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2786621F884D for ; Wed, 14 Nov 2012 14:44:55 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDI00KTB1TPY8S0@mail-out.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 14:44:40 -0800 (PST)
X-AuditID: 11807134-b7fe96d000000e2b-d5-50a41ed82b54
Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id A5.B5.03627.8DE14A05; Wed, 14 Nov 2012 14:44:40 -0800 (PST)
Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDI00A5W1UGB170@aniseed.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 14:44:40 -0800 (PST)
From: james woodyatt 
In-reply-to: 
Date: Wed, 14 Nov 2012 14:44:39 -0800
Message-id: <156086CB-465E-45CE-8A9D-BBCF11A65050@apple.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>  
To: "homenet@ietf.org Group" 
X-Mailer: Apple Mail (2.1630)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FAsrntDbkmAweXPEhbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvZrE9gKdrBXXLsr1MD4ibWLkZNDQsBEYmrTajYIW0ziwr31 QDYXh5DAFCaJ/vMPWSCcWUwSe/4+YgGpYhbQkli/8zgTiM0roCdx5NIEMFtYwFLi99cnzCA2 m4CKxLfLd8HinALOEi87l4PFWQRUJT4e6GeDmKMt8eTdBVaIOTYS07+cYYRY9p1dovdNE1hC REBf4umRX1DnyUrsPnKPaQIj/ywkd8xCcscsJHMXMDKvYhQsSs1JrDQ00UssKMhJ1UvOz93E CA6yQpMdjAd/8h9iFOBgVOLhPXVzcYAQa2JZcWXuIUYJDmYlEd4XB4FCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEea8zLgkQEkhPLEnNTk0tSC2CyTJxcEo1MLq+XNp6cIbwtq3bjrxZamp02Hni 97WayjsjmGYYZMRInKt0XxMQ7vnY/FNIpKr/ae6t85OvfONn8G4u6uAycgs7ZHO47cX7IF61 nK/XLv5meyq+8EbqtGgeXusjXrVT+OvddnnfWexU/cHSqrDl0WP21xZnuV1/T/8T/eP2WYbD KfJeT48EZyqxFGckGmoxFxUnAgDqbpzmLgIAAA==
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 22:44:59 -0000

On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  wrote:
> 
> I've always seen it to be solved via some kind of source based routing automatically discovered between the ISP routers.


My point is that it isn't sufficient to handle this problem at just the routers.  At a minimum, the *hosts* need to be told which default router to use with each source prefix.  Right now the only mechanism that comes close to doing that is ICMPv6 Redirect, which isn't suitable for addressing this problem.

This problem might not be so troubling if hosts didn't expect any and all of the default routers on a link either to forward packets with source addresses having prefixes they don't advertise, or to send a redirect for the destination to one that will.

Alas, hosts do have such an expectation, and that's not going to change any time soon.


--
james woodyatt 
core os networking


From jhw@apple.com  Wed Nov 14 18:48:03 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC52521E8040 for ; Wed, 14 Nov 2012 18:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPkNEWLEHWSy for ; Wed, 14 Nov 2012 18:48:03 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39121E802E for ; Wed, 14 Nov 2012 18:48:03 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDI00D9AD3QPN11@mail-out.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 18:48:02 -0800 (PST)
X-AuditID: 1180711d-b7fe16d00000096a-c7-50a457e226d9
Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay13.apple.com (Apple SCV relay) with SMTP id C5.64.02410.2E754A05; Wed, 14 Nov 2012 18:48:02 -0800 (PST)
Received: from kallisti.apple.com ([17.193.13.64]) by chicory.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDI00ILGD42GQ30@chicory.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 18:48:02 -0800 (PST)
Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated.
From: james woodyatt 
In-reply-to: <17524.1352942536@obiwan.sandelman.ca>
Date: Wed, 14 Nov 2012 18:48:02 -0800
Message-id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>  
To: "homenet@ietf.org Group" 
X-Mailer: Apple Mail (2.1630)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUi2FCcrPsofEmAwfVThhbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuf5O9kKdspW/Dpzi7GB8bB4FyMnh4SAiUT/9A+sELaYxIV7 69m6GLk4hASmMEmcXPQbypnFJLFx4W12kCphgQCJT437WEBsZgEtifU7jzOB2LwCehJHLk1g gqixlPj99QkziM0moCLx7fJdsDingLHE1ZvbgGwODhYBVYmuXYIQY7Qlnry7wAoxxkbizOQ+ Joi939klet80gSVEBPQlnh75xQZxqazE7iP3mCYwCsxCcsYsJGfMQjJ3ASPzKkbBotScxEpD Y73EgoKcVL3k/NxNjODgK5Tdwbj/J/8hRgEORiUe3qLriwOEWBPLiitzDzFKcDArifC+OAgU 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzhsfuiRASCA9sSQ1OzW1ILUIJsvEwSnVwCjHtNH7vvEc zhenxEMjZkTsPRjH8XL18mjBwm57A9/+/9O3827j2hH299+M8O7Z1kWnfZSvq5fW1AZ1drC5 yk4MccjLvHdCsOGWgaXR1hUiLjIHr/L9lv+a/GLiyf+fxA9eknuwNu2mNw/La/21CSw5d3+E /xaYKrfmf+qFZ/LHHfwLm9brvlFiKc5INNRiLipOBAAsgnIGOgIAAA==
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 02:48:04 -0000

On Nov 14, 2012, at 17:22 , Michael Richardson  wrote:
> 
>    james> My point is that it isn't sufficient to handle this problem
>    james> at just the routers.  At a minimum, the *hosts* need to be
>    james> told which default router to use with each source prefix.
>    james> Right now the only mechanism that comes close to doing that
>    james> is ICMPv6 Redirect, which isn't suitable for addressing this
>    james> problem.
> 
> the edge routers can fix things for the hosts.

If they coordinate.

Section 3.2.4 Multihoming of I-D.ietf-homenet-arch-06 goes into some detail about the challenges in the scenario under discussion in this thread, and it mentions two proposals by name:

  I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat
  I-D.baker-fun-multi-router

Neither of which sufficiently answers my open questions about how multiple provider-provisioned subscriber gateways will coordinate forwarding of packets to the correct egress for their source prefix.  Please don't misunderstand: I can imagine a routing protocol that could do what I-D.baker-fun-multi-router describes, more or less-- it would display the local path asymmetry I described previously, but that might not be a deal-killer.

What I can't imagine is that operators of provider-provisioned subscriber gateway equipment will have any incentive to deploy such a routing protocol, and I can imagine several ruthless and selfish reasons for them to resist.

For starters, imagine this scenario: I'm an unhappy customer of ALFA Broadband, which is the largest incumbent carrier in my region, and I want to add the scrappy local underdog bargain provider, BRAVO Networks, as an egress to my existing HOMENET installation, so I can be multi-homed while I renumber and transition from one service provider to another.  When I sign up with BRAVO, they have to ask me: is this a new HOMENET, or do you have an existing HOMENET routing domain we need to join.

If I tell BRAVO it's a new HOMENET, then I don't get be to be multihomed with ALFA because their equipment won't forward packets with ALFA's source address either to ALFA's router or to the global Internet.  Sadness. Must tell them about the existing HOMENET installation then.

If I tell BRAVO it's an existing HOMENET, then I can only be multihomed if I can also get ALFA's router to admit BRAVO's new router to the routing domain it serves, but ALFA provisioned the thing and configured it for me. It's a crude black box as far as I'm concerned, and that's just how both they and I like it.  So, to complete this migration, I now have to call up ALFA and say to them, "Hi, I just signed up with your competitor, and I'd like for the router you installed for me, with whatever firmware it's running, to cooperate with their new router, running who knows what, in the HOMENET routing domain you set up for me years ago when I first signed up.  Would you please reconfigure?  Kthxbai!"

Any guesses what their response is likely to be?

I'm honestly not sure how we expect this to work.  It seems, either A) I have to be a highly technical mediator between ALFA Broadband and BRAVO Networks for the coordination of any HOMENET routing domain for which they're both going to provide access service, or B) they have to communicate directly with one another. Neither alternative seems very practical to me.

> this has been discussed on this list extensively.

Without apparent resolution or the production of a draft as far as I can see.  Hence my ongoing skepticism about this usage scenario.


--
james woodyatt 
core os networking


From mellon@fugue.com  Wed Nov 14 19:00:54 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CE11F0C49 for ; Wed, 14 Nov 2012 19:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFwFW7KwxLIQ for ; Wed, 14 Nov 2012 19:00:53 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4631F041A for ; Wed, 14 Nov 2012 19:00:53 -0800 (PST)
Received: from kali.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 184902380986; Wed, 14 Nov 2012 22:00:46 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: <156086CB-465E-45CE-8A9D-BBCF11A65050@apple.com>
Date: Wed, 14 Nov 2012 21:00:45 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 03:00:54 -0000

On Nov 14, 2012, at 4:44 PM, james woodyatt  wrote:
> My point is that it isn't sufficient to handle this problem at just =
the routers.  At a minimum, the *hosts* need to be told which default =
router to use with each source prefix. Right now the only mechanism that =
comes close to doing that is ICMPv6 Redirect, which isn't suitable for =
addressing this problem.

This is at least notionally a very easy thing to do, since the source =
address they are using is in a prefix that they configured on the basis =
of a router advertisement.   When would it make sense to send a packet =
with that source address to any router other than the one that =
advertised that prefix?


From jhw@apple.com  Wed Nov 14 19:41:42 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1C821E8039 for ; Wed, 14 Nov 2012 19:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.442
X-Spam-Level: 
X-Spam-Status: No, score=-110.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaRctXfyzEQQ for ; Wed, 14 Nov 2012 19:41:41 -0800 (PST)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7519921E802E for ; Wed, 14 Nov 2012 19:41:41 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDI00DN0FLGJFJ0@mail-out.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 19:41:40 -0800 (PST)
X-AuditID: 1180711d-b7fe16d00000096a-eb-50a46474bccb
Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay13.apple.com (Apple SCV relay) with SMTP id 40.11.02410.47464A05; Wed, 14 Nov 2012 19:41:40 -0800 (PST)
Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDI00ECJFLGI720@aniseed.apple.com> for homenet@ietf.org; Wed, 14 Nov 2012 19:41:40 -0800 (PST)
Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated.
From: james woodyatt 
In-reply-to: <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com>
Date: Wed, 14 Nov 2012 19:41:39 -0800
Message-id: <1FA5F1E0-B40C-4B72-8589-919C9EAF6C8F@apple.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>  
To: "homenet@ietf.org Group" 
X-Mailer: Apple Mail (2.1630)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAsrluSsiTAYPsEQ4v3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoErY+G98IIvrBUfp1s2MN5n6WLk4JAQMJFY3GzVxcgJZIpJXLi3 nq2LkYtDSGAKk8TuieuYIZxZTBLzVhxhAakSFgiQ+NS4D8xmFtCSWL/zOBOIzSugJ3Hk0gQm iBpLid9fnzCD2GwCKhLfLt8Fi3MK2Eq8//CKFcRmEVCVmPn1BxvEHAWJ5V1HoGZqSzx5d4EV 5DheARuJzRvSIG74zi7R+6YJrFdEQF/i6ZFfbBBXy0rsPnKPaQKj4CwkJ81CctIsJGMXMDKv YhQsSs1JrDQ01kssKMhJ1UvOz93ECA7HQtkdjPt/8h9iFOBgVOLhLbq+OECINbGsuDL3EKME B7OSCO+Lg0Ah3pTEyqrUovz4otKc1OJDjNIcLErivPGhSwKEBNITS1KzU1MLUotgskwcnFIN jIv9rqz5sep9nfUM/SWpEf+//jWa9mL9vyPc534x7j5csl2UrZCnU6q/STffPC2/yGmb2oaF ivcfbpb14iyddCZiP7vEz7W8hcqVH2e75Cs/OxYazi9iNeF95/Q07XmnZt17d5VHez5Xn8KZ jU3c/38bPXmpY7ZVea+fqnCCpUP+iaKiwBjfXUosxRmJhlrMRcWJAFAMqQZDAgAA
Cc: Ted Lemon 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 03:41:42 -0000

On Nov 14, 2012, at 19:00 , Ted Lemon  wrote:
> 
> When would it make sense to send a packet with that source address to any router other than the one that advertised that prefix?

What if there are many millions of hosts already in the field today, which currently choose the default router at the head of their priority-ordered default router list, regardless of whether that router's previous advertisements ever included a Prefix Information option with remaining preferred lifetime?

However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider.


--
james woodyatt 
core os networking


From teco@inf-net.nl  Wed Nov 14 21:56:29 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7062521F85EB for ; Wed, 14 Nov 2012 21:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.292
X-Spam-Level: 
X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlsZGF7fqDku for ; Wed, 14 Nov 2012 21:56:28 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB2321F85E8 for ; Wed, 14 Nov 2012 21:56:27 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id w11so551979bku.31 for ; Wed, 14 Nov 2012 21:56:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ubd6MRpI3U8b3DIMIOAoGlR5DpXndYj5hgVM/kV2Gx4=; b=K5r/lZB9zCVVN+WavVqUr3C7rO/vVacjJwlyqWzQpJvhR6nhn6u8HQyGTdMkQoGA3r pE9CRPCaNS81yFYRqDchtzOw1ZSbcsoftq9X1ZsKLNZ0FBInwoU0M5pa6FyZPUv/zwlG 0b8DnP83SKayLis0VSAX5W+yU6BPgRMiiM3WJNf8BcwyCvs7W7sLlh6ncOrPIMSYIqFA ctX2ItvXk+cR4o3EkAicxHGjXQsBQGHOaQ7hBCufzQnR26zBzA8gFBwya2Z4bzi/FdHg fe9zDZjGVISWctTz+eZYQNeh/XwS3W8WDd5T33VhBe8sEg0nvF7qKhzYNyPiFMmDP9yA iSeg==
Received: by 10.204.13.20 with SMTP id z20mr11355bkz.75.1352958986615; Wed, 14 Nov 2012 21:56:26 -0800 (PST)
Received: from [10.87.17.167] ([80.187.201.33]) by mx.google.com with ESMTPS id hm4sm7187370bkc.7.2012.11.14.21.56.23 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 21:56:25 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot 
In-Reply-To: <1FA5F1E0-B40C-4B72-8589-919C9EAF6C8F@apple.com>
Date: Thu, 15 Nov 2012 06:56:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FCD438E-1FD7-4396-A348-93B1D97A59B9@inf-net.nl>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <1FA5F1E0- B40C-4B72-8589-919C9EAF6C8F@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQmdSymxgmcxbhli1ObCR3MC4hiM84dgbW+j23vZpYz+EHo1dJV+IhzYkare6ZlFQZoWEgSk
Cc: "homenet@ietf.org Group" , Ted Lemon 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 05:56:29 -0000

There are a few proposals on the table, that let the routers solve the =
problem. Legacy hosts can send the packet to router ALFA or BRAVO. =
Misdirected packets, say packets with source address from ISP ALFA send =
to BRAVO are redirected to router ALFA. Such forwarding should not =
trigger an ICMP REDIRECT, as the forwarding was on source address. ICMP =
REDIRECT are applicable for guiding packets forwarded on destination =
address.

Teco


Op 15 nov. 2012, om 04:41 heeft james woodyatt het volgende geschreven:

> On Nov 14, 2012, at 19:00 , Ted Lemon  wrote:
>>=20
>> When would it make sense to send a packet with that source address to =
any router other than the one that advertised that prefix?
>=20
> What if there are many millions of hosts already in the field today, =
which currently choose the default router at the head of their =
priority-ordered default router list, regardless of whether that =
router's previous advertisements ever included a Prefix Information =
option with remaining preferred lifetime?
>=20
> However notionally easy this problem is to address, I imagine that =
practical matters, at some point, must rise to the top of the pile of =
points to consider.
>=20
>=20
> --
> james woodyatt 
> core os networking
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From brian.e.carpenter@gmail.com  Thu Nov 15 00:16:42 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463CE21F85BF for ; Thu, 15 Nov 2012 00:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.546
X-Spam-Level: 
X-Spam-Status: No, score=-101.546 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-ycgXmlh3mg for ; Thu, 15 Nov 2012 00:16:41 -0800 (PST)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 272AB21F853C for ; Thu, 15 Nov 2012 00:16:40 -0800 (PST)
Received: by mail-wg0-f42.google.com with SMTP id fm10so3020420wgb.1 for ; Thu, 15 Nov 2012 00:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xnf3LjmRGNtMWVoYlAXCvM3FInmbsYssUiIrNtCgDH4=; b=v7YSb9f6Ejd2VfZmQRDNgO7Sr4mVx9ruxZb1vuzpKtNc7RwjLhOLr2+RGpXHw69ihC CV7uI//ejzRqgi9pyBw8/zeoslP/kCEoAzU0+fnnyenNC+gEECsU/e/LJOnSxoxSbQpy rFEef3ozI6aFr+SUtuCN+HUcijoKs4lq8rtmDYLVwC14nGQ64/nYpI6wT2qcjMemHBRZ Bzm5sgOBob0hrt/1x3JXIxNSoyEklw2o/3/0troFMTIJuCUvNhnVOk2jxs1gI2M9AsIN vp/PDagN5RrQmcjUJtxTtyLxuUCJPSNlratdCQ+knfchuf2xsXlFP/fjPWPWedSKf7A6 N3eQ==
Received: by 10.180.24.193 with SMTP id w1mr29674693wif.22.1352967400038; Thu, 15 Nov 2012 00:16:40 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-172.as13285.net. [2.102.216.172]) by mx.google.com with ESMTPS id w5sm6159971wiz.10.2012.11.15.00.16.31 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 00:16:32 -0800 (PST)
Message-ID: <50A4A4EA.9050100@gmail.com>
Date: Thu, 15 Nov 2012 08:16:42 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: james woodyatt 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>			<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>			<50A32C7B.7000904@bogus.com>		 <156086CB-465E-45CE-8A9D-BBCF11A65050@appl e.com>
In-Reply-To: <156086CB-465E-45CE-8A9D-BBCF11A65050@apple.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 08:16:42 -0000

On 14/11/2012 22:44, james woodyatt wrote:
> On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  wrote:
>> I've always seen it to be solved via some kind of source based routing automatically discovered between the ISP routers.
> 
> 
> My point is that it isn't sufficient to handle this problem at just the routers.  At a minimum, the *hosts* need to be told which default router to use with each source prefix. 

Of course. I suggested this when MIF started out, and it's a MIF
issue still.

   Brian

From mattia.rossi.mailinglists@gmail.com  Thu Nov 15 02:19:02 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715DD21F8614 for ; Thu, 15 Nov 2012 02:19:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIt92UpBM+qQ for ; Thu, 15 Nov 2012 02:19:01 -0800 (PST)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86CBB21F8613 for ; Thu, 15 Nov 2012 02:19:01 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id c4so2197457qae.10 for ; Thu, 15 Nov 2012 02:19:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hvP7FziWD0OMoLhtAdPMy7lXX+fPfoA9CQLsKM+NqrM=; b=ihPaZCk8c1j36s5frCzUKbsXwnoFuKipBF2lkGHPiV9K4aTI5ORxg5nLiJR6DJPfwG SLnSOPFnidMg64eqd9BSqzZC3s9m/c1XJK7ezpMH1ty9srK0dh2UxA9qAkOS/sjQjQti AQgXRazfBgw0jXMaVc7e8T7+bQGuJI6nZwgpyZODo5Uvvx+1oZNKQU/hE0Qvj4xoBUeU mKXg0oi1I03Q+JAryevm7MO0ARyp2rc+3lAMmhDrakW7AcZCQz7sGwdkvqEvx+HFXpKw TFHLip8Ypga7wlsICVQAiYdTCulnyoQ5v2+1jpAgPveD+ocirugoh2wyk06Mjwv2Urg4 2zSA==
MIME-Version: 1.0
Received: by 10.49.70.234 with SMTP id p10mr500250qeu.30.1352974740921; Thu, 15 Nov 2012 02:19:00 -0800 (PST)
Received: by 10.49.85.167 with HTTP; Thu, 15 Nov 2012 02:19:00 -0800 (PST)
In-Reply-To: <50A4A4EA.9050100@gmail.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB-465E-45CE-8A9D-BBCF11A65050@apple.com> <50A4A4EA.9050100@gmail.com>
Date: Thu, 15 Nov 2012 11:19:00 +0100
Message-ID: 
From: Mattia Rossi 
To: Brian E Carpenter 
Content-Type: multipart/alternative; boundary=047d7b2e53bcd29dcc04ce85fa66
Cc: "homenet@ietf.org Group" , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 10:19:02 -0000

--047d7b2e53bcd29dcc04ce85fa66
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 14/11/2012 22:44, james woodyatt wrote:
> > On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  wrote:
> >> I've always seen it to be solved via some kind of source based routing
> automatically discovered between the ISP routers.
> >
> >
> > My point is that it isn't sufficient to handle this problem at just the
> routers.  At a minimum, the *hosts* need to be told which default router to
> use with each source prefix.
>
> Of course. I suggested this when MIF started out, and it's a MIF
> issue still.
>

The hosts do already select the correct router depending on the prefix.
They're tied together. An RA contains a prefix and router address. That's
what the host keeps in memory.
If it's two RA's one router becomes default, the other more specific. The
host/applications will also only use one prefix at a time, thus always send
the packets down the correct path.
In my experience it was always the same prefix, the one that got registered
first (if no preference was setup in the advertising router).
If the host is connected via two or more interfaces (so we're in MIF area
now), there will always be one preferred prefix, and interface, and the
outgoing routing will work.
If applications are able to chose a specific prefix (e.g. VPN) they usually
implement some source routing on the host anyways, and send the packets to
the router registered with that prefix.
If you have an application listening for incoming connections, then it's
important that the application is smart enough to use the address on which
the incoming connection arrived as source address, and not the default one
which might be on a different prefix to avoid asynchronous communication.
As far as I know this is already common practice. So I don't really see a
problem here, unless you want to do some fancy load sharing and play ping
pong with source addresses.
If there's only one interface which connects to a multihomed router, the
principle is the same, but the multihomed router must be able to perform
source address routing, and forward the packets down the right path. And
this is something I'm not too sure about routers can currently do.
Mat

--047d7b2e53bcd29dcc04ce85fa66
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpent=
er <brian.e.carpenter@gmail.com> wrote:




On 14/11/2012 22:44, james woodyatt wrote:
> On Nov=
 14, 2012, at 13:34 , Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>> I've always seen it t=
o be solved via some kind of source based routing automatically discovered =
between the ISP routers.

>
>
> My point is that it isn't sufficient to handle thi=
s problem at just the routers. =A0At a minimum, the *hosts* need to be told=
 which default router to use with each source prefix.

Of cours=
e. I suggested this when MIF started out, and it's a MIF

issue still.


=A0


The hosts do already select the correct router depending on the prefix=
. They're tied together. An RA contains a prefix and router address. Th=
at's what the host keeps in memory.=A0
If it's two=A0RA's on=
e router becomes default, the other more specific. The host/applications wi=
ll also only use one prefix at a time, thus always send the packets down th=
e correct path.

In my experience it was always the same prefix, the one that got registered=
 first (if no preference was setup in the advertising router).
If the ho=
st is connected via two or more interfaces (so we're in MIF area now), =
there will always be one preferred prefix, and interface, and the outgoing =
routing will work.



If applications are able to chose a specific prefix (e.g. VPN) they us=
ually implement some source routing on the host anyways, and send the packe=
ts to the router registered with that prefix.


If you have an application listening for incoming connections, then it=
's important that the application is=A0smart enough to use the address =
on which the incoming connection arrived as source address, and not=A0the d=
efault=A0one which might be on a different prefix to avoid asynchronous com=
munication. As far as I know this is already common practice. So I don'=
t really see a problem here, unless you want to do some fancy load sharing =
and play ping pong with source addresses.



If there's only one interface which connects to a multihomed route=
r, the principle is the same, but the multihomed router must be able to per=
form source address routing, and forward the packets down the right path. A=
nd this is something I'm not too sure about routers can currently do.



Mat


--047d7b2e53bcd29dcc04ce85fa66--

From otroan@employees.org  Thu Nov 15 02:51:34 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8F621F882D for ; Thu, 15 Nov 2012 02:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.27
X-Spam-Level: 
X-Spam-Status: No, score=-10.27 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMsVR0YF0ej3 for ; Thu, 15 Nov 2012 02:51:34 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A16DA21F85B3 for ; Thu, 15 Nov 2012 02:51:33 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAODIpFCQ/khM/2dsb2JhbABEw0mBCIIeAQEBAwESASc/EAsOOFcGNYdjBpwloA6RfGEDpFSBa4Jw
X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="146777167"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2012 10:51:32 +0000
Received: from dhcp-lys01-vla250-10-147-112-121.cisco.com (dhcp-lys01-vla250-10-147-112-121.cisco.com [10.147.112.121]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFApW0e007981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 10:51:32 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com>
Date: Thu, 15 Nov 2012 11:51:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 10:51:34 -0000

>> My point is that it isn't sufficient to handle this problem at just =
the routers.  At a minimum, the *hosts* need to be told which default =
router to use with each source prefix. Right now the only mechanism that =
comes close to doing that is ICMPv6 Redirect, which isn't suitable for =
addressing this problem.
>=20
> This is at least notionally a very easy thing to do, since the source =
address they are using is in a prefix that they configured on the basis =
of a router advertisement.   When would it make sense to send a packet =
with that source address to any router other than the one that =
advertised that prefix?

exactly. that's rule 5.5 in RFC6724.
when there are intermediate routers between the host and the border =
routers the routers need to use SADR (source address dependent routing).

all we can do in the IETF is to write documents. I think RFC6724 is =
sufficient, but please correct me if I'm wrong.

cheers,
Ole=

From swmike@swm.pp.se  Thu Nov 15 03:20:10 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A465421F89DD for ; Thu, 15 Nov 2012 03:20:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmtE-pKfySQ9 for ; Thu, 15 Nov 2012 03:20:10 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 06E1721F898C for ; Thu, 15 Nov 2012 03:20:09 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3454F9C; Thu, 15 Nov 2012 12:20:06 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2E6D99A; Thu, 15 Nov 2012 12:20:06 +0100 (CET)
Date: Thu, 15 Nov 2012 12:20:06 +0100 (CET)
From: Mikael Abrahamsson 
To: =?ISO-8859-15?Q?Ole_Tr=F8an?= 
In-Reply-To: <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-316739639-1352978406=:27834"
Cc: "homenet@ietf.org Group" , Ted Lemon , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 11:20:10 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-316739639-1352978406=:27834
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 15 Nov 2012, Ole Trøan wrote:

> exactly. that's rule 5.5 in RFC6724.

Looking at 5.5, I don't see how we could design anything at all that 
relies on 5.5 working. It's not even a SHOULD or a MUST as far as I can 
tell?

> all we can do in the IETF is to write documents. I think RFC6724 is 
> sufficient, but please correct me if I'm wrong.

It's my opinion that we can't rely on 5.5 working. Hosts need to not 
support 5.5 and things should still work.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-316739639-1352978406=:27834--

From brian.e.carpenter@gmail.com  Thu Nov 15 04:09:28 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC82F21F8525 for ; Thu, 15 Nov 2012 04:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.552
X-Spam-Level: 
X-Spam-Status: No, score=-101.552 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i12XjF5SG19g for ; Thu, 15 Nov 2012 04:09:28 -0800 (PST)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id F084A21F8577 for ; Thu, 15 Nov 2012 04:09:27 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id hm14so793886wib.13 for ; Thu, 15 Nov 2012 04:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wTqTo8Vs4lDLyvrtPgmH0kabwJMkMbq39NGT0WWhjvw=; b=xa1pygf+ygqp1zTudaEA2ntVEQLhWN+2YCLjbsYGVrC4zfyXnWn49XDHDMitJ9JPMQ cNFQC2PEl4NeHpWOyv8/LU94T7tRK0TujmJu91FSsBup/MhXfB0ibK/lXT+ns74Wjoxv rkK9dRkeWQbJi22BlGqCjedyKVDZZ/mVK9tohzeaLjARDHFv4O7PE1DqBcGsiPLa3VpL BHTSzpUigJOg4tEfXPHn/1Dr0ggq0xzqccFQmvaXlEtoUAvJQYWczITuXk6uN/uElxgS I/nXc5d5Ro/DMBflvi/y/iD+Lg62/AuPyh8XudZSZZjoQojPF6/l+mkKycsxYbltB/Tu wshg==
Received: by 10.216.211.27 with SMTP id v27mr403264weo.178.1352981366562; Thu, 15 Nov 2012 04:09:26 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-172.as13285.net. [2.102.216.172]) by mx.google.com with ESMTPS id fa9sm7048995wib.5.2012.11.15.04.09.25 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 04:09:25 -0800 (PST)
Message-ID: <50A4DB80.9090208@gmail.com>
Date: Thu, 15 Nov 2012 12:09:36 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mattia Rossi 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>		<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>			<50A32C7B.7000904@bogus.com>			<156086CB-465E-45CE-8A9D-BBCF11A65050@apple.com>	<50A4A4EA.9050100@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "homenet@ietf.org Group" , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 12:09:29 -0000

On 15/11/2012 10:19, Mattia Rossi wrote:
> On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> On 14/11/2012 22:44, james woodyatt wrote:
>>> On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  wrote:
>>>> I've always seen it to be solved via some kind of source based routing
>> automatically discovered between the ISP routers.
>>>
>>> My point is that it isn't sufficient to handle this problem at just the
>> routers.  At a minimum, the *hosts* need to be told which default router to
>> use with each source prefix.
>>
>> Of course. I suggested this when MIF started out, and it's a MIF
>> issue still.
>>
> 
> The hosts do already select the correct router depending on the prefix.
> They're tied together. An RA contains a prefix and router address. That's
> what the host keeps in memory.

Where is that specified? And what if the network is using DHCPv6
to provide such information?

The strongest statement I can find in RFC 6724 about this is a
MAY in section 7, which doesn't make this predictable.

> If it's two RA's one router becomes default, the other more specific. 

The two might be of equal standing and both offer a route to ::/0.

> The
> host/applications will also only use one prefix at a time, thus always send
> the packets down the correct path.

I don't believe that is fully specified either. Each new socket
might make a new choice.

> In my experience it was always the same prefix, the one that got registered
> first (if no preference was setup in the advertising router).
> If the host is connected via two or more interfaces (so we're in MIF area
> now), there will always be one preferred prefix, and interface, and the
> outgoing routing will work.

Then why is MIF still arguing?

> If applications are able to chose a specific prefix (e.g. VPN) they usually
> implement some source routing on the host anyways, and send the packets to
> the router registered with that prefix.

Sure, but we are worried here about zero-conf defaults.

> If you have an application listening for incoming connections, then it's
> important that the application is smart enough to use the address on which
> the incoming connection arrived as source address, and not the default one
> which might be on a different prefix to avoid asynchronous communication.
> As far as I know this is already common practice. 

Not good enough - it needs to be specified.

> So I don't really see a
> problem here, unless you want to do some fancy load sharing and play ping
> pong with source addresses.
> If there's only one interface which connects to a multihomed router, the
> principle is the same, but the multihomed router must be able to perform
> source address routing, and forward the packets down the right path. And
> this is something I'm not too sure about routers can currently do.

Indeed. Again, this needs specifying, as does behaviour when
there are multiple routers and one of them receives a packet
that should exit via another one.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/

   Brian

> Mat
> 

From mellon@fugue.com  Thu Nov 15 04:26:22 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9DC21F86D1 for ; Thu, 15 Nov 2012 04:26:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level: 
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0EAOhtmksye for ; Thu, 15 Nov 2012 04:26:22 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9C39221F869B for ; Thu, 15 Nov 2012 04:26:22 -0800 (PST)
Received: from kali.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id A63842380425; Thu, 15 Nov 2012 07:26:15 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: <1FA5F1E0-B40C-4B72-8589-919C9EAF6C8F@apple.com>
Date: Thu, 15 Nov 2012 07:26:13 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <97E88859-5B33-4419-BF72-7CBBB716B98A@fugue.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <1FA5F1E0- B40C-4B72-8589-919C9EAF6C8F@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 12:26:23 -0000

On Nov 14, 2012, at 10:41 PM, james woodyatt  wrote:
> However notionally easy this problem is to address, I imagine that =
practical matters, at some point, must rise to the top of the pile of =
points to consider.

Those hosts are broken.   They can't work in a multi-homed environment.  =
 Millions of hosts is very close to zero.   Do you want to wait to solve =
this problem until there are billions?

Most of those hosts are Macs, iOS devices and Android devices, which can =
be upgraded easily and are upgraded frequently (at least according to =
the stats I follow).   So please just fix this bug in iOS and MacOS, =
instead of arguing that the situation is hopeless.

We are building a network protocol suite for the future, not the =
present.   IPv4 was broken in various ways when it was at the stage of =
deployment IPv6 is at.   Measures were not taken to solve some of its =
problems in the IETF, and as a consequence ugly hacks were done in the =
field to work around these problems.

It is not our job to prognosticate about what might get deployed.   It =
is to try to figure out what should get deployed.   It is perfectly okay =
if what we propose takes ten years to see widespread deployment.


From mellon@fugue.com  Thu Nov 15 04:28:01 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B5B21F86D1 for ; Thu, 15 Nov 2012 04:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level: 
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO51vkoS8Ww1 for ; Thu, 15 Nov 2012 04:28:01 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCFA21F869B for ; Thu, 15 Nov 2012 04:28:01 -0800 (PST)
Received: from kali.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id BA9562380425; Thu, 15 Nov 2012 07:27:59 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 15 Nov 2012 07:27:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1499)
Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= , "homenet@ietf.org Group" , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 12:28:01 -0000

On Nov 15, 2012, at 6:20 AM, Mikael Abrahamsson  =
wrote:
> It's my opinion that we can't rely on 5.5 working. Hosts need to not =
support 5.5 and things should still work.

Why do hosts need to not support 5.5?


From swmike@swm.pp.se  Thu Nov 15 04:31:40 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D056A21F853C for ; Thu, 15 Nov 2012 04:31:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkWGYwW5SntE for ; Thu, 15 Nov 2012 04:31:40 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07321F8527 for ; Thu, 15 Nov 2012 04:31:40 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id EAB469C; Thu, 15 Nov 2012 13:31:38 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E3E6F9A; Thu, 15 Nov 2012 13:31:38 +0100 (CET)
Date: Thu, 15 Nov 2012 13:31:38 +0100 (CET)
From: Mikael Abrahamsson 
To: Ted Lemon 
In-Reply-To: <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: =?ISO-8859-15?Q?Ole_Tr=F8an?= , "homenet@ietf.org Group" , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 12:31:40 -0000

On Thu, 15 Nov 2012, Ted Lemon wrote:

> On Nov 15, 2012, at 6:20 AM, Mikael Abrahamsson  wrote:
>> It's my opinion that we can't rely on 5.5 working. Hosts need to not support 5.5 and things should still work.
>
> Why do hosts need to not support 5.5?

>From RFC6724:

"Discussion: An IPv6 implementation is not required to remember
       which next-hops advertised which prefixes.  The conceptual models
       of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
       have no such requirement.  Hence, Rule 5.5 is only applicable to
       implementations that track this information."

So since 5.5 is not a MUST (and most hosts today do not support 5.5 as far 
as I know), designing HOMENET based on 5.5 support on all hosts seems 
misdirected.

... or what am I missing?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From otroan@employees.org  Thu Nov 15 04:39:14 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF521F887F for ; Thu, 15 Nov 2012 04:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.271
X-Spam-Level: 
X-Spam-Status: No, score=-10.271 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TpREwvcGx1j for ; Thu, 15 Nov 2012 04:39:13 -0800 (PST)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC8421F887E for ; Thu, 15 Nov 2012 04:39:13 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABjipFCQ/khM/2dsb2JhbABEw0mBCIIeAQEBAwESASc/EAsOOFcGNYdjBpxGoA2RfGEDpFSBa4Jw
X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="9600587"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 15 Nov 2012 12:39:10 +0000
Received: from dhcp-lys01-vla250-10-147-112-121.cisco.com (dhcp-lys01-vla250-10-147-112-121.cisco.com [10.147.112.121]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFCdAvd030282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 12:39:10 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Thu, 15 Nov 2012 13:39:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" , Ted Lemon , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 12:39:14 -0000

Mikael,

>>> It's my opinion that we can't rely on 5.5 working. Hosts need to not =
support 5.5 and things should still work.
>>=20
>> Why do hosts need to not support 5.5?
>=20
> =46rom RFC6724:
>=20
> "Discussion: An IPv6 implementation is not required to remember
>      which next-hops advertised which prefixes.  The conceptual models
>      of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of =
[RFC4191]
>      have no such requirement.  Hence, Rule 5.5 is only applicable to
>      implementations that track this information."
>=20
> So since 5.5 is not a MUST (and most hosts today do not support 5.5 as =
far as I know), designing HOMENET based on 5.5 support on all hosts =
seems misdirected.
>=20
> ... or what am I missing?

how do you want it to work?

the tools we have currently are:
 - ICMP redirect
 - ICMP type 1, code 5
 - DHCP option for SAS/DAS policy
 - RFC6724 rule 5.5
 - RFC4191

what is missing?

cheers,
Ole=

From swmike@swm.pp.se  Thu Nov 15 04:54:21 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ACA21F88D1 for ; Thu, 15 Nov 2012 04:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level: 
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29QkZHAGPSrJ for ; Thu, 15 Nov 2012 04:54:21 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 350AC21F88CB for ; Thu, 15 Nov 2012 04:54:21 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 777039C; Thu, 15 Nov 2012 13:54:20 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 70A6B9A; Thu, 15 Nov 2012 13:54:20 +0100 (CET)
Date: Thu, 15 Nov 2012 13:54:20 +0100 (CET)
From: Mikael Abrahamsson 
To: =?ISO-8859-15?Q?Ole_Tr=F8an?= 
In-Reply-To: <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>  <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-244564182-1352984060=:27834"
Cc: "homenet@ietf.org Group" , Ted Lemon , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 12:54:22 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-244564182-1352984060=:27834
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 15 Nov 2012, Ole Trøan wrote:

> how do you want it to work?
>
> the tools we have currently are:
> - ICMP redirect
> - ICMP type 1, code 5
> - DHCP option for SAS/DAS policy
> - RFC6724 rule 5.5
> - RFC4191
>
> what is missing?

In my mind, I was looking at a new mechanism that the ISP routers used to 
tell each other what prefix they were advertising and handing out.

I couldn't find specifics on "DHCP option for SAS/DAS policy", so I don't 
know what that means exactly. Could you give a pointer? If I read 
 my guess is that it is 
more for the homenet router when they get DHCPv6-PD, but I might be 
mistaken?

But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather 
solve getting the correct traffic to the correct ISP router on the ISP 
router level, not in the hosts. So no ICMP redirects, just source based 
routing between the ISP routers.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-244564182-1352984060=:27834--

From otroan@employees.org  Thu Nov 15 05:04:33 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4169A21F88FC for ; Thu, 15 Nov 2012 05:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.273
X-Spam-Level: 
X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnZVk1gol7uO for ; Thu, 15 Nov 2012 05:04:32 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5902621F88E9 for ; Thu, 15 Nov 2012 05:04:32 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABznpFCQ/khR/2dsb2JhbABEw0mBCIIeAQEBAwESASc/BQsLDjhXBjWHYwYLnEGgDJF8YQOXGI08gWuCcA
X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="146783667"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2012 13:04:31 +0000
Received: from dhcp-lys01-vla250-10-147-112-121.cisco.com (dhcp-lys01-vla250-10-147-112-121.cisco.com [10.147.112.121]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAFD4Upe024912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 13:04:30 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Thu, 15 Nov 2012 14:04:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>  <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" , Ted Lemon , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 13:04:33 -0000

Mikael,

>> how do you want it to work?
>>=20
>> the tools we have currently are:
>> - ICMP redirect
>> - ICMP type 1, code 5
>> - DHCP option for SAS/DAS policy
>> - RFC6724 rule 5.5
>> - RFC4191
>>=20
>> what is missing?
>=20
> In my mind, I was looking at a new mechanism that the ISP routers used =
to tell each other what prefix they were advertising and handing out.

the kind of do with =
http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-03

but you can't a) expect the ISP routers to be able to discover each =
other (might not be on the same link), b) operated by the same entity.

> I couldn't find specifics on "DHCP option for SAS/DAS policy", so I =
don't know what that means exactly. Could you give a pointer? If I read =
 my guess is that it is =
more for the homenet router when they get DHCPv6-PD, but I might be =
mistaken?

https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/
this is more for multi-homing to non-congruent networks.

> But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd =
rather solve getting the correct traffic to the correct ISP router on =
the ISP router level, not in the hosts. So no ICMP redirects, just =
source based routing between the ISP routers.

we're not, the RFC6724 rule only applies when a host is connected to two =
routers with different upstream connectivity.
inside the home, i.e the host is behind two internal home routers, SADR =
is used to get to the correct border.

the only thing we're asking for here is that the hosts also do a =
simplified form for SADR when directly connected to multiple border =
routers.

cheers,
Ole=

From swmike@swm.pp.se  Thu Nov 15 05:21:51 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3431221F882E for ; Thu, 15 Nov 2012 05:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level: 
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNkNWA7A65nW for ; Thu, 15 Nov 2012 05:21:50 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id BC5E821F8772 for ; Thu, 15 Nov 2012 05:21:49 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 127599C; Thu, 15 Nov 2012 14:21:49 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0E1009A; Thu, 15 Nov 2012 14:21:49 +0100 (CET)
Date: Thu, 15 Nov 2012 14:21:49 +0100 (CET)
From: Mikael Abrahamsson 
To: =?ISO-8859-15?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>  <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>  
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1836403134-1352985709=:27834"
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 13:21:51 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-1836403134-1352985709=:27834
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 15 Nov 2012, Ole Trøan wrote:

>> In my mind, I was looking at a new mechanism that the ISP routers used 
>> to tell each other what prefix they were advertising and handing out.
>
> the kind of do with http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-03
>
> but you can't a) expect the ISP routers to be able to discover each other (might not be on the same link), b) operated by the same entity.

b) I never imagined, a) would be nice if that could be solved. I don't see 
any text in that draft regarding source based routing though.

>> I couldn't find specifics on "DHCP option for SAS/DAS policy", so I don't know what that means exactly. Could you give a pointer? If I read  my guess is that it is more for the homenet router when they get DHCPv6-PD, but I might be mistaken?
>
> https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/
> this is more for multi-homing to non-congruent networks.
>
>> But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather solve getting the correct traffic to the correct ISP router on the ISP router level, not in the hosts. So no ICMP redirects, just source based routing between the ISP routers.
>
> we're not, the RFC6724 rule only applies when a host is connected to two routers with different upstream connectivity.
> inside the home, i.e the host is behind two internal home routers, SADR is used to get to the correct border.

What happens if the host doesn't support 5.5?

> the only thing we're asking for here is that the hosts also do a 
> simplified form for SADR when directly connected to multiple border 
> routers.

So, I still can't find anything about a mechanism for routers in homenet 
for network-wide discovery of where a certain src address packet should be 
sent when it's destined for the default route (to the Internet).

Why can't OSPF be used (needs new functionality) so that all homenet 
routers learn a default-route per prefix, and thus have multiple default 
routes, and select which one to use depending on what the src address is 
of the packet? That would relieve the hosts of having to do anything at 
all (it is nice if they can do 5.5, but things wouldn't break without it). 
Basically "multi-topology" but instead of being one for IPv4 and one for 
IPv6, we now have one topology per ISP allocated prefix.

Or am I missing things again?

I would really like to avoid requiring functionality in the hosts as I see 
this as a big obstacle to get homenet implemented in real life.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-1836403134-1352985709=:27834--

From otroan@employees.org  Thu Nov 15 05:28:23 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFA921F88FA for ; Thu, 15 Nov 2012 05:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.274
X-Spam-Level: 
X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBcgS3yUuZUy for ; Thu, 15 Nov 2012 05:28:18 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD0B21F88EB for ; Thu, 15 Nov 2012 05:28:17 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADXtpFCQ/khM/2dsb2JhbABEw0mBCIIeAQEBAwESASc/EAsOOFcGNYdjBgucP6AKkXxhA5cYjTyBa4Jw
X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="78254209"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Nov 2012 13:28:16 +0000
Received: from dhcp-lys01-vla250-10-147-112-121.cisco.com (dhcp-lys01-vla250-10-147-112-121.cisco.com [10.147.112.121]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFDSGnV007920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 13:28:16 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Thu, 15 Nov 2012 14:28:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>  <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>   
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 13:28:23 -0000

Mikael,

>>> In my mind, I was looking at a new mechanism that the ISP routers =
used to tell each other what prefix they were advertising and handing =
out.
>>=20
>> the kind of do with =
http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-03
>>=20
>> but you can't a) expect the ISP routers to be able to discover each =
other (might not be on the same link), b) operated by the same entity.
>=20
> b) I never imagined, a) would be nice if that could be solved. I don't =
see any text in that draft regarding source based routing though.

correct, we haven't described that anywhere I think.

>>> I couldn't find specifics on "DHCP option for SAS/DAS policy", so I =
don't know what that means exactly. Could you give a pointer? If I read =
 my guess is that it is =
more for the homenet router when they get DHCPv6-PD, but I might be =
mistaken?
>>=20
>> https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/
>> this is more for multi-homing to non-congruent networks.
>>=20
>>> But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd =
rather solve getting the correct traffic to the correct ISP router on =
the ISP router level, not in the hosts. So no ICMP redirects, just =
source based routing between the ISP routers.
>>=20
>> we're not, the RFC6724 rule only applies when a host is connected to =
two routers with different upstream connectivity.
>> inside the home, i.e the host is behind two internal home routers, =
SADR is used to get to the correct border.
>=20
> What happens if the host doesn't support 5.5?

one of the other things in my list happens.
ICMP type 1,code 5
ICMP redirect
blackhole
.
.


>=20
>> the only thing we're asking for here is that the hosts also do a =
simplified form for SADR when directly connected to multiple border =
routers.
>=20
> So, I still can't find anything about a mechanism for routers in =
homenet for network-wide discovery of where a certain src address packet =
should be sent when it's destined for the default route (to the =
Internet).
>=20
> Why can't OSPF be used (needs new functionality) so that all homenet =
routers learn a default-route per prefix, and thus have multiple default =
routes, and select which one to use depending on what the src address is =
of the packet? That would relieve the hosts of having to do anything at =
all (it is nice if they can do 5.5, but things wouldn't break without =
it). Basically "multi-topology" but instead of being one for IPv4 and =
one for IPv6, we now have one topology per ISP allocated prefix.
>=20
> Or am I missing things again?

no, this is pretty much what we imagined, and what Markus has =
implemented and showed at the IETF.
the hosts would still do better if they support rule 5.5 when directly =
connected to the exits.

cheers,
Ole=

From swmike@swm.pp.se  Thu Nov 15 07:15:45 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F56D21F88EA for ; Thu, 15 Nov 2012 07:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level: 
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-wCq9HVxkDk for ; Thu, 15 Nov 2012 07:15:44 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 889B321F866F for ; Thu, 15 Nov 2012 07:15:44 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 633539C; Thu, 15 Nov 2012 16:15:42 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CD4889A; Thu, 15 Nov 2012 16:15:42 +0100 (CET)
Date: Thu, 15 Nov 2012 16:15:42 +0100 (CET)
From: Mikael Abrahamsson 
To: =?ISO-8859-15?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Message-ID: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>  <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>    
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1094139346-1352992422=:27834"
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 15:15:45 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-1094139346-1352992422=:27834
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 15 Nov 2012, Ole Trøan wrote:

>> Or am I missing things again?
>
> no, this is pretty much what we imagined, and what Markus has 
> implemented and showed at the IETF. the hosts would still do better if 
> they support rule 5.5 when directly connected to the exits.

Absolutely, 5.5 is a plus and gives one less hop in the path, but at least 
the packet will be ultimately delivered to its final destination.

So with the above "pretty much what we have imagined", is there consensus 
that this is the way to go, or this is still being debated?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-1094139346-1352992422=:27834--

From teco@inf-net.nl  Thu Nov 15 08:03:20 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD0321F8934 for ; Thu, 15 Nov 2012 08:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYeYTq-7aCQd for ; Thu, 15 Nov 2012 08:03:20 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9672C21F8514 for ; Thu, 15 Nov 2012 08:03:19 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id w11so868796bku.31 for ; Thu, 15 Nov 2012 08:03:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JEow8PfrTupiXxCsiZ9Q7LT0j0pTnoiTVdfwLtuubuY=; b=mlAKCKKDMh5yMXcq2E05HrqmswmUd+2Ii3lwwliBcFDthh8Nb7HR2ke74jgH9rYpQK iW1u/AZmDGnDIp+TUYKDr7ag37GGV0Gft3I4em2MRQDS43qXBPLG70LQZ6LgIUVBOZBb Uy3HVv0XgHorAXTC9++Z9hBAkSeL9TMdQFk1LzBNp6/RNmoACoaiAU7PV0XcqNJVmqTw 7JPCH8zIfErlJaX1Qc7A6FuFCWL2XrMq4SXceVxwkTYpPKpHUTNqJcTgiiKWtY4bb5fE Y10JeRgryIxNcWSoljKR5WhxVdBjgiOm3NSV9dXAw85JZwYUp1gOYiDh2H593wOxle+X nRAQ==
Received: by 10.204.148.7 with SMTP id n7mr636509bkv.76.1352995399141; Thu, 15 Nov 2012 08:03:19 -0800 (PST)
Received: from [172.20.10.3] ([84.241.201.240]) by mx.google.com with ESMTPS id u3sm4230571bkw.9.2012.11.15.08.02.51 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 08:03:18 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Teco Boot 
In-Reply-To: 
Date: Thu, 15 Nov 2012 16:56:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7950FBD4-98E5-48FD-A86B-38995A0071B9@inf-net.nl>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>  <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>     
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQnrum2/OJtHkhvN8832bfCxVIlIPIdEHPhslbvbS6tKufTEvUyy/0LF95OzT/oZLLLtSKpy
Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= , "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 16:03:20 -0000

Op 15 nov. 2012, om 16:15 heeft Mikael Abrahamsson het volgende =
geschreven:

> On Thu, 15 Nov 2012, Ole Tr=F8an wrote:
>=20
>>> Or am I missing things again?
>>=20
>> no, this is pretty much what we imagined, and what Markus has =
implemented and showed at the IETF. the hosts would still do better if =
they support rule 5.5 when directly connected to the exits.
>=20
> Absolutely, 5.5 is a plus and gives one less hop in the path, but at =
least the packet will be ultimately delivered to its final destination.
>=20
> So with the above "pretty much what we have imagined", is there =
consensus that this is the way to go, or this is still being debated?

Step 5.5 is half a solution.

Smarter hosts would make usage of more information, e.g. prefer a better =
path. BRDP makes such information available (again, no code yet). This =
is the superseded rule 8: when host knows better, it makes more sensible =
decisions. RFC 6724 page 13:

                                     For example, if the implementation
   somehow knows which source address will result in the "best"
   communications performance.

Remark on ICMP Redirect: when router forwards a packet back to a better =
first-hop, based on routing on source address, it MUST NOT send a =
redirect. If it would, it could influence first-hop for other source =
prefixes. That gets messy.=20

Teco

>=20
> --=20
> Mikael Abrahamsson    email: =
swmike@swm.pp.se_______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From otroan@cisco.com  Thu Nov 15 08:26:06 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AA021F8917 for ; Thu, 15 Nov 2012 08:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPDf9VfithcF for ; Thu, 15 Nov 2012 08:26:05 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 826FE21F88A9 for ; Thu, 15 Nov 2012 08:26:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1086; q=dns/txt; s=iport; t=1352996765; x=1354206365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5UnVVGr8odkM/Eso1Sz2ap8eIyjqkyWTTltwbJRwaQw=; b=PvvyvQcjQKAkR9wLqTSwi+Ad3z0gi901LLXjjf1RP5C6x6Zdg/Kw5t4i os+CgS93pRiQN/BATT867/RoTOiU/igf5n3kI77+8ldQkHUIlPQpV65iZ VHOEYHg4tpGpdSoKedLAN4KVo/KdzEL9RoAQXRT9axGCUc+UI21XIl8C4 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAE8WpVCtJXG+/2dsb2JhbABEgmy/VoEIgh4BAQEDAQEBAQ8BWwsFCwIBCA4KLicLJQIEDgUbB4dlBgEKnGigCQSMMYVLYQOIJY1XjliBa4JvgWQX
X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142818118"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 15 Nov 2012 16:26:03 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFGQ3FF020396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 16:26:03 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 10:26:03 -0600
From: "Ole Troan (otroan)" 
To: Mikael Abrahamsson 
Thread-Topic: [homenet] prefix assignment on home networks
Thread-Index: AQHNw0QaXhixUrGHnUWvzC0bDHMfKJfrFUbb
Date: Thu, 15 Nov 2012 16:26:03 +0000
Message-ID: <08AD2462-9A8E-463B-8BD9-F0B3E0B6C935@cisco.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>  	<156086CB- 465E-45CE-8A9D-BBCF11A65050@apple.com> <4C251D80-9D1A-40AB-A0AB-69A08CF33354@fugue.com> <60244A3C-D752-4AFD-A08F-7A51E0F9D582@employees.org>  <31FED55A-DF6F-4920-8DBB-283D69DFC17D@fugue.com>  <1D7EA7E7-8D07-4C94-91F7-13AF0A79A856@employees.org>    , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001
x-tm-as-result: No--38.304400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= , "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 16:26:06 -0000

Mikael,

Given that we want multiprefix multihoming with multiple prefixes, SADR is =
pretty much the only solution.=20

But consesus? Wouldn't dear getting anywhere close to that. :-)

Cheers,
Ole

On 15 Nov 2012, at 16:15, "Mikael Abrahamsson"  wrote:

> On Thu, 15 Nov 2012, Ole Tr=F8an wrote:
>=20
>>> Or am I missing things again?
>>=20
>> no, this is pretty much what we imagined, and what Markus has implemente=
d and showed at the IETF. the hosts would still do better if they support r=
ule 5.5 when directly connected to the exits.
>=20
> Absolutely, 5.5 is a plus and gives one less hop in the path, but at leas=
t the packet will be ultimately delivered to its final destination.
>=20
> So with the above "pretty much what we have imagined", is there consensus=
 that this is the way to go, or this is still being debated?
>=20
> --=20
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

From mattia.rossi.mailinglists@gmail.com  Thu Nov 15 08:45:03 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECA221F867F for ; Thu, 15 Nov 2012 08:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KYZN3+rN2Db for ; Thu, 15 Nov 2012 08:45:02 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE32821F8934 for ; Thu, 15 Nov 2012 08:45:01 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so1556521lbk.31 for ; Thu, 15 Nov 2012 08:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gP4qMMYkvYDLO79W2KdpzU7w+4MQJG5ycgmxdKFQV5o=; b=Q3QzMsWu4vWVSsS+0BlYhiS9Z92kFKYztq06B9fXLuuHFhswRNa+iFNIPoad7/9/12 5ZzHdvuJsyg2bhr8hNjuovQejR8qSuQkkJawkTCk9b7wzxI66iKOamJljbDWRk/MDjmo uLWLoM+C7HIJSatUD8DNNh7+rEff9liXJVuhqUyhTKkd/tGDpdNf0IRg63AlHTn6OEM7 1QocUzF1AQ13pX4DtmV4LE4PGXsVE/j4AdN8KdBtAStJRzazSlgGlT7giwov2bTMiDue jVwBgQxlUpOANnZvWOYa6MplrcUVCjpr2LgM+omREq6ra+hiroip8pKN6CPWd08ipRhv LhrQ==
Received: by 10.152.105.44 with SMTP id gj12mr1645455lab.19.1352997900663; Thu, 15 Nov 2012 08:45:00 -0800 (PST)
Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id b4sm6466757lbi.0.2012.11.15.08.44.58 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 08:44:59 -0800 (PST)
Message-ID: <50A50DF7.7060807@gmail.com>
Date: Thu, 15 Nov 2012 16:44:55 +0100
From: Mattia Rossi 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Brian E Carpenter 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>	<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>			<50A32C7B.7000904@bogus.com>			<156086CB-465E-45CE-8A9D-BBCF11A65050@apple.com>	<50A4A4EA.9050100@gmail.com>  <50A4DB80.9090208@gmail.com>
In-Reply-To: <50A4DB80.9090208@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 16:45:03 -0000

Am 15.11.2012 13:09, schrieb Brian E Carpenter:
> On 15/11/2012 10:19, Mattia Rossi wrote:
>> On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
>> brian.e.carpenter@gmail.com> wrote:
>>
>>> On 14/11/2012 22:44, james woodyatt wrote:
>>>> On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  wrote:
>>>>> I've always seen it to be solved via some kind of source based routing
>>> automatically discovered between the ISP routers.
>>>> My point is that it isn't sufficient to handle this problem at just the
>>> routers.  At a minimum, the *hosts* need to be told which default router to
>>> use with each source prefix.
>>>
>>> Of course. I suggested this when MIF started out, and it's a MIF
>>> issue still.
>>>
>> The hosts do already select the correct router depending on the prefix.
>> They're tied together. An RA contains a prefix and router address. That's
>> what the host keeps in memory.
> Where is that specified? And what if the network is using DHCPv6
> to provide such information?
>
> The strongest statement I can find in RFC 6724 about this is a
> MAY in section 7, which doesn't make this predictable.
It's exactly that section. The MAY obviously leaves a lot of room there. 
About DHCPv6 I don't know as I haven't tried that. Good question.
>
>> If it's two RA's one router becomes default, the other more specific.
> The two might be of equal standing and both offer a route to ::/0.
Well, actually true.. So, yes you're right, source based routing in the 
host should become a MUST.
>
>> The
>> host/applications will also only use one prefix at a time, thus always send
>> the packets down the correct path.
> I don't believe that is fully specified either. Each new socket
> might make a new choice.
Different apps might use different addresses, the same app probably not. 
They would reuse the same socket options all the time I believe. Anyhow, 
this is just what I've observed so far. It's not how it probably 
should/could be.
>
>> In my experience it was always the same prefix, the one that got registered
>> first (if no preference was setup in the advertising router).
>> If the host is connected via two or more interfaces (so we're in MIF area
>> now), there will always be one preferred prefix, and interface, and the
>> outgoing routing will work.
> Then why is MIF still arguing?
Because this behaviour is not ideal. It's what I've observed, and 
probably the result of an unfinished implementation due to lack of 
specification. Somebody had to fix things somehow.
>
>> If applications are able to chose a specific prefix (e.g. VPN) they usually
>> implement some source routing on the host anyways, and send the packets to
>> the router registered with that prefix.
> Sure, but we are worried here about zero-conf defaults.
Yes. Source based routing a MUST. I agree.
>
>> If you have an application listening for incoming connections, then it's
>> important that the application is smart enough to use the address on which
>> the incoming connection arrived as source address, and not the default one
>> which might be on a different prefix to avoid asynchronous communication.
>> As far as I know this is already common practice.
> Not good enough - it needs to be specified.
I agree. That might be something to add to RFC 3484. Unless  it's 
already in there, but I couldn't find it.
>
>> So I don't really see a
>> problem here, unless you want to do some fancy load sharing and play ping
>> pong with source addresses.
>> If there's only one interface which connects to a multihomed router, the
>> principle is the same, but the multihomed router must be able to perform
>> source address routing, and forward the packets down the right path. And
>> this is something I'm not too sure about routers can currently do.
> Indeed. Again, this needs specifying, as does behaviour when
> there are multiple routers and one of them receives a packet
> that should exit via another one.
>
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/
>
Ah, something new to read.
Thanks,

Mat

From bs7652@att.com  Thu Nov 15 09:28:47 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BB121F89D7 for ; Thu, 15 Nov 2012 09:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.572
X-Spam-Level: 
X-Spam-Status: No, score=-107.572 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoT6uHh8ZEGI for ; Thu, 15 Nov 2012 09:28:46 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 98B5E21F89D5 for ; Thu, 15 Nov 2012 09:28:44 -0800 (PST)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id c4625a05.2aaadd227940.910026.00-555.2558867.nbfkord-smmo07.seg.att.com (envelope-from );  Thu, 15 Nov 2012 17:28:44 +0000 (UTC)
X-MXL-Hash: 50a5264c323790be-10f12af2be3f7a4add165ba308ce2a510c503e36
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 24625a05.0.909950.00-451.2558643.nbfkord-smmo07.seg.att.com (envelope-from );  Thu, 15 Nov 2012 17:28:35 +0000 (UTC)
X-MXL-Hash: 50a526434cede94d-a9c78ccb9507064b18d5199185c609d67f6fc04c
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFHSY69024070; Thu, 15 Nov 2012 12:28:34 -0500
Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFHSJJo023585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 12:28:29 -0500
Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint04.pst.cso.att.com (RSA Interceptor); Thu, 15 Nov 2012 12:27:47 -0500
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 12:27:47 -0500
From: "STARK, BARBARA H" 
To: Randy Turner , "homenet@ietf.org" 
Thread-Topic: [homenet] prefix assignment on home networks
Thread-Index: AQHNwc1XLuVpg3VVeEmOydkPpp/P/JfosfQAgAA/WgCAAHRvAIAAXgyAgAAm7wCAABSdAIAABN2A///nk4A=
Date: Thu, 15 Nov 2012 17:27:46 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.156.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=AOaE+nVk c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=C3VREvb7-QsA:10 a=sSpCeFR3TLIA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=wdKPuTGemoUA:10 a=48vgC7mUAAAA:8 a=febilzorAAAA:8]
X-AnalysisOut: [ a=pGLkceISAAAA:8 a=kKvtFM5SvmQTgo4-P20A:9 a=CjuIK1q_8ugA:]
X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=wnnrB20iCeYA:10 a=MSl-tDqOz04A:10 a]
X-AnalysisOut: [=AQPKBmBaaH26EqhZ:21 a=hKUJpdDBiFnqlAlc:21]
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 17:28:47 -0000

Chiming in as a consumer... [the views represented are 100% my own, individ=
ual, consumer perspective]
I'm a consumer of wireless service. I hear people engaged in wireless netwo=
rks saying things like "Prefix delegation isn't till 3GPP release 10; the b=
est a device can do till then is assume that they have the prefix advertise=
d by the RA" and "wireless connections will use a single stack -- either IP=
v4 or IPv6 but not both". I sure wish I could use wireless as a backup for =
my home network if I lose my wireline connections. Of course, with the devi=
ces I have (my smart phone for everyday use; I'm too cheap to go out and ge=
t an additional wireless service or specialized data-only device), I'd need=
 to use "tethering" which is limited to something like 3 devices, that all =
have to use Wi-Fi. I have more than 3 devices, and not all Wi-Fi, so what I=
'd probably do is use this Wi-Fi/Ethernet bridge I have lying around the ho=
use (I've used it at various times to provide Wi-Fi connectivity to devices=
 that don't support Wi-Fi), and plug the Ethernet side of that into the WAN=
 port of a router. That router looks like a single device from a tethering =
perspective, and I can do whatever I want behind it, without, um, permissio=
n from anyone else. But when (single stack) IPv6 gets offered on that tethe=
r, that router will only have a single /128 address. Hmm.

I'm also a consumer of 2 wireline broadband connections. Each has its own r=
outer. The routers are totally mine. Neither router is supplied by the asso=
ciated provider (routers aren't even an option from either provider). They =
have no connection to each other (because I buy cheap off-the-shelf consume=
r stuff, and cheap consumer stuff does nothing for multihoming today). Both=
 broadband connections currently support 6rd. From one, I end up with a /64=
. From the other I end up with a /60.

I've dedicated one of my wireline services to me (the low bandwidth one wit=
h the /60), and the other one (the high bandwidth with a /64) is for me and=
 everyone else in my family and the rest of my home network. The printer is=
 connected to the 2nd, so I have to switch my Wi-Fi connection to the other=
 when I want to print. How annoying. I have, in the past, put other routers=
 behind the general home network connection (the one from the /64 provider)=
, like when I needed a Wi-Fi WEP connection for an ancient TiVo, and, well,=
 for other reasons. I have various cheap routers lying around the house, so=
 I prefer to just use them when the need strikes, rather than go and get a =
new box that can do it all. With IPv6, I will need new routers, but I'll be=
 going cheap on them, too. None of the apps behind the 2nd router are sensi=
tive to dual NAT, so there's no need to do anything other than put them on =
separate subnets. All cheap routers support that, and it's pretty easy. Muc=
h easier than making them bridged APs (which has often caused mysterious DN=
S and disappearing IPv4 connectivity issues that I never bothered figuring =
out since dual NAT worked just fine).

My reasons for having 2 connections aren't all that geeky. My family's Netf=
lix and MMORPG gaming addictions were impacting my ability to work at home,=
 by using up all the bandwidth. As my family's home networking "guru", knew=
 I had choices of doing QoS (which would make me happy but not them, and re=
quire a more expensive router that could do QoS -- I know this because I've=
 seen those boxes at Fry's that say they do QoS), having a single connectio=
n with more bandwidth, or adding a 2nd connection with more bandwidth. I ch=
ose to get a 2nd connection, because it wasn't that costly and provided me =
with redundancy, in this era of Internet connectivity as a need rather than=
 a want. I know I'm not alone in subscribing to multiple broadband services=
 -- several of my neighbors also work at home (or run businesses from their=
 home) and have redundancy.=20

I don't know how long the lack of wireless PD delegation will exist, or how=
 long my wireline IPv6 will be offered via 6rd.
All I know is, this is my world as it currently exists.
Y'all know that "Serenity Prayer" about accepting that which you cannot cha=
nge, having the courage to change what you can, and the wisdom to know the =
difference? Well, I accept that I can't change those access networks. I get=
 what they give me, and I don't hold my breath waiting for them to change. =
But I *can* change the devices in my home network. As long as I don't have =
to pay a lot to do so.=20

Anyway, I'd really like it if I could get ISP-provided IPv6 working behind =
that router that I describe on the wireless connection (the one that will g=
et a single-stack /128 address behind the tethering device -- and I think I=
'd rather do IPv6 to IPv6 Internet endpoints, even if it is NAT66 on the ro=
uter, rather than go through NAT64 somewhere; and I really don't want to do=
 "NAT464" to get to IPv4 endpoints behind a single-stack IPv6 connection). =
I'd also like to do IPv6 to IPv6 endpoints from behind a 2nd router behind =
my general-purpose home network router (the one that gets a /64 from 6rd). =
Right now, I can't, AFAIK. Since I have all of these connections, it would =
be nice if I didn't have to physically move between them, but could have th=
em connected together and just configure a few simple choices to make thing=
s work (the way *I* want them to work -- so I do expect some simple configu=
ration).=20

Getting my multihoming working is more of a "nice to have" right now, thoug=
h, since I've got to keep IPv4 working right, and I don't see anything bein=
g done to solve IPv4 multihoming. I thinks that's something that I won't bo=
ther trying to change. The cascaded router scenario (in the tethered single=
-stack wireless network and in my general purpose home network) works today=
 with IPv4. But not with IPv6. That's a problem. The /64 is very real in bo=
th of those cases, and breath-holding or crying about it just doesn't seem =
to be a very effective approach.=20

That's my consumer wish list. Thanks for listening. Maybe I'll put this in =
my letter to Santa.
Barbara

> -----Original Message-----
> From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On
> Behalf Of Randy Turner
> Sent: Wednesday, November 14, 2012 1:58 PM
> To: homenet@ietf.org
> Subject: Re: [homenet] prefix assignment on home networks
>=20
>=20
> I'm not against one or more  /64 bit prefixes for a home net, if everyone=
 else
> (including the ISPs) think that home networks should be able to scale up =
to
> 18,446,744,073,709,551,615 hosts, I'm completely on board.  It's not my
> resource, so I'll take all they give me.  :)  It would be nice to have an=
 AT&T,
> Verizon, or some other major provider chime in to say they're on board wi=
th
> the assumptions we're making.  Maybe they already have, I've been away
> from the list for awhile, or maybe they've indicated this allocation stra=
tegy in
> some other forum.  I'm old school and I'm not used to having publicly
> routable address space to burn.
>=20
> Randy
>=20
> On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote:
>=20
> > I have a /48 at home, on a retail ISP, right now.  I know, one data poi=
nt does
> not a trend make, but it is a proof by example that some ISP is doing tha=
t.
> >
> > Andrew
> >
> > On 15/11/2012, at 6:27 AM, Randy Turner 
> wrote:
> >
> >>
> >> Have their been any ISPs that have come forward to discuss their
> consumer IPv6 allocation plans?  I don't think we should wrap ourselves
> around a model that says, "yeah, we need multiple /64s for consumers
> because that's the way a particular protocol works (SLAAC).   Maybe we ne=
ed
> another method. One /64 for a home network seems like overkill regarding
> address space utilization -- A /32 would be overkill.  I know some folks =
think
> we have more address space than we'll ever use, but gee....
> >>
> >> Randy
> >>
> >>
> >> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
> >>
> >>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter
>  wrote:
> >>>> On 14/11/2012 02:34, Randy Turner wrote:
> >>>>> I was thinking that, in an effort to reduce scope to something we c=
an
> deal with for now, that a /64 would be big enough
> >>>>
> >>>> It simply isn't, because it doesn't allow subnetting in the
> home/car/small office or whatever.
> >>>
> >>> I don't see the point in working on the /64 case-if that's all we're =
trying
> to accomplish, we've already accomplished it.   The interesting work
> Homenet is doing is in fact trying to solve the prefix distribution and
> automatic setup problem.   It's true that this is a hard problem.   It's =
also true
> that if we don't specify a solution, people will attempt to solve it in t=
heir own
> ways.   And if they do that, we will wind up in the situation that Jim fo=
und
> himself in with his broken box with its own built-in DHCP server.
> >>>
> >>> BTW, a little more on that topic: the reason that two DHCP servers on
> the same wire broke Jim's network in a flaky way is that IPv4 doesn't han=
dle
> the multi-homing case.   IPv6 deliberately places the multi-homing case i=
n-
> scope.   This creates a bit of a problem for legacy apps that do not supp=
ort
> multi-homing, but it also creates the winning situation that if one devic=
e is
> advertising a provisioning domain that doesn't work, applications that do
> correctly handle multi-homing will simply use a different provisioning
> domain.
> >>>
> >>> _______________________________________________
> >>> homenet mailing list
> >>> homenet@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/homenet
> >>>
> >>
> >> _______________________________________________
> >> homenet mailing list
> >> homenet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/homenet
> >
> >
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

From joelja@bogus.com  Thu Nov 15 09:36:59 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFF221F897C for ; Thu, 15 Nov 2012 09:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.499
X-Spam-Level: 
X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8yOGAbHBX6b for ; Thu, 15 Nov 2012 09:36:58 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6121F89CA for ; Thu, 15 Nov 2012 09:36:58 -0800 (PST)
Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAFHanBq069988 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 15 Nov 2012 17:36:49 GMT (envelope-from joelja@bogus.com)
Message-ID: <50A5282C.1020601@bogus.com>
Date: Thu, 15 Nov 2012 09:36:44 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "STARK, BARBARA H" 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>  <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 15 Nov 2012 17:36:49 +0000 (UTC)
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 17:36:59 -0000

On 11/15/12 9:27 AM, STARK, BARBARA H wrote:
> Chiming in as a consumer... [the views represented are 100% my own, ind=
ividual, consumer perspective]
> I'm a consumer of wireless service. I hear people engaged in wireless n=
etworks saying things like "Prefix delegation isn't till 3GPP release 10;=
 the best a device can do till then is assume that they have the prefix a=
dvertised by the RA" and "wireless connections will use a single stack --=
 either IPv4 or IPv6 but not both". I sure wish I could use wireless as a=
 backup for my home network if I lose my wireline connections. Of course,=
 with the devices I have (my smart phone for everyday use; I'm too cheap =
to go out and get an additional wireless service or specialized data-only=
 device), I'd need to use "tethering" which is limited to something like =
3 devices, that all have to use Wi-Fi. I have more than 3 devices, and no=
t all Wi-Fi, so what I'd probably do is use this Wi-Fi/Ethernet bridge I =
have lying around the house (I've used it at various times to provide Wi-=
Fi connectivity to devices that don't support Wi-Fi), and plug the Ethern=
et side of that into the WAN port of a rout
>   er. That router looks like a single device from a tethering perspecti=
ve, and I can do whatever I want behind it, without, um, permission from =
anyone else. But when (single stack) IPv6 gets offered on that tether, th=
at router will only have a single /128 address. Hmm.
http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal.
>
> I'm also a consumer of 2 wireline broadband connections. Each has its o=
wn router. The routers are totally mine. Neither router is supplied by th=
e associated provider (routers aren't even an option from either provider=
). They have no connection to each other (because I buy cheap off-the-she=
lf consumer stuff, and cheap consumer stuff does nothing for multihoming =
today). Both broadband connections currently support 6rd. From one, I end=
 up with a /64. From the other I end up with a /60.
>
> I've dedicated one of my wireline services to me (the low bandwidth one=
 with the /60), and the other one (the high bandwidth with a /64) is for =
me and everyone else in my family and the rest of my home network. The pr=
inter is connected to the 2nd, so I have to switch my Wi-Fi connection to=
 the other when I want to print. How annoying. I have, in the past, put o=
ther routers behind the general home network connection (the one from the=
 /64 provider), like when I needed a Wi-Fi WEP connection for an ancient =
TiVo, and, well, for other reasons. I have various cheap routers lying ar=
ound the house, so I prefer to just use them when the need strikes, rathe=
r than go and get a new box that can do it all. With IPv6, I will need ne=
w routers, but I'll be going cheap on them, too. None of the apps behind =
the 2nd router are sensitive to dual NAT, so there's no need to do anythi=
ng other than put them on separate subnets. All cheap routers support tha=
t, and it's pretty easy. Much easier than m
>   aking them bridged APs (which has often caused mysterious DNS and dis=
appearing IPv4 connectivity issues that I never bothered figuring out sin=
ce dual NAT worked just fine).
>
> My reasons for having 2 connections aren't all that geeky. My family's =
Netflix and MMORPG gaming addictions were impacting my ability to work at=
 home, by using up all the bandwidth. As my family's home networking "gur=
u", knew I had choices of doing QoS (which would make me happy but not th=
em, and require a more expensive router that could do QoS -- I know this =
because I've seen those boxes at Fry's that say they do QoS), having a si=
ngle connection with more bandwidth, or adding a 2nd connection with more=
 bandwidth. I chose to get a 2nd connection, because it wasn't that costl=
y and provided me with redundancy, in this era of Internet connectivity a=
s a need rather than a want. I know I'm not alone in subscribing to multi=
ple broadband services -- several of my neighbors also work at home (or r=
un businesses from their home) and have redundancy.
>
> I don't know how long the lack of wireless PD delegation will exist, or=
 how long my wireline IPv6 will be offered via 6rd.
> All I know is, this is my world as it currently exists.
> Y'all know that "Serenity Prayer" about accepting that which you cannot=
 change, having the courage to change what you can, and the wisdom to kno=
w the difference? Well, I accept that I can't change those access network=
s. I get what they give me, and I don't hold my breath waiting for them t=
o change. But I *can* change the devices in my home network. As long as I=
 don't have to pay a lot to do so.
>
> Anyway, I'd really like it if I could get ISP-provided IPv6 working beh=
ind that router that I describe on the wireless connection (the one that =
will get a single-stack /128 address behind the tethering device -- and I=
 think I'd rather do IPv6 to IPv6 Internet endpoints, even if it is NAT66=
 on the router, rather than go through NAT64 somewhere; and I really don'=
t want to do "NAT464" to get to IPv4 endpoints behind a single-stack IPv6=
 connection). I'd also like to do IPv6 to IPv6 endpoints from behind a 2n=
d router behind my general-purpose home network router (the one that gets=
 a /64 from 6rd). Right now, I can't, AFAIK. Since I have all of these co=
nnections, it would be nice if I didn't have to physically move between t=
hem, but could have them connected together and just configure a few simp=
le choices to make things work (the way *I* want them to work -- so I do =
expect some simple configuration).
>
> Getting my multihoming working is more of a "nice to have" right now, t=
hough, since I've got to keep IPv4 working right, and I don't see anythin=
g being done to solve IPv4 multihoming. I thinks that's something that I =
won't bother trying to change. The cascaded router scenario (in the tethe=
red single-stack wireless network and in my general purpose home network)=
 works today with IPv4. But not with IPv6. That's a problem. The /64 is v=
ery real in both of those cases, and breath-holding or crying about it ju=
st doesn't seem to be a very effective approach.
>
> That's my consumer wish list. Thanks for listening. Maybe I'll put this=
 in my letter to Santa.
> Barbara
>
>> -----Original Message-----
>> From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On
>> Behalf Of Randy Turner
>> Sent: Wednesday, November 14, 2012 1:58 PM
>> To: homenet@ietf.org
>> Subject: Re: [homenet] prefix assignment on home networks
>>
>>
>> I'm not against one or more  /64 bit prefixes for a home net, if every=
one else
>> (including the ISPs) think that home networks should be able to scale =
up to
>> 18,446,744,073,709,551,615 hosts, I'm completely on board.  It's not m=
y
>> resource, so I'll take all they give me.  :)  It would be nice to have=
 an AT&T,
>> Verizon, or some other major provider chime in to say they're on board=
 with
>> the assumptions we're making.  Maybe they already have, I've been away=

>> from the list for awhile, or maybe they've indicated this allocation s=
trategy in
>> some other forum.  I'm old school and I'm not used to having publicly
>> routable address space to burn.
>>
>> Randy
>>
>> On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote:
>>
>>> I have a /48 at home, on a retail ISP, right now.  I know, one data p=
oint does
>> not a trend make, but it is a proof by example that some ISP is doing =
that.
>>> Andrew
>>>
>>> On 15/11/2012, at 6:27 AM, Randy Turner 
>> wrote:
>>>> Have their been any ISPs that have come forward to discuss their
>> consumer IPv6 allocation plans?  I don't think we should wrap ourselve=
s
>> around a model that says, "yeah, we need multiple /64s for consumers
>> because that's the way a particular protocol works (SLAAC).   Maybe we=
 need
>> another method. One /64 for a home network seems like overkill regardi=
ng
>> address space utilization -- A /32 would be overkill.  I know some fol=
ks think
>> we have more address space than we'll ever use, but gee....
>>>> Randy
>>>>
>>>>
>>>> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
>>>>
>>>>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter
>>  wrote:
>>>>>> On 14/11/2012 02:34, Randy Turner wrote:
>>>>>>> I was thinking that, in an effort to reduce scope to something we=
 can
>> deal with for now, that a /64 would be big enough
>>>>>> It simply isn't, because it doesn't allow subnetting in the
>> home/car/small office or whatever.
>>>>> I don't see the point in working on the /64 case-if that's all we'r=
e trying
>> to accomplish, we've already accomplished it.   The interesting work
>> Homenet is doing is in fact trying to solve the prefix distribution an=
d
>> automatic setup problem.   It's true that this is a hard problem.   It=
's also true
>> that if we don't specify a solution, people will attempt to solve it i=
n their own
>> ways.   And if they do that, we will wind up in the situation that Jim=
 found
>> himself in with his broken box with its own built-in DHCP server.
>>>>> BTW, a little more on that topic: the reason that two DHCP servers =
on
>> the same wire broke Jim's network in a flaky way is that IPv4 doesn't =
handle
>> the multi-homing case.   IPv6 deliberately places the multi-homing cas=
e in-
>> scope.   This creates a bit of a problem for legacy apps that do not s=
upport
>> multi-homing, but it also creates the winning situation that if one de=
vice is
>> advertising a provisioning domain that doesn't work, applications that=
 do
>> correctly handle multi-homing will simply use a different provisioning=

>> domain.
>>>>> _______________________________________________
>>>>> homenet mailing list
>>>>> homenet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>>
>>>> _______________________________________________
>>>> homenet mailing list
>>>> homenet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



From mellon@fugue.com  Thu Nov 15 09:41:13 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3829221F84FC for ; Thu, 15 Nov 2012 09:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level: 
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKakc6o5emoI for ; Thu, 15 Nov 2012 09:41:12 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26821F8D6F for ; Thu, 15 Nov 2012 09:41:12 -0800 (PST)
Received: from kali.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 49AB32380986; Thu, 15 Nov 2012 12:41:10 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com>
Date: Thu, 15 Nov 2012 12:41:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <7718867B-3132-4BB6-904D-E3F2DC5C1710@fugue.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>  <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 17:41:13 -0000

On Nov 15, 2012, at 12:27 PM, "STARK, BARBARA H"  wrote:
> The cascaded router scenario (in the tethered single-stack wireless =
network and in my general purpose home network) works today with IPv4. =
But not with IPv6. That's a problem. The /64 is very real in both of =
those cases, and breath-holding or crying about it just doesn't seem to =
be a very effective approach.=20

Thanks for the long expression of your use case=97I think it's a useful =
example.

I do want to take exception to one thing here, though: cascaded routers =
do not work with IPv4.   They work with IPv4+NAT, or with IPv4+bridge.   =
And "work" is relative, as your use case story shows.

Chances are that part of the reason you had to go to a multi-homed =
connection was that your router configuration was suffering from =
bufferbloat, and so despite you having a decent connection to your ISP, =
you were experiencing congestion.   This is, unfortunately, very typical =
of home routers nowadays.

Adding a second entire network for your own private use worked, but it =
was probably overkill.   If you are feeling adventurous, you might want =
to try setting up a CeroWRT network with properly tuned buffers and see =
if it changes things for you.   I can't promise that it does=97I'm just =
a happy user of CeroWRT, not an expert on bufferbloat.   But the network =
behavior you are describing sounds a lot like what I was trying to cure =
when I installed CeroWRT.

What does this have to do with the homenet discussion?   We should be =
proposing a solution that doesn't perpetuate the architecture that leads =
to bufferbloat.


From bs7652@att.com  Thu Nov 15 10:15:28 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF5E21F89FF for ; Thu, 15 Nov 2012 10:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.657
X-Spam-Level: 
X-Spam-Status: No, score=-106.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRlvVghIt1bI for ; Thu, 15 Nov 2012 10:15:27 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id DB13221F8475 for ; Thu, 15 Nov 2012 10:15:26 -0800 (PST)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id e3135a05.2aaac6a03940.930720.00-580.2617580.nbfkord-smmo07.seg.att.com (envelope-from );  Thu, 15 Nov 2012 18:15:26 +0000 (UTC)
X-MXL-Hash: 50a5313e3c31d34e-23bbb9db599f946016c8e426b232dc32371d64d6
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 33135a05.0.930661.00-417.2617394.nbfkord-smmo07.seg.att.com (envelope-from );  Thu, 15 Nov 2012 18:15:18 +0000 (UTC)
X-MXL-Hash: 50a5313655bcec9d-70d9496de1e1a9d072aac39fbb907a7c2cbabbd9
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFIFFSI018382; Thu, 15 Nov 2012 13:15:15 -0500
Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFIF1Mf018027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 13:15:06 -0500
Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by sflint04.pst.cso.att.com (RSA Interceptor); Thu, 15 Nov 2012 13:14:50 -0500
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 13:14:47 -0500
From: "STARK, BARBARA H" 
To: Ted Lemon 
Thread-Topic: [homenet] prefix assignment on home networks
Thread-Index: AQHNwc1XLuVpg3VVeEmOydkPpp/P/JfosfQAgAA/WgCAAHRvAIAAXgyAgAAm7wCAABSdAIAABN2A///nk4CAAZU8gP//reoA
Date: Thu, 15 Nov 2012 18:14:46 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6112F5D4264@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>  <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com> <7718867B-3132-4BB6-904D-E3F2DC5C1710@fugue.com>
In-Reply-To: <7718867B-3132-4BB6-904D-E3F2DC5C1710@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.156.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=AOaE+nVk c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=C3VREvb7-QsA:10 a=sSpCeFR3TLIA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=wdKPuTGemoUA:10 a=NyG-T6F2jp6rMes976UA:9 a=CjuIK1]
X-AnalysisOut: [q_8ugA:10]
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 18:15:28 -0000

> Chances are that part of the reason you had to go to a multi-homed
> connection was that your router configuration was suffering from
> bufferbloat, and so despite you having a decent connection to your ISP, y=
ou
> were experiencing congestion.   This is, unfortunately, very typical of h=
ome
> routers nowadays.

No, my connection to my first ISP is 1.5Mbps downstream. The 2nd connection=
 is 30Mbps downstream. A single Netflix stream had no difficulty taking up =
the entire 1.5Mbps. Unfortunately, the technology used to offer the 1.5Mbps=
 service could only be upgraded to a maximum of 3Mbps. I figured Netflix co=
uld probably overrun that too, so I went with the 2nd connection. I could h=
ave just switched everything to the 2nd connection (my routers haven't had =
any difficulty with doing everything asked of them on the 30 Mbps connectio=
n -- Netflix users are very happy and the shrieks from the MMORPG addict mo=
urning death due to lousy Internet connectivity have stopped), but I like t=
he redundancy of having 2, and the 1.5 Mbps service is very inexpensive.

> Adding a second entire network for your own private use worked, but it wa=
s
> probably overkill.  =20

Not overkill. Just redundant. But I and my family need our Internet. We can=
not live without it. Redundancy is good when it isn't expensive.

> If you are feeling adventurous, you might want to try
> setting up a CeroWRT network with properly tuned buffers and see if it
> changes things for you.   I can't promise that it does-I'm just a happy u=
ser of
> CeroWRT, not an expert on bufferbloat.   But the network behavior you are
> describing sounds a lot like what I was trying to cure when I installed
> CeroWRT.

Hmm. I'm busy with other adventures right now, and not feeling the need. I'=
ll keep it in mind, though.
=20
> What does this have to do with the homenet discussion?   We should be
> proposing a solution that doesn't perpetuate the architecture that leads =
to
> bufferbloat.

/64s are very real, and the need to accommodate them appears to be relative=
ly near-term. Multi-homing is real. Improved multi-homing experience is des=
irable, but not an immediate need.
A diagnosis of bufferbloat sounds difficult to cure (requiring adventures a=
nd acronyms), so I think I'll stick with my state of denial regarding that.
Barbara

From gettysjim@gmail.com  Thu Nov 15 10:35:09 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345CA21F8473 for ; Thu, 15 Nov 2012 10:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN4K-+eCHOSt for ; Thu, 15 Nov 2012 10:35:08 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9CD721F845A for ; Thu, 15 Nov 2012 10:35:07 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fc26so2163380vbb.31 for ; Thu, 15 Nov 2012 10:35:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=40smJGfPVPd9lMShjMMKBGXhK2tvSLX4UsWLLoJkb6A=; b=NLk7xE0qWNZi59saRPF1/JWx6VUfNt2BODqaToFGlJ8zXXW5qkOcpQwz7AZuJdAo5j xF8XtZHCY/3jEWxEU4vOxdyPfemsYHh+38UzxnjOSYKXHi7OmN6v7UlzIQJCafqzRDC8 yjhjhfK1nggKXFKNvCINibAIwUV7HD0Fq7Or4inkSqgPooT2GAGV9Y4rQTLH25DQQo86 MznTKTXNxI6LCjngCQuFFkOnj0cj5LzMWKRLFoSLsxXbsUXN+v9X5jSd5/eXlgvz3gJc 5wSRuFJ/z5cv3Ag/EZLLN53XDQO/GVSi29mEOqyyZO6p2BzzFi86EIUy3rhG0GChH5VR m2+Q==
MIME-Version: 1.0
Received: by 10.58.252.72 with SMTP id zq8mr333610vec.20.1353004507299; Thu, 15 Nov 2012 10:35:07 -0800 (PST)
Sender: gettysjim@gmail.com
Received: by 10.58.151.202 with HTTP; Thu, 15 Nov 2012 10:35:06 -0800 (PST)
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6112F5D4264@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>   <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com> <7718867B-3132-4BB6-904D-E3F2DC5C1710@fugue.com> <2D09D61DDFA73D4C884805CC7865E6112F5D4264@GAALPA1MSGUSR9L.ITServices.sbc.com>
Date: Thu, 15 Nov 2012 13:35:06 -0500
X-Google-Sender-Auth: ipbEwj6IDLtOf3ejHc-fq63-nPM
Message-ID: 
From: Jim Gettys 
To: "STARK, BARBARA H" 
Content-Type: multipart/alternative; boundary=047d7b6daa7009809704ce8ce9d1
Cc: "homenet@ietf.org Group" , Ted Lemon 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 18:35:09 -0000

--047d7b6daa7009809704ce8ce9d1
Content-Type: text/plain; charset=ISO-8859-1

We're testing fq_codel on DSL right now on a particular Lantiq home router
with OpenWrt and CeroWrt (Broadcom, the most common chip vendor for DSL
devices, has not been cooperative with Linux/Open source,

It makes a dramatic difference in bufferbloat and perceived performance
(and on DSL, won't require messing with QOS settings, as we don't have to
put in an artificial bottleneck requiring tuning).

Results (on .5Mbps uplinks) should end up similar to those reported here
(though Michael misidentified exactly why what he's doing works on his
hardware):

http://planet.ipfire.org/post/ipfire-2-13-tech-preview-fighting-bufferbloat

In a few weeks, I'll announce which router and how to get the bits for the
adventurous, and willing to spend less than $100 for a new home router to
run in on.
                                 - Jim







On Thu, Nov 15, 2012 at 1:14 PM, STARK, BARBARA H  wrote:

> > Chances are that part of the reason you had to go to a multi-homed
> > connection was that your router configuration was suffering from
> > bufferbloat, and so despite you having a decent connection to your ISP,
> you
> > were experiencing congestion.   This is, unfortunately, very typical of
> home
> > routers nowadays.
>
> No, my connection to my first ISP is 1.5Mbps downstream. The 2nd
> connection is 30Mbps downstream. A single Netflix stream had no difficulty
> taking up the entire 1.5Mbps. Unfortunately, the technology used to offer
> the 1.5Mbps service could only be upgraded to a maximum of 3Mbps. I figured
> Netflix could probably overrun that too, so I went with the 2nd connection.
> I could have just switched everything to the 2nd connection (my routers
> haven't had any difficulty with doing everything asked of them on the 30
> Mbps connection -- Netflix users are very happy and the shrieks from the
> MMORPG addict mourning death due to lousy Internet connectivity have
> stopped), but I like the redundancy of having 2, and the 1.5 Mbps service
> is very inexpensive.
>
> > Adding a second entire network for your own private use worked, but it
> was
> > probably overkill.
>
> Not overkill. Just redundant. But I and my family need our Internet. We
> cannot live without it. Redundancy is good when it isn't expensive.
>
> > If you are feeling adventurous, you might want to try
> > setting up a CeroWRT network with properly tuned buffers and see if it
> > changes things for you.   I can't promise that it does-I'm just a happy
> user of
> > CeroWRT, not an expert on bufferbloat.   But the network behavior you are
> > describing sounds a lot like what I was trying to cure when I installed
> > CeroWRT.
>
> Hmm. I'm busy with other adventures right now, and not feeling the need.
> I'll keep it in mind, though.
>
> > What does this have to do with the homenet discussion?   We should be
> > proposing a solution that doesn't perpetuate the architecture that leads
> to
> > bufferbloat.
>
> /64s are very real, and the need to accommodate them appears to be
> relatively near-term. Multi-homing is real. Improved multi-homing
> experience is desirable, but not an immediate need.
> A diagnosis of bufferbloat sounds difficult to cure (requiring adventures
> and acronyms), so I think I'll stick with my state of denial regarding that.
> Barbara
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

--047d7b6daa7009809704ce8ce9d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We're testing fq_codel on DSL right now on a particular Lantiq home rou=
ter with OpenWrt and CeroWrt (Broadcom, the most common chip vendor for DSL=
 devices, has not been cooperative with Linux/Open source,



It makes a dramatic difference in bufferbloat and perceived performanc=
e (and on DSL, won't require messing with QOS settings, as we don't=
 have to put in an artificial bottleneck requiring tuning).



Results (on .5Mbps uplinks) should end up similar to those reported he=
re (though Michael misidentified exactly why what he's doing works on h=
is hardware):




In a few weeks, I'll announce which router and how =
to get the bits for the adventurous, and willing to spend less than $100 fo=
r a new home router to run in on.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim



=A0


=


On Thu, Nov 15, 2012 at 1:14 PM, STARK, =
BARBARA H <bs7652@att.com> wrote:


> Chances are that part of the reason you=
 had to go to a multi-homed

> connection was that your router configuration was suffering from

> bufferbloat, and so despite you having a decent connection to your ISP=
, you

> were experiencing congestion. =A0 This is, unfortunately, very typical=
 of home

> routers nowadays.



No, my connection to my first ISP is 1.5Mbps downstream. The 2nd connection=
 is 30Mbps downstream. A single Netflix stream had no difficulty taking up =
the entire 1.5Mbps. Unfortunately, the technology used to offer the 1.5Mbps=
 service could only be upgraded to a maximum of 3Mbps. I figured Netflix co=
uld probably overrun that too, so I went with the 2nd connection. I could h=
ave just switched everything to the 2nd connection (my routers haven't =
had any difficulty with doing everything asked of them on the 30 Mbps conne=
ction -- Netflix users are very happy and the shrieks from the MMORPG addic=
t mourning death due to lousy Internet connectivity have stopped), but I li=
ke the redundancy of having 2, and the 1.5 Mbps service is very inexpensive=
.




> Adding a second entire network for your own private use worked, but it=
 was

> probably overkill.



Not overkill. Just redundant. But I and my family need our Internet. We can=
not live without it. Redundancy is good when it isn't expensive.



> If you are feeling adventurous, you might want to try

> setting up a CeroWRT network with properly tuned buffers and see if it=


> changes things for you. =A0 I can't promise that it does-I'm j=
ust a happy user of

> CeroWRT, not an expert on bufferbloat. =A0 But the network behavior yo=
u are

> describing sounds a lot like what I was trying to cure when I installe=
d

> CeroWRT.



Hmm. I'm busy with other adventures right now, and not feeling the need=
. I'll keep it in mind, though.



> What does this have to do with the homenet discussion? =A0 We should b=
e

> proposing a solution that doesn't perpetuate the architecture that=
 leads to

> bufferbloat.



/64s are very real, and the need to accommodate them appears to be relative=
ly near-term. Multi-homing is real. Improved multi-homing experience is des=
irable, but not an immediate need.

A diagnosis of bufferbloat sounds difficult to cure (requiring adventures a=
nd acronyms), so I think I'll stick with my state of denial regarding t=
hat.

Barbara

_______________________________________________

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet





--047d7b6daa7009809704ce8ce9d1--

From bs7652@att.com  Thu Nov 15 10:42:56 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6772F21F8981 for ; Thu, 15 Nov 2012 10:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.653
X-Spam-Level: 
X-Spam-Status: No, score=-106.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3mFfMyTDbIw for ; Thu, 15 Nov 2012 10:42:55 -0800 (PST)
Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 666BB21F8552 for ; Thu, 15 Nov 2012 10:42:55 -0800 (PST)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id fa735a05.2aaad0c0d940.1568575.00-596.4371325.nbfkord-smmo04.seg.att.com (envelope-from );  Thu, 15 Nov 2012 18:42:55 +0000 (UTC)
X-MXL-Hash: 50a537af016e5ec4-b075f54d3cf35718a91fb703bad14b48bf0181b8
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 4a735a05.0.1568492.00-370.4371090.nbfkord-smmo04.seg.att.com (envelope-from );  Thu, 15 Nov 2012 18:42:45 +0000 (UTC)
X-MXL-Hash: 50a537a574741d7d-651b773e2a35285b502c58a2f88f4b202e212184
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFIgdga017944; Thu, 15 Nov 2012 13:42:43 -0500
Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFIgJYp017589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 13:42:38 -0500
Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint03.pst.cso.att.com (RSA Interceptor); Thu, 15 Nov 2012 13:41:56 -0500
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 13:41:56 -0500
From: "STARK, BARBARA H" 
To: joel jaeggli 
Thread-Topic: [homenet] prefix assignment on home networks
Thread-Index: AQHNwc1XLuVpg3VVeEmOydkPpp/P/JfosfQAgAA/WgCAAHRvAIAAXgyAgAAm7wCAABSdAIAABN2A///nk4CAAZQAAP//ttvQ
Date: Thu, 15 Nov 2012 18:41:56 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6112F5D42BE@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>  <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com> <50A5282C.1020601@bogus.com>
In-Reply-To: <50A5282C.1020601@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.156.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=M5v63VMs c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=C3VREvb7-QsA:10 a=sSpCeFR3TLIA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=wdKPuTGemoUA:10 a=48vgC7mUAAAA:8 a=G2Bp7wvQKDRWwG]
X-AnalysisOut: [IkmcsA:9 a=CjuIK1q_8ugA:10 a=QjMdy8ak6xpf8RJR:21 a=DTp-A_A]
X-AnalysisOut: [1pZ0yT47A:21]
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 18:42:56 -0000

> > But when (single stack) IPv6 gets offered on that tether, that router w=
ill
> > only have a single /128 address. Hmm.

 > http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal.

Which, I suspect, is how the router would get that single /128 address. Tha=
t works nice for the 3GPP tethering device to know it has a /64 that it can=
 offer for SLAAC use to tethered (non-3GPP) devices to self-assign a /128. =
It's not so useful for my tethered (non-3GPP) off-the-shelf home networking=
 router connected out its WAN port to the tethering device through an Ether=
net/Wi-Fi bridge, to provide addresses to the home network on its LAN.

Not all of the devices on my home network do Wi-Fi. And even if they did, h=
oming them all to point to the tethering device (many of which only support=
 3 or so tethered devices) would require effort. It's much easier for me to=
 configure a single Ethernet/Wi-Fi bridge to point to the tethering device,=
 and plug that into the WAN port of a regular home router. I know how to do=
 this (in the IPv4 world). I could even describe to my mother-in-law how to=
 do this.
Barbara


From joelja@bogus.com  Thu Nov 15 11:52:14 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55E121F8522 for ; Thu, 15 Nov 2012 11:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.774
X-Spam-Level: 
X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKQwxOCV2jZ9 for ; Thu, 15 Nov 2012 11:52:14 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5356E21F850B for ; Thu, 15 Nov 2012 11:52:14 -0800 (PST)
Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAFJqAJa071684 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 15 Nov 2012 19:52:10 GMT (envelope-from joelja@bogus.com)
Message-ID: <50A547E5.5060906@bogus.com>
Date: Thu, 15 Nov 2012 11:52:05 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "STARK, BARBARA H" 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>  <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com> <50A5282C.1020601@bogus.com> <2D09D61DDFA73D4C884805CC7865E6112F5D42BE@GAALPA1MSGUSR9L.ITServices.sbc.co! m>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6112F5D42BE@GAALPA1MSGUSR9L.ITServices.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 15 Nov 2012 19:52:11 +0000 (UTC)
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 19:52:15 -0000

On 11/15/12 10:41 AM, STARK, BARBARA H wrote:
>>> But when (single stack) IPv6 gets offered on that tether, that router will
>>> only have a single /128 address. Hmm.
>   > http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal.
>
> Which, I suspect, is how the router would get that single /128 address. That works nice for the 3GPP tethering device to know it has a /64 that it can offer for SLAAC use to tethered (non-3GPP) devices to self-assign a /128. It's not so useful for my tethered (non-3GPP) off-the-shelf home networking router connected out its WAN port to the tethering device through an Ethernet/Wi-Fi bridge, to provide addresses to the home network on its LAN.
There are somewhat limited options in my understanding with 3gpp release 
7 networks, this sounds like a relatively good idea given the 
limitations but it's use generally seems like kind of a bad idea. That 
said I'm in favor of bad options over no options, and I think it's 
heartening to see operators try and make this work.
> Not all of the devices on my home network do Wi-Fi.
really only one of them has to in the case of a bridge,
>   And even if they did, homing them all to point to the tethering device (many of which only support 3 or so tethered devices) would require effort.
The limit on the supported number of tethered devices is somewhat 
arbitrary, a usb dongle in business style cpe doesn't have the same 
limitations that my mifi does
>   It's much easier for me to configure a single Ethernet/Wi-Fi bridge to point to the tethering device, and plug that into the WAN port of a regular home router. I know how to do this (in the IPv4 world). I could even describe to my mother-in-law how to do this.
I would agree that if it's not easy  it's likely not going to workable 
general case. mobile phones that provide the bulk of the tethering 
capability already bind to the homenet (as clients/hosts) so they've 
already built the association necessary to offer service.
> Barbara
>
>


From bs7652@att.com  Thu Nov 15 12:08:46 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0EC21F8495 for ; Thu, 15 Nov 2012 12:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.649
X-Spam-Level: 
X-Spam-Status: No, score=-106.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XR-ljD8Po7J for ; Thu, 15 Nov 2012 12:08:44 -0800 (PST)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4F21F8477 for ; Thu, 15 Nov 2012 12:08:44 -0800 (PST)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id ccb45a05.2aaaf6843940.1634485.00-510.4521128.nbfkord-smmo06.seg.att.com (envelope-from );  Thu, 15 Nov 2012 20:08:44 +0000 (UTC)
X-MXL-Hash: 50a54bcc6f91f623-e7219077681efdb8e9a35a2583e4d7da467b34d2
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 4cb45a05.0.1634410.00-322.4520930.nbfkord-smmo06.seg.att.com (envelope-from );  Thu, 15 Nov 2012 20:08:36 +0000 (UTC)
X-MXL-Hash: 50a54bc434447ab1-980186541911213e4cfc16c524714ff9f4b0bc66
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFK8ajS020267; Thu, 15 Nov 2012 15:08:36 -0500
Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAFK8G1Q019753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 15:08:29 -0500
Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Thu, 15 Nov 2012 15:06:54 -0500
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 15:06:54 -0500
From: "STARK, BARBARA H" 
To: joel jaeggli 
Thread-Topic: [homenet] prefix assignment on home networks
Thread-Index: AQHNwc1XLuVpg3VVeEmOydkPpp/P/JfosfQAgAA/WgCAAHRvAIAAXgyAgAAm7wCAABSdAIAABN2A///nk4CAAZQAAP//ttvQgABu9oD//6/EAA==
Date: Thu, 15 Nov 2012 20:06:52 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6112F5D43EF@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com>	<50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>  <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com> <50A5282C.1020601@bogus.com> <2D09D61DDFA73D4C884805CC7865E6112F5D42BE@GAALPA1MSGUSR9L.ITServices.sbc.co! m> <50A547E5.5060906@bogus.com>
In-Reply-To: <50A547E5.5060906@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.156.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=VI9qaazX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=C3VREvb7-QsA:10 a=sSpCeFR3TLIA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=wdKPuTGemoUA:10 a=zkzAGIwqib3z_39M9xEA:9 a=CjuIK1]
X-AnalysisOut: [q_8ugA:10]
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 20:08:46 -0000

> There are somewhat limited options in my understanding with 3gpp release
> 7 networks, this sounds like a relatively good idea given the limitations=
 but it's
> use generally seems like kind of a bad idea. That said I'm in favor of ba=
d
> options over no options, and I think it's heartening to see operators try=
 and
> make this work.

Um, I really tried to indicate that my views were mine and were intended to=
 reflect my thoughts as a consumer. Not an operator. So please don't feel q=
uite so heartened.
Barbara

From joelja@bogus.com  Thu Nov 15 12:40:08 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A00F21F84C6 for ; Thu, 15 Nov 2012 12:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.666
X-Spam-Level: 
X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s3Byu+56-vU for ; Thu, 15 Nov 2012 12:40:07 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9DA21F84C2 for ; Thu, 15 Nov 2012 12:40:07 -0800 (PST)
Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAFKe3Bu072266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 15 Nov 2012 20:40:04 GMT (envelope-from joelja@bogus.com)
Message-ID: <50A5531E.9010108@bogus.com>
Date: Thu, 15 Nov 2012 12:39:58 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "STARK, BARBARA H" 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com>  <4796! 9290-9244-4CCF-B273-33B68F0DE52B@gmail.com>  <2D09D61DDFA73D4C884805CC7865E6112F5D3BD8@GAALPA1MSGUSR9L.ITServices.sbc.com> <50A5282C.1020601@bogus.com> <2D09D61DDFA73D4C884805CC7865E6112F5D42BE@GAALPA1MSGUSR9L.ITServices.sbc.co! m> <50A547E5.5060906@bogus.com> <2D09D61DDFA73D4C884805CC7865E6112F5D43EF@GAALPA1MSGUSR9L.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6112F5D43EF@GAALPA1MSGUSR9L.ITServices.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 15 Nov 2012 20:40:04 +0000 (UTC)
Cc: Randy Turner , "homenet@ietf.org" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 20:40:08 -0000

On 11/15/12 12:06 PM, STARK, BARBARA H wrote:
>> There are somewhat limited options in my understanding with 3gpp release
>> 7 networks, this sounds like a relatively good idea given the limitations but it's
>> use generally seems like kind of a bad idea. That said I'm in favor of bad
>> options over no options, and I think it's heartening to see operators try and
>> make this work.
Sorry the operator in this  context was Cameron/t-mobile in specific, 
operators who commented on this method, in general.
>> Um, I really tried to indicate that my views were mine and were intended to reflect my thoughts as a consumer. Not an operator. So please don't feel quite so heartened.
yeah I understood your position.
>> Barbara
>>


From jhw@apple.com  Thu Nov 15 13:04:16 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FD521F86D1 for ; Thu, 15 Nov 2012 13:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.573
X-Spam-Level: 
X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veYowZD68VA5 for ; Thu, 15 Nov 2012 13:04:15 -0800 (PST)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 60C4421F86A2 for ; Thu, 15 Nov 2012 13:04:15 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDJ00JC0RTQC4W1@mail-out.apple.com> for homenet@ietf.org; Thu, 15 Nov 2012 13:04:14 -0800 (PST)
X-AuditID: 11807134-b7fe96d000000e2b-45-50a558cd565a
Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id 64.D8.03627.EC855A05; Thu, 15 Nov 2012 13:04:14 -0800 (PST)
Received: from kallisti.apple.com ([17.193.13.64]) by cilantro.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDJ002P8RV1O750@cilantro.apple.com> for homenet@ietf.org; Thu, 15 Nov 2012 13:04:13 -0800 (PST)
Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated.
From: james woodyatt 
In-reply-to: <97E88859-5B33-4419-BF72-7CBBB716B98A@fugue.com>
Date: Thu, 15 Nov 2012 13:04:13 -0800
Message-id: <280F7D7D-ABE0-4CA8-900B-14FB3388B9E8@apple.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>  
To: "homenet@ietf.org Group" 
X-Mailer: Apple Mail (2.1630)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUi2FAspHsuYmmAwf8dHBbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvOqjcwFazgqdk3OamC8ydbFyMkhIWAisfT7XiYIW0ziwr31 QHEuDiGBaUwS3+//hXLmMEkc/tPGDFIlLBAg8alxHwuIzSygJbF+53Gwbl4BPYkjlyYwQdRY Svz++gSsnk1AReLb5btgcU4BW4mG2c/BNrMIqEr07JjDCDFHW+LJuwusEHNsJB51trNDLP7O LtH7pgksISKgL/H0yC+os2Uldh+5xzSBUWAWkjtmIbljFpK5CxiZVzEKFqXmJFYamuglFhTk pOol5+duYgQHX6HJDsaDP/kPMQpwMCrx8J66uThAiDWxrLgy9xCjBAezkgivp9zSACHelMTK qtSi/Pii0pzU4kOM0hwsSuK8yaFLAoQE0hNLUrNTUwtSi2CyTBycUg2MOpt+vPN9f8L/x+c6 uZuH3e9HNus0swnG363cPyXLy7HjzP/P1qvufE86X2xw8+ynja2WG96t2MKrWsG+u1F4Tn65 aF/KaycTJ7UgfUXPy+7dq6bVHnMKviARU5de+GV59PHDN258MdXcvmyT3rzINxxfNq9Ya5S1 KNgnQevbb9OEeMtDDZd+KrEUZyQaajEXFScCAESbhp46AgAA
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 21:04:16 -0000

On Nov 15, 2012, at 04:26 , Ted Lemon  wrote:
> On Nov 14, 2012, at 10:41 PM, james woodyatt  wrote:
>> However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider.
> 
> Those hosts are broken.   They can't work in a multi-homed environment.

Those hosts are not broken.  They work fine in single-homed edge networks, which are ubiquitous.  The deployment of multiple heterogenous default routers with hosts that expect networks to be single-homed is what breaks the network.

Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously.


--
james woodyatt 
core os networking


From mellon@fugue.com  Thu Nov 15 13:20:25 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C4F21F8495 for ; Thu, 15 Nov 2012 13:20:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJakgs4wNckd for ; Thu, 15 Nov 2012 13:20:24 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C5DB421F84D8 for ; Thu, 15 Nov 2012 13:20:22 -0800 (PST)
Received: from kali.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 872AE2380425; Thu, 15 Nov 2012 16:20:20 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: <280F7D7D-ABE0-4CA8-900B-14FB3388B9E8@apple.com>
Date: Thu, 15 Nov 2012 16:20:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <97651EFA-898E-492D-9EEF-3E9B810BF91D@fugue.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <280F7D7D- ABE0-4CA8-900B-14FB3388B9E8@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 21:20:25 -0000

On Nov 15, 2012, at 4:04 PM, james woodyatt  wrote:
> Those hosts are not broken.  They work fine in single-homed edge =
networks, which are ubiquitous.  The deployment of multiple heterogenous =
default routers with hosts that expect networks to be single-homed is =
what breaks the network.

It breaks the network because hosts in this environment cannot be =
counted on to do the obviously right thing, but instead are encouraged =
by the standard to behave in ways that can be counted on to be wrong =
almost all the time.

It's true that they are not broken with respect to the standard, but =
what the standard encourages them to do is the very essence of what it =
means to be broken.   We should fix it, not wring our hands and point =
out reasons why it's not our fault that the standard and the hosts that =
follow it are broken.


From jhw@apple.com  Thu Nov 15 13:21:13 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4821621F888D for ; Thu, 15 Nov 2012 13:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.577
X-Spam-Level: 
X-Spam-Status: No, score=-110.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22tSPeVm1X0h for ; Thu, 15 Nov 2012 13:21:12 -0800 (PST)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id B288021F885A for ; Thu, 15 Nov 2012 13:21:12 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDJ00M82SI8NQK1@mail-out.apple.com> for homenet@ietf.org; Thu, 15 Nov 2012 13:21:12 -0800 (PST)
X-AuditID: 11807130-b7fcc6d0000038e5-94-50a55cc7b1c3
Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id FD.78.14565.8CC55A05; Thu, 15 Nov 2012 13:21:12 -0800 (PST)
Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDJ00A03SNASG10@aniseed.apple.com> for homenet@ietf.org; Thu, 15 Nov 2012 13:21:10 -0800 (PST)
Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated.
From: james woodyatt 
In-reply-to: <280F7D7D-ABE0-4CA8-900B-14FB3388B9E8@apple.com>
Date: Thu, 15 Nov 2012 13:21:09 -0800
Message-id: <98E49D3D-85C8-4B78-A1A9-075681B29678@apple.com>
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <280F7D7D-ABE0-4CA@apple.com>
To: "homenet@ietf.org Group" 
X-Mailer: Apple Mail (2.1630)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUi2FAsrnsiZmmAwctGdov3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/DvncwFM9kqDpzsZmpg/M3SxcjJISFgIvHsXBM7hC0mceHe erYuRi4OIYEpTBINP/YyQjizmCTefNrCCFIlLBAg8alxH1g3s4CWxPqdx5lAbF4BPYkjlyYw QdRYSvz++oQZxGYTUJH4dvkuWJxTwFbi2+4OsF4WAVWJ3Q9OM0LM0ZZ48u4CK8QcG4nXX9ex QyyeziGx888fsGYRAX2Jp0d+sUGcKiux+8g9pgmMArOQ3DELyR2zkMxdwMi8ilGwKDUnsdLQ UC+xoCAnVS85P3cTIzj8Cg12MK79yX+IUYCDUYmH9/TNxQFCrIllxZW5hxglOJiVRHg95ZYG CPGmJFZWpRblxxeV5qQWH2KU5mBREudNDF0SICSQnliSmp2aWpBaBJNl4uCUamBUvDHX3o57 m+D6SbLu8+Sv+odPmvapp2Zl/Iy4NJuXVfnyz/r6Ygvq52hv7jw8y+Lat8nljsu3Va9JnMLj +56B5VPT9EiLzN5Dc7KqtfexijWwu8Q9tz5w++Htny+SJD//ZnIy/Fw07S3fEx/Z5KCtKmXP GqxenXqT/Ux1WeLN/Fklm5XcnHKVWIozEg21mIuKEwEk6x9bOwIAAA==
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 21:21:13 -0000

On Nov 15, 2012, at 13:04 , james woodyatt  wrote:
> 
> Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously.

Well, this is just wrong.  I didn't think this through completely.  Rule 5.5 of RFC 6724 *is* inadequate, but not for precisely the reason I describe above.  It would help, but Rule 3 overrides it, and dragons await the unwary sailor who doesn't keep synchronized clocks.


--
james woodyatt 
core os networking


From otroan@employees.org  Fri Nov 16 01:28:49 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA6521F857C for ; Fri, 16 Nov 2012 01:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.275
X-Spam-Level: 
X-Spam-Status: No, score=-10.275 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXevmmro5jOx for ; Fri, 16 Nov 2012 01:28:48 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 824A421F8577 for ; Fri, 16 Nov 2012 01:28:48 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAA0GplCQ/khR/2dsb2JhbABEwkyBCIIeAQEBAwESASc/BQsLRlcGNYdlBp1soA6QXWEDpFSBa4Jw
X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="146833911"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 16 Nov 2012 09:28:44 +0000
Received: from dhcp-lys01-vla250-10-147-112-142.cisco.com (dhcp-lys01-vla250-10-147-112-142.cisco.com [10.147.112.142]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAG9Sh3E028263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Nov 2012 09:28:43 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: <280F7D7D-ABE0-4CA8-900B-14FB3388B9E8@apple.com>
Date: Fri, 16 Nov 2012 10:28:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <280F7D7D- ABE0-4CA8-900B-14FB3388B9E8@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2012 09:28:49 -0000

James,

>>> However notionally easy this problem is to address, I imagine that =
practical matters, at some point, must rise to the top of the pile of =
points to consider.
>>=20
>> Those hosts are broken.   They can't work in a multi-homed =
environment.
>=20
> Those hosts are not broken.  They work fine in single-homed edge =
networks, which are ubiquitous.  The deployment of multiple heterogenous =
default routers with hosts that expect networks to be single-homed is =
what breaks the network.

given dual stack. all hosts are multi-homed.
multiple prefixes and multiple default routers have been part of the =
IPv6 design from day 1.

> Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it =
should work better than those that don't because new flows created after =
the primary default router becomes unreachable should automatically go =
to the next available default router, but existing flows will still be =
broken in the absence of the kind of coordination I described =
previously.

arguing from a standards perspective (not what implementations do). I =
don't think any of our documents describe a "primary default router".=20

given we have: RFC4861, RFC4311, RFC4191 and RFC6724 what is missing?
combined with happy eyeballs of course.

cheers,
Ole



From otroan@employees.org  Fri Nov 16 01:29:22 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F6C21F86E6 for ; Fri, 16 Nov 2012 01:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.276
X-Spam-Level: 
X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZFIe9sZYwWi for ; Fri, 16 Nov 2012 01:29:21 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1735C21F8577 for ; Fri, 16 Nov 2012 01:29:20 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABYHplCQ/khR/2dsb2JhbABEwkyBCIIeAQEBAwESASc/EAtGVwY1h2UGnWugDpBdYQOkVIFrgnA
X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="78280873"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 16 Nov 2012 09:29:16 +0000
Received: from dhcp-lys01-vla250-10-147-112-142.cisco.com (dhcp-lys01-vla250-10-147-112-142.cisco.com [10.147.112.142]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAG9Sh3F028263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Nov 2012 09:29:16 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: <98E49D3D-85C8-4B78-A1A9-075681B29678@apple.com>
Date: Fri, 16 Nov 2012 10:29:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>   <50A32C7B.7000904@bogus.com>   <280F7D7D- ABE0-4CA@apple.com> <98E49D3D-85C8-4B78-A1A9-075681B29678@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2012 09:29:22 -0000

>> Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it =
should work better than those that don't because new flows created after =
the primary default router becomes unreachable should automatically go =
to the next available default router, but existing flows will still be =
broken in the absence of the kind of coordination I described =
previously.
>=20
> Well, this is just wrong.  I didn't think this through completely.  =
Rule 5.5 of RFC 6724 *is* inadequate, but not for precisely the reason I =
describe above.  It would help, but Rule 3 overrides it, and dragons =
await the unwary sailor who doesn't keep synchronized clocks.

rule 3 deprecated addresses. how does that apply?

cheers,
Ole


From brian.e.carpenter@gmail.com  Fri Nov 16 01:50:07 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A73C21F844F for ; Fri, 16 Nov 2012 01:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.417
X-Spam-Level: 
X-Spam-Status: No, score=-101.417 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfRZFbV1K6Y1 for ; Fri, 16 Nov 2012 01:50:07 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B67FD21F81FF for ; Fri, 16 Nov 2012 01:50:06 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id u46so1025493wey.31 for ; Fri, 16 Nov 2012 01:50:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0f5QloXWKzJGaZ9KXcQRc92ulMGqwhXsXyTA7Vwsq40=; b=wp0tp5MqK/HF0E7MPoLfSG/60w0ksFWEpD8B1wz3x4agdvlvI7jY8YEkDum11JQsAC 3I7gFMr/bgZY64h3Y01z+M/oLtxCkVyr1h2+YPsJbSjA3a9LCqLq90H1Zz7PzDZrSNDV zwgkJvZn3wL01oqetbwZPjejFgKc6TL/rKfBbyWaaGza22zGTsPABC69BSCBQmvAjflJ JA75m96oru0ReVCBQPG8wcQnAgRFJCuWH3z4q9nRlUVybq5kRcKHmJbJuaoGgt9mMHU3 LPjyK6uFspThCWu9JycpcBBN3KfJWyXTvc+/FAuVKpZWEH2bKuHY/pQ2SVcA/fGmtGpV bmfw==
Received: by 10.180.88.72 with SMTP id be8mr1190801wib.19.1353059405871; Fri, 16 Nov 2012 01:50:05 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-111.as13285.net. [2.102.216.111]) by mx.google.com with ESMTPS id ey2sm5748wib.9.2012.11.16.01.50.04 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 01:50:05 -0800 (PST)
Message-ID: <50A60C59.4040006@gmail.com>
Date: Fri, 16 Nov 2012 09:50:17 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: =?UTF-8?B?T2xlIFRyw7hhbg==?= 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com>		<509CBCAD.5010503@gmail.com>	<39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw>	<50A1020F.5060406@gmail.com>		<50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>		<7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net>	<787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com>	<5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>			<50A32C7B.7000904@bogus.com>		 <280F7D7D-	ABE0-4CA8-900B-14FB3388B9E8@apple.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "homenet@ietf.org Group" , james woodyatt 
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2012 09:50:07 -0000

Ole,

On 16/11/2012 09:28, Ole Tr=C3=B8an wrote:
> James,
>=20
>>>> However notionally easy this problem is to address, I imagine that p=
ractical matters, at some point, must rise to the top of the pile of poin=
ts to consider.
>>> Those hosts are broken.   They can't work in a multi-homed environmen=
t.
>> Those hosts are not broken.  They work fine in single-homed edge netwo=
rks, which are ubiquitous.  The deployment of multiple heterogenous defau=
lt routers with hosts that expect networks to be single-homed is what bre=
aks the network.
>=20
> given dual stack. all hosts are multi-homed.
> multiple prefixes and multiple default routers have been part of the IP=
v6 design from day 1.
>=20
>> Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it sho=
uld work better than those that don't because new flows created after the=
 primary default router becomes unreachable should automatically go to th=
e next available default router, but existing flows will still be broken =
in the absence of the kind of coordination I described previously.
>=20
> arguing from a standards perspective (not what implementations do). I d=
on't think any of our documents describe a "primary default router".=20
>=20
> given we have: RFC4861, RFC4311, RFC4191 and RFC6724 what is missing?
> combined with happy eyeballs of course.

I think a unified explanation of the best current practice is
missing. Also there is that MAY in 6724 that I mentioned
earlier, which seems weak in view of the discussion here.

   Brian


From hpa@zytor.com  Thu Nov 15 14:06:04 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956AD21F8A01 for ; Thu, 15 Nov 2012 14:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIZnGQGcA2r0 for ; Thu, 15 Nov 2012 14:06:04 -0800 (PST)
Received: from mail.zytor.com (terminus.zytor.com [IPv6:2001:1868:205::10]) by ietfa.amsl.com (Postfix) with ESMTP id 336A721F89FF for ; Thu, 15 Nov 2012 14:06:03 -0800 (PST)
Received: from tazenda.hos.anvin.org (c-67-161-22-173.hsd1.ca.comcast.net [67.161.22.173]) (authenticated bits=0) by mail.zytor.com (8.14.5/8.14.5) with ESMTP id qAFM5tcZ010104 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 14:05:56 -0800
Message-ID: <50A56743.2020309@zytor.com>
Date: Thu, 15 Nov 2012 14:05:55 -0800
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2
MIME-Version: 1.0
To: Mikael Abrahamsson 
References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com>  <2571B8BA-F56E-4B50-8144-DDBD423FDAD1@fugue.com> <48F53295-6A21-4141-B49A-F3CA05728853@gmail.com>  <867F4B6A1672E541A94676D556793ACD1B66C8E973@MOPESMBX01.eu.thmulti.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 18 Nov 2012 23:37:41 -0800
Cc: "homenet@ietf.org Group" , Andrew McGregor , Ted Lemon , Wuyts Carl , Ralph Droms 
Subject: Re: [homenet] regarding recursive DHCPv6-PD
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 22:06:04 -0000

On 11/08/2012 01:48 AM, Mikael Abrahamsson wrote:
> On Thu, 8 Nov 2012, Wuyts Carl wrote:
>
>> Well, being a residential CPE vendor, I can confirm some of our
>> customers deploy /64 only to the CPE. Not recommended by us, but being
>> a managed CPE, it's the customer making the final decision on this.
>
> If they only give the end user a /64, then the end customer won't be
> able to have a multi-LAN routed home. Hopefully the end customer will
> switch ISPs to one that isn't so restrictive.

If they can request more than one /64 from the upstream, then can have 
multiple LANs.  However, as far as I can tell from the specs it would 
have to use different IAIDs for each request as getting multiple 
prefixes back in the same IAID means "all these prefixes refer to one 
network."

FWIW, Comcast's currently deployed network will give a /64 to an 
unqualified PD request.  I have been told it will give up to a /60 if 
given an explicit request for a narrowed prefix; I have not been able to 
test it myself at this point.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


From lorenzo@google.com  Mon Nov 19 00:48:06 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9A821F8499 for ; Mon, 19 Nov 2012 00:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.93
X-Spam-Level: 
X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPUuWMrxRs1B for ; Mon, 19 Nov 2012 00:48:06 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA8C021F8458 for ; Mon, 19 Nov 2012 00:48:05 -0800 (PST)
Received: by mail-ob0-f172.google.com with SMTP id ef5so4963453obb.31 for ; Mon, 19 Nov 2012 00:48:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RlJYngeQTGLJz7RwmhcsYdbQticNLHss2yuRvpb3tZ8=; b=jxGCKVE7X+jfswVutUBHrU9GYeMdF5SqzYrMIlxoSDgxvEe+OqakG/67gGfVrV2wbK jDcsWAJh8QkX8zjXIpBjw4he3XGEZfy6qmHLhl76lUvMh0GyClSi6Aan2+SzT9Awceze 9BWWFsc/irTqa2TvGHeXvDFNZyNQHvlN80Nee9c25afgzaaCf7lGKYZDT+68mKbTh4OB Dmx1ueINdNiLlfJd9+sdhDMpInRrrQSiErF5pqW6lPrSvJaUVgMDoF+sexhvlsFmKaFd 1ezuV6EPgyNU45iBrXLT6WQfv8z22EyITrDnG5uHi/UG5t5lWoIDXM19nc3WYAn3I91v OWIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=RlJYngeQTGLJz7RwmhcsYdbQticNLHss2yuRvpb3tZ8=; b=AHZlTkgHp4CIr16zN1BIPX0ieQyTqfa4SZX2ecMBtfT+/Aggy7avAGror6lStPFjfW qDjLYB2khMFtBN6QJcE3XzkF6cEBfbQpP5yKgmBhoW8hTux8lMn6HbTd0AQITu+xg7mk P3JTwSLKEYBm3aB+DJc1k5KlSRVr+nDNPtRIo9u7fcZB2ztY+tZFiNc4+BqQ3RjOeyQE K5DjaX1x0VLgGGH8QzR7YWoDH37YLeI6aWSbUAtaDyKAQXwDIAXHQh8RiSOFMKv0riog aQNnN6WqYGaT4AC5uPFxX1t2SgBzjUMA13tIm0ylPL2JZoPkEAVI5q2l96deOUXNwKSF /fYA==
Received: by 10.182.127.102 with SMTP id nf6mr10198691obb.14.1353314885576; Mon, 19 Nov 2012 00:48:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.111.99 with HTTP; Mon, 19 Nov 2012 00:47:45 -0800 (PST)
In-Reply-To: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com>
References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com>
From: Lorenzo Colitti 
Date: Mon, 19 Nov 2012 17:47:45 +0900
Message-ID: 
To: Ralph Droms 
Content-Type: multipart/alternative; boundary=14dae93b5dec0628d204ced52d4f
X-Gm-Message-State: ALoCoQnS8v+I390T4i8oM1AH3VYAjzxT/207qneOfcLja9tXmUTcp7bqrKxtdY9baXO1h1T5JtmvVaQ7q3+0xcDuapJSd20Swhz5KgFGypX1wOCvcGZBSOJ/0K2MjDhDAR3kov3G0KduVs1oQC+EAgh5CS/j9rMM1emPeKu5uAe9bCknbYpDV2aNYRirMDDCqN8A+WTUjOA+
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] regarding recursive DHCPv6-PD
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 08:48:06 -0000

--14dae93b5dec0628d204ced52d4f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 8, 2012 at 12:51 AM, Ralph Droms  wrote:

> Using PD in a home network isn't hard.  Use a single delegating router;
> most obvious choice is the device that received the prefix from the
> external source.
>

That doesn't work in a multihomed situation, though, right? Only if there
is only one border router?

--14dae93b5dec0628d204ced52d4f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu=
, Nov 8, 2012 at 12:51 AM, Ralph Droms <rdroms.ietf@gmail.com><=
/span> wrote:



Using PD in a hom=
e network isn't hard. =A0Use a single delegating router; most obvious c=
hoice is the device that received the prefix from the external source.




That doesn't work in a multihomed situ=
ation, though, right? Only if there is only one border router?
<=
/div>

--14dae93b5dec0628d204ced52d4f--

From lorenzo@google.com  Mon Nov 19 01:24:30 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B198621F8533 for ; Mon, 19 Nov 2012 01:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.632
X-Spam-Level: 
X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvnKvPIWNjdD for ; Mon, 19 Nov 2012 01:24:30 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F01D521F8466 for ; Mon, 19 Nov 2012 01:24:29 -0800 (PST)
Received: by mail-ob0-f172.google.com with SMTP id ef5so4991482obb.31 for ; Mon, 19 Nov 2012 01:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bc8TEhnuHAGEDJzw/7oONa0mjLbI2NjPoAwtxex3zEs=; b=GhKWiqrtxmbA2w1m4br4UuGV/twm3Bz147WwtiK6xzW9kbu9GjspbbLdbBU9IrTWd2 w4hcG2byDzOKJGhZ90zHEnJpgt8EGqxM31kTyQ9GFV6pSNMLxrXzlQ8Sl9zaN7MU4XdP XVS+Rh54Oa39t4Em1F617TOb3fGZHj7NvBqAA1S5iJC0mgCIOL+cDUUd9xJ7fe+uM6IM KtoVjqAvEAO988pku5miUWk/BBqa5ux1qZRBDWYZ4D2lSKvft5AiHW/7Jz9UTSHqR1dn JmKSGa86f/TMVyDfRCcbcN4kg9587SjcZtl/o6g0M7hbyxdi3piPcs5NdwtSOWNFzIBg tyGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Bc8TEhnuHAGEDJzw/7oONa0mjLbI2NjPoAwtxex3zEs=; b=ffDYqgjRO9KOXTstOjgmdnnj0Q+NkAqpvnd0wWpvW72te3WosBLQIqhuMgt3CHGLL2 10GeMJTNMX8gNGiyoTy9PNvWMX5UpKXvLgADsfcN251zYHJgobwZfx31nK/gEbbbx0XZ rTdiE4XqxwGZkCgymYe7S6SsyrKq2C8Vn+FuPC/EOcBhADI6UZ3To9aLsiufXNZpExj5 uYJFlABk10B3BZyFuI8eVkew1gzay++vnSpQ7GWBdhtY1EY6GzXL8D06X4QPR9AsoATf vuvS6PyVXdkOPlmzzoaZ0plp/hQDUglYXj7qvwv2FbX6j+055DzwreheiAjxZAdGWviP fN5Q==
Received: by 10.60.169.10 with SMTP id aa10mr9711068oec.37.1353317069528; Mon, 19 Nov 2012 01:24:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.111.99 with HTTP; Mon, 19 Nov 2012 01:24:09 -0800 (PST)
In-Reply-To: 
References: <9FB60CE5849B194190DC0CDAD4825AEC2F903245@PACDCEXMB13.cable.comcast.com> <15353.1352401878@sandelman.ca> <534ED16F-6A85-4CBA-991A-614170CDAD40@fugue.com>   <509CBCAD.5010503@gmail.com> <39701F3A-33CD-44B0-84CF-3B2B09F37C1C@dlink.com.tw> <50A1020F.5060406@gmail.com>  <50A203B4.2070100@gmail.com> <50A26ED0.7090803@mtcc.com>  <7818C19F-462C-494C-A281-A0D131B6F63C@townsley.net> <787B83DE-B7DA-45CD-8F41-798477761909@amalfisystems.com> <5E967BBD-12E0-4293-AD9F-CB3C77A7D5D3@amalfisystems.com>  <6289389A-386D-41CF-A8CF-79C33F9412CA@amalfisystems.com> <50A364D6.8090104@gmail.com> <320BFCE8-59CE-4C61-9622-B92CC1D25E55@fugue.com> 
From: Lorenzo Colitti 
Date: Mon, 19 Nov 2012 18:24:09 +0900
Message-ID: 
To: Randy Turner 
Content-Type: multipart/alternative; boundary=bcaec54a3900329cd804ced5af40
X-Gm-Message-State: ALoCoQl1M+wuHtG1KmorhozH6zKaMojw29XibgG9VbTyDhKRXugUoLv3hvd3iruEns5I84Jsa0cmVI720MLRrjzhwPUepYrdciQXvZnJUGlXosnkozWBDTN7OK3X0ZI13KdaNG2oYWRQ/pWEzSkYtqHM7v4CFXvY8z9G/CS1fIoeNywkZNbpKchJOJugtp0wTQUi/PwCO12a
Cc: homenet@ietf.org
Subject: Re: [homenet] prefix assignment on home networks
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 09:24:30 -0000

--bcaec54a3900329cd804ced5af40
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Most major wireline deployments provide /60, /56 or /48. Examples: free.fr,
KDDI, AT&T. Exceptions are RCS+RDS (working on shorter prefixes) and some
North American cable operators, which AIUI are crippled by sucky CPEs that
fail to do anything useful when they receive more than a /64.

On Thu, Nov 15, 2012 at 2:27 AM, Randy Turner wr=
ote:

>
> Have their been any ISPs that have come forward to discuss their consumer
> IPv6 allocation plans?  I don't think we should wrap ourselves around a
> model that says, "yeah, we need multiple /64s for consumers because that'=
s
> the way a particular protocol works (SLAAC).   Maybe we need another
> method. One /64 for a home network seems like overkill regarding address
> space utilization -- A /32 would be overkill.  I know some folks think we
> have more address space than we'll ever use, but gee=85.
>
> Randy
>
>
> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
>
> > On Nov 14, 2012, at 3:31 AM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> >> On 14/11/2012 02:34, Randy Turner wrote:
> >>> I was thinking that, in an effort to reduce scope to something we can
> deal with for now, that a /64 would be big enough
> >>
> >> It simply isn't, because it doesn't allow subnetting in the
> home/car/small office or whatever.
> >
> > I don't see the point in working on the /64 case=97if that's all we're
> trying to accomplish, we've already accomplished it.   The interesting wo=
rk
> Homenet is doing is in fact trying to solve the prefix distribution and
> automatic setup problem.   It's true that this is a hard problem.   It's
> also true that if we don't specify a solution, people will attempt to sol=
ve
> it in their own ways.   And if they do that, we will wind up in the
> situation that Jim found himself in with his broken box with its own
> built-in DHCP server.
> >
> > BTW, a little more on that topic: the reason that two DHCP servers on
> the same wire broke Jim's network in a flaky way is that IPv4 doesn't
> handle the multi-homing case.   IPv6 deliberately places the multi-homing
> case in-scope.   This creates a bit of a problem for legacy apps that do
> not support multi-homing, but it also creates the winning situation that =
if
> one device is advertising a provisioning domain that doesn't work,
> applications that do correctly handle multi-homing will simply use a
> different provisioning domain.
> >
> > _______________________________________________
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
> >
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

--bcaec54a3900329cd804ced5af40
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Most m=
ajor wireline deployments provide /60, /56 or /48. Examples: free.fr, KDDI, AT&T. Exceptions are RCS+RDS (working o=
n shorter prefixes) and some North American cable operators, which AIUI are=
 crippled by sucky CPEs that fail to do anything useful when they receive m=
ore than a /64.



On Thu, Nov 15, 2012 at 2:27 AM, Randy Turne=
r <rturner@amalfisystems.com> wrote:




Have their been any ISPs that have come forward to discuss their consumer I=
Pv6 allocation plans? =A0I don't think we should wrap ourselves around =
a model that says, "yeah, we need multiple /64s for consumers because =
that's the way a particular protocol works (SLAAC). =A0 Maybe we need a=
nother method. One /64 for a home network seems like overkill regarding add=
ress space utilization -- A /32 would be overkill. =A0I know some folks thi=
nk we have more address space than we'll ever use, but gee=85.





Randy






On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:



> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

>> On 14/11/2012 02:34, Randy Turner wrote:

>>> I was thinking that, in an effort to reduce scope to something=
 we can deal with for now, that a /64 would be big enough

>>

>> It simply isn't, because it doesn't allow subnetting in th=
e home/car/small office or whatever.

>

> I don't see the point in working on the /64 case=97if that's a=
ll we're trying to accomplish, we've already accomplished it. =A0 T=
he interesting work Homenet is doing is in fact trying to solve the prefix =
distribution and automatic setup problem. =A0 It's true that this is a =
hard problem. =A0 It's also true that if we don't specify a solutio=
n, people will attempt to solve it in their own ways. =A0 And if they do th=
at, we will wind up in the situation that Jim found himself in with his bro=
ken box with its own built-in DHCP server.



>

> BTW, a little more on that topic: the reason that two DHCP servers on =
the same wire broke Jim's network in a flaky way is that IPv4 doesn'=
;t handle the multi-homing case. =A0 IPv6 deliberately places the multi-hom=
ing case in-scope. =A0 This creates a bit of a problem for legacy apps that=
 do not support multi-homing, but it also creates the winning situation tha=
t if one device is advertising a provisioning domain that doesn't work,=
 applications that do correctly handle multi-homing will simply use a diffe=
rent provisioning domain.



>

> _______________________________________________

> homenet mailing list

> homenet@ietf.org

> https://www.ietf.org/mailman/listinfo/homenet

>



_______________________________________________

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet





--bcaec54a3900329cd804ced5af40--

From mellon@fugue.com  Mon Nov 19 05:47:58 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FEC21F85D6 for ; Mon, 19 Nov 2012 05:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level: 
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfTaCMdfYAbt for ; Mon, 19 Nov 2012 05:47:57 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A6E4621F85D5 for ; Mon, 19 Nov 2012 05:47:57 -0800 (PST)
Received: from kali.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id A054E2380400; Mon, 19 Nov 2012 08:47:55 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ted Lemon 
In-Reply-To: 
Date: Mon, 19 Nov 2012 08:47:54 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1499)
Cc: "homenet@ietf.org Group" , Ralph Droms 
Subject: Re: [homenet] regarding recursive DHCPv6-PD
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 13:47:58 -0000

On Nov 19, 2012, at 3:47 AM, Lorenzo Colitti  wrote:
> That doesn't work in a multihomed situation, though, right? Only if =
there is only one border router?

If there are two border routers, both advertise their prefixes.   Hosts =
don't handle this particularly well, as we've discussed elsewhere, but =
it works just fine in terms of delivering service to the local network.



From lorenzo@google.com  Mon Nov 19 21:33:33 2012
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D522821F88C1 for ; Mon, 19 Nov 2012 21:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.922
X-Spam-Level: 
X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwhSpWKPtyS6 for ; Mon, 19 Nov 2012 21:33:33 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21C7121F8818 for ; Mon, 19 Nov 2012 21:33:32 -0800 (PST)
Received: by mail-ob0-f172.google.com with SMTP id ef5so6048381obb.31 for ; Mon, 19 Nov 2012 21:33:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jrBOo9YChMr5AZOg4aP32KgKpveJoyz6iqvLSJHobr4=; b=c5kQUd/jtub/hqCmAWCf6UrYKSKPfffX9vV8IWaVlEwBssvBo7+uK8pFdgY6OuyFfq pCFMVNr0AuTaEn4N2EdgrZUsk8+lrUBC0ehxwSWaqZMbYyu4O9EtPgNvbDmdFNAgmZ4M tJb9yc/bUMMArvxHgL6bXotj/4iW1WAYKfUaep3tNhQszdKfgz1J9HVI6XpeJNVjyn/C vEDiBuwSjsujTm5tqGTaIY/h7icj0SrF2BPLwK4MuwC4RgEmDh5JQhcR9MthApVMZ5Kq 2/EwIAmi4JXrcC7zT4277Ga3TW0QcDsH/tZCdLo3uOLwKstmI9dAH3uLdK49OSmgA66s HxdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=jrBOo9YChMr5AZOg4aP32KgKpveJoyz6iqvLSJHobr4=; b=QrfX1nZvsenP60i6qGCPw/mVsOOIuL0vVZq4Ii92QiTTCxemEc/Eo3Pidhl0Zpqr1I g8aTvYETDNKe+E4UpGJX3fE5tF3bs4XYayZEYn8ig3SruI2vwJWXLoJm/cbuP3/4f/CN 96Ka26StgPuFpj4RsrshgFESYhFPSsr54C6WDypNVLe5KmgoY0wA5sd2GXhS6xiGHaJg sRFcPU5jfbKkXyKOzS6MATYUcXvYhg+oaOWzgZaLcLHi/rfssZ88UxLDOUunGcowEV1w 6wYX/WwTCkAQz2IOG2XBzGZmgtWqRUJR+n5UzzMadVj+q2xXTONZkPAZFSIlQ8t7E7Qs zwBw==
Received: by 10.60.32.235 with SMTP id m11mr12858908oei.129.1353389612477; Mon, 19 Nov 2012 21:33:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.111.99 with HTTP; Mon, 19 Nov 2012 21:33:12 -0800 (PST)
In-Reply-To: 
References: <9986DBDC-EC26-4C6E-972F-90FE52198734@gmail.com>  
From: Lorenzo Colitti 
Date: Mon, 19 Nov 2012 21:33:12 -0800
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=e89a8fb1f840182ed804cee693a5
X-Gm-Message-State: ALoCoQn9uMTwIU1P/lHJtPepvQNYo3DuphoIM0/wr3cmecIuPiLctSwiTN0fGMFtOfjDlIzFM8JiH1h6B0x3DSNJLdxUFYDfV8xfptVUi+zYr8BTAO2x9+xoPTB66TyYnFB90LNkSDAkPMp11arPGz/NYuHRVJWxIN4a0Cd18q6JFCT9xQ682KVQF1vQ6kMyacZyAzBwkRYa
Cc: "homenet@ietf.org Group" , Ralph Droms 
Subject: Re: [homenet] regarding recursive DHCPv6-PD
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 05:33:34 -0000

--e89a8fb1f840182ed804cee693a5
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 19, 2012 at 5:47 AM, Ted Lemon  wrote:

> > That doesn't work in a multihomed situation, though, right? Only if
> there is only one border router?
>
> If there are two border routers, both advertise their prefixes.   Hosts
> don't handle this particularly well, as we've discussed elsewhere, but it
> works just fine in terms of delivering service to the local network.
>

It's not just that. For example, if one of the border routers is unplugged,
the hosts stay configured with invalid addresses until the lease expires.

--e89a8fb1f840182ed804cee693a5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon=
, Nov 19, 2012 at 5:47 AM, Ted Lemon <mellon@fugue.com> wrote=
:



> That doesn't work in a multihomed situation, though, right? Only =
if there is only one border router?






If there are two border routers, both advertise their prefixes. =A0 H=
osts don't handle this particularly well, as we've discussed elsewh=
ere, but it works just fine in terms of delivering service to the local net=
work.





It's not just that. For example, if one of =
the border routers is unplugged, the hosts stay configured with invalid add=
resses until the lease expires.


--e89a8fb1f840182ed804cee693a5--