From fred@cisco.com Sat Oct 1 06:57:03 2011 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 3155721F96C7; Sat, 1 Oct 2011 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=-4.196, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+740cQaDAPl; Sat, 1 Oct 2011 06:57:02 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6A50321F93AE; Sat, 1 Oct 2011 06:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=9687; q=dns/txt; s=iport; t=1317477599; x=1318687199; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=uRTGQKM5xa30QoPmn5dHgF8SnCs6Lgg0844OqGPKLVw=; b=fB2Vj75qYRdXqluRVtGz0J1EmEd7BZWzsTpLOGWPBJ9NYUj2xiP6V4zF 3fNPgb9k8uAG+HmZ1QjIjlt4T1aSRL7S12b8oRlu4VwZ2ThfLFSVcwLsA 9GNanGMo7H2o4Ytw31n3YZavMvCAECh+9r53Wy+ZAcJ9is/DF3t3Tc19Y k=; X-IronPort-AV: E=Sophos;i="4.68,473,1312156800"; d="scan'208";a="122440" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 01 Oct 2011 13:59:52 +0000 Received: from Freds-Computer.local (sin-vpn-client-16-42.cisco.com [10.68.16.42]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p91Dxlbj007535; Sat, 1 Oct 2011 13:59:47 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 01 Oct 2011 21:59:52 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 01 Oct 2011 21:59:52 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 30 Sep 2011 21:26:04 +0300 Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <44783019-1016-4D06-BACA-6130617F099A@ericsson.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: C Chauvenet , MANET IETF , Mark Townsley , "JP Vasseur \(jvasseur\)" , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] Question for you 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, 01 Oct 2011 13:57:03 -0000 As I understand it, we have made the case that there is a place for = routing in at least some homes and in SOHO networks, and we should say = what protocols manufacturers should consider implementing in equipment = they sell. Two significant parts of the issue there, as you know, are = operational expense and cost of goods. Margins in residential routers = are thin enough that manufacturers (one of which you know from the = inside) essentially lose their entire profit margin if they pick up the = phone for a trouble call, and in addition the memory to store the code = and data, and the code itself, cost money on a COGS basis. Manufacturers = want to be able to buy trouble-free code for a predictable price, put it = in the system, and forget the system. Which argues for proven specifications and implementations that have = been field proven to interoperate when used in anger. To my knowledge, this doesn't automatically imply "give me that old time = religion". It does call for proven (and preferably documented) = interoperability between numerous independent complete implementations, = or proven interoperability of a common profile of a protocol, an = exercise I have suggested to some proponents of your favorite protocol = is good for the soul. RFC 1246 comes to mind. By the way, let me clarify a point that you may be confused on. There = are detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and = I think IPv4/IS-IS. To my knowledge, there has been interoperability = testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which are = in use in production networks, but the test documentation is a trifle = thin. So I'm not asking of your favorite protocol or a dozen others that = one could discuss something I think should let slide for the traditional = ones. I am simply asking that the claims for the protocols be backed = with interoperability testing, RFCs, Security Directorate reviews, and = so on. On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: > Hello Cedric: >=20 > I have the same questions. Furthermore, I'd wish to understand better: >=20 > *** whether the goal is limited to provide a best practice based on = "established" ICT technologies=20 >=20 > There are other "established" technologies. For instance there is = extensive networking experience in industrial networks, solving = different problems under different constraints. Same goes in AMI/AMR = networks, and to a lesser extent in Home, commercial and building = automation. Some groups in the IETF have finally started to pay = attention and build on that experience. Even if the resulting = technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale = is such that over a few years we have seen unprecedented amounts of = implementations, interop and compliance tests (e.g. under IPSO and WCI). >=20 > Also, if we map home use cases with the routing technologies that = applied today, we see that at the moment the traditional IGPs do not = play much role, at least from the home standpoint: > - Internet to Home (Content consumption) is not a Home problem > - Home to Internet (metering, P2P) is a default route > - Home to Home (Content and Access sharing) is dominated by OLSR. > - Inside Home (Content and Device sharing) is single subnet, solved = reactively by ARP or ND. > - Inside Home (Command & Control, Automation) meshing is proprietary = though going 6LoWPAN and RPL. >=20 > In any fashion, we can solve an additional problem of our own making = that would require our beloved ICT IGPs to be injected in the Home = network with always-on routers in each room or we can start producing = best practices on how the above can to be done with the technologies = that are already in place. Or both? >=20 > *** whether we have an assumption of a plethora of power >=20 > Year over year, we've seen the simplest devices migrate from a = totally-switched-off mode to some more and more power greedy sleeping = and always-on modes. > Always-on displays and LEDs appears fancy to the consumer but are of = consequence on the family budget and at the scale of a city, result in = measurable pollution.=20 > And we've been connecting more and more devices to the home power = distribution, devices that would not exist 10-20 years ago. > We know how power-greedy traditional ICT technologies are; people do = not want a new heating system that they cannot even stop in summer. > My take is that whatever this group produces has to be justified in = terms of power budget as it has to be justified in other terms like = usability and security. >=20 >=20 > *** if HOMENET is targeting home gateways and large home cinema gear = only, and whether we have an assumption of cat 5/6 cabling >=20 > This case is probably the low hanging fruit and that there is an = immediate need to solve a number of problems there. If that's what the = group is pursuing for the time being, well, that's fine as long as it's = very clear to everybody. But the rest of the world is low power and = lossy. Apart from certain ecological niches (that's datacenter mostly) = about all Internet-connected devices have evolved the wireless trait, = even if the most traditional devices can still use wires. The new trait = has lowered dramatically the cost and complexity of accessing the = Internet, which in turn allowed the introduction of new species of = internet-connected devices that now thrive under the name of Things. At = some point we'll have to address that too. >=20 > I do not know how that converts into cents at the current rate... >=20 > Pascal >=20 > -----Original Message----- > From: C Chauvenet [mailto:c.chauvenet@watteco.com]=20 > Sent: jeudi 29 septembre 2011 17:23 > To: Acee Lindem; Fred Baker (fred) > Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; = homenet@ietf.org; rtgwg@ietf.org > Subject: RE: [homenet] Question for you >=20 > Hi,=20 >=20 > " I don't think my wife would want a lossy network in our house ;^)" :=20= >=20 > Nobody wants a lossy network, but the technology you are using may = create lossy links... >=20 > I may have miss something in the Homenet scope. >=20 > In the scope of Homenet, is every device in the house runing over a = *robust* link (Bit Error Rate below 1 % at the PHY level) ? >=20 > Furthermore do these devices could have some high = Power/Computation/Size/Cost constraints ? >=20 > I fail to see the kind of technologies and devices that are targeting. >=20 > Thanks for the clarification. >=20 > C=E9dric . >=20 > -----Message d'origine----- > De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi 29 = septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C Chauvenet; = Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; rtgwg@ietf.org = Objet : Re: [homenet] Question for you >=20 > I'm in complete agreement with Fred. The areas where the existing = link-state protocols may need to be extended are auto-configuration and, = potentially, inter-area policies. =20 > I don't think my wife would want a lossy network in our house ;^) = Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: >=20 >>=20 >> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>=20 >>> Since you asked, *I* think that a homenet has functional overlap = (what I called "at least a smaller and slightly different subset" in my = email) in terms of requirements to LLNs. At first blush, it looks like = RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but = will hold reservation on what I think best fits the bill until we see = Fred's analysis, hear from others, etc.=20 >>=20 >> My two yen, which may be all it's worth... >>=20 >> If I were a Linksys/D-Link/NetGear/* product manager asking about = what protocols to put in, I wouldn't be asking about what still exists = in Internet Drafts and is thought by the engineers designing it to be = better than sliced bread, but about what was inexpensive to implement, = likely to be close to bug-free, and definitively accomplished the goal. = I note that most routers for the IPv4 residential routing marketplace = implement RIPv2; I know of one that implements no routing protocol, one = that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and = OSPF (don't ask which they are, I don't remember). This is from a google = search of residential routers a few months ago and covered perhaps 20 = products from half as many vendors. So my first inclination is to say = that for a residential IPv6 network, RIPng is probably an image match = for those vendors. >>=20 >> I have a personal bias in the direction of OSPF or IS-IS; I think = that once the code is debugged, SPF-based protocols are more stable (no = count-to-infinity), given a reasonable set of defaults generate far more = stable networks, and definitively know when there is more than one = router on a LAN, which can be important in subnet distribution.=20 >>=20 >> My first choice would NOT be something that isn't proven in the field = in multiple interoperable implementations.=20 >>=20 >> As a person thinking about making a recommendation, I'd suggest that = folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask = themselves why that level of interoperability isn't mandatory. >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 >=20 From d.sturek@att.net Sat Oct 1 07:36:37 2011 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 194D021F97C2 for ; Sat, 1 Oct 2011 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=1.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2ESlb-qZcKR for ; Sat, 1 Oct 2011 07:36:36 -0700 (PDT) Received: from nm5.access.bullet.mail.mud.yahoo.com (nm5.access.bullet.mail.mud.yahoo.com [66.94.237.206]) by ietfa.amsl.com (Postfix) with SMTP id ED42E21F97BC for ; Sat, 1 Oct 2011 07:36:35 -0700 (PDT) Received: from [66.94.237.192] by nm5.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Oct 2011 14:39:30 -0000 Received: from [66.94.237.100] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Oct 2011 14:39:30 -0000 Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 01 Oct 2011 14:39:30 -0000 X-Yahoo-Newman-Id: 240649.43085.bm@omp1005.access.mail.mud.yahoo.com Received: (qmail 67845 invoked from network); 1 Oct 2011 14:39:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1317479970; bh=3SSRNpPl/XFRrI+n8fHpuMxC6/SRMNmgIB9nbskpYVg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Or9o9hYkkhaBMnmhmxlykf6IJUDdziral3aCd3QsdENCSWLBpXsL014PYnrV07whc2fumk/lN+Hfu+/tN7hRaJ9z7+HV7RnTJBTGncweuWvqOjHo5YEwcZ0jUmfNdT3BbLdJESBLdS3sBQuhrUTAH/L0IeJkqLmUORgFWkyfqb8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0KPssaoVM1kUE_pJYgtsmd6i._3WAVc.iSvwEUWrDBBAm1M F.mOUuA_TjOg2HITBCiVqfFoRaThc6r3PW28y.IwCLZ1eyPq_PULrCS7lsGE P6ZZNWTTAEL0IWWGSj1y6YfCc0HH3bf_.FAw7tEmVMQzbWZEOOqMiNaOeULY cH4jkowR4tbIAUDT5tjpEths5CNMV_OUMbXsi69SQUAuVED86CMyQ7eeuQYF _OABtNqXM9RDTo4TDOMFmGalsXJbPMYaLVnzlGQoSrYap4CWrbDBCpBOQhDt Zr6Z3R8Qzy_E0h5wA5MhffQOOaBjh6gdAoByBLPKXEIgP_96nJ94hCKWBefH DB0ZMRMvkDoc67DmSfvHEdzWjLOiLl4gCW7I20X_7KmV6BbLxds59GpkCFFV 69wXcBmM.fgWn345bOg9x X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.196] (d.sturek@69.108.51.206 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 01 Oct 2011 07:39:29 -0700 PDT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sat, 01 Oct 2011 07:38:12 -0700 From: Don Sturek To: Fred Baker , "Pascal Thubert \(pthubert\)" Message-ID: Thread-Topic: [manet] [homenet] Question for you In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 01 Oct 2011 14:36:37 -0000 To add one more point to Fred's note: I think it is important to get a commercial group like Wi-Fi to participate in Homenet, adopt some or all of the drafts/RFCs then sponsor interoperability testing. I agree with Fred that having individual CPE vendors cobbling together RFCs will not yield a bullet proof home networking solution and that will kill the work in Homenet if customer support is needed. Don On 9/30/11 11:26 AM, "Fred Baker" wrote: >As I understand it, we have made the case that there is a place for >routing in at least some homes and in SOHO networks, and we should say >what protocols manufacturers should consider implementing in equipment >they sell. Two significant parts of the issue there, as you know, are >operational expense and cost of goods. Margins in residential routers are >thin enough that manufacturers (one of which you know from the inside) >essentially lose their entire profit margin if they pick up the phone for >a trouble call, and in addition the memory to store the code and data, >and the code itself, cost money on a COGS basis. Manufacturers want to be >able to buy trouble-free code for a predictable price, put it in the >system, and forget the system. > >Which argues for proven specifications and implementations that have been >field proven to interoperate when used in anger. > >To my knowledge, this doesn't automatically imply "give me that old time >religion". It does call for proven (and preferably documented) >interoperability between numerous independent complete implementations, >or proven interoperability of a common profile of a protocol, an exercise >I have suggested to some proponents of your favorite protocol is good for >the soul. RFC 1246 comes to mind. > >By the way, let me clarify a point that you may be confused on. There are >detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I >think IPv4/IS-IS. To my knowledge, there has been interoperability >testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which are >in use in production networks, but the test documentation is a trifle >thin. So I'm not asking of your favorite protocol or a dozen others that >one could discuss something I think should let slide for the traditional >ones. I am simply asking that the claims for the protocols be backed with >interoperability testing, RFCs, Security Directorate reviews, and so on. > >On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: > >> Hello Cedric: >>=20 >> I have the same questions. Furthermore, I'd wish to understand better: >>=20 >> *** whether the goal is limited to provide a best practice based on >>"established" ICT technologies >>=20 >> There are other "established" technologies. For instance there is >>extensive networking experience in industrial networks, solving >>different problems under different constraints. Same goes in AMI/AMR >>networks, and to a lesser extent in Home, commercial and building >>automation. Some groups in the IETF have finally started to pay >>attention and build on that experience. Even if the resulting >>technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale >>is such that over a few years we have seen unprecedented amounts of >>implementations, interop and compliance tests (e.g. under IPSO and WCI). >>=20 >> Also, if we map home use cases with the routing technologies that >>applied today, we see that at the moment the traditional IGPs do not >>play much role, at least from the home standpoint: >> - Internet to Home (Content consumption) is not a Home problem >> - Home to Internet (metering, P2P) is a default route >> - Home to Home (Content and Access sharing) is dominated by OLSR. >> - Inside Home (Content and Device sharing) is single subnet, solved >>reactively by ARP or ND. >> - Inside Home (Command & Control, Automation) meshing is proprietary >>though going 6LoWPAN and RPL. >>=20 >> In any fashion, we can solve an additional problem of our own making >>that would require our beloved ICT IGPs to be injected in the Home >>network with always-on routers in each room or we can start producing >>best practices on how the above can to be done with the technologies >>that are already in place. Or both? >>=20 >> *** whether we have an assumption of a plethora of power >>=20 >> Year over year, we've seen the simplest devices migrate from a >>totally-switched-off mode to some more and more power greedy sleeping >>and always-on modes. >> Always-on displays and LEDs appears fancy to the consumer but are of >>consequence on the family budget and at the scale of a city, result in >>measurable pollution. >> And we've been connecting more and more devices to the home power >>distribution, devices that would not exist 10-20 years ago. >> We know how power-greedy traditional ICT technologies are; people do >>not want a new heating system that they cannot even stop in summer. >> My take is that whatever this group produces has to be justified in >>terms of power budget as it has to be justified in other terms like >>usability and security. >>=20 >>=20 >> *** if HOMENET is targeting home gateways and large home cinema gear >>only, and whether we have an assumption of cat 5/6 cabling >>=20 >> This case is probably the low hanging fruit and that there is an >>immediate need to solve a number of problems there. If that's what the >>group is pursuing for the time being, well, that's fine as long as it's >>very clear to everybody. But the rest of the world is low power and >>lossy. Apart from certain ecological niches (that's datacenter mostly) >>about all Internet-connected devices have evolved the wireless trait, >>even if the most traditional devices can still use wires. The new trait >>has lowered dramatically the cost and complexity of accessing the >>Internet, which in turn allowed the introduction of new species of >>internet-connected devices that now thrive under the name of Things. At >>some point we'll have to address that too. >>=20 >> I do not know how that converts into cents at the current rate... >>=20 >> Pascal >>=20 >> -----Original Message----- >> From: C Chauvenet [mailto:c.chauvenet@watteco.com] >> Sent: jeudi 29 septembre 2011 17:23 >> To: Acee Lindem; Fred Baker (fred) >> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; >>homenet@ietf.org; rtgwg@ietf.org >> Subject: RE: [homenet] Question for you >>=20 >> Hi,=20 >>=20 >> " I don't think my wife would want a lossy network in our house ;^)" : >>=20 >> Nobody wants a lossy network, but the technology you are using may >>create lossy links... >>=20 >> I may have miss something in the Homenet scope. >>=20 >> In the scope of Homenet, is every device in the house runing over a >>*robust* link (Bit Error Rate below 1 % at the PHY level) ? >>=20 >> Furthermore do these devices could have some high >>Power/Computation/Size/Cost constraints ? >>=20 >> I fail to see the kind of technologies and devices that are targeting. >>=20 >> Thanks for the clarification. >>=20 >> C=E9dric . >>=20 >> -----Message d'origine----- >> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi 29 >>septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C Chauvenet; >>Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; rtgwg@ietf.org >>Objet : Re: [homenet] Question for you >>=20 >> I'm in complete agreement with Fred. The areas where the existing >>link-state protocols may need to be extended are auto-configuration and, >>potentially, inter-area policies. >> I don't think my wife would want a lossy network in our house ;^) >>Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: >>=20 >>>=20 >>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>>=20 >>>> Since you asked, *I* think that a homenet has functional overlap >>>>(what I called "at least a smaller and slightly different subset" in >>>>my email) in terms of requirements to LLNs. At first blush, it looks >>>>like RPL has lots of functionality - perhaps more than we really need >>>>for homenet, and by your own admission more than you need for LLN's - >>>>but will hold reservation on what I think best fits the bill until we >>>>see Fred's analysis, hear from others, etc. >>>=20 >>> My two yen, which may be all it's worth... >>>=20 >>> If I were a Linksys/D-Link/NetGear/* product manager asking about what >>>protocols to put in, I wouldn't be asking about what still exists in >>>Internet Drafts and is thought by the engineers designing it to be >>>better than sliced bread, but about what was inexpensive to implement, >>>likely to be close to bug-free, and definitively accomplished the goal. >>>I note that most routers for the IPv4 residential routing marketplace >>>implement RIPv2; I know of one that implements no routing protocol, one >>>that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and >>>OSPF (don't ask which they are, I don't remember). This is from a >>>google search of residential routers a few months ago and covered >>>perhaps 20 products from half as many vendors. So my first inclination >>>is to say that for a residential IPv6 network, RIPng is probably an >>>image match for those vendors. >>>=20 >>> I have a personal bias in the direction of OSPF or IS-IS; I think that >>>once the code is debugged, SPF-based protocols are more stable (no >>>count-to-infinity), given a reasonable set of defaults generate far >>>more stable networks, and definitively know when there is more than one >>>router on a LAN, which can be important in subnet distribution. >>>=20 >>> My first choice would NOT be something that isn't proven in the field >>>in multiple interoperable implementations. >>>=20 >>> As a person thinking about making a recommendation, I'd suggest that >>>folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask >>>themselves why that level of interoperability isn't mandatory. >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >>=20 >>=20 > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From fred@cisco.com Sat Oct 1 17:17:51 2011 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 7A9F521F8DB0; Sat, 1 Oct 2011 17:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.575 X-Spam-Level: X-Spam-Status: No, score=-108.575 tagged_above=-999 required=5 tests=[AWL=2.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVNZbpm65dXV; Sat, 1 Oct 2011 17:17:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF021F8DAB; Sat, 1 Oct 2011 17:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=299; q=dns/txt; s=iport; t=1317514849; x=1318724449; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=kfNAU+9GpEMuTtXQQZ1VkbIzn/xG9TEuYDzmLr+WTLI=; b=Iam20l1fV7Uf4hIXWh/CqWv2t9rAjeuIiZeGdAO/LIpjYTHx5ZayfyMV 5mfUrGps3ddfdpKMR+gmdRD9VLyr1FYnI8WLSJLF44NipI/OhJyTXfM35 OuUALUizaVcZVeT/7juxV5JS5+RNqngQJW4AsyicQVU7InhGlgr+SEdMr Q=; X-IronPort-AV: E=Sophos;i="4.68,475,1312156800"; d="scan'208";a="56909404" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 02 Oct 2011 00:20:45 +0000 Received: from Freds-Computer.local (sin-vpn-client-16-42.cisco.com [10.68.16.42]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p920KiRd000383; Sun, 2 Oct 2011 00:20:44 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 02 Oct 2011 08:20:45 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 02 Oct 2011 08:20:45 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 2 Oct 2011 08:20:32 +0800 Message-Id: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> References: To: Don Sturek X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 02 Oct 2011 00:17:51 -0000 On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > To add one more point to Fred's note: I think it is important to get a > commercial group like Wi-Fi to participate in Homenet, adopt some or all > of the drafts/RFCs then sponsor interoperability testing. That would be very interesting. From mark@townsley.net Sun Oct 2 19:08:52 2011 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 55B6B21F84DA; Sun, 2 Oct 2011 19:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BupKovd6xzg2; Sun, 2 Oct 2011 19:08:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D61FD21F849A; Sun, 2 Oct 2011 19:08:46 -0700 (PDT) Received: by wwf22 with SMTP id 22so3478515wwf.13 for ; Sun, 02 Oct 2011 19:11:47 -0700 (PDT) Received: by 10.227.197.207 with SMTP id el15mr2318636wbb.31.1317607906979; Sun, 02 Oct 2011 19:11:46 -0700 (PDT) Received: from [192.168.0.109] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fy13sm20938640wbb.18.2011.10.02.19.11.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Oct 2011 19:11:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Mon, 3 Oct 2011 04:11:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <225C6EB3-9659-41D6-8B39-90C7DC0F016D@townsley.net> References: To: Don Sturek X-Mailer: Apple Mail (2.1084) Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Acee Lindem , Fred Baker , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 03 Oct 2011 02:08:52 -0000 On Oct 1, 2011, at 4:38 PM, Don Sturek wrote: > To add one more point to Fred's note: I think it is important to get = a > commercial group like Wi-Fi to participate in Homenet, adopt some or = all > of the drafts/RFCs then sponsor interoperability testing. I am constantly amazed at the plethora of consumer-oriented standards = groups/forums/logos/associations/etc... We've had decent uptake of RFC 6204 and other products of v6ops = targeting the consumer space. I hope that continues.=20 Of course, anyone with specific ties into any of the organizations that = might want to use our work, please feel free to help make that happen. - Mark >=20 > I agree with Fred that having individual CPE vendors cobbling together > RFCs will not yield a bullet proof home networking solution and that = will > kill the work in Homenet if customer support is needed. >=20 > Don >=20 >=20 >=20 > On 9/30/11 11:26 AM, "Fred Baker" wrote: >=20 >> As I understand it, we have made the case that there is a place for >> routing in at least some homes and in SOHO networks, and we should = say >> what protocols manufacturers should consider implementing in = equipment >> they sell. Two significant parts of the issue there, as you know, are >> operational expense and cost of goods. Margins in residential routers = are >> thin enough that manufacturers (one of which you know from the = inside) >> essentially lose their entire profit margin if they pick up the phone = for >> a trouble call, and in addition the memory to store the code and = data, >> and the code itself, cost money on a COGS basis. Manufacturers want = to be >> able to buy trouble-free code for a predictable price, put it in the >> system, and forget the system. >>=20 >> Which argues for proven specifications and implementations that have = been >> field proven to interoperate when used in anger. >>=20 >> To my knowledge, this doesn't automatically imply "give me that old = time >> religion". It does call for proven (and preferably documented) >> interoperability between numerous independent complete = implementations, >> or proven interoperability of a common profile of a protocol, an = exercise >> I have suggested to some proponents of your favorite protocol is good = for >> the soul. RFC 1246 comes to mind. >>=20 >> By the way, let me clarify a point that you may be confused on. There = are >> detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I >> think IPv4/IS-IS. To my knowledge, there has been interoperability >> testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which = are >> in use in production networks, but the test documentation is a trifle >> thin. So I'm not asking of your favorite protocol or a dozen others = that >> one could discuss something I think should let slide for the = traditional >> ones. I am simply asking that the claims for the protocols be backed = with >> interoperability testing, RFCs, Security Directorate reviews, and so = on. >>=20 >> On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: >>=20 >>> Hello Cedric: >>>=20 >>> I have the same questions. Furthermore, I'd wish to understand = better: >>>=20 >>> *** whether the goal is limited to provide a best practice based on >>> "established" ICT technologies >>>=20 >>> There are other "established" technologies. For instance there is >>> extensive networking experience in industrial networks, solving >>> different problems under different constraints. Same goes in AMI/AMR >>> networks, and to a lesser extent in Home, commercial and building >>> automation. Some groups in the IETF have finally started to pay >>> attention and build on that experience. Even if the resulting >>> technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the = scale >>> is such that over a few years we have seen unprecedented amounts of >>> implementations, interop and compliance tests (e.g. under IPSO and = WCI). >>>=20 >>> Also, if we map home use cases with the routing technologies that >>> applied today, we see that at the moment the traditional IGPs do not >>> play much role, at least from the home standpoint: >>> - Internet to Home (Content consumption) is not a Home problem >>> - Home to Internet (metering, P2P) is a default route >>> - Home to Home (Content and Access sharing) is dominated by OLSR. >>> - Inside Home (Content and Device sharing) is single subnet, solved >>> reactively by ARP or ND. >>> - Inside Home (Command & Control, Automation) meshing is proprietary >>> though going 6LoWPAN and RPL. >>>=20 >>> In any fashion, we can solve an additional problem of our own making >>> that would require our beloved ICT IGPs to be injected in the Home >>> network with always-on routers in each room or we can start = producing >>> best practices on how the above can to be done with the technologies >>> that are already in place. Or both? >>>=20 >>> *** whether we have an assumption of a plethora of power >>>=20 >>> Year over year, we've seen the simplest devices migrate from a >>> totally-switched-off mode to some more and more power greedy = sleeping >>> and always-on modes. >>> Always-on displays and LEDs appears fancy to the consumer but are of >>> consequence on the family budget and at the scale of a city, result = in >>> measurable pollution. >>> And we've been connecting more and more devices to the home power >>> distribution, devices that would not exist 10-20 years ago. >>> We know how power-greedy traditional ICT technologies are; people do >>> not want a new heating system that they cannot even stop in summer. >>> My take is that whatever this group produces has to be justified in >>> terms of power budget as it has to be justified in other terms like >>> usability and security. >>>=20 >>>=20 >>> *** if HOMENET is targeting home gateways and large home cinema gear >>> only, and whether we have an assumption of cat 5/6 cabling >>>=20 >>> This case is probably the low hanging fruit and that there is an >>> immediate need to solve a number of problems there. If that's what = the >>> group is pursuing for the time being, well, that's fine as long as = it's >>> very clear to everybody. But the rest of the world is low power and >>> lossy. Apart from certain ecological niches (that's datacenter = mostly) >>> about all Internet-connected devices have evolved the wireless = trait, >>> even if the most traditional devices can still use wires. The new = trait >>> has lowered dramatically the cost and complexity of accessing the >>> Internet, which in turn allowed the introduction of new species of >>> internet-connected devices that now thrive under the name of Things. = At >>> some point we'll have to address that too. >>>=20 >>> I do not know how that converts into cents at the current rate... >>>=20 >>> Pascal >>>=20 >>> -----Original Message----- >>> From: C Chauvenet [mailto:c.chauvenet@watteco.com] >>> Sent: jeudi 29 septembre 2011 17:23 >>> To: Acee Lindem; Fred Baker (fred) >>> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; >>> homenet@ietf.org; rtgwg@ietf.org >>> Subject: RE: [homenet] Question for you >>>=20 >>> Hi,=20 >>>=20 >>> " I don't think my wife would want a lossy network in our house ;^)" = : >>>=20 >>> Nobody wants a lossy network, but the technology you are using may >>> create lossy links... >>>=20 >>> I may have miss something in the Homenet scope. >>>=20 >>> In the scope of Homenet, is every device in the house runing over a >>> *robust* link (Bit Error Rate below 1 % at the PHY level) ? >>>=20 >>> Furthermore do these devices could have some high >>> Power/Computation/Size/Cost constraints ? >>>=20 >>> I fail to see the kind of technologies and devices that are = targeting. >>>=20 >>> Thanks for the clarification. >>>=20 >>> C=E9dric . >>>=20 >>> -----Message d'origine----- >>> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi = 29 >>> septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C = Chauvenet; >>> Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; = rtgwg@ietf.org >>> Objet : Re: [homenet] Question for you >>>=20 >>> I'm in complete agreement with Fred. The areas where the existing >>> link-state protocols may need to be extended are auto-configuration = and, >>> potentially, inter-area policies. >>> I don't think my wife would want a lossy network in our house ;^) >>> Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: >>>=20 >>>>=20 >>>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>>>=20 >>>>> Since you asked, *I* think that a homenet has functional overlap >>>>> (what I called "at least a smaller and slightly different subset" = in >>>>> my email) in terms of requirements to LLNs. At first blush, it = looks >>>>> like RPL has lots of functionality - perhaps more than we really = need >>>>> for homenet, and by your own admission more than you need for = LLN's - >>>>> but will hold reservation on what I think best fits the bill until = we >>>>> see Fred's analysis, hear from others, etc. >>>>=20 >>>> My two yen, which may be all it's worth... >>>>=20 >>>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what >>>> protocols to put in, I wouldn't be asking about what still exists = in >>>> Internet Drafts and is thought by the engineers designing it to be >>>> better than sliced bread, but about what was inexpensive to = implement, >>>> likely to be close to bug-free, and definitively accomplished the = goal. >>>> I note that most routers for the IPv4 residential routing = marketplace >>>> implement RIPv2; I know of one that implements no routing protocol, = one >>>> that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 = and >>>> OSPF (don't ask which they are, I don't remember). This is from a >>>> google search of residential routers a few months ago and covered >>>> perhaps 20 products from half as many vendors. So my first = inclination >>>> is to say that for a residential IPv6 network, RIPng is probably an >>>> image match for those vendors. >>>>=20 >>>> I have a personal bias in the direction of OSPF or IS-IS; I think = that >>>> once the code is debugged, SPF-based protocols are more stable (no >>>> count-to-infinity), given a reasonable set of defaults generate far >>>> more stable networks, and definitively know when there is more than = one >>>> router on a LAN, which can be important in subnet distribution. >>>>=20 >>>> My first choice would NOT be something that isn't proven in the = field >>>> in multiple interoperable implementations. >>>>=20 >>>> As a person thinking about making a recommendation, I'd suggest = that >>>> folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask >>>> themselves why that level of interoperability isn't mandatory. >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From Ray.Bellis@nominet.org.uk Mon Oct 3 01:38:56 2011 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 8352721F8AF4 for ; Mon, 3 Oct 2011 01:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T-ZN7NjEdhV for ; Mon, 3 Oct 2011 01:38:55 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED621F8B0C for ; Mon, 3 Oct 2011 01:38:54 -0700 (PDT) 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=mqhw0VMy/WjCKGodeQUSS8jNSNHRH68ojeQRzkfal9h3Dv1f+h/FISZt BAVevIo0f7/AI5H+24vM99+sp3MFVrwjH8weH9EE+PlpFVhCHPmWh9Fv4 k8sF+d04mWLhPG1; 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=1317631317; x=1349167317; 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:=20Interim=20meeting=20-=20Wednesday=20evening |Date:=20Mon,=203=20Oct=202011=2008:41:54=20+0000 |Message-ID:=20<60D8E146-B315-447B-920E-24332981D929@nomi net.org.uk>|To:=20"homenet@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<81428029-fa7f-4705-b371-18ba6268 cdc9>; bh=lZ+AFVe2BKVrLZhbsdTDOA3NsEhzvyaBIitGzZs+yxo=; b=uKdpN9i/G9iRi1StLAXl6o7yuNT1ul1OAHtF/4AheIqcX4kyTx+1sVUQ NjTbBCnZk3kChe8T5TnZdgu4ghPQ7DovNrEztK3NOBI5trchbQy6yihdE V3gJirNhrPQjdo3; X-IronPort-AV: E=Sophos;i="4.68,478,1312153200"; d="scan'208";a="35705364" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 03 Oct 2011 09:41:55 +0100 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%19]) with mapi; Mon, 3 Oct 2011 09:41:55 +0100 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: Interim meeting - Wednesday evening Thread-Index: AQHMgahN4GhTTpwg3Ei/6/v7s3CSiw== Date: Mon, 3 Oct 2011 08:41:54 +0000 Message-ID: <60D8E146-B315-447B-920E-24332981D929@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: <81428029-fa7f-4705-b371-18ba6268cdc9> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Interim meeting - Wednesday evening 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, 03 Oct 2011 08:38:56 -0000 For early arrivals to our Interim we have a slot on Wednesday evening for a= n informal social gathering (i.e. beer and nibbles in a bar somewhere). Comcast have graciously offered instead to invite the Interim attendees to = the ISOC social event following INET Philadelphia reception on the 43rd flo= or of the Comcast Center and Mark and I have accepted that offer. If you're registered for the Interim and would like to attend, please regis= ter ASAP at: Registration is required for headcount and security purposes. thanks, Ray and Mark From jason_livingood@cable.comcast.com Mon Oct 3 06:05:39 2011 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 B58A321F8B29 for ; Mon, 3 Oct 2011 06:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-1.315, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CwstBBZFSPO for ; Mon, 3 Oct 2011 06:05:35 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8341D21F8B26 for ; Mon, 3 Oct 2011 06:05:35 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.55441749; Mon, 03 Oct 2011 07:02:51 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Mon, 3 Oct 2011 08:55:53 -0400 From: "Livingood, Jason" To: "homenet@ietf.org" Thread-Topic: [homenet] Interim meeting - Wednesday evening Thread-Index: AQHMgahN4GhTTpwg3Ei/6/v7s3CSi5VqlTaA Date: Mon, 3 Oct 2011 12:55:52 +0000 Message-ID: In-Reply-To: <60D8E146-B315-447B-920E-24332981D929@nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <351436BBECE7A44BAB1EB09B4246180C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Interim meeting - Wednesday evening 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, 03 Oct 2011 13:05:39 -0000 And if you are in the city Wednesday evening, I really do hope you register to attend this reception. Don't forget to bring photo ID for entry into the building though. See also this info regarding the building if interested - http://en.wikipedia.org/wiki/Comcast_Center_(Philadelphia) . :-) Jason On 10/3/11 4:41 AM, "Ray Bellis" wrote: >For early arrivals to our Interim we have a slot on Wednesday evening for >an informal social gathering (i.e. beer and nibbles in a bar somewhere). > >Comcast have graciously offered instead to invite the Interim attendees >to the ISOC social event following INET Philadelphia reception on the >43rd floor of the Comcast Center and Mark and I have accepted that offer. > >If you're registered for the Interim and would like to attend, please >register ASAP at: > >ladelphia-rsvp> > >Registration is required for headcount and security purposes. > >thanks, > >Ray and Mark > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From jpv@cisco.com Mon Oct 3 06:59:17 2011 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 12ED921F8B28; Mon, 3 Oct 2011 06:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=-3.925, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsT4IcJlLIIM; Mon, 3 Oct 2011 06:59:16 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B5FD321F8B12; Mon, 3 Oct 2011 06:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3221; q=dns/txt; s=iport; t=1317650538; x=1318860138; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yJXjgXbvFieq6gtR53/Gyg4zROJLH7oFW/LhTliunic=; b=QC9TwznMXKcaCu1osaWHZpmnspxMKD6f157RP7Eci0cIhKLvft7AKlCK X9AA+WBLlvLUTv96drLzMCc3/tQsn1x/bZXemahLaNBvaupN52Y5XnsVD hO7xsCWdewD2ZGbH36o1/9Pe2kOd1cd9zWQXHPjJMxacVNnaF930GL0yG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABbAiU5Io8US/2dsb2JhbABBqACBBYFTAQEBAwEBAQEPAVsLEAsYFRknMAYTIodZBpsZAZ03A4QIgjhhBJNghSUJjBI X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208";a="209701" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 03 Oct 2011 14:01:56 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p93E1tN5015015; Mon, 3 Oct 2011 14:01:56 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:01:55 +0800 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:01:55 +0800 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> Date: Mon, 3 Oct 2011 16:01:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 03 Oct 2011 14:01:55.0377 (UTC) FILETIME=[0250D210:01CC81D5] Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] Question for you 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, 03 Oct 2011 13:59:17 -0000 On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: >=20 > On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >=20 >> Since you asked, *I* think that a homenet has functional overlap = (what I called "at least a smaller and slightly different subset" in my = email) in terms of requirements to LLNs. At first blush, it looks like = RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but = will hold reservation on what I think best fits the bill until we see = Fred's analysis, hear from others, etc.=20 >=20 > My two yen, which may be all it's worth... >=20 > If I were a Linksys/D-Link/NetGear/* product manager asking about what = protocols to put in, I wouldn't be asking about what still exists in = Internet Drafts and is thought by the engineers designing it to be = better than sliced bread, but about what was inexpensive to implement, = likely to be close to bug-free, and definitively accomplished the goal. = I note that most routers for the IPv4 residential routing marketplace = implement RIPv2; I know of one that implements no routing protocol, one = that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and = OSPF (don't ask which they are, I don't remember). This is from a google = search of residential routers a few months ago and covered perhaps 20 = products from half as many vendors. So my first inclination is to say = that for a residential IPv6 network, RIPng is probably an image match = for those vendors. >=20 > I have a personal bias in the direction of OSPF or IS-IS; I think that = once the code is debugged, SPF-based protocols are more stable (no = count-to-infinity), given a reasonable set of defaults generate far more = stable networks, and definitively know when there is more than one = router on a LAN, which can be important in subnet distribution.=20 I spent enough years on OSPF and ISIS to agree with you that these = protocols are well proven, widely deployed with the number of=20 recent improvements (MTR, fast convergence, =85) to name a few are = particularly appealing. But before choosing a routing protocol the first step consists of listing the requirements. In LLN, as you = rightly pointed out, "smart objects" have a set of constraints in terms of resources =85 far from where we are on traditional routers =85 Thus I = would strongly encourage to list the set of requirements for this type of devices before making any sort of selection on the routing = protocol of choice, taking into account where we will be in a few years when the number of these objects will not be limited to a few dozens, = the LSDB *will* grow =85=20 >=20 > My first choice would NOT be something that isn't proven in the field = in multiple interoperable implementations.=20 >=20 > As a person thinking about making a recommendation, I'd suggest that = folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask = themselves why that level of interoperability isn't mandatory. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From jpv@cisco.com Mon Oct 3 07:06:22 2011 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 4333321F8B65; Mon, 3 Oct 2011 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwhsWpEnLtkT; Mon, 3 Oct 2011 07:06:20 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1774421F8B67; Mon, 3 Oct 2011 07:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=25663; q=dns/txt; s=iport; t=1317650962; x=1318860562; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=RtK+j3xpaY94bbYVNqKb98mWHEf7rjwsKTXqwCKWi5c=; b=nGYez50rU1nr1f0bQufjvqDicdSyMpSe8Ho3iD6gI3iISxG9v2igG3jP YhGQvcHHO6FsI6r95SMHEGh3gH18OsJPeR2HHzF+ioFSwIOZ4N6GYtTw/ HUE2PnEhaCRx2rjE18CUa/byfiTiFMavspyREBoQo02jWRPzneV/pJteb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACTBiU6rRDoI/2dsb2JhbABBqACBBYFTAQEBAwEBAQEPAQcDEEELBQcECw4DBAEBAScHJx8JCAYTGweHWQabJwGdNwOGQGEEk2CFJQmMEg X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208,217";a="5616848" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Oct 2011 14:09:22 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p93E9Lbc017226; Mon, 3 Oct 2011 14:09:21 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 07:09:21 -0700 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 07:09:20 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907" From: JP Vasseur In-Reply-To: Date: Mon, 3 Oct 2011 16:09:17 +0200 Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 03 Oct 2011 14:09:20.0655 (UTC) FILETIME=[0BB8D9F0:01CC81D6] Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , "Fred Baker \(fred\)" , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 03 Oct 2011 14:06:22 -0000 --Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 100% agreeing with you Don. On Oct 1, 2011, at 4:38 PM, Don Sturek wrote: > To add one more point to Fred's note: I think it is important to get = a > commercial group like Wi-Fi to participate in Homenet, adopt some or = all > of the drafts/RFCs then sponsor interoperability testing. >=20 > I agree with Fred that having individual CPE vendors cobbling together > RFCs will not yield a bullet proof home networking solution and that = will > kill the work in Homenet if customer support is needed. >=20 > Don >=20 >=20 >=20 > On 9/30/11 11:26 AM, "Fred Baker" wrote: >=20 > >As I understand it, we have made the case that there is a place for > >routing in at least some homes and in SOHO networks, and we should = say > >what protocols manufacturers should consider implementing in = equipment > >they sell. Two significant parts of the issue there, as you know, are > >operational expense and cost of goods. Margins in residential routers = are > >thin enough that manufacturers (one of which you know from the = inside) > >essentially lose their entire profit margin if they pick up the phone = for > >a trouble call, and in addition the memory to store the code and = data, > >and the code itself, cost money on a COGS basis. Manufacturers want = to be > >able to buy trouble-free code for a predictable price, put it in the > >system, and forget the system. > > > >Which argues for proven specifications and implementations that have = been > >field proven to interoperate when used in anger. > > > >To my knowledge, this doesn't automatically imply "give me that old = time > >religion". It does call for proven (and preferably documented) > >interoperability between numerous independent complete = implementations, > >or proven interoperability of a common profile of a protocol, an = exercise > >I have suggested to some proponents of your favorite protocol is good = for > >the soul. RFC 1246 comes to mind. > > > >By the way, let me clarify a point that you may be confused on. There = are > >detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I > >think IPv4/IS-IS. To my knowledge, there has been interoperability > >testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which = are > >in use in production networks, but the test documentation is a trifle > >thin. So I'm not asking of your favorite protocol or a dozen others = that > >one could discuss something I think should let slide for the = traditional > >ones. I am simply asking that the claims for the protocols be backed = with > >interoperability testing, RFCs, Security Directorate reviews, and so = on. > > > >On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: > > > >> Hello Cedric: > >> > >> I have the same questions. Furthermore, I'd wish to understand = better: > >> > >> *** whether the goal is limited to provide a best practice based on > >>"established" ICT technologies > >> > >> There are other "established" technologies. For instance there is > >>extensive networking experience in industrial networks, solving > >>different problems under different constraints. Same goes in AMI/AMR > >>networks, and to a lesser extent in Home, commercial and building > >>automation. Some groups in the IETF have finally started to pay > >>attention and build on that experience. Even if the resulting > >>technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the = scale > >>is such that over a few years we have seen unprecedented amounts of > >>implementations, interop and compliance tests (e.g. under IPSO and = WCI). > >> > >> Also, if we map home use cases with the routing technologies that > >>applied today, we see that at the moment the traditional IGPs do not > >>play much role, at least from the home standpoint: > >> - Internet to Home (Content consumption) is not a Home problem > >> - Home to Internet (metering, P2P) is a default route > >> - Home to Home (Content and Access sharing) is dominated by OLSR. > >> - Inside Home (Content and Device sharing) is single subnet, solved > >>reactively by ARP or ND. > >> - Inside Home (Command & Control, Automation) meshing is = proprietary > >>though going 6LoWPAN and RPL. > >> > >> In any fashion, we can solve an additional problem of our own = making > >>that would require our beloved ICT IGPs to be injected in the Home > >>network with always-on routers in each room or we can start = producing > >>best practices on how the above can to be done with the technologies > >>that are already in place. Or both? > >> > >> *** whether we have an assumption of a plethora of power > >> > >> Year over year, we've seen the simplest devices migrate from a > >>totally-switched-off mode to some more and more power greedy = sleeping > >>and always-on modes. > >> Always-on displays and LEDs appears fancy to the consumer but are = of > >>consequence on the family budget and at the scale of a city, result = in > >>measurable pollution. > >> And we've been connecting more and more devices to the home power > >>distribution, devices that would not exist 10-20 years ago. > >> We know how power-greedy traditional ICT technologies are; people = do > >>not want a new heating system that they cannot even stop in summer. > >> My take is that whatever this group produces has to be justified in > >>terms of power budget as it has to be justified in other terms like > >>usability and security. > >> > >> > >> *** if HOMENET is targeting home gateways and large home cinema = gear > >>only, and whether we have an assumption of cat 5/6 cabling > >> > >> This case is probably the low hanging fruit and that there is an > >>immediate need to solve a number of problems there. If that's what = the > >>group is pursuing for the time being, well, that's fine as long as = it's > >>very clear to everybody. But the rest of the world is low power and > >>lossy. Apart from certain ecological niches (that's datacenter = mostly) > >>about all Internet-connected devices have evolved the wireless = trait, > >>even if the most traditional devices can still use wires. The new = trait > >>has lowered dramatically the cost and complexity of accessing the > >>Internet, which in turn allowed the introduction of new species of > >>internet-connected devices that now thrive under the name of Things. = At > >>some point we'll have to address that too. > >> > >> I do not know how that converts into cents at the current rate... > >> > >> Pascal > >> > >> -----Original Message----- > >> From: C Chauvenet [mailto:c.chauvenet@watteco.com] > >> Sent: jeudi 29 septembre 2011 17:23 > >> To: Acee Lindem; Fred Baker (fred) > >> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; > >>homenet@ietf.org; rtgwg@ietf.org > >> Subject: RE: [homenet] Question for you > >> > >> Hi, > >> > >> " I don't think my wife would want a lossy network in our house = ;^)" : > >> > >> Nobody wants a lossy network, but the technology you are using may > >>create lossy links... > >> > >> I may have miss something in the Homenet scope. > >> > >> In the scope of Homenet, is every device in the house runing over a > >>*robust* link (Bit Error Rate below 1 % at the PHY level) ? > >> > >> Furthermore do these devices could have some high > >>Power/Computation/Size/Cost constraints ? > >> > >> I fail to see the kind of technologies and devices that are = targeting. > >> > >> Thanks for the clarification. > >> > >> C=E9dric . > >> > >> -----Message d'origine----- > >> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi = 29 > >>septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C = Chauvenet; > >>Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; = rtgwg@ietf.org > >>Objet : Re: [homenet] Question for you > >> > >> I'm in complete agreement with Fred. The areas where the existing > >>link-state protocols may need to be extended are auto-configuration = and, > >>potentially, inter-area policies. > >> I don't think my wife would want a lossy network in our house ;^) > >>Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: > >> > >>> > >>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: > >>> > >>>> Since you asked, *I* think that a homenet has functional overlap > >>>>(what I called "at least a smaller and slightly different subset" = in > >>>>my email) in terms of requirements to LLNs. At first blush, it = looks > >>>>like RPL has lots of functionality - perhaps more than we really = need > >>>>for homenet, and by your own admission more than you need for = LLN's - > >>>>but will hold reservation on what I think best fits the bill until = we > >>>>see Fred's analysis, hear from others, etc. > >>> > >>> My two yen, which may be all it's worth... > >>> > >>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what > >>>protocols to put in, I wouldn't be asking about what still exists = in > >>>Internet Drafts and is thought by the engineers designing it to be > >>>better than sliced bread, but about what was inexpensive to = implement, > >>>likely to be close to bug-free, and definitively accomplished the = goal. > >>>I note that most routers for the IPv4 residential routing = marketplace > >>>implement RIPv2; I know of one that implements no routing protocol, = one > >>>that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 = and > >>>OSPF (don't ask which they are, I don't remember). This is from a > >>>google search of residential routers a few months ago and covered > >>>perhaps 20 products from half as many vendors. So my first = inclination > >>>is to say that for a residential IPv6 network, RIPng is probably an > >>>image match for those vendors. > >>> > >>> I have a personal bias in the direction of OSPF or IS-IS; I think = that > >>>once the code is debugged, SPF-based protocols are more stable (no > >>>count-to-infinity), given a reasonable set of defaults generate far > >>>more stable networks, and definitively know when there is more than = one > >>>router on a LAN, which can be important in subnet distribution. > >>> > >>> My first choice would NOT be something that isn't proven in the = field > >>>in multiple interoperable implementations. > >>> > >>> As a person thinking about making a recommendation, I'd suggest = that > >>>folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask > >>>themselves why that level of interoperability isn't mandatory. > >>> _______________________________________________ > >>> homenet mailing list > >>> homenet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/homenet > >> > >> > >> > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 100% = agreeing with you Don.

On Oct 1, 2011, at 4:38 PM, Don = Sturek wrote:

Re: [manet] [homenet] Question for you
To add = one more point to Fred's note:  I think it is important to get = a
commercial group like Wi-Fi to participate in Homenet, adopt some or = all
of the drafts/RFCs then sponsor interoperability testing.

I agree with Fred that having individual CPE vendors cobbling = together
RFCs will not yield a bullet proof home networking solution and that = will
kill the work in Homenet if customer support is needed.

Don



On 9/30/11 11:26 AM, "Fred Baker" <fred@cisco.com> wrote:

>As I understand it, we have made the case that there is a place = for
>routing in at least some homes and in SOHO networks, and we should = say
>what protocols manufacturers should consider implementing in = equipment
>they sell. Two significant parts of the issue there, as you know, = are
>operational expense and cost of goods. Margins in residential = routers are
>thin enough that manufacturers (one of which you know from the = inside)
>essentially lose their entire profit margin if they pick up the = phone for
>a trouble call, and in addition the memory to store the code and = data,
>and the code itself, cost money on a COGS basis. Manufacturers want = to be
>able to buy trouble-free code for a predictable price, put it in = the
>system, and forget the system.
>
>Which argues for proven specifications and implementations that have = been
>field proven to interoperate when used in anger.
>
>To my knowledge, this doesn't automatically imply "give me that old = time
>religion". It does call for proven (and preferably documented)
>interoperability between numerous independent complete = implementations,
>or proven interoperability of a common profile of a protocol, an = exercise
>I have suggested to some proponents of your favorite protocol is = good for
>the soul. RFC 1246 comes to mind.
>
>By the way, let me clarify a point that you may be confused on. = There are
>detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and = I
>think IPv4/IS-IS. To my knowledge, there has been = interoperability
>testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which = are
>in use in production networks, but the test documentation is a = trifle
>thin. So I'm not asking of your favorite protocol or a dozen others = that
>one could discuss something I think should let slide for the = traditional
>ones. I am simply asking that the claims for the protocols be backed = with
>interoperability testing, RFCs, Security Directorate reviews, and so = on.
>
>On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote:
>
>> Hello Cedric:
>>
>> I have the same questions. Furthermore, I'd wish to understand = better:
>>
>> *** whether the goal is limited to provide a best practice = based on
>>"established" ICT technologies
>>
>> There are other "established" technologies. For instance there = is
>>extensive networking experience in industrial networks, = solving
>>different problems under different constraints. Same goes in = AMI/AMR
>>networks, and to a lesser extent in Home, commercial and = building
>>automation. Some groups in the IETF have finally started to = pay
>>attention and build on that experience. Even if the = resulting
>>technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, = the scale
>>is such that over a few years we have seen unprecedented amounts = of
>>implementations, interop and compliance tests (e.g. under IPSO = and WCI).
>>
>> Also, if we map home use cases with the routing technologies = that
>>applied today, we see that at the moment the traditional IGPs do = not
>>play much role, at least from the home standpoint:
>> - Internet to Home (Content consumption) is not a Home = problem
>> - Home to Internet (metering, P2P)  is a default route
>> - Home to Home (Content and Access sharing) is dominated by = OLSR.
>> - Inside Home (Content and Device sharing) is single subnet, = solved
>>reactively by ARP or ND.
>> - Inside Home (Command & Control, Automation) meshing is = proprietary
>>though going 6LoWPAN and RPL.
>>
>> In any fashion, we can solve an additional problem of our own = making
>>that would require our beloved ICT IGPs to be injected in the = Home
>>network with always-on routers in each room or we can start = producing
>>best practices on how the above can to be done with the = technologies
>>that are already in place. Or both?
>>
>> *** whether we have an assumption of a plethora of power
>>
>> Year over year, we've seen the simplest devices migrate from = a
>>totally-switched-off mode to some more and more power greedy = sleeping
>>and always-on modes.
>> Always-on displays and LEDs appears fancy to the consumer but = are of
>>consequence on the family budget and at the scale of a city, = result in
>>measurable pollution.
>> And we've been connecting more and more devices to the home = power
>>distribution, devices that would not exist 10-20 years ago.
>> We know how power-greedy traditional ICT technologies are; = people do
>>not want a new heating system that they cannot even stop in = summer.
>> My take is that whatever this group produces has to be = justified in
>>terms of power budget as it has to be justified in other terms = like
>>usability and security.
>>
>>
>> *** if HOMENET is targeting home gateways and large home cinema = gear
>>only, and whether we have an assumption of cat 5/6 cabling
>>
>> This case is probably the low hanging fruit and that there is = an
>>immediate need to solve a number of problems there. If that's = what the
>>group is pursuing for the time being, well, that's fine as long = as it's
>>very clear to everybody. But the rest of the world is low power = and
>>lossy. Apart from certain ecological niches (that's datacenter = mostly)
>>about all Internet-connected devices have evolved the wireless = trait,
>>even if the most traditional devices can still use wires. The = new trait
>>has lowered dramatically the cost and complexity of accessing = the
>>Internet, which in turn allowed the introduction of new species = of
>>internet-connected devices that now thrive under the name of = Things. At
>>some point we'll have to address that too.
>>
>> I do not know how that converts into cents at the current = rate...
>>
>> Pascal
>>
>> -----Original Message-----
>> From: C Chauvenet [mailto:c.chauvenet@watteco.com= ]
>> Sent: jeudi 29 septembre 2011 17:23
>> To: Acee Lindem; Fred Baker (fred)
>> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF;
>>homenet@ietf.org; rtgwg@ietf.org
>> Subject: RE: [homenet] Question for you
>>
>> Hi,
>>
>> " I don't think my wife would want a lossy network in our house = ;^)" :
>>
>> Nobody wants a lossy network, but the technology you are using = may
>>create lossy links...
>>
>> I may have miss something in the Homenet scope.
>>
>> In the scope of Homenet, is every device in the house runing = over a
>>*robust* link (Bit Error Rate below 1 % at the PHY level) ?
>>
>> Furthermore do these devices could have some high
>>Power/Computation/Size/Cost constraints ?
>>
>> I fail to see the kind of technologies and devices that are = targeting.
>>
>> Thanks for the clarification.
>>
>> C=E9dric .
>>
>> -----Message d'origine-----
>> De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 : jeudi 29
>>septembre 2011 16:44 =C0 : Fred Baker Cc : Mark Townsley; C = Chauvenet;
>>Pascal Thubert (pthubert); MANET IETF; homenet@ietf.org; rtgwg@ietf.org
>>Objet : Re: [homenet] Question for you
>>
>> I'm in complete agreement with Fred. The areas where the = existing
>>link-state protocols may need to be extended are = auto-configuration and,
>>potentially, inter-area policies.
>> I don't think my wife would want a lossy network in our house = ;^)
>>Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote:
>>
>>>
>>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote:
>>>
>>>> Since you asked, *I* think that a homenet has = functional overlap
>>>>(what I called "at least a smaller and slightly = different subset" in
>>>>my email) in terms of requirements to LLNs. At first = blush, it looks
>>>>like RPL has lots of functionality - perhaps more than = we really need
>>>>for homenet, and by your own admission more than you = need for LLN's -
>>>>but will hold reservation on what I think best fits the = bill until we
>>>>see Fred's analysis, hear from others, etc.
>>>
>>> My two yen, which may be all it's worth...
>>>
>>> If I were a Linksys/D-Link/NetGear/* product manager asking = about what
>>>protocols to put in, I wouldn't be asking about what still = exists in
>>>Internet Drafts and is thought by the engineers designing it = to be
>>>better than sliced bread, but about what was inexpensive to = implement,
>>>likely to be close to bug-free, and definitively = accomplished the goal.
>>>I note that most routers for the IPv4 residential routing = marketplace
>>>implement RIPv2; I know of one that implements no routing = protocol, one
>>>that implements RIPv2 and RIPv1 (!), and one that implements = RIPv2 and
>>>OSPF (don't ask which they are, I don't remember). This is = from a
>>>google search of residential routers a few months ago and = covered
>>>perhaps 20 products from half as many vendors. So my first = inclination
>>>is to say that for a residential IPv6 network, RIPng is = probably an
>>>image match for those vendors.
>>>
>>> I have a personal bias in the direction of OSPF or IS-IS; I = think that
>>>once the code is debugged, SPF-based protocols are more = stable (no
>>>count-to-infinity), given a reasonable set of defaults = generate far
>>>more stable networks, and definitively know when there is = more than one
>>>router on a LAN, which can be important in subnet = distribution.
>>>
>>> My first choice would NOT be something that isn't proven in = the field
>>>in multiple interoperable implementations.
>>>
>>> As a person thinking about making a recommendation, I'd = suggest that
>>>folks read https://tools.i= etf.org/html/rfc2026#section-4.1.2 and ask
>>>themselves why that level of interoperability isn't = mandatory.
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.or= g/mailman/listinfo/homenet
>>
>>
>>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www.ietf.org/= mailman/listinfo/manet


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

= --Apple-Mail=_524F1856-FAC7-4746-8A42-E35165549907-- From rogerj@gmail.com Mon Oct 3 07:16:22 2011 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 2DCC621F8B5F for ; Mon, 3 Oct 2011 07:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skaLSEN+LdDy for ; Mon, 3 Oct 2011 07:16:12 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA3D821F8B4A for ; Mon, 3 Oct 2011 07:16:11 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5911525bka.31 for ; Mon, 03 Oct 2011 07:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=URMcE79i3GlCHILnfGcuRKDxwkbVxrHKXNqQAIFQyHM=; b=r6EFlikk0E7XoTWVafTEHIg3kHdcoBTftO/McEUx82txXybD/+ffl7Lx6BaMsej0BE DwQluQy56X5kCftlc8+Fp0OjARhCZ6hEJDxMzf89eW75d80spNC8VqnJXCgyM+I4fXtI cAoQRLEnwYS8riUiijkOKTcl1MAdR55JFcBWI= MIME-Version: 1.0 Received: by 10.204.153.208 with SMTP id l16mr12088bkw.6.1317651552425; Mon, 03 Oct 2011 07:19:12 -0700 (PDT) Received: by 10.204.40.131 with HTTP; Mon, 3 Oct 2011 07:19:12 -0700 (PDT) In-Reply-To: <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> Date: Mon, 3 Oct 2011 16:19:12 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: JP Vasseur Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org, rogerj@gmail.com, Fred Baker Subject: Re: [homenet] Question for you 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, 03 Oct 2011 14:16:22 -0000 trimming the cc: list a bit On Mon, Oct 3, 2011 at 4:01 PM, JP Vasseur wrote: > I spent enough years on OSPF and ISIS to agree with you that these protoc= ols are well proven, widely deployed with the number of > recent improvements (MTR, fast convergence, =85) to name a few are partic= ularly appealing. But before choosing a routing protocol > the first step consists of listing the requirements. In LLN, as you right= ly pointed out, "smart objects" have a set of constraints in terms > of resources =85 far from where we are on traditional routers =85 Thus I = would strongly encourage to list the set of requirements for this > type of devices before making any sort of selection on the routing protoc= ol of choice, taking into account where we will be in a few years > when the number of these objects will not be limited to a few dozens, the= LSDB *will* grow =85 As I see it, we are trying to limit our options of routing protocols down to a few that can/should/might be implemented in HOMENET devices. Again, as I see it, there are two ways to get there, no idea which are the best, probably both 1.) (you suggested) create a list over requirements 2.) (Fred working on) create a list over all possible (and not possible) routing protocols why don't you start listing some suggestions for requirements while Fred create his list? I'm quite sure we'll end up with one good documented list:-) (I don't know enough of possible requirements yet to list any...) --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From acee.lindem@ericsson.com Mon Oct 3 07:21:52 2011 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 DA3E121F8B42; Mon, 3 Oct 2011 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNSUcI4YtZBJ; Mon, 3 Oct 2011 07:21:45 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BC92A21F8B4A; Mon, 3 Oct 2011 07:21:44 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p93EOVnB016847; Mon, 3 Oct 2011 09:24:32 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 3 Oct 2011 10:24:26 -0400 From: Acee Lindem To: JP Vasseur Date: Mon, 3 Oct 2011 10:24:26 -0400 Thread-Topic: [homenet] Question for you Thread-Index: AcyB2Ceq6pwYuC1ATY2JzWbYuLz6Zw== Message-ID: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 14:21:57 -0000 Hey JP, On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote: >=20 > On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: >=20 >>=20 >> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>=20 >>> Since you asked, *I* think that a homenet has functional overlap (what = I called "at least a smaller and slightly different subset" in my email) in= terms of requirements to LLNs. At first blush, it looks like RPL has lots = of functionality - perhaps more than we really need for homenet, and by you= r own admission more than you need for LLN's - but will hold reservation on= what I think best fits the bill until we see Fred's analysis, hear from ot= hers, etc.=20 >>=20 >> My two yen, which may be all it's worth... >>=20 >> If I were a Linksys/D-Link/NetGear/* product manager asking about what p= rotocols to put in, I wouldn't be asking about what still exists in Interne= t Drafts and is thought by the engineers designing it to be better than sli= ced bread, but about what was inexpensive to implement, likely to be close = to bug-free, and definitively accomplished the goal. I note that most route= rs for the IPv4 residential routing marketplace implement RIPv2; I know of = one that implements no routing protocol, one that implements RIPv2 and RIPv= 1 (!), and one that implements RIPv2 and OSPF (don't ask which they are, I = don't remember). This is from a google search of residential routers a few = months ago and covered perhaps 20 products from half as many vendors. So my= first inclination is to say that for a residential IPv6 network, RIPng is = probably an image match for those vendors. >>=20 >> I have a personal bias in the direction of OSPF or IS-IS; I think that o= nce the code is debugged, SPF-based protocols are more stable (no count-to-= infinity), given a reasonable set of defaults generate far more stable netw= orks, and definitively know when there is more than one router on a LAN, wh= ich can be important in subnet distribution.=20 >=20 > I spent enough years on OSPF and ISIS to agree with you that these protoc= ols are well proven, widely deployed with the number of=20 > recent improvements (MTR, fast convergence, =85) to name a few are partic= ularly appealing. But before choosing a routing protocol > the first step consists of listing the requirements. In LLN, as you right= ly pointed out, "smart objects" have a set of constraints in terms > of resources =85 far from where we are on traditional routers =85 Thus I = would strongly encourage to list the set of requirements for this > type of devices before making any sort of selection on the routing protoc= ol of choice, taking into account where we will be in a few years > when the number of these objects will not be limited to a few dozens, the= LSDB *will* grow =85=20 I think a viable option for 2012 is that if the LLN networks with their sma= rt objects have to connect to the traditional HOMENET fixed and wireless ne= tworks, they will need to do so through a border router supporting both env= ironments. IMHO, we don't need one protocol that meets all requirements for= every possible device in the home.=20 Thanks, Acee=20 >=20 >>=20 >> My first choice would NOT be something that isn't proven in the field in= multiple interoperable implementations.=20 >>=20 >> As a person thinking about making a recommendation, I'd suggest that fol= ks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselve= s why that level of interoperability isn't mandatory. >> _______________________________________________ >> 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 jpv@cisco.com Mon Oct 3 07:24:12 2011 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 048D421F8B42; Mon, 3 Oct 2011 07:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.088 X-Spam-Level: X-Spam-Status: No, score=-106.088 tagged_above=-999 required=5 tests=[AWL=-3.489, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxHlbduny7LV; Mon, 3 Oct 2011 07:24:08 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7A77421F8B44; Mon, 3 Oct 2011 07:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4147; q=dns/txt; s=iport; t=1317652030; x=1318861630; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=w1iDIrttuR9AFBLxAcxaHhhxb0QdgMPYXINpyQRQV0I=; b=jSMais6RnStApBVpLVJKeibE4fVvXIzVvlfFLMI2lePmm/omY9Ot9R5E YJj1V2DY22OwWlcX00RVj2roF2y7SodGDlzsWSQqM96pxemfVUGdX6p0r uq011kbxdKubjaIiGI7LKgH2KDX1AA2cE6RvS/4q7q2Aji3BofUiqrMgU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN/FiU5Io8UQ/2dsb2JhbABBqAGBBYFTAQEBAwEBAQEPAVsLBQsLGBUZJzAGEyKHWQabPwGdPwOECII4YQSTYIUlCYwS X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208";a="211220" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 03 Oct 2011 14:27:07 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p93ER6Mf007422; Mon, 3 Oct 2011 14:27:06 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:27:06 +0800 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 22:27:05 +0800 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: Date: Mon, 3 Oct 2011 16:27:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <667EF281-69A7-4F24-B426-DBD524F2CFC1@cisco.com> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Acee Lindem X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 03 Oct 2011 14:27:05.0899 (UTC) FILETIME=[86A82FB0:01CC81D8] Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 14:24:12 -0000 Hey Acee, On Oct 3, 2011, at 4:24 PM, Acee Lindem wrote: > Hey JP, >=20 > On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote: >=20 >>=20 >> On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: >>=20 >>>=20 >>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: >>>=20 >>>> Since you asked, *I* think that a homenet has functional overlap = (what I called "at least a smaller and slightly different subset" in my = email) in terms of requirements to LLNs. At first blush, it looks like = RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but = will hold reservation on what I think best fits the bill until we see = Fred's analysis, hear from others, etc.=20 >>>=20 >>> My two yen, which may be all it's worth... >>>=20 >>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what protocols to put in, I wouldn't be asking about what still exists = in Internet Drafts and is thought by the engineers designing it to be = better than sliced bread, but about what was inexpensive to implement, = likely to be close to bug-free, and definitively accomplished the goal. = I note that most routers for the IPv4 residential routing marketplace = implement RIPv2; I know of one that implements no routing protocol, one = that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and = OSPF (don't ask which they are, I don't remember). This is from a google = search of residential routers a few months ago and covered perhaps 20 = products from half as many vendors. So my first inclination is to say = that for a residential IPv6 network, RIPng is probably an image match = for those vendors. >>>=20 >>> I have a personal bias in the direction of OSPF or IS-IS; I think = that once the code is debugged, SPF-based protocols are more stable (no = count-to-infinity), given a reasonable set of defaults generate far more = stable networks, and definitively know when there is more than one = router on a LAN, which can be important in subnet distribution.=20 >>=20 >> I spent enough years on OSPF and ISIS to agree with you that these = protocols are well proven, widely deployed with the number of=20 >> recent improvements (MTR, fast convergence, =85) to name a few are = particularly appealing. But before choosing a routing protocol >> the first step consists of listing the requirements. In LLN, as you = rightly pointed out, "smart objects" have a set of constraints in terms >> of resources =85 far from where we are on traditional routers =85 = Thus I would strongly encourage to list the set of requirements for this >> type of devices before making any sort of selection on the routing = protocol of choice, taking into account where we will be in a few years >> when the number of these objects will not be limited to a few dozens, = the LSDB *will* grow =85=20 >=20 > I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home.=20 >=20 100% agreeing with you !! This is why I was limiting my comments to = "constrained objects" - Very much in line with you. Cheers. JP. > Thanks, > Acee=20 >=20 >=20 >=20 >>=20 >>>=20 >>> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations.=20 >>>=20 >>> As a person thinking about making a recommendation, I'd suggest that = folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask = themselves why that level of interoperability isn't mandatory. >>> _______________________________________________ >>> 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 bingxuere@gmail.com Mon Oct 3 08:30:25 2011 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 8EBC821F8B6F; Mon, 3 Oct 2011 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJqY3MNbw7qq; Mon, 3 Oct 2011 08:30:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6CBB21F8B6B; Mon, 3 Oct 2011 08:30:24 -0700 (PDT) Received: by iaby26 with SMTP id y26so6525242iab.31 for ; Mon, 03 Oct 2011 08:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xbstRIVnA5yg8Y10cKeOIzLdtKBFo8pidW1/bVximlQ=; b=jRj1FRHe8ID7J/RJVIKSLZbsboTDszu/VzA+EfAlY6va3ifFNe0MAD3ykARg0lrqIK slTKVlO8JT/vSRQrG4yVFrXt7/t+OIfxSrW3lcrWIOzMsGfTucoK797ytFsfFFMvsRAC pQei1GYN4wI5LjnHjqzDsGamOgICHhGqaoMyM= Received: by 10.43.46.9 with SMTP id um9mr65671icb.178.1317656007280; Mon, 03 Oct 2011 08:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.194 with HTTP; Mon, 3 Oct 2011 08:33:06 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> From: Qiong Date: Mon, 3 Oct 2011 23:33:06 +0800 Message-ID: To: Acee Lindem Content-Type: multipart/alternative; boundary=bcaec52997434008ab04ae66b286 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 15:30:25 -0000 --bcaec52997434008ab04ae66b286 Content-Type: text/plain; charset=UTF-8 Hi, Acee, Agree. I think the HOMENET requirements should be derived from major devices in the home network scenario. Maybe currently we should firstly focus on multiple router scenario for traditional fixed and wireless network for multiple services (especially WiFi) , and then introduce LLN network as well for smart objects in the same environment, together with the homenet architecture and new model in the future. Best wishes Qiong > > I think a viable option for 2012 is that if the LLN networks with their > smart objects have to connect to the traditional HOMENET fixed and wireless > networks, they will need to do so through a border router supporting both > environments. IMHO, we don't need one protocol that meets all requirements > for every possible device in the home. > > Thanks, > Acee > > > > > > >> > >> My first choice would NOT be something that isn't proven in the field in > multiple interoperable implementations. > >> > >> As a person thinking about making a recommendation, I'd suggest that > folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > >> _______________________________________________ > >> 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 > --bcaec52997434008ab04ae66b286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Acee,

Agree.=C2=A0I think the HOMENET requirements s= hould be derived from major devices in the home network scenario. Maybe cur= rently we should firstly focus on multiple router=C2=A0scenario for=C2=A0tr= aditional=C2=A0fixed and wireless network for multiple services (especially= WiFi) , and then introduce LLN network as well for smart objects in the sa= me environment, together with the homenet architecture and new model in the= future.=C2=A0

Best wishes=C2=A0

Qiong=C2=A0
=




I think a viable option for 2012 is that if the LLN networks with the= ir smart objects have to connect to the traditional HOMENET fixed and wirel= ess networks, they will need to do so through a border router supporting bo= th environments. IMHO, we don't need one protocol that meets all requir= ements for every possible device in the home.

Thanks,
Acee



>
>>
>> My first choice would NOT be something that isn't proven in th= e field in multiple interoperable implementations.
>>
>> As a person thinking about making a recommendation, I'd sugges= t that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why that level of interoperability isn't mandatory= .
>> _______________________________________________
>> 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

--bcaec52997434008ab04ae66b286-- From tony.li@tony.li Mon Oct 3 09:13:22 2011 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 329AC21F85BB for ; Mon, 3 Oct 2011 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aVkQhEIhXNp for ; Mon, 3 Oct 2011 09:13:21 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id 843E121F8BEB for ; Mon, 3 Oct 2011 09:13:21 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta05.emeryville.ca.mail.comcast.net with comcast id gDQT1h0011ZMdJ4A5GGJo2; Mon, 03 Oct 2011 16:16:18 +0000 Received: from [10.21.78.187] ([128.107.239.233]) by omta16.emeryville.ca.mail.comcast.net with comcast id gGEU1h01252qHCY8cGEXS8; Mon, 03 Oct 2011 16:14:52 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Mon, 3 Oct 2011 09:15:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Randy Turner X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 09:38:20 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 16:13:22 -0000 The problem with a RIP like protocol is that it will have RIP like = convergence properties. IMHO, that's no longer acceptable. Doing a subset of a LS protocol with a trivial default configuration = should not be unreasonable. Tony On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: >=20 > I would hope that we would NOT be seriously considering OSPF or IS-IS = in the home...this seems like using a sledgehammer to kill an ant. How = many routes are we talking about for a home network? I don't believe = any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. Our customers won't even know what an = IP address is. >=20 > Seems like a "RIP-like" (around the same scope of complexity) would be = enough for a homenet. I'm curious to see what comes out of the LLN = discussion. >=20 > The "filter" for any of these decisions should probably always be a = "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a = problem can't exist in a "zeroconf/admin" environment, then I would = think it would not be the right choice. Also, as a "first cut" = solution, we I think we should be focused on the 80% use-case, not the = fringe. The participants of this working group, and their respective = home networking setups, are probably not our "typical" customer.=20 >=20 > Randy >=20 >=20 > On Oct 3, 2011, at 8:33 AM, Qiong wrote: >=20 >> Hi, Acee, >>=20 >> Agree. I think the HOMENET requirements should be derived from major = devices in the home network scenario. Maybe currently we should firstly = focus on multiple router scenario for traditional fixed and wireless = network for multiple services (especially WiFi) , and then introduce LLN = network as well for smart objects in the same environment, together with = the homenet architecture and new model in the future.=20 >>=20 >> Best wishes=20 >>=20 >> Qiong=20 >>=20 >>=20 >>=20 >>=20 >> I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >> > >> >> >> >> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations. >> >> >> >> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask themselves why that level of interoperability isn't mandatory. >> >> _______________________________________________ >> >> 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 >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From lorenzo@google.com Mon Oct 3 09:35:46 2011 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 5E77921F8BBB for ; Mon, 3 Oct 2011 09:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.926 X-Spam-Level: X-Spam-Status: No, score=-105.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StAgox0cgbWe for ; Mon, 3 Oct 2011 09:35:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 137FA21F8BB0 for ; Mon, 3 Oct 2011 09:35:46 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p93GcgFe005679 for ; Mon, 3 Oct 2011 09:38:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317659923; bh=hgmZYd9uaKbS3jRn9ZKM7N9/1Ro=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Mp/sDGEuJLliSL6NqsFeuUE+yBI3VXjp/GkkPeTnHIwEiaPX5KmsjNJPqyCftWcaD jmcpdB/X/nGmM9xusl1XQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=W0RJ2XHiiA6Eng42zRBoN6PYM2anXL7PwzPltdF9qrD4TmLjuouZo9Y+X4hlIMCCt AI2sHruKHOw/scwPXb35A== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by hpaq5.eem.corp.google.com with ESMTP id p93GceLe018130 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Oct 2011 09:38:41 -0700 Received: by yxl11 with SMTP id 11so4869779yxl.4 for ; Mon, 03 Oct 2011 09:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vpVbhExkA2TIR1vbeIKb4J4VjFrzh1gD8jiY3i+VXJw=; b=QnS6jaqjGBbbsHrAgLaV5VctvJohIlIe15QHTJXPazVVaasePYXX9u4Iq3SCvv3EFs Zdup/jkZLg3sZecVJsmQ== Received: by 10.150.141.21 with SMTP id o21mr333226ybd.57.1317659920482; Mon, 03 Oct 2011 09:38:40 -0700 (PDT) Received: by 10.150.141.21 with SMTP id o21mr333205ybd.57.1317659920190; Mon, 03 Oct 2011 09:38:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 3 Oct 2011 09:38:20 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> From: Lorenzo Colitti Date: Mon, 3 Oct 2011 09:38:20 -0700 Message-ID: To: Qiong Content-Type: multipart/alternative; boundary=000e0cd75f907a4bcc04ae679b14 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 03 Oct 2011 09:39:41 -0700 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 16:35:46 -0000 --000e0cd75f907a4bcc04ae679b14 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 3, 2011 at 08:33, Qiong wrote: > Agree. I think the HOMENET requirements should be derived from major > devices in the home network scenario. Maybe currently we should firstly > focus on multiple router scenario for traditional fixed and wireless network > for multiple services (especially WiFi) > Agreed. While it's nice to think about abstract requirements and go off and pick a protocol that meets all of them, the truth is that if it doesn't get implemented, there's no point in doing so. If any of this is to be exist in the real world, then we need to start from the capabilities of devices that are currently common in home networking environments, because it's in those devices that this technology will be implemented first, if at all. --000e0cd75f907a4bcc04ae679b14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 3, 2011 at 08:33, Qiong <bingxuere@gmail.com>= ; wrote:
Agree.=A0I think the HOMENET requirements should be derived from major= devices in the home network scenario. Maybe currently we should firstly fo= cus on multiple router=A0scenario for=A0traditional=A0fixed and wireless ne= twork for multiple services (especially WiFi)
=A0
Agreed. While it's nice to think about = abstract requirements and go off and pick a protocol that meets all of them= , the truth is that if it doesn't get implemented, there's no point= in doing so. If any of this is to be exist in the real world, then we need= to start from the capabilities of devices that are currently common in hom= e networking environments, because it's in those devices that this tech= nology will be implemented first, if at all.
--000e0cd75f907a4bcc04ae679b14-- From budden@nps.edu Wed Sep 28 10:51:54 2011 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 D61D01F0CAA; Wed, 28 Sep 2011 10:51:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdfu4oML8s2r; Wed, 28 Sep 2011 10:51:54 -0700 (PDT) Received: from diamond.nps.edu (diamond.nps.edu [205.155.65.226]) by ietfa.amsl.com (Postfix) with ESMTP id 162F71F0CA8; Wed, 28 Sep 2011 10:51:54 -0700 (PDT) Received: from virginia.nps.edu ([205.155.65.26]) by diamond.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 10:54:42 -0700 Received: from SKYTRAIN.ern.nps.edu ([172.20.24.112]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 10:54:42 -0700 Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.112) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Sep 2011 10:54:42 -0700 From: Rex Buddenberg To: Mark Townsley In-Reply-To: <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 28 Sep 2011 10:54:23 -0700 Message-ID: <1317232463.2243.406.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2011 17:54:42.0471 (UTC) FILETIME=[B3497B70:01CC7E07] X-Mailman-Approved-At: Mon, 03 Oct 2011 09:40:11 -0700 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , "Fred Baker \(fred\)" , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 28 Sep 2011 17:51:55 -0000 On Wed, 2011-09-28 at 16:58 +0200, Mark Townsley wrote: > > >> The majority of IP-based home networks today are neither > power-constrained nor particularly lossy. I would agree that that is the case today, but suggest we look ahead a bit. There's a fair head of steam building in emergency services that has the term 'broadband' attached to it. Lots of confusion, but... We're about to see a repeat of what we saw in the CATV market where the vendors thought you'd connect a computer at home to the DOCSIS network. But we all hooked up routers instead. This time the story is the cellphone folks rolling out '4G' network segments and naively thinking that we'll just hook up cellphones (which have since become computers -- mine has 8G of RAM in it!). Scenario for orientation. Instead of the EMT in the ambulance having a cellphone to call the emergency room, the EMT will be armed with several diagnostic gadgets attached to a LAN (either ethernet or WiFi). And a router. The router will, in turn be linked to the rest of internet with a radio-WAN. Scenario implications. Right now, emergency services tend to rely on a set of high sites -- Monterey County where I live, has eleven. But the broadband technologies all look better with an order of magnitude more sites (think schoolhouse roofs) and consequently more handoffs (aka routing table volatility). Topology. The radio-WAN is in interior of internet, not fringe. Power-constrained -- probably not much change since a lot of this will be vehicle-mount -- ambulances, fire engines, etc. This all changes as soon as the trooper dismounts and exceeds WiFi range from his vehicle. Lossy. Depends on how you define the term... But radios lose more bits (and hence more packets) than wires. From rturner@amalfisystems.com Mon Oct 3 08:55:39 2011 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 4E43F21F8BDC; Mon, 3 Oct 2011 08:55:39 -0700 (PDT) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7G2kXP5S88N; Mon, 3 Oct 2011 08:55:38 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8A521F8B70; Mon, 3 Oct 2011 08:55:38 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p93FwdUJ011335; Mon, 3 Oct 2011 11:58:39 -0400 X-Authenticated-IP: 98.151.18.158 Received: from [98.151.18.158] ([98.151.18.158:62741] helo=[192.168.1.105]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 85/D8-03335-DABD98E4; Mon, 03 Oct 2011 11:58:39 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-47901164 From: Randy Turner In-Reply-To: Date: Mon, 3 Oct 2011 08:58:37 -0700 Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Qiong X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 09:40:11 -0700 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 15:55:39 -0000 --Apple-Mail-1-47901164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would hope that we would NOT be seriously considering OSPF or IS-IS in = the home...this seems like using a sledgehammer to kill an ant. How = many routes are we talking about for a home network? I don't believe = any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. Our customers won't even know what an = IP address is. Seems like a "RIP-like" (around the same scope of complexity) would be = enough for a homenet. I'm curious to see what comes out of the LLN = discussion. The "filter" for any of these decisions should probably always be a = "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a = problem can't exist in a "zeroconf/admin" environment, then I would = think it would not be the right choice. Also, as a "first cut" = solution, we I think we should be focused on the 80% use-case, not the = fringe. The participants of this working group, and their respective = home networking setups, are probably not our "typical" customer.=20 Randy On Oct 3, 2011, at 8:33 AM, Qiong wrote: > Hi, Acee, >=20 > Agree. I think the HOMENET requirements should be derived from major = devices in the home network scenario. Maybe currently we should firstly = focus on multiple router scenario for traditional fixed and wireless = network for multiple services (especially WiFi) , and then introduce LLN = network as well for smart objects in the same environment, together with = the homenet architecture and new model in the future.=20 >=20 > Best wishes=20 >=20 > Qiong=20 >=20 >=20 >=20 >=20 > I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home. >=20 > Thanks, > Acee >=20 >=20 >=20 > > > >> > >> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations. > >> > >> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask themselves why that level of interoperability isn't mandatory. > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-1-47901164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Seems like a = "RIP-like" (around the same scope of complexity) would be enough for a = homenet.  I'm curious to see what comes out of the LLN = discussion.

The "filter" for any of these = decisions should probably always be a "zeroconf" or "zeroadmin" scenario = -- if a proposed approach to a problem can't exist in a "zeroconf/admin" = environment, then I would think it would not be the right choice. =  Also, as a "first cut" solution, we I think we should be focused = on the 80% use-case, not the fringe.  The participants of this = working group, and their respective home networking setups, are probably = not our "typical" = customer. 

Randy

On Oct 3, 2011, at 8:33 AM, Qiong wrote:

Hi, = Acee,

Agree. I think the HOMENET requirements = should be derived from major devices in the home network scenario. Maybe = currently we should firstly focus on multiple router scenario = for traditional fixed and wireless network for multiple = services (especially WiFi) , and then introduce LLN network as well for = smart objects in the same environment, together with the homenet = architecture and new model in the future. 

Best = wishes 

Qiong 




I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home.

Thanks,
Acee



>
>>
>> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations.
>>
>> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 = and ask themselves why that level of interoperability isn't = mandatory.
>> _______________________________________________
>> 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

= --Apple-Mail-1-47901164-- From lorenzo@google.com Mon Oct 3 09:47:49 2011 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 0145421F8C5A for ; Mon, 3 Oct 2011 09:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.855 X-Spam-Level: X-Spam-Status: No, score=-105.855 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEc4U2gPDzSb for ; Mon, 3 Oct 2011 09:47:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 572F221F8C59 for ; Mon, 3 Oct 2011 09:47:48 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p93Gooac028871 for ; Mon, 3 Oct 2011 09:50:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317660651; bh=H9csBGolB77SmudUcR8LDxa6e3A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=J3otYeM5RVinsm2WEzoYSfXiXX177LFGhGK5OiOYhqsAb9H4Aq6rdafRf4SRLzUgg ipxOrebUXuovz0PHHjGYw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=mcy+MZLlQIEnBuk5NdA17TOnOBATr6EkWZPRVb13b5iRMZ2jeVTAPYqDhS7Oij0V8 XSa2v0BhhjjevzeuNB/4w== Received: from ywp31 (ywp31.prod.google.com [10.192.16.31]) by hpaq5.eem.corp.google.com with ESMTP id p93GoLrV004508 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 3 Oct 2011 09:50:49 -0700 Received: by ywp31 with SMTP id 31so8927227ywp.25 for ; Mon, 03 Oct 2011 09:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W6nPTfiW7Sr3M9Z37R+fr5qeilxW67EGeiOX8HSCLac=; b=b9fPYPHjRk3g4bZkp5qsZdVAXp+p4Z8McVS/MvnOp4MJRzIp75HeYkatNlJIyUoYOO Y5FMIPrLV/0ef/9O1vBg== Received: by 10.150.137.5 with SMTP id k5mr341932ybd.114.1317660648356; Mon, 03 Oct 2011 09:50:48 -0700 (PDT) Received: by 10.150.137.5 with SMTP id k5mr341907ybd.114.1317660648143; Mon, 03 Oct 2011 09:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 3 Oct 2011 09:50:27 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> From: Lorenzo Colitti Date: Mon, 3 Oct 2011 09:50:27 -0700 Message-ID: To: Randy Turner Content-Type: multipart/alternative; boundary=000e0cd3107addfacb04ae67c6c8 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 03 Oct 2011 09:49:02 -0700 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 16:47:49 -0000 --000e0cd3107addfacb04ae67c6c8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 3, 2011 at 08:58, Randy Turner wrote: > I would hope that we would NOT be seriously considering OSPF or IS-IS in > the home...this seems like using a sledgehammer to kill an ant. > If the devices we're talking about have enough resources to run them, and they have desirable properties that are useful in home networks, then what's the problem with either of these? Home gateways these days are capable of 1Gbps hardware forwarding and have pretty fast CPUs. For example, if there were a robust open-source version of IS-IS that didn't take up too much RAM and flash, you could define TLVs to implement zeroconf and you could get to something that works relatively quickly. --000e0cd3107addfacb04ae67c6c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 3, 2011 at 08:58, Randy Turner <rturner@amalf= isystems.com> wrote:
I would hope that we would NOT be = seriously considering OSPF or IS-IS in the home...this seems like using a s= ledgehammer to kill an ant.

If the devices we're talking about have enough resources to run them, a= nd they have desirable properties that are useful in home networks, then wh= at's the problem with either of these?=A0Home gateways these days are c= apable of 1Gbps hardware forwarding and have pretty fast CPUs.

For example, if there were a robust open-source version= of IS-IS that didn't take up too much RAM and flash, you could define = TLVs to implement zeroconf and you could get to something that works relati= vely quickly.
--000e0cd3107addfacb04ae67c6c8-- From dijeygui@msn.com Mon Oct 3 09:58:24 2011 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 3422521F8C32 for ; Mon, 3 Oct 2011 09:58:24 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK2RARfCn7iw for ; Mon, 3 Oct 2011 09:58:23 -0700 (PDT) Received: from dub0-omc2-s21.dub0.hotmail.com (dub0-omc2-s21.dub0.hotmail.com [157.55.1.160]) by ietfa.amsl.com (Postfix) with ESMTP id 7231C21F8C1C for ; Mon, 3 Oct 2011 09:58:23 -0700 (PDT) Received: from DUB110-W55 ([157.55.1.136]) by dub0-omc2-s21.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 10:01:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_4ef13f81-aab5-4d63-9783-edc5bb19b783_" X-Originating-IP: [82.130.22.50] From: Diego G To: Date: Mon, 3 Oct 2011 17:01:21 +0000 Importance: Normal In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com>, , , , <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net>, <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com>, <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 03 Oct 2011 17:01:21.0705 (UTC) FILETIME=[138C1990:01CC81EE] Subject: [homenet] CANCEL 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, 03 Oct 2011 16:58:24 -0000 --_4ef13f81-aab5-4d63-9783-edc5bb19b783_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I want to cancel my subscription to this mailing list. = --_4ef13f81-aab5-4d63-9783-edc5bb19b783_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I want to cancel my subscription to this mailing list.
= --_4ef13f81-aab5-4d63-9783-edc5bb19b783_-- From marshall.eubanks@gmail.com Mon Oct 3 10:08:37 2011 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 77AD221F8C74 for ; Mon, 3 Oct 2011 10:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.255 X-Spam-Level: X-Spam-Status: No, score=-103.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8MnJ679I5Pk for ; Mon, 3 Oct 2011 10:08:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67B0121F8C6E for ; Mon, 3 Oct 2011 10:08:36 -0700 (PDT) Received: by yxt33 with SMTP id 33so4658559yxt.31 for ; Mon, 03 Oct 2011 10:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kdBnHBJ8/Pegvps2CqObh2KMFUVGB/2vUXudqvTYNhw=; b=dpE6TDUESWz6G747azruZvHVMYp4VM8P8lo/69vaJi5A2lwod2ytxgxnWSMFV303vh +n5tHBdNwPPciC+OUhLDxDxdNVdIPgqfp93ddkrNEFbHDfkzRNdR8Hh7lKkZ8FgEkIcC aSKIkvnKBicT4iE5WoK+87CuP+aLMryLWBr9M= MIME-Version: 1.0 Received: by 10.150.143.2 with SMTP id q2mr338765ybd.368.1317661899033; Mon, 03 Oct 2011 10:11:39 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Mon, 3 Oct 2011 10:11:38 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> Date: Mon, 3 Oct 2011 13:11:38 -0400 Message-ID: From: Marshall Eubanks To: Diego G Content-Type: text/plain; charset=ISO-8859-1 Cc: homenet@ietf.org Subject: Re: [homenet] CANCEL 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, 03 Oct 2011 17:08:37 -0000 You do that by... On Mon, Oct 3, 2011 at 1:01 PM, Diego G wrote: > I want to cancel my subscription to this mailing list. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ^--- following the instructions there. Regards Marshall Eubanks > > From robert.cragie@gmail.com Mon Oct 3 10:21:05 2011 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 2FCD721F8C87; Mon, 3 Oct 2011 10:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xctrKU1n5w+Q; Mon, 3 Oct 2011 10:21:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86F9521F8C89; Mon, 3 Oct 2011 10:21:03 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4627204vcb.31 for ; Mon, 03 Oct 2011 10:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r+zpYmZwiEmmmjUR3mLNzqqrNUapL2RYtWyW/RfV2Xk=; b=IPDPH7uF3iDcizx9S1PfKuyOFrSvj21cwAoum0MSLDE2F88yPih1P/zNXWd9Fx91lM KNF1F/7MRIuYtl5Oi4oXWgiZ8HNnfd9bhsboxZVwxM08rNFq/D3ldsCCflgWA97q/qt0 Ei3bDd6SsWv7Vpr2qZnBN/ChJTmOOz53+8wZ8= MIME-Version: 1.0 Received: by 10.52.89.107 with SMTP id bn11mr200215vdb.146.1317662646110; Mon, 03 Oct 2011 10:24:06 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.179.10 with HTTP; Mon, 3 Oct 2011 10:24:06 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> Date: Mon, 3 Oct 2011 18:24:06 +0100 X-Google-Sender-Auth: dcCDAGeSBE8YFLyKck1EMnF_3kc Message-ID: From: Robert Cragie To: Acee Lindem Content-Type: multipart/alternative; boundary=20cf307d033ef48a8004ae683d6d Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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: Mon, 03 Oct 2011 17:21:06 -0000 --20cf307d033ef48a8004ae683d6d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 Robert On Mon, Oct 3, 2011 at 3:24 PM, Acee Lindem wrote= : > Hey JP, > > On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote: > > > > > On Sep 28, 2011, at 5:43 PM, Fred Baker wrote: > > > >> > >> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: > >> > >>> Since you asked, *I* think that a homenet has functional overlap (wha= t > I called "at least a smaller and slightly different subset" in my email) = in > terms of requirements to LLNs. At first blush, it looks like RPL has lots= of > functionality - perhaps more than we really need for homenet, and by your > own admission more than you need for LLN's - but will hold reservation on > what I think best fits the bill until we see Fred's analysis, hear from > others, etc. > >> > >> My two yen, which may be all it's worth... > >> > >> If I were a Linksys/D-Link/NetGear/* product manager asking about what > protocols to put in, I wouldn't be asking about what still exists in > Internet Drafts and is thought by the engineers designing it to be better > than sliced bread, but about what was inexpensive to implement, likely to= be > close to bug-free, and definitively accomplished the goal. I note that mo= st > routers for the IPv4 residential routing marketplace implement RIPv2; I k= now > of one that implements no routing protocol, one that implements RIPv2 and > RIPv1 (!), and one that implements RIPv2 and OSPF (don't ask which they a= re, > I don't remember). This is from a google search of residential routers a = few > months ago and covered perhaps 20 products from half as many vendors. So = my > first inclination is to say that for a residential IPv6 network, RIPng is > probably an image match for those vendors. > >> > >> I have a personal bias in the direction of OSPF or IS-IS; I think that > once the code is debugged, SPF-based protocols are more stable (no > count-to-infinity), given a reasonable set of defaults generate far more > stable networks, and definitively know when there is more than one router= on > a LAN, which can be important in subnet distribution. > > > > I spent enough years on OSPF and ISIS to agree with you that these > protocols are well proven, widely deployed with the number of > > recent improvements (MTR, fast convergence, =85) to name a few are > particularly appealing. But before choosing a routing protocol > > the first step consists of listing the requirements. In LLN, as you > rightly pointed out, "smart objects" have a set of constraints in terms > > of resources =85 far from where we are on traditional routers =85 Thus = I > would strongly encourage to list the set of requirements for this > > type of devices before making any sort of selection on the routing > protocol of choice, taking into account where we will be in a few years > > when the number of these objects will not be limited to a few dozens, t= he > LSDB *will* grow =85 > > I think a viable option for 2012 is that if the LLN networks with their > smart objects have to connect to the traditional HOMENET fixed and wirele= ss > networks, they will need to do so through a border router supporting both > environments. IMHO, we don't need one protocol that meets all requirement= s > for every possible device in the home. > > Thanks, > Acee > > > > > > >> > >> My first choice would NOT be something that isn't proven in the field = in > multiple interoperable implementations. > >> > >> As a person thinking about making a recommendation, I'd suggest that > folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > >> _______________________________________________ > >> 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 > --=20 Robert Cragie Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com --20cf307d033ef48a8004ae683d6d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1

Robert

On Mon, Oct = 3, 2011 at 3:24 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:
Hey JP,

On Oct 3, 2011, at 10:01 AM, JP Vasseur wrote:

>
> On Sep 28, 2011, at 5:43 PM, Fred Baker wrote:
>
>>
>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote:
>>
>>> Since you asked, *I* think that a homenet has functional overl= ap (what I called "at least a smaller and slightly different subset&qu= ot; in my email) in terms of requirements to LLNs. At first blush, it looks= like RPL has lots of functionality - perhaps more than we really need for = homenet, and by your own admission more than you need for LLN's - but w= ill hold reservation on what I think best fits the bill until we see Fred&#= 39;s analysis, hear from others, etc.
>>
>> My two yen, which may be all it's worth...
>>
>> If I were a Linksys/D-Link/NetGear/* product manager asking about = what protocols to put in, I wouldn't be asking about what still exists = in Internet Drafts and is thought by the engineers designing it to be bette= r than sliced bread, but about what was inexpensive to implement, likely to= be close to bug-free, and definitively accomplished the goal. I note that = most routers for the IPv4 residential routing marketplace implement RIPv2; = I know of one that implements no routing protocol, one that implements RIPv= 2 and RIPv1 (!), and one that implements RIPv2 and OSPF (don't ask whic= h they are, I don't remember). This is from a google search of resident= ial routers a few months ago and covered perhaps 20 products from half as m= any vendors. So my first inclination is to say that for a residential IPv6 = network, RIPng is probably an image match for those vendors.
>>
>> I have a personal bias in the direction of OSPF or IS-IS; I think = that once the code is debugged, SPF-based protocols are more stable (no cou= nt-to-infinity), given a reasonable set of defaults generate far more stabl= e networks, and definitively know when there is more than one router on a L= AN, which can be important in subnet distribution.
>
> I spent enough years on OSPF and ISIS to agree with you that these pro= tocols are well proven, widely deployed with the number of
> recent improvements (MTR, fast convergence, =85) to name a few are par= ticularly appealing. But before choosing a routing protocol
> the first step consists of listing the requirements. In LLN, as you ri= ghtly pointed out, "smart objects" have a set of constraints in t= erms
> of resources =85 far from where we are on traditional routers =85 Thus= I would strongly encourage to list the set of requirements for this
> type of devices before making any sort of selection on the routing pro= tocol of choice, taking into account where we will be in a few years
> when the number of these objects will not be limited to a few dozens, = the LSDB *will* grow =85

I think a viable option for 2012 is that if the LLN networks with the= ir smart objects have to connect to the traditional HOMENET fixed and wirel= ess networks, they will need to do so through a border router supporting bo= th environments. IMHO, we don't need one protocol that meets all requir= ements for every possible device in the home.

Thanks,
Acee



>
>>
>> My first choice would NOT be something that isn't proven in th= e field in multiple interoperable implementations.
>>
>> As a person thinking about making a recommendation, I'd sugges= t that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why that level of interoperability isn't mandatory= .
>> _______________________________________________
>> 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



--
=

= Robert Cragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 http://www.gridmerge.com


--20cf307d033ef48a8004ae683d6d-- From v6ops@globis.net Mon Oct 3 10:42:10 2011 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 D03FF21F8AF9 for ; Mon, 3 Oct 2011 10:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9vcvBKztbzy for ; Mon, 3 Oct 2011 10:42:10 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD6321F8B2D for ; Mon, 3 Oct 2011 10:42:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E37CA8700F3; Mon, 3 Oct 2011 19:45:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbWo+FYFh8MV; Mon, 3 Oct 2011 19:44:57 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 208F48700EF; Mon, 3 Oct 2011 19:44:57 +0200 (CEST) Message-ID: <4E89F498.7090400@globis.net> Date: Mon, 03 Oct 2011 19:44:56 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Randy Turner Content-Type: multipart/alternative; boundary="------------030701060809060506010600" Cc: homenet@ietf.org Subject: Re: [homenet] Question for you 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, 03 Oct 2011 17:42:10 -0000 This is a multi-part message in MIME format. --------------030701060809060506010600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Agree with the base requirements list: non-expert admin, non-expert config, supports mesh networking of widely ranging link types, IPv4 and IPv6 capable (optional: expandable for disseminating other configuration information), existing protocol, multiple implementations, inter-op demonstrated in production, runs on today's devices. Disagree with jumping immediately to the conclusion that OSPF is unsuitable to fulfill these requirements. I've see plenty of super-simple OSPF networks which consist of 4 devices communicating over an organizational boundary. It's just a question of standardizing configuration and limiting options to bare-bones e.g. default is that everything runs in area 0 => max of ±25 routers in the home = no big deal IMHO. It also leaves the future open if there are people out there who do want to expand further e.g. common building networks covering multiple residents. Not that I'm pushing OSPF, but let's not prejudice the outcome before we even start. best regards, RayH > Subject: > Re: [homenet] Question for you > From: > Randy Turner > Date: > Mon, 3 Oct 2011 08:58:37 -0700 > > To: > Qiong > CC: > "Pascal Thubert \(pthubert\)" , C Chauvenet > , MANET IETF , Mark Townsley > , JP Vasseur , Acee Lindem > , Fred Baker , > "homenet@ietf.org" , "rtgwg@ietf.org" > > Precedence: > list > MIME-Version: > 1.0 (Apple Message framework v1084) > References: > <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> > > > > <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> > <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> > <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> > > > In-Reply-To: > > Message-ID: > > Content-Type: > multipart/alternative; boundary=Apple-Mail-1-47901164 > Message: > 3 > > > > I would hope that we would NOT be seriously considering OSPF or IS-IS > in the home...this seems like using a sledgehammer to kill an ant. > How many routes are we talking about for a home network? I don't > believe any enterprise routing protocol was designed for a "zeroconf" > or "zeroadmin" type of environment. Our customers won't even know > what an IP address is. > > Seems like a "RIP-like" (around the same scope of complexity) would be > enough for a homenet. I'm curious to see what comes out of the LLN > discussion. > > The "filter" for any of these decisions should probably always be a > "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a > problem can't exist in a "zeroconf/admin" environment, then I would > think it would not be the right choice. Also, as a "first cut" > solution, we I think we should be focused on the 80% use-case, not the > fringe. The participants of this working group, and their respective > home networking setups, are probably not our "typical" customer. > > Randy > > --------------030701060809060506010600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agree with the base requirements list: non-expert admin, non-expert config, supports mesh networking of widely ranging link types, IPv4 and IPv6 capable (optional: expandable for disseminating other configuration information), existing protocol, multiple implementations, inter-op demonstrated in production, runs on today's devices.

Disagree with jumping immediately to the conclusion that OSPF is unsuitable to fulfill these requirements.

I've see plenty of super-simple OSPF networks which consist of 4 devices communicating over an organizational boundary.

It's just a question of standardizing configuration and limiting options to bare-bones e.g. default is that everything runs in area 0 => max of ±25 routers in the home = no big deal IMHO. It also leaves the future open if there are people out there who do want to expand further e.g. common building networks covering multiple residents.

Not that I'm pushing OSPF, but let's not prejudice the outcome before we even start.

best regards,
RayH

Subject:
Re: [homenet] Question for you
From:
Randy Turner <rturner@amalfisystems.com>
Date:
Mon, 3 Oct 2011 08:58:37 -0700
To:
Qiong <bingxuere@gmail.com>
CC:
"Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, C Chauvenet <c.chauvenet@watteco.com>, MANET IETF <manet@ietf.org>, Mark Townsley <mark@townsley.net>, JP Vasseur <jpv@cisco.com>, Acee Lindem <acee.lindem@ericsson.com>, Fred Baker <fred@cisco.com>, "homenet@ietf.org" <homenet@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <E62242EF-DF1C-42D6-AD06-DC1761383E44@watteco.com> <C16130C1-0C50-4FF9-A750-3864D21E41B6@townsley.net> <BDF2740C082F6942820D95BAEB9E1A840DBF1E@XMB-AMS-108.cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <B002C70D-626C-4BD4-91DF-ACE988CEF997@ericsson.com> <CAH3bfADXEMAFSKCZjsTkNyz-6ARrWgq9CCQS+ad4zXaVZ4aEYA@mail.gmail.com>
In-Reply-To:
<CAH3bfADXEMAFSKCZjsTkNyz-6ARrWgq9CCQS+ad4zXaVZ4aEYA@mail.gmail.com>
Message-ID:
<B579FAF0-B99D-4193-B694-BB7C3DB5DF2A@amalfisystems.com>
Content-Type:
multipart/alternative; boundary=Apple-Mail-1-47901164
Message:
3


I would hope that we would NOT be seriously considering OSPF or IS-IS in the home...this seems like using a sledgehammer to kill an ant.  How many routes are we talking about for a home network?  I don't believe any enterprise routing protocol was designed for a "zeroconf" or "zeroadmin" type of environment.  Our customers won't even know what an IP address is.

Seems like a "RIP-like" (around the same scope of complexity) would be enough for a homenet.  I'm curious to see what comes out of the LLN discussion.

The "filter" for any of these decisions should probably always be a "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a problem can't exist in a "zeroconf/admin" environment, then I would think it would not be the right choice.  Also, as a "first cut" solution, we I think we should be focused on the 80% use-case, not the fringe.  The participants of this working group, and their respective home networking setups, are probably not our "typical" customer. 

Randy


--------------030701060809060506010600-- From rturner@amalfisystems.com Mon Oct 3 10:56:25 2011 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 52BCD21F8CE2 for ; Mon, 3 Oct 2011 10:56:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+4ggtgFj-TB for ; Mon, 3 Oct 2011 10:56:24 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7221F8CDC for ; Mon, 3 Oct 2011 10:56:24 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p93HxMYa005622 for ; Mon, 3 Oct 2011 13:59:24 -0400 X-Authenticated-IP: 98.151.18.158 Received: from [98.151.18.158] ([98.151.18.158:65099] helo=[192.168.1.105]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 2A/CC-28170-9F7F98E4; Mon, 03 Oct 2011 13:59:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Randy Turner In-Reply-To: <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> Date: Mon, 3 Oct 2011 10:59:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <26DF30D2-2D20-4992-9FD6-08FA27AF18F2@amalfisystems.com> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> To: homenet@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [homenet] Question for you 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, 03 Oct 2011 17:56:25 -0000 I agree that RIP does have issues, but in a constrained-number-of-routes = scenario (like home networking), it may be "good enough" That being said, a "subset" implementation of an LS solution that takes = into account zeroconf/zeroadmin requirements would certainly be better = than anything RIP-like. Maybe this "subset" profile of an LS protocol with zeroconf/zeroadmin = requirements should be our focus? I would still like to hear the = outcome of any discussions regarding self-organizing routes, which would seem to benefit the = zeroconf/zeroadmin goal... Randy On Oct 3, 2011, at 9:15 AM, Tony Li wrote: >=20 > The problem with a RIP like protocol is that it will have RIP like = convergence properties. IMHO, that's no longer acceptable. >=20 > Doing a subset of a LS protocol with a trivial default configuration = should not be unreasonable. >=20 > Tony >=20 >=20 > On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: >=20 >>=20 >> I would hope that we would NOT be seriously considering OSPF or IS-IS = in the home...this seems like using a sledgehammer to kill an ant. How = many routes are we talking about for a home network? I don't believe = any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. Our customers won't even know what an = IP address is. >>=20 >> Seems like a "RIP-like" (around the same scope of complexity) would = be enough for a homenet. I'm curious to see what comes out of the LLN = discussion. >>=20 >> The "filter" for any of these decisions should probably always be a = "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a = problem can't exist in a "zeroconf/admin" environment, then I would = think it would not be the right choice. Also, as a "first cut" = solution, we I think we should be focused on the 80% use-case, not the = fringe. The participants of this working group, and their respective = home networking setups, are probably not our "typical" customer.=20 >>=20 >> Randy >>=20 >>=20 >> On Oct 3, 2011, at 8:33 AM, Qiong wrote: >>=20 >>> Hi, Acee, >>>=20 >>> Agree. I think the HOMENET requirements should be derived from major = devices in the home network scenario. Maybe currently we should firstly = focus on multiple router scenario for traditional fixed and wireless = network for multiple services (especially WiFi) , and then introduce LLN = network as well for smart objects in the same environment, together with = the homenet architecture and new model in the future.=20 >>>=20 >>> Best wishes=20 >>>=20 >>> Qiong=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home. >>>=20 >>> Thanks, >>> Acee >>>=20 >>>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations. >>>>>=20 >>>>> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask themselves why that level of interoperability isn't mandatory. >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From robert@raszuk.net Mon Oct 3 13:19:58 2011 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 912D421F8D89 for ; Mon, 3 Oct 2011 13:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tKPoWA2VkJc for ; Mon, 3 Oct 2011 13:19:58 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 4DCAF21F8D4C for ; Mon, 3 Oct 2011 13:19:51 -0700 (PDT) Received: (qmail 3959 invoked by uid 399); 3 Oct 2011 20:22:51 -0000 Received: from unknown (HELO ?192.168.1.57?) (178.42.87.122) by mail37.opentransfer.com with SMTP; 3 Oct 2011 20:22:51 -0000 Message-ID: <4E8A199B.1070607@raszuk.net> Date: Mon, 03 Oct 2011 22:22:51 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ulrich Herberg References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> <4E8A10D2.1030105@freedesktop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , Jim Gettys Subject: [homenet] Wired vs wireless ... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 20:19:58 -0000 Hi Ulrich, Can you also say the opposite that rotocols developed for wireless work equally well also for wired environments ? If so let me ask why do we need both classes of routing protocols ? If not I am not sure homenet should focus on wireless router to router communication at all. Yes I am in favor of wired env with fiber or with nice cat 7 wiring between my routers. Cheers, R. > I agree with Jim. The reason why we developed OLSR and the its > successor OLSRv2 was precisely that wireless environments are very > different from wired. There are plenty of deployments of OLSR and > several of OLSRv2, with up to several hundreds of wireless routers, so > it is demonstrably working. > > Regards > Ulrich From russw@riw.us Mon Oct 3 13:42:28 2011 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 D4CC021F8D3B for ; Mon, 3 Oct 2011 13:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C23Dc7M-q0UD for ; Mon, 3 Oct 2011 13:42:28 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 40CB821F8D15 for ; Mon, 3 Oct 2011 13:42:28 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:63161 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RApOE-00050J-2t for homenet@ietf.org; Mon, 03 Oct 2011 16:45:30 -0400 Message-ID: <4E8A1EE5.80509@riw.us> Date: Mon, 03 Oct 2011 16:45:25 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> <4E8A10D2.1030105@freedesktop.org> <4E8A199B.1070607@raszuk.net> In-Reply-To: <4E8A199B.1070607@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Wired vs wireless ... 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, 03 Oct 2011 20:42:29 -0000 > Can you also say the opposite that rotocols developed for wireless work > equally well also for wired environments ? If so let me ask why do we > need both classes of routing protocols ? I would argue that the OSPF MANET extensions would work just as well for IS-IS or OSPF in both wirelss and wired networks. > If not I am not sure homenet should focus on wireless router to router > communication at all. Yes I am in favor of wired env with fiber or with > nice cat 7 wiring between my routers. I am as well, but I think we should allow for both with a single protocol as much as possible. I think OSPF or IS-IS (or even EIGRP) can be adapted to the low power/lossy network situation, it just takes some thought and care. Russ From ulrich@herberg.name Mon Oct 3 13:50:40 2011 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 B751721F8E7C for ; Mon, 3 Oct 2011 13:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpeKm2GGOQiX for ; Mon, 3 Oct 2011 13:50:40 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id A88A321F8E74 for ; Mon, 3 Oct 2011 13:50:39 -0700 (PDT) Received: by wwn22 with SMTP id 22so3965364wwn.1 for ; Mon, 03 Oct 2011 13:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m8K7We81Sa7vUluBiTYV/EcB9ZhQnhUFu63g4KfL1ww=; b=jUtjoPeTXFqhxqLjWKXdE/UaPldUKyWVnBaWxC0bIdLYUS95UQhTviY2RpZoK+WdgP ZbhLRJ4dTRdoboKPeSefS4kp0CzdaWS41le9ul0/OQ4sPbZm72yPPDm9gTNGK9OEdKaE 9NoXtS+cgm9PcbEoCQMErPPA9nxcRdhwDhSaI= MIME-Version: 1.0 Received: by 10.227.204.14 with SMTP id fk14mr430227wbb.88.1317675222113; Mon, 03 Oct 2011 13:53:42 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 13:53:42 -0700 (PDT) In-Reply-To: <4E8A1EE5.80509@riw.us> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> <4E8A10D2.1030105@freedesktop.org> <4E8A199B.1070607@raszuk.net> <4E8A1EE5.80509@riw.us> Date: Mon, 3 Oct 2011 13:53:42 -0700 Message-ID: From: Ulrich Herberg To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: homenet@ietf.org Subject: Re: [homenet] Wired vs wireless ... 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, 03 Oct 2011 20:50:40 -0000 Hi, On Mon, Oct 3, 2011 at 1:45 PM, Russ White wrote: > >> Can you also say the opposite that rotocols developed for wireless work >> equally well also for wired environments ? If so let me ask why do we >> need both classes of routing protocols ? I have deployed OLSRv2 both on Ethernet and on wireless environments, without problems. I do not see a reason why OLSRv2 could not run in mixed environments. > I would argue that the OSPF MANET extensions would work just as well for > IS-IS or OSPF in both wirelss and wired networks. The OSPF MANET extensions would certainly be a valid alternative to consider. Which one performs better or is more suited (OLSRv2 / OSPF+MANET / ...) -- I don't know, that would be an interesting comparison. > >> If not I am not sure homenet should focus on wireless router to router >> communication at all. Yes I am in favor of wired env with fiber or with >> nice cat 7 wiring between my routers. > > I am as well, but I think we should allow for both with a single > protocol as much as possible. I agree. Not everyone likes long cables in a home environment. And having a single protocol would be indeed better. > I think OSPF or IS-IS (or even EIGRP) can > be adapted to the low power/lossy network situation, it just takes some > thought and care. We have invested that thought and care in MANET for years now. I think it could be worth investing the suitability of the protocols developed in MANET (as well as the OSPF MANET extensions), before reinventing the wheel. Ulrich > > Russ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From ulrich@herberg.name Mon Oct 3 11:19:30 2011 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 B349D21F8CF8; Mon, 3 Oct 2011 11:19:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPQo6f+VZz-U; Mon, 3 Oct 2011 11:19:29 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A439B21F8CF7; Mon, 3 Oct 2011 11:19:28 -0700 (PDT) Received: by wwf22 with SMTP id 22so4294283wwf.13 for ; Mon, 03 Oct 2011 11:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7NF6mEhyAWQdSYTjeb6T2ijt1G1bTbSxrQYK89uy3j4=; b=o6R9IyhFptxpO4ivemN9n/JnBYd1FB1dn+PijgvenHjbh1ouUYSdKZwqSwcfXYInrS gUrhtjQXsjDzjLa/xH4UiPXmYq3HTYz2Uiuw785TNGsrQM6E66/ZQeHxz0Ag8M1yuLcI FAj81UlEE8WuWt82PnHnP/lhEomCot6u00iMo= MIME-Version: 1.0 Received: by 10.227.30.154 with SMTP id u26mr265578wbc.73.1317666150824; Mon, 03 Oct 2011 11:22:30 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 11:22:30 -0700 (PDT) In-Reply-To: <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> Date: Mon, 3 Oct 2011 11:22:30 -0700 Message-ID: From: Ulrich Herberg To: Tony Li Content-Type: multipart/alternative; boundary=002215974902da3d1004ae690e61 X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 03 Oct 2011 18:19:30 -0000 --002215974902da3d1004ae690e61 Content-Type: text/plain; charset=ISO-8859-1 Hi Tony, I agree. I would like to mention that we are specifying an extensible, flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we are not far from submitting it to the IESG. OLSRv2 could well operate on home devices with limited resources, and does not have the issues of RIP. Regards Ulrich On Mon, Oct 3, 2011 at 9:15 AM, Tony Li wrote: > > The problem with a RIP like protocol is that it will have RIP like > convergence properties. IMHO, that's no longer acceptable. > > Doing a subset of a LS protocol with a trivial default configuration should > not be unreasonable. > > Tony > > > On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: > > > > > I would hope that we would NOT be seriously considering OSPF or IS-IS in > the home...this seems like using a sledgehammer to kill an ant. How many > routes are we talking about for a home network? I don't believe any > enterprise routing protocol was designed for a "zeroconf" or "zeroadmin" > type of environment. Our customers won't even know what an IP address is. > > > > Seems like a "RIP-like" (around the same scope of complexity) would be > enough for a homenet. I'm curious to see what comes out of the LLN > discussion. > > > > The "filter" for any of these decisions should probably always be a > "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a problem > can't exist in a "zeroconf/admin" environment, then I would think it would > not be the right choice. Also, as a "first cut" solution, we I think we > should be focused on the 80% use-case, not the fringe. The participants of > this working group, and their respective home networking setups, are > probably not our "typical" customer. > > > > Randy > > > > > > On Oct 3, 2011, at 8:33 AM, Qiong wrote: > > > >> Hi, Acee, > >> > >> Agree. I think the HOMENET requirements should be derived from major > devices in the home network scenario. Maybe currently we should firstly > focus on multiple router scenario for traditional fixed and wireless network > for multiple services (especially WiFi) , and then introduce LLN network as > well for smart objects in the same environment, together with the homenet > architecture and new model in the future. > >> > >> Best wishes > >> > >> Qiong > >> > >> > >> > >> > >> I think a viable option for 2012 is that if the LLN networks with their > smart objects have to connect to the traditional HOMENET fixed and wireless > networks, they will need to do so through a border router supporting both > environments. IMHO, we don't need one protocol that meets all requirements > for every possible device in the home. > >> > >> Thanks, > >> Acee > >> > >> > >> > >> > > >> >> > >> >> My first choice would NOT be something that isn't proven in the field > in multiple interoperable implementations. > >> >> > >> >> As a person thinking about making a recommendation, I'd suggest that > folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > >> >> _______________________________________________ > >> >> 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 > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --002215974902da3d1004ae690e61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tony,

I agree. I would like to mention that we are specifying an = extensible, flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I th= ink that we are not far from submitting it to the IESG. OLSRv2 could well o= perate on home devices with limited resources, and does not have the issues= of RIP.

Regards
Ulrich

On Mon, Oct 3, 201= 1 at 9:15 AM, Tony Li <tony.li@tony.li> wrote:


On Oct 3, 2011, at 8:58 AM, Randy Turner wrote:

>
> I would hope that we would NOT be seriously considering OSPF or IS-IS = in the home...this seems like using a sledgehammer to kill an ant. =A0How m= any routes are we talking about for a home network? =A0I don't believe = any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. =A0Our customers won't even = know what an IP address is.
>
> Seems like a "RIP-like" (around the same scope of complexity= ) would be enough for a homenet. =A0I'm curious to see what comes out o= f the LLN discussion.
>
> The "filter" for any of these decisions should probably alwa= ys be a "zeroconf" or "zeroadmin" scenario -- if a prop= osed approach to a problem can't exist in a "zeroconf/admin" = environment, then I would think it would not be the right choice. =A0Also, = as a "first cut" solution, we I think we should be focused on the= 80% use-case, not the fringe. =A0The participants of this working group, a= nd their respective home networking setups, are probably not our "typi= cal" customer.
>
> Randy
>
>
> On Oct 3, 2011, at 8:33 AM, Qiong wrote:
>
>> Hi, Acee,
>>
>> Agree. I think the HOMENET requirements should be derived from maj= or devices in the home network scenario. Maybe currently we should firstly = focus on multiple router scenario for traditional fixed and wireless networ= k for multiple services (especially WiFi) , and then introduce LLN network = as well for smart objects in the same environment, together with the homene= t architecture and new model in the future.
>>
>> Best wishes
>>
>> Qiong
>>
>>
>>
>>
>> I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and wi= reless networks, they will need to do so through a border router supporting= both environments. IMHO, we don't need one protocol that meets all req= uirements for every possible device in the home.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> >
>> >>
>> >> My first choice would NOT be something that isn't pro= ven in the field in multiple interoperable implementations.
>> >>
>> >> As a person thinking about making a recommendation, I'= ;d suggest that folks read https://tools.ietf.org/html/rfc2026#section= -4.1.2 and ask themselves why that level of interoperability isn't = mandatory.
>> >> _______________________________________________
>> >> homenet mailing list
>> >> homenet@ietf.org<= br> >> >> 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
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--002215974902da3d1004ae690e61-- From tony.li@tony.li Mon Oct 3 11:23:27 2011 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 F1CE621F8C89 for ; Mon, 3 Oct 2011 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66lqnz+AMz-o for ; Mon, 3 Oct 2011 11:23:24 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2721F8C07 for ; Mon, 3 Oct 2011 11:23:23 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id gBE41h0031YDfWL5DJSTDu; Mon, 03 Oct 2011 18:26:27 +0000 Received: from [10.155.34.172] ([128.107.239.233]) by omta20.westchester.pa.mail.comcast.net with comcast id gJRw1h00W52qHCY3gJS0ff; Mon, 03 Oct 2011 18:26:25 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Mon, 3 Oct 2011 11:25:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 03 Oct 2011 18:23:27 -0000 What's the rationale for not subsetting OSPF or IS-IS? Tony On Oct 3, 2011, at 11:22 AM, Ulrich Herberg wrote: > Hi Tony, >=20 > I agree. I would like to mention that we are specifying an extensible, = flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that = we are not far from submitting it to the IESG. OLSRv2 could well operate = on home devices with limited resources, and does not have the issues of = RIP. >=20 > Regards > Ulrich=20 >=20 > On Mon, Oct 3, 2011 at 9:15 AM, Tony Li wrote: >=20 > The problem with a RIP like protocol is that it will have RIP like = convergence properties. IMHO, that's no longer acceptable. >=20 > Doing a subset of a LS protocol with a trivial default configuration = should not be unreasonable. >=20 > Tony >=20 >=20 > On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: >=20 > > > > I would hope that we would NOT be seriously considering OSPF or = IS-IS in the home...this seems like using a sledgehammer to kill an ant. = How many routes are we talking about for a home network? I don't = believe any enterprise routing protocol was designed for a "zeroconf" or = "zeroadmin" type of environment. Our customers won't even know what an = IP address is. > > > > Seems like a "RIP-like" (around the same scope of complexity) would = be enough for a homenet. I'm curious to see what comes out of the LLN = discussion. > > > > The "filter" for any of these decisions should probably always be a = "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a = problem can't exist in a "zeroconf/admin" environment, then I would = think it would not be the right choice. Also, as a "first cut" = solution, we I think we should be focused on the 80% use-case, not the = fringe. The participants of this working group, and their respective = home networking setups, are probably not our "typical" customer. > > > > Randy > > > > > > On Oct 3, 2011, at 8:33 AM, Qiong wrote: > > > >> Hi, Acee, > >> > >> Agree. I think the HOMENET requirements should be derived from = major devices in the home network scenario. Maybe currently we should = firstly focus on multiple router scenario for traditional fixed and = wireless network for multiple services (especially WiFi) , and then = introduce LLN network as well for smart objects in the same environment, = together with the homenet architecture and new model in the future. > >> > >> Best wishes > >> > >> Qiong > >> > >> > >> > >> > >> I think a viable option for 2012 is that if the LLN networks with = their smart objects have to connect to the traditional HOMENET fixed and = wireless networks, they will need to do so through a border router = supporting both environments. IMHO, we don't need one protocol that = meets all requirements for every possible device in the home. > >> > >> Thanks, > >> Acee > >> > >> > >> > >> > > >> >> > >> >> My first choice would NOT be something that isn't proven in the = field in multiple interoperable implementations. > >> >> > >> >> As a person thinking about making a recommendation, I'd suggest = that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and = ask themselves why that level of interoperability isn't mandatory. > >> >> _______________________________________________ > >> >> 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 > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From gettysjim@gmail.com Mon Oct 3 11:25:08 2011 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 0327421F8B8B; Mon, 3 Oct 2011 11:25:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjkxujNfHG6C; Mon, 3 Oct 2011 11:25:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF99D21F8C98; Mon, 3 Oct 2011 11:25:06 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4702708vcb.31 for ; Mon, 03 Oct 2011 11:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+ePcMY+M3WAkB++jeChui9fwWYxCcUZnOtIW4kX3ULU=; b=GOBnn2Sto4V+8MeyLwwheXs52u/1s2QuxumbwbDulx1oCsYp9p6BFNGkJBkk5+XH0G Dfhq1Y+7rjQV4RMSMXDb6Zo7xqCfBhPr9PRCJY/FpFW2gxssLsYM2+u9NYo9GJQRg4e7 0HWNygPm6f90CCaGPFPn+61sbv6imhtgQvjVU= Received: by 10.52.89.239 with SMTP id br15mr246497vdb.428.1317666489517; Mon, 03 Oct 2011 11:28:09 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ja7sm14708026vdb.16.2011.10.03.11.28.07 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 11:28:08 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E89FEB6.3040904@freedesktop.org> Date: Mon, 03 Oct 2011 14:28:06 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Lorenzo Colitti References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , Fred Baker , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 03 Oct 2011 18:25:08 -0000 I think there is another set of routing issues that most have not thought about unless they have had experience with wireless networking; that is the possible need for diversity aware routing. See: http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf For an introduction to the topic, and some work in the area (e.g. babelz). In my house, for example, I have great trouble getting wires where all I need them, and I need multiple access points. I'd like to put one out in the pool shed, and I really can't get wires out there (without digging). This may or may not be orthogonal to the routing requirements to support multi-homing and multiple providers, but is something that many/most routing protocols have not dealt with in the past. - Jim From tony.li@tony.li Mon Oct 3 11:33:02 2011 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 853CA21F8CC5 for ; Mon, 3 Oct 2011 11:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lgQnoW4jE6N for ; Mon, 3 Oct 2011 11:33:01 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id DE99C21F8C6E for ; Mon, 3 Oct 2011 11:33:01 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta14.emeryville.ca.mail.comcast.net with comcast id gJan1h0040b6N64AEJbzx4; Mon, 03 Oct 2011 18:35:59 +0000 Received: from [10.155.34.172] ([128.107.239.233]) by omta03.emeryville.ca.mail.comcast.net with comcast id gJbk1h00N52qHCY8PJbnF5; Mon, 03 Oct 2011 18:36:11 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4E89FEB6.3040904@freedesktop.org> Date: Mon, 3 Oct 2011 11:35:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Question for you 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, 03 Oct 2011 18:33:02 -0000 LS protocols give every router a full picture of the topology, so the = diversity is apparent to all nodes. Tony On Oct 3, 2011, at 11:28 AM, Jim Gettys wrote: > I think there is another set of routing issues that most have not > thought about unless they have had experience with wireless = networking; > that is the possible need for diversity aware routing. >=20 > See: >=20 > http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf > >=20 > For an introduction to the topic, and some work in the area (e.g. = babelz). >=20 > In my house, for example, I have great trouble getting wires where all = I > need them, and I need multiple access points. I'd like to put one out > in the pool shed, and I really can't get wires out there (without = digging). >=20 > This may or may not be orthogonal to the routing requirements to = support > multi-homing and multiple providers, but is something that many/most > routing protocols have not dealt with in the past. > - Jim >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ulrich@herberg.name Mon Oct 3 11:39:41 2011 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 B1B6321F8D5C; Mon, 3 Oct 2011 11:39:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTJOX96C4KMl; Mon, 3 Oct 2011 11:39:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 721AB21F8D5A; Mon, 3 Oct 2011 11:39:38 -0700 (PDT) Received: by wyh21 with SMTP id 21so4012470wyh.31 for ; Mon, 03 Oct 2011 11:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V2l3enkK5NGNLPc8qIkwLl+mSlNRfDpB/iLAuk/waIs=; b=oU1d4AYf7+j2rf45E+3jjLJufcnFKxmzrp7xd5XaRIdSpBhAIB6qfxihRpDjTa35qR EWHtnm7LNzBfOJK8cThlxJAoog3Hzg/5N1vOa08O70F1BbMml6atbaNIQtVUS8YFFq8r IG9MzicMUiquYTZhDu9moC+J9KVIwAhrlj5pQ= MIME-Version: 1.0 Received: by 10.227.157.77 with SMTP id a13mr297130wbx.73.1317667359068; Mon, 03 Oct 2011 11:42:39 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 11:42:38 -0700 (PDT) In-Reply-To: <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> Date: Mon, 3 Oct 2011 11:42:38 -0700 Message-ID: From: Ulrich Herberg To: Tony Li Content-Type: multipart/alternative; boundary=0016e65503a8de969e04ae6956fe X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:41 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 03 Oct 2011 18:39:41 -0000 --0016e65503a8de969e04ae6956fe Content-Type: text/plain; charset=ISO-8859-1 Hi Tony, One reason for using OLSRv2 instead of OSPF is that it is optimized for wireless radio (fewer transmissions, optimized flooding, link bidirectionality check, compressed packet format, IPv6 support). Its TLV structure allows for extending the protocol easily (and for encapsulating other, arbitrary, data into control traffic messages). I assume that not all routers are required to be connected by cable in HOMENET, but some could be wireless (please correct me if I am wrong here...). I am not saying that OSPF is not (or less) suitable for these cases, but it may be worth considering the work done in MANET for HOMENET. Regards Ulrich On Mon, Oct 3, 2011 at 11:25 AM, Tony Li wrote: > > > What's the rationale for not subsetting OSPF or IS-IS? > > Tony > > > On Oct 3, 2011, at 11:22 AM, Ulrich Herberg wrote: > > > Hi Tony, > > > > I agree. I would like to mention that we are specifying an extensible, > flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we > are not far from submitting it to the IESG. OLSRv2 could well operate on > home devices with limited resources, and does not have the issues of RIP. > > > > Regards > > Ulrich > > > > On Mon, Oct 3, 2011 at 9:15 AM, Tony Li wrote: > > > > The problem with a RIP like protocol is that it will have RIP like > convergence properties. IMHO, that's no longer acceptable. > > > > Doing a subset of a LS protocol with a trivial default configuration > should not be unreasonable. > > > > Tony > > > > > > On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: > > > > > > > > I would hope that we would NOT be seriously considering OSPF or IS-IS > in the home...this seems like using a sledgehammer to kill an ant. How many > routes are we talking about for a home network? I don't believe any > enterprise routing protocol was designed for a "zeroconf" or "zeroadmin" > type of environment. Our customers won't even know what an IP address is. > > > > > > Seems like a "RIP-like" (around the same scope of complexity) would be > enough for a homenet. I'm curious to see what comes out of the LLN > discussion. > > > > > > The "filter" for any of these decisions should probably always be a > "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a problem > can't exist in a "zeroconf/admin" environment, then I would think it would > not be the right choice. Also, as a "first cut" solution, we I think we > should be focused on the 80% use-case, not the fringe. The participants of > this working group, and their respective home networking setups, are > probably not our "typical" customer. > > > > > > Randy > > > > > > > > > On Oct 3, 2011, at 8:33 AM, Qiong wrote: > > > > > >> Hi, Acee, > > >> > > >> Agree. I think the HOMENET requirements should be derived from major > devices in the home network scenario. Maybe currently we should firstly > focus on multiple router scenario for traditional fixed and wireless network > for multiple services (especially WiFi) , and then introduce LLN network as > well for smart objects in the same environment, together with the homenet > architecture and new model in the future. > > >> > > >> Best wishes > > >> > > >> Qiong > > >> > > >> > > >> > > >> > > >> I think a viable option for 2012 is that if the LLN networks with > their smart objects have to connect to the traditional HOMENET fixed and > wireless networks, they will need to do so through a border router > supporting both environments. IMHO, we don't need one protocol that meets > all requirements for every possible device in the home. > > >> > > >> Thanks, > > >> Acee > > >> > > >> > > >> > > >> > > > >> >> > > >> >> My first choice would NOT be something that isn't proven in the > field in multiple interoperable implementations. > > >> >> > > >> >> As a person thinking about making a recommendation, I'd suggest > that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask > themselves why that level of interoperability isn't mandatory. > > >> >> _______________________________________________ > > >> >> 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 > > > > > > _______________________________________________ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > --0016e65503a8de969e04ae6956fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tony,

One reason for using OLSRv2 instead of OSPF is that it is o= ptimized for wireless radio (fewer transmissions, optimized flooding, link = bidirectionality check, compressed packet format, IPv6 support). Its TLV st= ructure allows for extending the protocol easily (and for encapsulating oth= er, arbitrary, data into control traffic messages). I assume that not all r= outers are required to be connected by cable in HOMENET, but some could be = wireless (please correct me if I am wrong here...).

I am not saying that OSPF is not (or less) suitable for these cases, bu= t it may be worth considering the work done in MANET for HOMENET.

R= egards
Ulrich

On Mon, Oct 3, 2011 at 1= 1:25 AM, Tony Li <t= ony.li@tony.li> wrote:


What's the rationale for not subsetting OSPF or IS-IS?

Tony


On Oct 3, 2011, at 11:22 AM, Ulrich Herberg wrote:

> Hi Tony,
>
> I agree. I would like to mention that we are specifying an extensible,= flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we= are not far from submitting it to the IESG. OLSRv2 could well operate on h= ome devices with limited resources, and does not have the issues of RIP. >
> Regards
> Ulrich
>
> On Mon, Oct 3, 2011 at 9:15 AM, Tony Li <tony.li@tony.li> wrote:
>
> The problem with a RIP like protocol is that it will have RIP like con= vergence properties. =A0IMHO, that's no longer acceptable.
>
> Doing a subset of a LS protocol with a trivial default configuration s= hould not be unreasonable.
>
> Tony
>
>
> On Oct 3, 2011, at 8:58 AM, Randy Turner wrote:
>
> >
> > I would hope that we would NOT be seriously considering OSPF or I= S-IS in the home...this seems like using a sledgehammer to kill an ant. =A0= How many routes are we talking about for a home network? =A0I don't bel= ieve any enterprise routing protocol was designed for a "zeroconf"= ; or "zeroadmin" type of environment. =A0Our customers won't = even know what an IP address is.
> >
> > Seems like a "RIP-like" (around the same scope of compl= exity) would be enough for a homenet. =A0I'm curious to see what comes = out of the LLN discussion.
> >
> > The "filter" for any of these decisions should probably= always be a "zeroconf" or "zeroadmin" scenario -- if a= proposed approach to a problem can't exist in a "zeroconf/admin&q= uot; environment, then I would think it would not be the right choice. =A0A= lso, as a "first cut" solution, we I think we should be focused o= n the 80% use-case, not the fringe. =A0The participants of this working gro= up, and their respective home networking setups, are probably not our "= ;typical" customer.
> >
> > Randy
> >
> >
> > On Oct 3, 2011, at 8:33 AM, Qiong wrote:
> >
> >> Hi, Acee,
> >>
> >> Agree. I think the HOMENET requirements should be derived fro= m major devices in the home network scenario. Maybe currently we should fir= stly focus on multiple router scenario for traditional fixed and wireless n= etwork for multiple services (especially WiFi) , and then introduce LLN net= work as well for smart objects in the same environment, together with the h= omenet architecture and new model in the future.
> >>
> >> Best wishes
> >>
> >> Qiong
> >>
> >>
> >>
> >>
> >> I think a viable option for 2012 is that if the LLN networks = with their smart objects have to connect to the traditional HOMENET fixed a= nd wireless networks, they will need to do so through a border router suppo= rting both environments. IMHO, we don't need one protocol that meets al= l requirements for every possible device in the home.
> >>
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >> >
> >> >>
> >> >> My first choice would NOT be something that isn'= t proven in the field in multiple interoperable implementations.
> >> >>
> >> >> As a person thinking about making a recommendation, = I'd suggest that folks read https://tools.ietf.org/html/rfc2026#se= ction-4.1.2 and ask themselves why that level of interoperability isn&#= 39;t mandatory.
> >> >> _______________________________________________
> >> >> 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
> >
> > _______________________________________________
> > rtgwg mailing list
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


--0016e65503a8de969e04ae6956fe-- From robert@raszuk.net Mon Oct 3 11:52:58 2011 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 048CA21F8C5E for ; Mon, 3 Oct 2011 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ypzJMwqrdpA for ; Mon, 3 Oct 2011 11:52:57 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id B940221F8C5A for ; Mon, 3 Oct 2011 11:52:47 -0700 (PDT) Received: (qmail 26014 invoked by uid 399); 3 Oct 2011 18:49:10 -0000 Received: from unknown (HELO ?192.168.1.57?) (178.42.87.122) by mail37.opentransfer.com with SMTP; 3 Oct 2011 18:49:10 -0000 Message-ID: <4E8A03A5.5080601@raszuk.net> Date: Mon, 03 Oct 2011 20:49:09 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ulrich Herberg References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Qiong , Acee Lindem , Tony Li , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:52:58 -0000 One thing I am perhaps missing in this thread ... Why a wireless access point at the pool has to also be a router ? Isn't it sufficient to extend one or more layer 2 to it ? Thx, R. > Hi Tony, > > One reason for using OLSRv2 instead of OSPF is that it is optimized for > wireless radio (fewer transmissions, optimized flooding, link > bidirectionality check, compressed packet format, IPv6 support). Its TLV > structure allows for extending the protocol easily (and for encapsulating > other, arbitrary, data into control traffic messages). I assume that not all > routers are required to be connected by cable in HOMENET, but some could be > wireless (please correct me if I am wrong here...). > > I am not saying that OSPF is not (or less) suitable for these cases, but it > may be worth considering the work done in MANET for HOMENET. > > Regards > Ulrich From gettysjim@gmail.com Mon Oct 3 12:07:30 2011 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 E0BC421F8C45; Mon, 3 Oct 2011 12:07:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCFW4RnGOOAL; Mon, 3 Oct 2011 12:07:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4621F8C3A; Mon, 3 Oct 2011 12:07:26 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4752328vcb.31 for ; Mon, 03 Oct 2011 12:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RT953tceKRy9VbH/a2FkElpZtaDnmhwb56qJ1McT2b8=; b=YRKM/puxiTDinfOTrEs+rg2Ntp6VgfQgdR12YDlG5+Lzjl+PmLvMdMDKMxzCVOwlsH IKVnzvot+yT61rzxh/Z1nifsmzTu1tdoxRZuao37egwZnFVQDzfwSpOaHh/iEAyEm1on TOLINl5oZxzPOoKZY4FBekWqfb3GV9Ag1pJls= Received: by 10.52.98.3 with SMTP id ee3mr298227vdb.351.1317669028516; Mon, 03 Oct 2011 12:10:28 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id c20sm14833554vdt.6.2011.10.03.12.10.26 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 12:10:27 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E8A08A1.7000106@freedesktop.org> Date: Mon, 03 Oct 2011 15:10:25 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tony Li References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> In-Reply-To: <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Question for you 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, 03 Oct 2011 19:07:31 -0000 On 10/03/2011 02:35 PM, Tony Li wrote: > LS protocols give every router a full picture of the topology, so the diversity is apparent to all nodes. My point was just that wireless has a set of challenges that all may not be familiar with; knowing that may help point the discussion in fruitful ways. Routing isn't my area of expertise (though I have scars on my back from it in wireless...). - Jim > > Tony > > > On Oct 3, 2011, at 11:28 AM, Jim Gettys wrote: > >> I think there is another set of routing issues that most have not >> thought about unless they have had experience with wireless networking; >> that is the possible need for diversity aware routing. >> >> See: >> >> http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf >> >> >> For an introduction to the topic, and some work in the area (e.g. babelz). >> >> In my house, for example, I have great trouble getting wires where all I >> need them, and I need multiple access points. I'd like to put one out >> in the pool shed, and I really can't get wires out there (without digging). >> >> This may or may not be orthogonal to the routing requirements to support >> multi-homing and multiple providers, but is something that many/most >> routing protocols have not dealt with in the past. >> - Jim >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg From tony.li@tony.li Mon Oct 3 12:29:46 2011 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 7867721F8E0D for ; Mon, 3 Oct 2011 12:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD51f+2sELZH for ; Mon, 3 Oct 2011 12:29:46 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id A244C21F8E06 for ; Mon, 3 Oct 2011 12:29:45 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta01.emeryville.ca.mail.comcast.net with comcast id gDXG1h0021afHeLA1KYiGn; Mon, 03 Oct 2011 19:32:42 +0000 Received: from [10.155.34.172] ([128.107.239.233]) by omta17.emeryville.ca.mail.comcast.net with comcast id gKSL1h01i52qHCY8dKSPrX; Mon, 03 Oct 2011 19:26:47 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4E8A08A1.7000106@freedesktop.org> Date: Mon, 3 Oct 2011 12:32:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Question for you 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, 03 Oct 2011 19:29:46 -0000 On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > My point was just that wireless has a set of challenges that all may = not > be familiar with; knowing that may help point the discussion in = fruitful > ways. Routing isn't my area of expertise (though I have scars on my > back from it in wireless...). Understood. Yes, wireless has some challenges and I've spent some time in that area. = Certainly our standard protocols are not optimal for a purely wireless = environment. =20 However, for the generic, heterogenous networks that I would expect in = the home, I would expect that the generic protocols would be the better = overall approach. Tony From gettysjim@gmail.com Mon Oct 3 12:42:39 2011 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 7422321F8D82; Mon, 3 Oct 2011 12:42:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhhx64pwJ+ro; Mon, 3 Oct 2011 12:42:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 600A521F8D28; Mon, 3 Oct 2011 12:42:22 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4791739vcb.31 for ; Mon, 03 Oct 2011 12:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8g47aNweAibSgBLteuUo/RRZdPkIPHoxqZxkRHAtFq8=; b=Bvft+HMygzjKlAPJMDKaVag0/u9Lp7C1CMEPRhMdBxH5rMFwrNIsVjuUmWT6PuJMGN 90UWvT+Porh1NDj8RMwPdLWPxtmorLG38FnFIMet8nGKMiMwEF8Pa6vyG2qp4rrYxSOU i5ex4qbYTsWLACDn2ZpMUPfdoSbD44NvaA2O4= Received: by 10.220.5.210 with SMTP id 18mr104058vcw.83.1317671125138; Mon, 03 Oct 2011 12:45:25 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id o20sm14930893vdj.3.2011.10.03.12.45.23 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 12:45:24 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E8A10D2.1030105@freedesktop.org> Date: Mon, 03 Oct 2011 15:45:22 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tony Li References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> In-Reply-To: <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:40 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Question for you 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, 03 Oct 2011 19:42:39 -0000 On 10/03/2011 03:32 PM, Tony Li wrote: > On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > >> My point was just that wireless has a set of challenges that all may not >> be familiar with; knowing that may help point the discussion in fruitful >> ways. Routing isn't my area of expertise (though I have scars on my >> back from it in wireless...). > > Understood. > > Yes, wireless has some challenges and I've spent some time in that area. Certainly our standard protocols are not optimal for a purely wireless environment. > > However, for the generic, heterogenous networks that I would expect in the home, I would expect that the generic protocols would be the better overall approach. Having been seriously scarred by presuming that wireless was similar to wired, I'm a believer in careful testing, rather than "expecting" that something should work. Without "running code", demonstrably working, I'll take nothing on faith in this area. Wireless != wired, is what I took away from that (painful) experience. - Jim > > Tony > From ulrich@herberg.name Mon Oct 3 13:00:24 2011 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 1ADB521F8E4A; Mon, 3 Oct 2011 13:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACXaotQLm9ax; Mon, 3 Oct 2011 13:00:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7E321F8E4B; Mon, 3 Oct 2011 13:00:22 -0700 (PDT) Received: by wyh21 with SMTP id 21so4097261wyh.31 for ; Mon, 03 Oct 2011 13:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V/0/Xc29qo64CV689BadzRkO1E3mZo7dnjARW6XUbjU=; b=qcyA5KMcBSC9xtnn1OGsZOpFcisxn1hx1WS/+uyvRB2Kw2kbB82iPV3HvPhWV5qaM3 ZfDRZTTzi05egVzl8kxLLGUC71k6n7IC1Xs8JxfCf8itjALvchUYeyovEiFeafzUGK3L VTu6Bhn0QMHZQ4DZBUrrr9uSjZU5LUJH0mA2E= MIME-Version: 1.0 Received: by 10.227.7.25 with SMTP id b25mr357912wbb.103.1317672205030; Mon, 03 Oct 2011 13:03:25 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 13:03:24 -0700 (PDT) In-Reply-To: <4E8A10D2.1030105@freedesktop.org> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> <4E8A10D2.1030105@freedesktop.org> Date: Mon, 3 Oct 2011 13:03:24 -0700 Message-ID: From: Ulrich Herberg To: Jim Gettys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 03 Oct 2011 14:25:41 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Qiong , Acee Lindem , Tony Li , "homenet@ietf.org" , Lorenzo Colitti , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 03 Oct 2011 20:00:24 -0000 I agree with Jim. The reason why we developed OLSR and the its successor OLSRv2 was precisely that wireless environments are very different from wired. There are plenty of deployments of OLSR and several of OLSRv2, with up to several hundreds of wireless routers, so it is demonstrably working. Regards Ulrich On Mon, Oct 3, 2011 at 12:45 PM, Jim Gettys wrote: > > On 10/03/2011 03:32 PM, Tony Li wrote: > > On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > > > >> My point was just that wireless has a set of challenges that all may n= ot > >> be familiar with; knowing that may help point the discussion in fruitf= ul > >> ways. =A0Routing isn't my area of expertise (though I have scars on my > >> back from it in wireless...). > > > > Understood. > > > > Yes, wireless has some challenges and I've spent some time in that area= . =A0Certainly our standard protocols are not optimal for a purely wireless= environment. > > > > However, for the generic, heterogenous networks that I would expect in = the home, I would expect that the generic protocols would be the better ove= rall approach. > > Having been seriously scarred by presuming that wireless was similar to > wired, I'm a believer in careful testing, rather than "expecting" that > something should work. =A0Without "running code", demonstrably working, > I'll take nothing on faith in this area. > > Wireless !=3D wired, is what I took away from that (painful) experience. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim > > > > > Tony > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nordmark@cisco.com Mon Oct 3 18:43:28 2011 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 3093821F8E0E for ; Mon, 3 Oct 2011 18:43:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa2kmL-jMJZ9 for ; Mon, 3 Oct 2011 18:43:27 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B5BFC21F8DDE for ; Mon, 3 Oct 2011 18:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1731; q=dns/txt; s=iport; t=1317692791; x=1318902391; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tYs1YDg637v5+Vx1dyyoi7EggjuFD58AnMd1fGdzrEs=; b=OTMG+fmFpKe6olhGl+FYWfi2FlWWrQYBuoroxTB+KuQiIYZTfCYeNpf0 ZKe65N9p6E7Y7l5jwzyZtDHX+RJD8Y81hjLhxQIVMG6qDQ1TLmrWr+e+D ODLnCwQcaxqQz43MZ/1C6b+jxKz2OAiAUYa1iRl9L8umjTiYm4DYcAabR 8=; X-IronPort-AV: E=Sophos;i="4.68,482,1312156800"; d="scan'208";a="5754325" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 04 Oct 2011 01:46:31 +0000 Received: from [10.0.1.12] (sjc-vpn5-575.cisco.com [10.21.90.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p941kVQd014668; Tue, 4 Oct 2011 01:46:31 GMT Message-ID: <4E8A658B.9060200@cisco.com> Date: Mon, 03 Oct 2011 18:46:51 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ray Hunter References: <4E7A46EC.8080109@globis.net> In-Reply-To: <4E7A46EC.8080109@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Chown , homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 04 Oct 2011 01:43:28 -0000 On 9/21/11 1:19 PM, Ray Hunter wrote: > 1) I contend that multi-homing is probably going to become the "norm" in > Europe by 2022, due to The European Electricity and Gas Directive. That > corresponds at least to picture 4, if not more. If we believe that multi-homing will be more common, then I think we need to understand what the constraints are for the multihoming in particular as this relates to walled gardens. I can see many different possibilities, which imply different requirements. 1. Just two paths to the Internet; the home gets one PA prefix from each ISP. 2. Like #1 but in addition the ISPs run ingress filtering so that the source address in a packet from the home has to match the prefix that ISP delegated. 3. Like #1, but there are QoS guarantees for traffic local to an ISP. Thus a host in the home can connect to foo.ispA.net over either ISP-A or ISP-B, but gets better voice/video quality when doing it over ISP-A's connection. 4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, but fails (NXDOMAIN) when asking ISP-B. 5. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but fails (due to firewalls) for packets that are sent out via ISP-B. 6. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but the application-layer content is completely different (e.g., a "subscriber" view when connecting over the ISP-A connection). 7. The lookup of foo.ispA.net returns different IP addresses when asking ISP-A vs. ISP-B. Do we really want to solve all those problems in homenet? We can't tell the difference between behavior #1 and #6 at the IP layer. Erik From ulrich@herberg.name Mon Oct 3 19:25:44 2011 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 C38F521F8E64 for ; Mon, 3 Oct 2011 19:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJX0UCZSDcBH for ; Mon, 3 Oct 2011 19:25:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82AC821F8E50 for ; Mon, 3 Oct 2011 19:25:43 -0700 (PDT) Received: by wwf22 with SMTP id 22so23039wwf.13 for ; Mon, 03 Oct 2011 19:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Iv3w89LW+hT3AYRRVPlJRwTHXCUFQFCQk3/VbeGkijQ=; b=WWD7fAZf5iFYq0DWAY14lnduFia0xy1FkBVF3aLJ4OQLG+3YT+R5z9FBExbryRJGvG dJywuTXatOD80sHd2ZT8sYPMpPuFFOF2sbDfoqP71AFsaBMnE5oWwMZehXnYdUqIrRPO +NZVTAOWxukWTqhdjXSzLYE+cRMwe+jj04XcI= MIME-Version: 1.0 Received: by 10.227.204.14 with SMTP id fk14mr733976wbb.88.1317695326858; Mon, 03 Oct 2011 19:28:46 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Mon, 3 Oct 2011 19:28:46 -0700 (PDT) In-Reply-To: <12605.1317691562@marajade.sandelman.ca> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <12605.1317691562@marajade.sandelman.ca> Date: Mon, 3 Oct 2011 19:28:46 -0700 Message-ID: From: Ulrich Herberg To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 04 Oct 2011 02:25:44 -0000 Michael, On Mon, Oct 3, 2011 at 6:26 PM, Michael Richardson wrote= : > >>>>>> "Ulrich" =3D=3D Ulrich Herberg writes: > =A0 =A0Ulrich> arbitrary, data into control traffic messages). I assume > =A0 =A0Ulrich> that not all routers are required to be connected by cable > =A0 =A0Ulrich> in HOMENET, but some could be wireless (please correct me = if > =A0 =A0Ulrich> I am wrong here...). > > You should assume that essentially all devices with more than one > possible interface are possible routers. =A0So my HTC G2 has four > interfaces: wifi, 3G, Bluetooth PAN, and USB-ethernet. Yes, that's what I assumed. I would even argue that in the future, most links will be wireless within the house (and possibly even the connectivity to the Internet). > Note that just because my 3G is up and alive, and can be used by my > phone, doesn't mean that the purpose of it participating in the routing > is to provide *Internet* to the rest of the house. =A0It might only be > talking to my house network to get across it so that it can turn > activate a light switch... Yes, but that should not be any problem; it just depends which prefixes are allocated to and advertised by the routers. Regards Ulrich From therbst@silverspringnet.com Mon Oct 3 21:01:37 2011 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 ACDFB21F8EAC for ; Mon, 3 Oct 2011 21:01:37 -0700 (PDT) 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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uaoK+TGfga4 for ; Mon, 3 Oct 2011 21:01:37 -0700 (PDT) Received: from it-ipdr-01.silverspringnet.com (it-ipdr-01.silverspringnet.com [74.121.22.27]) by ietfa.amsl.com (Postfix) with ESMTP id 322F321F8E82 for ; Mon, 3 Oct 2011 21:01:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAJ6Eik4KyAE+/2dsb2JhbABCmHGQGIFTAQEBAQMBAQE3NAsQAgEIDQQBAwEBAQoUECcLFwYIAQEEAQ0FCId5uCqGQGEEh3eRLowc X-IronPort-AV: E=Sophos;i="4.68,483,1312182000"; d="scan'208";a="899014" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipdr-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 03 Oct 2011 21:04:38 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Mon, 3 Oct 2011 21:04:38 -0700 From: Thomas Herbst To: Erik Nordmark , Ray Hunter Date: Mon, 3 Oct 2011 21:00:55 -0700 Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AcyCN3R5C66GzQDiRpK4RU9jJwL2ygAEsMTW Message-ID: <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> References: <4E7A46EC.8080109@globis.net>,<4E8A658B.9060200@cisco.com> In-Reply-To: <4E8A658B.9060200@cisco.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: Tim Chown , "homenet@ietf.org" Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 04 Oct 2011 04:01:37 -0000 There will be wide area network providers who interwork with the home netwo= rk but do not provide global connectivity. =20 Two mentioned so far are utility networks and 3g providers. One of the out= puts of the wg should be to define how they should be configured to perform= their role without messing up Internet communication. A wg Chair from the Internet area did accuse me of "breaking the Internet m= odel" because the utility networks my company builds do not provide global = connectivity to users with our 100kb to the node. tom ________________________________________ From: homenet-bounces@ietf.org [homenet-bounces@ietf.org] On Behalf Of Erik= Nordmark [nordmark@cisco.com] Sent: Monday, October 03, 2011 6:46 PM To: Ray Hunter Cc: Tim Chown; homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting On 9/21/11 1:19 PM, Ray Hunter wrote: > 1) I contend that multi-homing is probably going to become the "norm" in > Europe by 2022, due to The European Electricity and Gas Directive. That > corresponds at least to picture 4, if not more. If we believe that multi-homing will be more common, then I think we need to understand what the constraints are for the multihoming in particular as this relates to walled gardens. I can see many different possibilities, which imply different requirements. 1. Just two paths to the Internet; the home gets one PA prefix from each ISP. 2. Like #1 but in addition the ISPs run ingress filtering so that the source address in a packet from the home has to match the prefix that ISP delegated. 3. Like #1, but there are QoS guarantees for traffic local to an ISP. Thus a host in the home can connect to foo.ispA.net over either ISP-A or ISP-B, but gets better voice/video quality when doing it over ISP-A's connection. 4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, but fails (NXDOMAIN) when asking ISP-B. 5. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but fails (due to firewalls) for packets that are sent out via ISP-B. 6. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but the application-layer content is completely different (e.g., a "subscriber" view when connecting over the ISP-A connection). 7. The lookup of foo.ispA.net returns different IP addresses when asking ISP-A vs. ISP-B. Do we really want to solve all those problems in homenet? We can't tell the difference between behavior #1 and #6 at the IP layer. Erik _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From nordmark@cisco.com Mon Oct 3 21:32:32 2011 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 A7CF221F8D67 for ; Mon, 3 Oct 2011 21:32:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1V9tKkGPm5O for ; Mon, 3 Oct 2011 21:32:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7702C21F8CC0 for ; Mon, 3 Oct 2011 21:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1293; q=dns/txt; s=iport; t=1317702934; x=1318912534; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0bPo7wrhIyCy7FROA5riZywoPH0DYLogxkqS0xcn/Jo=; b=bElcOtHQ+GVOY5RzZWOx7kWhfpouMPBi6gzlkaIqXc8JyLKEp0w0EXE4 E+P/sOIY+lW+5b9eJLJ7cXb4M+zphE8SHopfP4Wb2pdkkX1UHmDpdU8kI FfYBhh73NwUnTpK7HIuJGYbTxreeAHkBiKiTvEmw7ONE7oQV3hQqlleB/ A=; X-IronPort-AV: E=Sophos;i="4.68,483,1312156800"; d="scan'208";a="5753649" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 04 Oct 2011 04:35:34 +0000 Received: from [10.0.1.12] (sjc-vpn5-739.cisco.com [10.21.90.227]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p944ZYpf003780; Tue, 4 Oct 2011 04:35:34 GMT Message-ID: <4E8A8D2A.4060002@cisco.com> Date: Mon, 03 Oct 2011 21:35:54 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tim Chown References: <20110921113700.25835.21217.idtracker@ietfa.amsl.com> <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.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] draft-chown-homenet-arch-00.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, 04 Oct 2011 04:32:32 -0000 On 9/21/11 5:27 AM, Tim Chown wrote: > Hi, > > I have been working with Jari, Jason and Ole to produce a new version > of the homenet architecture draft. Mark, who produced the first > version with Jari, is now of course WG chair and has stepped down as > editor of the text. One thing I've been looking for is a way to avoid boiling the ocean; I think being able to assign stable IP address prefixes in an arbitrary topology is a hard problem, yet I think there simple home topologies that show up today with IPv4 NATs that we should be able to handle with relative ease. Today's IPv4 consumer home routers have a designated uplink port (labeled "Internet", "WAN", or something similar) and the behavior is different on that port (where it runs a DHCPv4 client) and the other ports (where it runs a DHCPv4 server). If we start with a simple solution to target such devices for IPv6 home networks (without IPv6 NATs), then we can come up with hierarchical prefix delegation and default routes towards the delegating routers; no need to ensure that a single stable prefix is assigned to each link in an arbitrary topology of routers. Then we can work on that harder problem as an extension of the simple approach for the simple topologies. Erik From joelja@bogus.com Mon Oct 3 22:15:14 2011 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 EE71821F8F22 for ; Mon, 3 Oct 2011 22:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEiM07oMNW1z for ; Mon, 3 Oct 2011 22:15:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3D821F8F0E for ; Mon, 3 Oct 2011 22:15:13 -0700 (PDT) Received: from Zorch.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 p945GPQ1042195 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 4 Oct 2011 05:16:26 GMT (envelope-from joelja@bogus.com) Message-ID: <4E8A96AA.3090906@bogus.com> Date: Mon, 03 Oct 2011 22:16:26 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Thomas Herbst References: <4E7A46EC.8080109@globis.net>, <4E8A658B.9060200@cisco.com> <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> In-Reply-To: <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> Content-Type: text/plain; charset=ISO-8859-1 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]); Tue, 04 Oct 2011 05:16:28 +0000 (UTC) Cc: Ray Hunter , Erik Nordmark , "homenet@ietf.org" , Tim Chown Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 04 Oct 2011 05:15:15 -0000 On 10/3/11 21:00 , Thomas Herbst wrote: > There will be wide area network providers who interwork with the home > network but do not provide global connectivity. Two mentioned so far > are utility networks and 3g providers. One of the outputs of the wg > should be to define how they should be configured to perform their > role without messing up Internet communication. > > A wg Chair from the Internet area did accuse me of "breaking the > Internet model" because the utility networks my company builds do not > provide global connectivity to users with our 100kb to the node. not all (inter)networks provide internet connectivity. something more pretty than the 250+ routes my split-tunnel ssl vpn client just installed when it came up would be appreciated. defusing knowledge about avail destinations is why we want routing in the first place. > tom > > ________________________________________ From: > homenet-bounces@ietf.org [homenet-bounces@ietf.org] On Behalf Of Erik > Nordmark [nordmark@cisco.com] Sent: Monday, October 03, 2011 6:46 PM > To: Ray Hunter Cc: Tim Chown; homenet@ietf.org Subject: Re: [homenet] > Homenet Architecture & Interim Meeting > > On 9/21/11 1:19 PM, Ray Hunter wrote: >> 1) I contend that multi-homing is probably going to become the >> "norm" in Europe by 2022, due to The European Electricity and Gas >> Directive. That corresponds at least to picture 4, if not more. > > If we believe that multi-homing will be more common, then I think we > need to understand what the constraints are for the multihoming in > particular as this relates to walled gardens. I can see many > different possibilities, which imply different requirements. > > 1. Just two paths to the Internet; the home gets one PA prefix from > each ISP. > > 2. Like #1 but in addition the ISPs run ingress filtering so that > the source address in a packet from the home has to match the prefix > that ISP delegated. > > 3. Like #1, but there are QoS guarantees for traffic local to an > ISP. Thus a host in the home can connect to foo.ispA.net over either > ISP-A or ISP-B, but gets better voice/video quality when doing it > over ISP-A's connection. > > 4. Looking up foo.ispA.net works when asking the DNS server at > ISP-A, but fails (NXDOMAIN) when asking ISP-B. > > 5. The lookup of foo.ispA.net works over either DNS and returns the > same IP address, but fails (due to firewalls) for packets that are > sent out via ISP-B. > > 6. The lookup of foo.ispA.net works over either DNS and returns the > same IP address, but the application-layer content is completely > different (e.g., a "subscriber" view when connecting over the ISP-A > connection). > > 7. The lookup of foo.ispA.net returns different IP addresses when > asking ISP-A vs. ISP-B. > > > Do we really want to solve all those problems in homenet? We can't > tell the difference between behavior #1 and #6 at the IP layer. > > Erik _______________________________________________ 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 v6ops@globis.net Mon Oct 3 23:26:29 2011 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 CAC7E21F8DA4 for ; Mon, 3 Oct 2011 23:26:29 -0700 (PDT) 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.059, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgIZjPBFfZU1 for ; Mon, 3 Oct 2011 23:26:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE221F8D7A for ; Mon, 3 Oct 2011 23:26:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A5CDF8700EA; Tue, 4 Oct 2011 08:29:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+H09UMZE3pW; Tue, 4 Oct 2011 08:29:24 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 161D28700E5; Tue, 4 Oct 2011 08:29:23 +0200 (CEST) Message-ID: <4E8AA7C3.2020008@globis.net> Date: Tue, 04 Oct 2011 08:29:23 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Erik Kline , homenet@ietf.org Content-Type: multipart/alternative; boundary="------------080007030600050402000201" Subject: Re: [homenet] draft-chown-homenet-arch-00.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, 04 Oct 2011 06:26:29 -0000 This is a multi-part message in MIME format. --------------080007030600050402000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 on starting by replicating the IPv4 stacking approach in use today. My 2c worth (as I can't attend the meeting) If the starting point for Homenet architecture is multiple trees of stackable devices, I would then define a stackable device to consist of one or more of: 1) An ISP port 2) An end device port 3) A L2 VLAN port 4) A stack-in port (optional) 5) A stack-out port (optional) 6) A topology configuration function (either manual or automatic) 7) A packet forwarding function 8) A VLAN function 9) A router function 10) A firewall function 11) name resolution function 12) An address delegation server function 13) An address delegation client function 14) an ISP selection function All of these functions can be implemented in existing code and hardware with IPv4 (e.g. openwrt). There's nothing really crazy or new here that people won't be doing already today with IPv4. In fact, the need for stackable devices has been written about on the IPv6 lists on several occasions. Please note that the above are functional descriptions, not hard allocations. The ports may well be the same Ethernets soft switched based on the location of the device in the tree, and their individual functions assigned using the topology configuration function. In the case of a VM running on an end host, that would implement the stack-in port function on the interface connected to a homenet router, and deploy other functions such as VLAN's and routing internally within the VM kernel. Looking at each item in turn: 1. An ISP port would adapt to the physical media of the uplink (Ethernet, DSL etc.), would provide any login credentials (PPP etc.) negotiate link addresses (address delegation client function = DHCPv4 client). It would also have a stateful packet firewall function (on by default). Existence of a working ISP port implies that this is a "root" device of the Homenet tree. How do you know if this interface is an ISP port? Manual configuration, interface type, PD learns a prefix via this interface. 2. An end device port would be a flat L2 LAN port. I think these are well understood. Although the endless debate of SLAAC or DHCPv6 or something else will probably remain just that. Given the massive deployment of DHCPv4 in home networks, I'm tempted to say DHCPv6 should be preferred, without any intention of restarting a war. 3. An L2 VLAN port would be any standard switch port, either internal or external. 4. The stack-in port connects to upstream Homenet devices. The stack-in port in IPv4 does not have to be any different from an ISP port in an IPv4 implementation. It acts as a DHCPv4 client and can spoof the remote end into thinking it's simply an end host by applying outbound NATv4 (also for address conservation). Obviously I think we'd prefer to avoid NAT66 by default. Equally there's no fundamental reason why the stack-in function should have the firewall function enabled by default. So in an IPv6 implementation it would have the firewall disabled by default, and would receive delegated prefixes (see prefix delegation below) 5. The stack out port connects to downstream Homenet devices. The stack-out port in IPv4 does not have to be any different from an end device port in an IPv4 implementation. It acts as a DHCPv4 server to any attached devices. In IPv6 it would have to be able to cascade Prefix Delegation obtained from the root CPE router. (see prefix delegation below) 6. The topology configuration function would be new for IPv6. Although it exists implicitly in IPv4 Homenet's, the fact that stack-out ports are largely functionally identical to end device ports and stack-in ports are largely identical to ISP ports makes it largely redundant: thus the firewall function, DHCPv4 client and server, and NATv4 are almost always enabled by default in IPv4 implementations. This would not work for IPv6. I think the topology configuration function should be automatic given the plug and play requirement for configuration by non-expert end users. 7. Packet forwarding is a basic kernel function of the device. It may either route or switch, depending on the port type. 8. A VLAN function would be allowed to speak any standard VLAN protocol, and can either be internal to the box as a virtual interface or a physical interface for inter-switch connection. 9. The router function can speak standard IGP on any interface (as already being discussed). Default would be disabled on the ISP port. 10. I think the firewall function is well understood for both IPv4 and IPv6, even though it is not fully standardized within the IETF. I don't think Homenet needs to specify too much here expect that the firewall should be stateful. 11. Name Resolution Here's where I start to run into problems. In IPv4 implementations with NATv4, you've always got the option of split DNS. There are a number of local name resolution specs which AFAIK assume flat LANs and are not generally routeable. I'm not sure that there's a simple solution for Homenet to handle the combination of local names and potentially multiple ISPs. I could well be wrong. 12+13. Prefix Delegation Client and Server: Whilst there's no requirement for address conservation yet in an IPv6 implementation, there's a real danger of getting stuck because AFAIK Prefix Delegation is only defined between an ISP router and _the_ (singular) customer premises router. Also if an ISP only provides a single /64 to the root CPE router via PD, there are no standards for how or whether to subdivide this prefix further. Does Homenet then simply fail? Or should it implement true CIDR to provide >/64 prefixes to sub-devices in the tree? 14. ISP Selection function The ISP selection function in IPv4 implementations can be a straight outbound ping to a remote device to check basic reachability, plus application of NATv4 to ensure that the return route is correct. Note that for Homenet I would bundle NATv4 in with the ISP selection function, not necessarily the ISP interface. There are many such basic load balancing implementations on the market already. Despite all of the various multi-homing initiatives, I have yet to see how an IPv6 ISP selection function would work. So the main 3 challenges IMHO are: 1) A protocol suitable for topology detection and configuration. 2) A protocol suitable for cascaded prefix delegation within the Homenet. Unless all Homenet devices implement a routing protocol that can distribute the address of a DHCPv6 server so a DHCPv6 client can be made to contact a DHCPv6 server in the root CPE device, which distributes prefixes it has learned via PD from the ISP. 3) Any protocol that allows ISP selection and correct reverse routing to the end device (without resorting to NAT66, or dynamic routing to end devices, or DHCPv6 distributed address selection) Homenet is unlikely to solve this in detail, but it should/could be used as a signal to other WG's of the importance of multi-homing. A basic choice of whether ISP selection and multihoming is a homenet router function, or an end device function would already be a useful pointer IMHO. I'm sure there's smarter people than me on the list that can fill these gaps, or exclude these requirements in V1. best regards, RayH > Subject: > Re: [homenet] draft-chown-homenet-arch-00.txt > From: > Erik Nordmark > Date: > Mon, 03 Oct 2011 21:35:54 -0700 > > To: > Tim Chown > CC: > homenet@ietf.org > > Content-Transfer-Encoding: > 7bit > Precedence: > list > MIME-Version: > 1.0 > References: > <20110921113700.25835.21217.idtracker@ietfa.amsl.com> > <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk> > > > In-Reply-To: > > > Message-ID: > <4E8A8D2A.4060002@cisco.com> > Content-Type: > text/plain; charset=ISO-8859-1; format=flowed > Message: > 7 > > > On 9/21/11 5:27 AM, Tim Chown wrote: >> Hi, >> >> I have been working with Jari, Jason and Ole to produce a new version >> of the homenet architecture draft. Mark, who produced the first >> version with Jari, is now of course WG chair and has stepped down as >> editor of the text. > > One thing I've been looking for is a way to avoid boiling the ocean; I > think being able to assign stable IP address prefixes in an arbitrary > topology is a hard problem, yet I think there simple home topologies > that show up today with IPv4 NATs that we should be able to handle > with relative ease. > > Today's IPv4 consumer home routers have a designated uplink port > (labeled "Internet", "WAN", or something similar) and the behavior is > different on that port (where it runs a DHCPv4 client) and the other > ports (where it runs a DHCPv4 server). If we start with a simple > solution to target such devices for IPv6 home networks (without IPv6 > NATs), then we can come up with hierarchical prefix delegation and > default routes towards the delegating routers; no need to ensure that > a single stable prefix is assigned to each link in an arbitrary > topology of routers. > > Then we can work on that harder problem as an extension of the simple > approach for the simple topologies. > > Erik --------------080007030600050402000201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 on starting by replicating the IPv4 stacking approach in use today.

My 2c worth (as I can't attend the meeting)

If the starting point for Homenet architecture is multiple trees of stackable devices, I would then define a stackable device to consist of one or more of:

1) An ISP port
2) An end device port
3) A L2 VLAN port
4) A stack-in port (optional)
5) A stack-out port (optional)
6) A topology configuration function (either manual or automatic)
7) A packet forwarding function
8) A VLAN function
9) A router function
10) A firewall function
11) name resolution function
12) An address delegation server function
13) An address delegation client function
14) an ISP selection function

All of these functions can be implemented in existing code and hardware with IPv4 (e.g. openwrt). There's nothing really crazy or new here that people won't be doing already today with IPv4. In fact, the need for stackable devices has been written about on the IPv6 lists on several occasions.

Please note that the above are functional descriptions, not hard allocations. The ports may well be the same Ethernets soft switched based on the location of the device in the tree, and their individual functions assigned using the topology configuration function. In the case of a VM running on an end host, that would implement the stack-in port function on the interface connected to a homenet router, and deploy other functions such as VLAN's and routing internally within the VM kernel.

Looking at each item in turn:

1. An ISP port would adapt to the physical media of the uplink (Ethernet, DSL etc.), would provide any login credentials (PPP etc.) negotiate link addresses (address delegation client function = DHCPv4 client). It would also have a stateful packet firewall function (on by default). Existence of a working ISP port implies that this is a "root" device of the Homenet tree. How do you know if this interface is an ISP port? Manual configuration, interface type, PD learns a prefix via this interface.

2. An end device port would be a flat L2 LAN port. I think these are well understood. Although the endless debate of SLAAC or DHCPv6 or something else will probably remain just that. Given the massive deployment of DHCPv4 in home networks, I'm tempted to say DHCPv6 should be preferred, without any intention of restarting a war.

3. An L2 VLAN port would be any standard switch port, either internal or external.

4. The stack-in port connects to upstream Homenet devices.

The stack-in port in IPv4 does not have to be any different from an ISP port in an IPv4 implementation. It acts as a DHCPv4 client and can spoof the remote end into thinking it's simply an end host by applying outbound NATv4 (also for address conservation). Obviously I think we'd prefer to avoid NAT66 by default. Equally there's no fundamental reason why the stack-in function should have the firewall function enabled by default. So in an IPv6 implementation it would have the firewall disabled by default, and would receive delegated prefixes (see prefix delegation below)

5. The stack out port connects to downstream Homenet devices.

The stack-out port in IPv4 does not have to be any different from an end device port in an IPv4 implementation. It acts as a DHCPv4 server to any attached devices. In IPv6 it would have to be able to cascade Prefix Delegation obtained from the root CPE router. (see prefix delegation below)

6. The topology configuration function would be new for IPv6. Although it exists implicitly in IPv4 Homenet's, the fact that stack-out ports are largely functionally identical to end device ports and stack-in ports are largely identical to ISP ports makes it largely redundant: thus the firewall function, DHCPv4 client and server, and NATv4 are almost always enabled by default in IPv4 implementations. This would not work for IPv6. I think the topology configuration function should be automatic given the plug and play requirement for configuration by non-expert end users.

7. Packet forwarding is a basic kernel function of the device. It may either route or switch, depending on the port type.

8. A VLAN function would be allowed to speak any standard VLAN protocol, and can either be internal to the box as a virtual interface or a physical interface for inter-switch connection.

9. The router function can speak standard IGP on any interface (as already being discussed). Default would be disabled on the ISP port.

10. I think the firewall function is well understood for both IPv4 and IPv6, even though it is not fully standardized within the IETF. I don't think Homenet needs to specify too much here expect that the firewall should be stateful.

11. Name Resolution
Here's where I start to run into problems.

In IPv4 implementations with NATv4, you've always got the option of split DNS.

There are a number of local name resolution specs which AFAIK assume flat LANs and are not generally routeable.
I'm not sure that there's a simple solution for Homenet to handle the combination of local names and potentially multiple ISPs. I could well be wrong.

12+13. Prefix Delegation Client and Server:
Whilst there's no requirement for address conservation yet in an IPv6 implementation, there's a real danger of getting stuck because AFAIK Prefix Delegation is only defined between an ISP router and _the_ (singular) customer premises router. Also if an ISP only provides a single /64 to the root CPE router via PD, there are no standards for how or whether to subdivide this prefix further. Does Homenet then simply fail? Or should it implement true CIDR to provide >/64 prefixes to sub-devices in the tree?

14. ISP Selection function
The ISP selection function in IPv4 implementations can be a straight outbound ping to a remote device to check basic reachability, plus application of NATv4 to ensure that the return route is correct. Note that for Homenet I would bundle NATv4 in with the ISP selection function, not necessarily the ISP interface. There are many such basic load balancing implementations on the market already. Despite all of the various multi-homing initiatives, I have yet to see how an IPv6 ISP selection function would work.

So the main 3 challenges IMHO are:

1) A protocol suitable for topology detection and configuration.

2)  A protocol suitable for cascaded prefix delegation within the Homenet.

Unless all Homenet devices implement a routing protocol that can distribute the address of a DHCPv6 server so a DHCPv6 client can be made to contact a DHCPv6 server in the root CPE device, which distributes prefixes it has learned via PD from the ISP.

3) Any protocol that allows ISP selection and correct reverse routing to the end device (without resorting to NAT66, or dynamic routing to end devices, or DHCPv6 distributed address selection) Homenet is unlikely to solve this in detail, but it should/could be used as a signal to other WG's of the importance of multi-homing. A basic choice of whether ISP selection and multihoming is a homenet router function, or an end device function would already be a useful pointer IMHO.

I'm sure there's smarter people than me on the list that can fill these gaps, or exclude these requirements in V1.

best regards,
RayH
Subject:
Re: [homenet] draft-chown-homenet-arch-00.txt
From:
Erik Nordmark <nordmark@cisco.com>
Date:
Mon, 03 Oct 2011 21:35:54 -0700
To:
Tim Chown <tjc@ecs.soton.ac.uk>
CC:
homenet@ietf.org
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<20110921113700.25835.21217.idtracker@ietfa.amsl.com> <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk> <EMEW3|507144591d242f9fb36239f554f547a1n8KDRS03tjc|ecs.soton.ac.uk|6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk>
In-Reply-To:
<EMEW3|507144591d242f9fb36239f554f547a1n8KDRS03tjc|ecs.soton.ac.uk|6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk>
Message-ID:
<4E8A8D2A.4060002@cisco.com>
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
Message:
7

On 9/21/11 5:27 AM, Tim Chown wrote:
Hi,

I have been working with Jari, Jason and Ole to produce a new version
of the homenet architecture draft. Mark, who produced the first
version with Jari, is now of course WG chair and has stepped down as
editor of the text.

One thing I've been looking for is a way to avoid boiling the ocean; I think being able to assign stable IP address prefixes in an arbitrary topology is a hard problem, yet I think there simple home topologies that show up today with IPv4 NATs that we should be able to handle with relative ease.

Today's IPv4 consumer home routers have a designated uplink port (labeled "Internet", "WAN", or something similar) and the behavior is different on that port (where it runs a DHCPv4 client) and the other ports (where it runs a DHCPv4 server). If we start with a simple solution to target such devices for IPv6 home networks (without IPv6 NATs), then we can come up with hierarchical prefix delegation and default routes towards the delegating routers; no need to ensure that a single stable prefix is assigned to each link in an arbitrary topology of routers.

Then we can work on that harder problem as an extension of the simple approach for the simple topologies.

   Erik
--------------080007030600050402000201-- From mcr@sandelman.ca Mon Oct 3 18:22:15 2011 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 CC20521F8494; Mon, 3 Oct 2011 18:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hajmjTkZ9iYM; Mon, 3 Oct 2011 18:22:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F26D921F848A; Mon, 3 Oct 2011 18:22:14 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 76A7F343AE; Mon, 3 Oct 2011 21:24:14 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 40DC29817F; Mon, 3 Oct 2011 21:26:02 -0400 (EDT) From: Michael Richardson To: Ulrich Herberg In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 03 Oct 2011 21:26:02 -0400 Message-ID: <12605.1317691562@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Tue, 04 Oct 2011 00:40:33 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Qiong , Acee Lindem , Tony Li , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 04 Oct 2011 01:22:15 -0000 >>>>> "Ulrich" == Ulrich Herberg writes: Ulrich> arbitrary, data into control traffic messages). I assume Ulrich> that not all routers are required to be connected by cable Ulrich> in HOMENET, but some could be wireless (please correct me if Ulrich> I am wrong here...). You should assume that essentially all devices with more than one possible interface are possible routers. So my HTC G2 has four interfaces: wifi, 3G, Bluetooth PAN, and USB-ethernet. Note that just because my 3G is up and alive, and can be used by my phone, doesn't mean that the purpose of it participating in the routing is to provide *Internet* to the rest of the house. It might only be talking to my house network to get across it so that it can turn activate a light switch... -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Mon Oct 3 18:23:57 2011 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 2357721F8B94; Mon, 3 Oct 2011 18:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYupk0YzMl9h; Mon, 3 Oct 2011 18:23:56 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id AF64721F8B74; Mon, 3 Oct 2011 18:23:56 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 218F0343A4; Mon, 3 Oct 2011 21:26:01 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0FC849817F; Mon, 3 Oct 2011 21:27:49 -0400 (EDT) From: Michael Richardson To: robert@raszuk.net In-Reply-To: <4E8A03A5.5080601@raszuk.net> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 03 Oct 2011 21:27:49 -0400 Message-ID: <12856.1317691669@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Tue, 04 Oct 2011 00:40:33 -0700 Cc: C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Ulrich Herberg , Acee Lindem , Qiong , Tony Li , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 04 Oct 2011 01:23:57 -0000 >>>>> "Robert" == Robert Raszuk writes: Robert> Why a wireless access point at the pool has to also be a Robert> router ? Isn't it sufficient to extend one or more layer 2 Robert> to it ? It's not much of an access point if it doesn't have a second interface, is it? If it's out at the pool, and it has no wired layer2, then it might well have a second radio (or a second ESSID), to relay. But, it might also be connected to the wired network in the pool house. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From Ray.Bellis@nominet.org.uk Tue Oct 4 00:42:08 2011 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 D437C21F87D3 for ; Tue, 4 Oct 2011 00:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai2yPOb0hoAt for ; Tue, 4 Oct 2011 00:42:08 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id E90D621F84C2 for ; Tue, 4 Oct 2011 00:42:07 -0700 (PDT) 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-Transfer-Encoding:MIME-Version; b=vCNHITeLHy227BFQtPvkvoSS/zuinzPsRNOVgX0iCkvusCnGov+Naz66 lYBtoYWlggN1Sy6saakohgV+uVcFNVmBSY6bDK3qaIUzhBQ5FiPLjrzyz rbhvLcCyAWB16PR; 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=1317714312; x=1349250312; 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:=20List=20administrivia|Date:=20Tue,=204=20Oct =202011=2007:45:09=20+0000|Message-ID:=20<8B7F972437853B4 0865000D86857B1D118D8C476@wds-exc1.okna.nominet.org.uk> |To:=20"homenet@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable; bh=/WaB9jnKu043FLEWQDU8UD7HLnp84rVS39DGHUTnV2A=; b=fBhe4H+mVMkTbcCLI7ytfpj9RHAZbuAaDaUBKkF1I7iUCOQKXwWhwb+0 Ig/MB2i+Cdv3H2p1gWyuPHNKDvtrTvGjVMjbvxxrc1dCEg/qYqWHuJiCi yQ5MJrZq5E52IlT; X-IronPort-AV: E=Sophos;i="4.68,483,1312153200"; d="scan'208";a="35721771" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 04 Oct 2011 08:45:11 +0100 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%19]) with mapi; Tue, 4 Oct 2011 08:45:10 +0100 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: List administrivia Thread-Index: AcyCaYrOvj6KSDTET6OiEV1LacspaA== Date: Tue, 4 Oct 2011 07:45:09 +0000 Message-ID: <8B7F972437853B40865000D86857B1D118D8C476@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] List administrivia 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, 04 Oct 2011 07:42:08 -0000 Please trim the recipient lists on your replies to the list - we're getting= quite a few messages held up for moderation because they've hit the limit = on the number of recipients.=0A= =0A= thanks,=0A= =0A= Ray=0A= =0A= =0A= From c.chauvenet@watteco.com Tue Oct 4 00:46:17 2011 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 1DF5121F8D2C for ; Tue, 4 Oct 2011 00:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.133 X-Spam-Level: X-Spam-Status: No, score=-4.133 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KEm1oDRSfvi for ; Tue, 4 Oct 2011 00:46:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 11E8121F8D31 for ; Tue, 4 Oct 2011 00:46:16 -0700 (PDT) Received: from mail14-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Oct 2011 07:49:19 +0000 Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1-R.bigfish.com (Postfix) with ESMTP id BC60F198276; Tue, 4 Oct 2011 07:49:19 +0000 (UTC) X-SpamScore: -28 X-BigFish: VPS-28(zz9371Kc89bh168aJc85dh98dKzz1202hzz1033IL8275dhz2dh2a8h668h839h8aah) X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB025.red002.local; RD:none; EFVD:NLI X-FB-SS: 0,0,13, Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1 (MessageSwitch) id 1317714483588368_9787; Tue, 4 Oct 2011 07:48:03 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail14-ch1.bigfish.com (Postfix) with ESMTP id 0EEF4CF80BC; Tue, 4 Oct 2011 07:46:24 +0000 (UTC) Received: from IE2RD2HUB025.red002.local (213.199.187.153) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 4 Oct 2011 07:46:22 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB025.red002.local ([10.43.198.103]) with mapi; Tue, 4 Oct 2011 00:45:48 -0700 From: C Chauvenet To: Ulrich Herberg Date: Tue, 4 Oct 2011 00:45:50 -0700 Thread-Topic: [homenet] Wired vs wireless ... Thread-Index: AcyCaaGsZS5bE0hyTYynWKJtlXvo3w== Message-ID: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E89FEB6.3040904@freedesktop.org> <61E0CF30-12F1-4218-90AD-102A635775E6@tony.li> <4E8A08A1.7000106@freedesktop.org> <64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li> <4E8A10D2.1030105@freedesktop.org> <4E8A199B.1070607@raszuk.net> <4E8A1EE5.80509@riw.us> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_A7B765F31FB74CD6A252DB05DA1ABA5Cwattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: Russ White , "homenet@ietf.org" Subject: Re: [homenet] Wired vs wireless ... 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, 04 Oct 2011 07:46:17 -0000 --_000_A7B765F31FB74CD6A252DB05DA1ABA5Cwattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Wired or Wireless is not really the point. I think we should rather draw a line between the Lossy and the Very Reliabl= e Networks (which is often tight to the power/size/cost constraints). I think a routing protocol can run over wired or wireless links, as soon as= it is a route-over protocol. The real point is the set of requirements taken into considerations for the= design of the routing protocol. For instance, we use RPL over PLC (wired) and 802.15.4 (wireless) because t= hey both fall in the LLN category (which is indeed not restricted to wirele= ss links). To my mind it is clear that we have to use a route-over protocol if we cons= ider multiple technologies (which I believe is a correct assumption in a ho= me). Some examples to illustrate my opinion : Lossy Wired : Some PLC technologies (See AMI technologies). Reliable Wired : Ethernet Lossy Wireless : 802.15.4 Reliable Wireless : Wifi Finally, I really agree with a previous remark on the list who states that = the single magic routing protocol is hard to find. We may use some routing protocols, depending on the type of devices we thin= k will be used in the home. A remark about this statement : "I think OSPF or IS-IS (or even EIGRP) can be adapted to the low power/lossy network situation, it just takes some thought and care." This doesn't seems to be compliant with the protocol survey which has been = done by the ROLL WG : See Figure 1 here : http://tools.ietf.org/html/draft-ietf-roll-protocols-su= rvey-07#page-14 Best, C=E9dric. Le 3 oct. 2011 =E0 22:53, Ulrich Herberg a =E9crit : Hi, On Mon, Oct 3, 2011 at 1:45 PM, Russ White > wrote: Can you also say the opposite that rotocols developed for wireless work equally well also for wired environments ? If so let me ask why do we need both classes of routing protocols ? I have deployed OLSRv2 both on Ethernet and on wireless environments, without problems. I do not see a reason why OLSRv2 could not run in mixed environments. I would argue that the OSPF MANET extensions would work just as well for IS-IS or OSPF in both wirelss and wired networks. The OSPF MANET extensions would certainly be a valid alternative to consider. Which one performs better or is more suited (OLSRv2 / OSPF+MANET / ...) -- I don't know, that would be an interesting comparison. If not I am not sure homenet should focus on wireless router to router communication at all. Yes I am in favor of wired env with fiber or with nice cat 7 wiring between my routers. I am as well, but I think we should allow for both with a single protocol as much as possible. I agree. Not everyone likes long cables in a home environment. And having a single protocol would be indeed better. I think OSPF or IS-IS (or even EIGRP) can be adapted to the low power/lossy network situation, it just takes some thought and care. We have invested that thought and care in MANET for years now. I think it could be worth investing the suitability of the protocols developed in MANET (as well as the OSPF MANET extensions), before reinventing the wheel. Ulrich Russ _______________________________________________ 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 --_000_A7B765F31FB74CD6A252DB05DA1ABA5Cwattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 

Wired or Wireless is not really the point.
I think we should r= ather draw a line between the Lossy and the Very Reliable Networks (which i= s often tight to the power/size/cost constraints).

I think a routing protocol can run over wired or wireless links, as soon a= s it is a route-over protocol.
The real point is the set of requi= rements taken into considerations for the design of the routing protocol.

For instance, we use RPL over PLC (wired) and = 802.15.4 (wireless) because they both fall in the LLN category (which is in= deed not restricted to wireless links).

To m= y mind it is clear that we have to use a route-over protocol if we consider= multiple technologies (which I believe is a correct assumption in a home).=

Some examples to illustrate my opinion :

Lossy Wired : Some PLC technologies (See AMI technologies)= .
Reliable Wired : Ethernet
Lossy Wireless : 802.15.4
Reliable Wireless : Wifi

Finally, I reall= y agree with a previous remark on the list who states that the single magic= routing protocol is hard to find.
We may use some routing protoc= ols, depending on the type of devices we think will be used in the home.

A remark about this statement :

=
"I think OSPF or IS-IS (or even EIGRP) can
be adapted to the low power/lossy networ= k situation, it just takes some
t= hought and care."

This doesn'= t seems to be compliant with the protocol survey which has been done by the= ROLL WG : 


Best,

C=E9dric.

Le 3 oct. 2011 =E0 22:53, Ulrich Herberg a =E9crit :
<= br class=3D"Apple-interchange-newline">
Hi,
On Mon, Oct 3, 2011 at 1:45 PM, Russ White <russw@riw.us> wrote:

Can you also s= ay the opposite that rotocols developed for wireless work
<= /blockquote>
equally wel= l also for wired environments ? If so let me ask why do we
=
need both = classes of routing protocols ?

I have depl= oyed OLSRv2 both on Ethernet and on wireless environments,
without probl= ems. I do not see a reason why OLSRv2 could not run in
mixed environment= s.


I would argue that the OSPF MANET e= xtensions would work just as well for
IS-IS or OSPF in both wirelss and wired networks.

= The OSPF MANET extensions would certainly be a valid alternative to
cons= ider. Which one performs better or is more suited (OLSRv2 /
OSPF+MANET /= ...) -- I don't know, that would be an interesting
comparison.

<= blockquote type=3D"cite">
If not I am not sure homenet should focus on wireless ro= uter to router
communication at all. Yes I am in favor of wired env w= ith fiber or with
nice cat 7 wiring between my routers.

I am as well, but I think we should allow for both with a single<= br>
protocol as much as possible.
=

I agree. Not everyone likes long cables in a home environm= ent. And
having a single protocol would be indeed better.

I think OSPF or IS-IS (or even EIGRP) can
be adapted to the low power/lossy network situa= tion, it just takes some
thought = and care.

We have invested that thought and care in MAN= ET for years now. I think
it could be worth investing the suitability of= the protocols developed
in MANET (as well as the OSPF MANET extensions)= , before reinventing
the wheel.

Ulrich



Russ
=

______= _________________________________________
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

= --_000_A7B765F31FB74CD6A252DB05DA1ABA5Cwattecocom_-- From ray.bellis@mac.com Tue Oct 4 02:47:02 2011 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 9832F21F8A7B for ; Tue, 4 Oct 2011 02:47:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtas00vJxb2e for ; Tue, 4 Oct 2011 02:47:02 -0700 (PDT) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1E92321F8A62 for ; Tue, 4 Oct 2011 02:47:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.1.0.149] ([94.175.239.226]) by asmtp029.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LSJ00BZCCN5YI80@asmtp029.mac.com> for homenet@ietf.org; Tue, 04 Oct 2011 02:49:56 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-04_05:2011-10-04, 2011-10-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110040041 From: Ray Bellis Date: Tue, 04 Oct 2011 10:50:02 +0100 Message-id: <35BB2E87-E9E2-4816-8506-C686EC921D49@mac.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Mailman-Approved-At: Tue, 04 Oct 2011 02:51:49 -0700 Subject: [homenet] Interim update 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, 04 Oct 2011 09:50:29 -0000 - Architecture Draft I'd like to remind the group that the principle objective of the Interim Meeting this Thursday and Friday is to help establish consensus around the Architecture Draft (currently draft-chown-homenet-arch-00.txt). With that in mind, would attendees _please_ ensure that they're familiar with it so that we can make best use of our time. Feedback via the list for the benefit of non-attendees would also be much appreciated. - Dinner We will be having dinner at R2L - http://www.r2lrestaurant.com/ which (according to the Comcast folk) has a fantastic menu and great scenery of Philadelphia and is located in the Liberty Place towers. - Audio Stream There will be an audio stream available, and recordings available after the event too. Connection details will be sent to the list as soon as we have them. Mark and I are now both en-route to Philadelphia - I won't be back online until this evening (eastern time). thanks, Ray From henk@uijterwaal.nl Tue Oct 4 03:08:01 2011 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 4C7D421F8C52 for ; Tue, 4 Oct 2011 03:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1SQyofiHzVI for ; Tue, 4 Oct 2011 03:08:00 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9C31921F8C4E for ; Tue, 4 Oct 2011 03:08:00 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id p94AAX4t073174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Oct 2011 12:10:34 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4E8ADB98.7070207@uijterwaal.nl> Date: Tue, 04 Oct 2011 12:10:32 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [homenet] Question for you 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, 04 Oct 2011 10:08:01 -0000 On 03/10/2011 18:50, Lorenzo Colitti wrote: > On Mon, Oct 3, 2011 at 08:58, Randy Turner > wrote: > > I would hope that we would NOT be seriously considering OSPF or IS-IS in the > home...this seems like using a sledgehammer to kill an ant. > > > If the devices we're talking about have enough resources to run them, and they > have desirable properties that are useful in home networks, then what's the > problem with either of these? Home gateways these days are capable of 1Gbps > hardware forwarding and have pretty fast CPUs. The problem isn't the CPU but the memory. Vendors want to stick in as little (expensive) flash and RAM as possible, and don't want to spend a few $$ for a few spare meg's of memory that won't be used by most of the customers. I've created new images for these devices and whenever adding something, one also had to ask the question what to drop in order for the new code to fit. Adding memory generally wasn't an option. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From rdroms.ietf@gmail.com Tue Oct 4 03:55:27 2011 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 EC6B021F8C22 for ; Tue, 4 Oct 2011 03:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqYoUDcBYHAY for ; Tue, 4 Oct 2011 03:55:27 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 45B9621F8C0F for ; Tue, 4 Oct 2011 03:55:27 -0700 (PDT) Received: by qyk33 with SMTP id 33so217291qyk.10 for ; Tue, 04 Oct 2011 03:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=6pUqxXivNa92JAP2Qqze/EvOS5ovS+g0ETDVNa/8DfI=; b=Kn5NdDDnDl4x0CWx72lSVJGeDSfNVQtxsIEOLsoVtXVTFVVIShrxITv6oIS4tB3OoE nm8gdzXJrJyBNWIy+qXxx7eS7QhXHUhqjetxkhJ1Y4tHEWLnKiUsOgHpeznwecArk0Zm mvHpRUb+NAgioCweNvr0G+0kDv3nUCg/5P+7U= Received: by 10.229.19.81 with SMTP id z17mr841237qca.73.1317725910413; Tue, 04 Oct 2011 03:58:30 -0700 (PDT) Received: from che-vpn-cluster-2-139.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id gq3sm19316212qab.24.2011.10.04.03.58.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 03:58:29 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Oct 2011 06:58:27 -0400 References: <20111004105243.24576.42801.idtracker@ietfa.amsl.com> To: homenet@ietf.org Message-Id: <88E891D7-0353-47AB-93F2-575730598172@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [homenet] Fwd: I-D Action: draft-baker-homenet-prefix-assignment-00.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, 04 Oct 2011 10:55:28 -0000 This draft is intended as a starting point for discussion at the homenet = WG interim meeting of autonomous prefix delegation and assignment within = a small network. =20 - Ralph Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 4, 2011 6:52:43 AM EDT > To: i-d-announce@ietf.org > Subject: I-D Action: draft-baker-homenet-prefix-assignment-00.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : IPv6 Prefix Assignment in Small Networks > Author(s) : Fred Baker > Ralph Droms > Filename : draft-baker-homenet-prefix-assignment-00.txt > Pages : 12 > Date : 2011-10-04 >=20 > It is necessary to allocate prefixes in small networks, which = include > residential and Small Office/Home Office (SOHO) networks in a manner > that minimizes or eliminates manual configuration. This note > suggests an approach. >=20 > Requirements >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-baker-homenet-prefix-assignment-= 00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-baker-homenet-prefix-assignment-0= 0.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From fred@cisco.com Tue Oct 4 06:48:05 2011 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 A8CF521F8672; Tue, 4 Oct 2011 06:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.583 X-Spam-Level: X-Spam-Status: No, score=-104.583 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdY5NC5ayDim; Tue, 4 Oct 2011 06:48:05 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7F56521F8669; Tue, 4 Oct 2011 06:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1090; q=dns/txt; s=iport; t=1317736270; x=1318945870; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=vQ83kY8GgRcQFzfIt7WTzUTlxZXTCB3Z0gqj6+UsCQg=; b=iv6/W+53L4vBLSpDFwi0+wju2zFGLU8MOGb6FG0BkFIxDObcxfMg1r0k 2ub12289HzPVe+812GQqAdo0aoyxsw+ZFh8lUtG0A+sAfMQ/31zs9Uiiv mS5R0zvzY0cdKTs/MhpioiPNv7/KX3g06/q2SN74+QUpXGr/kuAwrAB+/ w=; X-IronPort-AV: E=Sophos;i="4.68,485,1312156800"; d="scan'208";a="290063" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-3.cisco.com with ESMTP; 04 Oct 2011 13:51:07 +0000 Received: from Freds-Computer.local (sin-vpn-client-16-76.cisco.com [10.68.16.76]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p94Dp51w004888; Tue, 4 Oct 2011 13:51:05 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 04 Oct 2011 21:51:06 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 04 Oct 2011 21:51:06 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 4 Oct 2011 21:50:29 +0800 Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 04 Oct 2011 06:52:02 -0700 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 04 Oct 2011 13:48:05 -0000 On Oct 4, 2011, at 12:50 AM, Lorenzo Colitti wrote: > For example, if there were a robust open-source version of IS-IS that = didn't take up too much RAM and flash, you could define TLVs to = implement zeroconf and you could get to something that works relatively = quickly. RFC 1453 specified a default OSPF configuration that my (ACC) Router = came up with by default. The only configuration necessary was to supply = IPv4 prefixes/addresses to the interfaces and to turn OSPF on. In the = context of a home, I suspect it would be pretty close. Fundamentals: = default values for most attributes are as specified in the OSPF RFC, the = metric is the duration of a bit in 10 ns units (which in LAN networks = becomes a hop count), and all interfaces are in area zero. Change things = to your heart's content, but the default configuration is one that = actually works for most purposes in a small network. I'll entertain = arguments that this doesn't address every possible configuration, but = for the networks we're discussing, I'll argue that its "close enough".= From chelliot@gmail.com Tue Oct 4 09:02:25 2011 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 59C2221F8AF5; Tue, 4 Oct 2011 09:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA7CZfMebOXR; Tue, 4 Oct 2011 09:02:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 982C221F8AF3; Tue, 4 Oct 2011 09:02:24 -0700 (PDT) Received: by gyd12 with SMTP id 12so776015gyd.31 for ; Tue, 04 Oct 2011 09:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=TdL/cCA51NYy0S/CMH8eR5GOlMHev5YnmPGSL7wJNHA=; b=jcaWCwjXwJlm0Z0lpBfl2ngq/VcU5YXhSQqBO7wRKEFIfiuS062BFsMA62u1hTFdBy SDZBaioPKdhhznnNa+UTbrZdfhst7L3t8rHsZw0H2ZACVavxTtiCvoOks1qoZLrEfYY8 UW/Q+qLy/Kue7iWcib/+Wc25sPM3gSW+Ir8QA= Received: by 10.236.181.196 with SMTP id l44mr7704235yhm.37.1317744329961; Tue, 04 Oct 2011 09:05:29 -0700 (PDT) Received: from [10.43.72.188] ([166.137.15.196]) by mx.google.com with ESMTPS id u66sm20061696yhu.13.2011.10.04.09.05.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 09:05:28 -0700 (PDT) Sender: Chris Elliott References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> In-Reply-To: <12856.1317691669@marajade.sandelman.ca> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Type: multipart/alternative; boundary=Apple-Mail-3-134710160 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (8L1) From: Chris Elliott Date: Tue, 4 Oct 2011 12:05:20 -0400 To: Michael Richardson Cc: "homenet@ietf.org" , MANET IETF , "robert@raszuk.net" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 04 Oct 2011 16:02:25 -0000 --Apple-Mail-3-134710160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 3, 2011, at 9:27 PM, Michael Richardson wrote: >=20 >>>>>> "Robert" =3D=3D Robert Raszuk writes: > Robert> Why a wireless access point at the pool has to also be a > Robert> router ? Isn't it sufficient to extend one or more layer 2 > Robert> to it ? >=20 > It's not much of an access point if it doesn't have a second interface, > is it? If it's out at the pool, and it has no wired layer2, then it > might well have a second radio (or a second ESSID), to relay. But, it > might also be connected to the wired network in the pool house. Bridging works fine between 802.11 and 802.1--or another 802.11 link. No rou= ting required. It works for the IETF meeting networks and pretty much how all Enterprise ge= ar is setup. Let's keep it simple and only route when we have to. Chris. -- Chris Elliott CCIE # 2013 R&S --Apple-Mail-3-134710160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 3, 2011, at 9:27 PM, Micha= el Richardson <mcr@sandelman.ca&g= t; wrote:

=
"Robert" =3D=3D Robert Raszuk <robert@raszuk.net> writes:
<= /blockquote>
  Robert> Why a wireless access point at th= e pool has to also be a
  Robert> router ? Isn't it sufficient to extend one or mor= e layer 2
 &nbs= p;Robert> to it ?
=
It's not much of an a= ccess point if it doesn't have a second interface,
is it?  If it's out at the pool, and it h= as no wired layer2, then it
might well have a second radio (or a second ESSID), to relay.  B= ut, it
might also be c= onnected to the wired network in the pool house.

Bridging works fine between 802.11 and 802.1--or another 8= 02.11 link. No routing required.

It works for the IETF meeting networks and pretty much how all Enterprise g= ear is setup.

Let's keep it simple and only route w= hen we have to.

Chris.

--<= /div>
Chris Elliott
CCIE # 2013 R&S

= --Apple-Mail-3-134710160-- From russw@riw.us Tue Oct 4 12:55:08 2011 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 A438F21F8EED for ; Tue, 4 Oct 2011 12:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+4F-HioOkMT for ; Tue, 4 Oct 2011 12:55:08 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1A28F21F8EEA for ; Tue, 4 Oct 2011 12:55:08 -0700 (PDT) Received: from 60-244-235-201.fibertel.com.ar ([201.235.244.60]:49465 helo=[192.168.2.127]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RBB80-00031w-4J for homenet@ietf.org; Tue, 04 Oct 2011 15:58:12 -0400 Message-ID: <4E8B654D.70506@riw.us> Date: Tue, 04 Oct 2011 15:58:05 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] [manet] Question for you 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, 04 Oct 2011 19:55:08 -0000 > Bridging works fine between 802.11 and 802.1--or another 802.11 link. No > routing required. > > It works for the IETF meeting networks and pretty much how all > Enterprise gear is setup. > > Let's keep it simple and only route when we have to. There is a strong argument to be made that routing is simpler in the mobile space than bridging is... And that routing to the edge in these cases will actually make interfacing with some of the complex edge interfaces likely to evolve in the long term much simpler, as well. While we might not like that someone could have a 3g connection and an 11n connection on the same laptop, or even on a single "pad," this is the reality. Apple's recent move to "cut off" purchases for "outside products" through "third party web sites," should show us that there might be a point where you must go through network a to get content from them, and network b to get content from them --which is already going to require routing at the end device, at any rate. IMHO, we should accept that routing is going to be mixed with bridging at the end node, and work around that reality. :-) Russ From nordmark@cisco.com Tue Oct 4 14:39:20 2011 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 101E021F8DB0 for ; Tue, 4 Oct 2011 14:39:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7tn+OiQOrl6 for ; Tue, 4 Oct 2011 14:39:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C0EB421F8D7E for ; Tue, 4 Oct 2011 14:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1672; q=dns/txt; s=iport; t=1317764536; x=1318974136; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=T3IBIHpHztmBCL/xnjsYoyJbpO7b6m7KBwczFp4S6i4=; b=mkifb27lDmf4zdJv58xQ0adwsv3vNtQP6wBk1SF5zu9lUm90c1cgDecn ZyZZpc/V7eBZAivXG4cENsKJiFOGSAtdpwpgDAfXl20BqdkF9nwkT6v9w q84X/T+1BIliGRzX7tVzX9B+UafsixYRl3kWpG82p6Q+iZlxgeQWy3F/k c=; X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208";a="5950687" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Oct 2011 21:42:16 +0000 Received: from [10.33.22.78] ([10.33.22.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p94LgFqV027255; Tue, 4 Oct 2011 21:42:15 GMT Message-ID: <4E8B7DCC.6040300@cisco.com> Date: Tue, 04 Oct 2011 14:42:36 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <20111004213641.13638.37341.idtracker@ietfa.amsl.com> In-Reply-To: <20111004213641.13638.37341.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111004213641.13638.37341.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] Fwd: New Version Notification for draft-chakrabarti-homenet-prefix-alloc-00.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, 04 Oct 2011 21:39:20 -0000 This draft argues for looking at the topologies that can be made to work with consumer IPv4 home routers/NATs, and specifies how DHCP prefix delegation can be done in a simple way in such networks. None of us authors will be at the interim meeting, but perhaps we can discuss this remotely if folks are interested. Erik -------- Original Message -------- Subject: New Version Notification for draft-chakrabarti-homenet-prefix-alloc-00.txt Date: Tue, 04 Oct 2011 14:36:41 -0700 From: internet-drafts@ietf.org To: nordmark@cisco.com CC: samita.chakrabarti@ericsson.com, nordmark@cisco.com, wassim.haddad@ericsson.com, suresh.krishnan@ericsson.com A new version of I-D, draft-chakrabarti-homenet-prefix-alloc-00.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-chakrabarti-homenet-prefix-alloc Revision: 00 Title: Simple Approach to Prefix Distribution in Basic Home Networks Creation date: 2011-10-04 WG ID: Individual Submission Number of pages: 24 Abstract: Modern IPv4 home networks are often configured with multi-level of NATs and Residential gateways to separate islands of networks used for different purposes. With the introduction of IPv6 home networks we'd like to be able to maintain the same topological freedom as we have with IPv4 but without requiring any IPv6 NATs. This document specifies the topological restrictions for what we term Basic Home Networks and specifies how DHCPv4 Prefix Delegation can be used to autoconfigure IPv6 address prefixes in such networks. The IETF Secretariat From radhika.r.roy.civ@mail.mil Tue Oct 4 08:04:10 2011 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 1F56421F8C0D; Tue, 4 Oct 2011 08:04:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXHA-zBdfEAM; Tue, 4 Oct 2011 08:04:09 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7D421F8BBD; Tue, 4 Oct 2011 08:04:08 -0700 (PDT) Received: from UCOLHP3B.easf.csd.disa.mil (131.64.100.151) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Oct 2011 10:07:07 -0500 Received: from UCOLHP4H.easf.csd.disa.mil ([169.254.6.67]) by UCOLHP3B.easf.csd.disa.mil ([131.64.100.151]) with mapi id 14.01.0323.003; Tue, 4 Oct 2011 10:07:05 -0500 From: "Roy, Radhika R USA CIV (US)" To: Fred Baker , Lorenzo Colitti Thread-Topic: [homenet] Question for you Thread-Index: AQHMgp1Epg4erVaUIEald7KjKxFOT5VsSKHw Date: Tue, 4 Oct 2011 15:07:05 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3AF3DD09@ucolhp4h.easf.csd.disa.mil> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 04 Oct 2011 14:40:02 -0700 Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , Randy Turner , MANET IETF , Mark Townsley , JP Vasseur , Acee Lindem , Qiong , "homenet@ietf.org" , "rtgwg@ietf.org" Subject: Re: [homenet] Question for you 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, 04 Oct 2011 15:04:10 -0000 Agreed. Another idea is this: Do we also need any features like mobile ad hoc netwo= rking (e.g. OLSR) in homenet? RRR=20 -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Fred Baker Sent: Tuesday, October 04, 2011 9:50 AM To: Lorenzo Colitti Cc: Pascal Thubert (pthubert); C Chauvenet; Randy Turner; MANET IETF; Mark = Townsley; JP Vasseur; Acee Lindem; Qiong; homenet@ietf.org; rtgwg@ietf.org Subject: Re: [homenet] Question for you On Oct 4, 2011, at 12:50 AM, Lorenzo Colitti wrote: > For example, if there were a robust open-source version of IS-IS that did= n't take up too much RAM and flash, you could define TLVs to implement zero= conf and you could get to something that works relatively quickly. RFC 1453 specified a default OSPF configuration that my (ACC) Router came u= p with by default. The only configuration necessary was to supply IPv4 pref= ixes/addresses to the interfaces and to turn OSPF on. In the context of a h= ome, I suspect it would be pretty close. Fundamentals: default values for m= ost attributes are as specified in the OSPF RFC, the metric is the duration= of a bit in 10 ns units (which in LAN networks becomes a hop count), and a= ll interfaces are in area zero. Change things to your heart's content, but = the default configuration is one that actually works for most purposes in a= small network. I'll entertain arguments that this doesn't address every po= ssible configuration, but for the networks we're discussing, I'll argue tha= t its "close enough". _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From albert.e.manfredi@boeing.com Tue Oct 4 12:12:58 2011 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 9DE1B21F8F2A; Tue, 4 Oct 2011 12:12:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59IE4Eyy81K2; Tue, 4 Oct 2011 12:12:58 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 14D9121F8F29; Tue, 4 Oct 2011 12:12:58 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p94JFuqY013390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Oct 2011 12:16:01 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p94JFuBk009215; Tue, 4 Oct 2011 12:15:56 -0700 (PDT) Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p94JFlL9008835 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 4 Oct 2011 12:15:55 -0700 (PDT) Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-05.mw.nos.boeing.com (134.57.119.160) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 4 Oct 2011 14:15:47 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Tue, 4 Oct 2011 14:15:47 -0500 From: "Manfredi, Albert E" To: Michael Richardson , "robert@raszuk.net" Date: Tue, 4 Oct 2011 14:15:44 -0500 Thread-Topic: [homenet] [manet] Question for you Thread-Index: AcyCNxgRBuUVaon0Tb6zv65PHfvi/wAkiNgQ Message-ID: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> In-Reply-To: <12856.1317691669@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18426.000 x-tm-as-result: No--49.732200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 04 Oct 2011 14:40:01 -0700 Cc: "homenet@ietf.org" , MANET IETF , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 04 Oct 2011 19:12:58 -0000 > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Monday, October 03, 2011 9:28 PM > To: robert@raszuk.net > Cc: C Chauvenet; Randy Turner; MANET IETF; Mark Townsley; JP Vasseur; > Ulrich Herberg; Acee Lindem; Qiong; homenet@ietf.org; rtgwg@ietf.org > Subject: Re: [homenet] [manet] Question for you >=20 >=20 > >>>>> "Robert" =3D=3D Robert Raszuk writes: > Robert> Why a wireless access point at the pool has to also be a > Robert> router ? Isn't it sufficient to extend one or more layer 2 > Robert> to it ? >=20 > It's not much of an access point if it doesn't have a second interface, > is it? If it's out at the pool, and it has no wired layer2, then it > might well have a second radio (or a second ESSID), to relay. But, it > might also be connected to the wired network in the pool house. I don't think that's the answer. It would be perfectly plausible to connect= more the 802.11 access point on the same IP subnet as the wired network, o= r even more than one access point, all tied together at layer 2. For whatever reason, the 802.11 access points you can actually buy on the m= arket seem to incorporate a router. Seems really silly, when most homes con= nect one of these to a cable or DSL modem, both of which are also routers, = but there you have it. You end up with a stack of private IP address subnet= s. Bert From chelliot@gmail.com Tue Oct 4 14:59:32 2011 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 CB81E21F8DBF for ; Tue, 4 Oct 2011 14:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LluJWShl6kqZ for ; Tue, 4 Oct 2011 14:59:32 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA7C621F8DA2 for ; Tue, 4 Oct 2011 14:59:31 -0700 (PDT) Received: by eye4 with SMTP id 4so1062132eye.31 for ; Tue, 04 Oct 2011 15:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=iRaBL2wWz31RpAPMnxO54UsPwmxBOW0KVQUHUoSfKt8=; b=ppebAxeEoEsdiucyLzoYyPj8Ewc98h5V1dd9ce3ZDBAXiIpzRsDY6UDvSjcnJlMUXW thAx4+o6E3gaGp6o7lnnRhx64+YmNefEsPu/GXukpolROGYTztjGRgUaj1mOj4QXzi8U 2Ik+/KrNWojjtU5rYo9g7tX1GPE4UEzY2Qd90= Received: by 10.213.10.67 with SMTP id o3mr82ebo.95.1317765757196; Tue, 04 Oct 2011 15:02:37 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.213.29.207 with HTTP; Tue, 4 Oct 2011 15:02:17 -0700 (PDT) In-Reply-To: <4E8B654D.70506@riw.us> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> <4E8B654D.70506@riw.us> From: Chris Elliott Date: Wed, 5 Oct 2011 06:02:17 +0800 X-Google-Sender-Auth: OqR4WwkDLsQFfuyg_yZVII0qCXM Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=000e0cd136f6dad8e204ae803fdc Cc: homenet@ietf.org Subject: Re: [homenet] [manet] Question for you X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 21:59:32 -0000 --000e0cd136f6dad8e204ae803fdc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 5, 2011 at 3:58 AM, Russ White wrote: > > > Bridging works fine between 802.11 and 802.1--or another 802.11 link. No > > routing required. > > > > It works for the IETF meeting networks and pretty much how all > > Enterprise gear is setup. > > > > Let's keep it simple and only route when we have to. > > There is a strong argument to be made that routing is simpler in the > mobile space than bridging is... And that routing to the edge in these > cases will actually make interfacing with some of the complex edge > interfaces likely to evolve in the long term much simpler, as well. > > While we might not like that someone could have a 3g connection and an > 11n connection on the same laptop, or even on a single "pad," this is > the reality. Apple's recent move to "cut off" purchases for "outside > products" through "third party web sites," should show us that there > might be a point where you must go through network a to get content from > them, and network b to get content from them --which is already going to > require routing at the end device, at any rate. > > IMHO, we should accept that routing is going to be mixed with bridging > at the end node, and work around that reality. > I absolutely agree you need routing. However, I disagree that your pool AP needs to route, as Michael postulated. Keep routing in the core, or as needed in the case of multi-homed end devices. However, that pool AP may need access to several subnets. I want my primary home network, my enterprise home network, and my guest network all accessible as SSIDs at that pool AP. That means trunking back to the home router, in my mind. I don't see any references to VLANs or any form of trunking in the Homenet drafts or the mailing list archives. Am I missing something? Chris. > :-) > > Russ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Chris Elliott chelliot@pobox.com CCIE # 2013 R&S --000e0cd136f6dad8e204ae803fdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 3:58 AM, Russ White <russw@riw.us> wrote:<= br>

> Bridging works fine between 802.11 and 802.1--or another 802.11 link. = No
> routing required.
>
> It works for the IETF meeting networks and pretty much how all
> Enterprise gear is setup.
>
> Let's keep it simple and only route when we have to.

There is a strong argument to be made that routing is simpler in the<= br> mobile space than bridging is... And that routing to the edge in these
cases will actually make interfacing with some of the complex edge
interfaces likely to evolve in the long term much simpler, as well.

While we might not like that someone could have a 3g connection and an
11n connection on the same laptop, or even on a single "pad," thi= s is
the reality. Apple's recent move to "cut off" purchases for &= quot;outside
products" through "third party web sites," should show us th= at there
might be a point where you must go through network a to get content from them, and network b to get content from them --which is already going to require routing at the end device, at any rate.

IMHO, we should accept that routing is going to be mixed with bridging
at the end node, and work around that reality.

I absolutely agree you need routing. However, I disagree that your = pool AP
needs to route, as Michael postulated. Keep routing in th= e core, or as needed
in the case of multi-homed end devices.

Howev= er, that pool AP may need access to several subnets. I want my
pr= imary home network, my enterprise home network, and my guest network
all accessible as SSIDs at that pool AP. That means trunking back to t= he
home router, in my mind. I don't see any references to VLA= Ns or any form
of trunking in the Homenet drafts or the mailing l= ist archives. Am I missing
something?

Chris.
=A0
:-)

Russ

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



--
= Chris Elliott
ch= elliot@pobox.com
CCIE # 2013 R&S --000e0cd136f6dad8e204ae803fdc-- From chelliot@gmail.com Tue Oct 4 15:07:07 2011 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 77E7B21F8D76; Tue, 4 Oct 2011 15:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlGsC55IH8Pg; Tue, 4 Oct 2011 15:07:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD9E021F8D7F; Tue, 4 Oct 2011 15:07:05 -0700 (PDT) Received: by eye4 with SMTP id 4so1068002eye.31 for ; Tue, 04 Oct 2011 15:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DlKTZc4LxgLDUNfML/tAzte5fxeekVt14Lh5qHff3vA=; b=FGUDzDroCzqOQ6cMAQTFW0maSz+pzC3a4loojHZPsJ8QZ0v/L3mNjAIGopn4bqv/4v D206gyYsm3yKGSB2Rl0MEvoO1nTrPSeViXwC5Ltdynhp7jZCkJlUGpaqL4vL/tnxHoQT aI9EvdhPGdoT/qlkESvT74isLRll5yF8IUCA0= Received: by 10.213.2.74 with SMTP id 10mr1007495ebi.57.1317766211356; Tue, 04 Oct 2011 15:10:11 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.213.29.207 with HTTP; Tue, 4 Oct 2011 15:09:50 -0700 (PDT) In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> From: Chris Elliott Date: Wed, 5 Oct 2011 06:09:50 +0800 X-Google-Sender-Auth: 6n6KW6p5C_OQCV4i-TpVgYcZb4A Message-ID: To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=0015174478f2ecc75904ae805a15 Cc: "homenet@ietf.org" , MANET IETF , Michael Richardson , "robert@raszuk.net" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:07:07 -0000 --0015174478f2ecc75904ae805a15 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 5, 2011 at 3:15 AM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > > Of Michael Richardson > > It's not much of an access point if it doesn't have a second interface, > > is it? If it's out at the pool, and it has no wired layer2, then it > > might well have a second radio (or a second ESSID), to relay. But, it > > might also be connected to the wired network in the pool house. > > I don't think that's the answer. It would be perfectly plausible to connect > more the 802.11 access point on the same IP subnet as the wired network, or > even more than one access point, all tied together at layer 2. > > For whatever reason, the 802.11 access points you can actually buy on the > market seem to incorporate a router. Seems really silly, when most homes > connect one of these to a cable or DSL modem, both of which are also > routers, but there you have it. You end up with a stack of private IP > address subnets. > Often you can buy an access point or a wireless router. Many wireless routers have several switched Ethernet ports and a single "WAN" Ethernet port. Just don't use the "WAN" port and you're bridged. And some wireless routers (the Apple Airport series, for example) allow you to choose the mode they run in. They will bridge just fine, if you configure them that way. Of course, for a home network, routing and bridging and trunks and multiple SSIDs etc. all need to be configured automatically to a sane state. Two switches or a router and a switch can automatically trunk if they use a L2 discovery protocol, as can and AP. That same AP can then expose the VLANs on that trunk as separate SSIDs. All of this does not seem to be covered by the existing drafts. Are we assuming someone else will do this work or are we just interested in IPv6 and up? Chris. > Bert > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Chris Elliott chelliot@pobox.com CCIE # 2013 R&S --0015174478f2ecc75904ae805a15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 5, 2011 at 3:15 AM, Manfredi, Albert E <albert.e.manfredi@boeing.com<= /a>> wrote:
> From: rtgwg-bounces@ietf.org= [mailto:rtgwg-bounces@ietf.o= rg] On Behalf
> Of Michael Richardson
> It's not much of an access point if it doesn't have a second i= nterface,
> is it? =A0If it's out at the pool, and it has no wired layer2, the= n it
> might well have a second radio (or a second ESSID), to relay. =A0But, = it
> might also be connected to the wired network in the pool house.

I don't think that's the answer. It would be perfectly plausi= ble to connect more the 802.11 access point on the same IP subnet as the wi= red network, or even more than one access point, all tied together at layer= 2.

For whatever reason, the 802.11 access points you can actually buy on the m= arket seem to incorporate a router. Seems really silly, when most homes con= nect one of these to a cable or DSL modem, both of which are also routers, = but there you have it. You end up with a stack of private IP address subnet= s.

Often you can buy an access point or a wir= eless router. Many wireless routers have several switched Ethernet ports an= d a single "WAN" Ethernet port. Just don't use the "WAN&= quot; port and you're bridged. And some wireless routers (the Apple Air= port series, for example) allow you to choose the mode they run in. They wi= ll bridge just fine, if you configure them that way.

Of course, for a home network, routing and bridging and= trunks and multiple SSIDs etc. all need to be configured automatically to = a sane state. Two switches or a router and a switch can automatically trunk= if they use a L2 discovery protocol, as can and AP. That same AP can then = expose the VLANs on that trunk as separate SSIDs.

All of this does not seem to be covered by the existing= drafts. Are we assuming someone else will do this work or are we just inte= rested in IPv6 and up?

Chris.
=A0
Bert

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



--
= Chris Elliott
chelliot@pobox.com
CCIE # 2013 R&S --0015174478f2ecc75904ae805a15-- From jhw@apple.com Tue Oct 4 16:15:00 2011 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 3B3A021F8F59 for ; Tue, 4 Oct 2011 16:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.61 X-Spam-Level: X-Spam-Status: No, score=-106.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LRFfxvJ6ZWl for ; Tue, 4 Oct 2011 16:14:59 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id A232921F8F55 for ; Tue, 4 Oct 2011 16:14:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LSK005T4E04J070@mail-out.apple.com> for homenet@ietf.org; Tue, 04 Oct 2011 16:17:31 -0700 (PDT) X-AuditID: 11807136-b7c7fae00000458f-f6-4e8b9913bf45 Received: from ba0301b-dhcp202.apple.com (ba0301b-dhcp202.apple.com [17.193.15.202]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 44.4A.17807.3199B8E4; Tue, 04 Oct 2011 16:38:59 -0700 (PDT) From: james woodyatt In-reply-to: <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> Date: Tue, 04 Oct 2011 16:17:31 -0700 Message-id: <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1400) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42IRPMh/Sld4ZrefQcc1bov3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoErY+FL24J/YhX3Lk5mbWDcI9TFyMkhIWAi0TLtPCuELSZx4d56 ti5GLg4hgVVMEq2ta5hAEswCWhI3/r0Es3kFDCXu/ZzA2MXIwSEsYCvR/toQJMwmoCLx7fJd sBJOgTCJXdsvgM1kAYq/efSfBWKMtsSyha+ZIcbYSMyf0MwOYgsJTGCUOHKwBmSkiICIRPP0 UIhzZCU2PLvNPoGRbxaSI2YhOWIWkqkLGJlXMQoWpeYkVhqa6iUWFOSk6iXn525iBAVRQ6HZ DsYdf+UOMQpwMCrx8K4I6PYTYk0sK67MPcQowcGsJMK7+UOXnxBvSmJlVWpRfnxRaU5q8SFG aQ4WJXHe7u8tfkIC6YklqdmpqQWpRTBZJg5OqQZGs7fBMdujN+tciUp7tfDpA94ZfokCkS+3 H1/+/lK/mWf7N2/z7TMPfNkdKeh5atLifAerJKWbov5hR36/mdj409IlOCnmr0fd3XfqLTqL 5l/erql+QuniwUlnW62uXvT/NH3Wz576W1KX/1wNO3t4H9ejfVm9mRLKV8VmaLX1PDI9vmbh H+uF35VYijMSDbWYi4oTARcQRr8eAgAA Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 04 Oct 2011 23:15:00 -0000 On Oct 3, 2011, at 9:00 PM, Thomas Herbst wrote: > > There will be wide area network providers who interwork with the home network but do not provide global connectivity. > Two mentioned so far are utility networks and 3g providers. One of the outputs of the wg should be to define how they should be configured to perform their role without messing up Internet communication. Those utility networks have a fundamental problem that I contend is beyond the scope and charter of HOMENET. Utility networks of that sort do not provide transit to the Internet default-free zone. They must therefore obtain their routes to residential networks bilaterally. This implies that these utility networks could be-- and would do well to be-- numbered with ULA prefixes, and that they should use of an exterior gateway protocol at their border with residential networks so that each home network can advertise, into the utility network, its list of globally assigned prefixes that it obtains from Real Internet Service Providers. Yes, the scale of the routing problem faced by these utility networks is hard. No, I don't think they're going to be able to solve it adequately. This is-- however-- not our problem. It's theirs. They would not have this problem if they engineered their networks differently, i.e. to rely on real Internet service providers to provide transit through the default-free zone between their equipment in residential deployments and their equipment in their data centers. This is what EVERYONE ELSE in the world does, and it works pretty well. > A wg Chair from the Internet area did accuse me of "breaking the Internet model" because the utility networks my company builds do not provide global connectivity to users with our 100kb to the node. That's really not the problem, if you want my humble opinion. The problem, I would say, is that these utility networks insist on extending their private routing domains into our home networks where they don't belong and they aren't welcome. On Oct 3, 2011, at 6:46 PM, Erik Nordmark wrote: > [...] > 6. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but the application-layer content is completely different (e.g., a "subscriber" view when connecting over the ISP-A connection). This is the basic problem faced by any multi-homed host, e.g. a personal computer with a 3G interface and a Wi-fi interface that are simultaneously active, along with a split-tunnel VPN interface [or three] running on one or both interfaces. It is a problem for host operating systems and applications developers. I suggest HOMENET should steer well clear of it, and just about every related problem that is too easily conflated with it. -- james woodyatt member of technical staff, core os networking From mark@townsley.net Tue Oct 4 18:20:59 2011 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 7CB9321F8D39 for ; Tue, 4 Oct 2011 18:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn89YXW6llto for ; Tue, 4 Oct 2011 18:20:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE121F8D37 for ; Tue, 4 Oct 2011 18:20:58 -0700 (PDT) Received: by vws5 with SMTP id 5so1162412vws.31 for ; Tue, 04 Oct 2011 18:24:05 -0700 (PDT) Received: by 10.52.91.72 with SMTP id cc8mr1929103vdb.43.1317777844791; Tue, 04 Oct 2011 18:24:04 -0700 (PDT) Received: from dhcp184-49-148-184.whfp.phl.wayport.net (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id jb5sm19008024vdb.14.2011.10.04.18.24.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 18:24:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4E8A658B.9060200@cisco.com> Date: Tue, 4 Oct 2011 21:24:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F2EB2F6-A190-4CDC-B162-6F15BA3142AE@townsley.net> References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , Tim Chown , homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 05 Oct 2011 01:20:59 -0000 Homenet is concerned with how to make the network in the home work, so = what would happen today if I took two routers, connected them to two = IPv6-enabled ISPs, and then connected them to the same LAN in the home? = Most residential ISPs support source-address filtering today (at least = in IPv4, and in every IPv6 design I have ever seen), so your #2 seems to = be the most likely starting point.=20 Now the question becomes whether the routers take over and try to keep a = single prefix within the home and be smart about what traffic goes = where, or allow the two prefixes to be advertised and punt the = multihoming problem to the hosts. If we let the hosts handle it, I have = to say it is tempting to continuing punting the problem up the stack and = make this a transport issue rather than an IP issue.... - Mark On Oct 4, 2011, at 3:46 AM, Erik Nordmark wrote: > On 9/21/11 1:19 PM, Ray Hunter wrote: >> 1) I contend that multi-homing is probably going to become the "norm" = in >> Europe by 2022, due to The European Electricity and Gas Directive. = That >> corresponds at least to picture 4, if not more. >=20 > If we believe that multi-homing will be more common, then I think we = need to understand what the constraints are for the multihoming in = particular as this relates to walled gardens. I can see many different = possibilities, which imply different requirements. >=20 > 1. Just two paths to the Internet; the home gets one PA prefix from = each ISP. >=20 > 2. Like #1 but in addition the ISPs run ingress filtering so that the = source address in a packet from the home has to match the prefix that = ISP delegated. >=20 > 3. Like #1, but there are QoS guarantees for traffic local to an ISP. = Thus a host in the home can connect to foo.ispA.net over either ISP-A or = ISP-B, but gets better voice/video quality when doing it over ISP-A's = connection. >=20 > 4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, = but fails (NXDOMAIN) when asking ISP-B. >=20 > 5. The lookup of foo.ispA.net works over either DNS and returns the = same IP address, but fails (due to firewalls) for packets that are sent = out via ISP-B. >=20 > 6. The lookup of foo.ispA.net works over either DNS and returns the = same IP address, but the application-layer content is completely = different (e.g., a "subscriber" view when connecting over the ISP-A = connection). >=20 > 7. The lookup of foo.ispA.net returns different IP addresses when = asking ISP-A vs. ISP-B. >=20 >=20 > Do we really want to solve all those problems in homenet? We can't = tell the difference between behavior #1 and #6 at the IP layer. >=20 > Erik > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From marka@isc.org Tue Oct 4 19:27:30 2011 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 7E6C621F8B26 for ; Tue, 4 Oct 2011 19:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KAOv57buc2u for ; Tue, 4 Oct 2011 19:27:29 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A452121F8B02 for ; Tue, 4 Oct 2011 19:27:29 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 5B1E3C9423; Wed, 5 Oct 2011 02:30:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CBF6E216C36; Wed, 5 Oct 2011 02:30:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7842614A1E90; Wed, 5 Oct 2011 13:30:18 +1100 (EST) To: Mark Townsley From: Mark Andrews References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <1F2EB2F6-A190-4CDC-B162-6F15BA3142AE@townsley.net> In-reply-to: Your message of "Tue, 04 Oct 2011 21:24:33 +0200." <1F2EB2F6-A190-4CDC-B162-6F15BA3142AE@townsley.net> Date: Wed, 05 Oct 2011 13:30:18 +1100 Message-Id: <20111005023018.7842614A1E90@drugs.dv.isc.org> Cc: Ray Hunter , Erik Nordmark , homenet@ietf.org, Tim Chown Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 05 Oct 2011 02:27:30 -0000 In message <1F2EB2F6-A190-4CDC-B162-6F15BA3142AE@townsley.net>, Mark Townsley w rites: > > Homenet is concerned with how to make the network in the home work, so what w > ould happen today if I took two routers, connected them to two IPv6-enabled I > SPs, and then connected them to the same LAN in the home? Most residential IS > Ps support source-address filtering today (at least in IPv4, and in every IPv > 6 design I have ever seen), so your #2 seems to be the most likely starting p > oint. > > Now the question becomes whether the routers take over and try to keep a sing > le prefix within the home and be smart about what traffic goes where, or allo > w the two prefixes to be advertised and punt the multihoming problem to the h > osts. If we let the hosts handle it, I have to say it is tempting to continui > ng punting the problem up the stack and make this a transport issue rather th > an an IP issue.... > > - Mark Multiple prefixes with the hosts maintaining a default route(s) per prefix. > On Oct 4, 2011, at 3:46 AM, Erik Nordmark wrote: > > > On 9/21/11 1:19 PM, Ray Hunter wrote: > >> 1) I contend that multi-homing is probably going to become the "norm" in > >> Europe by 2022, due to The European Electricity and Gas Directive. That > >> corresponds at least to picture 4, if not more. > > > > If we believe that multi-homing will be more common, then I think we need t > o understand what the constraints are for the multihoming in particular as th > is relates to walled gardens. I can see many different possibilities, which i > mply different requirements. > > > > 1. Just two paths to the Internet; the home gets one PA prefix from each IS > P. > > > > 2. Like #1 but in addition the ISPs run ingress filtering so that the sourc > e address in a packet from the home has to match the prefix that ISP delegate > d. > > > > 3. Like #1, but there are QoS guarantees for traffic local to an ISP. Thus > a host in the home can connect to foo.ispA.net over either ISP-A or ISP-B, b > ut gets better voice/video quality when doing it over ISP-A's connection. > > > > 4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, but f > ails (NXDOMAIN) when asking ISP-B. > > > > 5. The lookup of foo.ispA.net works over either DNS and returns the same IP > address, but fails (due to firewalls) for packets that are sent out via ISP- > B. > > > > 6. The lookup of foo.ispA.net works over either DNS and returns the same IP > address, but the application-layer content is completely different (e.g., a > "subscriber" view when connecting over the ISP-A connection). > > > > 7. The lookup of foo.ispA.net returns different IP addresses when asking IS > P-A vs. ISP-B. > > > > > > Do we really want to solve all those problems in homenet? We can't tell the > difference between behavior #1 and #6 at the IP layer. > > > > Erik > > _______________________________________________ > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nordmark@cisco.com Tue Oct 4 19:45:40 2011 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 57F0621F8BEC for ; Tue, 4 Oct 2011 19:45:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbkNJYCdRJPB for ; Tue, 4 Oct 2011 19:45:39 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7724321F8BDC for ; Tue, 4 Oct 2011 19:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=3756; q=dns/txt; s=iport; t=1317782926; x=1318992526; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q1B6bmYW5eU/ExB6zifsbKbPNe809ZGr/6WyeYdQqwo=; b=Z0LXCX4mtGSJV4QiSB5Cz4jm2KF3YMgMULFvilw7DdOx+q/UkfzXiT1x E5IB1eBVGNwN7QN1WH2XZPiNosH+E+Oq2ZDB3vhSmHgVJlEzC2hpU0VUh aOElk7Y0CCFvdhgOjdlm23xCWITTNR1Rugl7RwatkEc/JbhNVif30QhmY k=; X-IronPort-AV: E=Sophos;i="4.68,489,1312156800"; d="scan'208";a="5992357" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 05 Oct 2011 02:48:45 +0000 Received: from [10.0.1.12] (sjc-vpn5-1604.cisco.com [10.21.94.68]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p952mjpn029606; Wed, 5 Oct 2011 02:48:45 GMT Message-ID: <4E8BC5A3.5040803@cisco.com> Date: Tue, 04 Oct 2011 19:49:07 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Townsley References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <1F2EB2F6-A190-4CDC-B162-6F15BA3142AE@townsley.net> In-Reply-To: <1F2EB2F6-A190-4CDC-B162-6F15BA3142AE@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Hunter , Tim Chown , homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 05 Oct 2011 02:45:40 -0000 On 10/4/11 12:24 PM, Mark Townsley wrote: > > Homenet is concerned with how to make the network in the home work, so what would happen today if I took two routers, connected them to two IPv6-enabled ISPs, and then connected them to the same LAN in the home? Most residential ISPs support source-address filtering today (at least in IPv4, and in every IPv6 design I have ever seen), so your #2 seems to be the most likely starting point. If a home network is multi-homed, then I suspect we'd need to solve at least #2. But what if it turns out that we do that and the real problem that needs to be solved is walled gardens that behave as #6? Then our solution to #2 doesn't do any good. Hence I think we need to write down the requirements around home multihoming and if we are going to dismiss 4-7 below we'd better have a good argument why those are a bad idea. > Now the question becomes whether the routers take over and try to keep a single prefix within the home and be smart about what traffic goes where, or allow the two prefixes to be advertised and punt the multihoming problem to the hosts. If we let the hosts handle it, I have to say it is tempting to continuing punting the problem up the stack and make this a transport issue rather than an IP issue.... For #2 I can see us exploring network-layer solutions like RFC6296. But for #3-7 that might not help. I think we had a discussion about application awareness of addresses and topology a while back (the IPv6 site-local debate) which seemed to indicate that applications don't want to deal with this. I could be that #4-7 are a bad idea and inconsistent with the architectural assumptions we make, but the IETF hasn't tried to make that statement AFAIK. Erik > - Mark > > > On Oct 4, 2011, at 3:46 AM, Erik Nordmark wrote: > >> On 9/21/11 1:19 PM, Ray Hunter wrote: >>> 1) I contend that multi-homing is probably going to become the "norm" in >>> Europe by 2022, due to The European Electricity and Gas Directive. That >>> corresponds at least to picture 4, if not more. >> >> If we believe that multi-homing will be more common, then I think we need to understand what the constraints are for the multihoming in particular as this relates to walled gardens. I can see many different possibilities, which imply different requirements. >> >> 1. Just two paths to the Internet; the home gets one PA prefix from each ISP. >> >> 2. Like #1 but in addition the ISPs run ingress filtering so that the source address in a packet from the home has to match the prefix that ISP delegated. >> >> 3. Like #1, but there are QoS guarantees for traffic local to an ISP. Thus a host in the home can connect to foo.ispA.net over either ISP-A or ISP-B, but gets better voice/video quality when doing it over ISP-A's connection. >> >> 4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, but fails (NXDOMAIN) when asking ISP-B. >> >> 5. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but fails (due to firewalls) for packets that are sent out via ISP-B. >> >> 6. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but the application-layer content is completely different (e.g., a "subscriber" view when connecting over the ISP-A connection). >> >> 7. The lookup of foo.ispA.net returns different IP addresses when asking ISP-A vs. ISP-B. >> >> >> Do we really want to solve all those problems in homenet? We can't tell the difference between behavior #1 and #6 at the IP layer. >> >> Erik >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > From jmh@joelhalpern.com Tue Oct 4 20:02:06 2011 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 7854821F8ACE for ; Tue, 4 Oct 2011 20:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IssZ08cF-pwg for ; Tue, 4 Oct 2011 20:02:05 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2221F8ACA for ; Tue, 4 Oct 2011 20:02:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6D0E14300D2; Tue, 4 Oct 2011 20:05:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 12FFD430080; Tue, 4 Oct 2011 20:05:11 -0700 (PDT) Message-ID: <4E8BC966.80902@joelhalpern.com> Date: Tue, 04 Oct 2011 23:05:10 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Erik Nordmark References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <1F2EB2F6-A190-4CDC-B162-6F15BA3142AE@townsley.net> <4E8BC5A3.5040803@cisco.com> In-Reply-To: <4E8BC5A3.5040803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Hunter , Tim Chown , Mark Townsley , homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 05 Oct 2011 03:02:06 -0000 Problem #2 (connectivity to two ISPs with different PA assignments and source address filtering) does seem forth addressing... if we can. Standardizing and mandating NPT66 (RFC 6296, not standards track) would seem highly undesirable. However, so are all the other answers I know of, such as source address sensitive routing. As for the later cases, while folks will build that, I think that solutions for those are probably better defined in places that can at least discuss business tradeoffs. Yours, Joel M. Halpern On 10/4/2011 10:49 PM, Erik Nordmark wrote: > On 10/4/11 12:24 PM, Mark Townsley wrote: >> >> Homenet is concerned with how to make the network in the home work, so >> what would happen today if I took two routers, connected them to two >> IPv6-enabled ISPs, and then connected them to the same LAN in the >> home? Most residential ISPs support source-address filtering today (at >> least in IPv4, and in every IPv6 design I have ever seen), so your #2 >> seems to be the most likely starting point. > > If a home network is multi-homed, then I suspect we'd need to solve at > least #2. > > But what if it turns out that we do that and the real problem that needs > to be solved is walled gardens that behave as #6? Then our solution to > #2 doesn't do any good. > > Hence I think we need to write down the requirements around home > multihoming and if we are going to dismiss 4-7 below we'd better have a > good argument why those are a bad idea. > >> Now the question becomes whether the routers take over and try to keep >> a single prefix within the home and be smart about what traffic goes >> where, or allow the two prefixes to be advertised and punt the >> multihoming problem to the hosts. If we let the hosts handle it, I >> have to say it is tempting to continuing punting the problem up the >> stack and make this a transport issue rather than an IP issue.... > > For #2 I can see us exploring network-layer solutions like RFC6296. > But for #3-7 that might not help. > > I think we had a discussion about application awareness of addresses and > topology a while back (the IPv6 site-local debate) which seemed to > indicate that applications don't want to deal with this. I could be that > #4-7 are a bad idea and inconsistent with the architectural assumptions > we make, but the IETF hasn't tried to make that statement AFAIK. > > Erik > >> - Mark >> >> >> On Oct 4, 2011, at 3:46 AM, Erik Nordmark wrote: >> >>> On 9/21/11 1:19 PM, Ray Hunter wrote: >>>> 1) I contend that multi-homing is probably going to become the >>>> "norm" in >>>> Europe by 2022, due to The European Electricity and Gas Directive. That >>>> corresponds at least to picture 4, if not more. >>> >>> If we believe that multi-homing will be more common, then I think we >>> need to understand what the constraints are for the multihoming in >>> particular as this relates to walled gardens. I can see many >>> different possibilities, which imply different requirements. >>> >>> 1. Just two paths to the Internet; the home gets one PA prefix from >>> each ISP. >>> >>> 2. Like #1 but in addition the ISPs run ingress filtering so that the >>> source address in a packet from the home has to match the prefix that >>> ISP delegated. >>> >>> 3. Like #1, but there are QoS guarantees for traffic local to an ISP. >>> Thus a host in the home can connect to foo.ispA.net over either ISP-A >>> or ISP-B, but gets better voice/video quality when doing it over >>> ISP-A's connection. >>> >>> 4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, >>> but fails (NXDOMAIN) when asking ISP-B. >>> >>> 5. The lookup of foo.ispA.net works over either DNS and returns the >>> same IP address, but fails (due to firewalls) for packets that are >>> sent out via ISP-B. >>> >>> 6. The lookup of foo.ispA.net works over either DNS and returns the >>> same IP address, but the application-layer content is completely >>> different (e.g., a "subscriber" view when connecting over the ISP-A >>> connection). >>> >>> 7. The lookup of foo.ispA.net returns different IP addresses when >>> asking ISP-A vs. ISP-B. >>> >>> >>> Do we really want to solve all those problems in homenet? We can't >>> tell the difference between behavior #1 and #6 at the IP layer. >>> >>> Erik >>> _______________________________________________ >>> 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 pthubert@cisco.com Tue Oct 4 23:43:14 2011 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 2B8D421F8B35; Tue, 4 Oct 2011 23:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.288 X-Spam-Level: X-Spam-Status: No, score=-10.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcLir3Ess4sh; Tue, 4 Oct 2011 23:43:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBFF21F8B33; Tue, 4 Oct 2011 23:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2312; q=dns/txt; s=iport; t=1317797181; x=1319006781; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rp5JBIbZkMpgn4dIN/4TB50PLlgaGmztjF4IgLtSKlI=; b=cp4KX/mRW7D1WZgf3Thm41vA/m0dlpuwGOr9T2qHtetvxzTCOfuE07Tw /+GvrTZoLc5+CDrlYJ79ZFEmn5xdnFi7ud9xrw8vQqFuSvNwyiTfHEaE1 kaDNastDfjVk7NmUx0CHdB0VKL5qcHU0WVtfPHNRXijOUA6n9jyur4eaw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANz8i06Q/khM/2dsb2JhbABChG2iK3eBBYFTAQEBAQIBEgEQDQRFBQsCAQgODAIGBhgCAgIBAVUBAQQBGhMHh1uZPgGMQZFHgS2EYzJhBJkXjBY X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="118297957" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2011 06:46:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p956kJoU019614; Wed, 5 Oct 2011 06:46:19 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 08:46:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 5 Oct 2011 08:46:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] [manet] Question for you Thread-Index: AcyCr3QOWtZIKFJKQVy/sD0bkANUyAAdxFIw References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com><1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net><47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com><48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com><3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li><2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li><4E8A03A5.5080601@raszuk.net><12856.1317691669@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Chris Elliott" , "Michael Richardson" X-OriginalArrivalTime: 05 Oct 2011 06:46:19.0063 (UTC) FILETIME=[7CAF4C70:01CC832A] Cc: homenet@ietf.org, MANET IETF , robert@raszuk.net, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 05 Oct 2011 06:43:14 -0000 Q2hyaXM7DQoNCj4gQnJpZGdpbmcgd29ya3MgZmluZSBiZXR3ZWVuIDgwMi4xMSBhbmQgODAyLjEt LW9yIGFub3RoZXIgODAyLjExIGxpbmsuIE5vIHJvdXRpbmcgcmVxdWlyZWQuDQo+IEl0IHdvcmtz IGZvciB0aGUgSUVURiBtZWV0aW5nIG5ldHdvcmtzIGFuZCBwcmV0dHkgbXVjaCBob3cgYWxsIEVu dGVycHJpc2UgZ2VhciBpcyBzZXR1cC4NCj4gTGV0J3Mga2VlcCBpdCBzaW1wbGUgYW5kIG9ubHkg cm91dGUgd2hlbiB3ZSBoYXZlIHRvLg0KDQpDZXJ0YWlubHksIGJ1dCB0aGF0J3Mgbm90IHRoZSBw b2ludC4gQXMgbG9uZyBhcyB5b3UgaGF2ZSBhIG5hdGl2ZWx5IGxvb3BsZXNzIHRvcG9sb2d5LCBm b3Igd2hpY2ggYSBXaUZpIEVTUyBpcyBhIHNpbXBsZSBleGFtcGxlLCB5b3UgY2FuIGJyaWRnZSBh bmQgcHJveHkvcmVsYXkvcmVwZWF0IGFsbCB5b3Ugd2FudC4gWW91J2xsIG5vdGUgdGhhdCB0aGUg RVNTIG1vZGVsIGlzIHJlcHJvZHVjZWQgYXQgTDMgd2hlbiB0aGUgNkxvV1BBTiBiYWNrYm9uZSBy b3V0ZXIgcHJveGllcyBORCBmcm9tIGEgYmFja2JvbmUgbGluayBvbnRvIGEgTExOLg0KDQpUaGUg cHJvYmxlbSBpcyB0aGF0IHNvb24gZW5vdWdoIHlvdSdsbCBuZWVkIG1vcmUgdGhhbiAxIHJlbGF5 IEFQIGJldHdlZW4gdGhlIHBvb2wgYW5kIHRoZSBsb3VuZ2UuIFlvdSdsbCBuZWVkIGl0IHRvIGlt cHJvdmUgdGhyb3VnaHB1dCB0aHJvdWdoIHNwYXRpYWwgZGl2ZXJzaXR5LiBZb3UnbGwgbmVlZCBp dCBzbyBzYXZlIHBvd2VyIGFuZCByZWR1Y2UgaW50ZXJmZXJlbmNlcy4gWW91J2xsIG5lZWQgaXQg dG8gaW1wcm92ZSB5b3VyIGRlbGl2ZXJ5IHJhdGlvcy4NCg0KQXMgc29vbiBhcyB5b3UgaGF2ZSBt b3JlIHRoYW4gb25lIHJlbGF5IGFuZCB0aGUgY29ubmVjdGl2aXR5IGlzIHdoYXRldmVyIG1lc2hp bmcgb2YgbGlua3MsIGxvb3BzIGNhbiBmb3JtIGFuZCB5b3UgbmVlZCByb3V0aW5nLiBUaGlzIGlz IHdoeSB3ZSBjYW1lIHVwIHdpdGggc3Bhbm5pbmcgdHJlZSBhbmQgaXRzIGV2b2x1dGlvbnMgaW4g TDIgc3dpdGNoIG5ldHdvcmtzLiBBbmQgYWxsIHNvcnRzIG9mIEwyIG1lc2ggdGVjaG5vbG9naWVz IGluIHdpcmVsZXNzLCBzdGlsbCBMMiBzcGVjaWZpYyBhbmQgcHJvcHJpZXRhcnkgd2hlcmV2ZXIg eW91IGxvb2sgYXQuIFRoZW4gYWdhaW4sIHRoZSBJRVRGIGFkZHJlc3NlZCB0aGUgcHJvYmxlbSBh dCBMMywgYW5kIGNhbWUgdXAgd2l0aCB0aGUgUlBMIHByb3RvY29sIHRoYXQgZHJhd3Mgb25lIChv ciBtb3JlKSBsb29wbGVzcyB0b3BvbG9neShpZXMpIHVwb24gYW4gYXJiaXRyYXJ5IG1lc2ggdG8g cmVhY2ggdGhlIGdhdGV3YXlzLg0KDQpXZSBjYW4gZ28gKGFnYWluKSB0aHJvdWdoIGxlbmd0aHkg ZGlzY3Vzc2lvbnMgYnV0IGluIHNob3J0IEkgYWdyZWUgd2l0aCBvdGhlciB2b2ljZXMgKFJ1c3Mp IHRoYXQgaW5kaWNhdGUgdGhhdCB3ZSBuZWVkIGEgTDMgcm91dGluZyBzb2x1dGlvbi4gSSBhbHNv IGZ1bGx5IGFncmVlIHdpdGggdGhlIHZvaWNlcyAoUm9iZXJ0KSB0aGF0IGluZGljYXRlZCB0aGF0 IHRoZSBiYWNrYm9uZSBkaXN0cmlidXRpb24gbmV0d29yayBhbmQgdGhlIG1lc2hlZCBmcmluZ2Ug YXQgdGhlIGVkZ2UgYXJlIGRpZmZlcmVudCBiZXN0cyBhbmQgbWlnaHQgbmVlZCBkaWZmZXJlbnQg dHJlYXRtZW50cy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg== From jpv@cisco.com Tue Oct 4 23:28:00 2011 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 8F50921F8A57; Tue, 4 Oct 2011 23:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.739 X-Spam-Level: X-Spam-Status: No, score=-109.739 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpOtfk2ClUeu; Tue, 4 Oct 2011 23:27:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1E18021F899F; Tue, 4 Oct 2011 23:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2050; q=dns/txt; s=iport; t=1317796266; x=1319005866; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=LM/9IamnG9nsWgB8SnAJAEViCE23IvbXtJ/QHiBZhhs=; b=WocKTU+YSyfslArBhmyR5+mWEyV/CE/06rDhHGDg8JQW5rgNd+kUBWHg Q48hkRcwDUT+HDkq8pCmfee/LCDFIZ19scldEOE/RLqc5YKGEFuPK6Lzi otuWeADMl4p+DsNrYUBmAmYMj45nZPyGd9EBuMzuCOhVRLrOsdULSTUEz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKH4i05Io8UQ/2dsb2JhbABCqA+BBYFTAQEBAQIBEgF2CxguVwYBNIdbmR0BngiGQmEEk2eFJwmMFg X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="57117333" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 05 Oct 2011 06:31:00 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p956UxEU028001; Wed, 5 Oct 2011 06:31:00 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:30:59 +0800 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 14:30:59 +0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1244.3) From: JP Vasseur In-Reply-To: Date: Wed, 5 Oct 2011 08:30:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> To: Lorenzo Colitti , Randy Turner , Qiong , "Pascal Thubert (pthubert)" , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org, Fred Baker X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 05 Oct 2011 06:30:59.0257 (UTC) FILETIME=[58700A90:01CC8328] X-Mailman-Approved-At: Wed, 05 Oct 2011 00:26:47 -0700 Subject: Re: [homenet] Question for you // Do we need three routing protocol ? 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, 05 Oct 2011 06:28:01 -0000 Sharing some thoughts =85 as already pointed on this list, we will more = likely need two routing protocols, one of constraint objects (e.g. sensors, actuators, ..), one for the = other devices, this is perfectly fine (and we know that some devices will not need routing at all, fine too). With = regards to Smart objects, since the IETF has already specified a routing protocol (RPL in the ROLL WG), do = we now want to "Tweak"/"change" /Add yet a third one (a simplified LS or routing protocol such as OLSR) = ? Since it was mentioned that we=20 should select a well established and stabilized routing protocol, it is = worth pointing out that although RPL=20 is fairly new, in the world of smart objects, this is the protocol that = will rapidly get the largest adoption and experience in the field, see the number of alliances that adopted it = (Zigbee/IP, Wave2M, =85)=20 On Oct 4, 2011, at 3:50 PM, Fred Baker wrote: >=20 > On Oct 4, 2011, at 12:50 AM, Lorenzo Colitti wrote: >=20 >> For example, if there were a robust open-source version of IS-IS that = didn't take up too much RAM and flash, you could define TLVs to = implement zeroconf and you could get to something that works relatively = quickly. >=20 > RFC 1453 specified a default OSPF configuration that my (ACC) Router = came up with by default. The only configuration necessary was to supply = IPv4 prefixes/addresses to the interfaces and to turn OSPF on. In the = context of a home, I suspect it would be pretty close. Fundamentals: = default values for most attributes are as specified in the OSPF RFC, the = metric is the duration of a bit in 10 ns units (which in LAN networks = becomes a hop count), and all interfaces are in area zero. Change things = to your heart's content, but the default configuration is one that = actually works for most purposes in a small network. I'll entertain = arguments that this doesn't address every possible configuration, but = for the networks we're discussing, I'll argue that its "close enough". From pthubert@cisco.com Wed Oct 5 00:14:22 2011 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 4622421F8B3F; Wed, 5 Oct 2011 00:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.293 X-Spam-Level: X-Spam-Status: No, score=-10.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jedz5fe-yeli; Wed, 5 Oct 2011 00:14:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A383021F8B0F; Wed, 5 Oct 2011 00:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2463; q=dns/txt; s=iport; t=1317799046; x=1319008646; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yZRnH6gd8WCvrB92aaKukWZaXpcxFBmS1BMpV1iB2bA=; b=TmFuWaXu6ATFi7IPq3JrKCZpvrdgyWjxUTtmNOd/oFm3ZO1CYvjP5lUw AI0PBBMuJ22WhGsI5DVx7L0cp807RMLFvwOW4FajDDzdpMAnz6r/RODZR sbgbW56zD585ELAActpeoEsvLQNg8TTvhb0oUemGhO7k93G4S6uOcKR/z A=; X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="118301009" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2011 07:17:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p957HJIi026029; Wed, 5 Oct 2011 07:17:19 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 09:17:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2011 09:17:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] [manet] Question for you Thread-Index: AcyCE6NqLjYtBFYkSiamqT4FTMaEnwBGn70Q References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com><1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net><47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com><48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com><4E89FEB6.3040904@freedesktop.org><61E0CF30-12F1-4218-90AD-102A635775E6@tony.li><4E8A08A1.7000106@freedesktop.org><64AA82AA-80B9-43AD-8F2B-9DC2F866887A@tony.li><4E8A10D2.1030105@freedesktop.org> From: "Pascal Thubert (pthubert)" To: "Ulrich Herberg" , "Jim Gettys" X-OriginalArrivalTime: 05 Oct 2011 07:17:19.0505 (UTC) FILETIME=[D1983810:01CC832E] X-Mailman-Approved-At: Wed, 05 Oct 2011 00:26:47 -0700 Cc: C Chauvenet , MANET IETF , Mark Townsley , JP Vasseur , Tony Li , Acee Lindem , Qiong , homenet@ietf.org, rtgwg@ietf.org, Lorenzo Colitti Subject: Re: [homenet] [manet] Question for you 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, 05 Oct 2011 07:14:22 -0000 Interestingly,=20 Those deployments are not limited to intra-home but include = between-homes, as I indicated earlier, for content and access sharing. Is that scenario in scope for this group? Pascal -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On = Behalf Of Ulrich Herberg Sent: lundi 3 octobre 2011 22:03 To: Jim Gettys Cc: C Chauvenet; MANET IETF; Mark Townsley; JP Vasseur; Qiong; Acee = Lindem; Tony Li; homenet@ietf.org; Lorenzo Colitti; rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you I agree with Jim. The reason why we developed OLSR and the its successor = OLSRv2 was precisely that wireless environments are very different from = wired. There are plenty of deployments of OLSR and several of OLSRv2, = with up to several hundreds of wireless routers, so it is demonstrably = working. Regards Ulrich On Mon, Oct 3, 2011 at 12:45 PM, Jim Gettys wrote: > > On 10/03/2011 03:32 PM, Tony Li wrote: > > On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: > > > >> My point was just that wireless has a set of challenges that all=20 > >> may not be familiar with; knowing that may help point the=20 > >> discussion in fruitful ways. =A0Routing isn't my area of expertise=20 > >> (though I have scars on my back from it in wireless...). > > > > Understood. > > > > Yes, wireless has some challenges and I've spent some time in that = area. =A0Certainly our standard protocols are not optimal for a purely = wireless environment. > > > > However, for the generic, heterogenous networks that I would expect = in the home, I would expect that the generic protocols would be the = better overall approach. > > Having been seriously scarred by presuming that wireless was similar=20 > to wired, I'm a believer in careful testing, rather than "expecting"=20 > that something should work. =A0Without "running code", demonstrably=20 > working, I'll take nothing on faith in this area. > > Wireless !=3D wired, is what I took away from that (painful) = experience. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim > > > > > Tony > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From russw@riw.us Wed Oct 5 03:07:49 2011 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 4374F21F8B02 for ; Wed, 5 Oct 2011 03:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWx+9-McE-sU for ; Wed, 5 Oct 2011 03:07:48 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8A62621F8A7A for ; Wed, 5 Oct 2011 03:07:48 -0700 (PDT) Received: from 60-244-235-201.fibertel.com.ar ([201.235.244.60]:65322 helo=[192.168.2.127]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RBORC-0003FK-IJ; Wed, 05 Oct 2011 06:10:54 -0400 Message-ID: <4E8C2D26.4000708@riw.us> Date: Wed, 05 Oct 2011 06:10:46 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: chelliot@pobox.com References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> <4E8B654D.70506@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: homenet@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 05 Oct 2011 10:07:49 -0000 > IMHO, we should accept that routing is going to be mixed with bridging > at the end node, and work around that reality. > > I absolutely agree you need routing. However, I disagree that your pool AP > needs to route, as Michael postulated. Keep routing in the core, or as > needed > in the case of multi-homed end devices. I suspect most all devices are going to be multihomed at some point or another... > However, that pool AP may need access to several subnets. I want my > primary home network, my enterprise home network, and my guest network > all accessible as SSIDs at that pool AP. That means trunking back to the > home router, in my mind. I don't see any references to VLANs or any form > of trunking in the Homenet drafts or the mailing list archives. Am I missing > something? We probably need virtualization in the home, as well, for just these situations. I don't see how you substitute one for the other, though --unless you're going to push all routing onto the host (and it's always easier to push the problem someplace else rather than to solve it). :-) Russ > > Chris. > > > :-) > > Russ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > Chris Elliott > chelliot@pobox.com > CCIE # 2013 R&S From russw@riw.us Wed Oct 5 03:10:33 2011 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 BA4C521F8BB5 for ; Wed, 5 Oct 2011 03:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXcQdUWk5VqZ for ; Wed, 5 Oct 2011 03:10:33 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id D0A2321F8B36 for ; Wed, 5 Oct 2011 03:10:26 -0700 (PDT) Received: from 60-244-235-201.fibertel.com.ar ([201.235.244.60]:65330 helo=[192.168.2.127]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RBOTU-0008VG-J6 for homenet@ietf.org; Wed, 05 Oct 2011 06:13:17 -0400 Message-ID: <4E8C2DB3.8050204@riw.us> Date: Wed, 05 Oct 2011 06:13:07 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Question for you // Do we need three routing protocol ? 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, 05 Oct 2011 10:10:33 -0000 > Sharing some thoughts … as already pointed on this list, we will more likely need two routing protocols, > one of constraint objects (e.g. sensors, actuators, ..), one for the other devices, this is perfectly fine (and > we know that some devices will not need routing at all, fine too). I would actually prefer to avoid multiple routing protocols in the home... Every control plane brings a new level of complexity into the mix, and mixing information from multiple control planes has always been notoriously difficult and error prone even when done by very smart humans in rather controlled environments. No redistribution, in other words, and certainly no automatic redistribution. :-) Russ From jason.weil@twcable.com Wed Oct 5 07:33:59 2011 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 4F54221F8C9A for ; Wed, 5 Oct 2011 07:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEKUc34LV9Ur for ; Wed, 5 Oct 2011 07:33:58 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA621F8AF7 for ; Wed, 5 Oct 2011 07:33:58 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,637,1309752000"; d="scan'208";a="266813227" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 05 Oct 2011 10:34:21 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 5 Oct 2011 10:37:06 -0400 From: "Weil, Jason" To: james woodyatt , "homenet@ietf.org" Date: Wed, 5 Oct 2011 10:37:04 -0400 Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AcyDbEDetpF/dEfCThKah6LH8PL30A== Message-ID: In-Reply-To: <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 05 Oct 2011 14:33:59 -0000 On 10/4/11 7:17 PM, "james woodyatt" wrote: >On Oct 3, 2011, at 9:00 PM, Thomas Herbst wrote: >> >> There will be wide area network providers who interwork with the home >>network but do not provide global connectivity. >> Two mentioned so far are utility networks and 3g providers. One of the >>outputs of the wg should be to define how they should be configured to >>perform their role without messing up Internet communication. > >Those utility networks have a fundamental problem that I contend is >beyond the scope and charter of HOMENET. > >Utility networks of that sort do not provide transit to the Internet >default-free zone. They must therefore obtain their routes to >residential networks bilaterally. This implies that these utility >networks could be-- and would do well to be-- numbered with ULA prefixes, >and that they should use of an exterior gateway protocol at their border >with residential networks so that each home network can advertise, into >the utility network, its list of globally assigned prefixes that it >obtains from Real Internet Service Providers. [JW] Why would the utility network require the global address space provided by the user's ISP? From a security POV, I surely wouldn't want a gateway to my network to which I have absolutely no control over (power meter for instance) have unfettered access to my home network. It was my understanding that the meter would be the demarc between the home network and the utility network, collecting data from electrical sensors with a Zigbee interface. If it has a network connection to the home gateway I would think it would use the home gateway's provided address space. > >Yes, the scale of the routing problem faced by these utility networks is >hard. No, I don't think they're going to be able to solve it adequately. > This is-- however-- not our problem. It's theirs. They would not have >this problem if they engineered their networks differently, i.e. to rely >on real Internet service providers to provide transit through the >default-free zone between their equipment in residential deployments and >their equipment in their data centers. This is what EVERYONE ELSE in the >world does, and it works pretty well. [JW] For any value add applications offered by application service providers, I would think routing through the default-free zone offered but your ISP/s would be the preferred option here. > >> A wg Chair from the Internet area did accuse me of "breaking the >>Internet model" because the utility networks my company builds do not >>provide global connectivity to users with our 100kb to the node. > >That's really not the problem, if you want my humble opinion. The >problem, I would say, is that these utility networks insist on extending >their private routing domains into our home networks where they don't >belong and they aren't welcome. > >On Oct 3, 2011, at 6:46 PM, Erik Nordmark wrote: >> [...] >> 6. The lookup of foo.ispA.net works over either DNS and returns the >>same IP address, but the application-layer content is completely >>different (e.g., a "subscriber" view when connecting over the ISP-A >>connection). > >This is the basic problem faced by any multi-homed host, e.g. a personal >computer with a 3G interface and a Wi-fi interface that are >simultaneously active, along with a split-tunnel VPN interface [or three] >running on one or both interfaces. > >It is a problem for host operating systems and applications developers. >I suggest HOMENET should steer well clear of it, and just about every >related problem that is too easily conflated with it. > > >-- >james woodyatt >member of technical staff, core os networking > > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet 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 jpv@cisco.com Wed Oct 5 08:10:10 2011 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 E169921F8D3A for ; Wed, 5 Oct 2011 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKvZPulbOeZD for ; Wed, 5 Oct 2011 08:10:10 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1AB21F8BF0 for ; Wed, 5 Oct 2011 08:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1092; q=dns/txt; s=iport; t=1317827598; x=1319037198; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7LifCJ8uKvq6TdWUYea9rEhBQHPA5ehNNU040ARwsws=; b=dppVHPdMv3a9DKP0YPYnpfHbiLlMVzV+GFfzcDz49edMjIdy4Hv6SJWH XqIY4J8xuvQDlQeDVJr98C7S21Vsqi/6cbCHt2mhoFkzPx/w0EIJrcbSG UPezhYicDoBe/Arwj3FSLbj6XdW+hW9ObvgDqWq7bymdRi7CtpP3kKJbp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIhzjE6rRDoH/2dsb2JhbABCqBKBBYFTAQEBAwEBAQEPAVsLEAtGJzAGEyKHWwaYXgGeEQOGSGEEk22FJwmMFg X-IronPort-AV: E=Sophos;i="4.68,491,1312156800"; d="scan'208";a="6072907" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 05 Oct 2011 15:13:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p95FD6Jj018036; Wed, 5 Oct 2011 15:13:06 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 08:13:06 -0700 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Oct 2011 08:13:05 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <4E8C2DB3.8050204@riw.us> Date: Wed, 5 Oct 2011 17:13:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <76C9AB39-8529-4AAC-BCE0-72E40585A30B@cisco.com> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E8C2DB3.8050204@riw.us> To: Russ White X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 05 Oct 2011 15:13:05.0981 (UTC) FILETIME=[489EC6D0:01CC8371] Cc: homenet@ietf.org Subject: Re: [homenet] Question for you // Do we need three routing protocol ? 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, 05 Oct 2011 15:10:11 -0000 On Oct 5, 2011, at 12:13 PM, Russ White wrote: >=20 >> Sharing some thoughts =85 as already pointed on this list, we will = more likely need two routing protocols, >> one of constraint objects (e.g. sensors, actuators, ..), one for the = other devices, this is perfectly fine (and >> we know that some devices will not need routing at all, fine too).=20 >=20 > I would actually prefer to avoid multiple routing protocols in the > home... Every control plane brings a new level of complexity into the > mix, and mixing information from multiple control planes has always = been > notoriously difficult and error prone even when done by very smart > humans in rather controlled environments. >=20 > No redistribution, in other words, and certainly no automatic > redistribution. >=20 > :-) Well if we can find *one* protocol for all devices in home, I am all for = it as well. Cheers. JP. >=20 > Russ >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From touch@isi.edu Wed Oct 5 08:22:10 2011 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 5D6BD21F8A6C; Wed, 5 Oct 2011 08:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKQp4kiIQRCW; Wed, 5 Oct 2011 08:22:09 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0521F8A58; Wed, 5 Oct 2011 08:22:00 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-93-161.lsanca.dsl-w.verizon.net [71.105.93.161]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p95FOVRb013892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Oct 2011 08:24:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> Date: Wed, 5 Oct 2011 08:24:31 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5D15F60D-1922-49CD-9B3C-469FC23B663B@isi.edu> References: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1244.3) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Pascal Thubert \(pthubert\)" , Don Sturek , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 05 Oct 2011 15:22:10 -0000 -1 The charter already allows for interface to external groups: --- The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. --- I.e., this can be handled via liaisons (better, IMO). Joe On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > > On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > >> To add one more point to Fred's note: I think it is important to get a >> commercial group like Wi-Fi to participate in Homenet, adopt some or all >> of the drafts/RFCs then sponsor interoperability testing. > > That would be very interesting. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From Ray.Bellis@nominet.org.uk Wed Oct 5 12:09:30 2011 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 B8EB721F8C10 for ; Wed, 5 Oct 2011 12:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5rh76WK3bHn for ; Wed, 5 Oct 2011 12:09:30 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id BBD1A21F8BEC for ; Wed, 5 Oct 2011 12:09:28 -0700 (PDT) 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=AI+QU+yfVaADE5lE5EkqEwtw4JI/v0VV3k9t6jfyL3mh2Al+dC1XnkZW G2bR3pRRB31wA1bMmiPMbgxxyrkSEoWjBRi+qEmp75Y2EjWFCjQpyF51V bKNvq1w5iTsLmAp; 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=1317841958; x=1349377958; 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:=20Interim=20meeting=20-=20audio=20bridge|Date: =20Wed,=205=20Oct=202011=2019:12:36=20+0000|Message-ID: =20 |To:=20"homenet@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20; bh=gDitqYV4K+QMCaA3R93ZJWV09D1b4/PHb0gbBKpNkXE=; b=S3UZwo43Q9eUesJ3eB0Y/9l3iMa1FlrkQiMJRRA12acr5W1QsdcE1XyE RbCTvLo6JKX7JTdW7y7sIKWz2AjCzZY1qZgaFStA+Di4R2yRJJIDlWGbI MKe0WAJBFulb9RA; X-IronPort-AV: E=Sophos;i="4.68,492,1312153200"; d="scan'208";a="28820590" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 05 Oct 2011 20:12:36 +0100 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%19]) with mapi; Wed, 5 Oct 2011 20:12:36 +0100 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: Interim meeting - audio bridge Thread-Index: AQHMg5K9bEyv2k0e7E67ke4TrDQwXg== Date: Wed, 5 Oct 2011 19:12:36 +0000 Message-ID: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Interim meeting - audio bridge 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, 05 Oct 2011 19:09:30 -0000 We were unable to source an audio streaming service, so instead a conferenc= e bridge will be available. We shall also be using the WG's Jabber channel: xmpp:homenet@jabber.ietf.or= g The access code for the audio bridge is: 2152863992 Here are all of the access dial-in codes from various locations: Reservationless-Plus Toll-Free Dial-In Number: 8664273611 <<-- Primary Toll Free from the US. International Toll-Free Dial-In Number(s) ----------------------------------------- Argentina Dial-in # : 08002220078 Australia Dial-in # : 1800634860 Bahamas Dial-in # : 18002054778 Belgium Dial-in # : 080073999 Costa Rica Dial-in # : 08000130952 Denmark Dial-in # : 80887949 Finland Dial-in # : 0800116371 France Dial-in # : 0800911910 Germany Dial-in # : 08001824395 Greece Dial-in # : 0080018092024135 Ireland Dial-in # : 1800559976 Italy Dial-in # : 800870911 Mexico Dial-in # : 018009269467 Netherlands Dial-in # : 08000226347 New Zealand Dial-in # : 0800445959 Norway Dial-in # : 80019275 Poland Dial-in # : 008001113790 Portugal Dial-in # : 800813914 Singapore Dial-in # : 8001011808 Spain Dial-in # : 900941732 Sweden Dial-in # : 020797146 Switzerland Dial-in # : 0800561617 United Kingdom Dial-in # : 08082348428 Local Dial-In Numbers Dial-In # =09 ----------------------------- Australia - Sydney - Dial-in # : 282239772 Belgium - Antwerp - Dial-in # : 034000342 Belgium - Brussels - Dial-in # : 024003532 Denmark - Copenhagen - Dial-in # : 032714408 Finland - Helsinki - Dial-in # : 358972519303 France - Lyon - Dial-in # : 0426030058 France - Marseille - Dial-in # : 0486060052 France - Paris - Dial-in # : 0170807172 France - Toulouse - Dial-in # : 0567804144 Germany - Berlin - Dial-in # : 030726167392 Germany - Frankfurt - Dial-in # : 06922224727 Germany - Hamburg - Dial-in # : 040809020733 Germany - Munich - Dial-in # : 089244432932 Ireland - Dublin - Dial-in # : 012475623 Italy - Milan - Dial-in # : 0236019675 Italy - Rome - Dial-in # : 0645217101 Netherlands - Amsterdam - Dial-in # : 0207075553 Netherlands - Rotterdam - Dial-in # : 0107114887 Norway - Oslo - Dial-in # : 22310518 Portugal - Lisbon - Dial-in # : 01211201020 Singapore - Singapore - Dial-in # : 66221022 Spain - Barcelona - Dial-in # : 0934923465 Spain - Madrid - Dial-in # : 914142522 Sweden - Stockholm - Dial-in # : 0856619471 Switzerland - Geneva - Dial-in # : 0225803302 Switzerland - Zurich - Dial-in # : 0445801757 United Kingdom - London - Dial-in # : 02031070237 Ray From jhw@apple.com Wed Oct 5 12:22:09 2011 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 D110F21F8C3C for ; Wed, 5 Oct 2011 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.61 X-Spam-Level: X-Spam-Status: No, score=-106.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXDmPqiDUnEE for ; Wed, 5 Oct 2011 12:22:08 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 91BA921F8C37 for ; Wed, 5 Oct 2011 12:22:05 -0700 (PDT) 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 Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LSL003UXXVVSWM1@mail-out.apple.com> for homenet@ietf.org; Wed, 05 Oct 2011 12:25:12 -0700 (PDT) X-AuditID: 1180711d-b7b16ae000004efb-40-4e8cae4db742 Received: from ba0301b-dhcp202.apple.com (ba0301b-dhcp202.apple.com [17.193.15.202]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 51.38.20219.D4EAC8E4; Wed, 05 Oct 2011 12:21:49 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 05 Oct 2011 12:25:13 -0700 Message-id: <88E3543D-77AD-4F68-BF97-714AFD067CDA@apple.com> References: To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42IRPMh/Std3XY+fwYk3ghbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxodnmQWHhStOzQpsYLzI38XIySEhYCJxYt9HZghbTOLCvfVs XYxcHEICq5gkduydzA6SYBbQkrjx7yVTFyMHB6+AscTrf2CmsICtRPtrQ5AKNgEViW+X74KF OYEqrjQ7gJgsQOHDjcUQM7Qlli18DbaIV8BGYuWHbrDZQgJGEmsOHGAFsUUE9CWeHvnFBnGM vMTils+MExj5ZiE5YRbCCbOQTF3AyLyKUbAoNSex0tBYL7GgICdVLzk/dxMjKHgaCmV3MO7/ yX+IUYCDUYmHV6i3x0+INbGsuDL3EKMEB7OSCK9/OVCINyWxsiq1KD++qDQntfgQozQHi5I4 7++PLX5CAumJJanZqakFqUUwWSYOTqkGRrX6ao6WiFqNntLSz3Y6M9fMeMzqG5/83cX8bnuP cMIdL83PSjnv9NmehIRIcb5W5z72fOvTbVP0LuXc5SsQWM/jpSXSwPn0s5tql45cpQjjbPFM rgNLXAwmdVz0v6hntXfVv/qEc/+idu07kOD0PmTr5usfz641Ulir5DeTcYfyI0cGI6V5SizF GYmGWsxFxYkArxALuBoCAAA= Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 05 Oct 2011 19:22:09 -0000 On Oct 5, 2011, at 7:37 AM, Weil, Jason wrote: > On 10/4/11 7:17 PM, "james woodyatt" wrote: >> >> Utility networks of that sort do not provide transit to the Internet >> default-free zone. They must therefore obtain their routes to >> residential networks bilaterally. This implies that these utility >> networks could be-- and would do well to be-- numbered with ULA prefixes, >> and that they should use of an exterior gateway protocol at their border >> with residential networks so that each home network can advertise, into >> the utility network, its list of globally assigned prefixes that it >> obtains from Real Internet Service Providers. > > [JW] Why would the utility network require the global address space provided by the user's ISP? I can imagine that it might require this on the grounds that provider aggregation will make it easier for the utility network to aggregate routes to its subscriber's residential networks. Otherwise, every subscriber ends up advertising their own ULA prefix into the routing domain of the utility network, and the result is a routing table explosion. > From a security POV, I surely wouldn't want a > gateway to my network to which I have absolutely no control over (power > meter for instance) have unfettered access to my home network. That's an orthogonal issue. From a security POV, you should have control over all the nodes in the network demarcated by the boundaries of the routing domain in your home. If you don't have control over the power meter, then it shouldn't be in your routing domain. You should have your own router, which you control and which enforces your policies, as the gateway to the utility network. > It was my > understanding that the meter would be the demarc between the home network > and the utility network, collecting data from electrical sensors with a > Zigbee interface. If it has a network connection to the home gateway I > would think it would use the home gateway's provided address space. I'd like to know how these utility operators would like to define the boundaries of their networks and how they should be demarcated from private residential networks with which they intend to interwork. Is there a document, preferably an Internet draft, which I should read to understand that? -- james woodyatt member of technical staff, core os networking From lee.howard@twcable.com Wed Oct 5 12:56:37 2011 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 570E311E80EB for ; Wed, 5 Oct 2011 12:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIJhtl+pUkwu for ; Wed, 5 Oct 2011 12:56:36 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 56C6311E80EE for ; Wed, 5 Oct 2011 12:56:36 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,640,1309752000"; d="scan'208";a="281962780" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 05 Oct 2011 15:56:33 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 5 Oct 2011 15:59:44 -0400 From: "Howard, Lee" To: Tim Chown , "homenet@ietf.org" Date: Wed, 5 Oct 2011 15:59:45 -0400 Thread-Topic: [homenet] draft-chown-homenet-arch-00.txt Thread-Index: Acx4Wdia5ZMJOhOgTliPufoyZRQSdALPzU2A Message-ID: References: <20110921113700.25835.21217.idtracker@ietfa.amsl.com> <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk> 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 Subject: Re: [homenet] draft-chown-homenet-arch-00.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, 05 Oct 2011 19:56:37 -0000 (Doing my homework at the last minute.) First, let me say that I think this document is well-written, and I like th= e way it builds up from fundamentals to explain why the architecture ought = to meet certain cases. The last paragraph of "Multiple Segments" says "multiple routers" but that = principle hasn't been mentioned. I agree that the architecture should allo= w for it, but it comes up abruptly. The section " Security, Borders, and the elimination of NAT" discusses se= curity, but provides no architecture or advice. It seems odd to lump these= things together, unless there is an assumption that Borders are firewalls = or advanced-security-monsters. For defense in depth, that unstated assumpt= ion should be explicitly repudiated. There's not really any discussion of = the elimination of NAT. "Naming and service discovery are thus important, but they {may=3D=3D>shoul= d} also be expected to operate across the scope". Or "should" could be "wi= ll" or "would" if you want to avoid rfc2119 language. "For the purposes of this memo and IP layer operation this arrangement is considered equivalent to the topology in Figure 1." Huh? How could they be equivalent? Figure 3 has some vertical lines that I think are strays. I wouldn't expec= t a host in a home network to have two simultaneous connections to the same= network segment (e.g., Network A, or Network B). The principle "Largest Possible Subnets" is explained, but given that routi= ng will be required, the reasons why large L2 domains are preferable to rou= ting are still unclear. The "Transparent End-to-End" principle is clearer now than it the previous = draft. To make the language consistent with rfc1958 though, it should be m= entioned that end-to-end communications are important for their robustness = to failure of intermediate systems, and that NAT (and firewalling, if you w= ant to argue that) is dependent on state machines which are not self-healin= g. Why is "IP Connectivity between All Nodes" an important architectural princ= iple? What if the SmartGrid guys don't want us touching some of their node= s? What if some parts of the network are managed and others are unmanaged?= The reason for this principle is unclear, and seems only to constrain us = where constrain may or may not be needed. I'd like to add a modifier to "Self-Organization" that manual configuration= should override self-organization. "Least Topology Assumptions" should be "Fewest Topology Assumptions." The "Intelligent Policy" principle is poorly defended. Apparently Cisco wa= nts to sell database/signature updates, but this principle presumes consens= us on an operating model that has never been tried. If the sentence "thes= e traffic patterns should be driven off up-to-date databases in the Interne= t" is removed, I do not object. Section 3.5 needs to be rewritten. It asserts that little to no protocol w= ork is necessary, when previous sections said (or asked) that remains to be= seen. It's difficult to assert that extensions are possible without defin= ing the requirements or at least use cases, and naming the protocols to be = extended. I'm arriving very late tonight. See you all tomorrow. Lee > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behal= f Of Tim > Chown > Sent: Wednesday, September 21, 2011 8:27 AM > To: homenet@ietf.org > Subject: [homenet] draft-chown-homenet-arch-00.txt > > Hi, > > I have been working with Jari, Jason and Ole to produce a new version of = the homenet > architecture draft. Mark, who produced the first version with Jari, is no= w of course WG > chair and has stepped down as editor of the text. > > The structure of the draft remains similar. We have expanded section 2 on= IPv6 implications > for home networking, added a couple of extra models in section 3, expande= d the principle > section and also added a considerations section where we discuss certain = topics that may (or > may not) be deemed in scope for the text. > > Feedback is of course welcome, indeed required! > > I don't know whether Mark and Ray will call for WG adoption at this stage= . The charter > targets a WG draft by the end of September, but this is also a document t= hat I hope will > have some additional revisions from your feedback before the interim meet= ing. > > There are some acknowledgements to be added; these will be included in th= e next version. > > Tim > > On 21 Sep 2011, at 12:37, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > Title : Home Networking Architecture for IPv6 > > Author(s) : Jari Arkko > > Tim Chown > > Jason Weil > > Ole Troan > > Filename : draft-chown-homenet-arch-00.txt > > Pages : 20 > > Date : 2011-09-21 > > > > This text describes the evolving networking technology within small > > "residential home" networks. The goal of this memo is to d= efine the > > architecture for IPv6-based home networking. The text highlights the > > impact of IPv6 on home networking, and illustrates some topology > > scenarios. The architecture shows how standard IPv6 mechanisms and > > addressing can be employed in home networking, lists a number of > > principles that should apply, and outlines the need for specific > > protocol extensions for certain additional functionality. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chown-homenet-arch-00.txt > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet 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 townsley@cisco.com Thu Oct 6 05:50:14 2011 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 6256C21F8C98 for ; Thu, 6 Oct 2011 05:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCZyhXjeEyVG for ; Thu, 6 Oct 2011 05:50:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEB421F8C92 for ; Thu, 6 Oct 2011 05:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=33323; q=dns/txt; s=iport; t=1317905601; x=1319115201; h=from:subject:date:message-id:to:mime-version; bh=BENWBQsf5ifpZBdLhaFoLHB0Z1Q++NOY34MvWZ/E15g=; b=hTSzHHy1BBwtyMNvOsUhV85OMjlyfL80xWpiIbD3GjkZK5xHUMGsRrs0 VkL+Pz3XJl7Zd9AXFqrvN5v7p280gh9xjWQEs0QWLZDrqhgJvBe94k5oO RYHAzmeLtFIjqcOxu1lfrwf6lBz1eVIhpM2wprMbYD9zob+/iZVMrrA+W 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHikjU6tJV2c/2dsb2JhbAAqFwOmeIE2gQWBbAFCEQIzDRgECAEDYAQWIodjJJcegSYBkCqNdYQJEAaCLGEEk26FKItXYw X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208,217";a="26483552" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 06 Oct 2011 12:53:21 +0000 Received: from [192.168.2.159] (rtp-vpn4-1906.cisco.com [10.82.215.114]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p96CrK1U023628 for ; Thu, 6 Oct 2011 12:53:20 GMT From: Mark Townsley Content-Type: multipart/alternative; boundary=Apple-Mail-23-295983180 Date: Thu, 6 Oct 2011 08:53:19 -0400 Message-Id: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [homenet] New Remote Participation Information 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, 06 Oct 2011 12:50:14 -0000 --Apple-Mail-23-295983180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please disregard the earlier conference call instructions, and use this = webex setup. We will be trying to send video, slides, etc. as well as = recording the meeting itself.=20 There is a link for more toll-free dial-in below beyond just the numbers = listed. You may join with the link as well in order to see slides, etc. = I may be muting people administratively during the call if there is too = much noise, just "raise your hand" or speak up on jabber if you want to = be unmuted.=20 Thanks, - Mark Hello ,=20 Mark Townsley invites you to attend this online meeting.=20 Topic: Homenet Date: Every 1 day, from Thursday, October 6, 2011 to Friday, October 7, = 2011=20 Time: 8:00 am, Eastern Daylight Time (New York, GMT-04:00)=20 Meeting Number: 201 102 953=20 Meeting Password: homenet=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://ciscosales.webex.com/ciscosales/j.php?ED=3D176096667&UID=3D0&PW=3D= NOWE1NDRlNzY4&RT=3DMiMxMQ%3D%3D=20 2. Enter your name and email address.=20 3. Enter the meeting password: homenet=20 4. Click "Join Now".=20 To view in other time zones or languages, please click the link:=20 = https://ciscosales.webex.com/ciscosales/j.php?ED=3D176096667&UID=3D0&PW=3D= NOWE1NDRlNzY4&ORT=3DMiMxMQ%3D%3D=20 ----------------------------------------------------------------=20 ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 ----------------------------------------------------------------=20 The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 Please dial the local access number for your area from the list below:=20= - San Jose/Milpitas (408) area: 525-6800=20 - RTP (919) area: 392-3330=20 -------------------------------------------------------=20 To join the teleconference only=20 -------------------------------------------------------=20 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 http://cisco.com/en/US/about/doing_business/conferencing/index.html=20 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign.=20 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://ciscosales.webex.com/ciscosales/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 townsley@cisco.com=20 33-15-804 3483=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 = https://ciscosales.webex.com/ciscosales/j.php?ED=3D176096667&UID=3D0&ICS=3D= MI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D7qOwpTTyUkOlzmbQBPrVy-QwkRS-LAa5afHbXkoqNIE= =3D&RT=3DMiMxMQ%3D%3D=20 The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going = tohttps://ciscosales.webex.com/ciscosales/systemdiagnosis.php=20 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com=20 CCP:+14085256800x201102953#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20= --Apple-Mail-23-295983180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Thanks,

-= Mark


Hello , 

Mark Townsley invites you to attend this online = meeting.Topic: = HomenetDate: = Every 1 day, from Thursday, October 6, 2011 to Friday, October 7, = 2011Time: = 8:00 am, Eastern Daylight Time (New York, GMT-04:00) 
Meeting Number: 201 = 102 953 


 
To join the online = meeting (Now from mobile devices!) 
 
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D17609= 6667&UID=3D0&PW=3DNOWE1NDRlNzY4&RT=3DMiMxMQ%3D%3D 
2. Enter your name = and email address. 
3. Enter the meeting password: homenet 
4. Click "Join = Now".To = view in other time zones or languages, please click the = link:https://ciscosales.webex.com/ciscosales/j.php?ED=3D17609= 6667&UID=3D0&PW=3DNOWE1NDRlNzY4&ORT=3DMiMxMQ%3D%3D<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, = sans-serif, Helvetica, Geneva; font-size: small; "> 

 
ALERT:Toll-Free Dial = Restrictions for (408) and (919) Area Codes 
 

The affected toll = free numbers are: (866) 432-9903 for the San Jose/Milpitas area and = (866) 349-3520 for the RTP area. 

Please dial the local access number for your area = from the list below: 
- San Jose/Milpitas (408) area: 525-6800 
- RTP (919) area: = 392-3330 
To join the = teleconference only 
 
1. Dial into Cisco = WebEx (view all Global Access Numbers at 
http://cisco.com/en/US/about/doing_business/conferencing= /index.html 
2. Follow the prompts to enter the Meeting Number = (listed above) or Access Code followed by the # sign. 

San Jose, CA: = +1.408.525.6800 RTP: +1.919.392.3330 

US/Canada: = +1.866.432.9903 United Kingdom: +44.20.8824.0117 

India: = +91.80.4350.1111 Germany: +49.619.6773.9002 

Japan: = +81.3.5763.9394 China: +86.10.8515.5666 

 
For = assistance 
1. Go to https://ciscosales.webex.com/ciscosales/mc 
2. On the left = navigation bar, click "Support". 

You can contact me at: 
townsley@cisco.com 
33-15-804 = 3483To add = this meeting to your calendar program (for example Microsoft Outlook), = click this link: 
https://ciscosales.webex.com/ciscosales/j.php?ED=3D17609= 6667&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D= 7qOwpTTyUkOlzmbQBPrVy-QwkRS-LAa5afHbXkoqNIE=3D&RT=3DMiMxMQ%3D%3DThe = playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going tohttps://ciscosales.webex.com/ciscosales/systemdiagnosis.= phpSign = up for a free trial of WebEx 
http://www.webex.com/go/mcemfreetrial 

http://www.webex.com 

 

IMPORTANT NOTICE: This WebEx service includes a = feature that allows audio and any documents and other materials = exchanged or viewed during the session to be recorded. By joining this = session, you automatically consent to such recordings. If you do not = consent to the recording, discuss your concerns with the meeting host = prior to the start of the recording or do not join the session. Please = note that any such recordings may be subject to discovery in the event = of litigation. 
= --Apple-Mail-23-295983180-- From tjc@ecs.soton.ac.uk Thu Oct 6 06:50:24 2011 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 7C9D621F8B70 for ; Thu, 6 Oct 2011 06:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4pe4w1yG3nK for ; Thu, 6 Oct 2011 06:50:01 -0700 (PDT) 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 D12B321F8A96 for ; Thu, 6 Oct 2011 06:50:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p96Dr7Yv017273 for ; Thu, 6 Oct 2011 14:53:07 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p96Dr7Yv017273 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1317909187; bh=34XdsKkkbm5ekds2c927I/EX7Sk=; h=From:Subject:Date:To:Mime-Version:References; b=MmSDz3nYpiAbm27I7WcSGSU+I+Td0zUQdYCFzD6MvMi6KXR5IByUXOgwHiMSiEOH5 CGF9Oiay7ICkGe2O7EA6LvgWXcxZ8IZrRhK+Aa2Up6pTi6AiP7P4F9p7ACtlSQeHEX wcLjaA8wHpMvdvPqv/+gcLVw7j9l7Stn//L1cNhs= 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 id n95Er70366103423oR ret-id none; Thu, 06 Oct 2011 14:53:07 +0100 Received: from [192.168.2.157] ([204.89.60.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p96DqgPc019814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Oct 2011 14:52:43 +0100 From: Tim Chown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Oct 2011 14:52:42 +0100 Message-ID: To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n95Er7036610342300; tid=n95Er70366103423oR; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <8C4B03D9-12E2-43F8-99E3-3971D84D6A42@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p96Dr7Yv017273 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [homenet] Jari's slides... 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, 06 Oct 2011 13:50:24 -0000 Are here for the time being: http://dl.dropbox.com/u/29188422/homenet_interim_arch_jari.pdf Tim From townsley@cisco.com Thu Oct 6 07:18:01 2011 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 6668121F8C33 for ; Thu, 6 Oct 2011 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOrMUGNEuNGO for ; Thu, 6 Oct 2011 07:18:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF3021F8C18 for ; Thu, 6 Oct 2011 07:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=2; q=dns/txt; s=iport; t=1317910871; x=1319120471; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=kZlq1L9Cl8T5LeZPtUnt9e77hDhkJPDjcfVWSDps1yLwzrDUk5nYVBhM BTCdfMS5dCaHcgpMt3jbKmog5XTO4BpuV161R79Ywn3LX+qZJ21iOqpjC 6D9lbeOrGobnfTqpVvN1shU4z2MvyX1jZCtYGKc6RFlYjwwphj0Vxd4bG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoHABW4jU6tJV2c/2dsb2JhbABEhzKSKI5ZgQWBbAEGglOfHIEmAZ4lhkthBJNuhSiMOg X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="26501128" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 06 Oct 2011 14:21:11 +0000 Received: from [192.168.2.159] (rtp-vpn4-1906.cisco.com [10.82.215.114]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p96ELAgK024920 for ; Thu, 6 Oct 2011 14:21:11 GMT From: Mark Townsley Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 6 Oct 2011 10:21:10 -0400 Message-Id: <1653AC01-55E2-4D3F-BFFF-0ED082450FC2@cisco.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [homenet] I have begun recording the session (forgot to hit start until now) 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, 06 Oct 2011 14:18:01 -0000 From fred@cisco.com Thu Oct 6 07:57:45 2011 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 E0B0B21F8B5C; Thu, 6 Oct 2011 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.397 X-Spam-Level: X-Spam-Status: No, score=-104.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsSdsfvHo2mA; Thu, 6 Oct 2011 07:57:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 406C921F8801; Thu, 6 Oct 2011 07:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1066; q=dns/txt; s=iport; t=1317913256; x=1319122856; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=RCKuhW2BLF/c0qBYEREJOZboPMw/rGD4YLTmLEc/QcY=; b=l8wFHk1GO9Li/DQZMwhoZZ2QIzC4AkdGeXq2NqEHzADnVJnkmp0QZHEX ydj1DMSLi+1VOLTCQXzKNOV/ypEZnJ9RuTE84KAqVLiw5o1r0wDhcZRDC 8Y5DqQsB/7tHR8W8YwWefeQdFNeni/abR0UPvyEZxVX5Iw/d+N9sKx3jX A=; X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="26512271" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 06 Oct 2011 15:00:56 +0000 Received: from Freds-Computer.local (rtp-vpn4-1292.cisco.com [10.82.213.12]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p96F04Gn000863; Thu, 6 Oct 2011 15:00:55 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 06 Oct 2011 11:00:57 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 06 Oct 2011 11:00:57 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5D15F60D-1922-49CD-9B3C-469FC23B663B@isi.edu> Date: Thu, 6 Oct 2011 11:00:56 -0400 Message-Id: <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> References: <1C39033D-FBB9-4CAF-8C8C-E21AB4A1E9CE@cisco.com> <5D15F60D-1922-49CD-9B3C-469FC23B663B@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Pascal Thubert \(pthubert\)" , Don Sturek , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 06 Oct 2011 14:57:46 -0000 Not sure that's the same thing. WiFi is an industry organization, not an = SDO. Yes, we could send them a letter. On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > -1 >=20 > The charter already allows for interface to external groups: >=20 > --- > The working group will also liason with external > standards bodies where it is expected that there are normative > dependencies between the specifications of the two bodies. > --- >=20 > I.e., this can be handled via liaisons (better, IMO). >=20 > Joe >=20 >=20 > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: >>=20 >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: >>=20 >>> To add one more point to Fred's note: I think it is important to = get a >>> commercial group like Wi-Fi to participate in Homenet, adopt some or = all >>> of the drafts/RFCs then sponsor interoperability testing. >>=20 >> That would be very interesting. >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From nordmark@cisco.com Thu Oct 6 08:03:36 2011 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 B583521F8CCF for ; Thu, 6 Oct 2011 08:03:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxVNniWxeVhA for ; Thu, 6 Oct 2011 08:03:36 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 556BA21F8B75 for ; Thu, 6 Oct 2011 08:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=80; q=dns/txt; s=iport; t=1317913602; x=1319123202; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7zjSE44u+szXlfUCfu20h1RB1hM4jc6JvR1oZuN3e2o=; b=gi/C8J5yVO+yCzNC54qu5xLUZhBu8yojmns8+4Y5vb4a3oWQb8ytOton 905HqP0arUMYPxJH49cPztNRg1uMki0qRz/cUzUXOqZPK2lm/ydYEs2Tb cXJKkgq8sorVgGPliN7j4dptnF4np1DMWcqMk1M3wSS/hpgb+QKeadO/5 o=; X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="6301268" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 06 Oct 2011 15:06:42 +0000 Received: from [10.0.0.117] (sjc-vpn6-1490.cisco.com [10.21.125.210]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p96F6fsp013078; Thu, 6 Oct 2011 15:06:42 GMT Message-ID: <4E8DC419.4040809@cisco.com> Date: Thu, 06 Oct 2011 08:07:05 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Townsley References: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> In-Reply-To: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: [homenet] 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: Thu, 06 Oct 2011 15:03:36 -0000 Is there an approximate agenda for the interim meeting? Thanks, Erik From Ray.Bellis@nominet.org.uk Thu Oct 6 08:07:02 2011 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 2EA0521F8BA8 for ; Thu, 6 Oct 2011 08:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.975 X-Spam-Level: X-Spam-Status: No, score=-8.975 tagged_above=-999 required=5 tests=[AWL=1.624, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D50tq-g868xJ for ; Thu, 6 Oct 2011 08:07:01 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4E60521F8BAE for ; Thu, 6 Oct 2011 08:07:01 -0700 (PDT) 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=BYCvIqLRLcqApeus1ziFhTCo9AKV0cMdzcY65HuLnCLV6tLt7BsE2lkB I2AbmavlHxEtQYQdmMBw2udp47JRgduHA8TFGBDc1L9YlcaGWcEb4HVo2 6Beyr+sTFac7toO; 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=1317913812; x=1349449812; 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]=20Agenda?|Date:=20Thu,=206=20 Oct=202011=2015:10:10=20+0000|Message-ID:=20<48B68BFB-DA7 B-4342-B4EE-9286784E97FE@nominet.org.uk>|To:=20Erik=20Nor dmark=20|CC:=20"homenet@ietf.org"=20< homenet@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20<4E8DC419.4040809@cisco.com>|References: =20<1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com>=0D=0A =20<4E8DC419.4040809@cisco.com>; bh=/yxcoQbgHAZc+63wGvC66hvjyDtrAILEXKsC43kvVVg=; b=547G3KKejdXfzdXTWQxBnisLtGGMr0eae5RarORxyS0OHbXGkzMVBdj7 vQjaXxb5/S8CBSmCPCv+zbdgT4/Se5Bh2E3IIBixcDhhokn3wE6L55Xen LmfyuH4EivGyYkV; X-IronPort-AV: E=Sophos;i="4.68,496,1312153200"; d="scan'208";a="28829837" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 06 Oct 2011 16:10:11 +0100 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%19]) with mapi; Thu, 6 Oct 2011 16:10:10 +0100 From: Ray Bellis To: Erik Nordmark Thread-Topic: [homenet] Agenda? Thread-Index: AQHMhDmUI9w1hrLtxEqSjnsUjVPa9pVvWt0A Date: Thu, 6 Oct 2011 15:10:10 +0000 Message-ID: <48B68BFB-DA7B-4342-B4EE-9286784E97FE@nominet.org.uk> References: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> <4E8DC419.4040809@cisco.com> In-Reply-To: <4E8DC419.4040809@cisco.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] 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: Thu, 06 Oct 2011 15:07:02 -0000 On 6 Oct 2011, at 11:07, Erik Nordmark wrote: >=20 > Is there an approximate agenda for the interim meeting? Yes, it's on the Trac Wiki: http://trac.tools.ietf.org/wg/homenet/trac/wiki/WikiStart Ray From curtis@occnc.com Thu Oct 6 11:37:50 2011 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 9059A21F87D6; Thu, 6 Oct 2011 11:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=2.019, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynXznUs1Gs7w; Thu, 6 Oct 2011 11:37:50 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id DBCE121F87D3; Thu, 6 Oct 2011 11:37:49 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p96IepoB039229; Thu, 6 Oct 2011 11:40:51 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p96IepoB039229 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1317926453; bh=ztJLFxO+Wff6PdKkJ84UqALjaimFABIuMikd+y/slKU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=B7t1VOzD7eW/G+dox6R4BtmqeGTVb/u+F+CbecToAZXwtc0X92YEhJp9TCAGXv9ya h2VliTuPkECBeZIjwt+jnjMsbG/wcspNw0PF6OQCD6wg9jcQ7VHvFM2bC7oJgODmtM uX8sMWE1hJP7jmFd8zlh0YWsT4OpZ27NhS6Qhfc4= Message-Id: <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> To: Fred Baker From: Curtis Villamizar In-reply-to: Your message of "Thu, 06 Oct 2011 11:00:56 EDT." <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> Date: Thu, 06 Oct 2011 11:40:51 -0700 Cc: Don Sturek , Joe Touch , C Chauvenet , MANET IETF , Mark Townsley , Acee Lindem , homenet@ietf.org, rtgwg@ietf.org Subject: [homenet] liasons and cross posting (was Re: Question for you) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:37:50 -0000 In message <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> Fred Baker writes: > Not sure that's the same thing. WiFi is an industry organization, not > an SDO. Yes, we could send them a letter. IEEE would be the relevant standards organization, if we had any relevant input into what is done at layer-2. IEEE usually sticks to layer-2 and IETF to layer-3 and up (layer-2.5 if that is what you want to call MPLS). We would contact WiFi if we had as idea for logo artwork for an IETF homenet/manet/roll/rtgwg blessed profile. This is not typically what IETF does. IMHO - neither is a good candidate for a liason relationship. btw - this message is cross posted to three lists: homenet, manet, rtgwg. I suggest we drop the cc to homenet only and anyone on rtgwg and manet can join homenet and continue the discussion. In Fred's defense, when he started this thread he asked that responses be sent to him only and not to the lists. [I'm not subscribed to manet, so this email may not get there.] Curtis > On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > > > -1 > > > > The charter already allows for interface to external groups: > > > > --- > > The working group will also liason with external > > standards bodies where it is expected that there are normative > > dependencies between the specifications of the two bodies. > > --- > > > > I.e., this can be handled via liaisons (better, IMO). > > > > Joe > > > > > > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > >> > >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > >> > >>> To add one more point to Fred's note: I think it is important to get a > >>> commercial group like Wi-Fi to participate in Homenet, adopt some or all > >>> of the drafts/RFCs then sponsor interoperability testing. > >> > >> That would be very interesting. From ulrich@herberg.name Thu Oct 6 11:47:43 2011 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 609BA21F8CE6; Thu, 6 Oct 2011 11:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxvrOF98xfeq; Thu, 6 Oct 2011 11:47:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACFFE21F8CE0; Thu, 6 Oct 2011 11:47:41 -0700 (PDT) Received: by wyg24 with SMTP id 24so29376wyg.31 for ; Thu, 06 Oct 2011 11:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0QgxndHEZJWYe+jdW7aNlHKlR7gzivxLvtaemBGs+2Q=; b=l8kTPfxqft6L6/nH6APdmnbV0SKkRpsVEp9h96UAj4ITM45CnJClN6RdHp+w4MKTyX K6p6fYiffsr4/x4fE12tRpGj+zG2m+9QVa44swKT52R/8NcnPxXJxtME5X/FrSHO7K8p Qt5+t3MDZu/tix0ebnV74sxBWwPc8saDkWIE4= MIME-Version: 1.0 Received: by 10.227.30.154 with SMTP id u26mr1367816wbc.73.1317927052304; Thu, 06 Oct 2011 11:50:52 -0700 (PDT) Received: by 10.227.7.68 with HTTP; Thu, 6 Oct 2011 11:50:52 -0700 (PDT) In-Reply-To: <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> References: <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> Date: Thu, 6 Oct 2011 11:50:52 -0700 Message-ID: From: Ulrich Herberg To: curtis@occnc.com Content-Type: multipart/alternative; boundary=002215974902cae35c04aea5cdc3 Cc: homenet@ietf.org, MANET IETF , rtgwg@ietf.org Subject: Re: [homenet] liasons and cross posting (was Re: Question for you) 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, 06 Oct 2011 18:47:43 -0000 --002215974902cae35c04aea5cdc3 Content-Type: text/plain; charset=ISO-8859-1 Hi Curtis, Sorry for my off-topic email: On Thu, Oct 6, 2011 at 11:40 AM, Curtis Villamizar wrote: > [...] > btw - this message is cross posted to three lists: homenet, manet, > rtgwg. I suggest we drop the cc to homenet only and anyone on rtgwg > and manet can join homenet and continue the discussion. > Actually, I would prefer to limit it to one mailing list (e.g. homenet). As many, like you, are not subscribed to MANET, the MANET chairs or I have to accept each reply manually because of the mailing list filters (and currently, there are several emails per day). I have sent an email to the MANET list that the thread is continued on homenet only, so everyone interested in the topic may follow the thread there. Best regards Ulrich > > > On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > > > > > -1 > > > > > > The charter already allows for interface to external groups: > > > > > > --- > > > The working group will also liason with external > > > standards bodies where it is expected that there are normative > > > dependencies between the specifications of the two bodies. > > > --- > > > > > > I.e., this can be handled via liaisons (better, IMO). > > > > > > Joe > > > > > > > > > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > > >> > > >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > > >> > > >>> To add one more point to Fred's note: I think it is important to get > a > > >>> commercial group like Wi-Fi to participate in Homenet, adopt some or > all > > >>> of the drafts/RFCs then sponsor interoperability testing. > > >> > > >> That would be very interesting. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --002215974902cae35c04aea5cdc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Curtis,

Sorry for my off-topic email:

On Thu, Oct 6, 2011 at 11:40 AM, Curtis Villamizar <curtis@occnc.com> wr= ote:
[...]
btw - this message is cross posted to three lists: homenet, manet,
rtgwg. =A0I suggest we drop the cc to homenet only and anyone on rtgwg
and manet can join homenet and continue the discussion.

Actually, I would prefer to limit it to one mailing list (e.g. homene= t). As many, like you, are not subscribed to MANET, the MANET chairs or I h= ave to accept each reply manually because of the mailing list filters (and = currently, there are several emails per day). I have sent an email to the M= ANET list that the thread is continued on homenet only, so everyone interes= ted in the topic may follow the thread there.

Best regards
Ulrich
=A0

> On Oct 5, 2011, at 11:24 AM, Joe Touch wrote:
>
> > -1
> >
> > The charter already allows for interface to external groups:
> >
> > ---
> > The working group will also liason with external
> > standards bodies where it is expected that there are normative > > dependencies between the specifications of the two bodies.
> > ---
> >
> > I.e., this can be handled via liaisons (better, IMO).
> >
> > Joe
> >
> >
> > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote:
> >>
> >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote:
> >>
> >>> To add one more point to Fred's note: =A0I think it i= s important to get a
> >>> commercial group like Wi-Fi to participate in Homenet, ad= opt some or all
> >>> of the drafts/RFCs then sponsor interoperability testing.=
> >>
> >> That would be very interesting.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--002215974902cae35c04aea5cdc3-- From samita.chakrabarti@ericsson.com Thu Oct 6 11:52:44 2011 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 2D69811E80BF for ; Thu, 6 Oct 2011 11:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11s4azbyEOb7 for ; Thu, 6 Oct 2011 11:52:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3897A21F899F for ; Thu, 6 Oct 2011 11:52:40 -0700 (PDT) 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 p96Itkhr024907; Thu, 6 Oct 2011 13:55:51 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 6 Oct 2011 14:55:50 -0400 From: Samita Chakrabarti To: Ray Bellis Date: Thu, 6 Oct 2011 14:55:49 -0400 Thread-Topic: [homenet] Agenda? Thread-Index: AQHMhDmUI9w1hrLtxEqSjnsUjVPa9pVvWt0AgABPWJA= Message-ID: <16D60F43CA0B724F8052D7E9323565D7243F638CC6@EUSAACMS0715.eamcs.ericsson.se> References: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> <4E8DC419.4040809@cisco.com> <48B68BFB-DA7B-4342-B4EE-9286784E97FE@nominet.org.uk> In-Reply-To: <48B68BFB-DA7B-4342-B4EE-9286784E97FE@nominet.org.uk> 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" Subject: Re: [homenet] 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: Thu, 06 Oct 2011 18:52:44 -0000 Hi Ray/Ole: Can we get a pointer for the latest version of the Prefix configuration dis= cussion slides that was presented just now? Regards, -Samita -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Ray Bellis Sent: Thursday, October 06, 2011 8:10 AM To: Erik Nordmark Cc: homenet@ietf.org Subject: Re: [homenet] Agenda? On 6 Oct 2011, at 11:07, Erik Nordmark wrote: >=20 > Is there an approximate agenda for the interim meeting? Yes, it's on the Trac Wiki: http://trac.tools.ietf.org/wg/homenet/trac/wiki/WikiStart Ray _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Thu Oct 6 12:01:18 2011 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 2583D1F0C5D for ; Thu, 6 Oct 2011 12:01:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04kcVWXbq9bQ for ; Thu, 6 Oct 2011 12:01:17 -0700 (PDT) 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 ED6EE1F0C5F for ; Thu, 6 Oct 2011 12:01:16 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p96J4PAA027987 for ; Thu, 6 Oct 2011 20:04:25 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p96J4PAA027987 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1317927865; bh=FBpqtUn0A1joBdwVqR/jF4HJfgk=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=nRmHLB9HofzlnxAYWTyQkQW9xnAet0VZmD4twHGuCp70a3Ykr6WYwtXs2QcU6NN01 T88qEPMi9Y+fYmhk6wRaZCHt+t5Dy/4Jbs8PI7FVVqHXL/k2MNtg8NsrxQGHyaJTJd UCelEZBN8ebY8Z0jeDAdRHwWrkGVp5Oxt0lhks+c= 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 id n95K4P0366105807cm ret-id none; Thu, 06 Oct 2011 20:04:25 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p96J4LAK029465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Oct 2011 20:04:22 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: <16D60F43CA0B724F8052D7E9323565D7243F638CC6@EUSAACMS0715.eamcs.ericsson.se> Date: Thu, 6 Oct 2011 20:04:20 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> <4E8DC419.4040809@cisco.com> <48B68BFB-DA7B-4342-B4EE-9286784E97FE@nominet.org.uk> <16D60F43CA0B724F8052D7E9323565D7243F638CC6@EUSAACMS0715.eamcs.ericsson.se> <645DA3DC-6B48-44FE-B3EA-9EFF419C53DC@ecs.soton.ac.uk> To: homenet@ietf.org X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n95K4P036610580700; tid=n95K4P0366105807cm; 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: p96J4PAA027987 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] 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: Thu, 06 Oct 2011 19:01:18 -0000 I think they're the ones on the wiki page? Fred's upcoming slides are on the wiki page too. Tim On 6 Oct 2011, at 19:55, Samita Chakrabarti wrote: > Hi Ray/Ole: >=20 > Can we get a pointer for the latest version of the Prefix = configuration discussion slides that was presented just now? >=20 > Regards, > -Samita >=20 > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On = Behalf Of Ray Bellis > Sent: Thursday, October 06, 2011 8:10 AM > To: Erik Nordmark > Cc: homenet@ietf.org > Subject: Re: [homenet] Agenda? >=20 >=20 > On 6 Oct 2011, at 11:07, Erik Nordmark wrote: >=20 >>=20 >> Is there an approximate agenda for the interim meeting? >=20 > Yes, it's on the Trac Wiki: >=20 > http://trac.tools.ietf.org/wg/homenet/trac/wiki/WikiStart >=20 > Ray >=20 > _______________________________________________ > 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 Ray.Bellis@nominet.org.uk Thu Oct 6 12:06:09 2011 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 E787C1F0C70 for ; Thu, 6 Oct 2011 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnlPIKi2dVKe for ; Thu, 6 Oct 2011 12:06:09 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id BE92F1F0C3B for ; Thu, 6 Oct 2011 12:06:07 -0700 (PDT) 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: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=Dv7qq+WEMva0rRBYQRmzQ1j28RrnLNSsLZo9RapsIlH0J0TfsHlNL9jV tQZbeRakSgl1txmOQZhfIOdi1R2SNkC3N8FGMl7kYyi1ACLa8VZ79W/cB HrlBsf0UJRZdLx1; 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=1317928160; x=1349464160; 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]=20Agenda?|Date:=20Thu,=206=20 Oct=202011=2019:09:16=20+0000|Message-ID:=20|To:=20"homenet@i etf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<9037cc93-c1d8-4027-9885-b3bd95d37086> |In-Reply-To:=20|References:=20<1B8D769E-1C5B -41FB-BF39-B5206545B30D@cisco.com>=0D=0A=20<4E8DC419.4040 809@cisco.com>=0D=0A=20<48B68BFB-DA7B-4342-B4EE-9286784E9 7FE@nominet.org.uk>=0D=0A=20<16D60F43CA0B724F8052D7E93235 65D7243F638CC6@EUSAACMS0715.eamcs.ericsson.se>=0D=0A=20<6 45DA3DC-6B48-44FE-B3EA-9EFF419C53DC@ecs.soton.ac.uk>=0D =0A=20; bh=852K74MQe1NYG5RLI20eAYEmWoUnqzEhAQm6et76Ilo=; b=SER/9KRiHpO4hoaO20GKN5E32FXTE1dDxOXpRaFU9pIeARRggUwsuSCB 1pVIKoBtq66N209h10S0ri05Lz2MSagspCCif2iid5pFfKrfmnDgxoG4w 34EukqwW0IELQ3v; X-IronPort-AV: E=Sophos;i="4.68,498,1312153200"; d="scan'208";a="35787699" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 06 Oct 2011 20:09:18 +0100 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%19]) with mapi; Thu, 6 Oct 2011 20:09:18 +0100 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: [homenet] Agenda? Thread-Index: AQHMhDmUI9w1hrLtxEqSjnsUjVPa9pVvWt0AgABPWJD///IVAIAAAWEA Date: Thu, 6 Oct 2011 19:09:16 +0000 Message-ID: References: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> <4E8DC419.4040809@cisco.com> <48B68BFB-DA7B-4342-B4EE-9286784E97FE@nominet.org.uk> <16D60F43CA0B724F8052D7E9323565D7243F638CC6@EUSAACMS0715.eamcs.ericsson.se> <645DA3DC-6B48-44FE-B3EA-9EFF419C53DC@ecs.soton.ac.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="us-ascii" Content-ID: <9037cc93-c1d8-4027-9885-b3bd95d37086> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] 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: Thu, 06 Oct 2011 19:06:10 -0000 On 6 Oct 2011, at 15:04, Tim Chown wrote: > I think they're the ones on the wiki page? The ones on the wiki page are the version from _before_ they were edited mi= d session. I hope to update those once we've revisited that requirements page once mor= e. > Fred's upcoming slides are on the wiki page too. Yes, they are. http://trac.tools.ietf.org/wg/homenet/trac/wiki/WikiStart Ray From ot@cisco.com Thu Oct 6 18:34:48 2011 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 9673621F8B73 for ; Thu, 6 Oct 2011 18:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-2.319, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75a7Cw6qpsrt for ; Thu, 6 Oct 2011 18:34:47 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8925921F8B72 for ; Thu, 6 Oct 2011 18:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=531; q=dns/txt; s=iport; t=1317951480; x=1319161080; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EL+UJUtxq52AxcOX3pLxIaaJZiqnJtf5imuw6SP8eCg=; b=hOuRtsMjl8Wk7/sfylRPObNN3Bg2TghBLMck2jkT/vUI/1YOFsKjBmr2 msG9CMZy1Yx12lQiGU+UdyuyOeJ2XAGz3vpkhjqwLj9I7Pv/+/r2HJIiH Qvpt38PzQ8Zu2gHI/zulnIkjpjZKGAV+1PZ3NHOwDXCeKPCiFtHmZ0ZNz 4=; X-IronPort-AV: E=Sophos;i="4.68,499,1312156800"; d="scan'208";a="489128" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 07 Oct 2011 01:37:57 +0000 Received: from dhcp-10-55-90-51.cisco.com (dhcp-10-55-90-51.cisco.com [10.55.90.51]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p971bu1v013311; Fri, 7 Oct 2011 01:37:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E8DC419.4040809@cisco.com> Date: Thu, 6 Oct 2011 11:09:24 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5B10E8AE-048A-4654-8D07-4CA1E1847797@cisco.com> References: <1B8D769E-1C5B-41FB-BF39-B5206545B30D@cisco.com> <4E8DC419.4040809@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: Mark Townsley , homenet@ietf.org Subject: Re: [homenet] 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: Fri, 07 Oct 2011 01:34:48 -0000 > Is there an approximate agenda for the interim meeting? Thursday, October 6 09:00 doors open 09:30 - 12:00 - Architecture Working Session 12:00 - 13:15 - Lunch 13:15 - 15:15 - Prefix Configuration Working Session 15:15 - 15:45 - Break 15:45 - 17:30 - Routing Working Session 19:00 Dinner Friday October 7 09:00 doors open 09:30 - 12:00 - Naming/Discovery Working Session 12:00 - 13:15 - Lunch 13:15 - 15:15 - Security Working Session 15:15 - 16:00 - Wrap-up and next steps From palm@broadcom.com Thu Oct 6 18:57:39 2011 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 3356421F8A58; Thu, 6 Oct 2011 18:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2eMZlQXQpdJ; Thu, 6 Oct 2011 18:57:37 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8392621F85BB; Thu, 6 Oct 2011 18:57:37 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 06 Oct 2011 19:07:14 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Thu, 6 Oct 2011 19:00:16 -0700 From: "Stephen [kiwin] Palm" To: "'curtis@occnc.com'" Date: Thu, 6 Oct 2011 19:00:40 -0700 Thread-Topic: [homenet] liasons and cross posting (was Re: Question for you) Thread-Index: AcyEV4fZDkVhhX0XRT6UsR1YWzbbiQAPWI4u Message-ID: In-Reply-To: <201110061840.p96IepoB039229@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 629081585IS16255453-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'homenet@ietf.org'" , "'manet@ietf.org'" , "Stephen \[kiwin\] Palm" , "'rtgwg@ietf.org'" Subject: Re: [homenet] liasons and cross posting (was Re: Question for you) 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, 07 Oct 2011 01:57:39 -0000 Wi-Fi Alliance (WFA) is also a standards setting organization in addition t= o its marketing role. Relevent work should be liaised to WFA.=20 I can help arrange a liaision application.=20 Regards, kiwin ------- Stephen [kiwin] Palm Ph.D. W: http://www.kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom - Broadband Communications Group=20 ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, October 06, 2011 11:40 AM=0A= To: Fred Baker Cc: Don Sturek ; Joe Touch ; C Chauvenet <= c.chauvenet@watteco.com>; MANET IETF ; Mark Townsley ; Acee Lindem ; homenet@ietf.org ; rtgwg@ietf.org Subject: [homenet] liasons and cross posting (was Re: Question for you) In message <96082B87-D6F6-4DCF-AEA6-789C99D5A720@cisco.com> Fred Baker writes: =20 > Not sure that's the same thing. WiFi is an industry organization, not > an SDO. Yes, we could send them a letter. IEEE would be the relevant standards organization, if we had any relevant input into what is done at layer-2. IEEE usually sticks to layer-2 and IETF to layer-3 and up (layer-2.5 if that is what you want to call MPLS). We would contact WiFi if we had as idea for logo artwork for an IETF homenet/manet/roll/rtgwg blessed profile. This is not typically what IETF does. IMHO - neither is a good candidate for a liason relationship. btw - this message is cross posted to three lists: homenet, manet, rtgwg. I suggest we drop the cc to homenet only and anyone on rtgwg and manet can join homenet and continue the discussion. In Fred's defense, when he started this thread he asked that responses be sent to him only and not to the lists. [I'm not subscribed to manet, so this email may not get there.] Curtis > On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: > =20 > > -1 > >=20 > > The charter already allows for interface to external groups: > >=20 > > --- > > The working group will also liason with external > > standards bodies where it is expected that there are normative > > dependencies between the specifications of the two bodies. > > --- > >=20 > > I.e., this can be handled via liaisons (better, IMO). > >=20 > > Joe > >=20 > >=20 > > On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: > >>=20 > >> On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: > >>=20 > >>> To add one more point to Fred's note: I think it is important to get= a > >>> commercial group like Wi-Fi to participate in Homenet, adopt some or = all > >>> of the drafts/RFCs then sponsor interoperability testing. > >>=20 > >> That would be very interesting. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From joelja@bogus.com Thu Oct 6 23:54:34 2011 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 153AE21F8B66 for ; Thu, 6 Oct 2011 23:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zU92MS1UW0W for ; Thu, 6 Oct 2011 23:54:33 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2421F8B5D for ; Thu, 6 Oct 2011 23:54:33 -0700 (PDT) Received: from Zorch.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 p976vi3P023933 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 06:57:45 GMT (envelope-from joelja@bogus.com) Message-ID: <4E8EA2E8.6000508@bogus.com> Date: Thu, 06 Oct 2011 23:57:44 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: james woodyatt References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> In-Reply-To: <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 07 Oct 2011 06:57:45 +0000 (UTC) Cc: homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 07 Oct 2011 06:54:34 -0000 On 10/4/11 16:17 , james woodyatt wrote: > On Oct 3, 2011, at 9:00 PM, Thomas Herbst wrote: >> >> There will be wide area network providers who interwork with the >> home network but do not provide global connectivity. Two mentioned >> so far are utility networks and 3g providers. One of the outputs >> of the wg should be to define how they should be configured to >> perform their role without messing up Internet communication. > > Those utility networks have a fundamental problem that I contend is > beyond the scope and charter of HOMENET. every-time I connect my split-tunneled vpn to my home network, I am attaching a non-dfz-connected inter-network behind my home network, I don't think of this as rare or particularly exceptional problem (it's not confined to utility networks). it does have the potential for address collisions (as built currently)in ipv4 due to the extensive if not quite complete use of rfc-1918 used within the scope of that private internetwork. > Utility networks of that sort do not provide transit to the Internet > default-free zone. They must therefore obtain their routes to > residential networks bilaterally. This implies that these utility > networks could be-- and would do well to be-- numbered with ULA > prefixes, and that they should use of an exterior gateway protocol at > their border with residential networks so that each home network can > advertise, into the utility network, its list of globally assigned > prefixes that it obtains from Real Internet Service Providers. > > Yes, the scale of the routing problem faced by these utility networks > is hard. No, I don't think they're going to be able to solve it > adequately. This is-- however-- not our problem. It's theirs. They > would not have this problem if they engineered their networks > differently, i.e. to rely on real Internet service providers to > provide transit through the default-free zone between their equipment > in residential deployments and their equipment in their data centers. > This is what EVERYONE ELSE in the world does, and it works pretty > well. > >> A wg Chair from the Internet area did accuse me of "breaking the >> Internet model" because the utility networks my company builds do >> not provide global connectivity to users with our 100kb to the >> node. > > That's really not the problem, if you want my humble opinion. The > problem, I would say, is that these utility networks insist on > extending their private routing domains into our home networks where > they don't belong and they aren't welcome. > > On Oct 3, 2011, at 6:46 PM, Erik Nordmark wrote: >> [...] 6. The lookup of foo.ispA.net works over either DNS and >> returns the same IP address, but the application-layer content is >> completely different (e.g., a "subscriber" view when connecting >> over the ISP-A connection). > > This is the basic problem faced by any multi-homed host, e.g. a > personal computer with a 3G interface and a Wi-fi interface that are > simultaneously active, along with a split-tunnel VPN interface [or > three] running on one or both interfaces. > > It is a problem for host operating systems and applications > developers. I suggest HOMENET should steer well clear of it, and > just about every related problem that is too easily conflated with > it. > > > -- james woodyatt member of technical staff, core os > networking > > > > _______________________________________________ homenet mailing list > homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet > From joelja@bogus.com Fri Oct 7 00:33:31 2011 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 E665621F8B05 for ; Fri, 7 Oct 2011 00:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFk6awfmvUCc for ; Fri, 7 Oct 2011 00:33:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 498CD21F8B04 for ; Fri, 7 Oct 2011 00:33:31 -0700 (PDT) Received: from Zorch.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 p977agul024634 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 07:36:43 GMT (envelope-from joelja@bogus.com) Message-ID: <4E8EAC0B.6090005@bogus.com> Date: Fri, 07 Oct 2011 00:36:43 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Henk Uijterwaal References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <4E8ADB98.7070207@uijterwaal.nl> In-Reply-To: <4E8ADB98.7070207@uijterwaal.nl> Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 07 Oct 2011 07:36:43 +0000 (UTC) Cc: homenet@ietf.org Subject: Re: [homenet] Question for you 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, 07 Oct 2011 07:33:32 -0000 On 10/4/11 03:10 , Henk Uijterwaal wrote: > On 03/10/2011 18:50, Lorenzo Colitti wrote: >> On Mon, Oct 3, 2011 at 08:58, Randy Turner > > wrote: >> >> I would hope that we would NOT be seriously considering OSPF or IS-IS in the >> home...this seems like using a sledgehammer to kill an ant. >> >> >> If the devices we're talking about have enough resources to run them, and they >> have desirable properties that are useful in home networks, then what's the >> problem with either of these? Home gateways these days are capable of 1Gbps >> hardware forwarding and have pretty fast CPUs. > > The problem isn't the CPU but the memory. Vendors want to stick in as little > (expensive) flash and RAM as possible, and don't want to spend a few $$ for > a few spare meg's of memory that won't be used by most of the customers. > > I've created new images for these devices and whenever adding something, > one also had to ask the question what to drop in order for the new code > to fit. Adding memory generally wasn't an option. one can handily demonstrate ospfv2 and v3 running on an off the shelf wireless ap platform with 16MB of ram along with the utility necessary to make it a functional ap/home-gateway. while memory is or can be tight there are other functional requirements driving memory utilization as well and how much ram they are built will depend on the need to pack features in to remain competitive. IF the could optimize the BOM down to a rock in a box they would but stateful inspection policy, gigabit ethernet/802.11n mimo buffers usb ports/support storage/media gateway functionality/ipv6 support etc all conspire to make the ap you have now have more resources than the one you had in the past. > Henk > > From fred@cisco.com Fri Oct 7 00:45:38 2011 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 EACB321F8B09 for ; Fri, 7 Oct 2011 00:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.167 X-Spam-Level: X-Spam-Status: No, score=-103.167 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0fobo5Mxdla for ; Fri, 7 Oct 2011 00:45:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B39EA21F8B08 for ; Fri, 7 Oct 2011 00:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5740; q=dns/txt; s=iport; t=1317973730; x=1319183330; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=YBOnmIQlSJbAgvVMKIb1hGoOo7tNRBKnCmgfC4dFVBk=; b=OFUaWA4EihiXZ7GxDGqkqoAF0IlKg2iOdPI8ZsptFxE4NQ21dnfPSmr8 yIMYz11hflVhAz7cLOh+sF8l5fMT9A9Jj8vNDFi8hDesRjbBncslqLTnh +u1J9dklEksgdv6IeJOTd4L8JUnPSaYLSoxEK2f7Zanp072bnYiLpYuli k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ+ujk6tJXG//2dsb2JhbAA+Bqg6gQWBWBQBCh0/UIEjh2OZcgGeHYQQgkFhBJNvhSiMOw X-IronPort-AV: E=Sophos;i="4.68,501,1312156800"; d="scan'208";a="26706357" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 07 Oct 2011 07:48:49 +0000 Received: from Freds-Computer.local (rtp-vpn5-166.cisco.com [10.82.232.166]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p977mm8I014142; Fri, 7 Oct 2011 07:48:48 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 07 Oct 2011 03:48:49 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 07 Oct 2011 03:48:49 -0400 From: Fred Baker Date: Fri, 7 Oct 2011 03:48:13 -0400 Message-Id: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , homenet-ads@tools.ietf.org Subject: [homenet] Thoughts about routing 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, 07 Oct 2011 07:45:38 -0000 Slides from the talk today are at = http://trac.tools.ietf.org/wg/homenet/trac/attachment/wiki/WikiStart/Homen= et%20Routing.pdf. I used them to lead a structured discussion of routing = technologies appropriate in Home and small Office (SOHO) networks, with = a view to requirements for selection of a routing protocol to = "RECEOMMEND" (RFC 2119 language) that Homenet router vendors implement. = This is in part to document a discussion we had in the room and in part = to lead it into list discussion. As one might expect, a lot of the discussion was non-controversial. = Points that raised discussion started with the issue of multihoming as = shown on slide 9. A question arose on how multi-address interfaces work = on typical operating systems including Windows, MacOSX, and various = Linux variants. It was observed that rather than actually forming an = address in each prefix as one would expect in a multi-prefix network, = Linux sees the various prefixes advertised in an RA and selects one, = forms an address in it, and uses that address until it expires. Per RFC = 4861, the lifetime on such a prefix is the same as the lifetime on the = IA_PD granted by the upstream network, which is generally on the order = of weeks. In the event that we have multiple routers to multiple = upstream networks each advertising a prefix and one fails - not just the = link, but the router and therefore the DHCPv6 server in it - the host = will continue using that prefix until it is actively rescinded. A number of folks in the room had a discussion during a break about a = related scenario, and concocted the idea of an "RA Server"; if there are = multiple routers to multiple upstream networks and therefore advertising = prefixes, one of them should advertise all of the prefixes, and if the = route to any given prefix fails (including if the RA Server fails and = another takes over the function) should remove the prefix from use. In a = network using OSPF/IS-IS, the obvious router to perform this function = might be the Designated Router. After completing the slides, I made the following statement and opened = it for discussion: "If I were to make a call today, given the facts in = evidence, I would want a routing protocol with a high quality open = source implementation that was proven and documented interoperable with = other implementations, and which had the necessary characteristics to = recover from failures in a period on the order of tens of seconds to = minutes as opposed to tens of minutes. I would recommend either RIPng or = OSPFv3, and recommend RPL for 802.15.4 interfaces." Four comments/discussions came out quickly, and as near as I can tell = represented viewpoints common in the room. 1) why recommend a routing protocol at all? I suggested that the probability of use of each of the scenarios on = slide 4 were single router network: 90th percentile tree network: unusual multi-router: perhaps 5th percentile multihomed: unusual The discussion in the room elevated the multi-homed case, due to = corporate information security requirements that required an employee's = home office to use a given network, the presence of TV-bearing and = mobile telephone networks, and so on. The argument for recommending any = protocol at all has to do with the zeroconf requirement and the = interoperation requirement; if you actually have multiple routers in the = home, it would be nice if they could exchange routes. 2) Networks calling for other protocols The room found the requirements of the Smart Grid HAN unconvincing. In = summary, the sense of the room was that one might sell a router that = interfaced a RPL network to an OSPF network in the rest of the home; ths = might be in a special purpose "interior" router, a function of the ESI, = or on the CPE Router itself. 3) Why even bring up RIPng? I bring it up because it is RIPv2 warmed over, and the majority of = residential routers I surveyed some months back support RIPv2; I expect = it is an image match to the expectations of companies that make = consumer-grade routers, and for simple scenarios works "well enough". = That said, documents such as RFC 1812 recommend implementation of OSPF = due to its characteristics with respect to timing. The sense of the room = favored implementation of OSPFv3 over RIPng, and suggested that someone = look hard at http://tools.ietf.org/html/draft-dimitri-zospf with respect = to prefix management; one wants a well tested and proven-interoperable = OSPFv3 implementation (with OSPFv3 itself at Draft Standard with respect = to the requirements of RFC 2026) that can also perform subnet prefix = management. There was discussion of a protocol profile; not only place all = interfaces into area zero by default, but remove the capability for = multiple areas and advertise the /64 allocated to RPL (if present) in an = OSPFv3 type 9 record along with the other prefixes on the router. How = much of the implementation could disappear (the LSDB would now only = contain Router LSAs, Network LSAs, and Prefix LSAs, and would only need = to process those types) was indeterminate. Using address families, this = could also subsume IPv4 routing, although it seems likely that since = routers already support RIPv2, that routing would continue to use RIPv2. 4) The use of OLSR in mesh network scenarios=20 Jim Gettys commented on the fact of OLSR use. The general sense of the = room was that OLSRv2 is interesting but out of scope for this discussion = as mesh networks are quite different from typical residential and SOHO = networks. =20 From jari.arkko@piuha.net Fri Oct 7 02:22:37 2011 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 EDE8F21F8783 for ; Fri, 7 Oct 2011 02:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mAkDftdhtTf for ; Fri, 7 Oct 2011 02:22:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 13E6321F8678 for ; Fri, 7 Oct 2011 02:22:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D21542CEFF; Fri, 7 Oct 2011 12:25:47 +0300 (EEST) 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 4qyIXQaU5dNa; Fri, 7 Oct 2011 12:25:47 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C99542CE32; Fri, 7 Oct 2011 12:25:46 +0300 (EEST) Message-ID: <4E8EC599.4050200@piuha.net> Date: Fri, 07 Oct 2011 05:25:45 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: homenet@ietf.org, Fred Baker References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> In-Reply-To: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 09:22:37 -0000 Fred, Thanks for the excellent summary! I'm in the camp that believes we do need an automatic routing mechanism. = Maybe it is because I'm in the 5% percentile, maybe it is because I belie= ve we'll see more guest/private and non-bridgeable subnets. (At the end o= f the day, I think an open Internet model for all devices will win, and w= e may be able to get rid of guest/private. But at the same time I think w= e need an answer on how to do current network models in IPv6 when the IPv= 4 answer is adding another NAT. If we do not have an answer, a copy of th= e IPv4 network model will emerge for IPv6.) In any case, I think the choice of a routing mechanism is a practical que= stion. What can we realistically expect devices to do. Your data points t= o RIP, but one significant point from yesterday's discussions was that it= might be easier to do internal network prefix assignment in general topo= logies with a link state routing mechanism. I still worry that we try to = optimize too much or aim too high with our expectations of functionality.= Perhaps something simpler would work for prefix assignment and we could = just do what most devices already have in their code, i.e., RIP. The IETF= is often in a danger of inventing new solutions as we are protocol engin= eers, and then failing to get the new stuff deployed. But I also like OSP= F a lot, and I think it would be a very elegant solution. I'm going to se= e if I can put it into my network, with some prefix assignment solution. I would like to see a recommendation for one protocol though. Something t= hat we would expect most home routers to support in the future. I think t= hat recommendation needs to be for a general purpose routing protocol tha= t we have years and years of experience with. (We'll of course see some additional things in many networks, too. One to= pic that has been raised often is LLN and ad hoc routing protocols. These= can naturally be accommodated where needed, as the current models in RPL= , for instance, call for a border router that can do the necessary per-pa= cket encap and speak RPL. Such a border router should also be a homenet r= outer and be capable of participating in the routing and prefix allocatio= n tasks with the rest of the home network. But I think it would be a mist= ake to adopt one of the ad hoc network protocols as the basic protocol to= run in all home networks. Speaking personally, I would at least like to = stick with more traditional solutions and skip the special encap and othe= r things that may come with other designs. For the record, I'm probably a= s sensor networked as you can be, but I do not use ad hoc routing protoco= ls because I happen to do all my sensor networking with link types -- WLA= N, wired, cellular -- that do not call=20 for anything special. I know there are other types of situations, but wan= ted to provide an example of LLN networking that runs in a more tradition= al architecture.) Question: Yesterday we talked a little bit about what it means for the ro= uting to be turned on automatically. Prefix assignment based on your dele= gation from the ISP is one part of it. What else do we need? Is this just= a matter of making our home router devices have OSPF on by default, and = as soon as the device gets its prefix it will start advertising it in the= routing protocol? Jari From fred@cisco.com Fri Oct 7 03:25:53 2011 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 2D0DD21F8BA8 for ; Fri, 7 Oct 2011 03:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.126 X-Spam-Level: X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfC1RJ+UoLNj for ; Fri, 7 Oct 2011 03:25:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB6821F8BA7 for ; Fri, 7 Oct 2011 03:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2232; q=dns/txt; s=iport; t=1317983346; x=1319192946; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=zg7gx/lXNIoaHJNFZJ12rD6TKuXO/IAbwNJRF67Ftz0=; b=JBXrVQqAwqP8z9x1bewlC5cQTl8nPNPGAC5GFKkGj8txDzfkDAmWSrjY C62/on1Q18qPu9gPODblEs1bOFlBadhQLcqdRVowoBkNWn1xMwM3qPjci viak0Jgmo019FRa3eSkS487UM5gttuXPW1hYY8y2ZXrjy9ap7BOq+xFiK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABTUjk6tJV2a/2dsb2JhbABEqDuBBYFTAQEBAQIBEgEnPwULC0ZXBjWHXJljAZ4rhlFhBJNvhSiMOw X-IronPort-AV: E=Sophos;i="4.68,501,1312156800"; d="scan'208";a="26730880" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 07 Oct 2011 10:29:05 +0000 Received: from Freds-Computer.local (rtp-vpn5-166.cisco.com [10.82.232.166]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p97AT4L5003195; Fri, 7 Oct 2011 10:29:05 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 07 Oct 2011 06:29:05 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 07 Oct 2011 06:29:05 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E8EC599.4050200@piuha.net> Date: Fri, 7 Oct 2011 06:28:56 -0400 Message-Id: References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 10:25:53 -0000 On Oct 7, 2011, at 5:25 AM, Jari Arkko wrote: > Question: Yesterday we talked a little bit about what it means for the = routing to be turned on automatically. Prefix assignment based on your = delegation from the ISP is one part of it. What else do we need? Is this = just a matter of making our home router devices have OSPF on by default, = and as soon as the device gets its prefix it will start advertising it = in the routing protocol? For the most part, yes. Most of the parameters that OSPF requires have = defaults specified in the RFC, and while they may or may not be perfect = they're not bad. In managed configurations (SP, Enterprise, etc) folks = twiddle the frequency of Hello messages, with a view to quickly = detecting a failure; IIRC, OSPF by default determines that a neighbor is = lost after 4 missed hellos or a link-down event, so in the worst case = this is 50 seconds from the receipt of the previous successful message. = I doubt that's a real issue in residential/SOHO networks. The other parameters in question include=20 - the interface prefix itself, which could be derived as in zospf,=20 - the area number (I'd suggest it default to zero),=20 - the router ID (a random 32 bit number), and=20 - security information.=20 I'd suggest that security information be akin to security on an SSID - = pester the user until he gives you something. zospf may have a comment = on security, I don't recall. The Router ID in IPv4 networks is often one = of the IPv4 addresses; for IPv6, it could be derived from a MAC address, = a serial number, or anything else as long as it is unique within the = routing domain. =46rom my perspective, turning on OSPF by default means that the router = will not start actually routing until 40 seconds after it is turned on = (OSPF start-up), and will otherwise mean that it beeps on the LAN every = ten seconds; the message is in the multicast group ALL-OSPF-ROUTERS, = which only other routers should be listening to. By comparison, your = favorite 802.1 switch beeps a BPDU on every interface once per second. I personally have no issue with OSPF given a rational set of defaults = and an acceptable implementation.= From jari.arkko@piuha.net Fri Oct 7 03:32:38 2011 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 D1FB521F8669 for ; Fri, 7 Oct 2011 03:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtbttuRzd3TE for ; Fri, 7 Oct 2011 03:32:38 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 37BA021F861E for ; Fri, 7 Oct 2011 03:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A4B4F2CEFF; Fri, 7 Oct 2011 13:35:50 +0300 (EEST) 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 6UcpujOTgGi7; Fri, 7 Oct 2011 13:35:49 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 73C812CE32; Fri, 7 Oct 2011 13:35:49 +0300 (EEST) Message-ID: <4E8ED604.1090808@piuha.net> Date: Fri, 07 Oct 2011 06:35:48 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Fred Baker References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 10:32:38 -0000 Thanks. Makes sense. Jari On 07.10.2011 06:28, Fred Baker wrote: > On Oct 7, 2011, at 5:25 AM, Jari Arkko wrote: > >> Question: Yesterday we talked a little bit about what it means for the routing to be turned on automatically. Prefix assignment based on your delegation from the ISP is one part of it. What else do we need? Is this just a matter of making our home router devices have OSPF on by default, and as soon as the device gets its prefix it will start advertising it in the routing protocol? > For the most part, yes. Most of the parameters that OSPF requires have defaults specified in the RFC, and while they may or may not be perfect they're not bad. In managed configurations (SP, Enterprise, etc) folks twiddle the frequency of Hello messages, with a view to quickly detecting a failure; IIRC, OSPF by default determines that a neighbor is lost after 4 missed hellos or a link-down event, so in the worst case this is 50 seconds from the receipt of the previous successful message. I doubt that's a real issue in residential/SOHO networks. > > The other parameters in question include > - the interface prefix itself, which could be derived as in zospf, > - the area number (I'd suggest it default to zero), > - the router ID (a random 32 bit number), and > - security information. > > I'd suggest that security information be akin to security on an SSID - pester the user until he gives you something. zospf may have a comment on security, I don't recall. The Router ID in IPv4 networks is often one of the IPv4 addresses; for IPv6, it could be derived from a MAC address, a serial number, or anything else as long as it is unique within the routing domain. > > From my perspective, turning on OSPF by default means that the router will not start actually routing until 40 seconds after it is turned on (OSPF start-up), and will otherwise mean that it beeps on the LAN every ten seconds; the message is in the multicast group ALL-OSPF-ROUTERS, which only other routers should be listening to. By comparison, your favorite 802.1 switch beeps a BPDU on every interface once per second. > > I personally have no issue with OSPF given a rational set of defaults and an acceptable implementation. From jari.arkko@piuha.net Fri Oct 7 03:39:38 2011 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 4075D21F8531 for ; Fri, 7 Oct 2011 03:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10M4s2JoYL7J for ; Fri, 7 Oct 2011 03:39:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B933221F8520 for ; Fri, 7 Oct 2011 03:39:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 915D32CEFF for ; Fri, 7 Oct 2011 13:42:50 +0300 (EEST) 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 SfC6cUHzvS40 for ; Fri, 7 Oct 2011 13:42:50 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id F1BDF2CE32 for ; Fri, 7 Oct 2011 13:42:49 +0300 (EEST) Message-ID: <4E8ED7A8.3000700@piuha.net> Date: Fri, 07 Oct 2011 06:42:48 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] minutes? 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, 07 Oct 2011 10:39:38 -0000 Were minutes from yesterday posted yet? Jari From fred@cisco.com Fri Oct 7 05:05:46 2011 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 0EC5721F8B8A for ; Fri, 7 Oct 2011 05:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmNCltDSHyol for ; Fri, 7 Oct 2011 05:05:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 20F9821F8B85 for ; Fri, 7 Oct 2011 05:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2315; q=dns/txt; s=iport; t=1317989338; x=1319198938; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=xb0Q25ZZjvxqqKWHq83P9ZDSgWojIcYbTO7U4GSIXjM=; b=e6czVTaVm6lW29+TkgfAQ83NgcwFIKMo9cR/IbyspZfko+UyBLbEy763 D7c15c4uphUyigqrVOSFSBKbbMB5r5bzVWih7HhQ9uK0nqH+DXVfj0327 lDxbtb+ZLbuulfWPmvdxl8CEEwB4wVcwCvhgKvjGKNf4GXTi6/0oqVesz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioHABXrjk6tJXG9/2dsb2JhbABEmWGOXIEFgVMBAQEBAxIBJz8QCxguVzuhUwGeMYZQYQSTb4UojDw X-IronPort-AV: E=Sophos;i="4.68,502,1312156800"; d="scan'208";a="26751899" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 07 Oct 2011 12:08:58 +0000 Received: from Freds-Computer.local (rtp-vpn5-166.cisco.com [10.82.232.166]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97C8vD6014060; Fri, 7 Oct 2011 12:08:58 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 07 Oct 2011 08:08:58 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 07 Oct 2011 08:08:58 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> Date: Fri, 7 Oct 2011 08:08:53 -0400 Message-Id: <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 12:05:46 -0000 On Oct 7, 2011, at 3:48 AM, Fred Baker wrote: > As one might expect, a lot of the discussion was non-controversial. = Points that raised discussion started with the issue of multihoming as = shown on slide 9. A question arose on how multi-address interfaces work = on typical operating systems including Windows, MacOSX, and various = Linux variants. It was observed that rather than actually forming an = address in each prefix as one would expect in a multi-prefix network, = Linux sees the various prefixes advertised in an RA and selects one, = forms an address in it, and uses that address until it expires. Per RFC = 4861, the lifetime on such a prefix is the same as the lifetime on the = IA_PD granted by the upstream network, which is generally on the order = of weeks. In the event that we have multiple routers to multiple = upstream networks each advertising a prefix and one fails - not just the = link, but the router and therefore the DHCPv6 server in it - the host = will continue using that prefix until it is actively rescinded. Speaking strictly for myself, here, this seems actively broken in = several ways. First, if the design of IPv6 calls for an address in each = prefix advertised in an RA, what would it take to get Windows, MacOSX, = FreeBSD, Linux, Linux, Linux, and Linux to do that? All discussion of = RFC 3484 seems wasted if the device has exactly one address. But also, the notion of tying the lifetime of a prefix on the LAN with = the lifetime of the prefix grant seems ill-considered. The purpose of = the lifetime on the prefix grant (RFC 3363) is to enable an upstream to = not need to be asked every 30 seconds for something it wants to leave = unchanged for a long period of time and yet make "a long time" not be = "forever". That's reasonable. But in the case called out here, it seems = like the lifetime of the prefix in an RA should be long enough that a = host can miss an RA refresh and not lose the address, and short enough = that we don't have to call in the national guard if someone trips over a = cable or a power supply goes spitzensparken. What do we need to do to change that RFC 4861 requirement? If what is = required is an Internet Draft in 6man (and I would expect it is), I'd be = willing to write that draft.= From narten@us.ibm.com Fri Oct 7 05:28:24 2011 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 62E7521F8B34 for ; Fri, 7 Oct 2011 05:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKiN1gN4sHP0 for ; Fri, 7 Oct 2011 05:28:20 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4818621F8B05 for ; Fri, 7 Oct 2011 05:28:20 -0700 (PDT) Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Fri, 7 Oct 2011 08:31:30 -0400 Received: from d01relay05.pok.ibm.com ([9.56.227.237]) by us.ibm.com ([192.168.1.102]) with XMail ESMTP; Fri, 7 Oct 2011 08:31:28 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p97CVS4g178002 for ; Fri, 7 Oct 2011 08:31:28 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p97CVQ0d018404 for ; Fri, 7 Oct 2011 09:31:26 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-199-223.mts.ibm.com [9.65.199.223]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p97CVPZt018340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Oct 2011 09:31:26 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p97CVOE7003287; Fri, 7 Oct 2011 08:31:24 -0400 Message-Id: <201110071231.p97CVOE7003287@cichlid.raleigh.ibm.com> To: Fred Baker In-reply-to: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> Comments: In-reply-to Fred Baker message dated "Fri, 07 Oct 2011 03:48:13 -0400." Date: Fri, 07 Oct 2011 08:31:24 -0400 From: Thomas Narten x-cbid: 11100712-5112-0000-0000-000000DB4958 Cc: homenet@ietf.org, homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 12:28:24 -0000 Fred Baker writes: > It was observed that rather than actually forming an address in each > prefix as one would expect in a multi-prefix network, Linux sees the > various prefixes advertised in an RA and selects one, forms an > address in it, and uses that address until it expires. I'd be surprised if this was in fact what Linux did. This would be a complete violation of existing specs. And, I'm sure that the the IPv6 Ready Logo/USGv6 tests would flag such an implementation as broken. But indeed, a number of linux implementations have tested successfully for USGv6 at UNH. E.g., if you look at http://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php It shows SUSE and RHE as having passed the IPv6 tests. Why do people think that Linux doesn't follow the specs when it comes to forming addresses via stateless autoconfiguration? Thomas From fred@cisco.com Fri Oct 7 05:29:40 2011 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 E62DE21F8B05 for ; Fri, 7 Oct 2011 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.06 X-Spam-Level: X-Spam-Status: No, score=-103.06 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtqBPKdVz6M2 for ; Fri, 7 Oct 2011 05:29:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BD62A21F8B06 for ; Fri, 7 Oct 2011 05:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1193; q=dns/txt; s=iport; t=1317990770; x=1319200370; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=R+74s6E+hcnoDzUo3W8K3YcBBwiOF3Ujiv71+wM0p1Q=; b=DEH4oZz+q2gCXT4G5Dzc1w3cjNkThohqUW5gwNv6gPBBKd1vhx3YXe+9 nwCzzDfD7PGJHX06iMMsOTeM93kL9cxK7//H0HlkNQkX+Z2wrb+1QI4ux QUXLsaeYcnXIdfT8bjJzDnLkSPojhC6KlXm+SzFQS1ObBDOyFxbeK3aas I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA3xjk6tJV2b/2dsb2JhbAApGqg9gQWBUwEBAQECAQEBAQ8BJzQLBQsLRicwBhMih1wHJJloAZ4xhlBhBJNvhSiMPA X-IronPort-AV: E=Sophos;i="4.68,502,1312156800"; d="scan'208";a="26756964" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 07 Oct 2011 12:32:50 +0000 Received: from Freds-Computer.local (rtp-vpn5-166.cisco.com [10.82.232.166]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p97CWnv2003786; Fri, 7 Oct 2011 12:32:49 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 07 Oct 2011 08:32:49 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 07 Oct 2011 08:32:49 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <201110071231.p97CVOE7003287@cichlid.raleigh.ibm.com> Date: Fri, 7 Oct 2011 08:32:42 -0400 Message-Id: References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <201110071231.p97CVOE7003287@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 12:29:41 -0000 I'll let those who raised the concern respond. On Oct 7, 2011, at 8:31 AM, Thomas Narten wrote: > Fred Baker writes: > >> It was observed that rather than actually forming an address in each >> prefix as one would expect in a multi-prefix network, Linux sees the >> various prefixes advertised in an RA and selects one, forms an >> address in it, and uses that address until it expires. > > I'd be surprised if this was in fact what Linux did. This would be a > complete violation of existing specs. > > And, I'm sure that the the IPv6 Ready Logo/USGv6 tests would flag such > an implementation as broken. > > But indeed, a number of linux implementations have tested successfully > for USGv6 at UNH. > > E.g., if you look at > http://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php > > It shows SUSE and RHE as having passed the IPv6 tests. > > Why do people think that Linux doesn't follow the specs when it comes > to forming addresses via stateless autoconfiguration? > > Thomas > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From jari.arkko@piuha.net Fri Oct 7 05:38:45 2011 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 3A5D721F8B2F for ; Fri, 7 Oct 2011 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K+MSKm-3YOf for ; Fri, 7 Oct 2011 05:38:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 50A0B21F8B19 for ; Fri, 7 Oct 2011 05:38:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 634982CEFF; Fri, 7 Oct 2011 15:41:57 +0300 (EEST) 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 iCdsBjzSVT4A; Fri, 7 Oct 2011 15:41:56 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 61DBE2CE32; Fri, 7 Oct 2011 15:41:56 +0300 (EEST) Message-ID: <4E8EF393.8080409@piuha.net> Date: Fri, 07 Oct 2011 08:41:55 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: homenet@ietf.org, Fred Baker References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> In-Reply-To: <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 12:38:45 -0000 Fred, >> As one might expect, a lot of the discussion was non-controversial. Po= ints that raised discussion started with the issue of multihoming as show= n on slide 9. A question arose on how multi-address interfaces work on ty= pical operating systems including Windows, MacOSX, and various Linux vari= ants. It was observed that rather than actually forming an address in eac= h prefix as one would expect in a multi-prefix network, Linux sees the va= rious prefixes advertised in an RA and selects one, forms an address in i= t, and uses that address until it expires. Per RFC 4861, the lifetime on = such a prefix is the same as the lifetime on the IA_PD granted by the ups= tream network, which is generally on the order of weeks. In the event tha= t we have multiple routers to multiple upstream networks each advertising= a prefix and one fails - not just the link, but the router and therefore= the DHCPv6 server in it - the host will continue using that prefix until= it is actively rescinded. > Speaking strictly for myself, here, this seems actively broken in sever= al ways. First, if the design of IPv6 calls for an address in each prefix= advertised in an RA, what would it take to get Windows, MacOSX, FreeBSD,= Linux, Linux, Linux, and Linux to do that? All discussion of RFC 3484 se= ems wasted if the device has exactly one address. Linux actually does configure multiple addresses, and seems capable of us= ing them in different situations. Maybe yesterday's comment about Linux b= ehavior was more about what it does when a set of addresses has no clear = preference (RFC 3484 or otherwise. My experience is that it does then use= one address/router unless something changes. (Indeed, this is often prob= lem as an earlier version had a bug that old networks didn't go down desp= ite moving to a new network, and if I happened to use the old router's ad= dress I was having a bad day.) > > But also, the notion of tying the lifetime of a prefix on the LAN with = the lifetime of the prefix grant seems ill-considered. The purpose of the= lifetime on the prefix grant (RFC 3363) is to enable an upstream to not = need to be asked every 30 seconds for something it wants to leave unchang= ed for a long period of time and yet make "a long time" not be "forever".= That's reasonable. But in the case called out here, it seems like the li= fetime of the prefix in an RA should be long enough that a host can miss = an RA refresh and not lose the address, and short enough that we don't ha= ve to call in the national guard if someone trips over a cable or a power= supply goes spitzensparken. > > What do we need to do to change that RFC 4861 requirement? If what is r= equired is an Internet Draft in 6man (and I would expect it is), I'd be w= illing to write that draft. > I was scanning RFC 4861 and did not see anything about IA_PD or delegatio= n, just saw a 30 day default value for the valid lifetime. Where is the t= ext that you would like to change? Jari From rdroms.ietf@gmail.com Fri Oct 7 05:59:26 2011 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 E35F221F8B83 for ; Fri, 7 Oct 2011 05:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQn-0RAt+SZQ for ; Fri, 7 Oct 2011 05:59:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3A3F21F8B2B for ; Fri, 7 Oct 2011 05:59:25 -0700 (PDT) Received: by gyd12 with SMTP id 12so4357212gyd.31 for ; Fri, 07 Oct 2011 06:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=H/5LzQkEy88s8ISmUuViYu6QlEgHloILwRUEHjU7Js0=; b=GsPDDORKT/x9mJuVru3uIKR0hiOdDTWviNtihoCqWz7DX/B1fTAYznTehgL8OTUAer w+C2+hLisbxKyjAicuocXdVfN9Q5tJgDYsRl6VUI7GMG2Zz6/BZXhucp9OUGouAlX6M0 MkrujmkVjgAVE19l7xBJkUaT8zlfhun7jeobs= Received: by 10.150.58.12 with SMTP id g12mr1413036yba.387.1317992559254; Fri, 07 Oct 2011 06:02:39 -0700 (PDT) Received: from [10.115.97.60] (mobile-166-137-143-116.mycingular.net. [166.137.143.116]) by mx.google.com with ESMTPS id d4sm17108115anm.8.2011.10.07.06.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 06:02:37 -0700 (PDT) References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> <4E8EF393.8080409@piuha.net> In-Reply-To: <4E8EF393.8080409@piuha.net> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8817B420-6C84-4B12-98FA-F13364BAD0B8@gmail.com> X-Mailer: iPhone Mail (8L1) From: Ralph Droms Date: Fri, 7 Oct 2011 09:02:32 -0400 To: Jari Arkko Cc: "homenet@ietf.org" , Fred Baker Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 12:59:27 -0000 On Oct 7, 2011, at 8:41 AM, Jari Arkko wrote: > Fred, >=20 >=20 >>> As one might expect, a lot of the discussion was non-controversial. Poin= ts that raised discussion started with the issue of multihoming as shown on s= lide 9. A question arose on how multi-address interfaces work on typical ope= rating systems including Windows, MacOSX, and various Linux variants. It was= observed that rather than actually forming an address in each prefix as one= would expect in a multi-prefix network, Linux sees the various prefixes adv= ertised in an RA and selects one, forms an address in it, and uses that addr= ess until it expires. Per RFC 4861, the lifetime on such a prefix is the sam= e as the lifetime on the IA_PD granted by the upstream network, which is gen= erally on the order of weeks. In the event that we have multiple routers to m= ultiple upstream networks each advertising a prefix and one fails - not just= the link, but the router and therefore the DHCPv6 server in it - the host w= ill continue using that prefix until it is actively rescinded. >> Speaking strictly for myself, here, this seems actively broken in several= ways. First, if the design of IPv6 calls for an address in each prefix adve= rtised in an RA, what would it take to get Windows, MacOSX, FreeBSD, Linux, L= inux, Linux, and Linux to do that? All discussion of RFC 3484 seems wasted i= f the device has exactly one address. >=20 > Linux actually does configure multiple addresses, and seems capable of usi= ng them in different situations. Maybe yesterday's comment about Linux behav= ior was more about what it does when a set of addresses has no clear prefere= nce (RFC 3484 or otherwise. My experience is that it does then use one addre= ss/router unless something changes. (Indeed, this is often problem as an ear= lier version had a bug that old networks didn't go down despite moving to a n= ew network, and if I happened to use the old router's address I was having a= bad day.) >=20 >=20 >>=20 >> But also, the notion of tying the lifetime of a prefix on the LAN with th= e lifetime of the prefix grant seems ill-considered. The purpose of the life= time on the prefix grant (RFC 3363) is to enable an upstream to not need to b= e asked every 30 seconds for something it wants to leave unchanged for a lon= g period of time and yet make "a long time" not be "forever". That's reasona= ble. But in the case called out here, it seems like the lifetime of the pref= ix in an RA should be long enough that a host can miss an RA refresh and not= lose the address, and short enough that we don't have to call in the nation= al guard if someone trips over a cable or a power supply goes spitzensparken= . >>=20 >> What do we need to do to change that RFC 4861 requirement? If what is req= uired is an Internet Draft in 6man (and I would expect it is), I'd be willin= g to write that draft. >>=20 >=20 > I was scanning RFC 4861 and did not see anything about IA_PD or delegation= , just saw a 30 day default value for the valid lifetime. Where is the text t= hat you would like to The text in question may be in RFC 3633, section 12.1, which requires that t= he valid lifetime for the prefix in the RA must be no later than the valid l= ifetime in the IA_PD.=20 - Ralph > change? >=20 > Jari >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From ot@cisco.com Fri Oct 7 06:13:01 2011 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 5804A21F8508 for ; Fri, 7 Oct 2011 06:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.611 X-Spam-Level: X-Spam-Status: No, score=-7.611 tagged_above=-999 required=5 tests=[AWL=2.988, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q6ysu+yT5f3 for ; Fri, 7 Oct 2011 06:12:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D6B5421F85D1 for ; Fri, 7 Oct 2011 06:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=819; q=dns/txt; s=iport; t=1317993370; x=1319202970; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XUroW588PL6ur4WbT4IN3ITWiZ4rx+WGEtTG//R8QfY=; b=WyY83CiQCRKiDfv3Fvpc9FZnshx+BXZn8BnoChNdy99g2fikV1B7nRxo glqr+k3oTS3lBnZDAMscif1husyw3Gw83MT6cVJiaaQj8R/ZmH0pbCevK thOVBywyMO0WgweSqPvw8Y4nJNWgph0Fh7qG5TM8zyqb0d/FlS5PnXcHK w=; X-IronPort-AV: E=Sophos;i="4.68,502,1312156800"; d="scan'208";a="57317095" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2011 13:16:06 +0000 Received: from dhcp-10-61-98-21.cisco.com (dhcp-10-61-98-21.cisco.com [10.61.98.21]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p97DG5Cb028086; Fri, 7 Oct 2011 13:16:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> Date: Fri, 7 Oct 2011 09:11:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E9B719B-62C7-4955-B906-C8D2D8B918C3@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , homenet@ietf.org, homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 13:13:01 -0000 > A number of folks in the room had a discussion during a break about a = related scenario, and concocted the idea of an "RA Server"; if there are = multiple routers to multiple upstream networks and therefore advertising = prefixes, one of them should advertise all of the prefixes, and if the = route to any given prefix fails (including if the RA Server fails and = another takes over the function) should remove the prefix from use. In a = network using OSPF/IS-IS, the obvious router to perform this function = might be the Designated Router. I think as a general principle addressing is independent of routing. and = that we should not as a result of loss of reachability deprecate an = address. every address, global or not has different reachability and a = host has to handle it. cheers, Ole From jhw@apple.com Fri Oct 7 06:14:16 2011 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 EB94F21F85D1 for ; Fri, 7 Oct 2011 06:14:16 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl-4tSEqIE27 for ; Fri, 7 Oct 2011 06:14:16 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 831D921F8508 for ; Fri, 7 Oct 2011 06:14:16 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LSP006AY68MIXI1@mail-out.apple.com> for homenet@ietf.org; Fri, 07 Oct 2011 06:17:28 -0700 (PDT) X-AuditID: 11807137-b7c6bae00000222c-89-4e8efdbe867d Received: from [17.153.52.70] (Unknown_Domain [17.153.52.70]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id D3.FA.08748.EBDFE8E4; Fri, 07 Oct 2011 06:25:18 -0700 (PDT) From: james woodyatt In-reply-to: <4E8EA2E8.6000508@bogus.com> Date: Fri, 07 Oct 2011 06:17:28 -0700 Message-id: <862965C2-E443-4154-B589-9A6C3C2B532E@apple.com> References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> <4E8EA2E8.6000508@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiONPETXff3z4/g/9HtC3eLzrEYvHq1BpG ByaPs0cWMHosWfKTKYApissmJTUnsyy1SN8ugStjw6XjzAUr2Cr6OhrZGxi7WbsYOTkkBEwk mk7MZYOwxSQu3FsPZHNxCAlMZpJomdXA0sXIwSEsYCvR/toQxOQVMJZ4/Y8JpJxZQEvixr+X YDabgIrEt8t3wWxOAU2JC4t/gNksQPEFt+cyQ9SLSGz9eBqqV1ti2cLXYHFeARuJF1cWQa29 xyhxdMoaFpCEiICyxM93W5ggbpOXWNzymXECI/8shDNmITljFpKxCxiZVzEKFqXmJFYamukl FhTkpOol5+duYgSFXEOh+Q7G7X/lDjEKcDAq8fB+fN7rJ8SaWFZcmXuIUYKDWUmE1+FNn58Q b0piZVVqUX58UWlOavEhRmkOFiVx3tIvLX5CAumJJanZqakFqUUwWSYOTqkGxhkz6izfyMxv O2j1zVh+wm+3BU/fhYYmKla26NtkVbxNnVS/vJDpPG/+1+xL3InO72YymNmp3X979tihwP3P mgR3GKpdDLCaxlB7fkILc97nVJ6y/qzDuSf058w4rVzFsrDgrNHtrIUTrlg5L1hzRSClKC7U 7/ShU1nG9yTZgmfUr/iyl/n1USWW4oxEQy3mouJEADNx/to1AgAA Cc: homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 07 Oct 2011 13:14:17 -0000 On Oct 6, 2011, at 23:57 , Joel jaeggli wrote: > > every-time I connect my split-tunneled vpn to my home network, I am > attaching a non-dfz-connected inter-network behind my home network Yes, but these utility networks are faced basically with the problem of establish a private network connection through an access concentrator in each and every subscriber home network simultaneously. In IPv4, this doesn't merely have the *potential* for address realm conflict... it's absolutely unavoidable, and it kills the deal before you can even begin to work on the routing problem. In IPv6, there isn't a huge problem with address realm conflict, but the routing problem looms pretty big. -- james woodyatt member of technical staff, core os networking From rdroms.ietf@gmail.com Fri Oct 7 06:38:01 2011 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 BB6BE21F8B8E for ; Fri, 7 Oct 2011 06:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UajMOO2AsK-Z for ; Fri, 7 Oct 2011 06:38:00 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF4821F8B23 for ; Fri, 7 Oct 2011 06:37:54 -0700 (PDT) Received: by iaby26 with SMTP id y26so5138632iab.31 for ; Fri, 07 Oct 2011 06:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=DctUavRE5DOnRao7vvDFuhYdUw4RSXKBrKIf/iITxtk=; b=XLRxWT2mwy34HtN+ZaXWyYZgmF3bjBYihCAJM7DnQeVF7fp9zB70mjRbFdH9Pjl3LH +2gpNLn/os3uzQV0lFCe5u2CXM9hjFNMqNhNOi0V9TCh4XHGC8ZNZXozOy6NCFFWsBKw 1RabJ3oz0Sua4DG1vH6CuleGEAZx5ap+XjO/k= Received: by 10.231.28.106 with SMTP id l42mr3273509ibc.66.1317994868118; Fri, 07 Oct 2011 06:41:08 -0700 (PDT) Received: from [10.115.97.60] (mobile-166-137-143-116.mycingular.net. [166.137.143.116]) by mx.google.com with ESMTPS id el2sm20032716ibb.10.2011.10.07.06.41.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 06:41:04 -0700 (PDT) References: From: Ralph Droms Content-Type: multipart/alternative; boundary=Apple-Mail-62-385246828 X-Mailer: iPhone Mail (8L1) Message-Id: <964A54F7-3A3D-474F-8E2E-8B7C00A05330@gmail.com> Date: Fri, 7 Oct 2011 09:40:56 -0400 To: homenet@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8L1) Subject: [homenet] Fwd: Interim meeting 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, 07 Oct 2011 13:38:01 -0000 --Apple-Mail-62-385246828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 >=20 > Our Internet connection is down, so we only have audio connection to the W= ebex session. >=20 > We're working on alternative connectivity and will fully join the session a= nd upload slides as soon as possible. >=20 > - Ralph >=20 >=20 >=20 --Apple-Mail-62-385246828 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8





Our Internet connection is down, so we only have audio connection to the Webex session.

We're working on alternative connectivity and will fully join the session and upload slides as soon as possible.

- Ralph



--Apple-Mail-62-385246828-- From jari.arkko@piuha.net Fri Oct 7 06:46:24 2011 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 8F0E621F8BA2 for ; Fri, 7 Oct 2011 06:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUGSm6GS4Mnb for ; Fri, 7 Oct 2011 06:46:24 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4521F8A70 for ; Fri, 7 Oct 2011 06:46:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E530B2CEFF; Fri, 7 Oct 2011 16:49:36 +0300 (EEST) 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 EjiFIMiNf-vJ; Fri, 7 Oct 2011 16:49:36 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C9E892CE32; Fri, 7 Oct 2011 16:49:35 +0300 (EEST) Message-ID: <4E8F036F.8050707@piuha.net> Date: Fri, 07 Oct 2011 09:49:35 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ralph Droms References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> <4E8EF393.8080409@piuha.net> <8817B420-6C84-4B12-98FA-F13364BAD0B8@gmail.com> In-Reply-To: <8817B420-6C84-4B12-98FA-F13364BAD0B8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , Fred Baker Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 13:46:24 -0000 Ralph, > The text in question may be in RFC 3633, section 12.1, which requires that the valid lifetime for the prefix in the RA must be no later than the valid lifetime in the IA_PD. > > Ah. The full text says: ... the requesting router MUST set the valid lifetime in those advertisements to be no later than the valid lifetime specified in the IA_PD Prefix option. A requesting router MAY use the preferred lifetime specified in the IA_PD Prefix option. I think this is fine, and allows the implementation to do the sensible thing. You can put in a smaller time. You can use the exact lease time. You would only get into trouble if the PD lease times where insanely small. Fixing that requires the operator to notice, and cannot be fixed in IETF specifications. In any case, we don't have a huge amount of PD deployment yet, so additional practical guidance on what kind of values to use within the rules specified above can be useful and might have an impact on what people actually do. Personally, I think its rather obvious, but I could of course be missing something. (I'm walking to the meeting site now. I had a day job conference call in the morning... Hope you solved all the problems in the morning session already :-) Jari From joelja@bogus.com Fri Oct 7 10:35:59 2011 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 BEC3D21F8BE8 for ; Fri, 7 Oct 2011 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XebuUC3yTCjL for ; Fri, 7 Oct 2011 10:35:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 522A221F8BB0 for ; Fri, 7 Oct 2011 10:35:59 -0700 (PDT) Received: from Zorch.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p97HdBAA035772 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 17:39:12 GMT (envelope-from joelja@bogus.com) Message-ID: <4E8F393A.7010602@bogus.com> Date: Fri, 07 Oct 2011 10:39:06 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: james woodyatt References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> <4E8EA2E8.6000508@bogus.com> <862965C2-E443-4154-B589-9A6C3C2B532E@apple.com> In-Reply-To: <862965C2-E443-4154-B589-9A6C3C2B532E@apple.com> Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 07 Oct 2011 17:39:12 +0000 (UTC) Cc: homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 07 Oct 2011 17:35:59 -0000 On 10/7/11 06:17 , james woodyatt wrote: > On Oct 6, 2011, at 23:57 , Joel jaeggli wrote: >> >> every-time I connect my split-tunneled vpn to my home network, I >> am attaching a non-dfz-connected inter-network behind my home >> network > > Yes, but these utility networks are faced basically with the problem > of establish a private network connection through an access > concentrator in each and every subscriber home network > simultaneously. In IPv4, this doesn't merely have the *potential* > for address realm conflict... it's absolutely unavoidable, and it > kills the deal before you can even begin to work on the routing > problem. In IPv6, there isn't a huge problem with address realm > conflict, but the routing problem looms pretty big. If you can cover the end-users total intersection between the utility network and their own with one or two prefixes instead of (for example the 250 public/private prefixes in my split tunnels table) it seems like a tractable problem. it's better if they're GUA,cause then you have some strong assurance that they don't intersect. I guess what I'd say is that while interconnection with private inter-nets may well be classified as either a threat or a menace at your convenience, it's not a new problem as surfaced by homenet and it's probably not going away. > > -- james woodyatt member of technical staff, core os > networking > > > From lorenzo@google.com Fri Oct 7 11:08:23 2011 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 9570B21F8ADE for ; Fri, 7 Oct 2011 11:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.933 X-Spam-Level: X-Spam-Status: No, score=-105.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wSAL2irjsPc for ; Fri, 7 Oct 2011 11:08:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id CEA7F21F8A7D for ; Fri, 7 Oct 2011 11:08:21 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p97IBZ1G003272 for ; Fri, 7 Oct 2011 11:11:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318011095; bh=JE4+5N1zLbFdlqU4Xt6fCdidkUw=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=GQ0bXJeStLv3wOd73J08xLdBWJvh1WYD6dwx4FU62WeZbKU/Ae5KBM5MhIR8FC8Gn zxrZT3ukzH1y7Uy5s/5cg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:from:date:message-id:subject:to:content-type; b=Yu7hI0YKogsfC6N/kZeIp5fdYZF7PnrWfsNiGVKb2kGrv03oqP990cOwFFRSZdIsg 0EwFcJmFyRv4BHxbhz28A== Received: from ggnq2 (ggnq2.prod.google.com [10.218.98.130]) by hpaq5.eem.corp.google.com with ESMTP id p97IAR0P014399 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 7 Oct 2011 11:11:34 -0700 Received: by ggnq2 with SMTP id q2so4339733ggn.4 for ; Fri, 07 Oct 2011 11:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; bh=jxeSmg/LUJzQsSGjcQgC7ABISI0B8yWDlXng6q5JgP0=; b=sUPvY/VQ/7utYYOZD8oYRJCHNglSRJDH6WqrtLlD6FN1o6nqIFiR59x9Ehcl3A8Dj2 PBAkRaHYp9dVeaqKMpgA== Received: by 10.150.202.10 with SMTP id z10mr1825608ybf.0.1318011090150; Fri, 07 Oct 2011 11:11:30 -0700 (PDT) Received: by 10.150.202.10 with SMTP id z10mr1825601ybf.0.1318011089881; Fri, 07 Oct 2011 11:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Fri, 7 Oct 2011 11:11:09 -0700 (PDT) From: Lorenzo Colitti Date: Fri, 7 Oct 2011 14:11:09 -0400 Message-ID: To: homenet@ietf.org Content-Type: multipart/mixed; boundary=000e0cd47ee2d28b9204aeb95e97 Subject: [homenet] Homenet strawman slides 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, 07 Oct 2011 18:08:23 -0000 --000e0cd47ee2d28b9204aeb95e97 Content-Type: multipart/alternative; boundary=000e0cd47ee2d28b8904aeb95e95 --000e0cd47ee2d28b8904aeb95e95 Content-Type: text/plain; charset=ISO-8859-1 All, here are my slides from the unscheduled talk at the interim meeting. Comments appreciated, and if anyone were so inclined, help writing it up would also be much appreciated. Cheers, Lorenzo --000e0cd47ee2d28b8904aeb95e95 Content-Type: text/html; charset=ISO-8859-1 All,

here are my slides from the unscheduled talk at the interim meeting.

Comments appreciated, and if anyone were so inclined, help writing it up would also be much appreciated.

Cheers,
Lorenzo
--000e0cd47ee2d28b8904aeb95e95-- --000e0cd47ee2d28b9204aeb95e97 Content-Type: application/pdf; name="Homenetstrawman.pdf" Content-Disposition: attachment; filename="Homenetstrawman.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gthhnetu0 JVBERi0xLjQKJSDi48/TCjQKMApvYmoKPDwKL1R5cGUKL0NhdGFsb2cKL05hbWVzCjw8Ci9KYXZh U2NyaXB0CjMKMApSCj4+Ci9QYWdlTGFiZWxzCjw8Ci9OdW1zClsKMAo8PAovUwovRAovU3QKMQo+ PgpdCj4+Ci9PdXRsaW5lcwoyCjAKUgovUGFnZXMKMQowClIKPj4KZW5kb2JqCjUKMApvYmoKPDwK L0NyZWF0b3IKKP7/AEcAbwBvAGcAbABlKQo+PgplbmRvYmoKNgowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjcKMApS Ci9SZXNvdXJjZXMKOAowClIKL0Fubm90cwoxMAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVu Y3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjcKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVE ZWNvZGUKL0xlbmd0aAo5CjAKUgo+PgpzdHJlYW0KeJy1U01rFEEQLdhbXRTWXHIWUWR7+6P6y5uS j9UNbCbOZkXwIEqyyCa6if8fX3cyJBOyYILSTPWr7p6e9+rVrNkozWWMroAXjfnbGa8ZQJscktdS T9zNcahMZ+yCj0HX11c3iY3ibAErvpOUuOQFn+Mj47erX8uvmk8vK5PuuTh91N1LPuEGt67ZpU7Y DaqquqTMIyMqWhGd2ZqsvEniOlmVw7uWx3s/z38bDoLz7Um/XEaiyuKMB0oqOI+L2qvX2+/8kp7T nPZoSge0oAnQgj5hZUIDOgae0w59pkPE5hW3P3i3BfdmM/fmIdKiRRANfjmnVEUpIyCYtN8Ab+m1 7Ow9ep32qFfwgcWqGFL0PbljOqryGvoCNKAXiLMqfkEHncR/QMNkq5KWkDmJQk8E26Pxpn5yCgJT kJnRR6D3IHaEWg/IYqU4gKrTPuYR0CFWjv+TBz7n4kF+uAX2vpaz0ZWWc4GdV96Ji9IT/7rKLB5M UIQBStHU5psDFfllr+yU9Q+P82QDL1E+iHgO6DmbTN8TV/+CGWq9f+1JyXfoCSht0ZCeYTzFM0Qc 0vZfe1HGH+Ie1Y4KZW5kc3RyZWFtCmVuZG9iago5CjAKb2JqCjQzNwplbmRvYmoKMTAKMApvYmoK WwpdCmVuZG9iagoxNAowCm9iago8PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJv eApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjE1CjAKUgovUmVzb3VyY2VzCjE2CjAKUgovQW5u b3RzCjE4CjAKUgovR3JvdXAKPDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+ PgplbmRvYmoKMTUKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAoxNwowClIK Pj4Kc3RyZWFtCnicnVDLCsIwEMx5vkQF26R59qioV6kEPYvSFmmrVf8fk5RQLHiRJZkZsju7mx4s ofCxHIgU1OGlRQ9HKMuVkVSEjKl2SR5acCW1oqG8GUWmBc88aTAR/q5xQueapKvmUZ8pqleYJJ5n 9Zd3jRKFc+3BTVxsZGGrKDzqzHuxPJHMCB4XCt3XFunu3r0ZlHBJtvz+KO6KqDYsAxMmUVzSHHYo t1fMyIIcyIbsyXEOe8PWuqmK31MNj0WID+ikSXMKZW5kc3RyZWFtCmVuZG9iagoxNwowCm9iagox OTAKZW5kb2JqCjE4CjAKb2JqClsKXQplbmRvYmoKMTkKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1Bh cmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjU0MApdCi9Db250ZW50cwoyMAowClIKL1Jl c291cmNlcwoyMQowClIKL0Fubm90cwoyMwowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kK L0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjIwCjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVj b2RlCi9MZW5ndGgKMjIKMApSCj4+CnN0cmVhbQp4nK1UUU/CMBA+w9v9DmM00bFu7dY9agAXIeLI ZGp4MRogBlDUR3+GP9ivnWMBZ8IIubR3l7Xf3fe13ZKF47KxszxQ0oV/mvOSEbgiCrRypV2xmWOR cXP2AxUGrt0+KxMvlL5nghlvJGaecsYLFGmez96mjy5PPmwnxXif7IQ95TEnQF2yrwtiZWRZFYnx Uhss7Wjf97UqCNnqFyk3O6+LT5EvSsfrQkVmRI6nOM03pc98TEc0oAQWU4cy6tE9RkajETXoCp9a 1KfhCacv3E7RZvJ/m0ltFiLQjlvJwGN7pJsMDOtIS8lKOJ7Q4RqTg++izW3hVGimCigSYN6gLuYh xGhAmi6USKBIXKpRq0wU/i1TF2hFX8hob/wrsX4FEHRIIbyhjhvxABViuqV4t0KR2qMEnqwQdEcJ KrFAvQ8bgPXQ3oAB3cDuIEUPWcs+FvN0GtSGKhnWxbDEymV2lven/o0JVjQjPBG0JtdoftUFFK4y PKvAaHSMN583nh+wiU4pIB++D5IJXVsJWubo4S+tKMnWPwVjP63jBXIKZW5kc3RyZWFtCmVuZG9i agoyMgowCm9iago0MTEKZW5kb2JqCjIzCjAKb2JqClsKXQplbmRvYmoKMjQKMApvYmoKPDwKL1R5 cGUKL1BhZ2UKL1BhcmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjU0MApdCi9Db250ZW50 cwoyNQowClIKL1Jlc291cmNlcwoyNgowClIKL0Fubm90cwoyOAowClIKL0dyb3VwCjw8Ci9TCi9U cmFuc3BhcmVuY3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjI1CjAKb2JqCjw8Ci9GaWx0 ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKMjcKMApSCj4+CnN0cmVhbQp4nK1V227TQBAdlLf9Dh7o A+7ae/GaN1BzIUKkdu24RXlBoDZCaSHAI5/BB/fMuG6U4KI6slZ7nfHZM2dnkq2KI624vW4WzmrM X27VVmGh48wHp614HO7hxNOtMt6lXsvnm90mSa1JeLFRBxse16pWd7jk9O3mx/qzVje/hEnbf94c hb1W1yoH6laZ0Aa2W0lU7YZnGxgrRMEYE1wbkNz+rlSnk+93v+PGqbzeFyrjnkWJU2XzUflVvSJH BV1STR8opzmN0As6owUtT1T5TY1LcMuf5pb3ph77EOlO2omSdzykzaFmwVrl4iiJQ7pH/8XfluZz 4VzKQwcUvRQdCjpH/KzHBGpMsM/pPXZzWKsHC856X+vbMGJtOuL40xcw1k7GDjBEMkWraEZLtNnu LY9g62ykB2PbBUarE0jKZD9J4i3+S9ckT6NnSZT6A/S+RB+zLTHQIHbeDJBunVjkkVEXaAWCr5Fr Z5jHkKKWPKtotcIhJyS7LNDnMPKTjqRYJzi7xDO3hcse7Nv/sYViyKIUFO0g4hmUuh9IvE4sEa+i K0R/BU2a6JeiTYFyZTHzRsDq4fdthtUIpkLmRzOX87kgXIgLF/f0OJ6Z/Zfn0Qpa6wdTsBOL3ogU H0Uzrr65JN0USs72lNwXcCxZVouVvXH67D8Kbvcem2O6CmVuZHN0cmVhbQplbmRvYmoKMjcKMApv YmoKNTA1CmVuZG9iagoyOAowCm9iagpbCl0KZW5kb2JqCjI5CjAKb2JqCjw8Ci9UeXBlCi9QYWdl Ci9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVudHMKMzAKMApS Ci9SZXNvdXJjZXMKMzEKMApSCi9Bbm5vdHMKMzMKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJl bmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagozMAowCm9iago8PAovRmlsdGVyCi9GbGF0 ZURlY29kZQovTGVuZ3RoCjMyCjAKUgo+PgpzdHJlYW0KeJytVNtu00AQHZS3+ZLygLsXr73uGyhN QqmaOnHjAHlBoDZCaSHAI5/BB3NmXBM1NVUTRdZ657I7O+fszK7ZJoble9UIITWYP9/ymiEYW2Qx mFRXbOtYJNMt+yzkmdHtq43i8tQ7EVa8pch/yTXf4ZDj16vvy0+Gb35qJu34cbNX7CVfc4moa/ax BbaRFFWryJxGiRWT6L2PoQWkp7+p+Hjw7e6XbRZV1w+JKmQUiQtcNZuqL3xEiyP6SDWN6IpK6tOY ejSgCeQStgE85/Qeo6bFAq4zuGTR7CVXX/m0Qubl/zMvdwZms5iYTlCO9Za3QQkRRUxTDjZxNuYP wL3406b53HAhl19HKMpoTlN8ExBVg4lL6GOlZ4p5BMtcpXMQd0Ez6H1IQ8xiOcOuEaxifwvL+J5y 9e2VZJE/TnLXQP/Is2lxMPY6Yz2ib5usmt6BMPFMsWKiNTdUWqewXynRTXWKd676PtRlLWRnugrm 9xMBvesIaE2QfuwKRieasRTHUFtHcAimEpp0V00flI+LTTvteKwvEjxuByoCV8BtQ+YOUASdsSgA dB/XPdGn5vS+b2YgorliKYqeXu2ldMuuJ8sD51PXcXDv2c+VfH8BvEcirgplbmRzdHJlYW0KZW5k b2JqCjMyCjAKb2JqCjQ2NgplbmRvYmoKMzMKMApvYmoKWwpdCmVuZG9iagozNAowCm9iago8PAov VHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRl bnRzCjM1CjAKUgovUmVzb3VyY2VzCjM2CjAKUgovQW5ub3RzCjM4CjAKUgovR3JvdXAKPDwKL1MK L1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKMzUKMApvYmoKPDwKL0Zp bHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAozNwowClIKPj4Kc3RyZWFtCnicnVDLCoJAFJ31+Y4W tUhnnIe6LEiE2ggTto1CJdSy+n+6MyJR0CYuM+ecue8ZIAIOZ8uRaMUJTx0GEOEiNYnmykd8awpy 0EEaHRvu09u3iGIlI0dafAl3NyjRU5Nw1d6aI0f98JNM517/VbtBhYKqDpDJtNib+a0m4TCOXC2R BlokSk4L+e5rizC79k8BoyjIVp8f5ZMgVBIYqXkKO6baM+ZsxvYsY1u2YyXLiZXsQC/5AvaCjaX5 it/zjc7C2wuwK0rHCmVuZHN0cmVhbQplbmRvYmoKMzcKMApvYmoKMTk3CmVuZG9iagozOAowCm9i agpbCl0KZW5kb2JqCjM5CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlh Qm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVudHMKNDAKMApSCi9SZXNvdXJjZXMKNDEKMApSCi9B bm5vdHMKNDMKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+ Cj4+CmVuZG9iago0MAowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjQyCjAK Ugo+PgpzdHJlYW0KeJytVN9v0zAQPhTt5UBCe+Qd8UODNIntxH4EbW21Vtsy0mSgviDQVqFuo4M/ hT+Yz9dmY52HtqiKYt9dnO+++3z2gtM4Yf+8XxpGJ5i/nfOCYSSpy61JtKxY97HIT+esclPkifw+ v3GyQqvMG3Nec/w444YvkKT3Yf5z9jXhs1/CpH2vzjphz/iUS6AuWNm2sBtLqmodP2vrsWxslVLW tAVJ9o8V9/qXF7/T5aLq9LZQzr8uzgxXy5+q7/yGFE1oTCX1MX6iQxpS/ZarH7xXgVV5P6vy0aTT 3MZJkHDGsoPrhH2RzmrNJo2z1Ba3iD/509J8KJwp/BCAogz1DymCBsewvN2nBuMAMe819AVfJnRA zxE5Xq0uaZeORLt9ijqRcUWATI3kIyQ4omEn0FSru6iPRbqWPnVmY9oHschA0BNIvBISTThBpMHr t+MQkZHMAyizvh2RrNuXmNds0olXpgNN0VmxzAX076hYEIss9eglah+LIluiXI1xAAW2RJPRqkH/ 0apTfqXcBpVRbnPnOIgFXbwWB6tO8V0USSSSnvp/lz2FWtv4ti2H/B3luBojqDcWPbsdcK1CJ/w1 7dAroH+mF8ig4D+7vnxq4dgIV7+HtVxGJ3JJNzSdIrQnpZTY7l2Ep9MHX9f++QvzBUQHCmVuZHN0 cmVhbQplbmRvYmoKNDIKMApvYmoKNDk1CmVuZG9iago0MwowCm9iagpbCl0KZW5kb2JqCjQ0CjAK b2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAK XQovQ29udGVudHMKNDUKMApSCi9SZXNvdXJjZXMKNDYKMApSCi9Bbm5vdHMKNDgKMApSCi9Hcm91 cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iago0NQowCm9i ago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjQ3CjAKUgo+PgpzdHJlYW0KeJydTzEO wjAM3O8vpI4Tp+mIxMLIxFwhSIcEKPxfwkmEkDoiy747yT7bK6wh1Nh1Ip4ULwUrlJCdQhTyrWOr talCgQsyBmrj+Sd49I4rydiIWheccdclwz4/l5mQ3u2Sb77SX94Lbjip6wqWOBKbiftzLOIiG2sh TjgareDgo+iyUD8ZjmVOV4fDQw16fAAC5zWiCmVuZHN0cmVhbQplbmRvYmoKNDcKMApvYmoKMTQ3 CmVuZG9iago0OAowCm9iagpbCl0KZW5kb2JqCjUwCjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJl bnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVudHMKNTEKMApSCi9SZXNv dXJjZXMKNTIKMApSCi9Bbm5vdHMKNTQKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9D UwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iago1MQowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29k ZQovTGVuZ3RoCjUzCjAKUgo+PgpzdHJlYW0KeJytVsuO0zAUvSg7b5DYjBBbYECI1IntJGUHGvpG bTppy2M2CDRToc5AgSWfwQdzfN10+jBVm6ksx49eH99zX+5cRKEUtr10E6Mlxi/XYi4wkVE9yYzU LLG5hpAdroVKTJpIPj67XcSpVrGdzMTGwn6nYiJucEnt9ezH9LMUV79Yk7L/vKqEPRWXIgfqXKis JHY7Y1blwo46s1hZmCmlMlMS4tvfFKLW+H7zO3JCxeW6oeq218PYiMIdKr6KZ6RoRC1qU48+UUBn NEbrUYdyGmA/p8lzUXwTbwvomP9fx/xgClGShdKrfizYn5vqW8r1TGthojCOsnSNxr2/pZr7wpnU fjxQJMF7TF1YY0RDek8TrEfYCWClIWYDzB7QQzpZ7FmpAduug2at2cHcnhofrFRSkoyk8rD8swNQ xR7ASBr+esAog/6tFZY9eLuD9TnvTNAb6H3suLEPiTH3ISQDauK0Zdngs9i7A1tjjsjWB0aPVyK7 9F/ALFf93MTK2sH5vA0/Nu7mx1imx2PmBaNXiNUWs9qOwACzIcez/fUj+sUF3V8475xFG0tRNsqh mtmqEiOPUGQ39AoOtdoyw5XETZFJ4r1T3Ksap7gXi55wJjfZy9t5biPg3SKyvXm9jBIbPQNXL6rH iDLaQ7dijHjB6JRe0FPU+g9wcYDxtLq2WibH09YLhog+43rj8tFa3flqV4XZdYnWYZpsXFI5OHVd h1kUH+P58UGhLNdQrPzJ7B6gAKYZct72OWtP6FF1dxqdbNPZ5U0vnjO0DwtccujaZc2dQ13a2Eek xWOb97prjxGn4t5/PWz7Bx55w5IKZW5kc3RyZWFtCmVuZG9iago1MwowCm9iago2MjAKZW5kb2Jq CjU0CjAKb2JqClsKXQplbmRvYmoKNTUKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAK UgovTWVkaWFCb3gKWwowCjAKNzIwCjU0MApdCi9Db250ZW50cwo1NgowClIKL1Jlc291cmNlcwo1 NwowClIKL0Fubm90cwo1OQowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZp Y2VSR0IKPj4KPj4KZW5kb2JqCjU2CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5n dGgKNTgKMApSCj4+CnN0cmVhbQp4nK1W32/TMBA+FO3FD8AeeUUMNgGZHdup+wjqunYrbdOmP4C9 INBWoW4wQDzxZ/AHc3dJ2qbzpDZUVmxffP38fb7zpbdChVJQe51NrJE4fr4WtwInUtVjZ6Vhj3Ub nWi4Fjq2tVjyz+dLI6oZHdFkLtYM6mdiIm5wk+M38++zT1Jc/WQmxfPjqhL2TFyKBFFvhXaFsOWM VRUGjcYRlgud1trZQhDv/jYVx81vN79U5pRelg+qTk89jKxIsx+lX8QhWBjAFCbQgQTOjkT6VZyk yCe5n0+yNV0Vu1B6qUaCY7dOleTVnTHCqjBSrlai/OBvQXNTOFujzgMFB6h+BKfQwj7AJzsLssZo 05m8Q6uJ7wL2Gucn1eBxgLPCb4JWAH32Od+aYFwIVjIK5R3Ff7YFVNJy7wGDiyMWHcAriEHjeIBJ 8CgX2EZpU+ix4MVx/IccG4UOGcQ7keMDW8r5gNR72FooJIAztLLIJiyuz14teIzxGXJMOyi2A82K XOruLpdtoRZpHlnpOaZqee7FgotDPI8mnJeyPEC7wRm8x6tNfDfElQac8DkGuEa+I14JcG3EKdKB j7BXPSm0VGGMDM0uksILBjW+jWPkPsRGkZ+sJDzXOtYyZvWkqJff+1Id3JyKycQJjTlqkI4uafu9 NaDVpM0Hhiz3kf0+Z3X7nqv8Al7Cc3zzHp6gpdEuRa+6PiM1l9FoF/q8YP5UJZFTDFaLAzbmlHy4 KMlLz2rho8KSybOGK+bG9zAyHrxI8qfPg4WBavO1G+S8h1SCoJurWr1sDVR3WkpS0thfCfYzDvUE 0cg/wX6CRZASosvlsMPlMKjI3tnQaqPLubdaO4qNhxyuLm8f5N/BBcVqm1ulQxU5aXdSXS39/5Kx 2kV19WKBzL+ZFMsGR/YptY3/TlH7B8wb3zcKZW5kc3RyZWFtCmVuZG9iago1OAowCm9iago2OTAK ZW5kb2JqCjU5CjAKb2JqClsKXQplbmRvYmoKNjAKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVu dAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjU0MApdCi9Db250ZW50cwo2MQowClIKL1Jlc291 cmNlcwo2MgowClIKL0Fubm90cwo2NAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NT Ci9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjYxCjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2Rl Ci9MZW5ndGgKNjMKMApSCj4+CnN0cmVhbQp4nK1UTY/TMBAd1NtcUG+cEQiQIHXijzjcQLuhpQsl 3bRZob0g0G6FursUECd+Bj+Y56lCtyFITYSsjMex/fzezNgbjiPFoT3bOtYo9B+veMNwVJw5b5WR Fc0xFoXuirWzqVOyfb0bJKnRSXDW3BgEu+KKr3HI6MX6y+qD4stvwqT+vl72wl7xBRdA3bD2tbCd J6rqQeiND1g+8lprb2tBcvrLkkf5zfX3eLuovNgPVBa+LEosl9tN5Sd+TI7GlNMZLeiEKjo/f8Ll Zz4uQan4N6WiM+PY+Ui1sk1Y0tdkGxRm3hi2cZTEPt1jfedXTfNQOJsG0wJFT2lCAwinOaIwoCNE Yiz9gB6Spbu3JysJVAFvLraiqSyeIHhh23tsm9GsMzlXi41VEqm/1P7sChgrK7YFDKJmYJ/TW/D2 NKIHIjYH/zkt0QZ0DG9Br6BnIfLH0JnTsCeJkP4mia5Qf4ohUaolPv2qoRWrWQ4hv6EkdrleyEyF jBf0GuNT+VNJTOeIbV0bR8H2I2ZcC7FwXiU5mUi+xpKbNzjtZK8W38Euadq/BpMMLo53/6MGW8Fu PTqHRfQMiupZRY/oHt3vTsdsBbI2aeRAyezp+9EZ0GrYVjCoGoLrUDI0RbaQD6mLUFrPScudO5X/ S7wZctsOfndD+w31HzcTCmVuZHN0cmVhbQplbmRvYmoKNjMKMApvYmoKNTAyCmVuZG9iago2NAow Cm9iagpbCl0KZW5kb2JqCjY1CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01l ZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVudHMKNjYKMApSCi9SZXNvdXJjZXMKNjcKMApS Ci9Bbm5vdHMKNjkKMApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdC Cj4+Cj4+CmVuZG9iago2NgowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjY4 CjAKUgo+PgpzdHJlYW0KeJydVMtOwzAQXBRx2QOIX0AcAEHqOHHiHEHQFsQrVdIgxAWB2gq1hQJH PoMPZuzIPEKQ2mqV9dqx1zOzm8w48AUb268CFQmM9xOeMQIRpLFWIrI76nNsMsOEw1glsbDHx98T mUShNMGYaxPjR1zyFJe0DsbPozvBw1eLxD0vw6Vyj3jAGbLOONSO2HdkWbmJGSNtcmlfh2GolSNk bz/MudV+mr4F1aZ88Fuo1DypLxXn1aH8gbdpl66pS30qyaMMUUk31KOCLqi/w/kjH+dAl/2PLlsY fBBrXzQCl2wrWQduyKY6ilgFvgx08ovAyoeDOW86lRjXkIq2qAPz6AgqlNDgjI6hTglVPPgefAHv VhJqUbrw5bEjEwjpiz9s3hdNGAhlfUMy2kNFO2DRtoxMlQ03z1bbsMvolNYx79IGog0bryJyHbG6 JBhT5jqYRVN9FV0K0aDTclVvzEUKdC/p9hbse9DkZ5ULq1lV+xMoVmDtBhpewjx0R/W9dGHVua59 d4VTm8t3hlTC10AZz90Zofy3GI3JSAKrR+dgWX35RV2CPpbatIb2cRsqSWzTzP1jMPYJ/M/+tApl bmRzdHJlYW0KZW5kb2JqCjY4CjAKb2JqCjQzOQplbmRvYmoKNjkKMApvYmoKWwpdCmVuZG9iago3 MAowCm9iago8PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAK NTQwCl0KL0NvbnRlbnRzCjcxCjAKUgovUmVzb3VyY2VzCjcyCjAKUgovQW5ub3RzCjc0CjAKUgov R3JvdXAKPDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKNzEK MApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo3MwowClIKPj4Kc3RyZWFtCnic rVZNk9JAEG2L21z06sGL5deWGpJMJpkctVg2skgMhkSRi6W1S1nsKurRn+EP9nWHiECkgKWm5qPT k857r3sG5spzXMXtebUwgYv505WaKyxcLw6tcQPZsW5jE09XSocmCl15fbY0/CjQPi9mas3gcapK dY2PtF/Mvk0/uuryhyCp+/fLg2JP1YXKEHWutK2JLVfCqjZ4DizHso7VWltTE5Kvv8xVu/v1+qdX bcovVoWKuceOb1RevZR/Vk/Iow69oT5l1DtR+Rd1mgNN9n802d5gvdA6biNQX0nm1oEyudgGgTKe 43s2WgF863cNc9dwJuKhIRS4D6mkhO5Ri56hD6DCkMZYZeI5r3SB3aFTPHmHZ+zbUGwvKHG0CWXf QH8l8oL4aBo1xhJhCoiUYC4hzhDzW4wFWh+y9ClFL9ETKvb+blgT8V34N4j82hJQ+w0BPdfw+WgK Rm2g7iJ56WoSJb0ZPOfwj4RtX3wpno+ENXO2eP/B2t7bsB+jeRTegLlxHQuw4VGYNwUjF6WbSo6Y fyFlLKiFATOaTEAokySPhVwLI29ldy1XsthcYE8C+tvSvQ2jjR0TrmE8+ARoHTuhZ0J9hBPQGIsm J4vCSOiD3Bcj0SMV8caySvH0jO6gmLhkzmBl/6h2g2OhY9cJgMjfuTgaA1bCNwajh2Qkzz0gXRZG CyyGQN+RQ9KiV+DFNvuf0iPS9J7uUutwZkHAV7LZveq3EGuKhYsro9fg1BVWzKI6yJIRVDdnj6+u gdT1aHG/L6+EHtoIPs5peUgWF9hstIHt4GI3Ot4U7cBfxIZQyO1Q1Gktfv0KqXCu/oFoUsrI9X5/ 538L3P4AYTawUwplbmRzdHJlYW0KZW5kb2JqCjczCjAKb2JqCjYzOQplbmRvYmoKNzQKMApvYmoK WwpdCmVuZG9iago3NQowCm9iago8PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJv eApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjc2CjAKUgovUmVzb3VyY2VzCjc3CjAKUgovQW5u b3RzCjc5CjAKUgovR3JvdXAKPDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+ PgplbmRvYmoKNzYKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo3OAowClIK Pj4Kc3RyZWFtCnicnVDLCsIwEMx5vkQP1qR5NDkqKB48WIiPqyhapK1W/X/cpJRiwYssm50hs88G IuEINmmBVpziqUIDAlw4YzVXUTHkJAqhgjQ6Mzymlz1JMyXTAEoMSHgL7FFTk+msfBRHjusrTtL5 8/pX7QIX5FS1gbTdYj2KW3UkxCwNtYRLtLBKdgvF7nOP6fJevwWMIpG/fB9KOJUY7qSFUDYxUnMH 36b7M0ZMsxXz7MDWbEtoQ56zPduN4W9YeJox/z1j+5lH+wDz80u/CmVuZHN0cmVhbQplbmRvYmoK NzgKMApvYmoKMjAwCmVuZG9iago3OQowCm9iagpbCl0KZW5kb2JqCjgwCjAKb2JqCjw8Ci9UeXBl Ci9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVudHMK ODEKMApSCi9SZXNvdXJjZXMKODIKMApSCi9Bbm5vdHMKODQKMApSCi9Hcm91cAo8PAovUwovVHJh bnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iago4MQowCm9iago8PAovRmlsdGVy Ci9GbGF0ZURlY29kZQovTGVuZ3RoCjgzCjAKUgo+PgpzdHJlYW0KeJytVU1vEzEQHZTbHBC/gVOL hONvew8cQGnahIp0YbuhsBwQqI1QWghw5Gfwgzv2dinZuKgx0crjseN9fjPzMrtCwTiG52nrGM1p /nSJKySHi8J6w3U80V/ToTBdorLGWR5fX94upNNKBmeJvUWwC5zjFV0yfL78tvjI8eJHZNKN7xdZ 2As8x5JQV6h8F9itF6PqFmHWPmB55pVS3nQBxdtfVDgcf736KdpD1fl6ooowCiYNVu1L1WfcAwOv 4S3M4RhKmMIA3sAp7cxpjGnM9rH6ggcVMSzvZlhuHYCwnvEkeYmxmn3yIeDCa41GMCm8Wwviwe+O 5n3hjAsmAQXP4Chm4FGMv4QJZWa6Nbzt6AouGd/g+2tbQMFNtAkwkHAAZ8Qy1LGGGTTNP9CVvBud bna2h74t0T91EgVnXhirdlCoJBYMo2ZfUaVq0uuIxlF+naSWCbqZdUqCQbNPJAPVwY20zqLUpmRL 2vkf8oVidmfkU2DwhJId+NaR/Yy8EXEf0O5h9AcU0YTsO3hJXtivoy3Jjsge9n/LI6dUkSAXO1ie 6JXzjFr0OmC26DU1Zi3kLppTCgos5XwMDymbrY5O/27e+frRjj4LfdqZ8klhgSCNjKN66qibpiHy EyIfJHRCIcxiEEEeJ3nBtJcbaTYuzy6mcW4zK5lfmgQUNHvwPjStm3/HB2rkFlRoE4/v/dUNzzU4 KKTUCmVuZHN0cmVhbQplbmRvYmoKODMKMApvYmoKNTM0CmVuZG9iago4NAowCm9iagpbCl0KZW5k b2JqCjg1CjAKb2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAow CjcyMAo1NDAKXQovQ29udGVudHMKODYKMApSCi9SZXNvdXJjZXMKODcKMApSCi9Bbm5vdHMKODkK MApSCi9Hcm91cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9i ago4NgowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjg4CjAKUgo+PgpzdHJl YW0KeJydUMsKwjAQXPA2n+FJD9akefaooCiKUIl6FkWL1EfV/8ckpYiCF1k2O7PvTQWeMATp1UBJ 5u3ujAoeMJ5pq5iMGd/cJwVzhtDKaBbLyzdJjRRpACW+SHgLbHDxQ/qD8lZsGY6PuEmj9+NfvQsc kPuuFYRtDnujeFVDgjVp6MWzRHErRXNQnD506I+vlyeHlj7JHT4/ymQJk9oaBS5tooViGVxd7vbo kKElrWhMM5rQmtrUIkFz2kTPNMYWwd+FO2Hk/M75753rYB7lBXquTWwKZW5kc3RyZWFtCmVuZG9i ago4OAowCm9iagoyMDkKZW5kb2JqCjg5CjAKb2JqClsKXQplbmRvYmoKMTEKMApvYmoKPDwKL0NB CjEuMAovY2EKMS4wCj4+CmVuZG9iago0OQowCm9iago8PAovU3VidHlwZQovSW1hZ2UKL0ludGVy cG9sYXRlCnRydWUKL1dpZHRoCjc5MwovSGVpZ2h0Cjc4MwovRmlsdGVyCi9GbGF0ZURlY29kZQov Qml0c1BlckNvbXBvbmVudAo4Ci9Db2xvclNwYWNlCi9EZXZpY2VSR0IKL1NNYXNrCjkwCjAKUgov TGVuZ3RoCjkxCjAKUgo+PgpzdHJlYW0KeJzs3QlYW1XaB/C0tfq5O864zajjPq6on/s48yk6bjOj ODq1OqLjjJZxH3QcLS20FdfUbtS2QmkJa6tAl3RLW5ouUEoKpCwtTUtDoUuABggQlkBuLv1Otpub lSQETpb/77n6tCGEl/Sce96c+95zTp8GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACAkRKY0I4CAAAAICQJrGgHAgAAABB6kEoBAAAA+A2pFAAAAIDfBDy0YwEAAAAI PUilAAAAAPyGVAoA/IBTBwCAGa7xAYAfcN4AAODglAgAvsJ5AwCAg1MiAPgEs9kAAHw4KwKAT3DG AABwgBMjAHgPZwwAAAc4MQKA93DGAABwgGt8AOAlnC4AAFzCuREAvIFzBQCASzg9AoA3cK4AAHAJ k/YAMCycKAAA3MEZEgCGhbMEAIAHOEkCgGc4SwAAeICJKQDwDKcIAAAPkEoBgAc4RQAADAvnSQBw B+cHAIBh4VQJAO7g/AAAMCxM4AOASzg5AAB4CWdLAHCGMwMAgJdwwgQAZzgzAAB4CdP4AOAMpwUA AO/hnAkAfPiEBQDgE5wzAYAP5wQAAJ/gEygA8OGEAADgK5w5AcAMn60AAPyAMycAmOFsAADgB3wO BQAznAoAAPyD8ycAnMapAADAXzh/AgAmqAEA/IZTKADgJAAA4DekUgCAkwAAwEjgLAoQyfB5CgBg hHAiBYhk6P4AACOEVAogkqH7AwCMHM6lABEL3R8AYORwLgWITJiUBgAICJxOASITOj4AQKDgjAoQ gdDxAQACBWdUgHDiTY/GdDQAQADhpAoQTnxKpcYsKgCA8IbzKkDYQCoFADD2cF4FCA9eTjKjywMA BBau8QGEB2/6Mvo7AMBowKkVIAz4lEqNZWAAAGEPZ1eAMIBUCgCAFsz5A4SBYTsyejoAgH9QiQoQ 9gT2hn3OGIcHABDSkEoBhD2fUqkxjg0AINT5VEGB0yxAKEIqBQAwejDzDxD2hu3m6OMAACOBT6wA YUzgxMNzxj48AIAwgIkpgDCGVAoAYAxg/h8gXA2bSqF3AwCMHD63AoQrpFIAAGPA+WTr4XxLJUIA 8A+6NgDA2Bg2m8JHV4CQg09JAABjBqdcgPDD77P4iAQAMNq8n5iiFSEA+MT7VIpSgAAAYcXlWZd/ jsUHWIDQglQKAGAsuZyVcpdNUYwTALzkOZXChyMAgIDzfmKKXowA4BWHLoxUCgBgDLg793JnWpx7 AUKFu87r7gkAABAQw+ZOOP0ChASkUgAAVHhIpQTui1cBINh4TqUwwwwAMEo8TEMJ3NdQAUCw8TKV ohcgAEDY8nAhABNTACHBw2cil38FAIAAcjnvJHCFYpAA4IGHLnwac8sAAKPP5WkW2RRAqEAqBQBA FyamAEKal6kUvQABAMKcu2QJqRRASEAqBQBAnbuTLbIpgCCHWWUAgGDg4XyLszFAMMOUMgBAkEAq BRCKkEoBAAQJLyemqMQGAO4glQIACBKez7o4JwMEIXcdE6kUAAAVns+6OCEDBBsvUyla4QEARBqc ewFCi7sOi1QKAIAWnHsBQghSKQCAYIPTL0AI8SaVohIYAEDEwhkYIFR46K3oyAAAFOEMDBASPHRV pFIAABThJAwQEpBKAQAELZyEAYKfN6nU2EcFAACn8ZEWIBQglQIACFpIpQCCHDopAECQw1kaIJih hwIABDl85gUIZuieAADBD+dqgKCF7gkAEPwwMQUQtNA3AQCCH1IpgOCEvgkAECpwugYIQuiYAACh Ah9+AYIQeiUAQAjBSRuIeJEocfnypIzspOWZSZnZxiMje0ZmzgxRdpLxyJlhenCGyPgI+bP5S+av kj8nmR/JND7T9GTySE6S9QmJmdnmP0/PyElYmvXJd9m0f91gh14JABBCMDEVOcg/8afLl09fTlKa LGOmJDJlR5mWdGhMD2NmZUy3zDEYs7WM7M/S0mi/Q0EBXRIAILTgvB2uyD/o1IyMRFFOoijLlLSY UpfgPri5rERjjpc5LSKTK3RJAICQg/N2eHh01qxpGRlJoizznA/1vCgwyZXximG2eQ4tQjIr9EcA gJCDT8Gh65MfshOXZyaJLMVI1DOfUT9Mc2uJGcayq7gwzazQGQEAQhHO3iEkwTj1lB3YqaeZmTnf rsxftHZ95paiwuLdkvLKHdU1pQfqKg7X1x5tPHziRGNLa3N7x6nOTnVXV3t3d0e3VqPt6ezp6ert JQf56ylN58m29qbWU0pV86HjJ/YfbaysP1Ky/8CWCvma3XvypDuWbdq8cI2Y/JTApVXGKnfj5UuR 6IOFC2n/swQMOiMAQCjCxFSQ+2jevMTlmaYb6EZU8vR5dt7C1eKcIulGWfmeuoMk52nu6ND29bEs O2a/i95gIMlYQ3OzvF65vaqGJFokf5tXsHqkaZXxrsOcxPTQvj0QPREAIEThBB6cpv+QlWScdfHz Jrsvc1embdgkLi0rO6g42tLS1ds7NDRE+3dyS88wJK+raTgq3Vf9445di9auI4mfH7+1aTGHrBnL s94QiWj/Tj5DNwQACF04hwePBJHIlDtl+zoB9e3K/Nxt23dU1xw8dryjWxvMiZM3DCyram+vOFxP ssEl6zbMysr1/QqgceWHEFpmAd0QACB0YWKKuqSlmcbVL32ZgJqZlUtyjPVlsiplQ3u3lvZvMLoY g+FkW9texaH8ncWzfyr0YZ7KePnP+P93Fy+m/UsMA30QACCk4TROxSc/mO+/8zp9ysxJXb9xa+W+ hubmQT1DO3xq2ru7Kw/XF+4qmZO/yutrf5Z1q4L22h/6IABASMPE1Fgio7lx1XGvM6j5hWvEe8oO NDb1DQzQjj3odGi15YcO527b/kXOCi9zKuNCVUGWUKEDAgCEOpzJx0bSclNptBdJ1MzMnGWbtpQe ONgR7hfvAkVvMNSfOLmhbK+3twSKchIzcoKkmAq9DwAgDOBkPnri0tKmZ2RZ9gL2eCRn5+Vu215Z f6RXp6MddQg71dm5q6Z2sXi9l5NU05dl0Q0YvQ8AIAxgYmo0TEtLS/RiPajPs/NWbt95oLFpQK+n HXJYUXd1ba+qWbhG7EVOZaykmjRpEpU40fUAAMIDzucBlGRa1mDYVaGWbpSUHzrcjyKoUdaq0WyT V80rHPbaX3aiKCt+zCup0PUAAMIDJqYCYvqyzGEzqPmFa6T7qsN+EYNgMzQ01NDcnL+z2PMSoOal PqdnZIxNVOh3AABhA6f0ETJey/NYUj4rK5eM402traG+hGao6xsYKDuoGL6YSpQzdfRnqNDpAADC Cc7qfiBvV+Jwy0PN/qlwe1WNtr+fdrBg52Rb++qSUg+TVOartIlpmaMXAzodAEA4wcSUr2ZkZnq+ NW/Zpi21RxsNY7hrMPiqp79/e1W18Md8Dzf6JWVmTx2dS37ocQAAYQYndi9NX5bloSZqVlbuqpLd LR0a2mGCtxiDQV6vHOaqnygnYVGAV05AjwMACDOYmBrW1GU5HvbL+zw7b90emaanh3aY4KeG5ubl ki3uL/kZr/oFagMadDcAgPCDc7sHCRkZSZluJ6O+yF0hKa/s7uujHSYEQFNra+aWIg8zVNMzsgSz Zo3wp6CvBZBg1qOCuZMF80xH3D20wwGAiIbTu7NJkyYlirLcjapf5f24bV8VligPP8dPqbO3bvNw vS8pI3skr4++FkDGDGr+y5Zj3ku0wwGAiIaJKQdkuExyU1v+eXbe5vJKbDQc3k62tYk2u56hMm89 89GyZf69MjpaoBinpObzU6mXaUcEAJEOZ3izqUuWGFc5cHNFr7B4dydqoiJG/UmVu6J0kmknZmb7 2l/wmSWABPNfsuVR5JhNZw8gAAAOTvLE9Ay3ZVFZW7c1d3TQDhDGGjs0tO+Ick7+KncJVdLyHO9f Db0sUASTJtlPSU2mHREAgFEkn+QT07PdrVu+RLxBqWqmHSDQpGeY4tr9X+X96Or+vuwZoqy4tDRv XieSu1hgCea9bDclNQeFUgAQFCL2PJ/kZjKKDJ1lBxUsFtsEE21fX8GuEnfl6NPSh19+KmK7WMDZ p1KYkgKAYBGBVx+mpaW5u6KXv7NYi1UOwElDc8vC1WKX01NJGdmPelwtIdL61ygRzJuEKSkACFoR dao3XZpxkUelrF7b0IwreuCWgWWLa/d/kbPC5f19SUtd798XgR9VRolDlZRgFt5PAAgiEXK2n7pk SZKrmajk7Lyd1bWMwUA7QAgBnT29OUVSl9lUosjF2lOR0LPGgGDei3ZTUnMxJQUAQSfsT/jTl7ue jEpdv1Hd2UU7Oggx8nqly3J00sY+WLiQ/8yw71ljw2EtKcEHz9COCADAUXif8JNcLWA+Kyt3R3WN AeXl4Jeu3t4sVwukG5dKyLRd7AvvnjU2jFVS/IJzrHAOAEEpXK/xvbt4scsK8+/XrlO1t9OODkJe 5eH6L3NXOjewRJHlzr6w7FZjzLjjnl2VFKakACBIhd85P2lppvNFvZmZOVsq5KiMgkDp7Oldtmmz y+qpX0VFhV+3GmOC2Q7LcmJKCgCCV5hNTLm8U++7nwobW1pphwbhhmXZbfKqmU7Z1F/f+yBsOhQt dpsXk5wKO8UAQHALm1QqKcPFRT3R5qKefh3t0CBsKVXNwh8L+E3ukedfIL3pgosvph1aqBLMesYu lcLmxQDB7ZL7ei+8P9Lv5AqDVOoNkcg5iZqZmSPdV80ODdGODsJcT39/5pYiruHdeOddpDc99bfY pEwf9uwDjkMeJZj9Iu2IAMCtSx/sufTBvsse7LvkgV7asdAU6tf4EjIykjId56O+XZl/5KSKdmgQ KUjGvqO6xtz2zjn/AtKV/pk007xOgsDjoujgQDDL4cY9TEkBBLXLHui9zJRKGbOp+yI6mxo/fjw5 +f/8l1cuPDbwbSOb3MAmNTIJR5n/NjAfK5kPjzDv1TMf1DPxSuaTI8xnR5nERmZWE/tVIzvnhCFT xaxr1W060kElcpd51NKNkq7eiP4HhUBh2KE+w9CpAfZgL7u3my3tYnd1slINu6WD3djOrm1jV7ex 69pYSQdb1MHmN2o+KdhCutL4CRNmrtn8deH6L1YWzMzOc1h1CjywW5PTmEphSgogqF1qzaPIcen9 EbQF26xZsza2DqY3swtOGL5oNExTMq9sPnDBLXf9+qucK2T6CSV6gdfHBXv0N1boH6lmXlMwnzaw MxqZ2ccNi08YCloN+Q2a0f5FZmRmJokcr+utLinFnXrgH5I4tQywOzXsylZD6kmD8JiBfI54qpa5 qUJ/4R7vOsWOPsG9jwtiP71Mpr+zUh9T3ff+/u5pB7s/P6qff9yw9CS7/pQ+Pz+f9i8apASzBPYF 55iSAgh2JH2ypVIP9AruCee92Gbt2LGmmVlygowOzGcNzJ/3M1ft9SFl8uk4t1R/3z792/WG5CZ2 4XFDRrN+/Yn+gP9GiaIc58WjdtXsD/gPgvCmY4cUvez6NjZdZZh+1PBwlf680tHqGr/aq3+mlnzo YEiSRj5xFLYY8uvqaL8BQUQw337z4rlIpQCC3cX3dfAnpi4Jx4kpgUCwuoX5/oQh4Sj70D5m9MYI d8f4Ev315fo3DhmETcwyFZt/ojsgv9d05z31clYcaGwKyItDJNCzQ/t72LxWw8dK5oYKY0Md465B PnHcX2X8XJNy3PCTipmFkipjwTmqpABCz2UP2sqlyEE7nEBa1zK46Lhh5lEmuoY5a7fp7P153rib 7j73nS8DNhzkHxGklnh7rGq8tlz/7mHD3GOGrGbDpiNH/P7VEjOyHBaPmv1jwQl1WwDfPQhX7NCQ so8tOMXOOGq4sdzUjLdoBM/HnX9vtGBpaWD6xa4BQXqZ911jws7+/6tmkhqNH3nWqPW03yFqBHPt q6TmTqYdEQB45Re8a3ymiqlwqFVe0cLMaWJeqLPOQZGR4i9vX/2bW1evXj04OGgwGDZt3vyruETB jv4RDhkTpb1v5u/YUlZeua+qclhy+WW7LT/x9kp94lEm9SST3erzyplJGY7zUYvWru/sCYd/OBhV hqGhim6WpCv3yK1teMlOwW0P/O1vfzt06NDQ0FBHR8d/v/xW8N26kWdT14kPz1kn3VtVQ5r9sD0j dcM283edU6qPOcB8d4xZoWJov1sU2FebvyyYhGU5AUKDQJB/6QPhU3xeqB6Yd8zwZA1ju1rxn8Uv v/yKQqEYsl9eifx1d2nprW/+15hojWzUGFei/5tCv7G1v13bO+RxEadd+w/xv/HKvfqpDUzaSdb7 RRicF+FM37hZNzjo/1sGkeFAj/Emi+u4+sBdA+ff9XBqampPT4/DM3t7e4XfL54wI3PkCdWv9uq/ PGaoadMOeGyipNc8vKuZ+y7SeR+vYeYeY/JbIqhh2+24hykpgFAzbe4gl0pd+2hfiE5vzJo1a9Fx 5u8KZuJuu5P5+aX6HU2n3GU45PGamprfxv1HsPb4iEYNSbsg+q9PP/20SuVpKSfy4+4tVjt8760V eiEZNVQDw/6OzoseZG4pGmQi8fM7eK+HYXNbDPfvc2y0L1T3qbvcVu4NDg4uz845+6MFI02o5ksm XHn9okWLGI8N9Vhzi8M3nkE+oRxkFh43zNqxI/BvSvCx33HvZcGsR2lHBAA+ONnKXv6QbWIqVxx6 Q/NGde93xwzXuL8j75pyfckxTwmVUql89oNPBSvqXL/CrgHBqkbXXyrqEvxh8h+eeKKhocHl65MH WZbl/tpwQuX8IhNK9G8dMiw5zjp/OydRlOWQR+VJd2DRA/DsYA+beNTg8PmCf7x5oK+9W+vu20n+ s2qt+OdvzzJ2AZevQPqFuy99v23clTcsWLBgYMD1xwR2aIjfZd7ccdjFvJaM+bbJkN8c5jsfCb5z 2LwYU1IAoSf2PzoulXr6nyF21vrx1EBiA3Om+8GCO26o0O/xmFCpVKo3PkuyFd/+dFjw1/cnXn1j 3L/eTtt/wvEFt2kFT736yKPR9fX17l5TNcC+UGfMlKY1DB7v6DYNHUOv7jjiMryHq/Qpx1znscY6 c/s8qnBXiYH1lHoB7O1mYw4w3swdvV3Xq9E6XunjGLctlm6/5q3PjG3e/C1f5QseeOq626MWpme8 pHB6wR+Kx139m9mzZ+t0rk8mJImSaNhLyvQ3VehXH+vSDRgv5Gl7elzGRvLAzxqYzGPhfLHPLo8i f571PO2IAMBnW0oM/OLzA/UhM0aLT/V+qmR8uo/75gp9+XG3CRVhLL79/Ktb//fetLS0pqYm85zS l8cMtheR9gr+9MZvH/6dcwkWRz3IvnrIcRQjuVzh8e7qU13uYrtTrl9wwvHNn27afYOfR63bI8PO euBZZTcbXeNDvyDHh3U9Hu5fIE29vLz8nqeefTX2taKiIq1WSx7RG9hz+QuMkI8h19z61Vdf9fe7 XkiNfMuOLvZXThPIrx9iDrR2TqvvcxnYuBL9R0eYtarAL84WDARfT7LfdA9TUgAhyWAYuuvZfi6V +lQYGh8AZ82a9WWTp4sXHo7bKvXyE2rPVeIczaA1jyJJVMyUex948MCBA+6+VzPIvl3v1VSAy+OJ /UzqCdtluxlO81EbyvYG5u2D8KXSsa8r/GyEnyh6unu9vf1kzglr11heLrj+jpkzZ/a62bGI9Jey bva6cj/7xYQS/eeNhrTKysC9ScFCMO8lfh4lmIcb9wBC1ex0W/H59Y/19elCYNLj+xPM1eX+Jy3m WaCaY82eEyry1ZfNlzC+WXX3vffV1NS4e75Wz37SYBhJPObj0waDeblC074wdvNRq0p2e5n+QST7 4eRI2+E0RXfPcNs4dumtP+XBZ6ZNm+Z8M6AZabH7ethbK0faLy4r0y9wcwU8dBk3L7ZbAwFTUgAh LBSLzz/0e/JH0i54f7bg9gfvffh36enpGo2nzfLq+1juc/H2JjXrqkKpj2FnNAUgiTIfV8qYRScM ienZDvvrrdy+0+VPB+BrGWBvrvC3+S3fK3jurYlX3ThlSty2bds8tDeSIL1uvYT9B3lva5fWOckn jxzoZe9xunnQ7+Pd+hA4L/nEbkpq/mTBHGxeDBDaQqv4XHyo7W65P6nUuVmVH2YUFh84rO3XsUND ng8DO3S3/UBwfql+SWOPts9StqEzsMIThnEBGim446ND/TPs86jsrdtwvx54o6iD9afV7ei/Y8Gq xRu21ataSUsbtmvU9zp+dni4Wl92st2cfZEkinwG+X11gPvFLZVMWrPb+w1DjiDuHodlOWlHBAAj FVrF598odGO/oR7/eFmhn3PCMGF0XvztPUf5edSyTVv0WD8KvJPb6lcqFaCDfNZYeNLw9P5RefGJ u/XJR0KjktMbdtXmWJYTICyEVvF5cp024HNBluOzNOMOYvQGI3JMlau4POqHdRuxnjl4b8Yh16sK jPTYpBa8/bVtPQQax00V+qnKMNmkT0DYpVLIowDCRAgVn7+76/jPywJ9rv7ix/Ovum716tUtLS3J 382f8L7QxXN+KBb860tvj8RM401/vkfyWfkJcx41J3+Vti+0d/OBMRa7x8UysCM6SBt+6tU/PPFE Y2NjeXl59FsfGkuqnJ/28ffe9guSkrl8heGO/5Xr5zSGyccKxykp3LgHEC5CqPj8VcmBxyv9yVJc H4u2T/jV9UuXLuVvb0H+LNm85ebXPrSlQ7sGbo66u7W1Ve1ZW7ta01XVovn2GHOD7wXA40r0M2UN JI/6IndFc0cHxTcZQtFbJY1nBDCPevmjO//3Hv7qH+QPpI1//t3cCUkZtqdNTSeG6RdEe4eqo2vj ye5/HmbO8j2Yyft14rY2um9voGAtKYAwFirF58+vqXtt76kAjBQ5tYIbopKTk92tzGxg2efqrE/+ y9tkTPEQ1SDDHOxjF6kMd4/grqUHK/qnbSmfmZmjOHZ8dN48CGevbqp5pNL1Wpe+He/PvvrGm0tL S92tv6Hs0XPp0A233+n5dj/NgH57J/uhkjl/BCWOH9d2hseWfII5L6HgHCCMbS5mQqL4nKRSN2aW /r5iBEPGmibBXb9/5513urtdb+rKDg1t1rCXcZcRN6mfffY5z8s69fX1fTn/e8F8id9RTdytf72s +SPxrt0H6kbnnYMw95e1la/uPnmWX0vXWo4Z2Rdede2GDRvcZUfdDkuovfRhVVWVh5BIrzl48OCD 70w1rkPib1QPVPQ/u6kuTFKpedi8GCCchUrxOUmlBHM2vihtuLLMzW6qJfoHX/r7hZPfM6ZMDl/a ohH83/MvvPBCa2uryxcnSdS2TvYKmf133fu4Wq3mnsOwbJ+biaze3t4ZcxYIvt/mx3jxRlXXhYuK hMW1o/KuQQQgqdR5C7e8WdXptpl9Xfjk628J/rvExZfmSyb+6trMzEyDm5U3evTstEb7ZRC2aJ58 +mn+5b8u3aDLjY3Il/bv33/P258ZO6CP/eLyssHJO5tuyd4TBqmUYN6L2LwYggujkhQQkia7tUYY nU7H4OZxf4VE8bk5lRo3Z+ObsuYr3GRTz363nHysPnz48Mczkie8MV1Q1CXY0S947q2Hf//7hoYG l/NL5MGdXexVTnuECbL2TU2YdtqUZSn62H83WNaS+lbRMeDm9rqenp6p384VLNnp/XjxcpX2+szd 5PcqbGgf3bcPwhdJpUgTunrZrtequt3d5Vpdu5+cJDdJJA++GieYLTY+KKoUXHOrUCgcGBhw+bK9 DDvT5Tq0D/2xpaWFPKGfMWzoYO81Xdq+plwvO9bqrotVV1ff+U6C9zcDXrpncMre1vFzN4ZHKvXk mm+4POq8xf/oHsB9JUCZplgoMBGrjImTTl2bmhAr4ETFJIskKqRUPnIoPs9bF4zvoDmVIgc5wf5j z8mb97rKpnYNHG1sND+ffMquqKh474MPqqqq3J3hd3ez17jbIyyndkeH/tsTBudKj4kl+ozDanfr Z3Z3d3/8hdC4zavHweLM3fo3q7uvzSgx/1KrjyKVAj+ZUylyXLVs15Tq7v9xdaXvznk/mXsB+X9n Z2dOXl5SUpK7nV/6GNZuO2/742nJwdJuXj0h77hnn17R3Oauu1XK5be9M33YW1yv3zvwlqx5wtxN 5DcKg1SqofvUxJRXuVTq87JC2hEBMJKEKGPKFJ2iIWmVXCRwLb42fNbHHSPBX3zOpVLm44+SQy9U 9Y53Og//YbZo2E3rzBut+nGrHf+4sFS/7kiLu9oSMlq9P/MrdzeAXysbeFfe9vMl27hfB6kU+I1L pchx0aKidyrVN7r6oFEh91TdZBaQxfyfrh080e56bybS9fbu3XvTv1wnVOTnPrev97mt9dyvEwap 1D+LUrk86pzvX2/vx+AEtDGKOFOqFCtScH82TUbF5UmkBaLkaO6R2Dy0V58Ef/G5QypFjmuXF7+/ r/2OcsdRo/6I0sPrGAyGN6Z9blwAamTjhfm4aq9+d5Pr6xpER0dHXP52/vPPLdW/Vq2N2Vo/zv53 QSoFfuOnUubjz5sPvVGtdZhQvXl+oedPGY3Hjv/8xThB7v6AdI3XD/R1aN3ud1wq23udtJX//FvK B96v6rhBVMr/RUI9lRLMm3T2969zqVT8zizaEQGc1spTzZmTuIlR5FkzqahkJWN7BpdfiTAz5QuD YejO4C4+d06lzMdj4v3vVHfeUj7InZN/Pztz2Impnp6eDRs2/j52imB6xshHjTvk+v0qtfMP7WXY 9BbLXjMkiZpU1ftmmepni7c5/xZIpcBvzqkUOS78fus/9px8ubqHn1DtKa/w/FKkDTc1NQnnp/zs hbcCklNNrevq63ec5TZv2PfiQctzbto7+HZ115Mb6sY5/RYhn0rNt62BcMaCvx3rDpM1siDIaOVS iVgiFktkmmEeNCo2TztFCdWn1cIoS8pUoLQr7GkSx5sfjxbKxuI3CCP84vMbHg+64nN3qZSpemrT 4+v2v1eleWJf/zmmgaP4aIt2YNCbo6a5/f09jQHZWe+x6oEmdceQCRkpXj9k2Xz55orBf1Rr/1F6 8tIftrv7FZBKgd9cplLm4xdLpH/ffeLN6u7bTJ81rluj6NJ51S/a+3SrDjTeKwvArjHjSvQLFG2D euP+L4MGdl07e52pQPHsUv1j+/rfq+58akPdGfM2uYw/pFMpwaxnjeseWFOp1zcvph0RhCmtzHpJ Llqm9figkdKcJMWkyE9rii3PMaZV9tRSS5IVner6aj24McbF52+IRInkyMiekZmTlJGVlJEzg/xZ lJ2Uafy/cRcVkemvxkdyyP//nbvW3XjBHddnlLxecpx8wn1Yrps4kmV2RnA8V6c3jxRX79W/Wt3z TqX6sbW1/7Ngs+fIkUqB3zykUubjrPmSR9bUkKb4WnXPtXsHR7X9uztI4vTPwwxJq84o0T9YOUA6 6RulJ24y3b7q4bglqzSEU6m5timpcfNf3t+GBXhhdGjlMZasKYaXSrl68PRpncJSZJ6n0Fmv9Ami hcWOr8koE6z1UnJc4vPRKBWffzRvXlJm5nSSL2VmJRnTJPOR49Px3+zCYVMp8zFuzsY7csveKmv+ V3XXM/v6rinXj9Y+yE7HBXv0D8gHXq/ueXdf+582KS74fquXMSOVAr8Nm0pxx3kLtz6z8eC78ra/ 12gflA9cuGfsUinyyeLpff3/qumeImu+a8Xe8XO9CvjWrNK4ykrab7A/BLMe5a8l9ee1QtoRQfhi VKL4OCI2LsV2mc7lg6dPy1PMGVZCE0mrai2plHGGypFWFOMiEwNvOBSf1x3xs/j8k++yZyzPSsow TyjlWGaZRnZ4n0rxj6vSdz61vo6cvd/ep/lbdc//Vg7+oiyQmRX5rH1duXGMiKvpfrtC/crOxrvy ZMPOQSGVggDyPpWyzVMt2ByVK5u84yhptHGmTxzXl+vPGcEOL87Hz8v0d1UOvlzd83aVJm5vy9Mb 665etsvXOG/N2j0jM5f2G+wP/pQUOUpOKmhHBECokqNs01AqabI5W4rLc26ftlQKs1K+cig+/2y2 D8Xn/0lLS1qemZThz4zT6KVSDh/J7/ux4oWiI1PKVHFkBNmnIfnPS9W9j+zT3SvX31Gpv7HC+Nn5 0jI9+bR+1m5jofjFZfpfyvTXlutvqdTfJdc/tG/gz/v6/lGjjavqjKtsIwPEa8XH/rBuvx9jBFIp CBQ/UinnTxyPi2tf3dVEmrSxYVd1/rNG++eqPtLg75YbGz/5vEA6AsmOSKcgXeOCPcZuctVeY5e5 vVJPug/pRJOqeqfUdBu7VYWadLEXtx25/6cK7ydm3adSOYnp2bTfY5/x86iHfkyiHQ6AEdNUYE6P Uk335dXmxfP/ag+p1Ig4FJ+rXG+0YkHe5SRjyZOxlikgU0+jmkq5PC5cVHSTqOSuPNmD+ZWPrKl+ akNdzJbDL21veL342N92NpK8608SxePi/b8r3Hfvyr235+z5ZdoOdyWySKWAipGnUs7HhLmbrkjb Tho8afYPF+4jXeCPmxSkO5BOQbrG5O1HSTchneXRtTWk49ydJ7spc/dFi4oCHoYxlcrKJacX2u+x bxympNY1hOQ1Sgg/tSLzkubx5kt+XK2U51kpXODzg0Px+ZTpLjaViEtLm5GZmZSZnTSy9OmbFT8t Fq8XbS5auX3n2t17NpdX7qypLTuokCkO7VUcrjhcX3m4Xl5/hPyh9EDdTxU1o5FKBcmBVAr8Nhqp VJAc5lTKeLpYHkorMvGrpK7P+Pewa7MAjAl1inkVhASp+e9arlYq1UWtVGqMtew8GBftDgH84vNb nurnHhfMmkVOaDP8moD6Lr8wa+u2zRWVJC+qP6k61dk5qPftDsGGrj7qJ/bRO5BKgd/COJW6LavU kkplZk+aNIn2O+0VwXcv8qekFldvpR0RgIlKYl7fQGhdaIpLpQRxBY7jMXcDYEwqJqX841B8fukD vVOX5cwQ5ST5kjvNL1yzqnj3XsWhptbWfjf7pfokvFOpFfVIpcBPz64O21Tq1mwulcoJlct8gnmT +anUIBuMW5pCBFJaFjaPreVmmXS11j2M42rtp540shTLOgkpWKLTTw7F57/922Evk6gf1m+UlFfW NR3T9vcP/2N8pOzsC8TJuSh+Y3WqtJYcKRtlMSn0BwvzkVLTHPB3DCLEIz/tDdeuYVxXKmcld4aJ F4lov9nDEAgn8a/uCea9TDsiiAgalaqJUGkYtw9aL9jFiXnPYQqsO8QY9+OzUQmt63u6qkgHb/GL z6/6v66E9BXu0qevV/yUv7O46khDj9P2EIFV29YzwtNy/K4TTm2CVR6si+anNPV9HmLQNFQ7vGaM uF5xskX0k8+rHzgcn1dg+T7w0wN5e0a9ayyp9rjisS41nXtmiajqhKJF06TualK3S6SykQR2c1bp 7DWbeCcc1xNTHyxcOHVZTpJINCMzM9G0rm+iKMu42K95PRbTjJbpD6Ylf03rAJvXaTH+OSPb8vjy nMSMrMT0bPJqfv9bOExJCWaFxkXJMMSoJAWEpMm+ZTOMTscQlKIaJTpuNU7ewuYOD1oXNk+Wqvjf arvGJxAk5BWrtTqNSp5s/U4sdT5CDsXnL00tdq59kpRXHDt1imXHaOPj6pGlUqm8HEnbo1V16Gwr mXUc5YaMlAZPCSFzstbhZSVdxscVu3aOcCz7967Do/fWQXi7L7d0JG3Pq66xxPNHU0ZkTqUy65xP vIz6WIy/sV24qGj7oaPcaceYI6WKSM4zw5QXmXdDmJE5SrcPWzKuGaIskpjNWJ710bJlnv8hBMLn 7FIpTEnRoykWmnMBscrcnHW14tTYaC5rEMTEJUtqHTdLCVVerHZu3VPP+XY8RprMe1/sGPc7HuNf Jfzwi8/veO6E+fTy7cr8dXtkjS2t7Jjfk9I1YDhv4Rb/TsgxUmuX6VELM7kZJGlevaVVKUtL+KkU o1bGpe+Myy1xOGKXWL43asnOhI21xSctY1CtdKSp1PKDHledAHAv97Da74bnbddYUmvKkRiJuCTW qV/E5e6MMn7XTrllITq2trI2eWOdXG35e1Oln/NmE+dtOtWvT9+4eRQyJX8O86TWDFFOIknq0jLJ YMP/h3DIowTf/WVM/v3BGSNJMK9EmWJqtxpRrOtcIS6vlnaogaBTxDuXPNk/aNnCOK7A1WSBViKM c3xromLFCsxIBYBD8bkwp+zQ8ROGsZqDcqZn2Yd+9K8mRCozl271t8Q6fmmztMf0pZ5j0bxUStvg OPvk8IK1BrvYRp5KrW9CowU/FZ3s8rfhed01LKnUYOoS969mnbmSbZHaXqTLdMboV/k3MRWVs0fH sBWH66knUR4nr7KSlmf+3/eJDlf3qDQGMGIUlgJrU/2PIs+WJ8QK86SSguQ42zyMCLVAJoxWJS+W SoykcoUKs1GBMpKVz0eJsErlz3iRqTDn4XKp1Pmr0WKFvEktq5RH2aVSjjVR9kdRQVOXSt2lVPeZ 29sIU6lr0nc19tB/eyFEtfQzN2eWjG7X8CKVihafMD7FoOZnTXGl5u9zTtW8Or6oPEm+e0d1De18 afjjsR9m2lVJzX+RVnsA68qTputT1rTKWAskVnLPqRVZH44RIZeCUeWw8nmfjvJCc5Xtumt936Il Rtpi+u5BW2Ws+8N6ge9YQu6ehFUyu+OnkijH5282f6gfYSq18MApLOIHI/HDQX+u8fnQNSypFCvd Iot36BerZHHppiuDS2SSelVxVS3/Po4CtenThl+zUr9M216mNl5D31N3cNhM5psVPy1YtfaH9RtF m7eukO5YXVK6UVa+bV/V7v11FYfra482Hmhsqm44Kq9Xlh86XHZQsftA3a6a/duraorkVZsrKsV7 ynK3bV+yboPwx3w/8qhposxzF7zO5VG3Lv7IVGeVnRD0txyGCp1KLhaLJWKxTKnx/CBhuZgVJVSf Pq22Fk05LZ2ktF7/iinGNQEYTQ7F53nrKM/5kXwjs75j4jyJb+PFFtN4Maj25nOxx7JzVuQ44kjl I06lXtq0v6lXPzZvIIQrVT/zepHC51TK+65hSaVcY07WufouqfikpTc1yXyulZowd9Oyw+3mmszu 3r6v8n7k8pbv8guXS7as2b1nV03t/qONqvZ23WAgJ3UNLNvZ03v8lLqu6RhJurZUyPN3Fi9cLZ7p PpX6Y9qX/CmpKcsWcV9q7+4OYGwRS55iuSQXJZR5fpDLkWJSjCt4y4SW4uvkYscic67cOkWOXApG 16sf24rPn/kn/eXjB9ihOTUt4+f6sAueX6kUq+3RafsH+Yeuvz3ZcbEd6QhnpR76qbysLfBrcEEE qmzvjy70ba1OP1IpZnBQY98vtIOMsqrC4fkJu45xg5P2ZH20L1GRY9ycjV9XqfoYW2VmZ0+PvP7I KU2nnt597IMMc0LdVnG4fn2ZbOlGyZe5lgWvkkTZP0v5p22nmO/f52dZpzo7aQUcTuQplowoOkXu +UGdQmR+MM94+Zrb/STaKZM63SROsExLudg2BSCQHIrP645QKzvn9OjZlAOnzpzv7dyUZbw4rUtx VeYRlSmX7D8mkVXbl517rpUKTCr11Nqq0lPIoyBg9rb1x6z3fMeEv13Dm7Jz83fl1ip7uLMEIyv1 eV2pifM2kY9LnYMuTjWMweD8IC3s0FB7d/eBxqaETXn8KanX0ucjlQo4VbEoLjYuLjY2RdLk+UFr fpVgesjTnry6WkvSFZOCVApGVxAWnxM6A5vX0HlDRrFXJ+d0yx0a8i0uamsTqswLGrTH8lOpJi/H Iz9TqQlzN31W1lSrCcB+OgB8B7sGEsuPk2wkwF3Dmko5XeO2P3IV3HjVVF8f6/uS6b9O35mt1PDn o/gGg3Jpxf/NncrlUTekffhdfiFSKXpUyeZVEITFpr82WS/ixSucLqrYNvNFKgWjL9iKz82GhoaK T/XF7z7qRenUHoX5s6yLO75lStOXdCctdSbeLYYwolTq7tw92crObj39+T0ISz0Mm9vQef9Kb1YO 8bprcLNSnlIp66sNalIyfU6izpi36d1dyh0tfWO/Zt1IbG2q4U9JFdYbi3ZOaTr31B3MLpJ+kbMC qdRYYpoKzNmRZbsTbW18lOU2PefyFKRSMJaCrficj4wa+U3dL2zc77l6KnaXdbPgrpbkdOs6hOly heXyGiu27vxiTqV0LfUxS6SxmTsdjpglDhvE+JZKXb1059za1hrNAO7Xg9F2oGtwwYFT1y0f5o5X b7uGdYlO8aqd0emO/SI2Uxo1Z2P0RvOGFGxB7mZBSlFMelH0EtORLo32OD01fu7GZ9fV/Hi0KxQ/ Xzxe+AWXR90oimeH7H4FxmAY0OOmkrFTa1mLM15pGaY01lopx+16TyOVgjEXbMXnDk7pDD81dr2x 7ZD75dCLxC22DFDb1afqsl2pbOIVzXreOOb0YIv9Pd3e3sEXlbMn5cApWZuOQRIFY8UwNFTRrvu+ Tn3PCg8FS951jWE2jiFdQJpQ5f4pjh3HcpyTsuXVrQdXHu1q7g+iIijvVbY28Kek0vdLaUcU4dTm W/qiErh/CFutlNypeXKpVGxqWKx5DkEvCIvPnWn1bFFz76KD6j+Kq89yVZQurFQ75kmGPskWuyzI 83bGp3tOOKRSxaYVoV2WmpDj2uW7pu89TtK8wyQ4JFFAA2l4R3r0BY3dMyqOuysvHL5rDLOd8WnZ RqnQQ9+x7zgT50meXFNFcrwtzb1dITgTxZm0YT6XR12e9q8BBhNQVKkk5qt5Qpnt/lHrrJSgQOnY xuWpsdbFEEJ7kU6NorigoEDsgvFhqUyhHZ1LSYxGIUqOjzVW/seJjW+vptj4EwuKR7bjjNL0KuQ/ saxp+Gd7TSWX5BUUSPx9TUanJTTECN7N4Cw+d2loaOiUjt14smdubesjBfLzFm51+AweL5anbKlO kVYLVzkvuRmAY/zcjdctL/7n1gPfyI5UawYGWWRQEBRINr+/czCvofPj0qM3iEqcromPetc4N2XL 7/IrvqtpWX+ip6XfEOqXuY90toyf/wqXSgkrxLQjinRKywYxsfxredZLfpZNZHg01lWpXNzcF1q4 9bXci04tDmRaQjDWxNVMSNJRRm6Ow36ZL19fV8HbDjBOGbAkUC00hxsvIX9RioUkAYx3gWSFKQ5J t0YpTY61e4ej41Lkaj8jEy4NxuJzD8iH8VYdu6O1j4wd5Ow9eXPdVekj3SnPwxjx0E8VCbJjSw+1 rzzStmhnxZcrC4vkVbTfAwAXdOyQonuQ5DOkuU7be/zh/AqnTxwBO361dOdfNx2YXd2S29C5vbWv WceGzfRsXNFSLo+6YPE/ugY8TmjDCOk0qiYjNX9OwO5B6wRUnJg/yDHKAm5c5qdYKql1FfTQ3zim NtXNbs32nBcpHQnezoZR0TFxkibmtC4AqZRtdXqTFFmAVk9ViaN4LygTekg+o/mptdK6+JiTKLHT PKc3grn4fFjk86+WGarWDKw5rl1+uGP+/tbE8uMvbz54d27ZFWnbJ/iy4OcF32+9UVTyxJqqD4ob vq1u/kHRtsI6RuitE1B6g6G5vYPurwzgDYYdajF94lh5tJM0ZmF1y4clDU+trbopc/eF3/uQX42f u+my1O135ZaRzywkPSNdjHS0Nce08o6BbmYo1CegnLX2dv7Pwte4VOqzkjzaEYW5WuuFuiih3PWD mmLz6JgsVdl/K1cuRQbJhGKlWqfTyAuSbYN16C91zqVSyRKlTme6CGWmVtUWF8TZJo/iAzfJY3vz U7k6SkYtyRMRklq/czZdnkNWGC8OSMjWGUtzOs1d9o1yxk+5+TNvUbFCqbxWLuUFGJ3qX9MJ8uJz n5CPxgPsUNcge1Q7KG/vLzvVW9LSs0OlLTrZJTneta5Js/pox9pGzYZjnVuOd0lPdu9q1pa29u5t 66s4rr7xNzf/4823GFy5g3BEGnafYeiUznCwU0caPGn2pPH/d96Si35xybx1UtIpSNcgHWTT8U7S WUiXIR2HdJ/Ktn6ldrBzkNWxQ2Ez7+TB1JIVXB511sLY5t6QH46DHJct8O+24z/YJLZsF+Piap1K 6m4OIipBEkqTAm5w70Oqy6Ivrdw6fxQtDdy8lMJy5TRWMfxzvaZx/pdycb+AH69ryZ0siVmTZfGx Ye7cZCSWpTQE0cm8dqKrte7eGCVW+dN8QqL4fLSdOnWKvIPjx48nf6AdC8AYufnmm0mzLywspB1I UNAO9l+0xLZTzJSipbQjCn+KPMvwFSuqdfmgZQvjuAKXH/K1Skkcv7LH/F1CcXhkwLW2+nmXv5Bt Xs78BLWsIJlIIb8+Iy8QxhinYqJEvJt0NcpiYXysdZ4mOi4hRaqwJWGMWi5KTY2P5t7GVFGqyLRa ilpMvpCaKparjTsd5KUkCwnyc+yzLU1tCvnhKSlCYZ7DJTLuomGCuFacYPkHS5C4qPLyaXvr02pL hma5xKmTm98PpwlMe9Z5TvJEhwgU1qkpkcKfPC+Eis9H1b333kvew+XLl9MOBGAsHDhwgDT4s846 qxs785rMrljH5VHj579yWNNMOyLwBqNSyKUSI2mxXKUJg+koC19TKdvehTG2/NL6vYwslVf3zROd LDEnPlp5ivNXk2W2svNoU60Ur5iKf/ukroB7ODrFfpLMWhkuiC7WkkTGehHWVTGbL9tbn+ZmLM0T XDpr+ZxI4akNaGSWqi2nGxZML2LkfxMKueLz0UDSeeO/SkwM7UAAxsKsWbNIg3/uuedoBxIUBg3M L5e+w6VSf10/n3ZEEOlsF/hcLv+mllozqRhzEberMvWoPNMEC3fDo/HZ8cICsTglIcb2iGnfZ12T NCE+nsvCYuISEuKTi1XG2R7zN1svwmptLxYtNGdNKilXpeZ4tVGnyLN8JTbPtFK23PrdURKn65Le b29tq78yvyxvPTFhXp4wPjYm2igmJi4lr5h/W571XYqSqHTqWmmqMCHOJCE5VVrrcTrLCyFdfB4o 1dXV5P0999xzSVZKOxaAUXfHHXeQBp+VlUU7kKCwbP92/rKc5S1K2hFBpONSowSxwlhrrlarVab/ NSmkBbx71WIsZdJckmDML4QSW/6gkVmfHJUqs2ULTdzdjoJYuXXQ42qlarlv1zqkUsZrZFweFpun PM3Ucn9NkDhmI8XW7RKTLTkWI7aWKjnPC3m/vfVprcyyv7X1QX666CRGbLlmZ5s9i45xUWoXFZfa NLLxP5yKz/129dVXkzdz/fr1tAMBGF1HjhwhTf2MM87QaMKjrmRE2CH2N5kfcXnUYwVf0I4IwNvF EPKsOzpzz49KkPBfx3qbm4vURSa0JEHc6gTWF+HV+TvOShmpJMmOcQiM5d+OqYNtOSnbsmAabmGE KKHf9fJqyzxYdLH1BGaZvIoyl57HJiQnx9stGxUtVVvX1ojiF9hFkTQthv/AyJbRQPE58cEHH5A3 csqUKbQDARhdX3/9NWnqTz/9NO1AgsKq+r38KaktTTW0IwLwIpWKipMotc7Pty/7ti1EkKdQ6zQ8 Wp1SYlleiUuTuFRK7jGVsiuOsnCxH6LaWhnF2/THmF9xv5hjhbq3GHGcQ9qjSbGmQ0KJLWPUKqW2 MI1Lk2kLzHNipmwqNkVira1javkraYxg2SsUnxNFRUXkbbziiivCb8EcAL577rmHNPX09HTagQSF B1YmcnnUXbmf0Q4HwIhLjWJTxHKZrJhPKpUrHK9EWZ9vu1pnwluAyz3fUynj6gH8ZCrVRW283XJS 0dHWWwd5U0DR/i37qas1v3Bcge1CvEbVpFQqFE2OYfBXc1XobIVeUU5rW/GKskawrjuKz0+fHhwc vOCCC8g7KZON6J0ECGbHjh0jjXzChAlqdSDXSQ5RO47X8aekVh4qpR0RgBGv7NyrqRsXWZCRriDe acEIJ9zNcX6nUiLn2ni124W/ePxZX9R6F16UxKsFoLilO2NkWtvujc6rdXGF646/qY8cis9XrI/E 4vPJkyeTd3LatGm0AwEYLXPmzCGN/LHHHqMdSFB4evU3XB513fIPDWwk1jZAEBpuMQR3z3dIpbSp 1rUEJE0arcaeVquzYNy+iJsLfGLripZcUuSwCAG3bEJUbEJqamqKDfmbkJsq8+NqmiTBshYn/zsZ E1dP5+bljAVg3NSTi/siVZLoQKRSp1F8fvp0Xp7xzs3bb7+ddiAAo+Whhx4ijXzx4sW0A6GvRt3E n5JaUr2VdkQAFgFKpXTcHjNcgbrta0pJckJycoJQpvItleKtfmBjv8i8Ktk6GVbgastlWyWYr5vI WEvZ+cu6chNK8WKnH2abPYsjyR63M06C0zO5JadGeIHvNIrPyZup0ZxxxhnkzWxsbKQdC0DgNTc3 jzNRqUa6iEoY+NumhVwedUnqlH4mEmtEITgFKJXilrK0LcFkpeGudokcbwP0mErxFkNILtacVnHF SAKhdW9lnUJkTbBc36bHNHHfFcv7WcNub23LmgqabM/hHnRaIPS0zDoNZc7ZdG42wua/G8IR7xCN 4nPiscceI2/mggULaAcCEHgLFy4kzft3v/sd7UDoa+xSn7Hgb1wq9aVs9Wj8FI2iuKCgQOyC8WGp TKEdnUoKRqMQJcfHGhfkiTNtdq8pNv7EgmKFT9dTGIVU7DL8gry8vAJxrVOVr39UckleQYFE5mr+ wpsodVrCdMUqfOpSApVK8VYkEETH5yk1pq1/VXLbNTbeBr5epFK8JTqtuRl31YzLi6TW5aRi89zt 5qfm1sbiVqMafnvr06eLzd8WlWz3UZBR2q43xgplSpWOYXSapoJkW829dVKOV4cfFSepNT5Tq65N ibVOoo1giQY+FJ+TJMrYuKKjaQcCEHiPPPIIad7z52M179PvSTO4POq8RX/X6HpG46dw2164F51a 7GcK4Q6jkvBLjYVy2/YfUb7dM6VNGa5mOTohb8RDj3VvkXjjgkhKsZAkgPEukKwwxeHueY1Smmy3 fJAgOi5Frg6HhMrvVMp562eNLFXgVrSUV7ztcl0pc+phTqWUBfG2b7T9w9su5wniCrTWO+w8b7Vs W1TTuqbBsNtbk5QpwekJZmqZi41vOLGpvGavLna/zESU2M/1GRydaIn04vOGhgaBafXCzs5O2rEA BJJarZ4wYQJp3k1NAR67Q05bf/fZC1/jUqmPd2WP0g/ycqHF5BFfU+DjbZQWFR0TJ2liyIDoXyrl za30JBkcUfQqsXkcNlcgy4Qeks9ofp6gFCeM9oBIkUJk+Ud0cXOcp+fHOt2aZuRy62dBTLLMPu20 vgjv4pe11shYm8Sb/IkvsNsRQKfM414+c+NSy59i8zyEzkv4LT9u2O2tubsCneu+ThtngCXxLtpO jMj5o4pOmRrn9NSYBJlXtwR6C8Xnt99+u/EfKy+PdiAAgZSWlkYa9v333087EPqSSn/i8qiJKa+e 0LaP0g/iUqlkiVKn491BpVbVFhfwRjd/7gp3/0OdblNi1JI8ESGp9Snr4VKpaKlKx+g4WrVKKUmx 3Q0vHMGqhtbluM3jKXe7epQz/hDPn3mLihVK5bVyKW8dI95FK7Ditn6WFsvkSlV4vkMalUJmWnqL /J6yWqWHXE6rUsrI84zPlMqVgV8ZBsXn06dPJ31x8uTJtAMBCKQnnnjCOOoJhbQDoaxXr7t4yZtc KvXGliWj97NsqwO5niyQc3uCebgU4ituJzV3dSpes91I7jJ8boe1aP/vH7eW+1ru5GpKjvLmBRmJ dbmk6GTejWO6Wuu0SZQ4oDMMAL5yKD6f+l3EFZ/v3buXdMULL7xQr9fTjgUgMDQazcSJE0nDrq+v px0LZfPlG7k8atz8lw+2nxy9nzVcxYvtCpr5CWpZQTKRItacZuQFwhjjVEwU/xKPRlksjI+1ztNE xyWkSBW2JIxRy0WpqdxljlhhqihVVGt6YTH5QmqqWE6ezMjyUpJJSi0kP8c+29LUppAfnpIiFJr3 9BgmleLuH+fXruhUcrFYLBGLZUqN5weNrJdsLJc4rZU5yVKPd5hqiq2/YrLDxRuFdWpKpBjJXmoA ARDhxedDQ0OXX3456Yxbt2KdGQgTIpHx9uS77rqLdiCU6Q3MVenvcqlUjPi7Uf1xvqZStt0reHus Wr+XkaU67nzGzcxYbk+Suyi+TZbZys7NW3XwiqkEBbayIt7GapabyoeblbLWNcXxbtTiKu35dVku Hzxtu1Xf8vrcveoihac5JS6Fc96i1/givDUnAShC8fmUKVNIP33//fdpBwIQGH/6059Ik/7iiy9o B0JZVt0u/rKce1SHR/XH8bb/cJWLqKXWTCrGXG3kqkw9Ks80wWK744k8O15YIBanJNiKwmNSjfNC uiZpQnw8l4XFxCUkxCcXqzze0h5tufubt+4id7XRbqVoPkankdt2gI0u5uWJvL3M5J4ftG3TZr2t nlsgSJiXJ4yPjYk2iomJS8kr5tdHW9+lKIlKp66VpgoT4kwSklOltVgwDYLIsMXnQ0NDJZWG77PD 8xLY+vXrSUf99a9/TTsQgADQarVnnXUWadJ1dXW0Yxl12sH+pbXbBhgXpyZy1rot6xMuj/r9TzNH OxguNUoQK4y15mq1WmX6X5NCWsC7Vy3GUibNJQnG/EIoseUPGpn1yVGpMlu20CQVWl/Cto8tVytV y3271tNCi7F5ytNMLfdXbp0f+zv4HCrAbVLldmVeqmJRnHE9q9gUSZPnB09rZTGWn2h5kJ8uOokR W67Z2WbPomNc3LIVFZfquNcvACUeis/bO4cW5+of/KuxnuqPb4Vnk+3v7z/nnHNIr6yurqYdC8BI mXdEuuWWW2gHMhaOdLaQNOmKtLe/LRd3D/Txv7SuoZI/JbXh6Eg32xqWl4sh5DkuN23choP/Otbb 3Fxc0pJZF1vktjNzuTqQi+0/JC62/xDEi3nndK8WQ0gQFfs3DKgt82C2SS3L5JU5VYuOTUhOjrdb NipaakwuTXf52aVzUSRNi+E/YF2qCIAu5+Jz8zTUvxIHrvydLcV64u/hmUoRzz//POmRycnJtAMB GKm//OUvpDEnJSXRDmQslDXXc8nSBYv/8VlJXkuvZY24h3+cwX3p9uxPyDlttIMZPpWKipPw7tjm np9ntzKSjrvPP0+h1tntSKtTSizLK3Fpkveb0hY41l457KZhS6Vik1NNdesWwuQEfupiv/+alxhx nEPao+FWBBVKbBmjVim1hRknZk5rC8y375myqdgUicbys5la2zVHf/bJBRgN/OLzq/+v74EX+/nz VObjkVf7aYc5WjIyMkh/vOeee2gHAjAifX19ETXFur5Bzp96IsdZC2OnFC1deaiU/2D2weIxCIZL jWJTxHKZccEbG6lUrnC8EmV9vu1qnYlXs0O+p1L8zV6NUh1r47mfy7tWyKOUcJcX+eXr3rGuiR3H W+xRo2pSKhUKp/1oGN7WaQqdrdArymkzXF5R1kg3pQUIiOPNBufcyeF4eHLYplKnTp0aP348Nn6F UFdQYByGrrvuOtqBjBHRgZ0OqZTzcfWy9xjWMAbB8MrOvco03OykpiuIH24HF97NcX6nUk4Law9z Bx8hTbBcgPNyfxOO9S68KIlXC0BxS3fGyLTcn12s1sUVrjvvLQIwxto0tmooz8d9L4RtKkX89re/ JV3yhx9+oB0IgP8mT55MmvFnn31GO5Ax8l3l+mFTqXe2LRubYAK0Ka021bqWgKRJo9XY02qti5Az bl/EzQU+sW0XWLN4+0UIhk+lrCXuPqdSkgTLWpz8b2NMXD3d7l5CburJxX2RKkk0UimgylwNFTfd rhrK83H3c+GcSn377bekSz7zzDO0AwHw08DAwPnnn0+acXl5Oe1YxsjUkhXDplLkuDt36spDpQZ2 dHdzCFAqpeP2mHHefUynlCQnJCcnCLkdxLxMpXirH/CmtuyqntwuhsC9LlfE5VttEqOw7ezG/TDr hFK82HnTNG72LI4ke9zOOAlOz+SWnMIFPhh73k9DORy3PdM3/KuHLIVCQbrkWWed1dvbSzsWAH+I xWLShq+66qoxKLEOEm9tTfMmlTIf1y3/cEn11n5mtPZ0CFAqxS1laVuCyUrDXe0SOd4G6DGV4i2G kFysOa3iipEEQtveyp5rpbRS2zZ80VLuOp1Oo2oyUmt532P/IJc1FTTZnsM9aF0g1EZmnYYy7y+j 45VO2V84tb0bwoDuEA3gjdVbGF+TKPPxmyfDOZUibrjhBtIrV61aRTsQAH+89tprpAF/9NFHtAMZ O8+vm+N9KmU+Lk2N+1K2WqPrCXgwgUqluGkcY6IRn6fUmLZ1UcmFXD7E28DXi1SKt0SnNTfjrpoZ i94t32grd49JEKYIrVKIZP4dfNG8Ncy5KaMoodzdg5Zl0qOS7epQGaXtemOsUKZU6RhGp2kqSLbV 3Fsn5Xh1+FFxklrjM7Xq2pRYa0xRQiRSQMXSH/V+pFLXRod5KvWf//yH9MvXX3+ddiAAPtPr9T/7 2c9IA969ezftWMbO73+a6WsqZT5e37w44MH4nUo5X1DTyFIFbvEmhdysKxXDS6WUBfG2b7TlHKpk LjuKKzB9q63A24NYoZQ/M8T9yvyLiXYPMsoEpyeYqWUuNr6x/aBU3jU7dbH7ZSaixL7eTggQOF/9 MOhrKnXl78I8ldq1axfpmb/4xS/YUa6pAAg4iURCWu/ll18eUa33lqyP/cijJm2YPxr39ClElskk p5vjPD8/1mWZt1YpiXO+ky8mWaZmXL0I7+KXtdbIWJvEm/yJ5y1EYHyWMo97edP8j9bT6uPGjWmS +ZspW356nuXl+XVQdg9atzB2rvsiNApJvIslzGNExc4FVMrUOKenxiTIvLolEGAUffT1gK/ZFO2Q R5fBYLj44otJBy0uHotVaAAC6K233iJN97333qMdyJi6JHWKr3nUK5sWjnb9eeAwKoVcSrJkibRY JleqwnMhSo1KITMtvUV+T1mt0kMaqlUpZeR5xmdK5Upc1gt51cqGDWV7uaOju5t2RP4wGIb+/qlv 2RTDhHk56+uvv07Go08++YR2IAA+IJ8CLrnkEtJ0t2/fTjuWsTM0NDRhwSs+5VGxkkWhk0cBhLNp 6ekzRNkzMnPMx9rde2hH5D/dwFDM2zrvU6l+XZinUoWFhWQ8uummm2gHAuAD8jndfG2a5FS0Yxk7 Gl2PT3nUG1uWsEPIowCCQhIvj/p2ZX7fwADtiEaku2coOtbbhRHIk2nHO7q0Wu2ZZ55JRiWFwnEj UYCg9e6775JGO2XKFNqBjKl6TbP3edSUoqWRs0YEQJBLXJ7J5VHkqFI20I4oAE61D933F6+yqfbO 8D8XPf3002RUEgqFtAMB8ArJEK644grSaDdv3kw7ljG1R3XYyzzqHeky5FEAQeKjefNmiGx5lGjz VtoRBczR4+xtzwyfSrWow396fMmSJWRUevjhh2kHAuCVkpIS0mIvuugivV5PO5Yx5byXscvjg+0i 2pECgE1ipu3S3ufZee2hWW3uTu0h9rrHhkmljjWHfyp14sQJMjCNHz++ra2NdiwAw4uPN957HoHr oXmzl/FHO7NphwkANh8tW5bEm5LaUV1DO6LAK6k0XPV7T6lUw/HwT6WIe+65x7g4jEhEOxCA4V19 9dWkua5bt452IGNt2L2MPy3Oox0jANjhX9pLWS1mwvROmfXbmcsfcptKKRoiIpX6/PPPydj0/PPP 0w4EYBh79+4lbfW8887T6SJuzWfPexlP272SdoAAYGf6D1lJvGpzpaqZdkSjKHOV221l9h+OiFSq qqqKDE/nnntuBA5PEFo+/fRT0lZffvll2oFQ4GEv4xl78mlHBwCOknhVUqLNRbTDGXVzlrnOpuQH wnMuztlVV11FRqgNGzbQDgTAE/Me3IWFhbQDocDdXsZfyLAjOUDQSRSJ+AsgnIyMauSp37nYpG9v daSkUu+9955xX6u4ONqBALhlnj49++yze3t7acdCgcu9jL8tF9OOCwBc4K/JuXL7TtrhjBGWHZoy 3XFbmZLKSEmltm7dSgapX/7yl1iOBoJWYmIiaaUvvPAC7UDocN7LeE7letpBAYALn6anc3nUzKxc dVcX7YjGzqB+6K8f2G0rs0MWKanU4ODg+eefT8ap8vJy2rEAuHbrrbeSJrpixQragdDhsJdxyr5N tCMCANf4U1JrdpfSDmes9fYNPfmGLZvaUhIpqRTx0ksvkXFq+vTptAMBcKGuro60zzPPPLM7vBa4 8xJ/L+Nx819eXL2FdkQA4FrCoiyu4HxmZk57t5Z2RBS0aYYemmTZVmbDDoZ2OGMnNzeXDFV33HEH 7UAAXEhOTibt889//jPtQOjg9jImeVRa7Tba4QCAW0kZtimp/J3FtMOh5lgzG/VnYza1piiCUimN RnPGGWeQ0aqxsZF2LACO7rzzTtI4MzMzaQdCh3kv4/HzX1m+fzvtWIIay7KlB+q2yavMR2PLKdoR QWSJS0ubwbu619zRQTsimg4eYW/8Q1/+pghKpYjo6GgyWqWkpNAOBMCOUqkkLZOk+h2Rel7aozpM 8qisul20AwkBVUcauIEsSYSddGBMJfLyqOwiKe1w6JNVG1ZviaxUav78+WTAevzxx2kHAmDn22+/ JS3zySefpB0INZuOVuUpdtOOIjQYWHZO/ipuOJuGLbFgDPELzptaW2mHExRYNrJWBjB/9p84cWJX JN25CcHvvvvuIy1z6dKltAOhhqQHtEMIJSX7D9gmpjIxMQVjJCkzk2t4aRtwj23kuu222yL5fnMI QseOHSNtcvz48adOoe4FvKIbHPwyd6U1lcqJx8QUjAn+8ubVygba4QA1CQkJEbvHGQSnefPmkTb5 6KOP0g4EQomkvJJXMZVFOxwIf9N4y3J+uzKfMUTQYkrgoKysjAxbF110kV6vpx0LgNHDDz9M2uT3 339POxAIJR3dWtsUgSiHdjgQ/kjGzjW5Ivk+2uEATUNDQ5dddhkZubZtw9o1QF9zc/P48ePHjRt3 8uRJ2rFAiMnYvNU2MbUME1MwupJEtp1iOnsicZ9Q4HvrrbdIKvXBBx/QDgTg9KJFi0hr/O1vf0s7 EAg9NQ1HMTEFY2P6MtuUVJ50B+1wgL5169aRweuaa66hHQiAZa2zuXPn0g4EQo/eYPh6xU/cAEca Eu2IIGzxl+U8dPwE7XCAvv7+/rPPPpucdmpqamjHAhGtra1twoQJWIEf/LahbC83wE3HfXwwOuLS 0rhN975dmY+lS8DsueeeI+PXF198QTsQiGhLly4l7fDee++lHQiEqsaWVt59fLjGB6MiUWRbA2Gj rJx2OBAsli9fToaw++67j3YgENGeeuop0g6/+eYb2oFAqGKHhmb/WIBUCkZVEm85KVV7O+1wIFi0 traab5tqbm6mHQtEqM7OzokTJ5JUqr6+nnYsEMLW867xJS1HNgUB9tG8edzVve/XrKMdDgSXhx56 iIxiqamptAOBCJWZmUlaYFRUFO1AILQdbW6xpVIZSKUgwGZk2O7dK67dTzscCC7ffPMNGcj++Mc/ 0g4EItSzzz5LWuDnn39OOxAIbSzLfp33o/UaH/bjgwCbwSuUau/W0g4HgktdXR0ZyP7nf/6ntxdL jcFY02q1Z511FmmBpB3SjgVC3srtO62rS2W/gfv4IHAenTWLWwZh0dr1tMOBYHT99deTsWz16tW0 A4GIs2LFCtL2fvOb39AOBMJB+aHDWKsTRkNihm05Kem+atrhQDD6+OOPyXD2xhtv0A4EIs6LL75I 2t706dNpBwLhoENr248vKRPX+CBg+CtzNnd00A4HgtHOnTvJcHbJJZewWHAMxlBfX98555xD2l5V VRXtWCBMzC9cg3IpCLgZ1nv35hXi8g24ZjAYLr74YjKilZSU0I4FIkhhYSFpdddddx3tQCB8rCrZ za0uhR1kICA+S7NNSW3aW0E7HAhesbGx5LTz3//+l3YgEEFeeeUVtDoIrL2KQ9yol4DKcwiEJJFt GYT6EydphwPBKz8/H9W/MJYGBgYuuOAC0upkMhntWCB8nGxrt23Gl5FFOxwIB0nWQqnPs/MGGYZ2 OBC8tFrtmWeeSca1w4cP044FIsK6detIe7vyyiuHhoZoxwLhw8Cyydl5KJeCQCGnKS6VypBspR0O BDvzPmizZ8+mHQhEhL///e+kvf373/+mHQiEm7QNm5BKQaAkLbNd3dtVg0XOYRiLFy8mQ9vvfvc7 2oFA+NPr9T/72c9IeysuLqYdC4SbNbtLrWMfUikYqUReodTJNmxhDMM4fvw4GdomTJjQ1tZGOxYI c5s3byaN7fLLL8f6GxBwJfsPWJeWyvnkO2RTMCJcHvV13o8sqhHAC3fffTcZ4DIzM2kHAmFuypQp pKW98847tAOBMHTo+Alu+JuWkUE7HAht3OKc2Vu30Y4FQsOsWbPIAPfCCy/QDgTCmcFguOSSS0hL 27YNpyYIvPbubt72MZiVAv/9VyTi2tKO6hra4UBo2LdvHxngzjvvvIGBAdqxQNjavn07aWY///nP GdxWDKPAwLIzrcNfogjrIYD/Ziy3FUopVc20w4GQceWVV5JhbuPGjbQDgbD13nvvkTb25ptv0g4E wtbsnwqxqTGMHGk/5oZEknPd4CDtcCBkvPvuu2SY+9e//kU7EAhPQ0NDv/zlL0kb27RpE+1YIGz9 sH4j1kOAkUuybr23aO062rFAKDHfWkUGOyycCKOhtLSUNLALL7xwEB/xYNTkbtuOVApGjru6t7a0 jHYsEErIAHf++eeTwa6iAps2QuB99NFHpHW99tprtAOBcLZujwwX+GCEpqWlcalU2UEF7XAgxEya NMm4VH5SEu1AIAz9+te/Jq1r7dq1tAOBcFYk34dZKRihGRnZXCrV2NJKOxwIMTk5OWSwi4qKoh0I hJuKigrzLaI6nY52LBDOdtXUYjEEGKGkjBwulerDXe3go46OjgkTJpAhr6mpiXYsEFY+++wz0q4m T55MOxAIc2UHFdwgSDsWCFVczfl3+YW0Y4GQ9Mgjj5Ahb+HChbQDgbByww03kHaVn59POxAIc/L6 I1wq9dG8ebTDgZDErYSQXSSlHQuEpLlz55Ih7w9/+APtQCB81NTUkEZ19tln9/b20o4Fwlzt0UYu lYoXiWiHAyEpyZpKbamQ044FQtKRI0fIqDdx4sSuri7asUCYSEpKIo3qL3/5C+1AIPwdaGziUqnP 0tJohwOh56Nly7gmVH7oMO1wIFTdeuutZOBbuXIl7UAgTJhbVG5uLu1AIPzxZ6WQSoEfpi+33b6H LWPAb1OnTiUD3yuvvEI7EAgHCoWCNKczzzyzu7ubdiwQ/moajnLj4Aeo+QTfJS3P5JpQh1ZLOxwI VXv27CFj30UXXYQ9Z2HkvvjiC9Kc/vSnP9EOBCJCtbKBGwc/Xb6cdjgQepJEllmpmVm5BpalHQ6E KpZlL730UjL8SaW4eQFG6q677iJtKSMjg3YgEBH2HVFyqdQbKDsH382wplLzClfTjgVC25tvvkmG v3//+9+0A4HQ1tDQQBrSGWec0dHRQTsWiAh76g5iXSkYCW5WSrR5K+1YILSJxWIyAl577bW0A4HQ JhQKSUN64oknaAcCkWJ7VQ1SKRiJJGv7KdxVQjsWCG19fX1nn302GQRra2tpxwIh7P777yetKDU1 lXYgECk27a2w7MGXiY1jwB9cKi4pr6QdC4S8Z599lgyCX375Je1AIFQdP3583Lhx48ePb23FfqAw RlaXlFr34MOsFPiDS6VK9h+gHQuEvPT0dJJK3X///bQDgVC1YMEC0oQeeeQR2oFABMkpkmJWCvw2 dckSLpXad0RJOxwIYYahIZ1hSHG8WWCy9ZimuJPdrmG3drCb2tl1bezqNlbcxm5sZ7d0sFINu6uT 3dPFVnSzh3rZtkG23zDEDA3R/iUgMMyNoWOQPdLHVnYb/6G9bwzRTzxJ2s/8lBTavwREkEVr11lS KRFSKfBZgkjEpVJHTqpohwMhgx0a0gyysi628BSbrjLMPW74VMm8UMfcXqk/+5V4wQNPCnb0C0r0 3hw/26O/pVL/5/3Mx0rmu2OGpSrDT6fY3Z3G/MqA5CoUeGgMvyjTj/OuGXCN4dIPv7n4nt+/K1ej McCY+SrvR1zgA7/xlzpvbsd9x+AJMzR0vJ/d2s5mtRi+ajKQ5OdSmQ+jpE8HGVIfr9HPajRkNBsk 7ayyj9WzGEmDCBoDhI3+wUFuHEzCHXzgu0TrRsZY6hzcYYeGjunY1Wr2yybDPXL9WbtHa8R0d0zc rb+tUp941JB/iq3vxewETWgMEH5aOjTcODhjeRbtcCD0JGZkcU2op19HOxwILuoBdkMbO/e44bdV +vHmseyDOWff/sCE6csCNjjm1ApSS7w9NrbeKdd/3WRYo2ZP6MiojmF07KAxQLg60NjEjYOJ6aiV Ap9x63OSYxBbp4EJGZUa+tmsZsOz+5kzzdMOqxoFj754z/0P7Nq1y2AwDA4OinLyzo2fO/LR88Kt 6k8Kt+2qkFfu21c5nB2lZebvmlCif7RGn64yHOhh2f9n707go6rO/oEHKlqtrdVirbZi3VqXSn3F tlbfqlhf/1ptqQqtVepOBBSJgEiWCSEsEsKWyJJIMpMdyEJIIAtkI/u+72QhIfvCJEySmczK/4TJ 3LmZzCSZ5CZnlt/3c+pHQzJ5Mtxyfpxz7nMxh84mXAxg8ZKKSpgz57be3rTLAfPD44/mqK3YIIbr uqQj8+ZfSlhz3NtrN23a1NraqvMXfzKNRkafufMzZ5vU4RnOoTdnyj6vl6d2DYqGxBMvL3hklLO/ 8PcFMu82RaMYz46cFbgYwBqEJKWgEwLMBLMqtSPoOO1agDK5ShXTo3y3Sq5zy9VD+bLytm5Dk5pS qUxOufDAJ5ttEkUzmkND62x+/7+2traiCc/syeXyH2fqfu1rZbLwLqUUR5G5g4sBrMfBiEicOYeZ ICFcfQntORlOuxagqVeq9GpV3JFtcHZ7pkRW1d5jaA4lHy8oKFiyaqNNTKf+V0jotznTrv+XIi7Z PPXixx9/3NPTY+jF2Rs3sUWV41/klkyZe7PisgQrEhzAxQDWQyqTb9XevodVKZgOZlVqX1gE7VqA mlaJ0rFRPpXlgudKZLUdvRPModXV1S+v2TSyqqD+kmPZNq+uvO3+3zg48lxrruq+4OnLNn94+b33 3jP0iBDyglVDyqeLZD/OlHlcEveKBlXXPZIq1Fueba28ehAT6IzgYgCr0tDegdv3YIacBf6aKHWK di1AR/ewckP9lKZOZiwtk9V3TTSHNjc3v7Pmy7+89NLx48fJzKie8l6rYL3ImXabP/2/f/3rX+3t 7YZepF6sfKFUz3pIUmtfTLP+2ZOMd6vkdUOYQKcJFwNYm5SSUiZKOeDMOUwLjz+6KrUfUcoqyZQq 98sKo6ZOZrxSJrvUfWWKN6GXDShHvzCm0+a5N956663xR5fVVNc7F42Zao0cmxvkA3JMoEbDxQBW yP98oqbPOXb3YJqcNS0694cjSlmjmF7lLeMO7ho1Xi+TNncaPIesRn71N/nXP3/1rtdff6O5udnQ 57cPK9+umlE9ZMxPl4V0KmbnDbNkc30xfLYDFwPQpVSpmEfG4Ol7MG1MlDoQHkm7Fphr5I+RtReN 283Rjsgmmw8cbB5a/Orrb4SGhkokE/V3PXNldBXizmxZRYf+tYseqfL9mukWM278rVwmUWAtwgi4 GMAKtfb0ah8Zw8ftezBNPL/Rs1IHIhClrE7nsPL2rOnMTXceTXQOiSqouySRSpXX76iaYEjkyh+N Xeu4N1cW3tQ/LJWpy+iTKdfUcTZvqseCDFnZAGZPI+BiACvEPijF88GZc5gm5qwU7uCzQpWDSm7n LGPHhgbF143TPJwz6UgWYvY0Ai4GsELfn43TRKkAGxsb2uWAuWIeZ7z7eCjtWmCunesUz9bM+MUe 7S3wNMZNGbIzPTLab7A5wcUA1mZQImE6SuHMOcyEk6YZwvbAENq1wFzzq7vC/cy11m3Rw7/Nysq6 dOnSantnG5dAPZ+zO9Lmsx1THd9GTG/2PNs5TPsNNie4GMDalNQ3MLt7jnw/2uWAGeNpohQZeLS6 tQmt6344V8rZvMnzu33RA2fPnlUqtZspYrE46PiJOz+x135aZNO7777bPame3k5hf2ab0OGS4i7D bbcNDfIluVcwexoBFwNYm2DNo/ecBQH2h3BQCqaP6XZOhkwup10OzKlTdZ3vFhhsb2jEOBC34J77 /fz8FAr9d50PyRWPF2g++XfP9PX1GSqJ5PkhqbxwQLnzsuLXedMv6e0iUUM/Zk8j4GIAqyKWSrcF BON5McAJnq8fE6WGJPjTxrqQ2XNpdPkDOcPTnzd982x+/diePXukUqnebyFTKv06FTcxn++Vvnv3 7omr6u3t/cTR1SagZNpV3ZElXZ7c2HgV17MRcDGAVSm4WKe9d0+AJSmYESe+doNPODBAuxyYU2T2 tNkb83FOx62GGjPGdC799/sL3t9ic27cekV4g83vntmwYcOAgctGrlQGdSlvHvvKP3rgUfY8OyxX SGX6zwN3d3e/b+9iE1Ru7NS5IEO2qqD3R57nMHsaBRcDWBVBfIJmSSrQ8SiiFMwIz1cbpVoNPIod LJV69vzhwfjVhb2GJlA3v+MKhaKgoOC99V/brD9gkzpsE9tt8+e/vfvuuz0GLhiFUnWyW7d90Miw 94k8ffr6JyjzRcp3qkc+eFO6LOhil6HNoI6Ojnc2OdmcqDZi6izuu/1w4k0H4zF7GsVELoZgXAww +64ODmnv3fNDZ06YqS0+2suptqWFdjkwp9SzJxk3H4xfU9Dzi2w9p47nRTYNDQ2pP18qlSYmJX3+ xReGHvZB5s2IHuVtBibi2wIK8q8qNjQofjDul36WLYtr6FAaeApbW1vb2xscJ72h/rYs2dpiIZk6 yU+E2dNYJnUxxONigNmUXMzqzIk2CDBj6zw9mSuqqK6edjkwp5jZk4wf7It9N7VpacHQ+Flpm8/k f2sjE190r/J24++uYo9f58lymzsNPdb28uXL/7BzsIm4pPdrn8qXfJLd/sOD8eofB7OnsUztYngA FwPMDoVS6R4azuSojd7etCsCS8BEqfTyCtq1wJxiz57q8T/H89eW9C3SOXt8pt3QGRg1sVj83Cdf 2uyLncnUyYwlRbLq9h5Dc2hTU9NrUUXsz1+YLVtV0v/C6TL2D4LZ01imeTE8XSSrwcUAnKpsamZm PXTmBK64BASpL6pz+YW0a4E5NX72JOOG/bFvJtR9WnL1VznaLR4H70mOZZJ57cqVK0EhIY+89YHN 3rMzn0NfK5O29grHf5ceqXJrk4KZN98vEb2b2sSsP2D2nDZcDGAl/M4laKOULw6cAzeY03cRaRm0 a4E5pXf2ZGaff56/uKak79lCyYIMmU1cb+OVq6Jh6aTjqkSa3ti+IrOdk0WJDyuGhKKRNRClSlUg Ur5UNvLB+emypwqGbUuvvpPS+OPvzhuqH7OnUXAxgDXoFApZp6Rw4Bw4w9NcV75x52jXAnNqgtlT PebtjVkclPNpdvuqkqtPFgzP52JCnMb4b41cffDmkXzpRyWiz/I6/xRa8IN9sRNUjtnTWLgYwBqE paYzUcqJj9094Iyz32jD872hEbRrgTk16ezJ3uh5JqxwdV7nqtKrfy2S3J0zd1PnwmzZXwolH5eK 1hR0Lz1detO47RvMnpzAxQAW78pV0Vb/IOaU1JYjR2hXBJaDeaLxVr9ABeuBWWDxpj57MmP+vtgH +el/j6/5LK9zdXHf8pLBx/OlP83icrq8NVP223zZsuKhz0r6V+d3vZ1Y96h/5oL9Ey07YPacOVwM YPGisrJZB86xuwdccmY9ho+EdtrlwNyZxuypM+44nPhceNG/khtW5bTb5nfbFglXlYreKh78S+Hw kkLZ4wWyh/Jlv8qV3Zkt+3Gm7KaMkZlxYbbsl7myB/NGfvWpQtlzRcNkovykVGRbLLQt6LbN7Xgn 5dILp0p+4ZU8k8IwexoLFwNYtv7BQe1D9wQBjnw+7YrAojj6aqNUQ3s77XJg7sx89hw/5u2N+dmR xEf8M58KyXk2tHDp6dLXYqr+ef7iOymN76c1k5nxzYQ68pGXosqeDSt8KiT3Mf/Mnx9Nmr+P4zIw exoLFwNYtsiMTO2SFDqcA9c2enszV1dB7UXa5cDcmY3Z00QGZk9j4WIAC9Yl7NvK6iVlLxDQrggs kIvmJF5cXj7tWmDuYPYEBi4GsGBBicnaHghYkoLZsdV/dAf5aHRMSUNjWll5Qe1FvR2GwZJEXOyg Ps3N3uxZ3y+h/QabE1wMYKkudXSyt/acsCQF3PnG29tJMHL6Tp3SnceNrMoq2jXC7Aquaac+zc3e 7JnVOdHzTUAHLgawSEql8kjUWdbUhl5SMFOb3AOc+f4j8UkQyL5xT+/gx52nXS/MriMll6lPc7M3 e0Zd0n3UCEwAFwNYkrbe3iPRZ2Ny8tLLK1hbewEOx47RLg3M1aajAU5+AeQqmjQ+IUpZFc+iJurT 3CyN+ftiT1zsov0GmxNcDGBJfGLPMf0StVEK7c3BeCtcXJyur0Hp3b+bdGRXVdP+CWB2VQrF1Ke5 2RvJrf2032BzgosBLMmOoOM6MxrPL2Dt4cO06wJzssVnJH7z/IxYgyJjZ/CJQ6ejA84nRmVm5+PY uRXoFMtuP5xIfZqbjbFgf2zZFTHtN9ic4GIAS+JxKkp3jhMEfogD5zA1PD8/nt/k56DUwzMy6lR6 ZmZFZX1b+4AYf9RYHaVKtTa1jvpMNxvjb1ElEgWegmQEXAxgSYrrGsZPeTxBAG7fg4k58f1HDpNP Fp9IVo/Nza9sah6U4O5guBbTIrrF4xz1yY7bMX9fbEhDH+231vzgYgBLUt18eVfIyfFpypHvT7s0 MEU8X/9J9/K+PxuXVlbR3Y8DAzCGTKlyL7W0hkKbsy4NyLAKYTRcDGBhhAMD3mdj9S5PrfP0pF0d mAqnYwG8Cffy9oVFJBYVXxHhIcVgULdEsSGzkfqUx9V4N76qTiSl/aaaK1wMYGEUSmVsbr6eNOUX sAWbfVbvQ4HAacLeUIEJyfVt7UocHYcpaB2SO+Y2U5/4Zj5sky9W9+MRITOCiwEsT1Xz5V3BJ8at TZEhoF0aUHO9wab+BOUaEByVmY2NPDBW77DCq7rnDrO9h+sWj3PupR2XB2W030hLgIsBLI9QNOB1 ZtxmnyDAydePdmkw11a4uDjz9feJ2uoXeDojSzQ0RLtGMFdylSqmdeDdc1XzaE+Fxo7XTpeEN12V KrEGyxlcDGB55ApFTE6enjQlwEF0K+Lk62toMcrvXELHFTwZATjQJVH41wv/EppPfU6cyvh9YJZ3 TW/jANYfZgUuBrA8lU3NO8dt9jmjEbp1GH3yi77eULUtrbSrA4uiUqkaBmT+9X1/P1N644E46lPk +PGDfbEvhhccq+2t6JfiQOCswsUAlqe7v39/+KnxB9FtXFxolwazZcuRI3p39HYfD82trlUqcZ8v zJauYeXZloG9ZZ3Pnsybvy+W+qRJxu+DsnYWt0c2i1qGFGjIP5dwMYAlGRBLxvdJIFPtihUraJcG 3HP01d/uICI9QyLFTb4wF8jf9JsH5aeaRTuK2paE5Nx0MH6OZ8wF+2Mf9890zL188tLViyKZApMm PbgYwGJI5fKQpJTxLadsvb1plwZccuT7jw9RO4NPlDY00i4NrJGcTKND8vPtg/51wp1FbW9El/78 aPIszZi3H078a0SRS0Er/+KVuNbB+gG5DAeJTQkuBrAA5K8G4w+i8wSBK7DTZylINh6/r/d9TJxw YIB2aQAjfwQJpcqcHkl409VjNb37yjo3Zze9GVP+u8CshUeSjLrti0yUj/pnkrl4Q2aje2mHd03P yUv9GV3inmEl1hzMAi4GMGtJRSXj16aw02fubGxseH6661Fb/YPIbzdORoHJIjOdRKG6Mqy8eFVa 0CPO6hxM6xhIbhOdb+mPvdwXdUl4qvHK9uDTt9/5823840ltotR2UWbnYH7PUE3/cI9EIVao5Jgr LcWkF8O+mNTb77zLzv3QuZZ+XAxAXXp5xfgmCWQupl0XTJOtt/f4Hub7wiKaOjtplwYwU9u2bSN/ Oq1evZp2IUDZ4cOHyZWwfPly2oUAjMqtrhm/00e7KJiOzb6+4w+Z+8adEw/j8QdgCfbu3Usm0P/+ 97+0CwHKjh49Sq6Et956i3YhAFpFdfVbddem0L3TzDgcOza+A+fJlFS5QkG7NABuHDlyhEygb7/9 Nu1CgDJvb29yJfzzn/+kXQjAGHk1tePWppCmzIadQOA8rgNnTE4eOs6BJfH39ycT6Kuvvkq7EKDM x8eHXAn/+Mc/aBcCoCujolKn2ZSzL9KUGfhq/37euPWotLIK2nUBcCw8PJxMoH/5y19oFwKU8fl8 ciW88cYbtAsB0CO5uFTnhj6HY0hTJm3FihU656Nc/IOK6xto1wXAvdjYWDKBLlmyhHYhQJmfnx+5 Ev72t7/RLgRAv7i8Ap31jc2+vrSLAoN0frN2BB2va22jXRTArEhNTSUT6COPPEK7EKAsICAAW71g ylQq1YmU1LETdABad5omHn/MepRrYEhzVxftogBmS0FBAZlAFy1aRLsQoCwoKIhcCf/3f/9HuxAA g2QKxfdn43R2+mgXBbp4An+dfb2ayy20iwKYRVVVVWQC/dnPfka7EKAsJCSEXAl//etfaRcCMJFB ieRAeCR7pnZEmjIlPL6/znNhiurqaRcFMLuam5vJBPrDH/6QdiFA2YkTJ8iVsHTpUtqFAEyiu79/ V/AJdhd0nkBAuygY4cDn6xw1Ty/H/Xpg+Xp6emyuwyOQrFxoaCi5DF544QXahQBMrralVefQFI6g U7fO05M3toVUfF4B7aIA5oJYLFZHqQE8ldu6RUREoC0GmJHxjzymXZG103nEXkR6hgp9OMFqzJs3 j8yhnXimpHWLjIwkl8Fzzz1HuxCAKVGqVAHnE8ekKfTtpMdp7HpUYEKSAjsdYE1+9KMfkTm0sbGR diFAU1RUFLkM/vznP9MuBGCqhoaH94edYs/gX+PQFA06R6QOhEdKpFLaRQHMqZ///OdkDi0vL6dd CNB05swZchn86U9/ol0IgBFauntc/IPQG4EinSNS2wKCW3t6aRcFMNfuv/9+Mofm5ubSLgRoiomJ IZfB008/TbsQAOOMe6YMtvnmlE7rg+yqatoVAVDw+OOPkzk0OTmZdiFAU1xcHLkMnnrqKdqFABhH oVR6n41l90aw5/NpF2UtdFofHE++QLsiADr++Mc/kjn0zJkztAsBms6dO0cugyeffJJ2IQBG670q 2h4Uwk5TtCuyCo5H/dlRan/4KRyRAqv14osvkjn05MmTtAsBmhISEshlsHjxYtqFAExHXk0te3nE iY80NevYOQpHpMDKvf7662QO5WNJ3LolJyeTy+B3v/sd7UIApkOlUvnExrObdq7z9KRdlCVz9vXH ESkAxr/+9S8yh3733Xe0CwGaLly4QC6Dxx57jHYhANPU1de3LSBYuzAlQNPO2fLV/v3su/YCEpJo VwRA2YcffkjmUDc3N9qFAE1paWnkMnjkkUdoFwIwfYlFxaxb+QI3envTrsgyOfO1Oco1MEQowsMy wNp9/vnnZA51dnamXQjQlJGRQS6D3/zmN7QLAZg+mUJxMOI0zp/PKnuBgL21l1paRrsiAPo2b95M 5tBNmzbRLgRoysrKIpfBgw8+SLsQgBlhP+mYJwhwQv9zrvEE2hzlGRklVyhoVwRAn4uLC5lD16xZ Q7sQoCknJ4dcBvfffz/tQgBmShCfoE1TeMwxpxzHNpJq7OigXRGASXB3dydz6Pvvv0+7EKApLy+P XAb33Xcf7UIAZqrjinAru/+5D/qfc8PW25u9JBWRnkG7IgBTcfjwYTKHLl++nHYhQFNBQQG5DO69 917ahQBwIDIjEw/m4xyPr81Ru0JODkoktCsCMBV+fn5kDn3ttddoFwI0FRcXk8vgl7/8Je1CADhw dWjINTCE2ePjfe9HuyKzZ+vt7cxqgJBfe5F2RQAmJCwsjMyhzz//PO1CgKbS0lJyGdx99920CwHg RmxuPvtUD+1yzB57ScrrTIxKpaJdEYAJiYmJIXPo008/TbsQoKm8vJxcBnfddRftQgC4cXVoSNux UxBg/z1OTE2fzpLUxZZW2hUBmBZ1m+tHH32UdiFAU2VlJbkM7rzzTtqFAHDmbHYuekxxgr0k5X02 lnY5ACYnPz8ft25BdXU1uQzuuOMO2oUAcKZ/cJBZmOIJAjb7+tKuyCxhSQpgUurliIULF9IuBGiq ra0ll8FPf/pT2oUAcOl0RhbrqXzY45sO8r5hSQpgYk1NTWQOvfnmm2kXAjTV1dWRy+AnP/kJ7UIA uNRxRch+Kh+5yGlXZGY2uQfwWG05L7a20a4ITNTg4OCBAwd41mrDhg021zk5OdGuZXa98847b7zx Bu0qTNQXX3xBroEFCxbQLsTkbNmyZenSpatXr6ZdyKzYtWtXh6U3rPaNO6ddmPJFVwTjsHMUlqRg AsHBwTYAAFbJwcGB9p/Bs6uyqRmHz6eN3d4cS1Iwgf7+/q1bt66zYm+++eY///lP2lXMuvnz55OJ 46OPPqJdiIl64403VqxYQbsKk/PKK6/YXO8DT7uQWbF58+ampibafwbPLqVSuTc0gmnXuc7Tk3ZF ZoPH1y5JfX82jnY5AEDfggULyJzY1oa/WIER1D1sX3jhBdqFwPSllJRq9/j4aNc5Vezdvarmy7TL AQD61KtSFn8yBLh1+vRpctk8++yztAuB6bsiEmkPn/thj29K7A/5M1HK/WS4QqmkXREA0Ddv3jwy J3Z1ddEuBMwJHgdgGY7FxDPHpTYfO0a7HDPAY/VASCwqpl0OANCnUqnUh2x7enpo1wLm5Pz58+Sy +f3vf0+7EJiR/NqLaDBlFObA+Va/wL6BAdrlAAB9CoVCHaWuXLlCuxYwJ+onKz322GO0C4EZEUul rM7nOC41CfaB84CEJNrlAIBJkMlk6ijV19dHuxYwJ5mZmeSyefjhh2kXAjMVlJjMPETmG29v2uWY NBw4B4DxhoeH1VFKJBLRrgXMSV5eng0eUmkR2Ht8jnzs8RmEA+cAoJdYLFZHqcHBQdq1gDkpLi4m l80999xDuxCYKdHQEOshMriPzyAnPg6cA4AeJEGpoxTJVLRrAXOift73nXfeSbsQ4ID32VimJYIN nsdnAM8PB84BQA+RSKSOUsPDw7RrAXNy8eJFctn89Kc/pV0IcOBCaRmz3uLgg4UpPdYePszs7vmd S6BdDgCYkP7+fnWUkslktGsBc3Lp0iVy2dxyyy20CwEOtPb0aFsioFenPuzdvZzqGtrlAIAJEQqF 6iilUCho1wLmpLW1lVw2CxYsoF0IcEChVO4IOs48j492OaaI2d0jox8nSwGApbe3Vx2lVCoV7VrA nHR3d6uvHNqFADf8zycybc9p12JyXnRxcdbs7h2NjqFdDgCYFkyIMD19fX3qK0cul9OuBTiQWlrO ansuoF2OaXH21e7upZSU0i4HAExLZ2cnmQ3nz59PuxAwM8y9n0NDQ7RrAQ40d3Wju5QhzgLt7l7H FSHtcgDAtLS3t5PZ8IYbbqBdCJgZqVSqjlL9/f20awEOyBUKF/8gTWDAHt8YPL/R3b39Yado1wIA Jkd9ePjGG2+kXQiYGTwI2/IcOh2Nk+fjORzT7u7F5ubTLgcATE5zczOZDX/4wx/SLgTMzw033EAu nvb2dtqFADfC0zIQpcbj8bW7e43tHbTLAQCTg+5AMG0333wzuXiamppoFwLcyKioZDLDpqPY4xvF tEHYFXISz90DgPEaGhrIbHjrrbfSLgTMz09+8hNy8dTV1dEuBLjR0N7OehifgHY5poJpgxCclEK7 FgAwRWQeJLMhmRNpFwLmZ+HCheTiqaqqol0IcIP9XGPcxKe2RSBg3pP08gra5QCAKaqtrcWT1GB6 7r77bnLxlJaizY6FUKlUroEhmkadiFIjmOfukdHU2Um7HAAwRdXV1WQ2/NnPfka7EDA/ixYtIhdP fj7uabIcnpFR6HnOxvMbvX3PxT9Ihm60AKBPZWUlmQ3vvPNO2oWA+XnwwQfJxZOVlUW7EOBMYEIS WkuxMWfOvc7E0q4FAExUeXk5mQ3vuusu2oWA+Xn00UfJxZOamkq7EODM2ZxczbFzRKlrtt7e6CgF AJMqLS0ls+Hdd99NuxAwP4sXLyYXT2JiIu1CgDNpZRVoLcXg8bUHpcoaL9EuBwBMVHFxMZkNf/nL X9IuBMzPkiVLyMUTG4uND8tRUHuRCQ9f7d9PuxzKnFhRqn9wkHY5AGCiCgsLyWx477330i4EzM8z zzxDLp6oqCjahQBnqpqamfCw+dgx2uVQxty+5x4aTrsWADBd+fn5ZDa87777aBcC5uf5558nF094 OGYZy3Gpo1PbpdPX2vf4eILRt+JECg4EAoBBubm5ZDa8//77aRcC5uevf/0ruXiOHz9OuxDgTJew j4lSTnyrPnm+YsUK5q1ILkbzNAAwKDs7m8yGDz74IO1CwPy8+uqr5OLx90cvR8vRPzjIilJW/Tvr dEx7UKq0oZF2OQBgujIzM8ls+PDDD9MuBMzP3//+d3Lx+Pj40C4EODMgFjP5wdnXuqOUrx/zVrT2 9NAuBwBMV3p6OpkNf/vb39IuBMzP22+/TS6eo0eP0i4EODM0PMw6K+VHuxyanPy0q1JiqZR2OQBg ui5cuEBmw0cffZR2ITCnVCpVZmZiWlrsTMZLL40cO1+/fvUMX8fLy/3q1T7abwmMkEil2icaW3dr KWfNmfPdx0Np1wIAJi05OZnMho8//jjtQmBOHT/+fW7uufLyjJkMT8/djz3226io4Jm8yIEDThs3 rhSJrtJ+S2CETC7XrkpZd8NzphPC9zFxtGsBAJOWmJhIotQTTzxBuxCYOzExoRcuRM0wR3EyBIJ9 PN4nzs6rEKVMhEyhYB07t+pVKaYTQkR6Bu1aAMCknT9/nkSp3//+97QLgTmSkZEYF3eceogiIyrK 397+o7177RClTIeYfVbKilelXnRxYd6HCyVltMsBAJMWHx9PotT//M//0C4E5kJlZXFEhC/1EEXG hQtRmzd/QHIUopRJuTo0pL2Dz4qbIWzxCWTeBzx9DwAmFhsbS6LU008/TbsQmHWtrc3BwYephygy 8vMTv/76A3f39YhSpqb3qki7wWfFd/A58f2Z96Gtt5d2OQBg0s6ePUui1B//+EfahcCsO3Bg64ED PFMYDg62bm7r1DkKUcqkdAqFrA0+Ae1yqOGxmkoNiCW0ywEAkxYdHU2i1DPPPEO7EJh1p08HpadH msLYv38Lk6MQpUxKc1e3Nkr5YVVqZCiUStrlAIBJO336NIlSzz77LO1CYNYhSsGkqpqatX2lrLiP PdMJYUcQHjEJAJM4deoUiVL/+7//S7sQmHWIUjCp3OpaJkp9aM0bfPzRKLU3NIJ2LQBg6sLDw0mU ev7552kXArMOUQomlVRUojkoZdVNpZw1q1KHo87QrgUATF1oaCiJUi+++CLtQmDWsaNUcnJoQsLx OR4XLoQjSpm46KwczaqU9TaVIniapTnfuHO0awEAU3fixAkSpV566SXahcCsY0cpPn9/QkL0XI74 +FPBwd8hSpm4oMRkZoOPdi00MWelQpIv0K4FAExdSEgIiVIvv/wy7UJg1rGj1KlTc31zllQqDQ4+ hChl4jxORY1GKStudX5tZFVqNEpFZmTRrgUATF1QUBCJUq+88grtQmDWIUrBxBRKpYt/kKYTglVH KeasVHxeAe1aAMDUBQQEkCj16quv0i4EZh2iFEys9+pVbScEvvU2lbrGepbxhVI8gA8ArqlUKrlK JVGoeqXK9mHlZYmyUay8OKSsGlSWDSi3HfEduYPvlddqh5QNYmWzRNk2rOyWKsVypUxJvlRFu3zg DKIUTKy2pQX9OdWYY+fZVdW0awFrIaxOChsRVS+UG/gUUU7U9U9JKtN8hrw+7fqHotKERn479ReS /0XlNM2gal1thXHBYWFxhl5TLhGJRBJDP981uUhNQvkRAwqVigShjD7l6W5lQIfiUItiR5Pi0xr5 /xbL7s+T3ZUjuy1L9sMM2bx0mY16CPJtfniLje128u83Zch+kiX7ebZsUa7s6ULZymq58yWFR4tC 0K6I6FYmXVG2iJVSJcKVuUKUgolllFcyUWqzry/tcmhijp0jSsGcKfRYanOdW46BWCTKGf2MxR6a zxB5LFZ/aGmOyJhvJq+2tWHY1hvMNsbqdlPXYxen5xclZaPfdJlAt1h5W5SH3WIblsUrvaLKOKtr CsQKVd2QMrZH6duu2HpJ8VKp7PYsTVKaykgZmsqn3ZIp+0OR7Ot6uVerIqpHWSZSDsixbGVOEKVg YqEX0jRnzq369r1rrCiVVVlFuxawFmVeK9UhwqPQQJSSFI5+xlIvTRQRCZaNppNCY6JUd5obO7Z4 GApvxmqLWmzwBSXBTHpb6jXml7tzVtoYsFLQzU1lBkkUqpx+Jb9dsfai/NF82Q1Tz04zHvPSZffl yt6rlh9uVSReUV6V4RlVZgBRCiZ2ICISZ87VmGPnmRWVtGsBazGHUUoSrJNd7KI4Wf+pH01LtmXj Nujqw+y0305bP/tHGPkFN0FUUlyUm+1S5kPLvAq5KE2XTKkqFSmDOhR2dfJf5FzPNkHlNn/7wCaw bM6iFHv8OHNkK9CnTZHRpxQrsEhluhClYAJDw8Osg1JWH6U0b0VGOaIUzJG5i1LCJG1SsTH+yw2/ rtcy/cFM3hQ1ZvOOFaXIL41+cLFdGauG+jhXzSd7cLRkNooElbhepXOj4oE8TZLZ7LXg3od37NjR 09PT2dlp67jN5mjazNPRjwS5672DjwUfP+bjc2wy+/kB6q9amC37/KI8rEvZK8UilSlClIIJ1LW2 MfnBybqbSl1jRan08gratYC1mLMoVa3ZabOPKouyH8049nF6DopL2gqjoqLioqJy6oUTf3BE92hC c03T2ZRrcmUFqcVjo5So0Gv0F+zTxn5VvWY/cCUXMW+EVDkSouzq5LdmagLPJ1sf+/3/nDt3Ti4f k/76+vocvnW32R0580D1cpkspEPa2j+gnOxAFC+1gvmqG9Jl71TJT3YqrsoRqEwLohRMIKWklMkP m45afZTSbPCllZXTrgWsxVxFKc3JcJulaaJrwjTN4s/4o+Csk/CL3XIm/iDRFGWnt5I0V81x+ijN Jt+YKOUx+jHXsVFKXjb6ky114+S4VLFIubNJcdvYk+SLUvt7+g3OPkNDQ/uPeP/A4RgHW3gfOJDM 1tvbO0GFw8PDC8Z+1YIM2Rd18iShctIYBnMGUQom4Bt3Dk/fYzDdztFXCubM3EQpSXWwZrEnWMJ+ TZvFceMiS6GHJs54FE78Qe35K/XLajDn2xePLDpVj6t/ZC1Ls2S12CtNszIm7w6202xC2s70HJdM qYrsVv6p2GDOWV810D8waOjLyeTlFxzyoy/3TDNEfbL11795NC0tbSq36YXkVYx/hXtyZIJ2hQjL U6YBUQoMkcrk2wKCNQelrP32vWusO/hSSkpp1wLWYm6iFLNG5JqkTk7yKE0TgpUC3dYfbWkC25W2 titXerC2//R+8JooR13ImI1CYY7mRLn9SL8FSeEy3fpHFHqxGjMsXWlnZ8vaD1yW1DajJCVRKL3b FNodPcPj6yrR1cEhQ6+jUCiizpy56zNnm9Th0S8h/+IcYLPkpcee/pNtWoOe1/xsx70P/SYlJcVQ iBqUK52bFC+UylLbhHKFgnxEqVT+Mn1w/EvNT5e5XFJ0DCNN0YcoBYZcZB2U4ln9QalrrG7nycWI UjBH5iJKadtJrWRushMyjREWT38rrTtJvVG4lNUqVHtrXnC1xED9am0GmyHoHqAyjlSp8mxRLMgw YhHJsVo0MCQ29IIk6qRcuPDQik9/sOg3n3zyaWpq6uDgIElKvCbFmNf5Ys/d9z+UkJBAPl/v65CA t7tlzJf8IF22pV7a3Nt/4XKvodo21suRpqhDlAJD4vMKWI+M4dMuhz6m23lSUQntWsBaMFHKy1Aq mnGU6tacjFpsn6T9qLyaSTLB9dNrMy6PUkc01oGrMsFoalvppdklF2nrZ4XFNreRdbLRhajFy0ZW pTR7e9ePqLtNM02RhBPYobjJmBzFjK3V/YNig28FeWV2RuqVskKR3cE7f/1AXFycoRAlVSg9WxU/ MPyt78yeqLDdzYphdEqnClEKDDl0OhoHpdicNWel4vPxOGOYI0yUsh1/aEltplFqTDuppUsXqy1l bactHXuSfKokZeoXtg2rHy1LeyJLoE0k8tFPI4mL+WCZgKlpWVQZ84NLcoLtmarCmqazx5d3Vbko Z1qnmzRjZ02fWDI88Xchseqtyuufz/P72X0PnDlzxlCIkimVvh2KBTOoh4wbM2QR3ViYoglRCvRi P8UYUUrNWbPBF5mRSbsWsBZTWJViosi0olT3+HZS49lN4yEywhz1FuHiOM25JuZoOslS9nZ2tnYj bFdqQ9tKW/KfdnFNPV6aTxz/U6e5LdPEMaPv/iAJx7VJPv3Qcizb5o2PbrrvN6tXrxkcNHginaga VKq/5La49paeK3o/R6FUhXQpb57Cea2pjOWVcokCaYoaRCnQK62sXBulcFDqOuasVHBSCu1awFqU aVIFs7ajqy1O08aA2SAzIkox7aQWr7T38vLy0CL/5cZEn2k8RCZO3ZyK1UuTFaUm4pZzWVP/ysJx +2mSasHoz+ZhdMPzAbny0fxpZZXvEl932hMWd76ju2fSe+7IJzxeMObL366SVXYKmS9UqlSRvcrb OApR6rEgQ1Y6gChFDaIU6HX0TAwTpdZ5etIuxyQwZ6WOxcTTrgWshVDTYclQJ6VqzV4YqwWTNkpN 9jjjNqZPZpieZpzaNTGjHyKjOcrOXjtqSvKytbWz16V9HsxKO3s7W/ukpp4J6peUeU07Sl0SK6cX VG7Plj1TMtXxiIG09stcWWj7cOwV5cQHn6Y94q8gSlGDKAXj9Q0MYElqPOaslOepKNq1gNUQMa0D bGwFuuFBVB3GbI+5aduJM1FqZdmEAYhZ4TF0m568KYyJOdoFLomwrWlEt4j16mM/KNIEnimcaJKP Vqs9KyXy0qSrlbrP2hMFa5oiuBm/UFbYNysZZmQElGj7IdAY89Nl4Z0yY98Q4AqiFIyXXl6hbYPg O9dXhcliWnS6nQilXQtYkRzWvthSO4+0svq2trb6spxgN1bnpcVubdqv0DYcWGZr7zpuGYiws/Oq l1xL0rSTWhms2zxKo9tNk2rs40a/A7PnuNhNm3N0Ppim/rLFrm36X5ZNNPqlrDv4mqK0x8tXuoXV C0VyuaS7qdBD21zKttr42wpPNfVxH2MEBTb3P+bm5nbu/PnH//u5TWidns+JarXxL5rqmFYquyFd FtIyvRstgQOIUjCex6koZklq7eHDtMsxFU780Sjl4h80lR7FABxpc5vkaPjSuDEtK0Vekx9KWpbT rTmvbrM0yXDrKO3NdJqeBsyuH3uLbcwH5fX24z7BME3wG9MMQSgw2FVqhJvuE/2mJL5Z+EAOd2tH 4Q02T/z5q6++GhgYUL8++WOhqanpcycXG56f9tNSh59Y8nT2pHJysotKUiouOhe33238PYY3Z8hi OxClqEGUAh3NXV3aJSk0OWfh+TK3NAYODU9yNzQAl+RtUW52+lOUrVtOm84cKgqeMIdctzKrQLO7 tzJ4ghNVcuZYu42tuoFndfBoJexzUGM+qLkrMHhKK0ciwUq9ZYjSgtlPPNZYvDKqzOitPbWk5iv/ LuBiYSq22+bZ1995552enh6932hwWPp0keaT3/iopqZmgqpIAOuTKi70K79qUEz7LPqLBUOFPQa7 ssNsQ5QCHZEZmTgopZeTrx/zzrT36r/BGWAWyUVN1YVpSXHXJeUUVo85rWSR5ML6wrS4qBFhUXE5 ZU0zWXlJbr7yalzN3dnS6YeopEGbv32w9KWXLl26pHdpmnywclD5R+bRfmfa316+fOJF7Kqqqic+ 22KTKJp2VQsyZO9ntpUiStGDKAVswzLZ9qAQJke96OJCuyIT4iQQMFGqsqmZdjkAYBwSpebvi11V 0GPwqTEJ/bf/3wqbfbH6f/W9r5948qmysjJDIap6SPlsydgvefL53t5e9ucY+tqCgoLHVtuPRDXj o9R/i/oXHklElKIIUQrYcqtrtLt7fCxJjbHCxYXph5BRUUm7HAAwDolSNntjfnooYVVx/w0GYsmR 4+FCoVAQELhoxacjh8DVH1+3796HfpOenm4oCF0cUr5QOu7VfHO3bt2q/gShVOHXqViUO9Iqoail y9Dr5OTk/ma1k02KeOo56q3igUcCsm/YH4soRRGiFDCUKtXBiNNMlHLy9aVdkclhbuI7m51LuxYA MI46SpGx8Eji6uK+W/QdTFpwopJMTNeuB5vW1la3gx73PvZEdHS03ie/kM9pECtfLtMfcm7afapJ NHz2ilJ7bkozni2RNXT1GgpUGZmZD6zlTRqo5qfL3isRPRaYTX4iRCm6EKWAUdV8GQ+LmRjTWiow IZl2LQBgHCZKkXGr5/nVeV2P5Oq5oc8zOIz9VYYCT5NE+VrFNE83qcc/S8Wdwn69pZLXv5Catmit i6HGCHdmSdcWC+/1SVX/OIhSdCFKAcMnNl67JIUD5/o4C0aj1HeR0bRrAQDjsKOUerwWV/N+iejW sctTPwitk0gmOt4+LJW+dcB/5D6+GeQoZqwuH7g6qD8FKZXKpJSUXx45N6a8dNmyosH30poX7I9j fhBEKboQpUCtpbuHdeNeoA0OnOvDPNF4e2AIWksBmJfxUUp9dOqT7La3igfZTxbe43984pdSKBTF xcVrvnGc997XnGQq1yqhRF+LFYVSdapHyezovVQo/ryw5z6fNJ2fAlGKLkQpUAtKTGa1k8KSlH48 zaoUGVeuTvakWAAwJXqjlHrc7Z1CAtV7JQO/yh0JLfMimwbEEtUUSOXy7JqG97LbZp6mfpAu867p lstHG1z0yZQHWxXqgPfTLNmy4qG1Bd2PXz8ZNX4gStGFKAXXdJek0OHcIB76IQCYrQmilHrcdijh 7/E1a4t63yoZXDg7Dx2edPwoU+bbofhn5ci/35Ipe7lIvKZY+E7KpXu8UyaoHFGKLkQpIPzOJbCi lD/tckzXV/v3M8elkopKaJcDAEaYNEox4y6v5H8lN6wtFv6jeOjBvJGdtblMU/fkjCSo1SX9H2S0 PCRIn0rBiFJ0mWaUcndfv3XrWoVCMcf1WKdLHZ2sG/cC7fl82hWZNJ7muFRwUgrtWgDACFOPUuyN v5ejylbltK8uurKyZOAPhcO3TvfZLhOMGzNkj+dLV5QMri7u+yyv8424mgf5afOMqRNRii7TjFJO Tp92drbOcTFWi33jHnogTIrp0rk//BTtWgDACNOIUuxxi8e5p47nvnfhkm1ep21hr21J/4elA68V DT1VKPtVruz2rJH9OEPrV/PSZTdnjhx5ujtH9kSB9OUi8XslA+QVRl4nr+vDjJbnwotuP5w47doQ pehiRymSagSCA3M8oqL4OlHK2dk2Ly9NqVRgVWoOVFxqYi9JbTlyhHZFpo4n8GfeLsn1Vn4AYBZm GKXGjwX74371/YWnj+e9FlP1dmL9e6lNH2e2rMpuW5XTsSqvc1V+16q8rlW5Haty2j/Jal2Z2rQi qeGNuJo/hxbc75t2i0c8h5UgStHFjlJ0hzpKbd++msdbc/jw9k2bPuroaKP99lg4mVy+LywCp6SM 4sTXRqmmzk7a5QDAVHEepUxnIErRZVJRys1tnYvLWvLvQUEeX3/9IY6dz7bk4lJ2A4RvvL1pV2QG HPl85k1LK6ugXQ4ATBWiFMwSk4pSmza9f+FC+Nmzflu3rnF2/hRRalb1DQy6BoZooxSWpKaMOXmO x8cAmBHLjlJFPYO032DrFRzsFRjoERh40Nt7p5fXdi+vHXM5jh7dTgb5vuSfu3bZHTnimpIStmPH V+7u63fssEM36VkVkpTCylGBK1asoF2R2WAade4KPqHEVQpgJs419VDPPLMXpc63YPGBmsHBAaHw ikDgcfq0z5YtH3/77RdzOXbuXPuZ7ZtfrnvH1XVdfHwQyVF7924hH3dyWtXfL6T93liy8sZL7NPm zr5YkjICz0/b87zjCi5UAPNwsq6TeuaZvSgVdLGb9hts1TIzk8LDvdLTI6Oj+Zs3f7Bly0dzOb78 8h07u5XqPT4fn90uLp85O6/Kz0+n/a5YskGJZPfxUNaSFBogGIfnoz15nlNVQ7scAJiSgKp26pln lsb8fTHeFe2032Dr1dbWxOe7Uz8oRUZEhLez8+odO9bYb/lk5471LlvX7txh53PM/fz5UxdryxUK Oe23ynKEpaazHxOzRSCgXZGZsXFxYd7AkymptMsBgCkp7x2gnnlmb5xu6KH9BlspqXT46NGd1EMU GefPh7i4fL5nz5cbNqysrSmpr69oaqppa2usri5KTo72E+zfsX19VFRQVxfaI8xUdfNl9taeEx9L UtPBHJfacyKMdi0AMCVdEvlthxKoZ55ZGhmdeMA6HQLBweTkUOo5Ki3t1LffbiQ5auPGlXvdHdkV 9vX11l0sr6wouHy5LjPjnPuezaci/IaGBmi9Y+ZOJBazt/acBYE2Li60izJLJIIyb2Nbby/tcgBg ckqV6tPkWuqZZzbGY34ZPRI0tabg3LlT0dF86jmKjMOHXbdt+8zB4SM7u/8cOrRTb7UymayurqKh oTItNXb3t5saGnBAxWgqlWrMY4vxuL0ZcORr38aUklLa5QDAlJxq6r/xQBz15MP5OFTZhXve515V VZmj42oPD2f1OHDA6eDBuR7km5Kxd+8WJ6dVJErZrf/Pxg3v+fsfnqBshUJRVVlUX19xYL9TSUnO nL1dliGtrJydo3jY2psBGxcX5j4+rzMxtMsBgCmRKFWOuc3Ukw+3482zZU2DMtpvrTWqra00kSWp gID9rq6r7da/s2njys1ffyKTTf5Qs87OVpKmPD2cm5rq5uC9sgyXu7td/IPYjy22RW/zmXEWaPf4 RGIx7XIAYEoaB2TvxldRzz9cjScCMjO60OecDpOKUuvW/ZvkqPXr3+3unuoTzfr6ei9eLDuw30ki wRQ2uUGJZF/YKXb3gy0+gbSLMns8Xz/mLS2ovUi7HACYqoq+4Q8Ta6inoJmPP5/MS+pAk3Nquro6 +PyD/v6e6uHmtvngAce5HHv2bHZx+WLbtnWOjrZf2f3nyy/fyctLM+pHaGyoSUk5k55+bpbeIgvQ PzhY1nhpWCbjx50fu7WHhpwc+Mbbm7mPLzgphXY5AGCEhgHZtoJWsz439WlybU4PFhNMiLfX9rNn vp/L4euzkySorzf9lwy79f85cdxnGmXXVBcfOuTK+bthGWRy+b6wCDLLe0ZGjWlsjoac3GGOS20P DJHK0PoMwJyI5cqQxv6ng3OohyJjxy+9U45U93SIccueaaEYpTZueG/PHofplV1VVeTt/a1CgctJ j/q29jEJSnNEau3hiQ72g1HYLRFKGhpplwMAxlGpVOV90n1lnXd7J1MPSFMZt3qe35LTnNYlVuB+ PdNDK0pt2rjym29WyeXT/Ot8fX1VWOgxHJfSq6alVSdH8fwCeGhsziknb+1xKf/zibTLAYDpkCtV md3i/WWdD/HTqIclQ2PhkUSnvMtxbQMSBUKUiaIVpezWv3flyvR73dfVVQQHHRoelnD4VliMnv6r Y3PUyD9pF2WBmONSW/2DBnAfH4DZUqhUJcLhgPq+L9Iafn40iXp20ixDnXsnvur7mt70LvGwEiHK 5JSW5oeG8tXDzW2zpwdvLseePd/Y29seO7aPqUE9BALPqbffrKjIP3J4+6y+S+ZLoVRuCwhmL0nR rsgy8Vi9OrMqq2iXAwAzJVaosnokPrVX3k+o/imlB8388GD8a1Elh6q6E9oH+2VK2m8J6NffLwwJ OVJenmFqY/36d1tbm6fyI0ilwzU1xXzf/bP9XpmvI1FnNd0PAm1sbGiXY5ns+XwmSh1Fr04ACyKS KdO7xMcb+/aVda48X/Vrn9R5sxmf7vJK/vuZ0l3F7f51QpKguiRKNDA3cUFBR0pL06gHJ53h5rbZ 0fHjKUapior80JPf19djHcCgiLQMZpanXYslI0mVeZ+7+/pplwMAHCORZkA+ckA9qkXkVd1L0s7a 1PqXIooe5Kfd6nluGqnppgNxi45dePZk3kdJtdsKWg9Vdoc3Xc3tlfTLVErEJzORl5eemBhOPTjp jMTECAeHj11dV08lStXVVRQWpvN995F/Vyqx+KlfenkFM8Xb4cD5rOGx2p7H5ubTLgcAZhdJVlKl SiRXXRqQ5fWIz7eJIhr7Qup7Ay72+FZ3e1d1HSrvOFDa/vdNLk++8g+PktajlZ0+1V3+tT3B9b2h jcK4FlFW91DtVWmfTClRqLD0ZI7E4qHAwO+oB6fxY8uWT9zd1xuKUsePe/v5HVQPH5+9ZBw9sksg OODsvLa3t3vu30azcLG1jZniHX1xVmq2fLV/P5OmdgafGJbhYVgAcO1Xv/qVjY1NeXk57UKAeydO HCsuvkA9OOkMDw/n7dtX791rt3Xrqo6OVp2a8/NH1qzGfxX5Qdavf3dgQETlnTR9VweHmCjlxMce 3yxiP48vt3qq900AgAW76667EKUsUllZQWxsCPXgpDMyMmLs7T8iOcrNbd3+/U46NUulwwEBnnq/ cOfOkeiFKDWBXSEnmeactGuxZA4CAROlPCOjaJcDAPQtXLiQRKmqKhzotSgymdTf34N6cBo/HBxW 7dnzpbv7eheXtaRInbIjIvwLC5PHf1V6+lkHh4+3b1+DKDUB37hziFJzw9lPuzBV39ZOuxwAoOz2 228nUaqmBsvUFuXUqYCCgiTqwUlnfP/9t9u2fbZ3r52j46fd3Z06NTc3N0RGCvR+oZPTZ3v2rEeU mtjZ7FymHwLtWiwcz1fb+RxPNwaA2267jUSpuro62oUAZ+rqqqOi/KkHJ52Rn5+4ZcvI1p6z86rC wqzxZfv769/aO3XKl8f7lHyhk9On6HY+gbyaWu3Jcz6fdjmW7EUXF2dNV4StfoHd/eiKAGDVbr31 VhKlGhvxdE4LoVKp/PxMcWuPx1vt5vbl9u1rTp3yH192SkpMRsZZvV9ob/8JyVE7dqwNCxPM+dtp Tpq7urUnz7EwNcucBP7Mux2emk67HACg6eabbyZRqrl5Sp0SwfRlZCQGBR2KiPA1qeHp6eLsvGr3 7nXkX8bX3NXV6e5ur/cL3dw2u7qu3rPnyz17tsz9m2leJFIp6yY+PXkVOORw7Bjzbm/1D+rpv0q7 IgCg5sYbbyRRqqWlhXYhwI3o6KDgYA9TG3v2fOPuvn7btnVyuXx8zYmJZwSCvXq/0N39m+tbe5+J xUNz/2aanV3BJ3DyfM44szqfR6Rl0C4HAKi54YYbSJRqb8dNKBYiNTUmPT3S1Mb33+9yclrV19ej t+asrOSEhON6v9Dbe6ez86qKiqI5fhvN1OGoM5qT54hSs87Rx4dp17nVP6j3KhamAKzUvHnzSJTq 6uqiXQhwIz4+/PBhV1Mbrq7ry8sLDdWcm5vm4eGs9wu3bfvyxIljc/kGmrWgxGTcxDeX2O06I9Kx MAVgjVQqlc11vb29tGsBSyaXT/P5Gq2tlzgtxMKdzcnFqtRc2sJq17nVP6hL2Ee7IgCYa3K5XB2l hEIh7VoAYKYyyitHo5Rf4Isuek74A+fYDzj2O5dAuxwAmGtSqVQdpa5ilx/A/JU3XmKm9S0CAe1y rMIWPp95z8mouYxbeACsi1gsVkepwcFB2rUAwEy1dPcwczqPjz2+OcK+lc/j1GmFUkm7IgCYOwMD A+ooJZGgiTSA2ROJxdqG5zguNVfs+XweK01lVlTSrggA5k5/f786Skmlug+WBQCzo1KptgUEY1Vq 7vH42ii1M/jEIP5yCmA1hEKhOkopFAratQAABw5GRDInz2nXYkVWuLg4+2nPn4fhUTIAVqOnp0cd pchfZmnXAgAcEMQnoB8CFc58f/b58+rmy7QrAoC50NnZSXLU/PnzaRcCANyIzMganc0RpeYc+8SU +8lwMQ5OAFiBtrY2EqVuuOEG2oUAADeSikqwKkWL/djGCJEZmbQrAoBZ19LSQqLUTTfdRLsQAOBG ZkUVohRFTqwTU2TUtbbRrggAZldTUxOJUrfccgvtQgCAG0V19cw8vvbwYdrlWJ0XXVx4rDS1NzRi aHiYdlEAMIsaGhpIlPrxj39MuxAA4EZ182Vtayk+n3Y51siB9WA+MoISk3FfD4AFu3jxIolSt912 G+1CAIAblzo6tQ3P8ewYSnhjt/nSyytoVwQAs6WmpoZEqTvuuIN2IQDAjU6hULsq5eNHuxwrtWLs Np+Lf1BzVxftogBgVlRWVpIodeedd9IuBAC40T84qF0P4fvTLsd68QQCHmtham9oBFqgA1iksrIy EqV+8Ytf0C4EALgxLJOxNvhwEx9NOnfz+Z9PVOJJxwAWp7i4mESpe+65h3YhAMAZF/8g9dzthMfw 0eYsGJOmzmTn0K4IADhWWFhIotS9995LuxAA4Mzu46Gahud4DB9lm9wDdI6gZ5RX0i4KALiUl5dH otSvf/1r2oUAAGc8Tp3WPNEYZ6Xo433vp7M2VdnUTLsoAOBMdnY2iVIPPvgg7UIAgDPeZ2PxGD6T whsbpVwDQ1q6e2gXBQDcyMjIIFHq4Ycfpl0IAHAm4Hyi5tg5NvhMhc423+7jod19/bSLAgAOpKWl kSj1yCOP0C4EADhzIiUVUcoE6aQptxNh3f1IUwBmLyUlhUSpxx9/nHYhAMCZ0AtpiFImyNbbm/yO sNPUnhNhPUhTAGYuMTGRRKnFixfTLgQAOBOWmo4oZZq2HDmicwR9z8nwnv6rtOsCgOk7d+4ciVJP Pvkk7UIAgDMRaRmaO/hw7NzkbBEIdE6huyNNAZizuLg4EqWWLFlCuxAA4ExkRqZmmkaUMkVO3n7s KEXGt8dP4iF9AGbq7NmzJEr98Y9/pF0IAHDmdGa2ZlUKG3wmaovPSAPVMR0SAoIrLjXRrgsAjBYV FUWi1J///GfahQAAZ6KzctDt3PTZf+/PG7s2hV7oAObo1KlTJEo999xztAsBAM6cyc7FBp9ZcPL1 1TmFTsbZ7FwFnnoMYD7Cw8NJlHr++edpFwIAnInJycOxc3Oxhc/X6ZBAxrGY+P7BQdqlAcCUnDx5 kkSppUuX0i4EADgTl5ePVSkz8pWPj7Of7trUt8dP1ra00i4NACYXEhJCotTLL79MuxAA4Ex8fgHO SpmXdZ6e489NkXEuvxCbfQAmLjAwkESpV155hXYhAMCZ8wWFaNFpdsgfxc7jdvqub/bFoesUgCnz 9/cn//997bXXaBcCAJxJLCxmJmLatYBxnPiB4w+ibwsITikpxfIUgGni8/kkSr3xxhu0CwEAzpzL x6qUGeN978cbd3SKjO9ORzd3ddOuDgB0HTt2jESpZcuW0S4EADhzNicXd/CZtU3uAXrTFBlnsnPk CgXtAgFAy8vLi0SpN998k3YhAMCZyIwsdDu3AHo3+8iIysqmXRoAaB05coREqeXLl9MuBAA4E3oh DRt8lmHk+TLjotS3x0/SrgsAtL777jsSpf7973/TLgQAOBOclKKJUtjgM3vjF6a+DUGUAjAhBw8e JFHq3XffpV0IAHBGEJ+AKGUxmCjldSZG/S+n0jNpFwUAWvv27SNRauXKlbQLAQDOfB8Th7NSFoNZ jMqtrm1o70grqxiWyWgXBQBa7u7uJEp98MEHtAsBAM4cjjqDO/gsBk+zKpVVWUW7FgDQY/fu3SRK ffzxx7QLAQDOHIw4jQ0+i8GsSqWVVdCuBQD02LlzJ4lSq1atol0IAHDGPTQcd/BZDGZVKrm4lHYt AKCHq6sriVKfffYZ7UIAgDO7Qk5qopQ/7VpgppgolVBYRLsWANDDxcWFRKm1a9fSLgQAOLMtIBgb fBbDWdP2PC4vn3YtAKAHj8cjUWrdunW0CwEAbiiVSuZ0De7gswBMlDqdiSbnAKbIwcGBRCk7Ozva hQAANwbEEiZKOfL9aJcDM8U8jC84KYV2LQCgxzfffEOi1IYNG2gXAgDc6LgiZKKUEx8bfGaPp/nd PBYTT7sWANDj66+/JlGK/JN2IQDAjbrWNiZK2fP5tMuBmeIJRn83PU6dpl0LAOixYcMGEqW2bNlC uxAA4EZxXQMTpb7y8aFdDsyUs8Bf/bu5C4/eAzBJ69evJ1HK0dGRdiEAwI308gomStGuBTjA42sf ZKxQKmmXAwC6vvjiCxKleDwe7UIAgBtxefnohGBJmMcZkyEcGKBdDgDoWrt2LYlSLi4utAsBAG6E paaj1bkl4QkETJRqaO+gXQ4A6Prss89IlNq+fTvtQgCAG4L481iVsiT2h/yZKJVfe5F2OQCg69NP PyVRateuXbQLAQBufBcZPTrzIkpZCubZMecL8OwYAJPz0UcfkSi1e/du2oUAADe+ZR7A54coZSGY KHXyQhrtWgBA1wcffECilLu7O+1CAIADcoVC258TUcpSMFHq6JkY2rUAgK6VK1eSKLV//37ahQAA B/oHB5kohWYIFoPnN3pcyjUgWIl+CAAm5j//+Q+JUh4eHrQLAQAOtHT3sJ5ljAfwWQhHVj+Err4+ 2uUAwBj/+te/SJT67rvvaBcCABwobWjUbvAdwwafhXA4pr2Jj/wW0y4HAMZYvnw5iVJHjhyhXQgA cCC5uJTphLBixQra5QA3bL29mSh1Lr+QdjkAMMabb75JopS3tzftQgCAA+jPaamYk+f+5xNp1wIA Y/zjH/8gUcoHzzwFsAheZ2LQn9Mi8fxGo9S3x0+qVCra5QCA1uuvv06iFJ/Pp10IAHBgZ/CJ0Z0g PqKURXESaI9LdQlx8hzAhLz22mskSvn7+9MuBABmakAsYd2+hw0+i8Lz82N+c/NqammXAwBar7zy ColSQUFBtAsBgJlq6uzS3r4nENAuB7i0YsUK5jc3LDWddjkAoPXXv/6VRKnjx4/TLgQAZqrwYh0z 22729aVdDnCMOS61NzSCdi0AoPXiiy+SKHXy5EnahQDATJ0vKMTT9ywYE6XIEIoGaJcDAKOef/55 EqXCw8NpFwIAMxWSfAFRyoI58bVRKrcax6UATMVzzz1HolRkZCTtQgBgpr47HY0z5xbsq/37nTXd pQITkmmXAwCjnnnmGRKloqOjaReiQ5UeKwuPlUWPG+GnZdEJ8ur22WqrUp0g3bBGvGajeM0emeTa NWGtnHzH8Fi5cCYvOqCIPj1afD1W5WF2KFUq14BgrEpZNp5mVco1MEQml9MuBwBG/OEPfyBR6uzZ s7QLGWtA/vIzQ3dNOF52lDZLOP628dtZ3+LVYdG1a2Ve4uv/Kc6ZQQSqDxMzL7vmtIK7egG0rlwV Mbs/jujPaaF4/EDmd7m2pYV2OQAwYsmSJSRKxcXF0S5kLIn8/cmilDrttHH4TeWKNcwrLxev8ZCR v/IVchCllO6vsmpePjyjBS4AA8oaL2mjlA86xVmmLXw+87scnZVDuxwAGPHkk0+SKHX+/HnahYzF RKlXh+sHVKI+lVAz2i4rwr0kTDLZEMvdIs+A/C31y66RijQf666Q+QVL/cLk3dNdSpc0SnUSYPRl jgoGYInPL2Am2a/276ddDswW5riUe2i4Ek+QATABTzzxBIlSSUlJtAsZi4lSH2pTDVtZ8GiaenkP h6cFFOpv+lYwl3tw6XvEOlHqLS+ccADu+cadG41SeJCxReMJtHt8jR0dtMsBgGuPPfYYiVIpKSm0 CxmLiVLL9UcpSYVUZ7+sO1+2fc/wdi8Z+c/C08NvXd9T86tg/sqmSg8bfn/5yAeXvDr08ocSzzB5 N+uoVWGs1NtjNJ4tWSMZWYm6vt7VXSLz5ku9g2Xd8mvyHrn7nmF3j+Hte6RlY/f7ymKl2z2GPb2G /VKVY35Bu2koKauVLdH8ezNXbxTAdUqVakfQcdy+Zw0cWcelojKzaZcDANceeeQREqXS0tJoFzLW 5FFqWBOlpOoopTnURGKSdv3Hs2QkSpEItGbsupBmiOMb1VlL5fnq+F8dd+xcwjpM5ShjlpbYW3ju +WOiVHfWMGv1TLVd8128K7AsD1zq7u/H0/esBPkTm1mY2hVyUq7AnSwAlD388MPk/5iZmZm0Cxlr sg2+dA9NcPIYTTRlfN19NDJCalUk/7BOsIvdg2XRYcNvsT5SOLK+pEriD2/YyLyC2HG7xJEvZ72s +tOuiSpYqSlLnZqUTEBiitFQhaxhVcIqcsl27PEBl4rrG5go5cDn0y4HZheP1auzuhmHLwEoe+CB B0iUyskxsTtBWMfOq3tU3e3K7h5lW8/IP6tL5J7azDPkXTK6vMOOUu97yJhT4jma0HXXRqn2dj+5 0lOzePUWX/N3OrnmrBRf+7c8nSg18oJezDeS1LO/76vDutt2PZqWDq8Od6u/w2UZ87VlXHdyAGsW k5M3uiQlCLD19qZdDswuno8/E6VOXjCxPQUA63PfffeRKJWXl0e7kLGm2Axho4zJI6wFH5n2ddhH lXTWgZj79ZjuBJpvyj4WPj5KsZeh2CO8UXfPrjps9PDV+9pz7Er35aOfvz1LeQ2AI9/HxGnmVnSU sgrMHt+2gOBBCf5iBkDTvffeS6JUYWEh7ULGmkKUWuMlY+/9MVEqhBVpJLVSJnQJJdqOCmRIBhSO mu280Z5RU41S1+SNMp1i3tdz05+2nVR8j/aj1cHMKpkMf/wBJxRKpWtgiGZVCgelrAL70cZpZRW0 ywGwavfccw+JUiUlJbQLGUsbpcTR+fKcLHk6ayRlyZv7dJeAtJmHFVDYR5sMD6Oj1LWRRKTtbXXX h9LxXTe1KW5kg0+85NWROweXLGcf6BKn93H2hoE167gi1J45R59z67D52DHmITL7w0+hwRQARXfd dReJUuXl5bQLGYt17HyKSzd6M88Uo9TosSWjolQYK0qt0XM2fnw7KT0La3iIDHCh4GKd9sy5D6KU teAJtAtTF1taaZcDYL0WLlxIolRlZSXtQsaarBnCePqjVImUOUAlGrvBRwb5iGRk6H7TaWzwrQkb G4pYbRMcvaTeXiMtp0YHX+ruqElZy/UsZwEYKzorh3mK8YoVK2iXA3PE2c+PiVJBicm0ywGwXnfc cQeJUjU1NbQLGYujKCVhMs+a8atbqniv4e17JO5hmserz+zYeXS79qW7UzVtrzayzsAz5Nr+DHiI DMzcd5HROHNuhWxcXJw1J6a2+gX29F+lXRGAlbrttttIlKqrq6NdyFgcRSkSezZoQou6sxNDmK9J O8we4tSilLYZwvUWB9EbNWlq+WjHA3Y7KXcDt+lFO45+wlt8NJiCGRkQS1gHpXDm3Lo4CbRdEU5n ZNEuB8BK3XrrrSRKNTY20i5kLM6iFPtQk9gvXzESXOSqwthhZjXJU9OZaipRin34yk+dzZimCkwu 6pEzD4ipNnDSS5jFFDCuGxWAMcoaLzGTqTPOnFsZh2PHmKcbbwsIvjo4RLsiAGt08803kyjV1NRE u5CxJEzTp6meJmIyT86Azq8ovTVrROPHy3vk2tik+aZ6o9TIy8oVG1hfyHxOW4I2mIXUqso07Q6W TPCoZVYPdjxEBmaCdVAq8Bs057Q+zqynG8fnFdAuB8Aa3XTTTSRKtbS00C5kLObYtr6b4/TSdCfQ XZW6TpXkJRmfoxzD5GOyjuabsptEaV9Wcq3+NPMikuoxX6kKZ7b51kj9NcnNr3aijBS/fTRx6etJ BTBVHqdO46CUNXMSCJiFqR1Bx8XDw7QrArA6N9xwA4lS7e3tk3+qmZP3KQuz5PEJsqRUeWGtQoj+ mGD+rg4NsXb3cFDKSrG7IiQWFtMuB8DqzJs3j0Sprq4u2oUAgNFKGhq1UcrXn3Y5QIcj65F824NC BsRi2hUBWBGVSmVzXU9Pz+SfDQAm5nRGFjOHbvb1pV0OUMNemDqbnUu7HAArolAo1FFKKESrSADz szc0Art7QPB8tQtTLv5BV0RTPGQKZoNM03v27OFZGQcHB9olTI4UqY5SmzdvnrNvGhCAw7HGaWlp 4fa3YPv27SZ3zyYYj/3oPZw5B/bCVHhqOu1ygGMHDhywAdD429/+RvuSNDN5eXmc/y6sWrWK9o8F M5VaWsZMnY4+frTLAcocjvnztNE6sBXHNixLZ2eng4PDOmuybNkyMlstXLiQdiGTW7Ro0X333TeX 3/Ho0aO0L0kz09TUxO1vwcaNG6urq2n/WDBTx2LimI5SL7q40C4H6GOtUgZ6nYlVqdCzDsxYSkoK iVKPP/447UIAwDINSYa3ap8Xg909GLHFJ5C9zVdQe5F2RQDTl5mZSaLUQw89RLsQALBMJfUN2kfv 8dEGAUbxWM3Pdx8PRcdOMF/5+fkkSi1atIh2IQBgmUIvpDHP3bM/hCgFo9Z5erLT1JnsHNoVAUxT aWkpiVK/+MUvaBdivvrTCuPCChOjxo2w3LiokqzqK4Oz833l1SURdgGOtiGOtmcSJdeuCVvzyHcM K8wzqluEfLA+itSpp/644LToqOoaIZ4VAzOgUCp3hZzEI4xBL0e+tjHCVr/Axo4O2hUBTEd1dTWJ UnfccQftQsyWuHjpgXdsJhxLwyKapNx+V3lc5Mfab3EoQHTtWlnC59f/8/McY/oHixoDJi6evGBw Yy+31YP1qGtt0+7uCbAkBWOQ2Yf9jON9YRESKcd/VgLMgYaGBnIx33rrrbQLMVvS8pWTRanracen jcNvqqi3ZV7Z+3PbuFT5tWuF04tSzScmL/7AOx51SFMwHewm5zxfNOcEXTw/P2e0mQIz19LSQqLU jTfeSLsQs8VEqUNH6sXDosF+oWa0ddeEJbgyacSukLtWk+LyZeqXDYhgOgV3N6cK0iIEWVndxmzJ MVFq8ZksyTW5RDqsHqLB3vrGRNtDTGALQJd5MJZCqfxWs7vHQ2dOMIC9MEVGWeMl2hUBGKerq4tE qXnz5tEuxGwxUcr3hN7nH5SljaappWfyuPuu9epvuiytfoYvxESpZQnlen65P0uzfbnRqMUuAOIi a3cPTc7BEFtvb5K0mUtlV8jJ/sFZOmIKMCv6+vrUPaVlMhntWswTE6W89UcpCbODplnY6a6Lcz1z xDUhUXhNXpjrs+zQxzYHPhY0M3909Kdl+az0Hvng4kMfL/V19cjK6tYeH5AXFkZ7xbmNLiUFHBSk nRAU1oy8bGOiV/IJr7TEbsU1eX+x25kjbnE+rmdOlI2NQGWFJ1zjAjwSfAQVrdcmjVLXej28EaVg miIzMpn50UEgoF0OmC4ngYDd/1wQn4CmnWBGxGKxOkoN4m8B0zN5lNKc6/Y+oY5ShQkbR9epfLVH xz0a+8kvkQikPQQ1ZmyM61A3Xen3ODT+V310j51La7SvE5YoZ4rpiGa+yu368adJotRgnmZVyrUa t/KBMdj37vHwCGOYjDNrYYqMrMoq2hUBTJVCoVBHKaEQZ2GmZbINvrQ4TXCKK1Z/pCzZcVwW+ji4 dZDkH9YJ9o1uaXFRWQHLtB9xLBxZFxpOSj5iF7KR+TT7SDf75DzWy268/mkkI0VoU1O1+tB4p6sm hi2NG91tZKLUUt0oJRd2F7uOLkm9sziOw91JsAq1La3amZGP3T2YxGZfX3abKdeA4C5hH+2iAKZq /vz5JEp1dnbSLsQ8sY6dV/f3d1/p7e7vbesn/+ysbszyCPmcyTNe19edrmkzz8iS1Mq4VOaUeI4m dNmERGhv91O0eviOvsKy5BrNB0dDl/Yj46LUyAsmMInLtZ4d4Q4dYU7As+/gW3zoY+1gJz3fiO5Z fAfBMoWnZWh39479//buJKiNLN0XOMte9aojXtxe9apXHXfRq4676Kgb0fsXL+Iqbt+outFV3VWu 0VW47LIBZQoZYxtMGWPMYAFSSikEGDHPMwbMbCYbMwrMjM1kZhAa/FISiERKgQBJR4L/L05UVFcj 9CmNpT/nnPwO2iDAyeijy3yJhcUGI2bDITD85je/4aLU1NQU6UICk5vNEDLKdw4eYY80/57fcPh9 DvsbRLxyePPY7vm/DrfRHTwpf1XOOUp9/DgTIbAa+Hft/OEBDW41Q0iIa1zAmQ5wCjt6fYQ6A6t7 cFr00WW+oha0QIfA8Nvf/paLUjrdee8Fu6TciFJXqhv4a3/2KKXhRZqdmYNdTBnlK/rNFV5ThZ3t iVCH2+jcjVIfDfPlDsV81ng4kfXxSJQSP23MtWxct43qtNDDZUTLHFr5suEjgHs6h0d45+5hdQ/c FSSV8o855kZzPzZNQQD43e9+x0WpgQH8uJ7JYZQSF472tA12NB6OltrB1xObjvM5B5lH3MVr6+te q8xTRynOYONhb6sgea7DlrjDbed1Qll6Wxd9sF2KP7EGcLyUknL7RyElU5IuBwKJOFnFn5sKV6oH J7FoAv7u97//PRelent7SRcSmA63nee6mTQEM4+bUeqV/siTuhWlWnhRitfS0+F5XTRD+PhxtWF/ 39TBHYgAx1tYXeXPKpAuBwKPhGH5m6bupGfMLuHABfBrf/jDH7go1dGBW7TO5KRmCM6Eo9T4Qdfx /Ib1owt83Fjfb0J+sMR2jgW+Ky1HZp9OjlL2+wpd3KII4KCys4t37h5W9+AsHFqgxzzLWdvcIl0U gEt//OMfuSjV1ISTj87EQ1Fqx5552CKn2a3N8uqkiOK46JYew9EnPdO2838W8nY9nRilDPZNXDg7 BtxgMpkePMuxfwLeiEGUgrPgPpX4E1PcSCos2UUrafBXf/rTn7gf2traWtKFBCYPRSku9gQfpB3N zJHtVSujB00+5Qcpy70oddgMISFp4aOhMOMgTcnS7M0Njt8rtb7QYj+G79+LW9x7fXCpDU1NY0oK POKmXO4wN5VeU2dCF3TwS3/+85+5KFVeXk66kMDksSjF39T0PTM6YZk5Mq52daXZJ5QeH3SmcidK 8Vt0MjPWVvb2pgqW4LT/QN4erevR1Wx0eZptPK5mI7T8O/i+b0Q7fHCDqqrG/sEnliNKwblQDCM5 ekNfaRv2ooA/+stf/sJFqcLCQtKFBCb964OmT+7uyrZnHqdT7Zaesi73nP9nccvhstzBkwpGKcu3 NeqCDx94+M4z25tk/4Yaa75yb7u7uBx9pcANi6trvCkpbDgHD6DkSsnRlb62gaGTHwbgW3/961+5 KKXVakkXEpjsp9053RznykF3AnGXwAHBm7XVEc5hJrTl9ZGmTgdPym8Sdfht9R917dEHj40+enbe rjbj4OA/66Ys/uSVwEi4HtHYsoB+w+Ce0raOwx4IDDqcg2eIFSqHNNU5PEK6KIAj/va3v3FRSqPR kC4E9hk233UNtpT3NtT2d3TNTKzoT34IAHG7e3uR6Zn7U1JK9bW0NNIVwcVBKViHNIXzjsGDBgZ6 OjoazjP+4z8sC3w0HXLO75OXxy4u4iA/gEuqbWDocHUP7aTA02il49xU4ysXLVwATqOiIreuLv/1 6xfnGRLJL//2b/+nqCjjPN9ErY77+edPZ2YmSV8SACDAbDY/zis8jFJyRCnwMOczZbhR243m0nAu bW31paWac+Yoj4ziYnVo6BcREV8jSgFcTqMzs+hwDt4mEkpTlZ1dpOuCQDU09DonJ5V4iOJGU1PJ zZv/+PXXYEQpgEtLUV51uOFcgQ3n4C2fCKWpkrZ2M/pNwSnNz8+o1U+IhyhudHXVcTnqwYOfEKUA Lq2phQX+5xr3YUe6IrjIBFf6Cl60oHsnuG9zc0Muf0g8RNlGSMi/oqKucjkKUQrg0kqvqUOHc/Al y61STmkqp6HJZDKRLg0CQ1JS1MOH4thY8kMi+T4y8ltbjkKUAric3q2s8Nty3pLJSFcEl4VzmlJW Vm/toJ8wnKy4OLOpKd8fRkrK3ejoq4hSAJeZtqGJ91mGKSnwKe5HziFNPdTmzS0tk64L/B2iFAD4 ieX19XBVur2X1I1kRCnwNYpx7DcVoc7oGR0jXRf4NUQpAPATBc2tvLacuHEPyKAVaoc0Zbutz4it U+ACohQA+IOltTWpfUqKYW/JMCUFxFBOK33cSCurWN8WOOsUAFEKAPxB9vPGw48tBm05gTAxw9BO gSrmWc7U+wXSpYHf4UcpufxhTg7r46FSxSFKAVxyc8vL/BP3KLmcdEUAH8NSU2nGcW7qNqvpGBom XRr4F36U0moJnL2u0SQgSgFccmx1LU6KAT/0iVQqcWqSYOs6ta3Xk64O/AWiFACQNfHuHb8nJ3ZJ gb8RMyztlKZisnNGZ2ZJlwZ+AVEKAMhKLa3ALinwc3SaSnB6qqilbXdvj3R1QBiiFAAQ1P92gv/B FKpQkK4IQFhogsq5Izo3YnPyxubmSVd38Y3NzTEVVQMT/hgMEKUAgJQ9g+GhNg9TUhAoRCKRhFE5 L/ZxQ9vQhFYJ3mM0mR48y+Gu811N1o7/7VJDlAIAUup7+3g37rFX4+NJVwRwMolc5Xxnn+1Tvm1g yGQ2ky7wAlrZ2LBf5x6d3zWfR5QCACJWNzcj1Bn8KEW6IgB33ZTLBbdOcSO5uBS9pzxuR6+3X2FN bT3pchwhSgEAEc94PTm5HPWJVEq6IoDToYTu7LONzLrnS2trpAu8UOz3p9xmNf621R9RCgB87+38 O/7nDqXAiXsQkEKSkrhfBAQDlVSVXtLavrmzQ7rGC6LlzYD92vaNjZMu5whEKQDwMYPR+KSgiN/e nHRFAOciZhiJ0O4pbkSmZ9b19KGf5/mtbm7ar2pGbT3pco5AlAIAH+M+WXh37bFUKnZJQcATiUQ0 wwp2S7DtSK/u6sYM1TnJSsps1zPCz9b4EKUAwJfef/hwm9UcfsookKPg4rgpl1vSlItAdSc9o7zj 5frWFukyA9Ly+vrT4jL7xewcHiFd0SFEKQDwGZPZnFJazvtwYW/EIErBRROWKtzM075rOrfpxczi EukyA4PZbNbNzmXU1oer0h3ulCRd2iFEKQDwmdaBwSMfK3LsNocLi1KoaKXLQMUN7teKV+NvjSYT 6Ur91LZe3/Jm4HFegasL6D9xFFEKAHzjw8ZmZHomf5cU6YoAvCsoKIiWKwX7edpHzLOcmq4edE7g m1taLmhuvcPrOyc4uK8hXek+RCkA8AGz2cxUVPHfBq/LZKSLAvAFLlBRjNpVByr7SC0t7xwe8cNT UXxmdXOz5c2AfW+5q2FfPL2TnuEnlwtRCgB8oOl1P//NUIwGCHD5uDpxhj8iWM2z5439byf86g41 r1rf2modGEwrqzghQVlDlJhh+PvQ2geHSJdvgSgFAN42t7TMv2sPjaTgMhPLXd7i55Cp0mvqukd1 Wzu7pEv2io3t7fbBYXl5ZfhJl4LLn7SCpeRy2wNDGcb+fz3KzTf5wWYzRCkA8Ko9gyE+v5D/xnhL hl1ScNndSGYpRnXiqp/E2jWdyxvPe19NLSz4Q2w4D/2eYWR6pqLjZWJh8Ykv3LaWRzEC9/nyv8Yf Op8jSgGAVxW3th1Z2sNuc4ADV2Qy/uafE8ddTZamtr5tcGh+eSVQYpXRZJp8v1Df25dWVik92tDg +BAlVricvqblSvtXJhQUmc1mX74iZ4hSAOA9Q1PTDm+PpCsC8EeWSSoFF6jczVQS66ZreXll1cuu gYnJNX9q+8llJy7pdY3oSts6UksruDrdfVGWdvGWd4kT70kRiUT8azU4OeWbl+YKohQAeMny+vo9 TRY/RwUzDOmiAPxamGVbtdqdzVQOIyozm0tWxa1tbQND43PzG9vbvinYYDQur62Pzc21Dw4VNLcm F5ceOc7AnQmo/d1Q6l9O8/5AK1T27yArKfPa63MLohQAeMOewXBkOwT3+ybOiAFwG5XK0u5tpnI5 baXOiM8rVFXVcAmnvreve1Q3PD0z9X5hcXV1c2fHzdagJrN5W6//sLHxbmVl8v177jt0Do/UdPXk NDSlllbEZOecuGn8mDko6zQUK04+S6tekVTK/2662bkzfBNPQZQCAG/IbXyBpT2A8xMrFFymsv49 OvVU1fEjMj0zKjP7QZaWS0S/ZufGavMe5eY/ziuIzy/kMljMs5wjPXU9NKztICybyUOSks55ZSjm cGIqqajERG7HFKIUAHhc++CQQ466goacAOdj7Z1uWQg75sRkPx3W2SdKoeZioQcviG3Tvn10j+o8 +M1PBVEKADxramHhSBcphr2Zmkq6KICLhmIYy34hS6Zi3b8H0DeDtmYnW+QLSfNiHznrXv39J/01 O3fPYPDecx0DUQoAPOjDxsaDLO3hO6oSZxYDeN0VmYxOUVpaBNi2VzGnaLDgkUkn2zNajm8+696n s79w3rrn895XPntqPkQpAPCUHb3+SUHRkV9OldgiBUCASCSybLJSKsUKpeUEQOZgWfD0s1i0faLJ mpSs/9PSX1SiUNFy9S3Sa/f81xKZnumzWxf5EKUAwCOMJpOystphkp90UQAg7LvERC5rhaSpKbk8 1LKznQnjhvVfxNZBpyhvpqZejY8PCgoiXexxgqRSfprKf9Hs+xoQpQDAI/JftDjM+d88ODMLAMB7 KF6PKW6Mz837uABEKQA4v4a+Vw6LApRMSbooALgs+A244nIL9oxGXz47ohQAnFPn8IjDfNQxh2cB AHgcnaLkvwtVd3X78tn9NkpR1FdbW5u+rwcATqV3bJzf7pj73VCswC17AOBr/BamUlX6/PKKz57a P6OURPJlX1+n74sBgFMZmJh0OOqdwukwAEDC5wzDT1NPi8t81v+cH6UyMhJZ9omPh1Yrc4hSERHf FBZquNqMvl3rBIBTGZ2ZdTy3FLfsAQA5EvmR/ef1vX2+eV5+lCI7bFHq/v0fQkL+lZx8Vyz+5s2b Xt9cBAA4rfG5+Qh1hkPzmU+kUtJ1AcClxn9TClelT75f8MGT+lWUioq6Ghr6z4aG3Pz81LCwL7Ht HMA/DU/POOYohhUhRwEAadfS0vjLfLHavB293ttP6ldR6vr1zyorNTU1WRERP+IOPgD/1P92wmF/ FDeuxcaSrgsAwMKhzVT280ZvP2NOjjIrK5EbGk18enocwREbG/bwYUhjY1509M0HD36k6a/1+l1v v3wAOJWuEV24Y45CK04A8C8OJ+N0j+q8+nTLy4sTE2NZWWkqVezNm59HRHwdEfGNL8eVr/7fj1f/ +8aNf+Tnp1VXZyYlRdy+/S1Nf6nTDXr1hQPAabUODDoezsWwIUlJpOsCADjiRgzLX+aLTM98/+GD V59xeLhfrX7U1JRfWqq6fv1/b936hy/Hjz/+97ff/tfz5zlcAVlZCTR9hctXZWVar75kADgVs9lc 2dnldM4pey2NQAcVAIAThSkU/PeruNz87V1vLXVtbm48fXqP7C6pxsY87p/l5erw8G+joq5e//kz Cf1N5J2f4h7RmvTEF02VU1NjZl91hwAAB3qDIaPuufN8FNb1AMCf0Yoj71qqqhqTyeTxZ+HySUrK A9uMENnB1RAZGfzgwY8///zp6OjrycmR2dm309O6np7msrIsLuzdv/dzZUXu8rIv7moEALv1ra3k 4lLnHIV95gDg54KCghw2TVV0vvT4s+TlqcrL1cRzFDfi4ui7d7+7desft6VX7eUZDIZ389ODgz0D b7qmpkbr6oqi7t8oLsrY2dn2+KUAAGdzy8u/Zuc6rusx7BWZjHRpAAAnu5HMOqSp3rFxD37/7u6W rKwE4iGKGyrVQ4nkq/Dwr64F/0/MgzDBand3d4aGesfHB2trC6KjbrwdH/bgpQAAZz2jY3eONo+y 7Y8SiUSkSwMAcBetVNK8N7EIVjOzuOiR7zw/P3vz5pfx8eG28fgxTWrExVEU9fXdu98F//T3G9c/ e/w44piyDYa9/v6XOl3/o1hxX2+7Ry4FADjYMxoLmludJ6NonAsDAAFIfPTdLCoze2lt/fzfdnHx XXZ2EvH5qCbLGcrJNP1lcPD/cDkq+KdPl5dPzorz89NcmuIS4NjY0PkvBQDwLa2tJRYWO01G4Xw9 AAhgtPJI387YnLz17fNuFvKrKPX99/91/edPf/zx7319nW7Wv7q6NDr6+lEstb29ec5LAQB2r8bf 3tVkOeeoMIYhXRoAwNmJRCKHTVNJhSXnPFNmbe3D06dRcnmsbfz6a2hcHOXLERsbFhkZfPfuNan0 By5EBf/09/x8zalewsTESPOLyprqgvNcBwCw2drZzX7e6ByiaDQzB4ALISQpid+3kxuK8iqD0eip 75+aer+kOMWXIyvzEZegfrnxv9z4+dqncXG3z1D24GB3/ONwT10EgEtrcHIqOksrsKinxM16AHBx hDAMffRdLqu+weShxpUEo9SN65+Jw74xmc4SC4eH+9RsPHojgGdNLSxsbO+QrsJHtnd3cxpfCExG MWqJXEW6OgAADwtLVVne33hvdzkNTR5p3UkwSl0L/mxtbfVsZU9NjZWUZKytefdgHbhUSlrbub9Z Mc9yts+3hu7/zGZz96hOcDKKVrIhCgXpAgEAvIJWODab0noiTZGKUtwYGnp95rInJ3WFBezq6so5 Xz7AR2u0KLbmqP02brox0hV50cziUkpJueBtetzva1fj40kXCADgRRQXpTyRpqamxisrC2wjJiYk OTnClyP+MfXLjS+Sk6PtNdhGcXF2f3+Pmy9hYKCbUTw0GPZO+9oBHFhzVBv/r1Xb4MVstbG5s1PY 3BousC3KsjNKLEfHAwC4FBwmpriR/bzxVGmKix9KZVx7e5W/jV9++by19bmbr2JoqDc+XnqmSwhw yDlHcWN++aLNdu7o9XU9fYK9DmgcBwMAlw+lFEhTRrfTVH6+urOz5vXrF341UlMfhIV90dn5wp2X MDzUV1WV29nZeI6rCCCco+p6eknX5Um7e3sNfa/uZTwTmomyTEZRaBsFAJcSzagc3hLZqhr9nuHE B46PDxcUKIkHJ4fBRbuQkC/u3fvenSg1OzsxONj9OI42Gg1mD93GCJcQ99tHbpPj/Ws13e4uMfu/ Hb2+6XV/VGa2YIiilSz3NoKdUQBwmVEKx7mpp8VlmzvH3cdtMhmVysfEg5PzkEi+jY6+6ipKlZVp Vap425DLH3IjISGCYR5FRYXodINeu8BwkXG/d7DVtc4BI7GwuHds3P05Xv+0tLZW2tYRmZ7pYibK sqJ3MzWVdJkAAORRTnNTcbkFK+sbrr6+rCy7ra2CeHByGOnpTySSr379NTgy8rvu7laHmt++HXE1 jXbjxj+mpsa9fI3hAtra2ZWVlLmMGUr1Q21ufW/fh40AO5nIbDbrZufU1XXHvDSs6AEAOKCd9k09 yNLOLS87f+Xc3LRWm0o8ODmMnp7nt259weWomJifbt++ajzaxZ37aFCp4gUf+OSJNDz8K0QpOK0P GxuP8wqPDRv7I1ypVlZW942N73nucAEvWfiwWtPVE6vNO+4VMaxYoQoKCiJdLACA36EZlUMv9Lua rNGZWYcvUyqFMwnZcfv2j/fv/8BFKYr66sMHx9umamuLm5tLBQNYSMgX3AMRpeBU5pdXYp7lOGWM EzIV9xeqsLl1eHra3zLV2tZWc/9AclHpSbGQpbkQJcUdrwAALlEKlUO/qXBVenP/G/sXcJmkqamE eHByGAUFDEX9i8tRNP1Vf3+3w4taXV3JzEwSfGBkZHBU1A+IUnAqbyYm76RnHN16raaUlmZKt2SO /W8Fxx11hqa2/uXI6MY2sROLjCbT2/l3VS+7kwpLTiyYVrKUQv0JQhQAgBtouWOa4kZeU7PBaFxe XszMTCYenBxGX1+jbWkvIuKbkpIs51eUkfGU+xrnBzY1FYeF/ZN7YHj4lcXF976/1BBwzGZzfW+f U8ywrHnxvywkKckyx3vSJJXkYIN6cWtbj25seW3d2/XrDYbJ9++b+wcy654L9oZyXsuzLv0rvV0Y AMAFE8owEqetU7KSMpXqyatXTcSzk8O4d+/ne/e+v3//h+Tke86v5dWrlxUVWYIPpKivY2J+ioq6 mpQk8EAAB1wOyapvcM5RtIukcTU+XqxQ0k4nCxwzorO0mtr6mq4eLllNLyzunO8IP5PJtLK+oZud ax8cLmxu5TKbVJXuZiWWHMioKRlCFADAGYmTHX+nDn+aoNWm1tXl+9XgSgoL+yeXiO7cCTaZHPef 7O7uJiRECj5QpYqjacvtflLp9wbDyX204JL7sLEpuBBGp5wcNm7JWMtNsu5NUjmHq9TSci5fFTS3 Vr3sftH/pntU1/924s3E5AA3JqcGraNXN9Y6MFjf21fW3pnX1MxW1cTlFrgfnI6GKJZSqD7H3XkA AOf2XWIif9fH/cQHqalR3EhL40a0n4zISMstexR1ZXNTYHGku7vt8WOJiwdes+5R/3J2dtr31xYC y8jMrHODSu53jZtyufvfJCgoSJymtBwm7jTlS3zQB/8MSUry3mUEALiEuDd/+9v+IyaxqSnf3wYX 7Wj6y9HRN4L1j4wMFBUpBB+YknI/IuLr6upCH19SCCxGk6nqZbdA/GDY88zb0CmWhT/LXy631/68 lKAsZciVSFAAAF4lsW72iHoal5J6nz8OZqhIjsjIa9XV+a4qHx0dsM5KCT8wIeGOLy8jBJzVzc3U 0grnEEUxak89RWiC5S4P2/Qv7YWwJBCfGOtLULJhDIPeUAAAPsO969KMkkpT8IdEztR1dW1tbW5v b5Eazi2k+Ewmk6sH9vf3GP2stw/4laGp6fuZgkf3emsn9hWZTCy3nGdnvW9OLTnNfvVjs5M1qjFq SqG6kcyeXAcAAHgH9yYs2DCHrapZ29oiXR2Ax+wZjWXtnYLzOVSqT6PI55ZfYRguAlEKNcWoLPus rCnLtjh4+E/L2O/JsP81CpVYoUZwAgDwN0FSKeXUEZ0b9zRZvbox0tUBeMD0wmK80HEw3I/9d4mJ pKsDAICLgPu1V/C2bk1tPcHWzQDnZDAaq7t6wp0aCNg7mQMAAHjKdZlMcIvs/cxnr8ffkq4O4NTm l1cSC4uFJqNYdzpHAQAAnJatT4Lg7qms+gbsnoJAYTAa63r6BLtZcj/eV2Qy0gUCAMBFFiZ0xAw3 ItMzW94MmEwm0gUCHGdsbu5xXoHgjW+UQkW6OgAAuBREUun+3UNOI6moZHphkXSBAAI2tre1DU2u ugfg3jcAAPAxmmEEj8MIV6qLWtq2d3dJFwiwz2Q2tw8O39NkCeQohhUzCFEAAECGpQeOUiXYVDA6 K7tzeATrfUDc5Pv3T4vLXE1GiZOxqAcAAITRDCPYKoEbTwqKRqZnSBcIl9Ty2npWfYPLfuByj50F AwAAcE4ikYhiVIKfWdxQVlbPLx932guAZ23v7pZ3vLzNagQbb9JKFof5AgCAHwqTyQRbJdg2UOW/ aEbDBPA2o8nU8mbgfobgUXrcYGk5VvQAAMCvUQoV7WK9L0KdUdbeuY4G6eAFXIh6OTIaq81zNTtK KdlPpFLSZQIAAJzM2i1B4OQ+e6Aq73iJE2fAU7gQ1TWie5STLxyirDOlN+Vy0mUCAACczrW0NFfr fdy4o86o6OQC1Q7pMiGAmUymntGxuFwXIcqyvVyN7eUAABDQKJnS1fSUJVClZ1R0vFzd3CRdJgQY g9HYNTLqqm+5dXs5F+NxlB4AAFwQYoVasP2UbUhV6TmNL3CXH7hjW69v6Hv9IEvr6seJ+0mjFGqR SES6UgAAAA+jGPUxS362tgmjM7OkywQ/9WFjo6y9MzI90/WPEEsp2WuxsaQrBQAA8CKJXCV4ILJ9 JBQUd4/q9oxG0pWCv5haWNA2NElV6cf82FCM6opMRrpSAAAAH5EolccHqnsZz8o7OhdXV0lXCsTs 7u11DA0nFhYf83NCK1maYb9LTCRdLAAAAAEUw7pqQmUfioqq1+NvjTjO7zJ5t7JS3Np27Frefqso dDkAAACgLTNUJwSq6CxtdVf34uoa6WLBi3b39rpGdKmlFSf9PLBihsVyHgAAAJ/Y2ofq+H3p3JCV lLUNDG3uoCHVxWEymUamZ7QNTRHqjOP/9GklS8nR4gAAAMClYIax7H45dhuVxNo/Ib2m7vX4W+xO D2hzS8vlHZ3Rx3Q22E9Qlns/wxiGdL0AAACBIUgqtXVOOKa9p23c1WTlNTUPTk4hUwWQ+eWV2u7e J/lFJy7sWppEMapghCgAAIAzuZmaKrEc53fCJBU3ItMzn9U3vBp/u7u3R7pqEGA2m6cWFio7ux65 PuflcBrKmqIpJCgAAABPEIlE1kmqk2YwrOM2q1FX13WNjK7jxGQ/sGc0js7MlrS1x2TnuPPHZ9kN xajDUlNJFw4AAHABhSoUtEJ9fEMq/kgsLK562TU+N2/A8p9vLa6utQ4MstW1J+4kP5iGsu6GUihI Fw4AAHApUAxDK1iJe/NUtuW/9Jq69sGhpbV10rVfWNt6/eDkVHFrW2xOnpt/Lrb95BTDfiKVki4f AADgMrIelOzu2p9txGTnZD9vbB8cfrfywWw2k34FgW1je6f/7URpW0diYXG4238E1ps0LSEKDTYB AAD8RJhCYdmdfppMxY37Gc80tfUvXr+ZXljEIqA7uPC5sLraoxsrbG59nFd4qqstYVjrHXlqnDgM AADgt0JTVLZGCpKTun06DKkqPamwpKC5tWNoeGZxCcnKbnl9/dX424rOl4ryqhMPcxFMUJY/DgX6 kwMAAASS6zLZfvv0U05V2cZtVpNcVFrY3No6MKibnVvb2iL9gnxkR6+ffL/QOTxS1t6prKy+n/Hs DFfPFp+4EYqGBgAAAIEvLI2llOwZpqr4464mK6W0vOBFS3P/m5GZ2aW1tUCfuTKaTCvrG2Nz87bg pKqqcbNlgeCw9lO1BFcs4QEAAFxUn1tv/duPVWfNDPzBZY+0soqcxhe13b1dI6NcLFlaW/e3NqH6 PcPy2vrk+/d9Y+MNfa8KmluZiqrYnDypKv2cL58+SFBcfApNUJF+oQAAAOA7IpGITlNRjErixgk1 px0R6oxYbZ6spExTW1/Y3FrT3dM2MNSrGxucnBqfm59dWlpaW1vf3tYbDGeu32A0bu7scBlpbml5 fH6e+849urG2waHnva9KWtsz656nllbE5eafZXfTiQmK2Y9PuAUPAAAAbCyH1ChUtIK1tIv0dPY4 ZoSr0u9qsu5nPovO0sZk5zzU5nH5Jz6vMKGgKKmwJLGw+El+UVxuARfMuP83Oiv7XsYzLh3dZjU+ q9C68cnSdEKsVFNyeVBQEOk/KwAAAPB3YTIZpbAc/2fbuO6pBcEAGAev1zK4K8AwIpGI9J8GAAAA BLZPpFJKLqcYNaWw7V332G4rsoO2vxZGJbYsdCrRsgAAAAB841paGp2mkshVhzNXvl0cPNVck7XH OGubZxNbp5uuIzUBAACA/7kaHy+2dF9XcilLbF0llFjnsuxTQJb/ovTMXndbOjpckrOmJopRUYzt GRmuEhFOuAMAAICL6BOpNNiadiiZkpLL6RQlLVeHKRTiNC6DqcVpSlrBcv/CJSLuv4dyX8Z9cVra Tbn8ukyGlTgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAE/1/ N5lF+AplbmRzdHJlYW0KZW5kb2JqCjkwCjAKb2JqCjw8Ci9TdWJ0eXBlCi9JbWFnZQovV2lkdGgK NzkzCi9IZWlnaHQKNzgzCi9Db2xvclNwYWNlCi9EZXZpY2VHcmF5Ci9CaXRzUGVyQ29tcG9uZW50 CjgKL0xlbmd0aAo5MgowClIKL0ZpbHRlcgovRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7d15vFVT /wfwc6fm0hwSRSmiiUiGRFLRU6gMSWUmKhXFIySkDIWEiEejqFCiJzQYoqeZNEcDzcNturc7ruec O3C7d597z9lrrf3Ze+3P+49f9/d7vezzXd/z/fzuPWfvvXYgQERERERERERERERERERERERERERE REREREREREREREREROScOx5FV0DkQn+IS9AlELnPRDECXQKR+9wkNqBLIHKfMsniPHQNRO7zuRiM LoHIfXqK5egS/CGuUxl0CRSFyunidHQNvtBPDEOXQNGYL/qgS/CF78W96BIoGr3FAnQJfnBSmjgD XQNF4wyRXgldgw90Fr+hS6DoLBN3okvwgXHiZXQJFJ0nxSx0CT7wp7gaXQJFp75ILo2uwXgNxbHi 6BooShtFJ3QJxhsoZqJLoGgNF5PQJRhvgXgAXQJFq5k4mICuwXBlU8WZ6BooWjE7xbXoGgx3g1iH LoGi95Z4C12C4caKkegSKHqtxY4YdA1m28rfyV6UkMgbXLU6TySVRNdANvAGV70GiNnoEsiOTrzB VatvxUPoEsiOMsmiProGg5VOEXXQNZAtM8WT6BIM9i+xEV0C2dNTLEOXYLC3xOvoEsge3uCq0++i HboEsmkBb3DVpp44XgpdA9nUhze4avOImIMugeziDa76zBV90SWQbctET3QJhiqZLOqiayDbnuSd NJpcJ7agSyD7eIOrLqPFGHQJJIE3uGqyUbRHl0ASRoiJ6BKMVEekcNNaL7uEN7hq0Vt8gy6BZMTs FK3RNZjoK9EfXQJJ4Q2uOpRIEueiayAp14q/eIOrcm3ENnQJJKdYomiGrsE8r4l30CWQpEliOLoE 86wXHdElkKROYj26BOPUEqnl0DWQpDLHeYOrar3EfHQJJG0Wb3BVbZZ4DF0CSbuTN7gq0HJti79/ Ln5MnA8shdSowhtcFZia5zuMa8SfwEpIlQWiN7oE7/sjz+51r4j3gJWQKn34UVFaJZEnGGvETcBS SBXe4CqvXZ5gnC7SyiNrIVWW8wZXWc/kCcZ94jtkKaTMYPE5ugSvm50nGJ+Jx5GlkDLniSTe4Cpn 1z/BSDgsGkNrISnNBv7zpN2N/LQop6b4JxhXiZ28XtnDvhTv/v3zS7zBVU6XPMEYIT6A1kJy+gjR I/fn5rzBVc5LeYLxq+gCrYXkVEwWSQ1yfo7dKa6BFuN1C8We3GBUF+kVscWQnP8IsSH34ui3uQuS jNjD4ovcYNwtfsQWQ5IuCf76n57zM29wlXKeOPJKbjCm82Jlr1sdTMaA7B+LHeINrhLuFPNG5AQj PlFcCK6GJPUKBiPtsuyfJ/MGVwlvieG5wbhC7OHvXo8rnyQ2iR3Vsn7uzBtcJSwTN+UGY5gYDy6G pI0T01aLeXGhH8sc50ZIthVPEafnBmOluA1cDUm7SCRdfFgMy/p5lvg3uBrvaib2BHKCcUpmRmV0 OSRtlejTWWRmbct9p1iKrsazHhYzc4PRU/yMrobk3S9WB0aKg7UCWTe41kCX41UTxODcYHwsngEX QwqUOyouT/hRLAtdTriQN7jatV5cmxOMuAPiYnQ1pMBYMTFQfU/W5YR9xTx0NR5VLlNUzgnGpWJf LLocUqCpSK4YaJUhuoeunOYNrva0EpsCOcF4TkxGV0NKLBX9Qo+oDF1OuPyfq20pGo+LKbnBWCa6 oashJe4RawOBmNmhywl5g6tNn4pHcoJRNTOzKroaUqLMEXFlIFBxi5geOJ83uNrzp7g0Jxh3iCXo YkiRMaG/AwIXHhf9A5vEjehqvOhkkV46JxhTxFB0NaRIY3E8dKr2fpF22UtiAroaL+ogVgaygxG7 TzRHV0Oq/Jy9M/cE8dcNvMHVjuezvu0OBaOZOBCHroZU6Sk2hK6TLrVaLNjLG1xt+FrcE8gOxhAx FV0MKVPqkGgV+rfuYZHBG1xtOCAaBbKDsZhfeJvkDfFJ1r+dheANrtE7WyTHB7KCUTkj8xR0NaRO A5Ga/eX7qGAyeKVPtLpmb34QDEZXsQJdDKn0Y85eqwmLhHgRXIv3vCZGhv4JBmOCeAFdDKl0h9ic /RdU9T28wTVqi8StoX9GiJf3iMvRxZBKJQ+Ka7N/apUhymJr8Zz4JFE79O8IMV8kxqOrIaVGiRk5 P7W/E1qIBzURB7J+3Y4QqWIauhhSq75IOxldg1fdJ/6b9e8IIcRd4FpIte+4e55d43IujwoFozq4 FlKtq9jCG8/s+UX8K+vfYDB+AZdCypXYL9qha/CmUuki+6ReMBjcy9E8r/AmJXsuF9uyfwgG40po JaRDPZHOP5Dt6J+7YfwIcZiXJhtoHvdDsmWqGJj9wwjxKbYS0uJmsY23Etjwu7gq+4fLf22BrYS0 KLY359sVikYlkXkSugbSariYjS7Bg9qGNlkhk9XJzODetVF7WnyILoE0+5o7XETvC/EQugTSrJP4 ixeHRmu3uAhdAmmWsEvcgK7Ba84QqcXRNZBuL4g56BK8pjN3HvSBMzMzaqJr8JiXxJvoEki/OV66 Z7l83RZdeg997f2Pv/ph1e9/7dy9d//Bw0f2bd/4y/8W/nf62GH9e7Rvfrb2rXgXcL8cP7hB7HT9 5T4xp17WfcjERVuPi0jsX/H56MduuVjXObjYw3zUrR/E7xCd0DWEF3Nmx8Gf/JYUUSDy2/Ht6F5X q9/zqb44wttY/GCo+BpdgqX4Jg+O/emIrUjktWv2kPZK09FTzFd5OHKrMzIyz0LXkF/Vfw1bcEw6 E//46/PHm6v6g3EM703yiS/c9U5XueW9zQoz8bdj3wy+XMX5h6Vu/tOTFGovdhdD15CjZOsRKzJ1 pCJH8rwB50iWWDxFnK5kreR2cX+KW9A1hFR/cG5kXzvJ+f2NtiUkqrxY7Fa2YnK3p13wcbLeoMU6 f1Wc6NjM7ra/zH1YzFK5bnKx09LF2dAC6r+w1rFQ5Dj++W1lbNU6XjylePXkWp+LV3AvXrXvMqdT kS1pWmcbf1OtE23U94DcqZ3YB7petMTNX6RhYpHlwOhGURZcLlNU1tIJcqHYraIr4nUbvpMITEW2 ZQ9E9XHjarFZVzfIfZ4U3zn+mgk3f48ORbak8VHcdzQo6wnp5BOnpgnZ7/ejdMrTO9CByGNR50i3 EZoh+mntC7nLDDHKyZdrOiUVnYV8tj5aPqLK/xSXae4Nucm14oDMWa/oXDEXHQMrR9+IYMOUk0W6 9vs9yEVifxd3OPRSbX5ARyCclLdrFlV8B7HKgRaRezye/Xxe3WJuBJ20iEzquCIuNH5OvOdEm8g1 qqWK8/S/ynW/oke/KOkfnlnYAuaKe/V3idzkE/GG7pe4aAF67CORMqpS+CUcENGeESSPu1okltL6 ArU/Ro98pBIHhfsioo5I5v50PhOzSeh8qnGVN9z2BW1htne3vq37Nmc+ieWKf/23Ua7fqcJ4j4rF 2o4d9/Ah9KxHadnFVusY5ezpnkHBQu538gXJQpUU0VDToS9ejp7z6GWOrVhwIYvEbZpaZKXEnmAd 3HQbbop4S8txK7ydgZ5yW/bdFZNvJfFJoo6WFlnrFaqCH/bhrhSHdZzV7b4HPeG2Lcr3K7SxOJA/ KxrFbQqWwAf7uMB6cY/yY9aaj55uGanPnPDZ914xV3mDwrstVMEVDr4ghdFPLFV9yLsPo2db0ooG eVbznnhOdYMKEfpg9j8HX4/CqXRcXKD0gKfMRs+1vNQn/zlzscrJZ3m2Cb16R+dej8KbKMaqPNwt +9FTrcTS+jnrKZUu1G+FG9b84Euv5y65rnC5OFJW2cEqTEVPtCpJ9+S2Z7uy7hTpwtAr6zzlSlFY o+580oV/gMdZpY/KhZbUT8xQ1Z2iTQ++7A4+0swl+ogVio70YAp6mJXaFPrw9ZEYpKg7RasdOvfT 37GXo8JVSFLzQNIyU9CTrFpKn0Bgs7haRXMi8m7wNRPLOfZyVIQPxTgFR6nv+MaCDph6msjU9ZSm Ak4O7eL7vFOvRkVqLo7Jv/m3qXy0hXtsFGsVdDgyI4Kvd/xkx16OivSL6CV7iCHoCdbmKxUdjkS5 0EZ0eq5cM97JtbQctpf4Re4AJSajx1efdKfuaw1db57h5PWK5nggXc+tAScdE81l/vsqi9DTq9Xr jpxxKxbajG6qE69knn1C0xXJ74tJ7R/o99gTTz37wogXn3vmyYED+nS9tFak34+c+zt6dDWb7sSp hXtDr3ShAy9koNAlyWPUHjL2/EGzf1rzV5rF3RNJOzYun//e9UV+Lr8av0mzbkeXfPlkw0g39LT5 RqwPvo6T1/Ga5Olg7w6p270gvvU7C9cfKGImUrct/bx39UKO0tGJR4W5QOKG795rp++5hZ1Cr+Hc KROz1EgPNu8uNceKaTFtbXKkQ/HXjwMt7vnM0hX5qAunHV//WStNHzgWBw+/XM+hfWBWsHtKdi+o /59fo3vMfOaWeXdb/aV9nzfvYLXv6OoJOj7mXR06dmcNB/aH60Ptk9+9oMX8vTZGIm3NCwXugh2g dOg8Yv9310i/BfmFtrzerPdTjMnitgv5j9915h20OREZ6/qfePuzuaf1Cpf43bmSb0I+DUNHvU/t MZ3w6rcusTnYv7T5f/+vl0e/lNiRf0pMRPLiunmONVTNmHnRjjFKdyf8KHjI3c49k0EZt+6/elPU Kzn5e8nNAbf8c/XIo2oW4U1pP52ubr5qhb5Vce7ydnWMCcZZq6Vf8+CwnGPdp2ABXra2fqGtjsaY 4OGORPZ0J3cxJRjV1ih40SNDso7V1W/fRxWwIYKnMUWkSlLwaCMUHcxRhgQjVs0jU3e1Cx6rg5/O X4Txs6LNl58PHiulsJOormVIMB5TtPn4ktjA1T45312o9CFKpqtM6OoDbz60yZBgrFD0smntzjH/ +qhIrFYyXf2DR8qsp+RQTjMjGGWV3WQ3arOqI3nb8coKhishdHLKwa1IVDIjGDWVve5OZUfyOBVf TPUMHaiZggMBmBGMy9HlmkfB7qYxvwWPM1/+OBBmBKM1ulzzKPhk0CF0nDbyx4EwIxhN0eUaJ1PB 5qY/Bo8jecs9jhnBaIQu1zgZ8hdMXRE6jpPPMlOKwSArqfLBCD00YYtnH5fMYJCVFOmJrp8ZPMxD skeBYTDIinQwXtsaPMrxz2e4TaS3mzAYZEU6GOvRKwijRYT1MxhkRToY+9ArCIPBIBmywajo1kv3 GQySIRuMp9ELCIfBIBmSwShlZ7MWR5gdjBJ1rrrp7gHPjf5w4uSPPp4+ddwkdLnGkTyP0Rtdf1iG BqPkBd1fmrZkN7o682VI3cIX/we6/rDMC0bplk/O2ODWj3TmkXqS5O3o6sMzKxiVu7y2hHdiO+qY zJN8VqGrD8/rwbj17wpjmj79M39ROG+6/Vy0Q9deCK8H483s8hKu+3APuhS/amk7GAuD/7Vbt5Tw ejA2BGuLbTl2P7oOH1tldyfmi0P/tcx2qTp5PRiiQe0RO9A1+Nz9NoPxWfC/3f4buvowPB+MbZno Cnxvr72tNeuG3rlHGAwy1qs5Q1K8dtOrb+zR56mX350657+zpk/58N03Rw4fOuiOVudYPeXz/eB/ eaAMg0HGOl6n4U2Pjf12ayFfCh5ZP2/Ciw+3zPO4tlNTgv/noQEGgyj4l+/MZ288K+vZOy8H/7fk qgwGUa5D37/Rpdbh4A+jAwwGUV6hP7vSz2QwiApIndW7HoNBZEHRcxmUYzCILDAYRBYYDCILDAaR BQaDyAKDQWSBwSCywGAQWWAwiCwwGEQWGAwiCwwGkQUGg8gCg0FkgcEgssBgEFlgMIgsMBhEFhgM IgsMBpEFBoPIAoNBZIHBILLAYBBZYDCILDAYRBYYDCILDAaRBQaDyAKDQWSBwSCywGAQWWAwiCww GEQWGAwiCwwGkQUGg8gCg0FkgcEgssBgEFlgMIgsMBhEFiINRsdeWk1B94HoBJEGQ69qB9F9IDqB O4LBXxjkMq4IRmt0F4jycUMwSm5Gd4EoHzcE49/oJhDl54JgVExEN4EoPxcEYwS6B0QF4INRPQnd A6IC8MF4B90CooLgwaiThm4BUUHwYIxDd4DIAjoYp6WgO0BkAR2MkegGEFkBB6PSUXQDiKyAgzEE vX4ywYf/Vu50aC5K7Ue3lEzwLXSKNbgH3VEyQyP0JCu2Et1QMsOH6ElW61J0P8kQSeXRs6zUZHQ/ yRQPomdZpWo8uUeKLEMPs0pPoLtJ5miMnmaF1qGbSeYYhZ5mdS5C95IMsj0GPc/KjEb3kkzSDD3P qiTsQ7eSTPIKeqBV6YjuJBllC3qgVfkE3UkyS0P0RKtRkheck1ID0COtRgd0H8kwc9EjrcZ/0H0k wySXQM+0CvG8E4MUuwY91Cpche4iGWcoeqhVeB3dRTKOER8y1qO7SMZJNOCqkNPRTSQD1UOPtbw7 0T0kA3VHj7U8PnSP1BuJHmtpMXvQPSQDzUHPtbTG6BaSibai51raw+gWkokyS6MHWxa3ByEdmqAH W9Yf6A6SkTqjB1vSyegGkpn6oCdb0g3oBpKZRqAnWxIfYExaTEJPtqR56AaSmRagJ1vSXnQDyUy/ oSdbzino/pGhtqFHW8616P6RoQ6iR1vOAHT/yFBp6NGW8yG6f2SqkujZlrIM3T4ylbcfrJSIbh+Z 6iT0bMuoiO4eGcvTwbgQ3T0yVjn0cMvogu4eGasserhlDEJ3j4zl6V06x6K7R6ZKQc+2lNno9pGp 9qJnW8pSdPvIVJvQsy1lO7p9ZKpl6NmWkoJuH5nqa/Rsy6iA7h4Z6wP0cMuoh+4eGetZ9HDLuAzd PTLWvejhltEG3T0yVlv0cMvohO4eGesc9HDL6IHuHpkqNQE93DIeQrePTLUaPdtSeA0haTIVPdtS hqLbR6Z6Cj3bUoah20emugE921JeRLePTHUKeralDEe3jwz1B3q05XCrc9LD43udMxikx0Po0Zbz Erp/ZKjG6NGWw88YpMXuGPRoy3ka3UAy03j0ZEt6FN1AMtOt6MmW9CC6gWSkjEroyZbEq2tJh0Xo wZbFHTpJh37owZZ1PbqDZKLM6ujBlnUJuoVkooXouZZWG91CMtH96LmWVg7dQjJQamX0XMtLRTeR zPMxeqoV2IVuIpmnJXqqFViFbiIZZx16qFX4Et1FMs4j6KFWYQy6i2SaYxXQQ60CryIkxUahZ1qJ zug2kmFSa6BnWgk+55vUeh890mpURveRzJJRDz3SihxFd5KM4u2dOfNYgu4kmSStDnqgVTipzaDJ B9CtJJOMQc+0tNIdRi7LQLeRDHO0Gnqu5VS9a1YyuodkoCHoyZZRrNPsdHQDyUh/lkEPt321X9uH bh+Zam4J9HjbdekMfq4gfVZ680upVj+hG0eGO3wzesijd8k8dNfIB94qjh706NT6FN0x8oflNdGz HoUST/PrWXLIrqbocY/YNZvRzSIfOfYv9MBHptjLmehWka9kPIye+UjUXYbuE/nOy+ipL9pdvLCc nPdOLHrwC1fhE3SHyJ8mxKFnvzCXbUP3h/xqWgJ6+sO7OQXdHfKvL4qh5z+cvvw2ioCmu/OvqRg+ xJuwxrvxocYJE9FtId97E52CgsrORTeFSLyIzkF+1XhWj9zgQXQSTlT+V3RDiELS26KzkFfJH9D9 IMp2uAE6Df+Im4nuBlGu7aei8/C399G9IPrHYrec6BuO7gRRXm+hE5GtH7oPRCfqhs5EyO28DoRc 5tj56FQEAk2Oo7tAlN/GsuhclNuE7gFRQfDnLH2M7gCRlRuwueiFXj+Rpb0nI3PBDxjkVrOBueAH DHKvO3HBmIpeO1FY+6ugcnE/eulEhRgPykX1w+iVExXmKkwwpqHXTVSo9ZAnBLRFL5uoCAMBuSj5 O3rVREVIrOx8MJ5DL5qoSK87not63HOQ3C/V8YdXzkcvmSgCMxzORTf0goki0tjRXJTahV4vUUSm OxqMAejlEkUms76DuSi1G71coghNdjAY/IVBnpFxtmO54C8M8pDRjgWDvzDIQw47tTECf2GQpzj1 EPBH0QslisY6Z56zVHoPeqFEUWntSDD6opdJFJ2PHAnGOvQyiaKTVM6BXLRAr5IoWj0dCMYk9CKJ ojVPfy4qcYs18pyM07QHgw/DIA/qoz0Y/OhNHvSN7ly0QK+QyIbUkzQHgx+9yZNu1psLfvQmb5qk Nxj3oddHZMs+vddLfYleH5E95+nMRRn+JUUe1UtnMDqhV0dk01SdwZiAXh2RTTs15iJ+P3p1RHZp 3KyzJXptRLZpPJMxCr02Itte0BcMPhGDvOtLbblogF4akX07tAWD20mRl1XVFYwZ6JURSbhcVzB2 oldGJKG7plzURC+MSMYzmoJxG3phRDLGawrGG+iFEcn4XlMwlqIXRiRjm55clEpDL4xIRpKeYLRA r4tITkktwXgcvSwiOXp2XfsMvSwiOQ21BIM7rZHHXaUjF3Ep6GURybleRzBqoVdFJOkGHcFojV4V kaQuOoLRC70qIklddQSDt7WS1/XQEYzZ6FURSdLywLEN6FURSbpFQy7ieaUUeV0HDcGojV4UkazW GoLRCr0oIlk6bvrugl4UkawLNASDT4whzztDQzAGoRdFJKuEhmAMRy+KSFKihlwExqJXRSRpvY5g fIJeFZGkhTqC8S16VUSSJuoIxnL0qogkPaUjGH+gV0Uk6VYdwUhEr4pIko7ze4F09KqIJJXVEYxU 9KqI5PylIxeB4+hlEcmZpSUYx9DLIpKj5UupwBH0sojktNMSjEPoZRHJ0fNsyoPoZRFJ2aolF4F9 6HURSZmgJxh70OsiktJDTzB2oddFJKWGnmDsQK+LSIaWmzGCtqIXRiRjjKZgrEAvjEhGe03B+Aa9 MCIJR4prCsZU9MqIJHykKReBMeiVEUnQ8syYkKHolRHZl1xGVzAeQS+NyL4ZunIRuAO9NCL7dH0n xWdTkpftjNcWjDrotRHZNlxbLgLFMtGLI7Krrr5gBP5EL47Ipu815iLwPXp1RDbdqDMY49GrI7Jn c6zOYDyLXh6RPb115iLQA708IlsOajvrnaUpen1EtryoNReBkhnoBRLZcKSK3mAE1qFXSGTDC5pz wTsyyIsOVdAdjCfQSySK3jO6cxG4Hr1EoqjtO0l7MGqg10gUtQe154J7rpH3/BLnQDCmoVdJFKWW DuQi0Bu9SqLoTHciF4HG6GUSReVYTUeCEcuHx5CnPOJILgKBr9ALJYrCT1ovN8/jcfRKiSKXcq5D uQg0Ry+VKHJPOpWLQCyfN0aesSTBsWDw9lbyjMO1nctFoAt6tUQRut3BXAROSkUvlygi453MRSAw D71eokhs1HufdwHc85zcLT3rfx4939lcBM4CL5uoUJlZf+xn3uRwLgKBn9ErJyrSUMdzEXgIvWai ouyKcT4YVdLQqyYqwnbncxEIfIFeNVFRygOCcQt60URFuQwQjJKH0asmKsIDgGAE3kOvmqgIYxDB aIReNVERtD5BKSw+WolcLhESDF5iS25XAxGM+L/QyyYqXBtEMAKD0csmKtx9kGBUS0Gvm6hQ2p+J Ye1t9LqJCjUJE4wzeCMfudoPmGAExqIXTlSYbaBg1OQ1tuRm6fGgZIxDr5yoMDVBwTiTvzLIzVqA gsEvpsjVuqGCUSURvXSi8Jzbtza/AeilE4X3LiwYxTai104U1lxYMAId0GsnCmstLhiBb9CLJwpn DzAY5/JaQnKrVGAwAv9Gr54oHIc3dT5B/HL06onCgNzDl6sRz3+TSzm93fmJhqKXT2TtCmgwiq1G r5/IUgdoMALnJ6EbQGSlBzYYgbvQDSCy8gg4GHzCMbnSs+hglF6DbgFRQW+ggxGofwzdA6ICJqJz EQjchu4BUQFfoGMR9BS6CUT5fYNORciH6C4Q5TMfHYqQhPnoNhCd6Dt0KLJUWIvuA9EJFqEzka3m NnQjiPJajI5EjrO2oztBlMdSdCJy1ebjZMhFVqAD8bezd6B7QfS3X9F5+EfdnehmEOVag45DHmeu Q3eDKMd6dBryqsgnHZNLbEaH4QTFp6L7QZRlCzoLJ4oZgW4IUch2dBTy68mr0MkFtqCDUEB93rlE eG76VipHaV5sS3CuOfOdF/+cIjR3XF2bX21uUUhYc9AZsJaM7gv53HR0BKxloPtCPjcBHQFr6LaQ 372DjoC14+i+kM+NREfA2iF0X8jnnkdHwNoedF/I555AR8AabwEnrL7oCFjjQ8AJ6150BKytQveF fO5WdASszUP3hXzuKnQErPGGJcI6Fx0Ba2+i+0I+VxEdAWvPoPtC/paCTkAYD6EbQ/62DZ2AMDqj G0P+9j90AsJoim4M+dtMdALCqIRuDPnbWHQCwjmM7gz52lB0AMJZie4M+VovdADC+RTdGfK1m9AB COcldGfI1y5FByCcbujOkK/VQgcgnAbozpCfpcahAxBOQgq6N+Rj69DzHx6/liIct57fC+IGtoTz Mnr8w+uD7g35mEtvbA25AN0b8rEr0eMfXtwRdHPIv05Fj38hvkY3h3zrKHr4C/MUujvkW8vRw1+Y q9DdId+aih7+wpTkMzIIxLUXnWf5Et0e8qtu6NkvFDdEIJCL0LNfqDPR7SGfSiuJnv3CrUU3iPxp BXryi/AKukHkT++iJ78IzdENIn9y8ZVSWWK2oDtEvtQEPflFGY7uEPnR8QT04BelMbpF5EeL0XNf tHXoHpEPvYke+6LxQkJyXg/02BfttHR0k8h/zkOPfQRmoptEvnPUtVvn5HEdukvkO9+jhz4SsVvR bSK/eQU99BEZjG4T+U179MxHpBpvVyJHpZ+EnvnIvI1uFPnLEvTER6hOBrpT5Csj0BMfqWnoTpGv tEUPfKQuQneK/CStLHrgI/YtulfkIz+hxz1yl6B7RT7yAnrco8DrQsgxV6CnPQoNMtHdIr84EI+e 9mhMRreL/GIKetajUjsV3S/yidvRsx4dbqRDjsiohB716JTbhe4Y+cKP6EmPVnd0x8gXnkAPerRi fkK3jPygIXrQo3YBryUk7Tahx9yGUeimkfm8dNo7V6lN6K6R8Rqhp9yOK3n+m/TagJ5xe8ag+0aG ew494vaU5ebnpFUD9IjbdDn3JSSN1qEH3DZuZUsaDUHPt22xC9C9I4OdhZ5v+6rvQzePjLUQPd0y 2vM7W9KkB3q4pTyLbh8Z6khp9GxLifkc3UAy0zj0aEsq+xu6g2Sky9CTLavOQXQLyUAevRwkr9Zp 6CaSeR5Fj7UC3dFNJOMkVURPtQqPo9tIpnkXPdNqvIHuIxnGe/e0WorlswFIJU+f9c6r2KfoVpJJ OqEHWpn4Kehekjm2e2rH2sLFfoDuJhljEHqaVYp5C91OMkSiRx7UGqmR6IaSGby4a06hXkB3lEyQ VBU9yMoNRveUDPAGeow1GIBuKnle6unoKdbhrhR0X8nj/oOeYT2a/YluLHlael30CGtS7Tt0a8nL 3kcPsDbxr6N7S9513MhPGDm6JaHbS141Cj28WjX+A91f8qYjVdCzq1eluegOkyc9i55c3eJe5FZs FLV95dCDq19LPiWAotUbPbVOKPseus3kMasNug+jMO12oDtNntIKPbFOqfAOP2lQxGag59VBzVag u01ekVwLPa1Oiut7GN1w8gaPPovStlM/yEC3nDxgq7f3/bejwVfoppP7tUWPKUKr5ei2k8tNRM8o RkyXX9CdJzfbWxk9oigxHZc62ulUR1+NJHVFzydS2x+canPmV824mY+XfImeTbALxztxT3jia3UD gXoOvBApcsjk25MiU3Ww7utEVt6T/b3fQs2vQ+p0A0+lKyTcNFPfw8lSJjXPfZ0u2l6EFJuCnEc3 qfrIKh39zZh/f57vNuI26ngNUm9bedwouk6j59eq7W7mdw+dfOJL3K32BUiTjBaYEXStc55Q9gVu xo99qxc4frHtqg5POg0DzJ7b1bhz8m7pxm4Yc2MFy6P3UfCukW4/Jzg8dB4R03DA7P22u7pzUs8a YQ9daq/C94/02HOag8PmOXVuH70k2lPVe+YM61y78MPyOcuul97SmQnzsIT6XZ755LdI4nFwxfSn 2hf8TFFQKW6k63aPaZ8rQ8TVuPTWgW/O/HHt7nwRyTy0bfWPM17t06FhFA+i6oF5tylS0/VNkrnK 1Khd99zzGzVp2qxZ/dPKxdg5ROxK9DtPhVlbVvXQUGRaod96KsTes9Dz4V9fot98Ciu5edHvH2lS X991WSQn82b0cPgaHyXrVo+jR8PfSvBaQnd6Dz0ZftcSPQFkZYZP9ql1sffRM0AFzSmGHguqKH+d Iim2sCR6KigQ6IQeA8pnMU/sucI49CDQCVZa3yZATiu9Hj0KlMfiiuiBoBxNnNi1hyKzgH9HuccA 9DRQrtn83O0iMXy+skt8zDtZXaXqNvREUMiYOPQk0IkuSELPBImMvugxoAK6oqeCjrRHDwFZeAk9 F363vRF6BMhK3Bz0ZPjbolPRE0DWKvA8H9Cr/DrKtWrqfgQBhZN4A/rNp0I0SEQPiE8tPxP91lOh WhxHj4gfZbxSHP3GUxFuzEBPif9svAz9rlPR7kePid9kvl4K/Z5TJPqjJ8VfNl6JfsMpQv3Qs+Ij R5/gpwvveAQ9Lr7xER9+4Sl81JIjVl2JfqMpSr3RM+MDa2+2tUE9Qd2Zjp4bN1qhbqPfjbfHot9j suP6Y8pmwBTpdwVOH3lEyaFW9+Q+g151if0nYpopKetmiQpP7JI9UMasq9FvLkmot1XFOBnjwKU5 fSl+61yZqwMSR/FpMB5X/RdlU+V92+vn6czpgzfbO0rKp51KwN5PUqXMZ2qHy8P+l+8mopgrXvs9 2mOkL7yXOwyaIWaojiHzoIlW/3++/qBFkf9NteODLkyFQTrzy6ngp+WB4dpTqf2whUXvrrLl4/6N eM7CMI34EfzQdYV2KOHCB1//7x/WvzuOrJz27PVVHXqryFFVv3V4Dt1m3TmRtKnE+df3fHT4uM/n fv3tvAULvpjw+pC+tzdnJEwWO9jXZ8EnlEG/AeRWLf5CTydM0l3o5pOLVf4SPaAga+oX3RzysZjH UtEzivABbzqlIjRahZ5Sx+3thG46eUCx5332GfxTfqdEEWm6Bj2rDjrYDd1u8owSL/lm06mvqqOb TV7SdBl6Yh2x5w50o8lj4h4+hJ5a7TLf4eV+FLVTpqAHV7NVl6BbTN7UagN6djU60p93Y5NNxfod QM+vJhnv86lGJKHiyBT0DOvwTUN0Y8nrzvoEPcXKrSn8vguiiDT/ET3JSu18gI+eJzXa/IyeZmV2 9y+J7iYZpO1i9EQrsfdRXkZLal23BD3V0vYN4k16pF67+ejJlrK9f1l0B8lQF0xWtwu4w1Z142Pn SZ8zRh5Gj7gdX7dGN45MV/6xqLesBEsa1wjdNPKD2Dafeegev7V9yqMbRr5x2jN/ogc+IqlTr0S3 ivwlruMXrv8gvnpgNXSbyIeqPOTms367RjZBN4h8q84Qmw9W0SxpSjvebUFQzUdtQccgn6Of3MJT eeQCTYb+hg7D3w6O78irBMk1zh74swt23PnjrWt5fptcpvItHyA3S0+e07ceugVE1s7rPzcZEIrM X0e14R9Q5GolWvx7jpNbUqUvfbVjJfSiiSIR1/jhj3c4EIpD819owy+gyFtO6zDkC33pOPbDqK51 +YRU8qhTrn9q2m9qn0WTsXnmsNvP54YG5HnxdTs+Pn6J/I0ch1d99mK3C3jXNpmlYuMb+o76dEX0 mxvuX/P1O4NubloZvQAinYrXuKBt98deHj/7+5WbdidZRiFt3+8rFsycMHrwPe2b1iiGLpjIefHl a5xVt37DJhc1v6JF86YNz61zxqmV+dcSERERERERERERERERERERERERERERERERERERERERERER UR7/B3u3Ye0KZW5kc3RyZWFtCmVuZG9iago5MQowCm9iago1MzczMQplbmRvYmoKOTIKMApvYmoK MTAzOTAKZW5kb2JqCjgKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAKUgovRm9udDIKMTMK MApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNDkKMApSCj4+Ci9FeHRH U3RhdGUKPDwKL0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIK L0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjE2CjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MQox MgowClIKL0ZvbnQyCjEzCjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2Uz CjQ5CjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCj4+Ci9Qcm9jU2V0ClsKL1BE RgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iagoyMQowCm9iago8PAov Rm9udAo8PAovRm9udDEKMTIKMApSCi9Gb250MgoxMwowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hP YmplY3QKPDwKL0ltYWdlMwo0OQowClIKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgo+ PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRv YmoKMjYKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAKUgovRm9udDIKMTMKMApSCj4+Ci9Q YXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNDkKMApSCj4+Ci9FeHRHU3RhdGUKPDwK L0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwov SW1hZ2VJCl0KPj4KZW5kb2JqCjMxCjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MQoxMgowClIKL0Zv bnQyCjEzCjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2UzCjQ5CjAKUgo+ PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAov SW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iagozNgowCm9iago8PAovRm9udAo8PAov Rm9udDEKMTIKMApSCi9Gb250MgoxMwowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwK L0ltYWdlMwo0OQowClIKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgo+PgovUHJvY1Nl dApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKNDEKMApv YmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAKUgovRm9udDIKMTMKMApSCj4+Ci9QYXR0ZXJuCjw8 Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNDkKMApSCj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAox MQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0K Pj4KZW5kb2JqCjQ2CjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MQoxMgowClIKL0ZvbnQyCjEzCjAK Ugo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2UzCjQ5CjAKUgo+PgovRXh0R1N0 YXRlCjw8Ci9BbHBoYTAKMTEKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9J bWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iago1MgowCm9iago8PAovRm9udAo8PAovRm9udDEKMTIK MApSCi9Gb250MgoxMwowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKL0ltYWdlMwo0 OQowClIKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgo+PgovUHJvY1NldApbCi9QREYK L1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKNTcKMApvYmoKPDwKL0Zv bnQKPDwKL0ZvbnQxCjEyCjAKUgovRm9udDIKMTMKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2Jq ZWN0Cjw8Ci9JbWFnZTMKNDkKMApSCj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKPj4K L1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2Jq CjYyCjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MQoxMgowClIKL0ZvbnQyCjEzCjAKUgo+PgovUGF0 dGVybgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2UzCjQ5CjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9B bHBoYTAKMTEKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0lt YWdlSQpdCj4+CmVuZG9iago2NwowCm9iago8PAovRm9udAo8PAovRm9udDEKMTIKMApSCi9Gb250 MgoxMwowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKL0ltYWdlMwo0OQowClIKPj4K L0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0lt YWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKNzIKMApvYmoKPDwKL0ZvbnQKPDwKL0Zv bnQxCjEyCjAKUgovRm9udDIKMTMKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9J bWFnZTMKNDkKMApSCj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQK WwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjc3CjAKb2Jq Cjw8Ci9Gb250Cjw8Ci9Gb250MQoxMgowClIKL0ZvbnQyCjEzCjAKUgo+PgovUGF0dGVybgo8PAo+ PgovWE9iamVjdAo8PAovSW1hZ2UzCjQ5CjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEK MApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+ CmVuZG9iago4MgowCm9iago8PAovRm9udAo8PAovRm9udDEKMTIKMApSCi9Gb250MgoxMwowClIK Pj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKL0ltYWdlMwo0OQowClIKPj4KL0V4dEdTdGF0 ZQo8PAovQWxwaGEwCjExCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1h Z2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKODcKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAK UgovRm9udDIKMTMKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNDkK MApSCj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9U ZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjEyCjAKb2JqCjw8Ci9UeXBl Ci9Gb250Ci9TdWJ0eXBlCi9UeXBlMAovQmFzZUZvbnQKL01VRlVaWStBcmlhbC1Cb2xkCi9FbmNv ZGluZwovSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzClsKOTMKMApSCl0KL1RvVW5pY29kZQo5 NAowClIKPj4KZW5kb2JqCjEzCjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9UeXBlMAov QmFzZUZvbnQKL01VRlVaWStBcmlhbAovRW5jb2RpbmcKL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRG b250cwpbCjk3CjAKUgpdCi9Ub1VuaWNvZGUKOTgKMApSCj4+CmVuZG9iago5NAowCm9iago8PAov RmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjEwMQowClIKPj4Kc3RyZWFtCnicZZLLboMwEEX3 /gov00WEMeSxQJaqVJVY9KHSfoCxB2qpGMs4C/6+xpOkSWoJ5MM87hUz2aF+qq0JNHv3o2og0M5Y 7WEaj14BbaE3luScaqPCidJbDdKRLBY38xRgqG03kqqi2UcMTsHPdPWoxxYeSPbmNXhje7r6OjSR m6NzPzCADZQRIaiGLjZ6ke5VDkCzVLaudYybMK9jzV/G5+yA8sQ5mlGjhslJBV7aHkjF4hG0eo5H ELD6Ls6wqu0QY8L5uj9H1Lf0qU8R+zDGmViI80RFh1QmKnOkLVKBtEfaIEmkXaIiRwIkVNgwgUaS cn7rcEnboPQOs7m4ts3vbZdobYvWSrS2La4l+D+J8uRZYTZajy6T4Olje6O7/NplAy5zU0fv48jS mqRZLVMyFi6b5Ea3VKXnF7PXuREKZW5kc3RyZWFtCmVuZG9iago5NgowCm9iago8PAovRmlsdGVy Ci9GbGF0ZURlY29kZQovTGVuZ3RoCjEwMgowClIKPj4Kc3RyZWFtCnic7L0JfJRF1j566l17706n 00u27uwbISE0SyCSNywRiEBYTdBIQEDQURYFl1HBlc0FXHGF0XEZcIYmQQyLY3Qc13FkVBx0dGQc 3OWTUUQGSfd9qrobYty++b7/vb/7uzcJz3uq6q1Ty6lTp07VWwAxIjLTcpLJdfbSi0LfDnvwbaTc S6RPn7vwnPNNH+8sRvgokfrXc35x6dxRV3wwn8i+h6hs8bw5M2f/rXboeKLqkeAZOA8J7ivToohf jnj+vPMvuuTNsj8sQXwjUfiNXyw4e6bU7/1sogsuQnzf+TMvWeh5R1lK9OBpyB9auHjOwn+N/cCL +C+IUl5Td1KmwCOUqRRSJlHsQBLR+bED/B2n0qdELCuOxE8bPUZ/ZcUsRO3sGPnoKAuwfjSGFPoG Pd1CXXQ7eWgK3cHclE9emkpjmII8ZXQDuye2NPYJnUK30AOxJ9jVsU14fzM9R0fRgr8rjAbReOSf SnPoE/kDao7dTSZaQVYaSpOYl2bSm/j9Gm24lW6j37PLY0dRq4euRnk1VEd1sadjx6mUblDWqvvM j9M62sW02Nmx+ZRNubRaKou9GXuPCqmZHqTH0KYy1qmMphw6j66j9SwgP4fQ7fRrijKb1CKPUJ9C TWNoGl1AF9Nq2kQvMTdrVPeph2K/jH1EGqVSMdo0nz5hA9g46SHFFhsWe5vOoB30AvrLfzuVM5RH 1DOitbH7Ys9QGj3BLGw3e1qtUm/quir2q9jvyIb29INExqOeWXQNPU0v0r/oS2lZbBmNpsmo+Y8s i4VYIST+phSQrpSulF+nvuhtC1q7hDZQBCOyk3bRk5DN32g/fcA8LIONZbPYOvalZJNmS6/K98jb 5DcUpvwG8s6jAsjoInqIttOf6BV6lakov5I1snPZAnYnu4/tlyLS59I3ikm5RvlW6VILo/uj38bG x74mP6XTaXQZLYNsH6R22kZ/pr30JX1FR5iLDWbz2K9YhO1nn0tmKVeaIC2U7pAekn4rj5fXyU8r A5ThynnKK8rb6vXqGn2mHj3+cPTW6G+jf4k9EfsLdMeB8gupHhK9ClrxED1Fr6P0t+hdep/rD8of yqazs1DLhWwlu439lv2R/YV9il6S+M2VhkojUesCaTHkdLV0q3Qban8Vv3ukt6V3pc+kr2VVzpUH yovkX8kRuUPeI3+ouJRCpa/ST5mgTFdiGJkq9VR1svqoull9Rj2k1WiztYXax/rV+rWmP3WVdv09 StF50Ui0HbprgiZdBkncTw9A77dhDF6CRP+MFu+nwxiFdJbDitDualbPGtg4djo7k81hV7MV7Ba2 nt3DHmC/Qw/QB0lH28ukOmmyNFOaI10rrZBulLbhd6f0ovSmtE86iJb75Dy5TO4nj5Gny2fIF6AP F8lXytdCsuvkTfKr8uvyR/LH8kGMmk/JVpYolyl3KY8o25S/qKep5+P3AfUptVP9i3pcPa5JWrqW qVVo52qPau/rmj5Qb9RX6W/oX5kWskxWipaHqNuPFMAczJY2SR5lGTuIhCymkBM9L8M4TMas+Ipq 5SjGxcHfo21pUkBJ5ZyaoUTAfxHbRQPYH2mZJsmwisp+amPvSPuVP0in0F7WygLKI/IF6ktSDm2G NVor7ZZ2seG0TaqRpkn3ysQ+YI/SB9D3S+g2dh67kDazg2wIu4INYsvoDckrT2bXUk3sAUlhZjaG HSK0gK5SZtNZ9JM/rJreoU+i9yt25XLYpw66AyP6GL3HfkPHmBr7HNZNhjWaCStzA/T9OuJWrwXz bBnmYwAW5Bfaq7SNabDig7RhymV0iP5Nn6g7oVHDYUk/is5X7lf+GRsUK8cMwyyjRzHv5tGpmDEf QEueRJzHzsRMt8CWVGFWN9J0mk1XwOqti0Vi98auiV0aW0Avg/cY68OOsY2YER3gqKEX8HszvcXW YB6e+tP9/LGf6GzqpE+ZnxWwKsyHg+pSda26Sd2m/l59ResHaV9L90Cj34c2W9CDs+kv9Cl9w0wY mwD1oTDaOxhtb6JfSM3ykzSCpdNCzNli2PHhiZ5ciFKuhvTuxXx+EnPjEOzEmfR72sck5kOPzkb9 JpTTADnPQO6HMYLXsHakzIbVLqXP0G8HGyxdhPoMlHQHrFYn2vQOfQhpx0S7+sAujGTTUNY3dDrN Rg0DqZFtxQhsp2pY1pHynyDvfOai4SyX/Rp8rZihDsqiavWfTKI+0fGxwdJ8+UmsMTGkb8TqlUGn sEVohRP96KI0NoEGRCehDa8zWYmw10Qr7pLmxFbIF0d/QS/TbzAmhrJUx2pt1E0xaoedUjN0SPXg QQPC/av6VVb0Le9TVlpSXFRYkJ+XmxMKZmdlZqQH/D5vmifVneJyOuw2q8Vs0jVVkSVGfUbl1beG IoWtEaUwb/Toch7Pm4mEmd0SWiMhJNV/N08k1Cqyhb6b00DOuT1yGvGcxomczBWqoZryPqFReaHI KyPzQh1s+sQmhG8cmdccihwU4XEivFaE7Qjn5IAhNMo/b2QowlpDoyL1S+etHtU6EsVttVpG5I2Y YynvQ1stVgStCEV8eQu3Mt8wJgKSb9SQrRKZ7GhUJD1v5KhIIG8kb0FELhg1c3akcWLTqJEZOTnN 5X0ibMTZebMilDc84iwTWWiEqCaijYjooprQfN4bWhPa2qdz9Q0dLprVWmabnTd75plNEXlmM68j pQz1joz4LjvgPxlF4e4RTSu6v82QV4/yzw/x6OrVK0KRzolN3d/m8GdzM8oAr1RQ37q6HlXfACE2 TA6hNum65qYIuw5VhnhPeK/i/ZuTN4qntJ4bipjzhufNW31uK4YmfXWEJl2a05aebuyI7af0UaHV U5ryciK1GXnNM0dmbvXQ6kmXtgeMUOC7b8r7bHWlxAW71eFMBGz27oE5J96JkMjOQw2TTkiW8Rbl jYFCREJnh9CSpjz0aTB/zBlMq88ejGz4aWbgiszGiMyPmEe0rnYN4emcP6IWuPJCq78maEDewc+/ mzIzkaIVuL4mHuR6ckLV8D4ZjpSVRUpLuYroIzCmaOMwER9Q3mdphzQwb6ErBALxUSNkO7N5SAXE n5PDB3hNh0GzEIksn9gUj4doVkYbGRVlzRGplb/pTL5Jm8rfLE++OcHemgdN3kbcaU+LmApP/HG6 vKmj5g2JMO9PvJ4Tf98wOa9h4vSm0KjVrQnZNkz5Tiz+fvCJd4lQJHVEk5whJUJShizeQinPPJGZ R5psEaUAfzSh1LMjMpRSJLBQfcTVOjr+bLbk5PwoT4du6sbUETvEuQQ5yZZoZWRI2XfjQ78T/07r bKtltFcplBqmTF+92vKdd/UwQKtX1+eF6le3rp7ZEVs+Ky/kylu9Q3pEemT1wlGtyQHtiO1ckxGp v6EZnZjHhkBZJRq+NY+tnLjVYCsnT2/a4cJOZuWUpjaJSSNahzdvzce7ph1wVQyRKp1I5bEQj1ED g6K3SSbxKmOHQbRcvFVEgoif3cFIpJmSaYzO7pDiaS6Rhp9yuDF88FX8wivQafg2iUU1vUOqNVJJ VaIyWXQlyihg0tSoJO9mhWSGM+wnf5nrSE1XzXjX4ZpxXTVUi7DrOB79KnNSclIK8GBwMI6H5M7j hkrfUkjpRF10Lvyk69UXsRIF6RqjVHM5UsOqy+UOD/EPCRjq1LS56Zt1zexNJSMQDDuRS6Lp2YMz nR3SrW2uu20d0kVGbirLtGSyIKEx5DLnuLwhr+RNz3HmuFzMFQg9NMJfhna1jDs43nUET3d1xUFX jQuNrO06fMDV9WFLmbu6ul8ltZSVsbzCAeGBAwcNHBAuzMvV9IKB+f2rlDSPpmuajI5IX8TYpCP+ gmsWnLc2Ixq1sowPv2TZ8x9rLuuCr3TZINvlG18I9hs6acllV4Taj3U92vLwzWOnR90sEP0ILeeS fQq7Tp0srG4H6bF9hnlQdVgrxkPviHUa5uIBYc3AA7F9RmNOEd7hUUKlSqlabKmwDaZBaq3tXDpX miPPVeeZzrF8LDvHakwymZlsMZsV3czgRukeeGuaWVFCquZRVc1kMdKzhll4Fdb0rLClQJJlTTF3 sN2GQ9MlVcG21GTz+dKpQ5ppWINMbJaWM5l1SPmGOWhmleblZsm8U8onBTnMIZWpAetZZyck2xU4 0rLocMsif9f4UXNGfojhh3xra8YdTIGwa7rKympWqH3LVlzx7Iq+fk50V03Nimef3apJI6Y0bTOH zfYwlTX3q2QNEevkhkg2JuIOkmPRNpNi2RmLQlLHt2rKYP7TzBZhnPhPTo6MX5aTKsvqU9HfL+/a fmn0OWkoqy596Tk2Ltqu7jy+Wgp17YcLTDNjH6lnqa9jZ/emMf568yrPKu8GWq89b35DfsP6tWwu MBfbiu0lnhLvEnWJ+XrVpKfqPl+qz1cilcoFql6s3qXeaX5R/qNVrWUT4NZNchHbDydLIgi1PcUf FtSCfsCfMHz+csXkMBzusKNhhpNNcDKnkeYPOztYsZHrLrfIzi8c0+gLEkWlV2ayzLSijTpz6kG9 Upcx3W5oz7hycly4i7jetnDFPXyQoLFlLYsOlHHKAy1cbVlLSwtTNSUvRCkuygn5vD61kKtvisvb v2qgUsuCw6OvfB59J7qSXcbCzP7o7Kro39IfWvrgyy9sXLpJyjjj0CfsZuw6L2C3bzgrUr/42k+j x6Kffn4Hl9ztmKGHoLNWWmucYlIV3VSguYMqq1S3qJKqmmWlAJbKYi6wEjy7BlkabSErs6aH7JV2 wy7bFXMIClnJBSWtabf1S/SKWwnRrZpxh2sOxw0GR0p1RcsiGPQdpMY627KqVZjStnRBtqZWY9Sb kUlWoT/9Kvun5KTlJHC7Unv8E2l/V0jur+48Gt31TXTRN2j9LIz7kxj3EO0z6gdnN2RP05ealtqu M11ru853bYZZ82kZbp87ozil2F+cXpxtGm09Q5linm49V/mlcpn/ovTtju2u5+3Puf7q+sjlkDO1 EB9nI5heDXND6DnzZpZrZjcfanfDhFSWysc5lY9zqbfciV0dCwVmILnIPU0KhkKylB7KrcyVcgNF Gy3MaQlaKi2yhY93zpUbvjPeXECuwwcXiRkUH3cM+8EUPp8WldUgOTH0bEBOCsY+N18aEHYPGtg/ pCRGP83lxugPGiDXSle2RDc8/mF002OdO258jaWw/n2ibwc3L3/mg493t+waIWV809UxfdXT7JzX P2CzZ4z54KVBv7jiyJfRb6PfjgnvRD/Xw27lQQfM7M+GwyxrpoDsMyluE6xIR4za3dZamWv/GS1h To3SyVPCcpVu8ui6STZJki6bFUkyI6IYyKMYeK9Uaa/ChkAnjIBhbbS2WuWF1uVWaaO10yqFrJVW yWoyJwrl1HBMnhw2VwlV6sTSxJXJ0m/JCWWCiRnnamlZtPhIIgaNqq1hEFM1ASv6cosByxM3Ody4 7DfMjqKwKYQHb/UTsEEmQxgirmX9KkeIXMu3WweYllsHiI6dkt43bJqMhyp75SrZkJV6+TrTWtNG U5vpgKw9K79qetskh+QKU1geappgukXeYNoobzFF5KdM1riB7z8gLBn9hYHfb9grqsJSiD90zwCk 3GmYc/qGpSl4iNz12SHE8DBJuu6XZJ/eRyrSh0r99fGSoZ8pTdPNHilDHyeN0u/WN+svS29JH0sf 6f+WrEVSsT5Wv0RfqT8maQxiWVyW/CEuJdFHasEMYil8bU5Zz0JSE0uN/rVrK+xmufz6sXp59/GR fI3mFuAoRt+JVfpio0BTd3h2+OVTVXaO+qYquVMK7A4HZbi4GXCSyVu0RWe89e1ma5hbMsMbzKrM as1amLU8S81yObubg8zu5mCca9GRMmi/GLmuGrFy1HAlX8R4Q2HWsJHUsBLn5QUkaDZfo4sK825n f2OOSVdumnXn+HNffPqBLUtHnDV6wEZ1pzfn3S0rOuanpHX9VXkm2tp3Vl3jPLsFFcOsqbvRnzTK oaPG1dXOMc7T9XOt59o2mR9xbMzb7thntmgmzeIzeS0DHfWOeqducplTPA6P0+Ma6BjoPNW5xHGp 63WL9RLzJYGlWSvNKwPXZ8FJ8ZhtTsdkxxLHtY7bHA86VEfIbvPY7TanLc3u8xakujys1bPRI3k8 FMrh4oLg0sjk4MtwEdlddsn+RkbRRi2idWp7NEVbsTCPhfIq86S8nLTuUsvtd/ZJqblaFh1pOXi4 5WBy0RWSa1kEKrQfmt/iuML1LEuppqTRWNTCBVol5Kl7vb7UHLmvlJeXknJSqnl3SAs+27v8madb rzi3PXr/m4unnDW35m97z62ZMDp/20fqzgkvXf3QXzMHX785+j6r3dyc03WvPD6/afjYM2wqXzXG xj5UvoTd7cP2GKfsSOnI2l78XB8Fi2oaFtU0f9kcdU7xRdol9ouK37K9mWdrtkx1TM1tzptnm+s+ J2d+8Tl9Ls66PuuOHJs7D/OkPTsY5tSYE0gPT8ydmPd07tN5yqLcRXlX5V6V94/cf+RpZZZSe35u fl61PZzXYGmwj8wdkXeufU7epfbLclfZV+c+bHnE/mhuqtlitmu5Wl7AErB7c/XcPItdYb5pfiMQ Ci/wswX+DX7Jv1OaQxmYfTYY+QyWUe6RaTTj03FMeihcyQzWiK3dWrYRfm8nM7H/Uoz0apfClPJS s/+LmI/5jFRf2NegFxWm9w0WbXRFXJKrgX2REh/AQPlrCZ1vmNy0lYzBzeP46ME1BS1bzJf4RWWH W8oOxOnisgNuX3V8yoplMRfyyMgaBnnsSdB/tqVW50I8IIi92ObmsT2G011tD7mrLQJOnvax4bAh zV5t8XOI5fTkT3PcNBppQyxD7ANyB0COY+wjcuvzHrb8JtdCLc2JqZha4OVehVAT/sv95ROLjq6l eXxeRWgW90fGslD6hhU3rzvltPCO/2pdseyL3zAP8+nRfalXXHHVmIo+g1nk1SU3xOip6KfRN9m7 metWXjoxPCbD3XfotEt/t/APc798yb7o7AG51eGCirnnP7nmynfOY4zrVx/YpB3Ck15s5FWYK5VK tdG8ED7qWrOuMVUqUGRJJ5MZLq2yjK8zrNywaDq8WlrGZxGiKbKjUVooLZfWYp8UMHU9lhiViU1b JYwK/JIWzCE84NEeSNgk7nWwFhjMAdzrYO9Fxyk3Rscrzxw9+u0wFDsm9rHSVxlGeVTFFhnz9HRT pprlTR+bMTpzTMHfXO+lmAcG6gOnF84NnFN4feEtgVvTH07fkfF8+gsZNk2zp3m1gLdIK0lrDlws XS89rD2uPafZngq/5ZKy8qv6pfSx5xtlfcP5Rm4xHoGs8IL84/lSfn0W181KhzN8ShajLFdWJOvf WUpWVh/WnwykxjdNU3OMzJTaHCPDhYc/PZyDndPjim6zW/pwW413guK1oMjRh++tDI81u1+hqcRc bG8O2jbYpKCNxWzMZji8YVv6hDALt2I0bqpkjPUvyZnhY+/52ATfDN8Cn+wL9J9fl3BpFkO3Fx1s 4X5NWTx2gG8SD0LtIFgs10Ljhd0qi6thW0UWW9R8MLlc52OBzsgKT8mfnS+1lDXzHQCMmexwxYdk UQtXzSIoIjdqssfry+G6qWl5uYn93KD4ho7x9SPNAwUexDd5bE6s7LVXd3c0yBkF0U+tLl0e/euW Xz857Z5b/nha44KGKeysgZ/mD2oaedqo/i6r9H7fu29rXvVEtOOG607LHBQw1de3rZx+Y0NmQShz 4qih0dfcVf6imqHTqgoH5c+BVKZCG2qhDQH6hzGxydnsbvbOc853z/de4b80cKd0p+0513P+v7re 9H+ifWL6JPWTtKNa6uDUwWlj3WO99f5m23ybPsQ9yDvIL1+sXuxcoV7vXBV41P2Id4d7u9fsEKOU Eeb0cbcn7Ohv5ymB7LCgzpSwfSdTyIIxdKdYyUBWMpCP+q/FWO3ELFLwKuTTGU9lOVRh5wF7zgQH c6Rn6DmeQHpTfPiS++aywwfLuCMKPzS+/wCN24RF2H7EXU4u2YGDVC54vhfBcCj9op85zp4w/4pl 5zXOTWOessOvfBL9jHkPPvOB9HnV5CnrNj157xkLKn7/DCtkCtNZwSPc56iD7IogOw9lsgd3kCt2 1Ki3Vt9lvtt+h+tR9RHLLvMue0e6yeRho6VTtXrLhOxH7du17enPW16wvWnZZzuqf2O3Zzoz0wxo TZrhSAk7055KezVNThPSya4V1OEDlW40sGy7Gx2tDsnhd3NLvz2QEWb93WJLlxWKb+1yS+K0rDxO /ZmCGk5MsY38xMyFZs9wuzFr2hWr289nT75VpxxWkRYXakX2jOwF2RuylWxnjsmwO8OmQFZihpR9 Z493EIbe8PiNYk+t38h24oFp6efzV9jp2i6xELjRCORw88YgkzsxfTltS2bF1BO2XTAQXrireaPb fJxE2s2WYSJal1Nbxt3e5gN8VrWI6h0GpOTglTp49djM+mrjrrHY0GM5gn/Rn5vDRdRSxviQh7AY 8DEnOUcsEanxFcEnHWP+gZ9siX523Xzmef0gc2tdhnz1zOHTi+RLpp1ZU8PYpIq7f/X4unexmpZF n48+ecWa0ewXly0bMeJCbuv9UIgP4Ut4qcPAbpaVKiFXKKVZWe5XTcpTfinNmyJ53N4UR6qTXI5U Ri7JYzY5rWyGNYZtBB8Ii8ZSnF4W8zIvj2a7UO4hFK2leizm/rVw1RuxUyl2VaTMSJFSOphi2B2p hZJnBm30dnolL9cJsy3sDfgu2SHNp/iYLaoZx0+4jrdgkQgcID8sGXe7gFo8qquc+EnYptT+YpWs 8ulilqT1T8uD253nv7f6riWXXFg4YtgpA157LfrRvUph4/XXTs5/1lU9seHd40/IY/hcmBKdqLSK VaWCjTdmXZy1Ikty2+wL+11vX95PCTH4h3Il6y/1lw02Qhohn+Fs9jQXTCuZhqE6z3k05Wiqe6i9 v3docf8+cIy8DcUj+xyydfksN8GOW212a6nNXuTw+tLK7TYs3f58PgMeFzNAKLojRShJu9UWp8Wl 8QmQVxCn/cLxiWBOyxCLwQxs6i5qCzqLOHFYyrnArWm6P6CVllgL0/0drMQwBwLp6Tf3Y/1YB+sw LNQ/P8cdqGyqSdibw5gNi7ADdh10dYml9yB+uw4n9jDJNYFE40TlbRgcob5weX3Cz63mgN/ONxAw Ty2LRjQZ9vnO+Z75BeeUzC2bX6G1YP/jU72+5FowADYrocA+bKk9DikvhMUj1ZPwdjBwl7I6U1bx tAsGFaTar+x884pZjD31x+VMH7Zw183RL98/fk3rOTetnDfnmvqiwWnZOd5+eWfd89jjN+9lVpb+ 29uPn7p757k1O25ySNf85r5f3f/QxvsgrFvgxzTDj/FSm1HmZEFWzQfSNZwNT/k7+zcz66pXzZea UualqIxJqZ4Ud6rskZiTCzVL1s0WiyfN4iWyWgpNZiOUH95iZjEzM0PMGBJvbn54rX+jX1roP+SX vvAzP3kKvWnCbCHvxjR2KI2lBXy1ccHDx0wcyyB0JBETng/fWByETH1iyTUJLwj7iBSodLaUBlUO C/Ov8SDbvPLJmfdOyIp+FJp4Sv0F/aPYLXR9sGH0wpU3d62T+j0yfcDIVdd3fY5OQ7dvxUR8DEF+ 1nzxDjKjZbUpllrD3GiWlpsj5k7zHvMXZjVobjUvM29EgiprOqmK7CRm0B7aD84WCRNZ1XTFIulY Q4Qu5uSHlYAp0a+T/agV01McH7kSjsPislTeaOBWfkrLAsp2pkSPfztWKfz2bYzQKozQDHH+9RU/ D3i33Z4iTjuMKwLlYV12yalakXmutsXylOUF88uWty2WyXKrLNl1v7leO920VFO3m99TDirHla81 dbw+3jRXu0K5QblHuVe9W7tbv9tkCSpurUwpU0u1Ur3UVGFvUBpUC/wUbFZMFtViljXFqioaP5i3 Wk26RbZYrEqHdL6RrlaYqoPYbc+xS9ZCtpz4GTgFbLW/TLhdvN8B15FFfsyo+Il3fItYW4NZssKE XaGp5uSByAtt5pzEMWwLNhy0GF5Wfy6bHIY/esoqFmBj2PTo7ey66F+iX1+j7jx+hC2NXt51Fnt3 VfQxVH1yNCeL8zujhI+l2qhKy9WI2qnuUb9Q1aDaqi5TNyJBRZdkuChyIaPkqFFA+d6oJcapf3yM 1J3H6lHXlUTaeljFIjZ0B5WAuwV1YRWypWleW1gOm8L+cN5IaZRplH9kni0kV5RMNreWLC/ZUPJr 7RH9Ydvj2uO2SMmekv0lDiqpKGnEi6dK3ivRSoz0zHAt4svFS1XPUfT0LL5stFn0HLF6KLorJaUo IzOzsMgC1XO6Ct0pxvQBrSlsARSpQ6o3nOkZhVmZSFuQyVozWSbSthUUFhbB3JW0ERUJJ8Rcy6kx EO0uQtYiow6oAfKLwkXGkFPCFUWvFr1XJDuLgkXLi2QqChVVFsWKlKJA8T9rko51YvMWt5U1R7De Y0k6sqiFk+TUdYnpW3uQnwfEzwDY4jK+LLGy1Jw07jP7hOfs84qpXHRiKp+c1VcyeU3n3Dsq6x84 c8kDxZjbWUUTh87rG/0ou3Zg3bzy6EdK4brfTJk6dcqMM0eu72qWZtzft2b0mjuiklR/z/Q+9dfe 1XUcY7aOWzuMmZc2GH491Zc63TTPpHQoDKPlGmka6fzEpWrCtKXoDrtms1oZ1IMVekmYNmIxFPJj ps1iLbQ5uHztdtsJC2djh7DKfdfCCUl9z8jFJ8bBxPlIzndMmhASDJ3SHP0of2L1mIvKYCjUNa+3 3D0hKGU/Nmdw47Vt0aBSeO+2EfOu/SW3a5Pgv96Nntrh/d9pjP6YfWT6JvWbNOV56WNVcgfUgFlq dk1LneZt9t8prdfWm+60dZj3Sn9T3zHvtX2kfqR9bHc9YnpZ+pP2B9NzNnWJaZV2rUlOEVpo9XER eRTdU62nt2YszJAyHDn0HXd90RF+jHZQdCe5+pnnu+a653rn+xXGlz5s5MNudIvSPJSXm19Y0G2d m7S6695/sXD0xc9viX6zmoXuuOCC22+/4II7pNwbmLY6+vwX/4r+4drYo/c/+ujGex99lPd3TfQX yp3or4sy6W6j7+DU0amSOyxX26tTwxkj5TH2MakjM/6dYZ6mTbM0u6d5p/mbM4/o/84wYf6k816p uof3ymu1upwOX44pfWE2y04pcTichS4XnzaGdSEt5+cnWbXxfi4ad7AGA+k6kOxu3E1Irk18vZ+r zbXMR5/n+udnivWeqzvvM7Ym2BkWpeSwbr1ew7T+vzt3B5Oix3c03TwBQ+y9ae6sq68/+5yVGNrG 2dG/R7uiR6Jv1U/t+kTe0b75vvZHHtiAFp2Bvs9C31Moi+4zBrlrpLA97KnJHCuNtI/0jM00LQyy LFOaL9ysNltOt09LbfY1p0/LetjycOZR8xH7Nx5bCjkyuBAUaxoXQqpVd7o0f44pkO0uwU6tMCXF Kbymm13MlR6Mu0lHuvX/cI/uly1KCGC+Ot8yN3W+b35gbhYEwFI04eTEd2bcy2Hhk9s2ecygX894 fMlqJneee08Nk6OHrps9d9W1M2feEv2F5D118soNzMWwxkw/475j9fK2Bzc8ENlyz++4h76CSB4k Rv9Ro/hOlZkdbLI6V12iyhXuJsc8x0K3YjE7bUGbdLMtZpNqbRNskq1Dutgo0XXMcFnSLMVkdpkr zQvNijl9mXuDW5rhXube4t7jVtwuKmSy0ABJWs42MokFUmp3sMy4G76o24Q+0hIYF3fEIQzM7+qq uDIsooaIb3JDZMDE6U1bLVWDoQk5YlafcMm1FLaRz+kR541sbT791FOGTqpQCu88b+SAr/vWbYr+ C32sxIx2oY+l0jNGp5ai5ZmKfCm+vPXu9Z47i24vNeueeo/k3mXf4Xg+54O8o/YjuVqJfap9jv12 653uR3J32PS6PCN/ZOE5ubMLV7hXeK7PvSbfPKhwlFZvHWuf4KzPGZ6r5+YXFQ6yDcjhp28D8nXN oqaYc/z2Iltubm6enp9r9LnQdonn0rSlJUtKV6ZdW3p32u2l23K35dmXs5t9N/jvKv1NaaSP5svx Gjl5Ya+RGQwHvew9bHr6m3IaC24ukAoMf1a4IJ0f8Rg+rDuNfVhlH1bRh/XJzqmEcvVnOZRYm+Lf NS218ZWZfxcJlF3SwUV+HOuNOM9J2FB+Zs8ta9lBShwhDtAY05iXFeYOzKnPmcKafbPZfN8RZmE+ SUnPyZWKU+02qTh9hsKU+mJrYzpLr0/VsWvCH+7AJ9GyKIMfeL7M9xw5HXGaKw6E83l8f3swPx4P pIu4kYHAeXY2MLc+d739ttxnc9/I1XJybXZFSafErob68/1Nu6+8liW2wCKeWxAWZ7xZWP2JxU95 lVa2nB1iMkHv+ZmvInKmepGTMWMcKWyGckiReBe8Bor29vcZKNdnoFCfMWBQ2MfP63xGQQkeKNfp C4qjMcU3Nd3A+uVMZ43psXQp0Xlx7Ct++PfdlkX8S+/ieDQujMQ5bXxPuQg/LS1iY58fe9EwW921 zmI8IIfPt9urbR5bNQ+22fjJ76dbrdVi8874Z59FiTNcfsuhqLAoX5zhcoPQ/QiX39rjx2eVLN19 wdnnDyrwpI2JPnbGlW9/8PYbxdFvUmY0LagMZRayp5ubDn/xVherKJs0tTizIpTmSWkYNu2u1btv WtNv2PCgNy87LXPu2Ibrb3ktglkUjH0srVPvw6r4ilESImxeLSXOIY6xjmanHkgjv+xNI5871cN8 bsnD/LJZt+g2Pxe3k3wbfRGf3ArS6ZN92KS3pTG+aLRTGr+hcpHhsFnNFZYKwj55BqwE38YX++VC n3tqWq1ng2eLR271LPes9ezxHPKo5HF5Qp5Kj+IJpF+yMelONUQGwU4MFfcPPLFOfgx8PH4K7Dos 9vgHxc0WZD0ARyqlf2KP38KwofcImfq40PixeEregP4DClKkyzqtRZlFY/2zLj/tsmqr+aqrWLpS uD865eqyzIy3S/tPHNXvdvbq/td/HV0F+dwIKzNZKYSHdK/hOz3lnJQ7VNmsBbQaqSalQWpI+UjS xd4vRbF6yZLm8VjMWqqnMC2NuIF0eIWfFD/o+Ak/yWw64SCZ2CETM/34FjC+yPTwj1pyBoijVXQy J97tgQN5UB4/5Mn55206jQWCk2pHLy5lgQ1TZ5216Q5pY9S/f87QCUsOsE5sqtBPKzzB6einlWUY aWpxekVY5w+NP0z8gS3WvnZQsZ0LpQ8J360wTbaaTBabFXtWyS2nm9MtuVRufd5qw9w+ZHizQmEL qVYPBawFVGoN0xDrCjIn7phYmN0myrKafWGFkZlpZKHaWv4hvUx8KMsw3FayKFaL2SxJTEPYXM3P Ug1/ZnHYag+K+wyK3edLd1lqLRPEZ/tKw6pI1ValVpmgyMpOqRIu6nLDaRtALAQTIrOA7VnoVoAr V5l/3MEWrFQtAXFHRsSFh87dc3c1QxPE1C5r4edp8RsuLCfVxw+vU7EFeyI6hRW9MMSnOVwvsZwo pNf1/uOjvOXlUnZcpmbsiAZDpjapyOgHyVpIkyy6as4gr5StpKjpusecbUmx2dxlcpmWZ62Wq7XR 8mhtvbxeE+fJxiV9ToUIrYqiKmarRbFlULriVT3mgCXNZsujYqVILTcXW4ps/WiQOsxcT6dKp6qj 9THmi+kS5WL1EvMllottK2ilskJdaV5pWWF7i95S9qp7zW9Z9to+pU+VA+oB86eWA7Z/07+VI+pR /Yj535YjtnK1I/a6Yc4YElYK8TB3xN4WMQuP2ZLviMc0ccg9JP7FHtRq4JEYYhPDnkF8eM6J30NI Q8Bq8JhVgxHXoUFmPuh8V8QtKreHYuS3PWNV1FBHbFy7ZjGDnmZUyWQLgUu2kcQUm6xarLrZpJl0 XVUVheuHzQJFIUuFo9YhOaAUpjozc1AIMj+frIBBMnNsC7GA/dkdLD3uq6QHxnWl+7u60gNd/rgS UHz4axO7NFf8my0/vhJPShGt5J/e4sZb2HCsBMQt/zarYa9Gj4+22avR4aMw+1bDxlMOwezLcaLx L4NWHtufXATEKsL9Iq5fqfwPy5Fl1hyNsJTnn2DOrS+ztOjm6JdPbIOOjZY6OL59W9rcNRVaZsPM bRUzd72xplh/QZHW6zvYO2yvfsiumvR0xa8Va4NosGk0a2aXsyW6pZCV6QPZEL2ejdXXW49qR3Vz gVKol1rCyhDLCGW85Q+K6TTLFKXZMls533IJu8Jym3KHvtOyV3nHctxilxVdN1u8SkgptfRXai31 ijlNCViGWMZbzrM8ojyhvGg5oph19Lbd7ef2Yl87fG2FuwNptpQwUyy6wgcRxERmE7+ysn97SXk4 JjMeNJze/LBcKJk9kmRWNas18fqQlfGg4cNrayGpHiJVU1X4qiaz2Upqh3R+m9bfzM9hrKY5E+wb 7Pvtsl3myVJ/K092H4p/FuDffRWac9ISLPLzI87AOFfLERGiirh1xYNfkytblLwpFw8lzzR91XFF f9wSgk7zDsYPbJLq0bJo0WLGH/2ZGFfGR9XGlkXXsdN3P8fGRtezVdFH9r0t5Uly9B2WHzV3/YWN iT7BbYcjOlGZhFFNZeFt7mKVpfKu+23OsMlrd4Z1/tD4Q/UiTYpfgRoSVjVNsVsdmkuiVE1JlRRo ET9Ub4Ur2cG2wKA67RWOYgqlVaa1psn8sFH4WoVhcQbpzswOp/EvtNWy4Q+El/EBYUWGWRIxiUk8 5mbVZGQODCe+nnueTazVZeO6Anhyuxq/dAhpLR7nOnwA+96WiviEgk2N33oQE0p3iNPgxDRqaYi4 sNQPwVLfprhoZwyjFTu0VXYxccswcQXtY8NhT6lNdaUG8HD7a1WuZohw2oZ4vKzm+CTSHTJ2V0Xi E5iDlUWPsrzoqhEFI05f1jhxfGD4gFlnBTChHNKXx6UdLbNOyU15x35hs/grOvxiqHTzX2j+1TOc NV+bAibxN1ce+GeN+BuJz1W2rTt27HiXi0xpws4zwSH49GHR8TTCRceOHbvMRYn0Ez/2AVoiSapO YBN1yC/TQuVCcgP1ehY1q8/TdPYRnYl35wEj5CzKVB6jqci/BPELQW+VqmNdyD8NeADoD4wDCoEz gNMTmAzUgedFYBPKmMHLEfSfdK7+Cp2Cugi4A5gJ3KZOo9vx7k6tmmbxdNR1A8rIQ/gupN+nbaJ1 CK/H+2aeV1DOP43G4n0fhG9Vp8Vi+o2kI40Q7kK6F/XfwtsMWoj6L1QujB1EuBRlj8H7FaBTQack 2usX4X9yHtFX3sdVPAz5XIn0dcAkYA1wBuTD+SvBF0T8RoStaJcZ1AY4FKJc5KmRTqEIaDnqH5Ho N4l+ox8n+oT2izb9MKby9nUH2sT79QnwCrCnW9t64sbv4EIaKfcX48f7bAeGSq/QcMglyvulfhD7 hgOatw/92gWoymzqZ6LYJrSzVt1G6xGvAmoELiSm3EsL5MMYg210mXYH/QrpJPUDjlCB9DmlawU0 CPJrQvmnA3NQ5h+EPszmbYh9DhpUPoCPcSG1Auei7heTcuKyQXw0xrUJeY/zGQG5XgvMhwzWA4t5 +1B/BZc5xv0bNi36G+Tdj3oaOFBnUAB9j48rLQH/IpTFRD3xcYhTAO/PhUx/BzwFPM3bkITQswRE WZtIljbFvgJNBdKBV4B1XN+AVqCa50H9FuS3CH2FznDd5PrBdUN9XujqZN72eB/EXFiTmDPng/8M IAAUa4/RmQkUIy+Xzyyus3y+JMvmusV1JkmFTp8n9P4F3k+uU93obWonTeRtEPVCt5KUzzuUeymn cppo093yXlrLdZbrW5JyuXBd4/ORz4kEbezW1z6JOdIH/NlC16GLSZqUxQn6Kt2NMqdp66Cnn9F4 5W0aL/+JxquXgt6C/u1AGvqj7IUNK6MJpk4qwVhOAO9dPeh6Dn0vOxd13axshiz20n1CrnulXGUv U9XNsU9UYi+qm6UrRfh7tCdYZ/wdpxzd3/2n6f8TSG+qm2kuwp+qe2Mx9OcWPif0z1glEEpSpLcB y4FSUxlbbzqPdehTyaURHQYWKAYNUQ0apHRSrZJGBuRUgPSp2qnC7q5F+c+zz+hGjNf1ehrlyZ/A NqIu6U2sDwAvH3RcNz36js711KUkTeprT8p1httdUBU0gHm3E9gFvJ3AP4D3oY+jgVP52sDts1gf YKOBG+P6Gjt4Qj9fpHtBb0rqZw89Le2hn3pPvexJ+drC7btYWzBP0Y4bk/3n9pHbOG4juZ3ja18y f0/ajf922I6/Cjv8Ck1PzOsSoBKoQBm7E3ZkF1zUw5ijH2uvx3bptbFd8kuxXdpdsYf182IvaNti 96LfJSfW1M64LePzKbmWcjnxdTG5jqqFNDdhz+4WeVG/WEenCTtA2qWYf+fSLJT7J76u8nko34t5 B3mivKuVR+kXyvu0Fm13ylvi6cpkGs9torIUYaTDpvP3VnmteD9J+YqWKiUIPwp6D6VoOi3VnuE8 sVdE2j/j73iaOp3uhN5VKKvo1+pWauJjxfshDYi9xMcecz7dtJzu0wk6/D7drRxDnzvRx+cFvUfo E+dtjx3j/dOHkk+V0T+eB+A86n0USsjjDiGLTiGj24UOQxa8TO0N4W+Qug/5N9AVJgvdbSqCffqa 0nXYElHXVjrdZAi5K2K9/hfmx2fQsam0UvXE/i30/7FYTD6GOfQZ5hcHw7s0Cqif0T2YSyuFfOJ0 DZ8/8meUxnUE/Zsi/InPoOMP0WJtM92gdULv9mIt2Itx+wx9OY8GI7xO2Rz7FnlHoQzidSN9ovBP +DplxPbw+aJ3kl83UD/y8DYI/w/1yh+gvbfSStiSOtNn9KDG/WzilywpG+gXh4gvA64EbohDpLni FDuNW+kKni7NoRfQCokoxvhcUH6DuXcP1cmPkEWZC//hU7paqqAV8njo3UGsGTJdweNKHyqWD1KD fFSsPytUCw0S+bxYxz+mRqUZ/J00W2mj2XIMYT9wO/QRfGoHTVfPhp91FspJQBoIHjM1amsQrog9 xvOJOo7GvBzKpVQl+LpBtDUJ3uYHurX5dvTqKugDby+/Ed+tvbytJ9qZaOMPtU/0k5cLPpHnb1QH Ob0DFMRpdKJ0I20GNkpvww/vpCvZHbGdkGt9D4zuHleuZCuBRkBRrqT7QctBPwX2AvcCu4H/UgbQ dSj7adB2vi/gkH4P2wWK9w8BTwJ/T77rDl7PD6V3h/JhbGf3uFpF1RxSH9j0Pt99J/LfT2HlEtjh ythODnkpWTg0B5XoJiqR3kf6NPD1iKvFdKeyAHknkfxzbfop4KeymxyN7n1Mjgeo97+Bd7rREKeY X+V8ff7ftO9/AozvMuAcIf+N1Ffo0MfwyfXYH9huOovtjx2DPdc44nFKF/K8n1KS44T0lSK9x/hB VwZymfdMR7iGIxnvOa4/F0e587sjqQdJ6FVkcCh/R36gZxzrgcGhcR3r8/34iXp/DFMoDDnVK1PQ lve/H9dcVMEhLUR8Pd5/SEUcJ+JTqISD5+WAbPM4IOudHNL7lMMhT8K7SSL/MI5ucm3icpU7Oa/g F+OT1POe4wNeUp6FPToAn3kKpfek3edsz3nbMy1pS34oT4+5UfljZf5/CZg7LwHPA8/931oP9JwR dBVwEXy61+FvROCrPog95st0I1HXSqJvnyY6PgN2CGvw8d8ibSrChaD/AvxImw+K1ejb/QgvxLs3 gFeAjUoGXZLwKwOIj4rzdj2cKK8gzs/5jsHb+XZgnP/bFcA9CP8ZgJZ9+wfQ20C/Rv4I+JpB4QMc vxo0jHgjAH04/hfEhwFY948PAT4B0M7jcGOOV4D/fmAp90d+YB/6f5b+yP7jv0vjZwDUInxOtLfn HuK/TZPj+TO0514jOf4/R5N7ie/RhBzg873E0W3v85N7nCTFeP47gcPAF8qqWBd8Sl340fBlhc/N /ccEFf72XuFPssSZoqDcd+b+K/eduf8Keq/Y572K9lxIp/F9vmhXch3pZlulPjQH8CYAu0cjkOc1 tOcQbI8T6+vX8C3XciQOOs+KI/Yy1i4nbO5TbHfsa9BXEM/CWmZOrmlJ2/o9G/v9Ne3/1vh/ukb+ D9bUCQnM74Fk+twEer6vSCCXo+da/J/i59bu//Fa/iNrdPd1+n8bT67zSZiHURWHbqDdxvf90p5+ wM/Ff87P/U/jPf2ObvGtHD/xXsR7+iXJeE987/33dS/uz6RjviXRY979p8A8Ha4siL2VnK/JNvSc xyfmWyKuLaORwKgkZY9SMexICXBDYt+VhzDWwNhlfH0zHacq02+pCvHHxb+tJWxOrDm+9sVuYNvg S38j/l2x6xDXlVdE3qYEmn9On3vqLffPhX8ImYm2r8VYHKYKYCjgBrYC558Y6wp+2y76goyVl+9z 5QOxr1HW1z/mC/4YxT5vMd/vIe5E3AlbnKFtpWx+riH2353Yv/4TdvF5mn/yjC/WpbWLPGeKs+W3 aTzs/FzsiRco/4w9Jr7h+LHVWJz8jiLO1u5KfEvJ4GdD+hf820/st4nzuWm6H+vgVzRVq6Ns8R0i fhY/G3nP5mdT0j/4v8knzpD9CVrOz6f4eqWViDXG0e0ceQjQrAykUqA68Z3qDPkYyn5A8K4R32S+ pYjyW5rGv4VZNtFt5ufpNhP6Y55G9+mZdJ+ymG61DKH1Jn6GnEnr+HqVXFch++gPnP3xs8z8bmea os89fQLRvoGwq9WxB7rXm+QzjYBsJsW/DSXO2X/St0E5g4By4DDw4Q+fd8ZeSZx7Lk+s8eecWPN7 ntPfT32VElFf/EwWa7ZqQzk20XYh455tSdYFuXT9mC+U9E0SZ1T8O9vViW9wYcCTSJsi/II6Og3j NYGfmakryK+spknSptizJ/LAZxJnjH8WOruat1OJf7fLSOjcrRK/kvwWecSZ5BviG951CVwJPX1Y fDP7TJyFTdI2A/zcMUaTIKsPTwJz6wRiHyqbUReH+O4XezaBe5SJQj8DCd3MUI7SGOVRoTPuxDdB p7IO4LJbCB0dmMCF/Nub+L4nqJDVZ5D7apog+sjP5jZDbyEf+X5xPnhGMq+plqboq6CvW6A7V6Pe egpq64HD5NcGwD9cjX6PAu/VtFL6F1VxsJti70sKwmgIh0xUpcAzh+0h/u2XfxNOfFdbAtyG/vBv W1/xfCJv/FsuRymHtInlJL4TJsOp8bBIeymBrxJ4uBuQL/YP4FvpID85RPkS2vVf8TbJLuhqD4Bn VgIykMW/ASqnQ1bfxYieAC+nFT2BdE4LeiKRnt4TSOd0eE8gffgPtOPH8v1YO34svbAnkF74f6Ad P1ZuXk8gPe8n2tfQE0hv+A/a8WNyzu8JpOf/RDvG9wTSx/dsB+zTFuAp7FEf5+sn1upLQPm/n3kK 6ALgdwhj3xubm4i/kMg37yT4TyyYwEiA76WxHsc+B+4FJp4EryuWlvg3SBP1xM5D+EvQU+N1cd7o rnjdAok6ow8n2voEsKNbnLcddUffj9cn6kY7ojvjfkzs7kT+oYl6H4m3O+oDvSien7/nfRR8j5xE DNMvBjvexfs2+SR426PY+8d+FfeZoh0JWT4Qr7cL+8RYAChPvF950i7QC+JbEf+2g7XaJBFxym2t sLnzydNtrUp+s76T2zsNrVFqKEuDD4cyLNxv4DZc7Cdh98V+8q/iu/psgXysI28g/g+UsRF66IDd vJaKeR3iu8yF/D5L7AHuc8hv0EQO4Wt0irW6jq8HllOoWRuCNh2mdJSfof+ZbtDO4vdLxJpn1ech fg78Dv6NTKelpvvpBn0f3stUj/VqRDI9ubfVrovF1D5kTVLrEGo2P4n0a+FLpVMDr08fQPxMZ1Cy 7hNyeIzvc8W4c/lvAn5LdLwMOE20Ge0FTQHNSN4bEDJ5EXtymfqIb07v4z0ju+bDvDpOxboZ/sV2 WmmW6C59hti7z1Q2fOe+QDn//qS9Rn3UaygtuXfX3oZcz4cvnaD8bCR5HqDeR3crL6Cs+ygkvmsl zgNO0GQZ/HvbZ3QPvyvR069J+lEn/JvEGcGJOhL94ZSvnd36L2g3fyN+prCVTuffxvh3POF39KDJ NvHvePxbGso5S/hfw+gs/TKsrb+leu1ZGqGOgJ8+lkaY0imkP0QB7p/pc6Gb3F/jZzghKlfvIczx 2AiMz4ugFwORxPyelphzfwUeS9iOSfF0MTeR1nV3Iv1c4HJgfvw9fxdbFg93fREvX7y7PJ6/i9sq /g1O4mc0CXTFz23EnD3Kw93kfIfw6b9Pk9/ub0v4rT9N/5tnaHwO8ztVP/CNvyfl34eHJuOYn6/F wX252J+TfnRPGv/eL3xY/t3/swR9N0Ff5rrGfb2etOf9lR+7z/LjfmxiniXpd++99KTNJ+7l/AxV ut2T+SH63z27E9/rYaeS9Pv3DxJncidowi/veQ/nJL0FftrfE36sI36uSDeKuzk/gRN3uL6Kfal9 1Z3CRgL8Ts8PQctGvmwi/XexL/XfnaTijsFPQLsZfDdjfQnGvjQFu1PycKDNa+OIbQeeBf4OfA60 A50yi30p/sX2dbEvlXXdKdaOdWJ/8kP36yZp96He+1DPVNQHK66/iPbCCog7DT8B+OykR8E3S/Tx K74W/iT+jHrgLZiuRz3Xg+cY6jkm6FccSbkn5ZiUC/r2kRivZJuT9SfK/d+OI8q84afw4+MS+4rj /1S/f6rt6vOxvwDv8jDm0juJfck78bt7KOO7bb5JtPtD9BHQT49D3KXZFPsyga8g1w+Av3EblcAz iTtLH3PdkqEDHKgnAdTTUw++SiARj9+/iXVpH8b26WNj7/J5wO/+cHBf6ofko8+J/QU6+K5+B+if wXOu2CNx34t/f+ZnN/yO7cyE7csxv4L160ZxJhPia70pAt0m2J+nae53fb7Y5IQN5vdg+Z0it9ZO U+QonY798jrFBpv0ZuxDDtR1bQIvJrAu7vvF/gj8IXFHkqf/pjvkvpTNgfAQ1IdaYvcl/G3uxy6O I/pRPP1ku07ckYQnjL0uoW8zMd5O4b/chbbdhT04oxu4vyDWCCf240vpJviUDnHnJrHvF2cP/wKN IwdymaLcIu6MThb4BPn4vRpA3MmJ31OaqOXTRGW/uF8Tv/PL7/q+B3wJ3s/hc049ebeGl8H9Qe4X yf+EHGFT5Aewx4XnLD8IOjUORQa9HHv0xfBR/45wBMhGei7oxcAlCBeCXgacATyWSP8lVfG/lyCr CHNgL61sj1M5sa8We+tX45BDqAPp0kvIdy2FpS+RNhqwAGMS4Hl2w8fj74aLfFXSJ6jjNLLIGYnw CLx7GzDF9+/iXOHLxLtknuEn86gHqd6yHj5VKrAqtlOti+1kn1C2MoXfH4rZAYxklO+Hnkj4UZit sQnA/fz89Xv3ApLfyRNUfYGq1VuoSvPS1WqAGrAXqNOcWIebqBj2h9+/nhrfE0X53m4ev0/M7xLL e+Pn3onzcRHW9lBf87XY98LLStw5FlTaTOIfcGZTxdop7tIz7r1tjntk4v405lrSz9Vb6Ub9V/Al f0VnJGzRzMRZVwpf1xGuFmdCJTQ8focqNjzu48f4fJgM23Di7JVTfqeN61bCF+T5H5O9/M5VbBD/ ViGfwu9rCd7RwBjgyoQMx6Lc+7t9f9rO0fPOxv/T37d6fp/6se9FP3c34+fuanwv/h9+U+l5d+Pn 7nL8XPx732B+5nuZ8s/Y09yH5nZUz+Lh2F7gjzLCHNDlGN69DV3KQb5rpEOYs+9gffiWgokz0Qyk e2C/PMpRoX8r4uXBPy8QZ678bH5ht7/nsAa+61zul8o7Y89yOyfuIZI4sxzT7ay27sQ57TCaKGwt bGrirPZGvk8TNsgioHE7w20QO0QWgLidEeeSFyGeE7dLPCwtxWy4CeFGvB8Tt1PcBskzwDMDacfi NkvYTG7b+DyEvZIN4CzEP00ANkg6AArIv4+3Q/qYf6uJ3hIHX3OiG/jaJGynFC9XnEMinPj7KHzt 4/fWZyJf3c/5Swn/MuljPtsz/nN+IfK82B0935/4hvMev+sPf+F58sb/zkti35W4G631F/sVYXcw lhndzt/DiTPnsBivVZQCm5LxvX2BTAv42Cb39JDTc4m7JUk6Iw6xTnM5fiRsJaMWUQdsXELvNOHX 8P0d3ztsin+LSOz9kns5b0K3itG3O7AOruT3/BPr/W7+vSWBX3Pwdie++f/i/x1g0+OQ3ohDcSTw pzg094/D5EpgfxyWkUQ29NM+5D+Hc3QcrmvjcK8lSgXS0EYv4HPE4Ude/8NE6WhzBurLDBNlVRJl Y24EvRiKM4nyLifKn01U0EFUjHWl5DD///p60Yte9KIXvehFL3rRi170ohe96EUvetGLXvSiF73o RS960Yte9KIXvehFL3rRi170ohe96EUvetGLXvSiF73oRS960Yv/X4Px/7GJvqQaupk0kshFFfxv rmrHpGdIJWnrlOV1dvkx2gLgJZ4hYCMgkyE/1q7bq4wOULdH0DZvWdWOWCcCQ/qL9PLbqpbvljfT DOqP5M1tU3ny5nZjZJWg/YfGaUU/QdtM8de6pypYlw62CkAiZyI0AbgZ2AA8BWho0GZ6D4gBsvyo /EBbfRAlPISCnHUe+SF0z8DzVSAGyGj9Q+jLQ/RFIkVBqx5sN9t49Q8Krgz5QXA58XQBy4EtwKuA Sgvw3ADEABmhB/DuAZLkB+RftbmCrjqLfD8tAyT5bnIy/l+Pdsrr211CNne1O1OrjDqXfDs1AhJF 5HHUCUgodh3Y1pGE7A1t5f2ECBvaLY4qF/KvQaPXoCFrUOVGPJmIGwDPv6Y91cuLv6bNmSL4ftlW GY4H2l3+qkZI4RJi8hz5AsqjoHwlaDbo2aBZoLPk2WQX7TTana6q5aivFtlr5TQqwes62UtVoCPl dMoQ2Za0OeL1LGkrLq1Cj0fIfpHFKdspDGqS9baqYGiXbAjhr2w3W3n7Vra50qqelK+TdfIg13Lk 8gWdT8oWjKxF9GRKu9letbbOJk9BN6dALEG0kUHKF4iCLmhDQXUp8ig5k7x4d56cRWmg9XK2oI/I v6J60PvaCzODnbvkWwXXLbxQVD8srlrD2u2Oqs46szwMbyPyTRiAm0Tla9sLB1dRXaFcTJWABBkv Q2iZUPrVCK3GqK3GSK3GSK1Go1ZD+0hehTerkKdCvowWyhfTWmADwlyt0tog0B0ikF9ctUMOyH4I xrULomRITW83O3jL/G3uVJHN325zVNU+KV8IPb8QZRryRe0+f9WCXXKp6Eqfdn8GZ1jYBnV9UvbF hwaMXj4kT8qZEAQXTJac3ZYWjNQFEeeKHCQmvSTt4UKSXpf28uGWXkWc05cT9JUE/XOcxjqlPfFJ Ib3G6f66TOkDFDZDepc2ICRJu6Q/UCUY3pY6eCukt6QdVAu6D/HZoDtA+4PubMt5IdghdbSDoO33 tNm9vLPSH9rKKhKBYEEi4MtIBNzeqroC6RnpacpEEX8FzQd9WuqkXNCnQP2gndJF9ALo49IAGgq6 LUGflXZzFZeekLbTYND2NgdvQqRN52RLm8bJ79ooHmusCO6WfidtpnRk/W1bYTpSH20vzA86d6E8 Jj0kXdSWFXTXWaRfsSZ2GJk20j5OyS090DaIF7K2bXcouENaK601/IOMAqPceFiuLKgsr3xYDhWE ykODQg+H6lzSTTAgGyTMX2kNnoMoJEF7AANYK61qUwZF6rrQJ94viZbjuVGEWvFcKEKEp+vE20Mi VCtdRxMACWVcCSwDlgNXkYLnZcAvgcuBK0TKRcAS4GJYk4XgWAiOheBYKDgWgmMhOBaCY6HgWChq XwJwjlZwtIKjFRytgqMVHK3gaAVHq+Dg7W0FR6vgaARHIzgawdEoOBrB0QiORnA0Co5GcDSCo1Fw GOAwwGGAwxAcBjgMcBjgMASHAQ4DHIbgqARHJTgqwVEpOCrBUQmOSnBUCo5KcFSCo1JwhMARAkcI HCHBEQJHCBwhcIQERwgcIXCEBIcLHC5wuMDhEhwucLjA4QKHS3C4xPgsATjHfnDsB8d+cOwXHPvB sR8c+8GxX3DsB8d+cOyXLt4q76n7I1j2gGUPWPYIlj1g2QOWPWDZI1j2gGUPWPYkun6REIYEtbkS WAYsBzhvJ3g7wdsJ3k7B2ynUawnAeSPgiIAjAo6I4IiAIwKOCDgigiMCjgg4IoJjIzg2gmMjODYK jo3g2AiOjeDYKDg2CsVdAnCO/1wp/+Ohka5iTSastdJyViLoMvpc0Ctpn6BX0FZBL6eHBf0lXS3o ZTRI0IupUFCUJ+hFFDSxtuAgZ50XJmACMANYAGwAtgBPAboIvQq8B8SkAUau4tQn6Bv0LfpTurpF 369LTm2CtkHboj2lqVu0/ZoUqsuQ7MKOwrTQzeK5DM8vACwieNaKUK0URr1h2NkB+A1LYSPlYOiL UvZqKXuqlG0pZTeXsjqzdCpThKUL0SAJDWdNhq1wWHAfMKiwaBgs003bP/cF2woHBjvY7jgpMcpA Pwe2Ag8DVwODgCqgHCgAgiKtFPmbjNxEkbuBIiAHCPEqyOslIneKydgh2dnD7X+0k5nXU1QMvl1t RZUgHW1FE0CeaCuaFawzs+1UxL0i9jhGbjPolrbgAbz+bZw81hbcBfJoWzAM0tJW1BfkjLaiV4J1 djaVggpnnZKgk9FvTie1Bach28S2YAlIWVtRIc9diooK8LaENdEB0IIEV368pry24FCQ3LZgNc9t oiI+8EyjctE8FeBUbkeDvtjBmhRmWIMHg7cGPwf7ZxAs1OOtUIcC8mpBB5tmWIK7y+9H5rpgW52F 58f6sDVBI5w+Hny4YFXwHpTFCrYH7wr2Dd5U3mFC8o1o9ypRRVvw6lCHtNlIDS4PVgYvKj8QvDA4 NjgzOCnYUoD0tuCZwd28mdTMmqTN24ONKHAMelHQFjy1oEM0sT54adAIFgWrQ7u5fGlwvNxB5bu5 BKgqXnsfyLe0oIPr+NRBHSzFKNUP6Wv1M/Th+lA9T8/Vs/Us3WNym1wmh8lmsphMJs2kmCQTmTz8 /+gt4//nq0cT//WrpvCnIsIuiT/Fv1iDpYqZJBpLkVS5QWqYPJw1RDrPpoZZociRyXkdzDJxekTN G84i7gZqmDI8MrisoUOPTYoMKmuI6I1nNG1l7KZmpEaklR2MpjR1sBhPui4j4h6Bl3TdjRk7iLHA dTc2N5Pfu7TWX+sellJdP/IHHq2JZ9nJH3/3YFbkjobJTZFNWc2RKh6IZTU3RK6aHDqzaYfklOyj Ru6QHJw0N+1QFkrOUZN4urJwZDOyHRDZoM0OZKMiTpDNNJxCPBvsyXCeDWMUz1cIduTL4QT5LHYq FPkKLXaRT2E839Z9oVEjt4ZCIk8B0T6RZ18BdcsDjQHvyK2FhSJXXog18VysKS8kGlYiCgoGkaU8 KLIw+HWioCATlUUqTmYpSGQZcCLLAFGXzE7mCcbzeIqTeTzFyFP2v/yZM7zs/2rral7bhqG47JRm bffRXkpoVhbPZIcJN7jQ5tAw28E+5bLSHeydnA5De9pAVnvzdh295E9wL6FH2YbSFQoF/2Hre7KT fWDZ0pPeT3o/8yQj3ukphcmT0ot0L9S9CGoori7OOuLHaa+XJRyBnmi9C0+/nKGcRoLrkSsS3e1l ZtkAlwibupuR0vvkZ6Udublpm54+dYPCGvnOP1w/l1z+qMHYCI35yGU5DbCDsIVcDnI5yGXZluTy zvHcf/SzZ2SMyZ2lLNSNdTjDYVcLxtub3z7ggf51pHWS7v0KUW7IBg3Ec30sXkBFyHAMByH4zxB6 CepXNdRJjrTuvXJTQ5ug3tLHy3TrBCdNxMHxRGgnn308KsKeNu8ZwyLhDvHOXXhhHMsKz98zCWss cVPhnDNsOGWETMT7k4k4PIYvabeBKnQD0O0tdK2W1GVra97d70cAKXyEEiMd9qhCwYP2OkRdbTVd TdsqhgpxsbO7//UBbvDvUCGOUy/zgQyf1cvibR/jl7gYHFQSwlWU+Y62jxnBh7AUZb+S9pYBnVl/ ZsyGaT810uEqaG/noHwzx6s0H8xbJKZs4QjoxgE4G7N2A991/npXEqfYoTSgTCbqJv+7mtbJwMHp S8ey2iqT5uPFhlR6VhuBnajY+WIZrxdJkMtFlZFqtGz+FBgR8gQ7q7gjCmVuZHN0cmVhbQplbmRv YmoKOTMKMApvYmoKPDwKL1R5cGUKL0ZvbnQKL1N1YnR5cGUKL0NJREZvbnRUeXBlMgovQmFzZUZv bnQKL01VRlVaWStBcmlhbC1Cb2xkCi9DSURTeXN0ZW1JbmZvCjw8Ci9SZWdpc3RyeQooQWRvYmUp Ci9PcmRlcmluZwooVUNTKQovU3VwcGxlbWVudAowCj4+Ci9Gb250RGVzY3JpcHRvcgo5NQowClIK L0NJRFRvR0lETWFwCi9JZGVudGl0eQovRFcKMjc3Ci9XClsKMApbCjc1MAowCjAKMjc3Cl0KNAoz MwowCjM0ClsKNjEwCjAKNzIyCjAKNzIyCjAKNjY2CjAKNzc3Cl0KNDMKNDgKMAo0OQpbCjcyMgow CjY2NgowCjcyMgo2NjYKNjEwCl0KNTYKNjcKMAo2OApbCjU1NgowCjU1NgowCjU1NgozMzMKNjEw CjYxMAoyNzcKMAo1NTYKMjc3Cjg4OQpdCjgxCjg0CjYxMAo4NQpbCjM4OQo1NTYKMzMzCjYxMAo1 NTYKNzc3CjU1Ngo1NTYKXQpdCj4+CmVuZG9iago5NQowCm9iago8PAovVHlwZQovRm9udERlc2Ny aXB0b3IKL0ZvbnROYW1lCi9NVUZVWlkrQXJpYWwtQm9sZAovRmxhZ3MKNAovRm9udEJCb3gKWwot NjI3Ci0zNzYKMjAwMAoxMDEwCl0KL0FzY2VudAo3MjgKL0Rlc2NlbnQKLTIxMAovSXRhbGljQW5n bGUKMAovQ2FwSGVpZ2h0CjcxNQovU3RlbVYKODAKL0ZvbnRGaWxlMgo5NgowClIKPj4KZW5kb2Jq Cjk4CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKMTAzCjAKUgo+PgpzdHJl YW0KeJx9UslugzAQvfMVPraHCGxwaCWEVKWqxKGLSvsBxh5SpGIsQw78fc1MkpZUChLL87xlsCfe VY+V7SYWv/lB1zCxtrPGwzgcvAbWwL6zERfMdHo6InzqXrkoDuJ6HifoK9sOUVGw+D0Ux8nP7ObB DA3cRvGrN+A7u2c3n7s64Prg3Df0YCeWRGXJDLTB6Fm5F9UDi1G2qUyod9O8CZpfxsfsgAnEnJrR g4HRKQ1e2T1ERRKukhVP4SojsOainpCqaQkGwulTnCr6S3n0SYNPkoikRCQJiZJEyErXbgutQVqi iX1HWkDEjxYNLvKcFkmQZuXVZrghmkJt6AJRe70ZkVEgaTNO2pa09HeZxsVUnuyXlxSrZvhlMykZ SvU3XvyLzyheUtKW4iUlSbLI10npRRLPt4EmpMIz4LlGpHED+X1GaLUJy4kvg3keJ33wPkwSTi+O 0DI8nYXzgLvBLSq8fwD++uSzCmVuZHN0cmVhbQplbmRvYmoKMTAwCjAKb2JqCjw8Ci9GaWx0ZXIK L0ZsYXRlRGVjb2RlCi9MZW5ndGgKMTA0CjAKUgo+PgpzdHJlYW0KeJykvAt8FNXZMH7Omfvs7O7M 3m/Z7Gazm5AFAiRcgtGMchMw3EGCrAS5gwgBRFHUUBUQUdHWa1XwUgWVEiBgQFtTSrVeKNRrxSq0 xWuN8raUKpDd/3PO7MZg3+//6/f7dnZmzpy5nfPcn+c8ZxBGCCmoGXFIn7VyReyJyAd/h5pHERIn zV06b/FbqxoegfJJWK+Zd/Wqud+9dsUrCNkbEbqKzJ8zc/bRf6VeQmjJbLhnwHyocFV5s3AM96PS +YtXXH/6ytxZOG5HqPrdq5fMmsmf3jUBoad/Bsd/Wjzz+qWuy4RjCH14NVwfW7psztLk+/Xw/A83 ImT7tbAfBWENCc+iIJ9CAYRyn8P6Bd1nF+S+oOfpnnwFd7flV4S2ou14AdqOXkEH8Em4awfah1rR 75EfDYV+rUY/Q+uQiKZBzR1oAiwC1P8MB3OtqBI9AXB4Ah2Cay9HN6P9yIcDuS/RLeh27h2463Zk RyXoYjQOLUF34cty16Lp6Bh/KxqILkPXoKW4OTc1d3fuvtzT6BdoH/f7XCeyoRCaBcuh3DfCn3J/ Rr3gjvvRw+gYvk/Zg0x4SzNc+Rhahh7hMjzOzcudgRbE0XXQBh7Vo0O4naTh6XPQ5ziAV3ND4ClP 5VpyB+GqCMqg+egRtB/3xyNIXJieq88dQj54x/Xw1IfRLrQXljb0K3QUa8LJ3NO5kyiIeqKR0J9W 9AfczmU712TrAGICQKkHqoEzS9Cv0WvoCE7g35Algib0E0zhhty7yIP6osnQ2mfhzs/wv8nNsNzC vcoPz12CHACXeym00e/QX3AIV+KxeArpQZaQx7llSIY39oVlNloA8H4Inv4JTuO9RCOHuaf45/mz YlH2eM4BGEmhn6PH0G+wHXoaw8vxT/D7+G9kCJlBfk7+yv2M38a/Lc2EXl+JFqO70PPo39iFB+Hx +Ao8H6/G6/C9+GF8CB/BX5CLySSyiHzLzeeauF/xl8AykV/O3yqsFe4Uv8hOzR7M/jH771y/3Fo0 HuhhDbT+fvQ49GwfOow+hOUY+isWsA07YInhOJ6Mb4TlZnwXfhJvxdtwK7zlCP4r/hL/A/8LnyUI FpGESZyUwJIgy8h15GfkUXIYliPka/I95+dKuDTXn6vlGrgl0Kp13CZY9nB/4UP8YT4HcO4nPCBs FrYKzwsHhJOiJv1ERvJb557qrOj8JIuy67MPZHdlW3N/QV7AYQigUIxqofUzYVkI+H4AKG4Hegdr ALsQrsAX4csAMjPwQtyErwdI3oYfwb9gbf8lfhmg9AH+FtpsJxHW5t6kP7mEjIXlSjKHNJFN5D7S St4nZziJs3FOzstVcCO4DDeHW8Gt4h7gWri3uI+5v3KnuXOw5HiVL+ZL+BSf5kfwM/hr+cf5z/nP henCm8KnoiouFteKbeL/SAOki6Rx0ngpI90j7ZXelRuBOn+L9qAXUbcfPs6t4YZxe9DdpIoPkj+Q PwA9z0CzuXoClEq24vXkJtxKSoXrxQvIBXgMOsmnANavks3kNLmAq8ej8US0kPS1niZ6+OdgV8v/ FnXwL0Pf/gBPvl7U8M3kW1FDuzAiNfDO33F9+DT3JjrKHcMS/wT6iFexH3eQZ7lxQAW/4i8SpqI4 9yj6JdeEb0J7yDCE1LPyRqDjMfg5kAuTcD/8HZdDHBkDVDSQ+xu6FS0if0IdwMfr0YN4Nj8P3Y2q 8Gr0OXoGuKKHcI1YIXrx62QBv4G4cSsi/DboXQ0uxZzgQbfhDPeI+C35EF2LDvMq+oR7AVp/mPyS q+dPChPwfOCAm9Ba1JRbg1YJU/m38TzE4SkoyR8H6baa68fHYX8LSJXpINP2AnfvBzlwMVcPNQGg nMuALiaDhHgElodATvBAQQuAxy8HKfYH1CpOIm1onuDAIHUQ4t/MTkDTcs+gh3Pz0DW5+1AvkAfr cqvhiVvRp+getBXfnr0RLUVR4JxP8GXCcHJYGJ7rRTaQD8lE8sD5+AVoJ3EAfQXLL+HgIuEltIH/ AE1EdbmNufeAustBwj6MrkKj0Ano5Tfwhku5dlSVHUN25oZzS6G/x9D43LO5Yqyi+bmr0Vj0MvqF JKCZUhpw3ILfhv7eiOaQCbkV3JzsAoDDPQAFE6B1LcifO8whkyddbNZddGHtBYNrBg3sX13Vr2+f yt69eqYrepSXpZKliZJ4rDhaFAmHggG/z+txuwzd6bBrNlWRJVHgOYJRz2GJ4Y2xllRjC59KXHpp L3qcmAkVM7tVNLbEoGr4+de0xBrZZbHzrzThyrk/utK0rjS7rsR6rBbV9uoZG5aItRwamoi14Wnj p0L5rqGJhlhLByvXs/ImVrZDOR6HG2LDAvOHxlpwY2xYy/CV8zcMaxwKj9tpU4ckhsxRe/VEO1Ub FG1QavEnlu7E/oswKxD/sME7CZLt0KiWUGLosJZgYihtQQuXHDZzdsu48VOHDQ3H4w29erbgIbMS V7WgxCUtzjS7BA1hr2kRh7RI7DWxBbQ36M7Yzp7tGza26eiqxrQ2OzF75vSpLdzMBvoOIw3vHdri v+FE4IdDeLhryNR13c+GuQ3DAgti9HDDhnWxli3jp3Y/G6fbhgZ4BtxLksMbNwyHV28EII6eGIO3 kdsbprbg2+GVMdoT2iurf3MSw2hN48JYi5K4JDF/w8JGQE1oQwuasCq+KxQy9+WOo9Cw2IZJUxPx lrpwomHm0MhOD9owYdXuoBkLnn+mV8+dumEBdqfDmS9o9u6FOV3nWIldTkujJ3RBFtMWJUYCQbTE ZsWgJVMT0KdBdDNnENowaxBcBr8GDHe1zAaMLGhRhjRu0AfTenp/i5DUE7EN/0JAAYmOr8+vmZmv EZP6vxAtUjrpIjU4Xyi3pNMtFRWURKQhgFNo40XsuH+vnivbSCKxVI/BDsCHxgFsZzYMrgTwx+MU wXe2megqOGhpHj/VOo6hq8K7kFmZbmghjfRMe+GMdzI901w403V7YwIouRVRc9XbIqe6/k7d5x42 f3AL9v3/nJ5jnR89MTF6/LSpsWEbGvOwHT3pvCPr/KCuc/lSi3vIVC5M8iUS5thZIMrpXRfTg6la C5+Ev8iIenabJANVshocG96iN15qbRvUePy/vKktd5LexXY/3JZvZsvg9PnHF5x3fF7ztA0cNBhU 5ehJ0zZsUM87B6RmvXBkfgcUjyZNjceGtKDJwJlJ+Lfl2gfRtSHcYgLIhtALgP6sqvzheReG8+UG +FHq7NVzOAi6DRuGJ2LDNzRumNmWa74qEdMTG/aRA+TAhqXDGguE05bbf2e4ZfjGBoDVfDwYmIKg S3Ym8PrxO028fuK0qft08BXWT5q6i2AypPGShp2lcG7qvhhCJqsltJZW0oMYPUCjMXRyF5HZ9eF9 JkLN7CzPKtjxrDaMWJ1cqMNoVhux6vRCHYE63qozWR39URkzZNLU7tTDWLKhF1AjwczAFhBY7BJC cSNuJGGDQemei3Ht50wBnUUxHhwkgq7kdpPrwKsRwG+4dh+4Od/tLklWC22578ySVI9qm6iCouMx EgTR9o0iyxxHkCTXqk6lWSEKgNv02p3VyieY42sJNu1GNQ5qTc8G0mP0U+na+s5avTOdqe2sRXW1 OiydtbDBhqumhq59++B02s31r/JyVWy7qd+hXh/3PdSH2439J09mv7S2oMDR6ux40ii8g3R0oamW OTHSXZKs6224ajfa7JBhbxrSZseViNO5GMdxLxiPbQyk9dOZztMd+ukOeH1dLbwug1PEqB44YGCV KMHi1TE+dv8f6qe9vGZV2YWJNE5nx7+Mv8OOb452nj3SsOGBl36VLc7Gznv/HFMrJ+U6UVQdI5dC W6Bu5jDsW9Fm7koHcE6rrpPJUPiu1elkhROtdjsrfG06VZVMdjqKHcTxgivfxjT8ftROdwIZ1WUp WKp8YBPopHMNwKrkwrIb1rw8rf5wdjw+jv/y8r4HNkx7+2zn0W+y/8jK0MplYI8M5vcCLgeZxega hXwvc9cIkqhco/Lq9wK+pg4MbkKC2uXTGIYy9adqO2r1E7W1qPIUIOdU3z5JI94/blQZcW/cIDjb hO95Dt+TberA922l+63Za+A9z2U/wbeCv6iiMXtUILLnxTY8zkxhrpYQrOJapBIODpA4SBo8Fmzp JWAZbgEa22J74iHo8anMqRM6vBeogm71Dr2zgxJF3z5VQAUeUSobMGDg3kPjLu9XM4A7dKjpzlR9 cOYV8N6LcRtZSBYDXfc0g0vJUo7U43p4ZQKRkLAULgjyS++iPTuR0T9DlfUdffugJgBm/7j3YtID t+3ZQ2lpP2zWQes5lDQDhDa21mriDsRvgfNbeNbK05kM4KPDatT+Q4cO0XtR7nNSA3TAoYn7EJf7 ZJenhrTlPjFjnpoHOUy4zdwOjnArEfbA1cCIHFK5LxD5AuhjG7yc330DPLlWP9WhW7heJ/ROZ27S D1Kcp9NeXIXxtk3ZqUHh6zMeyp+Tc5/zhtAOdFeEJ+8klOlNNRTlBU/UbvcDA37BaIwWzCAlMsVA Gq1BPk2DrUbrUCUQ2CHYHIL+0B6Fd4r/+aRT8CSRPukzoFZW+MYM2mwifaROa5CuaXRL67oe+cMz W8VYUI8A+YMItP0ajBYfrC5Ynbnj5lW8uI6st613vu4QFMkWIMPcl3lHBYeEJ7mne6cHJ4QXSYts s9xXexcFG8OryHXiStsNznXiQ9ID+uuBo+R98X3bR85QV3OXK2Y8Ud1HwUjRQQ5tKjaWIyqMHFAb Q1Roboq+dqfFXMBXmaZ0R76ZONOEMmgQ/WFYGxrcumtAVT+fzwVMJiZKylJu3VfVb4ChpxIlkjh5 0TtbVu5accnCd554d9W9+7atXr1t282rR2XIO5jHF74wY3c2dzSbzf52+0Mv4seyD357Es/HC79Z sJbSyjFA4FnAnYp2mDGOysZF/C3kHvKwzL/AYwWJAuEUAWsEv6Gy1qu0TwhTedOWO86kCBS+Mg2G 0AhDqIMhFKBsBim6Cjhh+AlpggnSWChAoo+AY4IpECFo249r8e3IYo2mNMAlbf3ggEppVFfnr8EG lcgZlEnHE4YoSv2BC6vI2daL35n04F8rV/A3XrS6+Jcj3phB+1YLtCxB36L4tTwtKYZuD7jd4mQ7 JSXDYIVvTEXXoRT1CFFKon56QTRKz0YjDjgT1WjLo23kJVMjqt8fK9YNQmLFIA0q3z1Et4dQZQdt aR3dHuxHiZd0vVBzuQh7oak4DVJ4z3HT5nKTyVEPraPP3gWPpqxis5HJfiqFGRT/t7dReqbvo29j LzMHXCBcIL4kvCK+JL0mvx6RRmoN2iTHIm224wbXDe47XC+7Pg19Gj4Z0l6xvegmYT2iF+lRXfx1 7iSSgPhl2CuArVBU1WVRfCMS8kQiITkSAmkhhyKcPaq3kad3jzWw0YYDe2gPEAOHExNNXe5/B6BN aR2/RNagGNLxIFMz9tSRGWQJuQWsif2kFBXje3ZaxA5y5XSaihcQLp21dR2dmROGi2IWNuscvdMO EDWWpEUFDhiEMjizrKEh6Y2nBgLGBwzoXw2kz4Qw8AWIY1CUosRL5wYSf/KpR77d+vCNP3kU73N/ 98d3Tl/67IEnp0e3b7+4dlb7zQc/nbvop49ucB/+8KvtU597+en1M/sCI4aAUnSwMFRkxylzgGuq Nl97RNumva4Jl3GX2X/Gcy6ABNJEThJUGychDUjiDY73cBzP2RHR7LzEvUReQjIYNltMFfE8XILe UPk2MvdFQVDNouJqtcAvqiW+WOEbJsfUNjzQtEtmSaJaao73lzY5CeUPm91TjcDKihGO0JvpPVA4 sZfeQ/Y42vBGBtOvgUcYu5yiRFirf6YzbtFP1Z6uNWpqmC2zrneaB8A6nU7gH7Cv9yE7aAZXDRDm u6atqoYr6VXD8UVFtfQRDcBgcI3p0UxbjdY8rkYzUzVaSQT2vWoYTzaAsdYfVxlV3oTBGZg80Hkb eeynr77amu2PZ/yC23tu1C+yTwDq7+9cBJxINURceAY4cYrFGPsQhv7ZaYdwxKFGvd6IixKUzcnz 0YjdgZEUAKnC9AYr0CsDlPIrD1UyKQl80HlQP5im5N/DxTjUybajQ6uKNhQ94H7W/Vvtfe2jsKy4 A46KEKf0EfrY9gO1c8B7ulv1utzuNxxOj8PtcTjtQN+mmzbEdGwBs8fhNL0436gXnTx+h9q9QPtm jDbPmKEv0W/R79F5vVlaHmBiPoBRQA8QaOypF2kzAptirpdxf+TE9wNRDdrl2IP340GgmwGtPyiA 4jZ8386CDjjVwViDKoJTGWp3AGewjmYMWMECObFO7p0WAIuIsQfjDNwEOrnBPdBHFUKBK9xgGXHA GcjrkUBfpCb/yvvw1T9p3b7x8o3l2+4mH3a+OPa2e9uxvOKuU7/vxM36hjsPPvnIrrF1PvI/L2RX Ts+e/uNr9+46TnV7PWDOCzK0CFXgsXmhVuzExXgG5nC4PGrasd0OAi0slEQ9djWKUVKnoo7peT3q 1ykG/TpVC36m5/15pXzo3UP67wqYzHToBzMUk70WBfFQyfQODQ6NTXNNii3iZkuz5YWu2bEV8rWR 2+W1kffld32GFKMgLrN4QpycYOKUluLshERPlMUSsTg9YdBWjrMTaGcYvzODIpLMN5VCm8HqGWS6 0J7kcp0hEixmHbgUenHyRaq39E09VYq5KK4xfXX+Gf4l/lv8vN9Hz/l99HX+NlK6O22pcuDEji4k WvqcyTfaxzzGKPtQDdaAJbCdqQIXJSrGXFSMJUqQoQ+kQg17uqGUO7s70HPkoikXT76KXPzyvNbO 647c9pfsicfu+GL7x50Dx949ZtnTT954w3P8RMfCPvV9Lvrmz7Mas/9+e0PHzXg0Xo23/WbrgXMf Z55raHv8oR07AAAzQd75hGeRHS01HQftmIc/kXkFZBnlwj4E84pmXw6OFAXJWCbIORJyysuVv6Ox gPsZhKuD3RJ8C5gYQUeeiqm13lRbf6pjjH6a6mxqP1IZX2PUWAIdiJXauSLiRCkxwOUaOJPbszHb MXqAcx/3k3/ewZ/ZvvH+rCt7tu2j7fgr/Nqj1DucCBQYBAr0owTqQ5BFg60aCkd7UxkJ2ppM7t3b FY+KQnnUZY8qGiU2aivuZbZm2km9HUqGzoJ6pQV20hngCq4QV7iK6yJfrtSr0cu97IleRr7eH2zK 8w1Wqpc7qLuYt1tfZA0RCw0RrYacYParsyDD8++ndVA4Z5bQSvpaeqeXiTMv6+kP/Su8DN6FK/MN KKyUgwb29+EevpG+kanPtC/7CEoffBO6Ca/mV8hNtmXatfYb/HeiDXgjv1ZeY7tNW2u/y/+W8arb VQKcsisSC9FdLFZJd71iKco+0R4xDUUDSINmbOmNu0F6+SsKVtrIPFNPL3eaMeAd8HmdupM42/C9 e/sFlreAgwXnd5Uu93YZvl7TS7yb+nYZvqeA909ZIq8j37cM61ze+R6U/4H+b0JNDQ04lepfnVf6 kg+2CFgGatyebtzSnXXwwqVXf/ZK+1eLFq+7K3v6ww+zp++9au2i+bffMXfe+sEjN01cs3X7T255 lgv3eGjhlqPHtsx9sEfPg+tfziGM2+/5DZ40/7ZbZ8xad9u5XP2msc80/+S5rVQq7gODZy2fYrGL QaATBCRKChFrea4Wizz4aqCjEKE28hNy3ptsorwAHhXrF+uam0YTYN0HbhvXcOjQuWfBfSNoGvCm Bt5bFJWg28zKjaE7w2R1aHWYXBWaEyaLtJkOMg2MOzLAMdRBwkFZ4pFeZhjI3sODo8C+O8xEvCRe W6wW15aUxGrj8Si6MnqNeqV/Yal+ZQxMuIUJ6lkD8KkzDxqnlrq5nczNPV3LaOuE4WdWNvxQJoMB 4AMHDLyIdLe5eAp+B5FoB/CfcNTXt/SlQU9ft/yRwL7gv9/8AKNpt04dECJth/CCUtfC+sEXpH9x 1eAFmzc97Dt09KtnGp9cMWZU49XZB2mPc50ICQ1gfUnIgeftxQ6nzsycf7TmC98xIU8oXzYwlmLs IbBtpd5HnyfPVxr19dwm/XXhVbFdP6nbZKEBTyHj9Pm2Fv2f2j/t/3QovMbbeQdnUxWB5zW7QxYl SYOyLGoS+Mw0muRk3ktM0jxwinAcrfPSOi7Gax64S4kKghwVObGNLDUVJGtfmgQTsh/bgFxspkuL oTkSN2Ecf5g/xnObeMy3YWzaxmnt0jGN26RhjR7rTumwRG6RmiUi/dT5/gcWfQRhhX8AaCQU1Ds6 UKCuNtRRd4Khp4P64GnQ/Ot6B9jeik+BWacfPOg4eHCdYO0Ba6NbbBNHt0THT5vayjs5WdoPxj3K fUd5qAEva8pYPlUCvPgEF+fccS5VJkocqfojmfrx850/f+JD/D8PDy+JVAn7zwzHL2eHkmn4gX3X 3XUnlcUPAG1+CZgymD3g3od4wMkI6mvz/PDElMTcxHLlNkVcELpWWKost90q3GoTy3wKFyiriPqK FMXtilZU9OiBIkVRgFsxOFlIDqREjQpgEaxis4pKYNFFJa0oUsiLMn26yHAteigdiJOSKS1C79BU ep1G6cJLr9JCPYuiMeaaxvJ+6Wkm0lkh75OeaWVItgqi5aWqzDPNpC+YHujyOmlAcAw7qO84lXdE 8x4LrMAkwDO1NZUGDRJil7/glVYZ8X6+LtnkIAkc72e5K6kEmMz9LDaC8gMktfXN5XPn3X7P5c2/ 2Zj9Kb5wzaBRo4f/5PHsR3jxlakh0wZPun9jdruwv2HfnCufqSp7uXnezsa+3ATDN7d+5JIeZ7dI 2qBFwyes6ks93bm5z4WVIDOK0Dt7ZpGFRQRbqo717wtzBi3FUD/7LLQUrShqRrcVbUKPCM9zv7Dv 41rtr9mPoBNF/ywyHK4io6iIqxDLjYpIrHiEfYrncu+U4HxhUdGNrjtdj3APOx6JbMVPk63Gew43 8qCQ7tFDPA0u7SqvwVTG9yqv0Z0I82F3VOPCUV7RU85RKBXDGIeK/amYjGWNtkYORmdNtyKwmXpq L8A2by9ZwgcwQKMgYCotw36RT5SUAuBcpSB5/FKKyiHi9biolOdbD1yY/e2nHdkPfr4DDznwZ9zz gleqDvx029+mL/5s7VN/JaTvt2d/g695+1M8eefxN3ttue/J7Lf3vpT9csPLVJI/DrJnGlC0E2D3 qVkZK8ZDZIs6DT3qRDI0WcHFJrMkGFEpKotlBVgNIz0mkkLFRfp/TXr/LpDedwXSi/6Y9PLlzA8k 17fPkFXmAC4syaIsyLzMi8FAKEBEmwp8oHKi1+fxuX2cGOb8cexywCYgR+LYpxpxBFBMpyvgtwZn KIX6fX4fmJsE6DMZ75f3p8EWjT+Ov39+2s0NK5aPueHeQ7dnd+Kae3/Rd1j9g1eP2Z59S9jvLbrs quzhg89ms9tm9ts+oO+wL5/57N8VUej1kyAZaOaRDd1vekUhKsuShDieAlJVojYkS5Q6inRXtTSJ GxVTY3aihuy88v/ArtoFV1gElAdaPWPYTP2pE+kf82nfPlaw2Fqf5EvPPc6lz73H3Sbs356teyFr 3065CFQ7fzv0QUF3mWnWh3sk3NUN6MKjMRKzERKy/RftNm1WbDPPhNn/aL56wfRuze/W/hOW0Uxd hh+3fSv38blPSUvnONruwds750IbFgPv7wPeT2K3GQp7wl7SWIavlN3YxZWWorjLT5IoShhzxmgb MBb9UQcHVpyCcaosWRrjOOhXWSMLMpxgPWHaNx9tOMowwLRvmN5PljWX4bKiVEzFKgvsqcHUrCu6 WLlez5zO9wcaTx2fLvO4lh1TeQkrdQeAoIfyiXAkFAlGOFFL6UlvqjglJ/lUIhmwF8WRz+mOw8Ue d0yCoxIhGccRG1C2x4BNVInHUSkHG8RcqjQNWtemCz9K6yiD+yeN86SHzy/1JiA+6MiKx8WDABlo cJeRxfdkj2z5U3Zz62487qPNGN+X2hG/au+S2w9cFx+0DpN7bz55Eal7AXceX7Z8H77yT+/j5a3z 2n7WZ2lz/fjbxq7ffDD7XfPMgdgAfDwNEqWEccKfaIyl3Qy5vdU8F1XULeoRlagCITYZODgmSSKN /zCNB/CmDiyUmKssUsM7wDQfZpov0wx+NrHF8nHXdlOFh/4X5Cfnya+bxPHluSdmxzFwixvtS+38 BQ0B8Fi7Aq6WBLLwmK5lwSTgJrDLmRjCoOSAJGFNwPbpA+TMgQOdorC/8xky7cxwsruzHtr4CjDU GoACh97aQ3mH0IDv7kEXssDv7qpqa9+rj7Uv72HtE0lrXxS19oGQFSiusOvVMWGTsEMAWgVj7R60 BbUgvhKZaBw6hk4iwRWDyk2IE6y4GYVCIA+drwvQ+aYAndOmbll6DDpP8u83dBO+Q6ZP3dUM5lym oWlZbWemABIaUKOsWGW8coCaRtDHgbnPuZnMGtpm6nPIPHEFuVZcb19viArjt1YbZbc2HDJtfNSp KClVlVM2Gs2iLbMVwlo2SzqwgqW0aY3JAgy2TMyNY27TPc7d6ObdOEX1eUEkflVA6p/zMmW0a2+h Jx16psnqEbUegQU70tB8lMkHigb0h46wcEPqgh3S0lkjF5YfaPjNT35zCG8JbF09ZPnN3D/OBdve WPgJlYvU6qtg46+LTQ0ToGUByTFq3JJnTadEuP9aiJ/+D8Un/ofi+yxjSW8L2HHvAwfI2wDwf26H VzyEkOiElujkRCGOKAM2Ga3LDrvB5BSgGQoCDeyX05LmoqcFp8YpCBNZsTmQrBDVJjIs6HkUnNnL UKAjGpzN9+S7Qk/OtZ43REVd/rr2dv3IkXYatE6nmb2SRoUhq2KJUZbIthzb8mwrsK1MuT1BS4Sp BxB9VK46fvBtVLaVCq6PTAFWTEspAWsx1VXtZBtB4xB2gHKVQcvSjtOnsQJ7yEtkCnIBrKaY9rwe EgvgZ49FNICQPlUJKogxeK3VmYzVG/ZjkjUdNm9BxCl7SFjmV2prtd8DKLWR2kgn14NP2ns6pnJX 8Cvt1zvW2WUbEeQa+wDHWDKaGyqZcr39Eof6EHmYe0B6QN7KPSuJLuJ0OPoIxCMIRNbs9j6CDEVZ m+CcgE1wpmRZUW3AwQ6HTvHU6Gp2Edd+shXZcd9dQkxuw31NVVPUmKndYsO2/dBJB7bBGdIGLpji BEJ0LtWx3kamvBgTGoVmAYQC2brboEIuSMd1M7UBoDPmZUE51HVwIgM+V10tSwIoLCHwxKjvte4m 5nrBDrjoBxfrV0jLnQUafB/c2PeZhzW6RYNz5XCOSv/vdjpUWpsPuL+7N17j6BlnQfe9A2sc/Qay 4p5eUJsPrKcbwEdDTRmQPw1A/tjnHzAQx0HU4gQ2HsKl+Io+vmB/PAMLL2Wn7MhOFfaf/ce9l477 OXfuzHD+zbP9+eNnKTM+ClqomNoy+KadLltBY8gBzcciXF+YcVqSwcmNSTK4uzK48pys8IQoksxz MVEUCpJT6FJOgsVJoE7MECPnTMyGY7ZxtkbbUluzTbDJYBcx9WSHl/13BhL/nxqqy0DqJpbTmTTT SU2nztNJLhooAi+YZxiy2I+OeR9/UTOq5RhsgIIb+vah5gHgoFU2h9dA99v3Dq+RzX5WsV+NVBJk I+R7g1DsZxVpbcIaN7claiSHB1Y3PT611w3FIqtYBEUvLX6305vHXxp3Yx1AYRWmmhIbj77Gkf2v ncsCwtbwtwCyms82Uw9kFthvHwvvIgcKozfMcSEn9ugeT9gfDvO8zntsfluY3+bf63jVwfn9gTCJ FZnGWPdYvxmaKkxVLtcnGzPc0/wzAlNCl4fv9D9M9GCU41xRm+JNxcB8pfqCIkEq6D+JRhwp6CWq QSj0JToYmo+bnwHCoKIn1FyEi5wpikOxm+gIRgpem+W2ZQqSu/68sWtw3dw6ivfjqZPBrK+BOqrq h4xqAq4bmoXX4wFv4uHPt2b3vnI4u3/r73HRBx/h8Kov7/1D9gPyBl6MHzuQ/cWfj2W37Pk9nvbr 7L+zh3E1Du/Gtp9mP7W8Nr4TqNuOAmiX2XOOschDRuujPVfoV3h4mxYFCYP8Actqd6VkFieQ9bzs zduxcigWwvAPBez/t8b8f/oiwe5qLB87aMpY0YMuc96ynsAoZS5YFBxYEo8bUO7yvkiP++qvvq/h m+zr2fX4xpcfz1zW97bsHcJ+h2vO3sUvZTs7X+Dwxlum3+q1U8p5Anh8O0AhgErwOTPusjmwa0Bk WvFceXExON5Mc7CtxLal1CSh/WCD37SgFQq2QsHVlvvrbleoGvYnd5eUVRv0uKisWs/vnfk9nP/T 7qKUdR6u1/N7et4cCYWkY1RkVGyibXpkcWSZcr1jlfN2db3zQfs2Z5vzC8fnTh20XcxwegzDaTg1 xRUm8ZBPFV10vFwIKIrPHwpG/VSUsPQOvx/FSxg+AwGn0yFHU45HxUJiiVhAFTObS5gBLbJQUSZW urS0uZQrLQn8tzgW/4/yKHHB1v9w2PIMEDwR6Mhnj+VxnYZztTWVbFzbGtYWujJouv1Q3uI0Vdl0 1jj1wYZrMBUbuIlpDAdIn1CwxgD55ILVYUZq9BIPrMWwdgmchm5BJ/Ds3QmuNwFySjDSYlHw+BNk w8G3bnjjnfryyZflTh2YfM3lveKj/4KfuP2BMQ8+le0j7B/7+1WPvl+ULB1zbbYJ971t4yCb1Hkt VzVw1Yj5LE9keu5z/u/gZfYhXrNsFjeLX86t4PlkWX+uJjKEGyldVjSseGjp8LKJXIM0vejy8jvc jgR1Iim8SwuFZKGQKhTKCoUEQ4V1sVVIFgqpQqGMWu7DaancniolpVxZcoCzOjE0OaxyWmxKYnLy attC+yLHXM+cwCrbDfYbnDfp15YuT67lNtjusG9w3qXfXnpr8j77A84HvNG8pdYrnnKFUyEl1QNM a9Qj5OL79U2hOcBc9l6rwneESTjps/eKliVxUvAJVHZYsedoLyUa9XFM5qXBm81Yji3dZVgiQ2WH tYTNXslSh90mxCNF0bAsiTxHRJwsLYE6UYiGe4VMSnb3gBzq8KFezE1nWlbHMTwON+KleBMWwYlo Md296Cvpq6HFo5QU6oF7UBHucJDJPWjT7PS+HqF+0CecclH1TU+5CkTu6gpxuyZRXgj2zbvtmfoT zGPoYPHOHwJxOng/J+jmFO0RkDGNOdNYZwP1JJp+oGKQ+e6BUVLVLx9HKi1jgzQsZSkfrfN6/D7e z4gUnI7S1PQX7TN+f9OS5yaOm35B9urxC+bd/I+fPfX9WmG/c/u2lidqBuEPpzbfsPbsY69l//kw /kC/5q7LL1k+dNi8hH9meuBTc5b8ZvaCt9Y47rx7zRVjq6oWlV+wZ+W1h5evYFmYfUA37GejCXeY doFEAeCITVFQ2sjy3TErJv+iGMOkkg5PYbwH573qL0wbEw9yXjb8o+C2/LUgJM4VhELWMqDpE+W9 D3f3YACcYJ2cyHyms9xBK3JHkyVYsqI7W8RvyIYF+/btZ/5JW/sEaH8aLfCgD0015ZzKT5Vfl3kf JQMf2FDV/AXycH6UvNL5jPCFU9IQMdrIS62i4kmRgn1GuuwzoudDNcfNCHMvMjEfjvnG+Uijb6mv 2cf57CxsUzAH1Vg+HcUSh2qBUtQucajyeZfCEodqlzhUM15qnv0gDtMZGvrJO52WNcC0XRplMLia lhXAvE7mgBp844HZ2bPv/iF7ZumBEdtven+vsP/czo+z5566G9u/5Mae2/XKnqsOsAxFpICeG06z c/BF+QwEl4CRzLS7igRFFjARKj8+pH98yKiqApjXscHmsFlaKeAKVM4l1Uqtj9ao3SHfoWzS2rWT mi2mjdMIT2wyyQ/XKlgDRwoeWVfHxlbgblVRYrLgkWUBAYkQwUOIoMCrvoyp4JnMkfEcIrNwQ3nN OBk3y5tkOMbYtBOzvGYGwfeQzYQQWmPEhHEC6QPeyCahXTgpCOCRrN9ta9xqeSRNNN+NrgHdyrkM BTsCVt5lfsiHjvhYXocHPItdyAmY+J9digvTHThmYNxZw6TUASmHywYwBwSxVHNmlNGEgziusvyJ Kkwu7vz92/im3sUlvfDGVzsPgFX6QfPS66/ne5wZTmEeREhaSW0L/JGZ6oFSRg9XKlCDBhg1rgGB kWiEMdI1IjAVXW5MdV0e0B+SH3LmAWlW6TgUTHurhWptqDBUG+2dJEzSrvDOFmZri7wrhBXajV6n 4KWeq0sGViMMj3V1DGt+Jj0p8KMcD/6hKAHwVaBExe5wOjWP2+Xy+vyBgLctV7tbQIEY3Wsug+7N aV5wP5BACPggHoxRQJDlqDfg8XoDLk1Rol4XFF2G5nTGdMOj64ZL0eSAV3AaOvAVNEngArrTqSiy TKBNAZfLMJAc8vtD+sUKHo9iSIOtF1YTCXj83hgd1AgG2/CdOy3DIBMK1neCO9kZCnYGxgybM/Sz Lpug4E5SeyCfWF4YwKvv7lyevwNOWufQDx6ETe3BQqn7BpDtBGQblCZcagD416KAJFRW/EABeYfV ATW7NVMwB1lEsSwDBOG2CMLtgp27CpxMOhyI8ePZG187VhoapGL/V2+PTUR6ffbb7DUvZd8sk/ye 7OvAq3UP3v/3Uu6TzlD263/e2cr9EhyazMbYnBFnnwLq6QEyuAWoR8PaTpeD8ojTblRfikfIlyqc KtuUArE4NOSwY1tUAzxHRaCDztq6zoN5Gkg/z2OOYMwrKi+raqooXl2u4u9BgMUwDxjm1XJbpBrT jUztUdjzsDfdtBZuEaKSSGxqVAMx8RLeA+3i8R4zjKQ+sgmsOkqrs2FbyIGRII5HQTuV44DF+lOA JxqIr60/1VSrn9DPdY0m1Bo1zLljCdFNFEOABAsRyxpYdgt1Mk2FlMRrcCBeo4D3uAdcSzDdLDut Px4wkGoCLMW9Pci34y499wc+dO71Bm5rK/f87FHbt5+T5m0H42NU7gs+wl+EytFA0svsqdiViqA9 VNHDXlFRYx/gHRgeXDGyImPPVCy0L6ho7LPBvrbHI76fh7bZveWFGGIZy7ampWeCz5XvDb5UfjB4 uPxt78fl8lAfjlJ7waAi3eX6YTC9P9Uck2mp2F8cSPesqK7ha3qO5C/tOUVuSM+VF6RXauu017Xv 7d+njYHVDszrlaXV/n5xT2BGjyU9SI9IpaPOcY9jsyPnEDY7dji+dXAOLT+/4KvCjINTppfm2zpY eotDpMkvDkeE87eR5/YG7vdEIhKiF4WYqh1WpvaLcLYeM/WZSGRaOBkvpZovb1h+bWm+Up5qq1I6 fkEzdkqpP0P7XkqDozb6ulL2otKCDi9tI1eYjjITpfRULNUntSMl1FD/iFpMYHC+v5cV+tawYEY0 Ud2npr2GbKnBNX7atovpE/3JQEll6SviYZEUi3UiER3MGWFpQmKAeSEsfUhkbqPoYB4JGzER+w7q ltwM5lZaB3JiuWNd6rS2M/3pp1SLnkjXdXSesPJ+reubLGPTypilphizwejIPmpKspguNb4GsqV/ dZmVtHERYdaYz+v1+PyJFEezN7wsZwYu4mpn71u44+URyy/tv+joPFw1bP0tq4paAtccuWP9c+N0 xV/ycsR/1cEl0/stXjD/yVTRrZOHP3/7mDVjPA57qDSpXtPrwoamQNOdo82Zo3pff/Ls7RcOwh+X R/Ty+spLG68Ye+F1QNFrgaJpPIrOEWg2f44FzVkq9BeGCUJdcUsxKS4uiVRFLoksLd5ULA521/pq Q5f5Lgtl5Ix9qjPjuzK0UL7aPt95je+aUHvxh9pR/9HgX91f+78O/q3oeHGuOBgTKp2Vnj5CndMU LnOOE+YKR4v+xZ/RNd3r4EGuhCMg1FRvxGELlB6xYd1m2hptzTbeGtm1MRq1BfKh4NMFn/hkIRpv TTuw0bRCFpWnNFBJ8WlbgY0qxFuRLGYSVnFJQtoxWO1bcAs+ifliXIfHYg5To5ESLaaJXkWUvDAj FcyMNuyipIIZqWAaoKUUxi710VfjABu6YwkQOBgdMfA804tSxTI63gY1YLD/UMnMMPizLAVKKWAI LENN8QTYYWCdR4lXR4mSMg6M8x/ypXo927ps51U7mszsP3718iJSPfnelS/84tqVLwj7O/91z9h7 3lie/Tb7/mP4gVcm33nozSOvHgK5Oi73BdcB8iqEp+UttGrHLU7stGE6QLMUcYh3RWxSIMLbsMMr ybT3Euu9xHLrJJ32XmIUfujdVy3v42CmH12pITdC0XBxZIh7iH+ie6K/0d3o/zn5OfeI/Wn96ZAm 24PqQrKAWyhcqy21N9uf0fYoe9U9mubT1mp/I5yjZIZzifMWJ+fEIGLMVX3YqFEjNGsT2oKOo5Ng YDqdNvRDGyPQ9FKHzORTSRj6V2pLF4NFgWkyD0WQybBzKcNJiOFkZMRbeljCxVKdRCQHi6qp9CKJ iVepb7j6YN5LAKxYzJ9Zlp8ax5KhBzV0LDuV7lhWGC01air1zAn4M18L8NaA/VZ6aDWbC9LlV1HM cbU7i7795dHsv5d9ecf2PxfvCN4ybf1zT9+28G58u//Fw7gIqy9gsmbHE+FFV//2nfcP/IRGj4YD zo5ZuTx4svm0Snh70l5tH2oX+nv6Ry4nk9QJnomReWS2MEeZ5WmMtBe/K7zn/jj4qftTz7f+vwc/ ZZznKy5Ohyi7jg5R3pV6k1J7b99g0t8+mgyzD/eMjFyuTrHPs38qfu47g085dOzlHDbdCRxpkwwE LMnZAlUYJQ1nUtePGFg3TKPRaDaANSlNWAxquCjnGExpUVY1REpBBmNYg7k/FOKGg0LcKIx/GNRZ uYRix1jhKn1FOiwdk3IST1E0VuKkKCM5JqelqEWKDG1MLUlM+0jBaPW47jkGTfUdnd2Zjk0Lqz3B nB26/sBnNIYf709lMQhjC2HAc7h7kuKgOQdvee/ahe/e2vhA5e7O2AvXrvzF1huvf2Lt4xvPPrUZ cxvGX0wcZ4YT11tv/ObVo28dpDgbDVI0CnzmBZxNNP3FKOIlk7mMkFEm2+Zwi4Qlyhyb7LXm8jEA nDAn0FJRhOVLuz4UznhOh/i+rsHBvpGLXfWhiyPjXdODEyIzXYtDMyPXi9d7T5PTAR35sNPu94/z Ub+R80Wcm/QtOtF1PhxRJbSfPEcptiDN2oEbAO46cMf9buAev2kHrcscSXthgoO9MFppp9crZRXV LXZsDxXTQd5kqpruzYupmi3Gxb4qvVQySyuqC5iKdcNUhGHKYrAIwxEbz6aY6i4TM+n6zhNj9KZ0 +nRTl0NKB3PzCfW1nU21+UzMfOIW1aDLCixmBas9Upz5qjjO8rRF7sr9Pb/Z92X2W+z583vYgc99 oe66fdbGzqNkvDZoyh2rt+Ep/qdacTEIew2XZz/Jfq/Hduyfj+9fO2T+MyBF3IDCZuEd5Md2M+pR sDNYGewTNINLgz/XHrVvs8she7m9Jdge5IMUHuWh4uoi2c5pzoiKvSTtcfOciNTNHuzJuU3en+QR R+7DbMBld99B1WzgJR0prt6EcNCkbBI07cAmyMOiGuUsqlFCGQf1zMcz/pEPenryQc+vmNphQ6Bs 4lZb7gzLgUdPBYIv4/0ojk5jFQXS6dPpbmxAx2Oo0Qy+a0eGhjxq2byeGsNK8fDohqhIogwWkq64 wsgQnWGcxumKNWtwGvhkWZWR6F9Fc0yBTUCsUanmpfNKdm3e7A7duvKy6eFB/SYMPXyYe2Rj06Lq 4Ze7HlOHN1618dxc4IhLsuO5r4AjoqgCLzEbbTbB09OW9FxmG+YRlaJgUU9bytMzUWMb4BllG+6Z Ik21zbedUf/ldfRO9Cy7KHFR2WVlm3pu6SkNiA/oUddzuG14fFiPSfFJPRZIs+KzejT2bO55tOyL +DeJb8sMv0/0tpGdreURt8Q0iR5DfZgeaUbt6AgCs5XcZPYTIhGnOqwkoqk+b1WySk0GAkf8WPeb /kZ/s5/vCSAnk3syseZnYs3fJdb8TKzRSQWs9itLrNGr6CSDvFjzU6NgFJt3sMKJk6ikuPQV52Hn MWfOyRc765xjQdExjnGGKG6dJSzRncWDrAkyTibbnMF0zxVxKt7SY7qJt1Md+o8kXOeJ03Quyon8 dJQTVlinCZSSn6aRMQOyDLiGWHLO37+QWNA9I3vuDlu/IStuWh9w4JUtH5285o93vXzDM3M+2vLr rx5+5qbVW7ffcP3WqaHxyX6zpw1suRPXfvwQxhsfaj638LvD1z/PVfyx/ZW3fvvqb2lcYh1CHM0z 8+CZ+5APCN/rr+ao28LM6yTfnxvG7bfzrGqwP1jtlw3N8HACRs6IIHlsqpZUzKoB1TkFtyvYx3SM z2SJfeVs66EoUKhjYbAUP2bbKSF6nULjzwwlioeiRKEKhk07oUmB7Pj0XjaIP4YF8PzVA6pbfCd9 ZKlvi6/Fl/PxPuJJWgOkOrThJJ2rGwPKOY54NqqUH5w4Y/oZl/KFFJ5uw6RnLHsQEcaWhJmcY7wj xnUbfWLzJdlYabqbhciq2XxeZg7SMATjTofokJIOUQtjuwx8iejw5RoETG2l+bAYrtdIGAyNotdY 13pz+8pfjm69dtG4u2rBJPzHfZmnH+2cQZ5Yd+PEu2/qfAl4cj0gqpbl/kjokHmlMoD2YKyySdmi tCjtyjHlpCIhpVhZqjQrm/NVx5WcohYrYGNJPOEUkbsZI1EQeVWUkgLiN/Nb+Ba+nT/Oi+38SZ4g PsYfgSOet2xlMpnvghvP4Mar9K08k2x8QbLxhcgtT5lIpTDkx8g/ht4y9i0ACqnuXwHILGtKs5R9 gMr61tZW/u+HD5/18qmzR0Gs557MjseDWZ9d6D1zGC8khQv4KmGtIPhlQZB4nvCCG2G7jXAejTcE m0R7aBOliOHcBBLd7weutCdVdZMNF9vqbGNtHE1KMQfSHuWTVJijYGM+pS3KPBONdsomM5+E8bYt 6PZsj4/oztWMi2ku3hidhqSaUF099QlYCl5X/4yqqnW6bOWYOmTdmZJ1NYwVhxRGFkXQCepVXjyQ sTSN4tJ5ZWtbs/NLBhQPHNBadfGDI/kv//jH72982DHyPn762S0H62dTfgVa4L6j2XBkphkWLdtK nCJOUzin/Z/CaZFTCsnf1gCkWigohQLLVmADmJO561TiEmPuOI33nNztKqtWqJMGe5fAKuKswrwN akSeF3hxoDICUCH2Uqeq13HXqke5v4nSMyJOiCkpKdeIg5Q6+1h7A98gTpUalJv4VcLDyqvi2/z7 4gnxS+nf4vey16WqAsfxRBQlRZHhQJHlpCR6JEnkeD4pqB5BUFUgWJ4Gj3mBhixtNqTybdhpKgLP oislMj2Kx5h3oFsD7JvAALIlEUmCr4hwHRoLnEPzvvoy3mcYR1aaGqNk5GISgLkTiLkmKKjZ/xIf Mbc7rhmq2UhO02k2kpP+YVwSzFN/DQ1d0XmgsA+wmbYSoF2u5dg2H5Szj1ZwsXIbR5SAnSZQgO9h zRk1VaVnUY0iFxXVijTnu6gGdu/uirHdznh+ZijLXmlC6TQbwhRz7bviLNFil4/uPtml14jWjh1p bLfTVsh+oQE2+irXxzyWPT54m8dTyzZ0mHdXgN789c6wdTnONFjRDzoExeQV/ThBAkvAofi5L7ML 8SufZJ+4Rdh/7mXckl3ZOZsU35C9gtLlrbAZyPj1b3sFJqBYwuHAQVbiYXV/a9+nr7W3vjfSbiZB 3TiFYmGzcEzgx8LmpMAVC0uFZiEn8CDNVcJZAp4+iQl6L1g2mxFuBzeTdJf23/0g7Yu6SXsL15Y9 JueNscJgUy5XGH7Kyy40hj9fdlHhRUNHVrIiZkf0RyFzaytLW7R0qJgCmymBX6NJSacKOWanCt9U +JNZb7NXJ/kT/AnlL/5PY8J7wukY8cuxhBIIxxSOS0QjopeaFBIWE6Ggrh5J4k3JLUmSBDnmSG4y sMEzjy3AvDUWpmMem4d20mCz7GlHDcL8NibGDBagMwrZFUYhS81owxlTCyQ3hXGYPS7c9bgwe1yY ZvoZ9HFhpiXDzPEOU15iyjms0QeHC5G/MH2eD5GqRBIfQZjGAEgxovzHMf4r+g/+YxIX+fIa+FzB Rj5lepgqtlDhsFiyNNmGr9/9YwlsxWc6T3QL2XQL9cFBJxsuaALvH4xnUD2MiQ1/90xph+Zxpzya EcYuu7egqPOuC52HzYZb/WxmHFPXzI7urrif6PfMwpUPFt/8xuPP7U5Mv2jpz1qnzr5szWA+df+Y GVdN3b9jb2cZeezqGYPvf7rzQbLr+uvHPXJv54cFm+szoBcfvsl0C5zoJlv1Nv1v3Ofuk9xpt8hT kVsLBLNKxw/pRwLHA7kAH5M9Do/PBTYXFn121e7QHKUBZmcFmM1lY9aWjVlbti5ry8aYwFbCrqAQ ZtaWjVlbcPy9hVCbmo/GnTaZOLQxg86G4W8bE6BMF6KWV+BkgCwNbAm0BNoDfIAjVV4f483TrYaR T0v9Xw0u9UcGl9HN4OLznNhuun5swI3xs294dP3op2qYEXZebZol5LLkNdDBXVaYTzQUVVYllRP1 lCE6wtipuvJIponsTVQKMyzno7jdULzuyWs/bnxinK62Viy6dPmzfOrBHcOW1ve7qXM5WXvN4ovv e6uTzXQZmvuCLwMs2lEQL9rrDdCeuOloAfMJKEsup6UgO+GS1KA2QrxUniI2yPPEBbJcrQ92Dfb1 DwzTR7tG+4YFpgvTlQl6xpXxTQgsFhYrs/XFrsW+2YHrsFcRBfsV3CRhknqFdjU3R5ijXq2p/ggv GSAyPKVh5vuEGRlIXZ8OkVgwJx8ILIReWSGfmWZNk81nr7FCu+kuTVb3kTCSdCkmcVLfYyAjaP1I GkqAsqMUaQ7q9rIZZYjFGlGE4ZeFEPJcy+QPYgnXyIRHUnFAUN8QDSnkP31kYU5vSmdOZ7ql8HRl vdF4Dxv7mShMVK4SrlJ4qpvoJW42nRvlJ3d3d4qGPn3H7z7Cvhv/fuexbMe+XevW7tp9+7pdxI3L 7l6Z/Uvnob//BEex/a033/rj7958Axq0LruAjwMGXSiKrzLv1vRe+oX6aJ2vi7XESHGsh5Yo6uft V3RJ0dLYppg82D84PMo/KtwgX6FN908PL5QXaQv0xf5F4fbYO56PAx+H3ome8JyIHo/lYr4En9bT 3v78YH04P0qfpn9q+3tRVrcZDs4XoaFz0Rdx2JAjWHpExbpqqo1qs8rHGApjZj5l4DPTxrIIAoUU goJB15WXbIXRVUprCZZOsAK7q0iVK4nQ/x4xLwTK9W6Bcv28QPnpHwfK2UAWiEgWKC8eMTCAz4uU FwLlPw6Tszi5UdM9Su4uCFWf10O/upMqM7hu2Fv39OD75q8/svDaYzdOu6e38czK659/dsXyndkF wq82jB+/MffQU9mzd142uPMs9/Shg2++9+YbH1BZejuw4quAQwO9bl5Q6cY6jxN8NT+En8jP5Vfw omLIiqzY3YZiR5yMbQz4SFXKN8lYLom5sZuUGP9nH7LLqvjONLqJNJGR/Hm6y3IjxW7m5BjXiIP/ 4Uae0DOnltEZSRQ6NYWPiSD99XUOlgqdWUZnlFmAsmI3Eoik25+8aEHdFVdedMklF1zpifKpJ5ou Hfxs2Yi6xmWd71Io1OW+4HYCFPpwfvNGvsRTMlgZpQwtnVIyp2S1crdyW+kz7ud7HuDsij8U8PcZ 3fN9vxAmkwnR+2E1MF2erkxXp9uma9PtC+WFykJ1oW2httDemmotc9Lko9IeA0qnqQ222anZ5SsS K0qbS3+qPqrdV/5gz/v7PK1u054qe7p8d+p3KV95weYpKRQShUJpoVBu+SH5a2ghUSiUFgpFNEvY Fa2ZJpclNZUPxVJe3ta7KESDRCXBniyOHawLjg3OCO4IHg6KzmBxcEnwWJAvDt4TJMFfAW68QBcs qmp66OU6TYXX8RFwKbCO2WyS3R5ftRVtdRjVGPeeXnR1ESmKeCXeGuxkLvBnBTf3M9NNEcxHetuK QzhUGjTdgep+9PZKFhkMWFvKV0H2Fa5gjN4ZjNG7gsxFCbLIarCNXLFLKq2AW/dEao5U4Ar6FnpH RSH/ssKakyLSwlfsuwYVIfaqeFlFdWO/9n6krl9zP9KPRohLUcCyrBjJxSwogxChBdqAGPv6Am1E rNTJWN3JmueMsTAW1ccx9i0HNlsiH9AqOVZwoIJ982HgTFN9nunpJ5l02C0bkx9kTaebus3pTVtj Lmn6OaUmNshKrWaa9kZ3XfPV/JaeNst6RROCp2fK0F26W+fEEnssjJRyKYyFXrCJeuAw7kiEUUnC rsk9wIkuL1NUMc2HUbFeRDW6NUuNbVgyQUV6zZo1qJuAopGGTNcHXcpSZb1J/+oBA/8jnQ4WmkPM Ym11u5x33Lj6+v7Jn7768NiLB1XcO/GmX00zWrTlC1Yv9Pkqw7e98uCUBa/edPhDfGFk0bI5Qy9M BJL9Rq4ZM2JVeXH60hvnBSZMnzAwESlyq6VVF6+ePm3z5S9QPi3N/YNUCA8jP53LptIJWqlq9kHF i6HQHMQIa3YVc8inK2mnCkqCszn1ElSC7a6khnOSPEwZ1igtlZqlTRKPQEdvkVqkdumIJLJ09Hxe +ilGRRJNuGMDg5blny/kM9XPMOqg2p9qGRpEyBsBlv0i7ScLUQAP2Dn3R+4Q+4hfZ61+4lQtG6Xp rKVC3qiq0l+3knGTfmuQhsagjYHse0YsQ43ooctqr7q652237d6zx50ujz6xWb9ozpNk1kYsXZ29 a2PnT+t7hpgnCbLsOP0OPx67D4Xo6Ab4iCTm9tFk6JNmlctTnXbjUtnt07DbZwNhbgCYUJUvGfBT wzXErGI/s4f9LhYA7kpr8DPx7e+yhP2efCg4H3f0M9fGTy1hO4VHzo/b/dg/JsQ8T2oEh06GyNLQ llBLKBfiQ1pS6VIc9Lt0MeWIclzhlYLiULoURz7uqbJoJ30+0xcKs4IVFnZUxgTPcz5pePE/zV3Q IGwMurYm/wkYYKIQrzvsTjvN7qJTmcHk5bUwssuGFWyqqFgDKhjuzY+flaVYwMn/w8Q1rm71e1c+ NVa3tdqMa8aPv/uC1kdbL108tv9ycl/n7rv6jhg/8Z71pObsUcBOiMaLATsq/io/Mu0XZKTKIha7 UgdL2SyXynT3DEKWQPhifwGjEqNGpfLdbtQo4NBUy3RDQNLthj3O71XqNCvReDUqhw2zcJSSZDXy wQaOjpo3l/euRjHYOLUeqFxJqTWov3opGqFOwVNIgzxVmYvnkgXyAuV6dB2+jqySr1euU9fhdWQt d4e0Xt6gPIYeUu5VX0BPqr9CL0o71dfR79Sj6D31a/Q39Sw6pfaE7qgB5FPLUUodqI5FpqoIpstX LQCpVBe+f0fzJkVqUFCScrJETsRkKIUFrWOGE4UKqyWCoNlo6snHaYANrIfSh9KosivBcqAqyXJS UT2KoiKOkKSVeSeoKpgsLI1OlFSFQ1io1LBWIpumaX2TFYf3mEKzQAQomUqMmLjE9tXblJo6QsHO TGcmFOg4kcl/KqUrgmXUnD8Vi+Yh5zNffvhZeY4src1dhfEvs1f/+kSyOJD+el/2Gj7Vedu8JZNW kvU0aouRiJDwIlCHiy8qzCd00cEYJn2sdCMxb82+26rZmYr9wrTRkhHTrBPtrQ4r/AyqlZYMkx2r BoeRBtYQFp0ADbvGPmehGZjwKm+o+TiIJegM+vGeQ/r7h/R32dTCfC4k6x39UWYIAwd6cAXfQyWj jCuMuw3OiFmfjst/BIsvFAwqdpTieLUeKbIipOaLxaXVvKgpbjGsBF0Cj3jRptgcsktHbs4jReSw rQh8paRUIacd1ai/NFi+wDGUGyGaUr082jbEOcIY5brCOcG1SJotz3OtEm+QVsj7xP3Ova5/iWeV cptRjsrtZY5yZ5mr0jMIDXRdJ6+VH+Ie1J7FW8lW2zPaHrRX3O/4Pf+++KHyBf+F83PXKfGMErGx eRoa2+qilRDGVDrbuvJkG1YdTt6FDFmSk5Iz6aAOg0Pi7FhL2tty75sDqZSyA/VVMK/Ajj1uUbUZ KTVtTOInqNONq43VxgZDNVQeaJGiw0LMj9NOK9OnKq1kd/0EXSztD/+w6eFYOqokKKoq2zRN1Q0D 5Pvo3QJygc0y0pyrOh2x3xqSHJMMlystSB5BkByA56Td4bHbHTJ4uWlV9sDtNEc1zymIYMnFy05D c9hZ81wgx+m3EyjruJx0HpPqOa3bMZ2m3Wzn7G34WVONjVXxEvUWlahtZLKpjDXwEuMWg6aGTzZt uoAbWUSSA+Z6dg8+7T49l5lEwfpTmUwA7Br4UybLBP73/NQ81xls+1+kp0oOvZau6/LJkKNbiidO bbXHtBh5OXccbNrjyJE70or6OGMuoNGuLzo1jG6pnshm8B7ZKdEPPUFFfOLoliqWEiPnju+UYlat Kz/bkk6IObIXTEF4NkirI7ukPvSJu9Agst96U9fDu+7zs/uM3PHdaoyPoUH53Nf89Jp397pqUE9Y aQDbTYPKDQU3MW3NzmEzMalAYfLE7WdJslwZh0dnX9q/rY6v2rZvc/8L9+7Itr60rccHIGB+fsJ4 g1zT+dCbh8jcs0fJ6j3nDoOkcYIe+h+QNDr+c14PeZ3YJvJEEYloB4p0MovcWZlmRMm+gRJ+0enC zpIgi5eb44I105wP8A/IDzsecbYL7WK79KZTcZq+mhDnVrz2kN4fD7atwXfb5ErX5XyD1GCb6ngQ P6Q+ZHuRtGm/t73heEs/yr2n/NH+kf6p6iowl01DLsMZsINhQWdUmQ5acoqI2JGqEpFNs6QkAWLI SsudK4qcJCsKFkVF4Dkw+Zygz+3Y6bTrNjAqiN3GaboqOolT1V9FrypETyLFg5DCEfurdmxPapxH 0zhVUTiOiOAJaBpSx7qwa6T9Zq1Edc4UlZtNFTTDi6Y4Tmxmn1saYjpi3M2kZCzAcqSx+mD+S6JM WYCu0D/VT3WwmeM/0DPL0s1Tayb/0cQap3OdzKjU2sKOkm6t/P+1dx7wUVVp/39umZY2k0rKJJOQ QiBCIJQYQDKJIZSohBZIRGpAICpqEOsL4yJNwIIrKiptLQi6DAlCKO8b1FWEVXR9BXet2HZVVnFd dRcwue/vOffeZBiCUXf38/98/p8hfO9zz7mn3VOfU2ZmsFEpdkYlphaFi099phZFdO1SpAA2N2QU ucTnJuKLpK4ZRQ6v2/z4VV61WJ4TuxEYcPp24aGnkPchlG6SU7qj9aEPf9PLfUF241ut90or33t7 YOvncq7UempY79K+Z1ojWo5II6tbr8B7ZbSOVr5CHUmW/mHUkdSwOKcSrriTnDHWcGusN8aZHu6N SDfqSlJ+XvJ7yYmvJie5WIhJuhg2UhqdbsnJL3G1uyg3rsq5PUzxRnpRIOm5vfu5+GKLcMQkRCbG dAvvFtEtckDEgMj+UQ9Fh+fG5MYOT6iOqY6tjp8TMyd2TvzN1gWRN0ffEndL/JLIO6NXxayKXRH3 YNiW8P2ufdF7474I+0vcd5EtrlNxmjvNrFEJseHuFNVZ5rzDqTiT2pKvLyLEtB3xL3Q6I1zoK6E5 JMXFxmbHhMXB4IxAZ5gdHoZpcFgsH04Ot3IA5Ha55Xx3s1t2N8nFzzqRF964JnmcN7w4xhsjT4lp jpFjmqTSXU6pKw1NCeNHIre86RG9I0ZFKJURWoQcAReN+U7kjVy8MyX9NnSMyLwW/t4tVCL+DHii 69tPkvj7h79MTnR9Ke4okScOZo2yB26ecZVaJuoPer0o9DaJ6G32UYT2GYVrn0mBfU2c9v6uwqKw roVFUWhlz8YXRRsf4KtmfZmgw6D6xHbTz1MUiiP5hgrDX22b2XVR3KALBg/vEp1jCW+9+vn38rp6 8j7e2XpVSVbv26r6tV75lCs3K6XOmarmtjx0w+23LZDrzry8vbR6LGs5ueh73kS9ipK2eyNjmuRD djlGKojpwruoR7wO3EhD0sSe6vPekbjpLuc68l1FUlHYCKlcLrePcIxyTZLGyePsNY5K11XSDHmG fa7jVmm+/VbHSmmJfYXjlPQtfxVdjtTdnucosj9uf0uycWvZ7YrvJ6N7dfCXzGZiIi0PdITJ9rCw bEnG8CdL/DVs8jRLHl4xbFok6d+SLEbzvKgwuUly7sRgaLHuky8nIhsvW4ll4a6RG6MkivJGTY3y RX0dZRGnyrP4UdR8ClsoSdtJGkXzSCOFxNeoUJLTNT+Duw3elTF2SVv45pM8cXZJfAFe3mDXp5gi fiqO8Rmqpivqd8bXO1x3hVDHUJrPdpdy7Lwoo+eenfMSpud3cy5yVupfSHNdtXSFKHs7ug+n+DSA Lj7bnVLksCekXMTKWUOXIjHtCksokuNAckJ7x9K3v2TN1D8wMKBvRnyu/Fj9xNZRSm3Lc/Nuniud WKPYrWtubJl8q+NhLuc1RGqp4sc7U2xGdMYaxf9DJcOr/w20Qs1UTlMkYZIlFQR8ceKALrw9ZC5s 5shz5725oLV11+7W1gVvzrvit9OPPfDA0em/VU5f/+b1sJPk3fX/e/0lk/2THzh27AEIxNsedlDI ct017WGdHYL4ySP+CQj57q/+sN4xxTn4O3uKXfwS0uaPu/Vg+VLvhntOb2+50kX2CPFrfJLwIfzZ hrReRhe76PT207e4yLBv+xfZ32pY8e9YGfjlt2iyWk/xYIQtlW60VNFEaRnVyFvpNkZJJa/6NF0P t1thLoHcy37hfjz4AAwGVSDZsLsUTANj2Qy3e9gvwriWwxGynmrsHppnqdJaEN9ay0GaBdbjfrP6 MW2xFtHVMD8Gf80qUSG7gZ+11q30IOwfwfMZsFsPORHmTbifBH+9jXuHbTUlsQRW2HdHOCuN9+2m PEcD1HrtQ7xLNcIcCZYijkrIclABN7GQpWCZdJCWSwe1zXgOSYsR/zK2B2WGHI5wluB5MfxlwbwY 98lIhxXSCTJArvw0oRbTfsh8vP8E/b3BQZrN79z2Tki/kaZz0dNYEQji/G+QKRdpn0I6AtIWzOIg Rih9yQdZB1LAaPlVulq9hCTk10OWT0lhUPM4n94HF6m1dBnMEtI51rKT1rEZXCqo11rUR2ij8i1d iGe3WNfiPWqR333A95Qv/5V6WrNpEepXGcK/HaxHmJ+J+lBL4xB/L8i+6qeiDi0FqxDXSTOfOG9g vh3lOgZx/cAtAv7HgmEoFx+4itOD+PM5z7ncparWIrj9BG4mMbDvIsC7c51kP+wfYWUb9XBzu6TN cLMa+XocUgXxnAYTUc8M8OwlhJMErCAV9AKfgs2gDgwEFSAXcRPiVUR9RZ3huinqB+qG5SDyEGkT dVZ/h/WiPPU2s8kIi+PJsD5NdQYZHCa3F66zSMsOM2xuU1xnTCnqd52o91/xe3KdapNoe+oJGsZp EG0QdcuU3O6QZm4PazHxXw65DvV4MddZTp8pOV+4rok8QZsw5OCAd+0t2ggkuuJMo64vNqWZF21y Nj2GMKdap6NP2UjD1fk0XLmXpqtfU5nSnXpZesMO7wO3fvkEjbEfoL4oy1EwPxQkH2RsR6W5lgN4 z23Iz6P0KPL0OvWo3FU9Klks27TPLSQdsmyTF4r7c2Qw0gH9GUsm8NnPtf8lyMcs29BnbtO+sBzV NLzPGm4TthNSb5BuStg3AB/oYc+THrTXSU228eSyEn0L5qleGmjxUqF6AOUTj34ebQH24y0fUrOy GuPXUe1Pko988lFaaounafJa9GmISz5GixkOH/LagHp0Vp0LrkumNOtrsOQ+36hTHkgr2t8Rg08M vgffoR5VoE4m8djA/bMYH9BHg6V6fdVOt9XPQ/Q45EqzfgbV07qg+hkRXC+DpRhb0L+b7RTpWGG+ P/eP3MdxH8n9HPczpvtgGeD/Tnkr6jH3w69SjdGuuxqMRBo/Mto++mGU9wRNs5ZrT1p3aluUGG2L tQD3fwQW7Um8901tY+pErdUYT7ubY6luT+HmOGrpS1cb/dljor/5hn4txtEqkT6HdTstspxBuaMP FOndaLRB5CfSXadORZ6vo1V4jyRlGdoj7MEkzhNRFkSJPC7wmKjcj3zmsWg1LVbegb7AfvtStBgv imkC0n5I2GFMZcl2lgm02XqCCtTx6GsPUC2XFb8Hp4fL3n4DRdrj0U8cpT7qU3ATT2Fwt1HkgZee FPWC/dZBpUJe2GaQDXX2Mrjh8DYJP16KMfLjMZEXwj90Ea7DnBcI0xpPY4Q+cYI2WMbTBLShTTYf bYIGTWgXWxDG4/A3ntMCf8livL6fLkf7Wo6+aTn6HBL1v0Y7o2zD+9yEfh0oPuTRNkq0+JCHdeLd y1S9j13G7UfZSjlcR6z3ox9mfeJ+ulPNo6HWOloNu9UW9JOIdyXs7kD77Y22uwL+PUa/TYh7BezZ bzHrMqwjcHuxeSnW6hN6AIk0sJ6C+JXPaZMykpajHpfY70c+LKGeqNKsNKaBPjrCvNBglY6wc+lS ylBc9F9sL/elNxBDOJHGY+ge9Xaao1ZRgdIHbTeaeqp/QFs9RQ8rTpqiHqaH1SZaxWY1lnKhsVcq O6Fbsv1rVMn28hswP0g16mD4X07XqFOoXtmBuvcmhamzUNbwZ7kL9SQL/r9BuAbSx1SjVKFtLcX9 Ke1pdifi2KlNYNTh1FP4C0Ck1SQozXIF3mokyhTp5fuz0ou0tqXTTGMH6RPvyeHCH7tRH+Zf5tHe Bdm6bB0tr6ZtYKP8Nl2sXEo3S1u0vcjX8iCGB5rV/tJtoJfan3aD23F/AeT/gO26Gbpbf3oHLEHY z0E2WsWiv0RyKQ1gCbv14EHwe/NZIBxPR/aBWFK0vWeZn8VYA6Rvtb1MsHvk8wDEN0C9SNvLoC6O ZKyLKM62gOKUbrBPg78gsyUF7elZylJI+0dnafox8K93QD56A9/RLA/IhJ/AuwEynaUxNvzitP1S UL6LwBUif7+ieL0OUZR0THsXsko6Ri7lBtRBAHNPmGPN/DTLCfb3Cfug8kNdIc7zYPtgc3C5dmaW G2lKIGY9aKsPa2gIoxbDPQg22w/REMb6Ip69eK5ZfbITaqiHso7ThDrY7VyzdRR1Y+QspDWZ/aDN gTbza+gjALsV/iNpGMNtl5F3Yr4G2p73p6FMQL4O4HxV1unPzfIxyyW4fJA+r3qERkDmQBZBjoUc acrANhvcboPtzL6kIzdBbaP3+cL8/wm0ncPgIHjpPx2XRKirwAWs70IPKYYeeRT6yeV8Kr8FfckP +eAJ9EPjIN+CHUbv1u4gEvfRsLsS8lGiM9/h/nrYH9XRZDWFNhp6ZRLsdhl+7UZ4Y3X/Z14mOv0t 2K77P7MVzMX93wDG8zPvQT4H+SDcfwF/d0A+rz9vmQLzArAf5hMwXwUm4v4eyHjIC0AsiIH/tQzr I+fMQ//tsuP5x0+V0FlmIJ0eXvOCvC14DvGTpVmencjguYZZ/p3JgDWDIKnnA+ZMH0Hv8wfOfX5s jmNKlGdrIOp4rQU6ZQTr0azLsv4s9EdDivmb0GMRL1GcKVl3Zv2VdWfWXyE3iTUDi0jPeJ7ni3QZ 40Zg3yp9S+uBC6QYsg5uTsndtCPoe5yo399hbvQYA3MUqNLRXsPY5cRY14x+9zvIV2FOhfzOHNPM vvWcPraTMe3fbf65Y+QvGFMLDKYEcT57kwsNRjDBY/HPpbOx+xeP5ecZowPH6X/VbI7zJo4hVMDY vNpeJlgvPUcP6MTcmZ77c83BesfPNgfpJaY5mHOeB9c9U59JpuQ2gtrdz4XnFuqz7bq/mYbgdtzW 3gwz8mhoIOgHco0xdDP6C+j/WirAGKWtgd1C+w9UYH+GCmB+FmDcbP0SspafQW6QVvP6Nv9SU+uv YHaprwq3Ew1qO6vPwfWW9XOhHyLPRD94D6ef8sEgEAN2gKvNsuY5JOL+k4xRl+e5ao32nXoEBOmA ncr+dB14BmYnzE70xXHWaPTbXnqS1+MhwyDD0L+Pbl/j01qstwg3I8Xa8nwajn7+GvUor31pvxNr eq3E387I+yiLMYZ6zHU6mON5bciWzuslWpOxPjfV+g3GwQkYDx08diDeKrEnVKfyOu439GslnMqM NeQ4cy2Z16d4vLL2gh9exwhcR/6Y+qiTqAwUq/o+1Xhef1E+FXs1y3jdXbmM9hv7W/6wrbTecZDW 22up3L5I7DetVR6hxbB7xHYXPWLNE/sr481xlcfEDtb+eC0zuW1N03jnYJ1ApG8SXcLrMYHxmv7s 5RhLvxHrUPo6Zie6Dcb4O0Gtvl+hfd/xeqf2irHuOdsY4xe0jfnB6/STaLSyEPM+c032CchjNFld Cow8Dk6LGRfypeV8upCpm+B+gljr0/d7eA0qNmAfrlzk8+eivEZwmVki0YadXP7aHlXfnytVb4J7 mZLUk0BfexT7c7w2zGuQjLwebfQatBXUQfU+sYd3hwHcak8If1fp+2bWsaAY6ZqFeLby3pEJLWlH +0QdT3cKxLqatlmO0/ZAXi//XuwxOo29wCR1Fcp5qliXNvcEE9VcsW6dq44DKH9wM8xZ4t0NKfLK C39OzOv4HXltrhcRntmVQcYaqeHWtpvKbV7U13AqtzRSljIP+ssB9HVulN1IlKuTFisfUZp6Ic1Q oqmWkcq1I9IJSGjqjPwF7P8Eea/4ffUa3hM299X09Wk6IzgMXQEYe7nMTEbeKmUY+4TVxn2qfg+7 ItolMMPYSk8EAHfaR+CM/GvEXUq1chPi2Ii0IB7FhfYXBPxMN8g14hmmTkAbO5uLg4FflvnBwJ5l djCGfXIwsGdZGgzsSztIx/ncnS8d57PPCQb2Of+GdJwv3MxgYJ/5I+mrCAb2FT8jHefL56xgYJ/1 I+m4LBjYXxacDvRPmMe2voS56dOQfzTG+88hL4FE7Wv9He4xv9BmGeY/Gu4eAJj/ag8BzJW1UgP0 eRrPgZdB/hVgXq2Nbqf1EKRbP4dhxqPdB3qAKj0u9tu6T49bYMTZ2qj7b3nGSG+AuTUB/FmPT8TN fe9eyEywznC/3IjXr6e99b529/yc31H487ejKWAMnnsgx7bT+qyO9gLkbwGvix4ELxv3aUZ+8Dvv 5rDa+wU6LfaKeG8HY7VtK5EYs2+lS0Sf+9pZY5W+Z/0xbRH9nYa+bzAVWCOhhzxKpaw3cB9umSnc r7TUYmwi6CdVYj+vTj1OFvVFSrJ8SlPUa6hM2QW9eBj6W8Qh9mUQNvfbrHMoK+hSIPYqxZ4Q753c RMvCdgr9xQU3cepfkN6HqBlztuW8f8b9ua0XzPfgXTbRTZZb6Rb71dRs/RppPUqzMF55rFOoyPIr Gm7Oba1Xk8MSAb3AkOESzXC4Yc9nE/5MZY5l0Otep0rkWaEZd1s+2CgO9k/o6yutyLlWlP0PeeAS kWakF3qYirl1nHluwHIF8qRWpOcysef0FKmYo5PlJMbuEZRrc0D3yqfljkTaaP0e72FFXHkB5wV4 n34r5diupD6WZZRjzt2tnyCfx1GYKXk/zlwPgO62SZ0t9MUYsa9lrAe0STMM3m/z0So+KxGs15h6 VJtOYawRtK05mO8DyeNn2/sbMkDf0NcUDkA/jac83scTayLB0kiT2Mc7gLpk6LO2ZhppUyCfoFnW pTTWcinyJZbG2l6gGNswSmT9zGYTet3VPEZbTkEXHUs5qPsXG+39RsBtaZjRxufD/i3wtN4euX2x vWibsGtZZ9jPBbeBOfpzfqYt0u9bTurhi2e36e5b0A413oOTA9ZqPtAR85D0QD3VOEu19BzZvnfP 9ae8U/kT19C4DfOZqg72+IPlfZCzTTP0vA/QRtfAbzqwmnp0sFT18ykLdSl0Q5aPG/I3XNdY1wuW wedXznee5Uf0WL2dmfLscy+mnGzInLZzOZ3IwHMy7VLTDHPUT127M9bckk3ZwfkDfU2uXVrPmT8F SlEmpBh6LOvvI8U+P5/N+RHaznD9CnXgbKoYPk/QEVaMJIztqrMx9PzzYr0b/oDdE4z2dwZpvl1H e9jghMFmRpEwlwbqvcFofxd0fL6uzPoo4gX2njq2QzpC//8RkAdkQwu2xwhp5bHwR4GWwdhOGqw0 0TTGzHczH818wbv9Ge89uy3NZvxGuP9qOf6r5fLveu8fS3sgxhk9U/LZPWuH6Ub5CP6uI87SbKVY AyvydR/YBg4b3MegrSTzWSVlJurTTHFesc3POfVgNeamjGE2zt9YrdDsbIl6O+CzPzpU3VH+2Gbq 9c/WTc8ncW5H170+xXtEGmdsZxl9X5ajkjYZ52Q93Ldg3OV23lt9jmadrfNpY/X5tLYZ46QF7qMt 86lc/r32G8st6BO+1l62LIIuABDXHQaHDDbqup+23TgHaRXngbfSU4FgbpvGsBvEVw8eN/Rt1mOv 12n9i27fni6z71X+ifc4Q0nifKlXzK8r1TmY08+hJOUEnkNf4P0mZRqV8JihDIBuxWdubjLOy/La w/uQOpHIl0plS0D75vM1fK4GiDM5XE4vYQxg9y8J/+b8PlesL9WhH3+HPOLsD56JMz0Ig886sV6k YEZhGYV6MRpuR2t/UB6EHG7wT3AN0ltFc+Q7qKcyC/Ph16HvxMP+OjAP94mQTlANHgELqI+wP4N6 chrugaLC/AqkBXN7C+xOGazS4edivr2LaqET1yI83d1R4UfHSrXS8yKuWqUU4cGdjJmSAo1CiTfu rXi+BP6a9fk7ryuwe/HMdONod2P5ksrDZlG5NRas0PZaSrS90uc0WK2haJRpJOiPsj5izB9Yj3oN ILe09TAfloPPBZj75Ia0PENzLBdRT0sL9IN3UQ+O02DL9/SwpZhyrZUYx54mrkuDAM/tZvF5YnGW +Kh2xFz7NrFOpHjHizQMZUh8fsOU8jb+8ADed7wYj8RZeom1t226RibOT+ttTei5tjJajHZcDoYb 575n6ftj0EHR9lT9nGqu+jil6nocz6FakVsat4ex6Bva1l5Z8pk2rluGLgiv2tPyGzyv1Qp5r0Ku 5PNawu/l+rxU4/XqXwNes3wkYP9pLfP/en9LDtqHOt9+UWdnMzo7q3GO+WfuqQSf3ejsLEen5qA9 l872y1BXWUcux7jSbN2qHYV5N7gX/etjjEqaJtZHdX1thRKOtj0fc9ARlGWsifI6aRr6rzR1lVjT X6qHR7Hom0r1tXntB+NzDmI9ldfmWC9VEsXnIJKNzzVw+CON9VvxuYm2ddp+NJ77Wu5TxZjBZ7sx T0N/U8t9i3yI+so/6H2QdFRA3BeJdclSpLFUSHEv9zD6lFJyyH3xLvfpKE7tkOiTovQ+SyGE18T9 GcZfvb9KVZL1/kt+U++D5PfhxuRb8AXv1Yj59H59zGl9SoxNp/V+UvSFvA6Je/F5FH3+5OQ2yJ+D 6UxfMnTLbUFynyk70wsNP9sMP+e6N/ZuMJbEijH5IHXntYm2eRdRX3E2+s9ivjIcz1kHadfzzfV2 UU4oI31vXwqeF/B+DpetOafX181a3wyQU3TEOM35+BfoZWEYdy8RcaCPE/s99dq3Rjp5fpKEerqy be5nzuXMuQbRIHU9PaZcCV2oN59JEuP9/oD57WMM1zPjw009OuCNjpEw75b+qSNPBdAzFPSXSg04 jN57KTSo6ejpV+k4/koU/gRRJObbUblErv060YnnEhOmE7uTKP4SogSE1QVjWSJqYBLeIxlxpbxP 5H6eKHWrTlo/FMdkokwMLVmDibJLdbphVtAD8/c8K9EFeJ+eGP/y322nj/v89P2KqP8rRIU+oiKE P/AbosHlREMGoCm/TeRFmkqgXZZhXBh6C9EwpGPEtUQVaBOXfK9z6Q9Eo5HPY14mGoexsuoOohqE ewVmKlPmEk0bEyJEiBD/Qa45D4f/s0yXQ4QIESJEiBAhQoQIESJEiBAhQoQIESJEiBAhQoQIESJE iBAhQoQIESJEiBAhQoQIESJEiJ+ExL/YRN/QYHqUbCSTi/L5W03V2WoqWUjeQ+OU3MacRM/r+5Xu dBzISveGvFTPHqWbktowyONtUjIbY+ILnCU9lXSEli+u6bjOA9tBM1BpipIGexeui4APbAfN4HVg FZ+N4qfpYB7YAI7zEyVVcTeke1wl3ZQk+E1CGp1KFzoJNKCQB9d8MApMAXeDDcAq3LHNPLAINIOv xROv0qVhTV+kvUvDSiEa515VIIzTdOOkK4SxcUK1Li8drcuyEbqzgbqzPv10616luux2gS5jsgt8 LMMiCw6UJCgJeMkEJPxaXCX5d+SUJPLQRiWe/EBWrIaNV4lpzMop2NCsqCQpsiJRLXm0A4rUEBld UBIma/JJiiGP/JX8pf5E/rIxKrpgQ8lI+SPaDpqBIn+Evw/lD2mRfJzzHNdisAE0g9fASWCVj+Pv A/y9L79PTvk9ygfFYArYAJrBSWCT38PVJb/LtUVc+b4YyPK7uLrkd/Ba7+DqlN/G3dvy20ja/zYU FhXsETd5+caNJ9u46ZJi3MQkFDTJbzSc6o4alYOSRo3ap3SlIdRX6dqQ3cfTpCQ2DJ7jaZI/bkzP 82ws6S2/SX6A2ourC6SDSjAVXAusuDuGu2PkA/eAjcAPUMtwdYF0+TB4BRyj3sALKoFdfr0B0TTJ rzXklHpKEuQj8kHqghx/VX5ZyFfkl4T8vfyikIcg0yAPyy81pHmoJBzPCX5ckC7IfDy3yM81ZsV4 tJJouRl558E1HxSDUWAKuBtY5Wa5a0OtJwaB7KPDdoLLBvpcyCdos528cz3enItRAdP5kjPwItzh siF9Q47szVn7EIx8yblrDe74knPHKtzxJeeW23HHl5yrFuCOLzm1c3HHl5yaKbjjS86ocbjDpUle vzurm6dwVJ2UXuKUb0Qu3YhcuhG5dCOp8o38R6dUTtvDDT16IMfWefO69/D49kq+/ZJvjOTbLPlm Sr6Fku92yTdY8k2WfHmSzy350iSfV/Ltky5EVvgk786zjEXeRMl3WPI9I/nqJV+O5MuWfFmSL10q 9DbJGQ0j+goxVIjGEm50kBcNQe/jlDOQoxmo8xnoE5pxfQ1owuSFo/SuuuOkNJZdG3sU6+ZeAwvm lQyXX4DHF1AML9AHQEUBvYBq9AICeQEBOHEtBlPAAXASaMAK112R8LvF1YlrPigGU8AicBJYRXJO ApnmGUncLhKWbyR6FJvkF/DXFX8ZcoY31eV25bmGK3e7JWeaNCpNS5MLKSGBiGKi7dFNUuSuf0T+ 8x+R5ChxyHfJd1MqCuIeQ97dcCrV0yQ92JCzz1MSLz1AaSpqnVREOVI25IVUL8z9yW1n2Y/c8jbI ggZ3Fbw5G3Iu8OyVotjXLs8p9yeez91NMm4/c+/zvJXepEoNnqOw2bbL86Z7hedQfpMdNvtzmiSI venC6R73hZ5nDgunt+PBugbPQha7PP/lHuapc4sHM/UHk+th8jo9Y3JqPMMRXpl7usdbjzB3eYrd kz2DdVf92c8uT28kIU+/7YHEdneLSDPTRIDjC5uk2d4LbGttE22jbANsBbYLbBk2jy3VlmKLs8fY XfYoe4Q9zG63W+2qXbaTPa5JO+7N418wjLOKHzLkjyxLpIp7l8xXmcQPHMqSXaaR5I9VKuSKsaVS hf/ADKqYnu7/fmxmkxQ2usZvySyV/DEVVDGu1H9hXkWTTRvjL8yr8NsqL5+4Q5LuqoatX17eJNG4 iU2SxlZLUvwxF0/cQ5IUvWR1CsvcJaurqykxYUFxYnHMkOii8rIOLlONa8DPrieedZ/qX1sxdqJ/ a2q1v4BvtNTqCv99Y9MnTdwjfSN9PbRsj/Q3FtUT9yhDpG+GjmF7ZUhZdXVFk1Ql3FG69De4Q435 m3Bnx8DM7ijdnqa7W6e7y4Z/uMtiAXcOB2ULd9kOh3CnSuxuR33W0LIdWVnCTZd0qhdu6rukB7o5 nA032dnCTYKPDgs3hxN87MY/RDhxu+EkzS2cSMnkFk7cUrJwUtXuJN9wsqLNyQoRkyK1u3HrbiKP m24ij8NN3k/9N7M0L09qHFQ9Y9LQmZlDp2YOnQmm+lcumJ3o901PT98xo5ofpPuVnKnTZ8xmOW2m vzpzZpl/RmZZ+o5Bkzp4PIkfD8os20GTho6buGOSd2ZZwyDvoKGZ08qqG4dV9is8K64VbXH1q+wg sEoOrB/HNaywg8eF/HgYx1XIcRVyXMO8w0RcJOp45cQddiqtvniSLhvl8DDU16kpGdWlCa5rh4jK OygjcWHKXmgrWyg8r9ofkVnqjwT8qGdJzxJ+hDbFj6Jg7TQeJS4clJGyV9piPHLBOjqzlPLm31B/ AyUOnVOm/6/HP1jNv4EzXL/m1Z/vH54N9XunldXPJ6rw9xhb4S8eXTNxh80G26n8Sv6Bpl14+NAm 7YBu2QuWA9lSUdocst1gtnM4DIfnlv8NhhS/MeuT9zVK3jRpPtVXK/60inEyuoJxNXjXSTUT90KX 4uGhvhovWC/lSfVmGEay9d86Z8HvbDL/BuPOyIv5htR9wku9mSVt/ziz8tpybD4CpP8DthK/7Qpl bmRzdHJlYW0KZW5kb2JqCjk3CjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9DSURGb250 VHlwZTIKL0Jhc2VGb250Ci9NVUZVWlkrQXJpYWwKL0NJRFN5c3RlbUluZm8KPDwKL1JlZ2lzdHJ5 CihBZG9iZSkKL09yZGVyaW5nCihVQ1MpCi9TdXBwbGVtZW50CjAKPj4KL0ZvbnREZXNjcmlwdG9y Cjk5CjAKUgovQ0lEVG9HSURNYXAKL0lkZW50aXR5Ci9EVwoyMjIKL1cKWwowClsKNzUwCjAKMAoy NzcKMAozNTQKXQo2CjEwCjAKMTEKMTIKMzMzCjEzClsKMAo1ODMKMjc3CjMzMwoyNzcKMjc3Cl0K MTkKMjEKNTU2CjIyClsKMApdCjIzCjI3CjU1NgoyOApbCjAKMjc3Cl0KMzAKMzMKMAozNApbCjU1 NgowCjY2Ngo2NjYKNzIyCjcyMgo2NjYKNjEwCjc3Nwo3MjIKMjc3CjUwMAowCjU1Ngo4MzMKNzIy Cjc3Nwo2NjYKMAo3MjIKNjY2CjYxMAo3MjIKNjY2Cjk0MwowCjAKNjEwCl0KNjIKNjcKMAo2OAo2 OQo1NTYKNzAKWwo1MDAKNTU2CjU1NgoyNzcKNTU2CjU1NgoyMjIKMjIyCjUwMAoyMjIKODMzCl0K ODEKODMKNTU2Cjg0ClsKMAozMzMKNTAwCjI3Nwo1NTYKNTAwCjcyMgpdCjkxCjkzCjUwMAo5NAoz NzMKMAozNzQKWwo2MDQKXQozNzUKMzc5CjAKMzgwClsKNjA0Cl0KMzgxCjQwMwowCjQwNApbCjYw NApdCl0KPj4KZW5kb2JqCjk5CjAKb2JqCjw8Ci9UeXBlCi9Gb250RGVzY3JpcHRvcgovRm9udE5h bWUKL01VRlVaWStBcmlhbAovRmxhZ3MKNAovRm9udEJCb3gKWwotNjY0Ci0zMjQKMjAwMAoxMDA1 Cl0KL0FzY2VudAo3MjgKL0Rlc2NlbnQKLTIxMAovSXRhbGljQW5nbGUKMAovQ2FwSGVpZ2h0Cjcx NgovU3RlbVYKODAKL0ZvbnRGaWxlMgoxMDAKMApSCj4+CmVuZG9iagoxMDEKMApvYmoKMzE2CmVu ZG9iagoxMDIKMApvYmoKMTk1NTMKZW5kb2JqCjEwMwowCm9iagozNTcKZW5kb2JqCjEwNAowCm9i agoyNzI2MgplbmRvYmoKMQowCm9iago8PAovVHlwZQovUGFnZXMKL0tpZHMKWwo2CjAKUgoxNAow ClIKMTkKMApSCjI0CjAKUgoyOQowClIKMzQKMApSCjM5CjAKUgo0NAowClIKNTAKMApSCjU1CjAK Ugo2MAowClIKNjUKMApSCjcwCjAKUgo3NQowClIKODAKMApSCjg1CjAKUgpdCi9Db3VudAoxNgo+ PgplbmRvYmoKeHJlZgowIDEwNQowMDAwMDAwMDAyIDY1NTM1IGYgCjAwMDAxMjg2MDcgMDAwMDAg biAKMDAwMDAwMDAwMyAwMDAwMCBmIAowMDAwMDAwMDAwIDAwMDAwIGYgCjAwMDAwMDAwMTYgMDAw MDAgbiAKMDAwMDAwMDE2MCAwMDAwMCBuIAowMDAwMDAwMjA3IDAwMDAwIG4gCjAwMDAwMDAzNzMg MDAwMDAgbiAKMDAwMDA3NTk5NCAwMDAwMCBuIAowMDAwMDAwODg0IDAwMDAwIG4gCjAwMDAwMDA5 MDMgMDAwMDAgbiAKMDAwMDAxMTQ0MiAwMDAwMCBuIAowMDAwMDc4OTg1IDAwMDAwIG4gCjAwMDAw NzkxMzIgMDAwMDAgbiAKMDAwMDAwMDkyMyAwMDAwMCBuIAowMDAwMDAxMDkyIDAwMDAwIG4gCjAw MDAwNzYxODAgMDAwMDAgbiAKMDAwMDAwMTM1OCAwMDAwMCBuIAowMDAwMDAxMzc4IDAwMDAwIG4g CjAwMDAwMDEzOTggMDAwMDAgbiAKMDAwMDAwMTU2NyAwMDAwMCBuIAowMDAwMDc2MzY3IDAwMDAw IG4gCjAwMDAwMDIwNTQgMDAwMDAgbiAKMDAwMDAwMjA3NCAwMDAwMCBuIAowMDAwMDAyMDk0IDAw MDAwIG4gCjAwMDAwMDIyNjMgMDAwMDAgbiAKMDAwMDA3NjU1NCAwMDAwMCBuIAowMDAwMDAyODQ0 IDAwMDAwIG4gCjAwMDAwMDI4NjQgMDAwMDAgbiAKMDAwMDAwMjg4NCAwMDAwMCBuIAowMDAwMDAz MDUzIDAwMDAwIG4gCjAwMDAwNzY3NDEgMDAwMDAgbiAKMDAwMDAwMzU5NSAwMDAwMCBuIAowMDAw MDAzNjE1IDAwMDAwIG4gCjAwMDAwMDM2MzUgMDAwMDAgbiAKMDAwMDAwMzgwNCAwMDAwMCBuIAow MDAwMDc2OTI4IDAwMDAwIG4gCjAwMDAwMDQwNzcgMDAwMDAgbiAKMDAwMDAwNDA5NyAwMDAwMCBu IAowMDAwMDA0MTE3IDAwMDAwIG4gCjAwMDAwMDQyODYgMDAwMDAgbiAKMDAwMDA3NzExNSAwMDAw MCBuIAowMDAwMDA0ODU3IDAwMDAwIG4gCjAwMDAwMDQ4NzcgMDAwMDAgbiAKMDAwMDAwNDg5NyAw MDAwMCBuIAowMDAwMDA1MDY2IDAwMDAwIG4gCjAwMDAwNzczMDIgMDAwMDAgbiAKMDAwMDAwNTI4 OSAwMDAwMCBuIAowMDAwMDA1MzA5IDAwMDAwIG4gCjAwMDAwMTE0ODAgMDAwMDAgbiAKMDAwMDAw NTMyOSAwMDAwMCBuIAowMDAwMDA1NDk4IDAwMDAwIG4gCjAwMDAwNzc0ODkgMDAwMDAgbiAKMDAw MDAwNjE5NCAwMDAwMCBuIAowMDAwMDA2MjE0IDAwMDAwIG4gCjAwMDAwMDYyMzQgMDAwMDAgbiAK MDAwMDAwNjQwMyAwMDAwMCBuIAowMDAwMDc3Njc2IDAwMDAwIG4gCjAwMDAwMDcxNjkgMDAwMDAg biAKMDAwMDAwNzE4OSAwMDAwMCBuIAowMDAwMDA3MjA5IDAwMDAwIG4gCjAwMDAwMDczNzggMDAw MDAgbiAKMDAwMDA3Nzg2MyAwMDAwMCBuIAowMDAwMDA3OTU2IDAwMDAwIG4gCjAwMDAwMDc5NzYg MDAwMDAgbiAKMDAwMDAwNzk5NiAwMDAwMCBuIAowMDAwMDA4MTY1IDAwMDAwIG4gCjAwMDAwNzgw NTAgMDAwMDAgbiAKMDAwMDAwODY4MCAwMDAwMCBuIAowMDAwMDA4NzAwIDAwMDAwIG4gCjAwMDAw MDg3MjAgMDAwMDAgbiAKMDAwMDAwODg4OSAwMDAwMCBuIAowMDAwMDc4MjM3IDAwMDAwIG4gCjAw MDAwMDk2MDQgMDAwMDAgbiAKMDAwMDAwOTYyNCAwMDAwMCBuIAowMDAwMDA5NjQ0IDAwMDAwIG4g CjAwMDAwMDk4MTMgMDAwMDAgbiAKMDAwMDA3ODQyNCAwMDAwMCBuIAowMDAwMDEwMDg5IDAwMDAw IG4gCjAwMDAwMTAxMDkgMDAwMDAgbiAKMDAwMDAxMDEyOSAwMDAwMCBuIAowMDAwMDEwMjk4IDAw MDAwIG4gCjAwMDAwNzg2MTEgMDAwMDAgbiAKMDAwMDAxMDkwOCAwMDAwMCBuIAowMDAwMDEwOTI4 IDAwMDAwIG4gCjAwMDAwMTA5NDggMDAwMDAgbiAKMDAwMDAxMTExNyAwMDAwMCBuIAowMDAwMDc4 Nzk4IDAwMDAwIG4gCjAwMDAwMTE0MDIgMDAwMDAgbiAKMDAwMDAxMTQyMiAwMDAwMCBuIAowMDAw MDY1NDAxIDAwMDAwIG4gCjAwMDAwNzU5NTAgMDAwMDAgbiAKMDAwMDA3NTk3MiAwMDAwMCBuIAow MDAwMDk5Mjk3IDAwMDAwIG4gCjAwMDAwNzkyNzQgMDAwMDAgbiAKMDAwMDA5OTcyMiAwMDAwMCBu IAowMDAwMDc5NjY3IDAwMDAwIG4gCjAwMDAxMjc2OTYgMDAwMDAgbiAKMDAwMDA5OTkyMiAwMDAw MCBuIAowMDAwMTI4MzIzIDAwMDAwIG4gCjAwMDAxMDAzNTYgMDAwMDAgbiAKMDAwMDEyODUxOSAw MDAwMCBuIAowMDAwMTI4NTQwIDAwMDAwIG4gCjAwMDAxMjg1NjMgMDAwMDAgbiAKMDAwMDEyODU4 NCAwMDAwMCBuIAp0cmFpbGVyCjw8Ci9TaXplCjEwNQovUm9vdAo0CjAKUgovSW5mbwo1CjAKUgo+ PgpzdGFydHhyZWYKMTI4NzcyCiUlRU9GCg== --000e0cd47ee2d28b9204aeb95e97-- From nordmark@cisco.com Fri Oct 7 11:22:10 2011 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 A19C021F8ACE for ; Fri, 7 Oct 2011 11:22:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8qq-kp-YLfY for ; Fri, 7 Oct 2011 11:22:10 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 41DF121F8482 for ; Fri, 7 Oct 2011 11:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1248; q=dns/txt; s=iport; t=1318011908; x=1319221508; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wL4aQCCo/R1RafsH0LqTHtO978fHQu8zWFfbq6g0+bU=; b=DN9Jo9y5NrLc8QzFCZiVyQAQFun0C3elObq//7ViiYKwcukPBvWBZq5V 8LTuFbzmdBTPxxqWcWbQ8EmxFi8dUElozfg4bIoUp7Od5cSy+yeaqW/PB ghPwVagt8M5+ZwKQQ9AzqfLz7KMP3xD7cP7U5qfquGROeitWN2fC3vp5D s=; X-IronPort-AV: E=Sophos;i="4.68,503,1312156800"; d="scan'208";a="6600135" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Oct 2011 18:25:08 +0000 Received: from [128.107.115.47] ([128.107.115.47]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p97IP8VA029813; Fri, 7 Oct 2011 18:25:08 GMT Message-ID: <4E8F441D.9070202@cisco.com> Date: Fri, 07 Oct 2011 11:25:33 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 18:22:10 -0000 On 10/7/11 11:11 AM, Lorenzo Colitti wrote: > All, > > here are my slides from the unscheduled talk at the interim meeting. > > Comments appreciated, and if anyone were so inclined, help writing it up > would also be much appreciated. Lorenzo, The slides say: "Support arbitrary topologies including loops" What is the implication of that on IPv4? Are you assuming that the dual-stack home network will delegate IPv4 prefixes and route IPv4, with no internal NATs? How would someone transition to such an IPv4 network from their current daisy-chain or tree of IPv4 NATs? The other question is about the assumptions about the requirements of stability of the prefixes that are assigned to links. For routing you have: - Survive loss of any router for any time period - Works regardless of router boot order That combined with your strawman prefix assignment seems to result in the set of prefixes assigned to a link changing each time a router goes down. Am I reading things correctly? FWIW such an unstable prefix assignment doesn't sound useful. Assuming we allow routers to come and go, I think we want the hosts assigned to a link see the same prefixes for that link over time. Erik From lorenzo@google.com Fri Oct 7 11:36:36 2011 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 E557A21F86EE for ; Fri, 7 Oct 2011 11:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.935 X-Spam-Level: X-Spam-Status: No, score=-105.935 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TocBEEQEyBhE for ; Fri, 7 Oct 2011 11:36:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6621F867F for ; Fri, 7 Oct 2011 11:36:35 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p97Idn2w024507 for ; Fri, 7 Oct 2011 11:39:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318012789; bh=kw/8/7s3N9jds+k3TWvIKOWS3kI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=PQQLGDtb7r6qrufjdCOrHHXfteueZPvFuWxOqwK9k9EvKUmBa2gpwsxbx1Jh8QXnn +TJiAdlpjlOrNYJLG/FPQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=C5f/Izy9BnEZNscY4mBgG3N0OC55rBo7SUCqgNOlf1ha86D/tymFkbccfTHFixpnQ vDZKqLZPmNhCjS2/4mtBw== Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by hpaq6.eem.corp.google.com with ESMTP id p97Ico0Y017819 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 7 Oct 2011 11:39:48 -0700 Received: by yxt3 with SMTP id 3so5680533yxt.8 for ; Fri, 07 Oct 2011 11:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5zCTDY4+6lecO3NNzemUJRWA2aUJKiqEWXfQ2J9M1Ig=; b=xENh6WUe5JzBFCHrGBT7K3DY9EDQY4Q7AlGqyRiVMzAonQ1DKKApMoZO5xDUCe4GjA 9qBmLMjWT9P3JmGnJSHA== Received: by 10.150.138.9 with SMTP id l9mr1858750ybd.171.1318012788302; Fri, 07 Oct 2011 11:39:48 -0700 (PDT) Received: by 10.150.138.9 with SMTP id l9mr1858743ybd.171.1318012788116; Fri, 07 Oct 2011 11:39:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Fri, 7 Oct 2011 11:39:28 -0700 (PDT) In-Reply-To: <4E8F441D.9070202@cisco.com> References: <4E8F441D.9070202@cisco.com> From: Lorenzo Colitti Date: Fri, 7 Oct 2011 14:39:28 -0400 Message-ID: To: Erik Nordmark Content-Type: multipart/alternative; boundary=000e0cd56a1a0b8d4404aeb9c4a3 X-System-Of-Record: true Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 18:36:37 -0000 --000e0cd56a1a0b8d4404aeb9c4a3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 14:25, Erik Nordmark wrote: > The slides say: > "Support arbitrary topologies including loops" > > What is the implication of that on IPv4? > Are you assuming that the dual-stack home network will delegate IPv4 > prefixes and route IPv4, with no internal NATs? > > How would someone transition to such an IPv4 network from their current > daisy-chain or tree of IPv4 NATs? > IPv4 won't work. You would likely never get to such a topology (or never stay there) if you need IPv4, since you would notice it's not working and unplug it. :-) However, it would be nice if IPv6 were able to work in this situation as well, so if you don't need IPv6, you can plug things in any random way and have things work. Supporting arbitrary topologies and loops is not an absolute requirement (especially loops, since loops will break IPv4), but it would be nice to work in multiple topologies, and you have a routing protocol anyway then being able to support loops comes for free. The other question is about the assumptions about the requirements of > stability of the prefixes that are assigned to links. > > For routing you have: > - Survive loss of any router for any time period > - Works regardless of router boot order > > That combined with your strawman prefix assignment seems to result in the > set of prefixes assigned to a link changing each time a router goes down. Am > I reading things correctly? > To achieve stability, routers would need to write the prefixes they form into stable storage (like they would a DHCP lease). I think it's reasonable to write to stable storage whenever you configure a new prefix or change an existing prefix (but not if you simply refresh it). If the router comes back up and nobody has the prefix, it would simply claim it back. If someone else has it, it would have to just form a new one using loop detection. Cheers, Lorenzo --000e0cd56a1a0b8d4404aeb9c4a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 7, 2011 at 14:25, Erik Nordmark <nordmark@cisco.com<= /a>> wrote:
The slides say:
"Support arbitrary topologies including loops"

What is the implication of that on IPv4?
Are you assuming that the dual-stack home network will delegate IPv4 prefix= es and route IPv4, with no internal NATs?

How would someone transition to such an IPv4 network from their current dai= sy-chain or tree of IPv4 NATs?

IPv4 won= 't work. You would likely never get to such a topology (or never stay t= here) if you need IPv4, since you would notice it's not working and unp= lug it. :-) However, it would be nice if IPv6 were able to work in this sit= uation as well, so if you don't need IPv6, you can plug things in any r= andom way and have things work.

Supporting arbitrary topologies and loops is not an abs= olute requirement (especially loops, since loops will break IPv4), but it w= ould be nice to work in multiple topologies, and you have a routing protoco= l anyway then being able to support loops comes for free.

The other question is about = the assumptions about the requirements of stability of the prefixes that ar= e assigned to links.

For routing you have:
=A0- Survive loss of any router for any time period
=A0- Works regardless of router boot order

That combined with your strawman prefix assignment seems to result in the s= et of prefixes assigned to a link changing each time a router goes down. Am= I reading things correctly?

To achieve= stability, routers would need to write the prefixes they form into stable = storage (like they would a DHCP lease). I think it's reasonable to writ= e to stable storage whenever you configure a new prefix or change an existi= ng prefix (but not if you simply refresh it). If the router comes back up a= nd nobody has the prefix, it would simply claim it back. If someone else ha= s it, it would have to just form a new one using loop detection.

Cheers,
Lorenzo
--000e0cd56a1a0b8d4404aeb9c4a3-- From fred@cisco.com Fri Oct 7 12:35:50 2011 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 B668D21F8C58 for ; Fri, 7 Oct 2011 12:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHqhvB6XMzWK for ; Fri, 7 Oct 2011 12:35:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 211FF21F8C57 for ; Fri, 7 Oct 2011 12:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=559; q=dns/txt; s=iport; t=1318016344; x=1319225944; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=+Ejz/dB4zhH71BpQ+wyJzgS8Lic4wYXzGRCfxSTbUGc=; b=DHyl9gNwFrQZY3Zeyd2+C81lN6aGzmgrFBjRPqFJ1HkfS4q3RnOFQc5c 78xbEV05o1L0fXU0f90OoNitghg7TSzTN8jYlS1y+dBewZKbDhlXXVRiS Nxg0fpY1js59vLlWULh1bGQ1xz8Ss1g/z8trOHln6D5DAK3nsaT8G8miC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsIAEBUj06tJV2c/2dsb2JhbAA4CQOZY4xcggCBBYFsAQoBHIIyoFeBJgGeMYN9ASCCMmEEk2+FKIw8 X-IronPort-AV: E=Sophos;i="4.68,503,1312156800"; d="scan'208";a="26875002" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 07 Oct 2011 19:39:04 +0000 Received: from Freds-Computer.local (rtp-vpn4-1741.cisco.com [10.82.214.205]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p97Jd3ox018864 for ; Fri, 7 Oct 2011 19:39:04 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 07 Oct 2011 15:39:04 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 07 Oct 2011 15:39:04 -0400 From: Fred Baker Date: Fri, 7 Oct 2011 15:38:56 -0400 Message-Id: To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [homenet] Interim: Looking for folks in Philadelphia this evening 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, 07 Oct 2011 19:35:50 -0000 If there were a "interim attendees" list, I'd send this to that one. = Apologies to anyone coming back five years after today's date and = reading this in the archive... I'm here this weekend, staying for NANOG. I left early this afternoon = because I have some phone calls; the day job intrudes. If anyone would = like a dinner companion, please feel free to send me a text message or = call at +1-805-637-0529. Barring such, I'll likely go to the Hard Rock = this evening, as it's across the street from the Loew's Hotel, which is = where I am.= From curtis@occnc.com Fri Oct 7 12:51:54 2011 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 3E9E821F854E for ; Fri, 7 Oct 2011 12:51:54 -0700 (PDT) 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=[AWL=0.046, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4CRXTHcN9Cw for ; Fri, 7 Oct 2011 12:51:53 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 48E9721F8C78 for ; Fri, 7 Oct 2011 12:51:53 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p97Jt2XE086866; Fri, 7 Oct 2011 12:55:02 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p97Jt2XE086866 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318017302; bh=eSWsf17zRnIOjsJ9xs1On46guQ/Y0RiOXetY6ovvywg=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=PtkSAukifhjXAtMk/K5rSrUwRdbZC2oatv88VP27jsOU0D3PXbLOYXGVqmFxmSQVg v+WKU3uP1V4py9gMRKaXuOCQ4Mvs2suBX0ufz+RNHM06lCp+2ZKHHjXBx9P7QJvUNJ b3A9FRmbXyNxYkYyHumuc0AQQeHCC0pWPOtOS970= Message-Id: <201110071955.p97Jt2XE086866@gateway.ipv6.occnc.com> To: Joel jaeggli From: Curtis Villamizar In-reply-to: Your message of "Thu, 06 Oct 2011 23:57:44 PDT." <4E8EA2E8.6000508@bogus.com> Date: Fri, 07 Oct 2011 12:55:01 -0700 Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 19:51:54 -0000 In message <4E8EA2E8.6000508@bogus.com> Joel jaeggli writes: > On 10/4/11 16:17 , james woodyatt wrote: > > On Oct 3, 2011, at 9:00 PM, Thomas Herbst wrote: > >> > >> There will be wide area network providers who interwork with the > >> home network but do not provide global connectivity. Two mentioned > >> so far are utility networks and 3g providers. One of the outputs > >> of the wg should be to define how they should be configured to > >> perform their role without messing up Internet communication. > > > > Those utility networks have a fundamental problem that I contend is > > beyond the scope and charter of HOMENET. > > every-time I connect my split-tunneled vpn to my home network, I am > attaching a non-dfz-connected inter-network behind my home network, I > don't think of this as rare or particularly exceptional problem (it's > not confined to utility networks). it does have the potential for > address collisions (as built currently)in ipv4 due to the extensive if > not quite complete use of rfc-1918 used within the scope of that private > internetwork. Joel, Being new to this WG I may have it wrong, but a point of this WG may be to change the use of RFC1918 space to IPv6 space. For example, not only your computers, but your home thermostats, your electic meter, your entertainment systems, SIP phones, etc can each have global IPv6 addresses. Beats "go check the thermostat at 10.0.0.1" from your mobile phone. Authentication will be an issue for product (but from the charter, not in scope for the WG). With an IPv6 only home network you don't need to use rfc1918 number space. You can put your /64 behind a firewall if you like. You can use RFC3142 as one means to reach the IPv4 world at least for anything based on TCP (SMTP, HTTP, etc). Or you can use application gateways (what I use). The benefit over using net 10/8 or other rfc1918 space is that if your hosts at different sites use IPv6 and if your laptop in a IPv4 only site can at least get a 6to4 tunnel, you can use a globally routable IPv6 number space. Try using IPv6 instead of rfc1918. (for example, see mail headers). If the provider side of the WAN connection just hands the home router an IPv6 prefix, then some form of autoconfiguration is possible. If not, IPv4 rfc1918 autoconfiguration can be used with NAT unless a tunnel is configured. It wouldn't hurt to do both IPv4 rfc1918 autoconfiguration with NAT and IPv6 autoconfiguration with a native prefix or with a configured tunnel (or with 6to4 enabled). Curtis From nordmark@cisco.com Fri Oct 7 13:16:21 2011 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 AC2A121F8C1F for ; Fri, 7 Oct 2011 13:16:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eEX4c8pkdW8 for ; Fri, 7 Oct 2011 13:16:20 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D1DD921F8C1D for ; Fri, 7 Oct 2011 13:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=2574; q=dns/txt; s=iport; t=1318018775; x=1319228375; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=h+FcqmqVKm9SXM5+ASkaDXVHJUoSZgv7iuETcoR/5bc=; b=LC90tbXQmG9G74tBsK/drvbiVN1tcvyYggO8gLRocnRiq4tbMJOtGbK0 eLgXyNwOV5a3SE2qUspH6GSJvhwT/2McQpm5AhIrNKFVONsk19PWE7XAx rkka1ZusANAO2+zI4KlW5WpRta2Mvs97Rq/DndVgKAXGmi+YnWnNL+80w E=; X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208";a="6607563" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 Oct 2011 20:17:54 +0000 Received: from [10.0.1.12] (sjc-vpn6-857.cisco.com [10.21.123.89]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p97KHroj026751; Fri, 7 Oct 2011 20:17:54 GMT Message-ID: <4E8F5E8B.4010102@cisco.com> Date: Fri, 07 Oct 2011 13:18:19 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <4E8F441D.9070202@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 20:16:21 -0000 On 10/7/11 11:39 AM, Lorenzo Colitti wrote: > On Fri, Oct 7, 2011 at 14:25, Erik Nordmark > wrote: > > The slides say: > "Support arbitrary topologies including loops" > > What is the implication of that on IPv4? > Are you assuming that the dual-stack home network will delegate IPv4 > prefixes and route IPv4, with no internal NATs? > > How would someone transition to such an IPv4 network from their > current daisy-chain or tree of IPv4 NATs? > > > IPv4 won't work. You would likely never get to such a topology (or never > stay there) if you need IPv4, since you would notice it's not working > and unplug it. :-) However, it would be nice if IPv6 were able to work > in this situation as well, so if you don't need IPv6, you can plug > things in any random way and have things work. > > Supporting arbitrary topologies and loops is not an absolute requirement > (especially loops, since loops will break IPv4), but it would be nice to > work in multiple topologies, and you have a routing protocol anyway then > being able to support loops comes for free. Unfortunately I missed Fred's discussion yesterday (hopefully there will be a recording) but the above seems backwards. Today there are IPv4 NATting RGs, and there are cases when you end up with multiple (could be tied to separate services or other functionality) in a home. Seems like we'd like to be able to introduce IPv6 support without NATs into such a home network without breaking IPv4. You seem to focus on a clean slate approach. > To achieve stability, routers would need to write the prefixes they form > into stable storage (like they would a DHCP lease). That can be used to get a stable prefix per interface on the router, which I observe isn't the same as getting one (or a set of) stable prefixes assigned to the link to which that interface is attached. > I think it's > reasonable to write to stable storage whenever you configure a new > prefix or change an existing prefix (but not if you simply refresh it). > If the router comes back up and nobody has the prefix, it would simply > claim it back. If someone else has it, it would have to just form a new > one using loop detection. In your view, if there is a single prefix assigned to the home by the ISP, and there are three routers connected to a particular link in the home, would each of those three routers assign a different prefix to the link? Am I missing something? Erik From joelja@bogus.com Fri Oct 7 14:05:59 2011 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 7B53B21F8C10 for ; Fri, 7 Oct 2011 14:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPqZjqo3TDzA for ; Fri, 7 Oct 2011 14:05:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EEC6921F8C0C for ; Fri, 7 Oct 2011 14:05:58 -0700 (PDT) Received: from Zorch.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p97L9Bjd040036 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 21:09:12 GMT (envelope-from joelja@bogus.com) Message-ID: <4E8F6A72.5000802@bogus.com> Date: Fri, 07 Oct 2011 14:09:06 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110071955.p97Jt2XE086866@gateway.ipv6.occnc.com> In-Reply-To: <201110071955.p97Jt2XE086866@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 07 Oct 2011 21:09:12 +0000 (UTC) Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 07 Oct 2011 21:05:59 -0000 On 10/7/11 12:55 , Curtis Villamizar wrote: > In message <4E8EA2E8.6000508@bogus.com> > Joel jaeggli writes: > >> On 10/4/11 16:17 , james woodyatt wrote: >>> On Oct 3, 2011, at 9:00 PM, Thomas Herbst wrote: >>>> >>>> There will be wide area network providers who interwork with the >>>> home network but do not provide global connectivity. Two mentioned >>>> so far are utility networks and 3g providers. One of the outputs >>>> of the wg should be to define how they should be configured to >>>> perform their role without messing up Internet communication. >>> >>> Those utility networks have a fundamental problem that I contend is >>> beyond the scope and charter of HOMENET. >> >> every-time I connect my split-tunneled vpn to my home network, I am >> attaching a non-dfz-connected inter-network behind my home network, I >> don't think of this as rare or particularly exceptional problem (it's >> not confined to utility networks). it does have the potential for >> address collisions (as built currently)in ipv4 due to the extensive if >> not quite complete use of rfc-1918 used within the scope of that private >> internetwork. > > > Joel, > > Being new to this WG I may have it wrong, but a point of this WG may > be to change the use of RFC1918 space to IPv6 space. I've got a little experience numbering networks... My observation which apparently you missed was in response to James Woodyatt's point about whether the interconnection of private inter-networks (e.g. those without internet routes for example a utility such as an elecritc provider) was is scope for homenet. > For example, not > only your computers, but your home thermostats, your electic meter, > your entertainment systems, SIP phones, etc can each have global IPv6 > addresses. Beats "go check the thermostat at 10.0.0.1" from your > mobile phone. Authentication will be an issue for product (but > from the charter, not in scope for the WG). > > With an IPv6 only home network you don't need to use rfc1918 number > space. You can put your /64 behind a firewall if you like. You can > use RFC3142 as one means to reach the IPv4 world at least for anything > based on TCP (SMTP, HTTP, etc). Or you can use application gateways > (what I use). The benefit over using net 10/8 or other rfc1918 space > is that if your hosts at different sites use IPv6 and if your laptop > in a IPv4 only site can at least get a 6to4 tunnel, you can use a > globally routable IPv6 number space. > > Try using IPv6 instead of rfc1918. (for example, see mail headers). > > If the provider side of the WAN connection just hands the home router > an IPv6 prefix, then some form of autoconfiguration is possible. If > not, IPv4 rfc1918 autoconfiguration can be used with NAT unless a > tunnel is configured. It wouldn't hurt to do both IPv4 rfc1918 > autoconfiguration with NAT and IPv6 autoconfiguration with a native > prefix or with a configured tunnel (or with 6to4 enabled). > > Curtis > From ot@cisco.com Fri Oct 7 14:15:18 2011 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 C9C1121F87E2 for ; Fri, 7 Oct 2011 14:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.358 X-Spam-Level: X-Spam-Status: No, score=-8.358 tagged_above=-999 required=5 tests=[AWL=2.241, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTCEhH2uVvB4 for ; Fri, 7 Oct 2011 14:15:18 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id ECEEB21F86C1 for ; Fri, 7 Oct 2011 14:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=911; q=dns/txt; s=iport; t=1318022312; x=1319231912; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=H49u8HedXsOHh4oEAOWlo61XiI3kV0uPt1lfRa7a1Bo=; b=iUadqyxsZ68jEDV54imBfLJClDZSWK2SN7UjultpaFrhCAu2ArT8KoJG BogJzeQ6PU5SneArLhFvjUbmDE9AFTXfzcNxycDljhIz4BCVhlgUWmRO4 bu5kdQ/++6ga7Zv/krsoyaP0JBROv4rjXDg34hbGysU90cBRTg050C/wq M=; X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208";a="57355015" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2011 21:18:29 +0000 Received: from ams3-vpn-dhcp5702.cisco.com (ams3-vpn-dhcp5702.cisco.com [10.61.86.69]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p97LISqS016526; Fri, 7 Oct 2011 21:18:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E8F5E8B.4010102@cisco.com> Date: Fri, 7 Oct 2011 17:18:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 21:15:18 -0000 >> I think it's >> reasonable to write to stable storage whenever you configure a new >> prefix or change an existing prefix (but not if you simply refresh = it). >> If the router comes back up and nobody has the prefix, it would = simply >> claim it back. If someone else has it, it would have to just form a = new >> one using loop detection. >=20 > In your view, if there is a single prefix assigned to the home by the = ISP, and there are three routers connected to a particular link in the = home, would each of those three routers assign a different prefix to the = link? >=20 > Am I missing something? see the zospf draft. the DR of the link will assign the prefix for the = link. the BDR should also store that chosen prefix into stable storage. = of course if you power off both the DR and the BDR and power up a new = 3rd router, the link will get a new prefix. cheers, Ole= From lorenzo@google.com Fri Oct 7 14:38:48 2011 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 1945221F8C1B for ; Fri, 7 Oct 2011 14:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.868 X-Spam-Level: X-Spam-Status: No, score=-105.868 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdBYFXryTlXM for ; Fri, 7 Oct 2011 14:38:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0021F8BF3 for ; Fri, 7 Oct 2011 14:38:47 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p97LfukT024098 for ; Fri, 7 Oct 2011 14:41:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318023717; bh=c5fJSzeez1XRMJVPdkJAcV1Y114=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rqlpCApP4p44wemMMeBeo73wPl8IowS9RA4GbtihOMoAXD38p5HuMT03/dVu3YOXa qKs0B0PUDy+yruYvvQz6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=nXE1xs8KTwMYqKSdDbwjQqr2RSOqoxsBpYB0XQyIw9oBaRjkVCu5U26j1xPt0YEN3 5MioxFTt+qrYTBuoHSzxQ== Received: from vcbfl15 (vcbfl15.prod.google.com [10.220.204.79]) by hpaq14.eem.corp.google.com with ESMTP id p97LWw0R029261 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 7 Oct 2011 14:41:55 -0700 Received: by vcbfl15 with SMTP id fl15so6309269vcb.3 for ; Fri, 07 Oct 2011 14:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rlOrZREwEc3j9YcSZ25GxXWamlsubS6ZcGu6m+2arKI=; b=aAwMdn2OhgL/UUtDBpV74XzhJmuTbghEMZqoub2QuI871QeSbIo000ZRqrzIoT2Ett HDS4u6DXMHWbQygRX2bA== Received: by 10.150.251.28 with SMTP id y28mr1982287ybh.342.1318023715378; Fri, 07 Oct 2011 14:41:55 -0700 (PDT) Received: by 10.150.251.28 with SMTP id y28mr1982283ybh.342.1318023715170; Fri, 07 Oct 2011 14:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Fri, 7 Oct 2011 14:41:35 -0700 (PDT) In-Reply-To: <4E8F5E8B.4010102@cisco.com> References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> From: Lorenzo Colitti Date: Fri, 7 Oct 2011 17:41:35 -0400 Message-ID: To: Erik Nordmark Content-Type: multipart/alternative; boundary=000e0cd630625927e204aebc4fd4 X-System-Of-Record: true Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 21:38:48 -0000 --000e0cd630625927e204aebc4fd4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 16:18, Erik Nordmark wrote: > Today there are IPv4 NATting RGs, and there are cases when you end up with >> multiple (could be tied to separate services or other functionality) in a >> home. >> > Seems like we'd like to be able to introduce IPv6 support without NATs into > such a home network without breaking IPv4. > This approach doesn't break IPv4, but it will work regardless of whether IPv4 is working or not. So if/when IPv4 goes away you can plug any port into any other port, even in topologies that IPv4+NAT can't handle, and it will still work. I don't think "doesn't work if IPv4 doesn't work" should be a goal. > > You seem to focus on a clean slate approach. More than clean slate it's ships in the night. In your view, if there is a single prefix assigned to the home by the ISP, > and there are three routers connected to a particular link in the home, > would each of those three routers assign a different prefix to the link? No, the intention is that there be only one prefix on the link. --000e0cd630625927e204aebc4fd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 7, 2011 at 16:18, Erik Nordmark <nordmark@cisco.com<= /a>> wrote:
Today there are IPv4 NATti= ng RGs, and there are cases when you end up with multiple (could be tied to= separate services or other functionality) in a home.
Seems like we'd like to be able to introduce IPv6 support without NATs = into such a home network without breaking IPv4.

This approach doesn't break IPv4, but it will work regardless = of whether IPv4 is working or not. So if/when IPv4 goes away you can plug a= ny port into any other port, even in topologies that IPv4+NAT can't han= dle, and it will still work.

I don't think "doesn't work if IPv4 doesn&= #39;t work" should be a goal.
=A0
You seem to focu= s on a clean slate approach.

More than clea= n slate it's ships in the night.

In your view, if there is a = single prefix assigned to the home by the ISP, and there are three routers = connected to a particular link in the home, would each of those three route= rs assign a different prefix to the link?

No, the intention is that there be only one prefix on t= he link.
--000e0cd630625927e204aebc4fd4-- From townsley@cisco.com Fri Oct 7 15:04:58 2011 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 195BF21F8C11 for ; Fri, 7 Oct 2011 15:04:58 -0700 (PDT) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyPrQV8w8XYR for ; Fri, 7 Oct 2011 15:04:57 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFDC21F8BE7 for ; Fri, 7 Oct 2011 15:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=5536; q=dns/txt; s=iport; t=1318025292; x=1319234892; h=from:mime-version:subject:date:references:to:message-id; bh=SWf3XIpd3JPU/NhzSqXhfyec3jPyvAPsPBNDIjFqobg=; b=P9wkowcTCtxPEU7okuhHEpk1Jm0igjU460NgcS+AfS7GiQUoNwA5Nn58 gAysbsuL6J9Z8qXl4MEFFLcuGzk2RljQCjY2Ho+LKMZCVvlCWZ9tLu2Jj j5NclilT6xgwyQOK85UmpuMn3Dd5COvHdGILXclhgD/2EchEIo8cACrvg Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8HAAZ3j06rRDoH/2dsb2JhbAAqGpk8jlyBBYFTAQEBAwESAUIpCwUNCgMBAi9GBwIIGRERh1wHJJk0AZ4yhk9hBJNvhSiMPA X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208,217";a="6628732" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 07 Oct 2011 22:08:12 +0000 Received: from [172.16.160.85] ([10.21.168.221]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97M7bY1021497 for ; Fri, 7 Oct 2011 22:08:11 GMT From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-415674164 Date: Fri, 7 Oct 2011 18:08:10 -0400 X-Priority: 3 References: <1468990530.708341318019041765.JavaMail.nobody@rsj6rmd002.webex.com> To: homenet@ietf.org Message-Id: X-Mailer: Apple Mail (2.1084) Subject: [homenet] Fwd: Your recording "Meeting Center MPV-20111007 1515-1" is available for viewing 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, 07 Oct 2011 22:04:58 -0000 --Apple-Mail-4-415674164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYi Begin forwarded message: > From: messenger@webex.com > Date: October 7, 2011 4:24:01 PM EDT > To: townsley@cisco.com > Subject: Your recording "Meeting Center MPV-20111007 1515-1" is = available for viewing > Reply-To: messenger@webex.com >=20 > Mark Townsley,=20 >=20 > Your recording is now available on the WebEx service site. Click the = link below to play it:=20 >=20 > = https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D55295492&= rKey=3Df4fa72f47cd5d52b=20 >=20 > Meeting Center MPV-20111007 1515-1=20 > Friday, October 7, 2011 8:15 am San Francisco Time=20 > 4 Hours 50 Minutes=20 >=20 > * You can forward this message to others to allow them to play back = the recording. *=20 >=20 > -------------------------------------=20 > Additional Options=20 > -------------------------------------=20 >=20 > To edit recording information and playback control options, click the = link below:=20 > https://cisco.webex.com/ciscosales/editrd.php?rID=3D55295492&SP=3DMC=20= >=20 > To view more options for this recording, such as downloading, click = the link below:=20 > https://cisco.webex.com/ciscosales/viewrd.php?rID=3D55295492&SP=3DMC=20= >=20 > To view all your WebEx Meeting Center recordings, click the link = below:=20 > https://cisco.webex.com/ciscosales/servicerds.php?SP=3DMC=20 >=20 > http://www.webex.com=20 --Apple-Mail-4-415674164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: messenger@webex.com
Date: October 7, 2011 = 4:24:01 PM EDT
=
Subject: Your recording = "Meeting Center MPV-20111007 1515-1" is available for = viewing
Reply-To: messenger@webex.com

Mark Townsley,

Your recording is now available on = the WebEx service site. Click the link below to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&S= P=3DMC&rID=3D55295492&rKey=3Df4fa72f47cd5d52b

= Meeting Center MPV-20111007 1515-1
Friday, October 7, 2011 8:15 am = San Francisco Time
4 Hours 50 Minutes

* You can forward = this message to others to allow them to play back the recording. *
=
-------------------------------------
Additional Options
= -------------------------------------

To edit recording = information and playback control options, click the link below:
https://cisco.webex.com/ciscosales/editrd.php?rID=3D5529= 5492&SP=3DMC

To view more options for this recording, = such as downloading, click the link below:
https://cisco.webex.com/ciscosales/viewrd.php?rID=3D5529= 5492&SP=3DMC

To view all your WebEx Meeting Center = recordings, click the link below:
https://cisco.webex.com/ciscosales/servicerds.php?SP=3DM= C

http://www.webex.com =

= --Apple-Mail-4-415674164-- From nordmark@cisco.com Fri Oct 7 15:05:12 2011 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 19D3F21F8C1F for ; Fri, 7 Oct 2011 15:05:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdCAHQaN44qO for ; Fri, 7 Oct 2011 15:05:11 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 906D621F8BE7 for ; Fri, 7 Oct 2011 15:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=2179; q=dns/txt; s=iport; t=1318025306; x=1319234906; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bYRveMwqPgkdlNaaF0xrOSu0Rjfza93LjjEfm0iOQ+Y=; b=UUBl3kuVLFfqCljN9SwvIcfs0bWIOwxeZ6W0fB2clFbofWyr21cfQca8 NnpvLqfRvEoumgGr2cOAvWtC5g3uce/Lz0gubWsvTziyh7jZvbWncMHxt +m3pHh3AL5F0YxKqAqzS3zIuJpV3YVgHvpX5MmvcKx09p80iK9+osFNG6 0=; X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208";a="6624099" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 07 Oct 2011 22:08:26 +0000 Received: from [10.0.1.12] (sjc-vpn6-857.cisco.com [10.21.123.89]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97M8Q6t021958; Fri, 7 Oct 2011 22:08:26 GMT Message-ID: <4E8F7873.4050505@cisco.com> Date: Fri, 07 Oct 2011 15:08:51 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ole Troan References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 22:05:12 -0000 On 10/7/11 2:18 PM, Ole Troan wrote: >>> I think it's >>> reasonable to write to stable storage whenever you configure a new >>> prefix or change an existing prefix (but not if you simply refresh it). >>> If the router comes back up and nobody has the prefix, it would simply >>> claim it back. If someone else has it, it would have to just form a new >>> one using loop detection. >> >> In your view, if there is a single prefix assigned to the home by the ISP, and there are three routers connected to a particular link in the home, would each of those three routers assign a different prefix to the link? >> >> Am I missing something? > > see the zospf draft. the DR of the link will assign the prefix for the link. the BDR should also store that chosen prefix into stable storage. of course if you power off both the DR and the BDR and power up a new 3rd router, the link will get a new prefix. The zospf draft (see section 3.6) declares a conflict if two routers attached to the same link pick the same IP subnet prefix for that link. That doesn't seem what we want. And zospf doesn't talk about using stable storage; doesn't seem to have any notion of providing stable prefixes assigned to the links. Thus this problem remains to be solved AFAICT. I think we first need to agree on what we think are the requirements on prefix stability. What if one of the routers attached to the link fails and is replaced by a different router? What if a link partitions? And later merges? What the user intentionally splits (partitions) a link (e.g., to create a separate link for the teenage game room); should the network automatically pick a new prefix for that new link? (How does that interact with the prefix being in stable storage on the router.) One thing to keep in mind as we think about these requirements is that if the user has created a bridged Ethernet with no routers, all of the above will work naturally; might take seconds to relearn when the topology changes but there is no manual intervention needed. Is that the goal for this prefix assignment? Who is working on the requirements document? ;-) Erik From townsley@cisco.com Fri Oct 7 15:05:12 2011 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 C146B21F8C2F for ; Fri, 7 Oct 2011 15:05:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISnRaOv9vsy1 for ; Fri, 7 Oct 2011 15:05:12 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86221F8BE7 for ; Fri, 7 Oct 2011 15:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=5524; q=dns/txt; s=iport; t=1318025307; x=1319234907; h=from:mime-version:subject:date:references:to:message-id; bh=pGq350DYuIh/JdeVtZxndCuwvWErcMc8O4KvVnR6HMc=; b=ST8jQFs0P/PZ8Zx8QoWe4aoXBfmpYwdP+0uAlEQJTt3xb8WKtIYK9oy6 vHPpi2+WDpycCUQMwN0GyqAzQoqjZcpt9DcAK4p3VK3OX1MvBjX//hGMP 8UcbnDB4mkoNNX7vSmqTeVrEYMjZ4lFNM+P++M1peskB8NteVI2AIecbZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8HALt3j06rRDoH/2dsb2JhbAAqGpk8jlyBBYFTAQEBAwESAUIpCwUNCgMBAi9GBwIIGRERh1wHJJktAZ4yhk9hBJNvhSiMPA X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208,217";a="6611896" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 07 Oct 2011 22:08:26 +0000 Received: from [172.16.160.85] ([10.21.168.221]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97M7bY2021497 for ; Fri, 7 Oct 2011 22:08:25 GMT From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-415688979 Date: Fri, 7 Oct 2011 18:08:25 -0400 X-Priority: 3 References: <1084731933.680971317935943639.JavaMail.nobody@rsj6rmd002.webex.com> To: homenet@ietf.org Message-Id: <0B43FF73-9ABB-4DCD-9364-49614DBA7A57@cisco.com> X-Mailer: Apple Mail (2.1084) Subject: [homenet] Fwd: Your recording "Meeting Center MPV-20111006 1253-1" is available for viewing 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, 07 Oct 2011 22:05:12 -0000 --Apple-Mail-5-415688979 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > From: messenger@webex.com > Date: October 6, 2011 5:19:03 PM EDT > To: townsley@cisco.com > Subject: Your recording "Meeting Center MPV-20111006 1253-1" is = available for viewing > Reply-To: messenger@webex.com >=20 > Mark Townsley,=20 >=20 > Your recording is now available on the WebEx service site. Click the = link below to play it:=20 >=20 > = https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D55257142&= rKey=3D62aaa35dd9fb6dad=20 >=20 > Meeting Center MPV-20111006 1253-1=20 > Thursday, October 6, 2011 5:53 am San Francisco Time=20 > 19 Seconds=20 >=20 > * You can forward this message to others to allow them to play back = the recording. *=20 >=20 > -------------------------------------=20 > Additional Options=20 > -------------------------------------=20 >=20 > To edit recording information and playback control options, click the = link below:=20 > https://cisco.webex.com/ciscosales/editrd.php?rID=3D55257142&SP=3DMC=20= >=20 > To view more options for this recording, such as downloading, click = the link below:=20 > https://cisco.webex.com/ciscosales/viewrd.php?rID=3D55257142&SP=3DMC=20= >=20 > To view all your WebEx Meeting Center recordings, click the link = below:=20 > https://cisco.webex.com/ciscosales/servicerds.php?SP=3DMC=20 >=20 > http://www.webex.com=20 --Apple-Mail-5-415688979 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: messenger@webex.com
Date: October 6, 2011 = 5:19:03 PM EDT
=
Subject: Your recording = "Meeting Center MPV-20111006 1253-1" is available for = viewing
Reply-To: messenger@webex.com

Mark Townsley,

Your recording is now available on = the WebEx service site. Click the link below to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&S= P=3DMC&rID=3D55257142&rKey=3D62aaa35dd9fb6dad

= Meeting Center MPV-20111006 1253-1
Thursday, October 6, 2011 5:53 = am San Francisco Time
19 Seconds

* You can forward this = message to others to allow them to play back the recording. *

= -------------------------------------
Additional Options
= -------------------------------------

To edit recording = information and playback control options, click the link below:
https://cisco.webex.com/ciscosales/editrd.php?rID=3D5525= 7142&SP=3DMC

To view more options for this recording, = such as downloading, click the link below:
https://cisco.webex.com/ciscosales/viewrd.php?rID=3D5525= 7142&SP=3DMC

To view all your WebEx Meeting Center = recordings, click the link below:
https://cisco.webex.com/ciscosales/servicerds.php?SP=3DM= C

http://www.webex.com =

= --Apple-Mail-5-415688979-- From townsley@cisco.com Fri Oct 7 15:05:27 2011 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 EC05521F8C1F for ; Fri, 7 Oct 2011 15:05:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS-RllAPP9nh for ; Fri, 7 Oct 2011 15:05:27 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAEC21F8BE7 for ; Fri, 7 Oct 2011 15:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=5553; q=dns/txt; s=iport; t=1318025322; x=1319234922; h=from:mime-version:subject:date:references:to:message-id; bh=FXVGuCwpdePEW3rcnywJqreckI65W3LBPfW0yRpjf4c=; b=RLT2XLuqjj5zRRtIs9i+KBSh3yvHdXVfBPfQkqbDIMB3OJbP9yGfb/TB dxTsD2smuy/r4o17c9qwP69V7NiSbrQooBTlKI8lsHbXKGKQ+PYZLSWzl d9GEIOVJWLlqgr5S/CkmQ1cD21zj5pvhaY9hH9YAlzN/REZVO/m7AdWyE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8HAFN4j06rRDoH/2dsb2JhbAAqGpk8jlyBBYFTAQEBAwESAUIpCwUNCgMBAi9GBwIIGRERh1wHJJkxAZ4yhk9hBJNvhSiMPA X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208,217";a="6628802" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 07 Oct 2011 22:08:36 +0000 Received: from [172.16.160.85] ([10.21.168.221]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97M7bY3021497 for ; Fri, 7 Oct 2011 22:08:35 GMT From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-415698756 Date: Fri, 7 Oct 2011 18:08:34 -0400 X-Priority: 3 References: <289176131.680911317935942578.JavaMail.nobody@rsj6rmd002.webex.com> To: homenet@ietf.org Message-Id: X-Mailer: Apple Mail (2.1084) Subject: [homenet] Fwd: Your recording "Meeting Center MPV-20111006 1420-2" is available for viewing 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, 07 Oct 2011 22:05:28 -0000 --Apple-Mail-6-415698756 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > From: messenger@webex.com > Date: October 6, 2011 5:19:02 PM EDT > To: townsley@cisco.com > Subject: Your recording "Meeting Center MPV-20111006 1420-2" is = available for viewing > Reply-To: messenger@webex.com >=20 > Mark Townsley,=20 >=20 > Your recording is now available on the WebEx service site. Click the = link below to play it:=20 >=20 > = https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D55257237&= rKey=3D19e448923d8901d2=20 >=20 > Meeting Center MPV-20111006 1420-2=20 > Thursday, October 6, 2011 7:20 am San Francisco Time=20 > 5 Hours 12 Minutes=20 >=20 > * You can forward this message to others to allow them to play back = the recording. *=20 >=20 > -------------------------------------=20 > Additional Options=20 > -------------------------------------=20 >=20 > To edit recording information and playback control options, click the = link below:=20 > https://cisco.webex.com/ciscosales/editrd.php?rID=3D55257237&SP=3DMC=20= >=20 > To view more options for this recording, such as downloading, click = the link below:=20 > https://cisco.webex.com/ciscosales/viewrd.php?rID=3D55257237&SP=3DMC=20= >=20 > To view all your WebEx Meeting Center recordings, click the link = below:=20 > https://cisco.webex.com/ciscosales/servicerds.php?SP=3DMC=20 >=20 > http://www.webex.com=20 --Apple-Mail-6-415698756 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: messenger@webex.com
Date: October 6, 2011 = 5:19:02 PM EDT
=
Subject: Your recording = "Meeting Center MPV-20111006 1420-2" is available for = viewing
Reply-To: messenger@webex.com

Mark Townsley,

Your recording is now available on = the WebEx service site. Click the link below to play it:

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&S= P=3DMC&rID=3D55257237&rKey=3D19e448923d8901d2

= Meeting Center MPV-20111006 1420-2
Thursday, October 6, 2011 7:20 = am San Francisco Time
5 Hours 12 Minutes

* You can = forward this message to others to allow them to play back the recording. = *

-------------------------------------
Additional = Options
-------------------------------------

To edit = recording information and playback control options, click the link = below:
https://cisco.webex.com/ciscosales/editrd.php?rID=3D5525= 7237&SP=3DMC

To view more options for this recording, = such as downloading, click the link below:
https://cisco.webex.com/ciscosales/viewrd.php?rID=3D5525= 7237&SP=3DMC

To view all your WebEx Meeting Center = recordings, click the link below:
https://cisco.webex.com/ciscosales/servicerds.php?SP=3DM= C

http://www.webex.com =

= --Apple-Mail-6-415698756-- From nordmark@cisco.com Fri Oct 7 15:17:50 2011 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 4560221F8B2A for ; Fri, 7 Oct 2011 15:17:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya1-ok76i4XY for ; Fri, 7 Oct 2011 15:17:49 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8C08D21F8B16 for ; Fri, 7 Oct 2011 15:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=3568; q=dns/txt; s=iport; t=1318026064; x=1319235664; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ex5CQc7Y0vxJ5UXRotA0FcmPCxqXH1/Xyj2ba/PKlOw=; b=MSjob1BwI9lkyErDC4tOswXbul2GuUMmLfUa/2texG6waLZCFnyAkY0B I9WU/xzXph6EaVhIHJtieJvr0Dk6CM64Boh1BP9BihgOx7IWJlTTWrd4g 7Kzj0TmApJPT53q2K0lK+znMQfjeSb01K+30hXpoqLLwiROnS9m73hsJM c=; X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208";a="6646146" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Oct 2011 22:21:04 +0000 Received: from [10.0.1.12] (sjc-vpn6-857.cisco.com [10.21.123.89]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97ML4Dq028393; Fri, 7 Oct 2011 22:21:04 GMT Message-ID: <4E8F7B69.9000603@cisco.com> Date: Fri, 07 Oct 2011 15:21:29 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 22:17:50 -0000 On 10/7/11 2:41 PM, Lorenzo Colitti wrote: > Seems like we'd like to be able to introduce IPv6 support without > NATs into such a home network without breaking IPv4. > > > This approach doesn't break IPv4, but it will work regardless of whether > IPv4 is working or not. So if/when IPv4 goes away you can plug any port > into any other port, even in topologies that IPv4+NAT can't handle, and > it will still work. > > I don't think "doesn't work if IPv4 doesn't work" should be a goal. > > You seem to focus on a clean slate approach. > > > More than clean slate it's ships in the night. So if we take a topology below (if it doesn't display correctly, look at figure 7 in http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-00) +------+--------+ \ | IPv6 | \ | Customer Edge | \ | Router 1 | | +------+--------+ +------------+ | Network A | | | | +-------------+------+-------+-------+-----+ | | | | | | | | | +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | | |IPv6 Host | |IPv6 Host | | | IPv6 | |IPv6 Host | | | | | | | | | Router 2| | | | | +----------+ +----------+ | +----+-----+ +----------+ | | | | | | | +-------------+ | | | | Network B | | | | | | | | | +----+-----+ +-----+----+ | | | | IPv6 | |IPv6 Host | | | | | Router 3| | | | | | +----+-----+ +----------+ | | | | | | | +--------------------+ | | Network C/A | +------+--------+ | End-User | IPv6 | | networks | Router 4 | | +------+--------+ | Network D | | +-------------+------+--------+---------+ | | | | | | +----+-----+ +-----+----+ +----+-----+ +-+------+-+ | |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | | | | | | | | | / +----------+ +----------+ +----------+ +----------+ / If this was an IPv4/NAT network it wouldn't reliably work, since there is a NAT loop involving R3 and R2. Thus in IPv4 the link out of the bottom of R3 would actually not exist. I think what you are saying is that it is fine if the deployment of IPv6 encourages folks to create the R3/R2 loop above, even if that makes IPv4 fail. I find such an approach rather unrealistic; it might be reasonable in greenfield IPv6-only home networks but I would never recommend that as a way to move current IPv4 home networks forward. I thought we wanted the solution to apply to the average Joe, and not just experts like ourselves. Regards, Erik From mark@townsley.net Fri Oct 7 15:33:24 2011 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 3F72A21F8BE7 for ; Fri, 7 Oct 2011 15:33:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ulcz4lpvoG5R for ; Fri, 7 Oct 2011 15:33:23 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id CFCED21F8B87 for ; Fri, 7 Oct 2011 15:32:55 -0700 (PDT) Received: by pzk37 with SMTP id 37so10851349pzk.9 for ; Fri, 07 Oct 2011 15:36:10 -0700 (PDT) Received: by 10.68.10.70 with SMTP id g6mr16834149pbb.65.1318026970298; Fri, 07 Oct 2011 15:36:10 -0700 (PDT) Received: from [172.16.160.85] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id u1sm35622551pbr.9.2011.10.07.15.36.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 15:36:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4E8F7873.4050505@cisco.com> Date: Fri, 7 Oct 2011 18:36:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> <4E8F7873.4050505@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: Ole Troan , homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 22:33:24 -0000 On Oct 7, 2011, at 6:08 PM, Erik Nordmark wrote: > On 10/7/11 2:18 PM, Ole Troan wrote: >>>> I think it's >>>> reasonable to write to stable storage whenever you configure a new >>>> prefix or change an existing prefix (but not if you simply refresh = it). >>>> If the router comes back up and nobody has the prefix, it would = simply >>>> claim it back. If someone else has it, it would have to just form a = new >>>> one using loop detection. >>>=20 >>> In your view, if there is a single prefix assigned to the home by = the ISP, and there are three routers connected to a particular link in = the home, would each of those three routers assign a different prefix to = the link? >>>=20 >>> Am I missing something? >>=20 >> see the zospf draft. the DR of the link will assign the prefix for = the link. the BDR should also store that chosen prefix into stable = storage. of course if you power off both the DR and the BDR and power up = a new 3rd router, the link will get a new prefix. >=20 > The zospf draft (see section 3.6) declares a conflict if two routers = attached to the same link pick the same IP subnet prefix for that link. = That doesn't seem what we want. >=20 > And zospf doesn't talk about using stable storage; doesn't seem to = have any notion of providing stable prefixes assigned to the links. >=20 > Thus this problem remains to be solved AFAICT. >=20 > I think we first need to agree on what we think are the requirements = on prefix stability. What if one of the routers attached to the link = fails and is replaced by a different router? > What if a link partitions? And later merges? > What the user intentionally splits (partitions) a link (e.g., to = create a separate link for the teenage game room); should the network = automatically pick a new prefix for that new link? (How does that = interact with the prefix being in stable storage on the router.) >=20 > One thing to keep in mind as we think about these requirements is that = if the user has created a bridged Ethernet with no routers, all of the = above will work naturally; might take seconds to relearn when the = topology changes but there is no manual intervention needed. > Is that the goal for this prefix assignment? No manual intervention is definitely a goal. >=20 > Who is working on the requirements document? ;-) For now, the arch document will be capturing as close as we are getting = to formal requirements in an ID.... mostly principles and high-level = requirements.=20 I'm not convinced a detailed or separate requirements document for any = of our 5 areas could be produced without it becoming a reverse = engineering exercise from various solutions anyway. We tried to have a = formal "just the requirements" discussion during the meeting, and what I = heard was quite a bit of solution discussion couched in requirements = language anyway. - Mark >=20 > Erik > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From townsley@cisco.com Fri Oct 7 15:35:27 2011 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 D112F21F8BF4 for ; Fri, 7 Oct 2011 15:35:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pePoO6vt4Zlq for ; Fri, 7 Oct 2011 15:35:27 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 49D5621F8BEC for ; Fri, 7 Oct 2011 15:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=539; q=dns/txt; s=iport; t=1318027122; x=1319236722; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8RwzbtusHGS9d5DxMC43jrTbQesYzraKUiltcSj76T8=; b=e/vumgFR1OBwCzaxLdYV42GR2FmwntZcDsAJKBqSKlQxz4i6CJo3oKJ0 82XaKEJeGgcOcaQwAnbMRb+QTMF7WGQV7f/YWhqJT2J2/4hbxGmmkj8dR CpLr1617nttioqgcWHrVmQnjKMIS1F6gxIdIrv3eJM37m8NopJ/VSi8mV Q=; X-IronPort-AV: E=Sophos;i="4.68,505,1312156800"; d="scan'208";a="6616565" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 07 Oct 2011 22:38:41 +0000 Received: from [172.16.160.85] ([10.21.168.221]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p97MceIA009058; Fri, 7 Oct 2011 22:38:40 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4E8F7B69.9000603@cisco.com> Date: Fri, 7 Oct 2011 18:38:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> <4E8F7B69.9000603@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 07 Oct 2011 22:35:27 -0000 On Oct 7, 2011, at 6:21 PM, Erik Nordmark wrote: >=20 >=20 > I thought we wanted the solution to apply to the average Joe, and not = just experts like ourselves. That's the point though. Experts know how to construct a network without = loops (presumably), Joe doesn't. You're pushing the problem from the = protocols to the documentation. - Mark >=20 > Regards, > Erik > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nordmark@cisco.com Fri Oct 7 15:48:33 2011 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 4BABC21F8BF4 for ; Fri, 7 Oct 2011 15:48:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNX3ZdWdVKYj for ; Fri, 7 Oct 2011 15:48:32 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AF47C21F8BF0 for ; Fri, 7 Oct 2011 15:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=898; q=dns/txt; s=iport; t=1318027907; x=1319237507; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BK2ECcM7O+Qy/pYIpu064P1Se7eIWSbW6XinMCe1NFs=; b=AXyByDLABbu5R7fSkBpaK4UHzEyKYWHQ2RnhgXBUUgoFwZCql/KBTAbt 7rJZ9AFOteb7A5oNqXQDcLqCrbDhXvfikqvokJ/Ql1TWhH51bukP8yLlx VGHlWqYMAmjQxpNNMMz9lmoMb5n9Lz/5/2AzGwLDRXlIPCMwDianGCeXZ Q=; X-IronPort-AV: E=Sophos;i="4.68,505,1312156800"; d="scan'208";a="6650585" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Oct 2011 22:51:47 +0000 Received: from [10.0.1.12] (sjc-vpn6-857.cisco.com [10.21.123.89]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97MpktR011794; Fri, 7 Oct 2011 22:51:47 GMT Message-ID: <4E8F829C.9040902@cisco.com> Date: Fri, 07 Oct 2011 15:52:12 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Fred Baker References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> In-Reply-To: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , homenet@ietf.org, homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 22:48:33 -0000 On 10/7/11 12:48 AM, Fred Baker wrote: > I suggested that the probability of use of each of the scenarios on slide 4 were > single router network: 90th percentile > tree network: unusual > multi-router: perhaps 5th percentile > multihomed: unusual Fred, are the above numbers based on any survey data? Reason I'm asking is that I have two consumer devices with IPv4 NAT in my home (a VoIP box and a backup device) where the instructions said: 1. Insert between or existing router (or PC if you have no router) and the DSL/cable modem 2. Insert between your PC and your existing router (or modem if you have no router) Those consumer instructions naturally result in a daisy-chain of IPv4 RGs/NATs, which is a subset of a tree topology. I can't be the only person who have a VoIP box or a Time Capsule. Erik From nordmark@cisco.com Fri Oct 7 15:51:56 2011 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 DF49821F84AF for ; Fri, 7 Oct 2011 15:51:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hssZ0rwSNKxn for ; Fri, 7 Oct 2011 15:51:56 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5845921F8497 for ; Fri, 7 Oct 2011 15:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=910; q=dns/txt; s=iport; t=1318028111; x=1319237711; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IxbSLaCJD9rjbk8inWXiLR6vZN5NQsJzNPZH7zqrm+w=; b=I0bAXPlSH+MKzQ0GJnwqgN+SWy46rUYA3IEA4Pdg4+9/0oaqnf61DDDh E8t+H/sdC1pOvTtaIPvytuz1kviwH/wTy7dxRIkj9YKP1Pj3I+OEdQPpq WDBhzXJkZ7oE09+Foc7azdX99j8vH6zTjXI4gB4SOoA5OWgOmb83iPVnO A=; X-IronPort-AV: E=Sophos;i="4.68,505,1312156800"; d="scan'208";a="6635717" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 Oct 2011 22:55:11 +0000 Received: from [10.0.1.12] (sjc-vpn6-857.cisco.com [10.21.123.89]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p97MtAaM017507; Fri, 7 Oct 2011 22:55:11 GMT Message-ID: <4E8F8368.5070304@cisco.com> Date: Fri, 07 Oct 2011 15:55:36 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Fred Baker References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Jari Arkko Subject: Re: [homenet] Thoughts about routing 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, 07 Oct 2011 22:51:57 -0000 On 10/7/11 3:28 AM, Fred Baker wrote: > The other parameters in question include > - the interface prefix itself, which could be derived as in zospf, > - the area number (I'd suggest it default to zero), > - the router ID (a random 32 bit number), and > - security information. Fred, Do existing OSPF implementations have the ability to pick a random router ID, and detect when there is a router ID collision? One benefit of using IS-IS is that the router ID is longer and based on a factory-assigned IEEE MAC address. The zospf appears to have an approach for router ID collisions, but that probably isn't (widely) implemented. (In any case, we'd need to figure out what it means to have stable prefixes allocated - to interfaces or to links - but that is the prefix autoconfig part of the problem as opposed to the router config part of the problem.) Erik From mcr@sandelman.ca Fri Oct 7 17:17:23 2011 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 394AA21F87FC; Fri, 7 Oct 2011 17:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpeQ2xSKn1cD; Fri, 7 Oct 2011 17:17:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 592BC21F87C9; Fri, 7 Oct 2011 17:17:21 -0700 (PDT) Received: from marajade.sandelman.ca (173-101-76-84.pools.spcsdns.net [173.101.76.84]) by relay.sandelman.ca (Postfix) with ESMTPS id 76986343A4; Fri, 7 Oct 2011 20:19:30 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 96E4598CB4; Fri, 7 Oct 2011 18:44:13 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 921F398CB3; Fri, 7 Oct 2011 18:44:13 -0400 (EDT) From: Michael Richardson To: Rex Buddenberg In-Reply-To: <1317232463.2243.406.camel@localhost.localdomain> References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <1317232463.2243.406.camel@localhost.localdomain> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 07 Oct 2011 18:44:13 -0400 Message-ID: <12459.1318027453@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "Pascal Thubert \(pthubert\)" , C Chauvenet , MANET IETF , Mark Townsley , "Fred Baker \(fred\)" , homenet@ietf.org, rtgwg@ietf.org Subject: Re: [homenet] [manet] Question for you 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, 08 Oct 2011 00:17:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Rex" =3D=3D Rex Buddenberg writes: Rex> Scenario for orientation. Instead of the EMT in the ambulance Rex> having a cellphone to call the emergency room, the EMT will be Rex> armed with several diagnostic gadgets attached to a LAN (either Rex> ethernet or WiFi). And a router. The router will, in turn be Rex> linked to the rest of internet with a radio-WAN. Rex> Scenario implications. Right now, emergency services tend to Rex> rely on a set of high sites -- Monterey County where I live, Rex> has eleven. But the broadband technologies all look better Rex> with an order of magnitude more sites (think schoolhouse roofs) Rex> and consequently more handoffs (aka routing table volatility). Great, but unless you are saying that the EMT is going to use my home network to get more bits through, I don't think this is at all in scope. The EMT have the organization and manpower and mandate to have a managed network. The home network has no manpower, and is seldom organized. (The more geekier the network, the less organized :-)) =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATo+AvYCLcPvd0N1lAQKDxgf/S4/yiS0mpPJ0KoqyJJNiNVlUgU1G16YT r/8thGM0vZwOsL/MRwHbnoQORpQwUyQ0f4XtnKGl4i6y7U8yk3b8rA4np4RqNcQh MyBC+W3zmhwNQq6uFlu8fy6Yql8Gvz1opDmCBzGDtXSGQ6cA8nBaaMteSLX4f9wX baEi0VOXzxFI+V5vBx3Pji6iNj18TiZQ1+10s1/ZPKxbuRDf/fVyzz5BVXDy6yGS QpMH6VE/AGz+M63+s6uX8/sx3seT3WWtXG8+Vk6GZ946Qa5R4Ro7upe7226BMHqh 4ofMyjJFdYe+e0K/HuF6C36aUwXmDSs9WVqCN6qs+K9CYqadfg6GUQ== =EQd1 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Oct 7 17:18:14 2011 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 9E1B921F8B8F for ; Fri, 7 Oct 2011 17:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2iGfbax9ZSP for ; Fri, 7 Oct 2011 17:18:14 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B97B121F8B87 for ; Fri, 7 Oct 2011 17:18:09 -0700 (PDT) Received: from marajade.sandelman.ca (173-101-76-84.pools.spcsdns.net [173.101.76.84]) by relay.sandelman.ca (Postfix) with ESMTPS id 9431F343B0; Fri, 7 Oct 2011 20:20:21 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 9802B98CAD; Fri, 7 Oct 2011 18:38:11 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 934CE98B2E; Fri, 7 Oct 2011 18:38:11 -0400 (EDT) From: Michael Richardson To: Jari Arkko In-Reply-To: <4E7A4CA0.4040302@piuha.net> References: <4E7A46EC.8080109@globis.net> <4E7A4CA0.4040302@piuha.net> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 07 Oct 2011 18:38:11 -0400 Message-ID: <11569.1318027091@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Ray Hunter , Tim Chown , homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 08 Oct 2011 00:18:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Jari" =3D=3D Jari Arkko writes: Jari> Though its not clear to me exactly how that affects the Jari> architecture. Wireless extenders are part of L2 that is not Jari> usually visible, though the other things are perhaps more Jari> visible to l3. Maybe the effects are what we should be talking Jari> about in terms of the requirements. I wanted to point out that one of the complexities in debugging L2 networks that contain things like wireless extenders is exactly that: they are not visible, they don't show up traceroute, you can't address them easily to ask them questions, and the like.=20 I think that these things will go away over time once we are successful. (BTW: I think that proxy-arp might me the solution to bridged IPv4 vs routed IPv6. Proxy-arp has the "feature" that it usually breaks multicast, but that might be a feature for a wireless extender...) > So there may also be a requirement for interconnection of > multiple ultra-short range networks via a house backbone: > e.g. lights on top floor pool to form a mesh network, and lights > in the basement form a mesh network, but the reinforced concrete > floor partitions the two wireless meshes, so you need a routed > connection between them. Jari> I think we do include that already. Its part of being able to Jari> provide a routed, multi-subnet network. Precisely for these Jari> reasons. (But if you are arguing that we should all use some I need to CC the roll list on this part, see next email. >> 3) Virtual machines are exploding. I run 4 VM's on my >> workstation. With the various upcoming application stores and >> multiple application developers running on one system, I could >> easily imagine that each application eventually runs in its own >> mini-VM, so each IPv6 host becomes the equivalent of an old style >> mainframe with multiple prefixes and intra-machine routing. That >> may add another layer of routing to your picture. There may also >> be virtual firewalls between those VM's, which adds another >> layer. Jari> Yep. I have that in my network, too :-) But the question is, Jari> what does it imply in terms of requirements? It at least Jari> implies that we need to support many devices, and probably Jari> even more reason to allow for additional subnets (e.g., to Jari> allow one set of virtual machines exist in their own subnet Jari> inside a physical device). I want amplify something I said today about subnet allocations vs virtual machines. Products like XEN, VMware and VirtualBox have some kernel components which needs to be installed by an administrator. This means that he VM host (the "dom0") can have a (virtual) switch for the guest machines which can be either *bridged* or *routed*.=20=20 (I can't speak to Parallels, but I know it can bridge or NAT) There are advantages to routing, particularly on a laptop that sometimes does not actually have any network connection, and also you have the opportunity to enable the Advanced Security feature in the virtual router. The problem is with things that use QEMU/Bochs based emulation. This includes the Android emulator that comes with the Android SDK.=20 (Note that this emulates an ARM system on an x86 platform). This presently can also include the KVM system in some situations. (KVM is basically native (x86 on x86) emulation with acceleration by using VT extensions.) The issue is that the default configuration is to include a reverse stack in QEMU. It's rather ingenius actually. It basically turns a TCP SYN packet into a call to the OS connect(2) call. The result is NAPT, and default "Simple Security" sans PCP. It's possible to configure QEMU to instead bridge to a virtual interface, but it's not default, because that setup requires superuser to configure, and it doesn't work at all (AFAIK) on windows or OSX.=20 Is this really an issue for the IETF? Not really, things can be made to work, but my concern is that a typically KVM/QEMU user could, if the router code is built-in to the QEMU, rather than into the operating system, wind up allocating a prefix each time they boot up a single VM, and while they might not run a lot of VMs at the same time, they might well run many different VMs sequentially.=20=20=20 How and who do we inform when we have run out of prefixes? =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATo98p4CLcPvd0N1lAQL6hwf+PbkdK6TfPUOJzofDfibXHJW7AohmHeuX +8JXSd6q8Nv5/4D2ZrnHPTJO77R4/p3jabBzr8EpfgPaOTthgMmyQZO6QTQcf2rn 45nyFoHi9yeP6J7ORE7R3AQKN9PYWTgOida7J4WbCo6IwaWKGK2zhSXf2Y4VdcKQ HcLEKNTq+yoSOBe8+X6RBFndOeJdBT5y3UoE2OWf9RU3R8te7tuntqN1et24DhWl hPMlZS3RBAz1/8RuA/vIvYTwocXPK/UVYbXQc8FRZ6Uq+0XZ7krAYDs81l4iJVIi EwqZrcUxRdyli8vrx61tsFCtulVrIUjbhu/6lrLBLOsdhkXa/RzloQ== =A1Pd -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Oct 7 17:18:32 2011 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 DCF5021F8B8F for ; Fri, 7 Oct 2011 17:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbRmfHovErld for ; Fri, 7 Oct 2011 17:18:32 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9D21F89B8 for ; Fri, 7 Oct 2011 17:18:32 -0700 (PDT) Received: from marajade.sandelman.ca (173-101-76-84.pools.spcsdns.net [173.101.76.84]) by relay.sandelman.ca (Postfix) with ESMTPS id 7929F343AE for ; Fri, 7 Oct 2011 20:20:21 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 5ECCB98CB5; Fri, 7 Oct 2011 20:16:53 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5BDBF98CB1 for ; Fri, 7 Oct 2011 20:16:53 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 07 Oct 2011 20:16:53 -0400 Message-ID: <14431.1318033013@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] scope questions as a result of interium meeting 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, 08 Oct 2011 00:18:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable For those that weren't present today, the meeting space (The Hub) had mostly unuseable natwork today. I measured 50-70% packet loss (curiously, my managed IPv6 tunnel had 20% less loss)... and I mostly could not sustain a TCP connection long enough to even get email. I don't know what kind of network connection or what kind of wifi access point, or what kind of router they have there. The reason I ask, is because 70% chance that it was really a "consumer" grade, and I might even bet that it was running some WRT variation. It didn't get fixed during the day, nor do I know if the problem was even local. The reason I say all of this, is that we were sitting there, a room full of the smartest network geeks around, and we were 100% powerless to do anything. We couldn't even find out what was wrong, let alone fix=20 attempt to fix anything. This situation is kinda useful as a common data point for failures: how would our proposed solution have faired? If the problem wasn't local, would our proposed multi-ISP solution have helped? Would happy-eyeballs have kept us happy? So I'm curious what the problem was, why it took more than 1-2 hours to resolve. The second question I have is deeper: we had at least 10 smartphones with 3G+wifi connectivity. I wasn't going to volunteer mine due to excessive cost of international roaming data rates, but many were=20 locals. We had a common "LAN" (the THEHUBPUBLIC wifi)... if we had had running code available... could we, the doctor, have healthed ourselves? So, perhaps it is more clear to some, why I keep going on about the fact that due to smartphones, pretty much EVERY HOME is a multi-ISP home. (Imagine that eh, running ospfv3 in your pocket?) =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATo+WdICLcPvd0N1lAQK2lggAmShAsEkdcqLlLiElUw52qaBwCYMBW2yw ftWWXzbjpjpsHNnfzOIKNwDtmpodbfKS9nT7uSXz8PNTvJYbFXx+aB0Bk4VmHN5d RZdu73EPHf+zMpmkjiPPgEHgJw1N4reqhdFOFxCAyYdwpHpacdjO3cQsBa8zvs9a iAzFSLuUWh/ADpMhUPKLfBeMgbI59GaUKkotMukDYNFoBC7mVws7CAz7p4PG3u2P 4aX1II4L6SqiUictNM1CI9XmKdObIGMf2qSXny2fbi/3IcDnOwvfLULLzgC975jA dN+7rqs3T5sEodRk0BZBk673nIrNydHR6tqSApwsRqJ9jorSZ0daxA== =LGeg -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Oct 7 17:29:28 2011 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 A8D1B21F8C0C; Fri, 7 Oct 2011 17:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIn2i3yJzznE; Fri, 7 Oct 2011 17:29:27 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 49DC521F8C14; Fri, 7 Oct 2011 17:29:27 -0700 (PDT) Received: from marajade.sandelman.ca (173-101-76-84.pools.spcsdns.net [173.101.76.84]) by relay.sandelman.ca (Postfix) with ESMTPS id 7A7673427C; Fri, 7 Oct 2011 20:31:35 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 23FAE98CAE; Fri, 7 Oct 2011 18:38:19 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 1A8E998B2E; Fri, 7 Oct 2011 18:38:19 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org, roll@ietf.org In-Reply-To: <4E7A4CA0.4040302@piuha.net> References: <4E7A46EC.8080109@globis.net> <4E7A4CA0.4040302@piuha.net> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 07 Oct 2011 18:38:19 -0400 Message-ID: <11595.1318027099@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 08 Oct 2011 00:29:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This is a conversation that started on the Homenet list. > So there may also be a requirement for interconnection of > multiple ultra-short range networks via a house backbone: > e.g. lights on top floor pool to form a mesh network, and lights > in the basement form a mesh network, but the reinforced concrete > floor partitions the two wireless meshes, so you need a routed > connection between them. Jari> I think we do include that already. Its part of being able to Jari> provide a routed, multi-subnet network. Precisely for these Jari> reasons. (But if you are arguing that we should all use some If you plug two RPL root bridges into two ports of an ethernet switch, they will happily link your lighting network together. That's something that I think that might not have been clearly stated in the discussion at today's interim meeting: RPL might not be hidden behind the ethernet/802.15.4 router, it might use the ethernet to connect different zones. So, don't be surprised if you see RPL ICMPv6 messages crossing some of the inside lans. Continuing along the thought process that stuff should just work, regardless of how grandma plugs things in... it would therefore be nice if RPL could bridge across a routed homenet lan. This would work, I think, if the RPL ICMPv6 DIOs, which are currently multicast to a link-local group by default, could instead on a RPL node with an uplink, send to a site-local ULA multicast group.=20=20 This is also not strictly necessary: the upstairs and downstairs RPL meshes, if they allocate ULA prefixes as we have discussed, simply route across the homenet LAN, and probably things will work. Where this might fail is if the P2P mechanism in RPL was being used, because it basically forms a temporary DAG across the mesh find the most direct route. If the best route is via the homenet, it won't be found if the two meshes are partitioned. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATo9+IICLcPvd0N1lAQIj7wgAgqowGY0MAHkFV4541q8mWk86/Zjm5f9P GucOpy2yCp0L5VXpXDtt/DspghFpnOh5eniGpg44qlBrLj1CW1CtsRZu+bFuqoU2 KCWzuoen4iqpJPKudDOUKpfDiN8qiN+ClDhioWyJZbwgd6x51icxEPpx65mxA+Hq HaGhc6zWx8zxlpzHVAmiaLBmRn8q9aHYY5g340hsSBhFY261npekXsA6sjzc1WaD fy11B+s9+kDGCdPi6PGzC9t7rWbanWcu7Z/n6VkoNM56BgkW8f0AulblabjD9I0U i4OP1dOq/I7F/ZiTDj+ZWkZRzemm0a7obgk+dNAbc9yKMgjFDCVkNw== =xubg -----END PGP SIGNATURE----- --=-=-=-- From Ray.Bellis@nominet.org.uk Fri Oct 7 18:25:17 2011 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 1B2D321F8BCB for ; Fri, 7 Oct 2011 18:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.001 X-Spam-Level: X-Spam-Status: No, score=-9.001 tagged_above=-999 required=5 tests=[AWL=1.598, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nELoQTiRPvZ7 for ; Fri, 7 Oct 2011 18:25:16 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30421F8B8F for ; Fri, 7 Oct 2011 18:25:15 -0700 (PDT) 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=SGAQilBPRZPw85ELUB0q8Yt7ZHesdOCZrl2aCC8efP+qusRji+AAFmGj ZFG/vmwfr097QsVE+Fu3S4jgw+Ubs+RT9UxptUIA3Qy/j7BoCcjxfBCsV 8SrJZowVLnzFQsb; 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=1318037311; x=1349573311; 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]=20scope=20questions=20as=20a =20result=20of=20interium=20meeting|Date:=20Sat,=208=20Oc t=202011=2001:28:21=20+0000|Message-ID:=20<732D3569-A5BC- 4105-A480-4EE86F3648C7@nominet.org.uk>|To:=20Michael=20Ri chardson=20|CC:=20"" =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20<14431.1318033013@marajade.sandelman.ca> |References:=20<14431.1318033013@marajade.sandelman.ca>; bh=fMx5F4IRKuhjcSafXOQmN9MUnHcT0nMQO0wjyw/2jNs=; b=fMkBeTtqHWqKB6kw2O9ddQZTHyimBbOgsw9gltAklYPGqbOm5ZrsiClR VsN8RXruD6Q2KugM+80X2+JFWSFwWig2lRlhe1kl/bhJa5LfIY5pxegV1 6UU+EgdZnIyEw6S; X-IronPort-AV: E=Sophos;i="4.68,505,1312153200"; d="scan'208";a="28848366" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 08 Oct 2011 02:28:22 +0100 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%19]) with mapi; Sat, 8 Oct 2011 02:28:22 +0100 From: Ray Bellis To: Michael Richardson Thread-Topic: [homenet] scope questions as a result of interium meeting Thread-Index: AQHMhVBJ05ufeNe2TUK4bOewDZekh5Vxl7yA Date: Sat, 8 Oct 2011 01:28:21 +0000 Message-ID: <732D3569-A5BC-4105-A480-4EE86F3648C7@nominet.org.uk> References: <14431.1318033013@marajade.sandelman.ca> In-Reply-To: <14431.1318033013@marajade.sandelman.ca> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [homenet] scope questions as a result of interium meeting 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, 08 Oct 2011 01:25:17 -0000 On 7 Oct 2011, at 20:16, Michael Richardson wrote: >=20 > I don't know what kind of network connection or what kind of wifi > access point, or what kind of router they have there. The reason I ask, > is because 70% chance that it was really a "consumer" grade, and I might > even bet that it was running some WRT variation. There didn't appear to be an HTTP server running on the default NAT gateway= , so that would rule out _most_ consumer grade devices. I didn't run any p= robes beyond that. > It didn't get fixed > during the day, nor do I know if the problem was even local. We were told that it was an issue with the building's managed service, and = the word "fibre" was used. Ray= From fred@cisco.com Fri Oct 7 19:12:33 2011 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 A972821F87C2 for ; Fri, 7 Oct 2011 19:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7f83e4baoqv for ; Fri, 7 Oct 2011 19:12:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0729C21F8726 for ; Fri, 7 Oct 2011 19:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1049; q=dns/txt; s=iport; t=1318040148; x=1319249748; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=NKiOZocQrZhnICfYBEI+jcH7EVewuKwvYZjS9+cZTgM=; b=UyPPfo+CM7Cyf0IjpU4cicyWV2vcwSDU97XRH1AehraDQxkpziCzfamE uItP/CEGH8iuMDsvxtl4fB5/O3lP+FFor9HmBoyE03FAcZ3S88Bv5sahb eRICW6AtBbrsfEm4czrSjwudSxBRqggp7yKp+x2dDbwno4VAIEEiL8GMJ Q=; X-IronPort-AV: E=Sophos;i="4.68,505,1312156800"; d="scan'208";a="26924124" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 08 Oct 2011 02:15:47 +0000 Received: from Freds-Computer.local (rtp-vpn4-1288.cisco.com [10.82.213.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p982FktG012597; Sat, 8 Oct 2011 02:15:46 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 07 Oct 2011 22:15:46 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 07 Oct 2011 22:15:46 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E8F829C.9040902@cisco.com> Date: Fri, 7 Oct 2011 22:15:41 -0400 Message-Id: <28169CAC-6748-4C68-AE9F-2102C6243572@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8F829C.9040902@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , homenet@ietf.org, homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing 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, 08 Oct 2011 02:12:33 -0000 On Oct 7, 2011, at 6:52 PM, Erik Nordmark wrote: > On 10/7/11 12:48 AM, Fred Baker wrote: >> I suggested that the probability of use of each of the scenarios on = slide 4 were >> single router network: 90th percentile >> tree network: unusual >> multi-router: perhaps 5th percentile >> multihomed: unusual >=20 > Fred, >=20 > are the above numbers based on any survey data? They are as scientific as the end of my thumb :-) > Reason I'm asking is that I have two consumer devices with IPv4 NAT in = my home (a VoIP box and a backup device) where the instructions said: > 1. Insert between or existing router (or PC if you have no router) and = the DSL/cable modem > 2. Insert between your PC and your existing router (or modem if you = have no router) >=20 > Those consumer instructions naturally result in a daisy-chain of IPv4 = RGs/NATs, which is a subset of a tree topology. >=20 > I can't be the only person who have a VoIP box or a Time Capsule. >=20 > Erik From fred@cisco.com Fri Oct 7 19:13:58 2011 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 8DF1021F87C2 for ; Fri, 7 Oct 2011 19:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3dPXaN1j6ep for ; Fri, 7 Oct 2011 19:13:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABA221F85D1 for ; Fri, 7 Oct 2011 19:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1206; q=dns/txt; s=iport; t=1318040233; x=1319249833; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=3rHzI3QfC7/mvaQkRYWiqwRwzys5w2xWeKcPgwAZJgE=; b=U+5JLJs+0n56kGJYlBzrHqyw7NKKCcoCjTCX4W9lilpHuQXn8NUI6Jxg xWl6jMn/aNzyNMCE6VMJ8cRc1FOL3CUHIbm0pyfXZkn5i9s70RgYUyuvM yZ4LF0/4pPAoK0SY4NYay5i6ffgaK/Ln7Ql4ATgEQAIPokv84XEbeIeH4 c=; X-IronPort-AV: E=Sophos;i="4.68,505,1312156800"; d="scan'208";a="26927727" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 08 Oct 2011 02:17:11 +0000 Received: from Freds-Computer.local (rtp-vpn4-1288.cisco.com [10.82.213.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p982HAAk003288; Sat, 8 Oct 2011 02:17:11 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 07 Oct 2011 22:17:11 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 07 Oct 2011 22:17:11 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E8F8368.5070304@cisco.com> Date: Fri, 7 Oct 2011 22:17:05 -0400 Message-Id: References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> <4E8F8368.5070304@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org, Jari Arkko Subject: Re: [homenet] Thoughts about routing 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, 08 Oct 2011 02:13:58 -0000 On Oct 7, 2011, at 6:55 PM, Erik Nordmark wrote: > On 10/7/11 3:28 AM, Fred Baker wrote: >> The other parameters in question include >> - the interface prefix itself, which could be derived as in zospf, >> - the area number (I'd suggest it default to zero), >> - the router ID (a random 32 bit number), and >> - security information. >=20 > Fred, >=20 > Do existing OSPF implementations have the ability to pick a random = router ID, and detect when there is a router ID collision? OSPFv2 implementations generally pick one of the IPv4 addresses of the = system. Not sure I can make a general comment on OSPFv3. > One benefit of using IS-IS is that the router ID is longer and based = on a factory-assigned IEEE MAC address. > The zospf appears to have an approach for router ID collisions, but = that probably isn't (widely) implemented. ZOSPF is, AFAIK, an internet draft that has never been implemented. > (In any case, we'd need to figure out what it means to have stable = prefixes allocated - to interfaces or to links - but that is the prefix = autoconfig part of the problem as opposed to the router config part of = the problem.) >=20 > Erik >=20 From a-nakagawa@nbpo.jpix.ad.jp Sat Oct 8 02:03:12 2011 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 3472D21F88B7 for ; Sat, 8 Oct 2011 02:03:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7fRPaOYcLpp for ; Sat, 8 Oct 2011 02:03:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0421F8888 for ; Sat, 8 Oct 2011 02:03:11 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4553072vcb.31 for ; Sat, 08 Oct 2011 02:06:25 -0700 (PDT) Received: by 10.220.188.70 with SMTP id cz6mr840489vcb.134.1318064784010; Sat, 08 Oct 2011 02:06:24 -0700 (PDT) Received: from [184.49.148.118] (dhcp184-49-148-118.whfp.phl.wayport.net. [184.49.148.118]) by mx.google.com with ESMTPS id cx10sm2415248vdb.11.2011.10.08.02.06.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Oct 2011 02:06:23 -0700 (PDT) Date: Sat, 08 Oct 2011 18:06:22 +0900 From: Akira Nakagawa To: homenet@ietf.org Message-Id: <20111008180559.008B.8A9D23A3@jpne.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.54 [ja] Subject: [homenet] Japanese Home Router Guideline 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, 08 Oct 2011 09:10:23 -0000 Here is the Home Router Guideline in Japan that I introduced at the meeting yesterday. Ver.1 in Enalish (2009.06.22) http://v6pc.jp/pdf/v6hgw_Guideline_1_0-English.pdf Ver.2 in English Publish soon... Ver.1 in Japanese (2009.06.22) http://v6pc.jp/jp/upload/pdf/v6hgw_Guideline_1.0.pdf Ver.2 in Japanese (20010.07.29) http://v6pc.jp/jp/upload/pdf/v6hgw_Guideline_2.0.pdf Akira From acee.lindem@ericsson.com Sat Oct 8 03:32:49 2011 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 799AA21F8512 for ; Sat, 8 Oct 2011 03:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-jTdF9liRzn for ; Sat, 8 Oct 2011 03:32:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D524D21F8507 for ; Sat, 8 Oct 2011 03:32:48 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p98AZwTS018940; Sat, 8 Oct 2011 05:35:59 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 8 Oct 2011 06:35:52 -0400 From: Acee Lindem To: Erik Nordmark , Ole Troan Date: Sat, 8 Oct 2011 06:35:52 -0400 Thread-Topic: [homenet] Homenet strawman slides Thread-Index: AcyFPa4aUN1WRl9JTo6B2qwdaiBurgAZ6H93 Message-ID: References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> , <4E8F7873.4050505@cisco.com> In-Reply-To: <4E8F7873.4050505@cisco.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" , Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 08 Oct 2011 10:32:49 -0000 Hi Erik,=20 My opinion is that OSPF auto-configuration is a separate draft from using O= SPF for prefix assignment within the routing domain. The zOSPF draft would = not be used as is - the work from 2002 would be acknowledged but we'd start= with a clean slate.=20 In answer to your other question, I don't there are any implementations of = OSPF or ISIS that support auto-configuration today since there has, heretof= ore, not been a strong requirement.=20 Thanks, Acee ________________________________________ From: homenet-bounces@ietf.org [homenet-bounces@ietf.org] On Behalf Of Erik= Nordmark [nordmark@cisco.com] Sent: Friday, October 07, 2011 6:08 PM To: Ole Troan Cc: homenet@ietf.org; Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides On 10/7/11 2:18 PM, Ole Troan wrote: >>> I think it's >>> reasonable to write to stable storage whenever you configure a new >>> prefix or change an existing prefix (but not if you simply refresh it). >>> If the router comes back up and nobody has the prefix, it would simply >>> claim it back. If someone else has it, it would have to just form a new >>> one using loop detection. >> >> In your view, if there is a single prefix assigned to the home by the IS= P, and there are three routers connected to a particular link in the home, = would each of those three routers assign a different prefix to the link? >> >> Am I missing something? > > see the zospf draft. the DR of the link will assign the prefix for the li= nk. the BDR should also store that chosen prefix into stable storage. of co= urse if you power off both the DR and the BDR and power up a new 3rd router= , the link will get a new prefix. The zospf draft (see section 3.6) declares a conflict if two routers attached to the same link pick the same IP subnet prefix for that link. That doesn't seem what we want. And zospf doesn't talk about using stable storage; doesn't seem to have any notion of providing stable prefixes assigned to the links. Thus this problem remains to be solved AFAICT. I think we first need to agree on what we think are the requirements on prefix stability. What if one of the routers attached to the link fails and is replaced by a different router? What if a link partitions? And later merges? What the user intentionally splits (partitions) a link (e.g., to create a separate link for the teenage game room); should the network automatically pick a new prefix for that new link? (How does that interact with the prefix being in stable storage on the router.) One thing to keep in mind as we think about these requirements is that if the user has created a bridged Ethernet with no routers, all of the above will work naturally; might take seconds to relearn when the topology changes but there is no manual intervention needed. Is that the goal for this prefix assignment? Who is working on the requirements document? ;-) Erik _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From jari.arkko@piuha.net Sat Oct 8 06:01:25 2011 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 B383C21F8B65 for ; Sat, 8 Oct 2011 06:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b40aj4wZeo8Q for ; Sat, 8 Oct 2011 06:01:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1913D21F8B61 for ; Sat, 8 Oct 2011 06:01:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 013152D565; Sat, 8 Oct 2011 16:04:41 +0300 (EEST) 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 mVWdj9-3PQKk; Sat, 8 Oct 2011 16:04:39 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3F29C2CE32; Sat, 8 Oct 2011 16:04:39 +0300 (EEST) Message-ID: <4E904A66.9020603@piuha.net> Date: Sat, 08 Oct 2011 09:04:38 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Fred Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Interim: Looking for folks in Philadelphia this evening 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, 08 Oct 2011 13:01:25 -0000 Oh. Had I seen this e-mail earlier I would have joined you. I'm also still here, no time to stay for NANOG but I won't leave until the evening. I'm going to rent a bike and tour the city today. If anyone else wants to join, I'll start around 10 AM and I can be reached before that at this e-mail address. Jari On 07.10.2011 15:38, Fred Baker wrote: > If there were a "interim attendees" list, I'd send this to that one. Apologies to anyone coming back five years after today's date and reading this in the archive... > > I'm here this weekend, staying for NANOG. I left early this afternoon because I have some phone calls; the day job intrudes. If anyone would like a dinner companion, please feel free to send me a text message or call at +1-805-637-0529. Barring such, I'll likely go to the Hard Rock this evening, as it's across the street from the Loew's Hotel, which is where I am. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From jari.arkko@piuha.net Sat Oct 8 06:09:50 2011 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 6F60A21F8B18 for ; Sat, 8 Oct 2011 06:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf1HEgnoiZhT for ; Sat, 8 Oct 2011 06:09:50 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D240521F8A66 for ; Sat, 8 Oct 2011 06:09:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3A0B02D565; Sat, 8 Oct 2011 16:13:04 +0300 (EEST) 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 b+UzAsv3FH5s; Sat, 8 Oct 2011 16:13:03 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2F75A2CE32; Sat, 8 Oct 2011 16:13:03 +0300 (EEST) Message-ID: <4E904C5D.5090908@piuha.net> Date: Sat, 08 Oct 2011 09:13:01 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Lorenzo Colitti References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 08 Oct 2011 13:09:50 -0000 I like this, with the possible exception of using ULAs and your desire to deprecate prefixes as soon as connectivity goes down. (Speaking as someone whose prefixes got invalidated two months ago but who hasn't been home long enough to fix the problem, but my devices still happily communicate with each other using the old prefixes :-) I also agree with Erik that loop and arbitrary topologies is not really required. But the people in the interim at least seemed to say yesterday that we want to go there. I am interested in trying to write up a solution. Jari From jari.arkko@piuha.net Sat Oct 8 06:11:45 2011 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 C997621F8B6D for ; Sat, 8 Oct 2011 06:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlcsDAmyciF6 for ; Sat, 8 Oct 2011 06:11:45 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 310D821F8B47 for ; Sat, 8 Oct 2011 06:11:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 193DD2D565; Sat, 8 Oct 2011 16:15:01 +0300 (EEST) 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 IJ1eX2ToKtva; Sat, 8 Oct 2011 16:15:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B3E352CE32; Sat, 8 Oct 2011 16:14:59 +0300 (EEST) Message-ID: <4E904CD2.1080705@piuha.net> Date: Sat, 08 Oct 2011 09:14:58 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Erik Nordmark References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> <4E8F7873.4050505@cisco.com> In-Reply-To: <4E8F7873.4050505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ole Troan , homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 08 Oct 2011 13:11:45 -0000 Erik, > And zospf doesn't talk about using stable storage; doesn't seem to have any notion of providing stable prefixes assigned to the links. > > Thus this problem remains to be solved AFAICT. The draft is useful background, but I think some work remains. Maybe even a lot of work. So yes. > > I think we first need to agree on what we think are the requirements on prefix stability. What if one of the routers attached to the link fails and is replaced by a different router? > What if a link partitions? And later merges? > What the user intentionally splits (partitions) a link (e.g., to create a separate link for the teenage game room); should the network automatically pick a new prefix for that new link? (How does that interact with the prefix being in stable storage on the router.) We talked about the stability requirements on Thursday a bit. From my perspective the requirement is that crashes, power outages/recycles, and addition of new devices must not cause existing allocations to change. Other changes.... they may, and I think it would be too much effort and complexity to try to prevent all changes in all situations. > > One thing to keep in mind as we think about these requirements is that if the user has created a bridged Ethernet with no routers, all of the above will work naturally; might take seconds to relearn when the topology changes but there is no manual intervention needed. > Is that the goal for this prefix assignment? > > Who is working on the requirements document? ;-) Ole was working on the slides for the requirements, but many of the entries probably need some further details. (Like Mark, I think it would be probably more worthwhile to move a bit back and forth between solutions and requirements rather than make a pure requirements list.) Jari From jari.arkko@piuha.net Sat Oct 8 06:11:59 2011 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 B61B321F8549 for ; Sat, 8 Oct 2011 06:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-fEwEWo3W3Q for ; Sat, 8 Oct 2011 06:11:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2F86221F8538 for ; Sat, 8 Oct 2011 06:11:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 20C082D565; Sat, 8 Oct 2011 16:15:13 +0300 (EEST) 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 GXxvo6EfLcHY; Sat, 8 Oct 2011 16:15:12 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 331B12CE32; Sat, 8 Oct 2011 16:15:12 +0300 (EEST) Message-ID: <4E904CDF.8040004@piuha.net> Date: Sat, 08 Oct 2011 09:15:11 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Erik Nordmark References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> In-Reply-To: <4E8F5E8B.4010102@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 08 Oct 2011 13:11:59 -0000 Erik, > In your view, if there is a single prefix assigned to the home by the ISP, and there are three routers connected to a particular link in the home, would each of those three routers assign a different prefix to the link? > > Am I missing something? I think we need efficient prefix assignment (no double or triple assignments) and stability. I think this still needs some work, but should be doable. Jari From mcr@sandelman.ca Sun Oct 9 08:32:51 2011 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 D663C21F8A69 for ; Sun, 9 Oct 2011 08:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpMKq5LSKzRG for ; Sun, 9 Oct 2011 08:32:51 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5085321F877F for ; Sun, 9 Oct 2011 08:32:48 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 5272E343B0; Sun, 9 Oct 2011 11:31:45 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id A19E398CAD; Sun, 9 Oct 2011 11:33:37 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 99E8B98C90; Sun, 9 Oct 2011 11:33:37 -0400 (EDT) From: Michael Richardson To: Erik Nordmark In-Reply-To: <4E8F829C.9040902@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8F829C.9040902@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 09 Oct 2011 11:33:37 -0400 Message-ID: <27415.1318174417@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 09 Oct 2011 15:32:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Erik" =3D=3D Erik Nordmark writes: Erik> Reason I'm asking is that I have two consumer devices with Erik> IPv4 NAT in my home (a VoIP box and a backup device) where the Erik> instructions said: 1. Insert between or existing router (or PC Erik> if you have no router) and the DSL/cable modem 2. Insert Erik> between your PC and your existing router (or modem if you have Erik> no router) Erik> Those consumer instructions naturally result in a daisy-chain Erik> of IPv4 RGs/NATs, which is a subset of a tree topology. That's a good point: many VoIP ATAs want to be the first device so that they can control the QoS, and ideally get the public IP address. Does your VoIP box do PPPoE as well?=20=20 Or did I misunderstand. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpG+0YCLcPvd0N1lAQKrjQgAhbKv02qMIRp/KfYL7yEl127suC4XcgUO l7IY/vuRylImMdEVEvY9jeUSm47bfoHG4XQZyOZax9V3ILs0uwMzXCOtvz6lVbBo xeLf8bnT8lvWTvq1u3rfx6bIKRAjwEcpMuSHiGT8FTgdiaVmrTrRD6PTFnJDPxl9 uzN+jBkucd6vxv5aPL/onISmdI8kwxo1zAJj2V1Yw0bhGtuyUYiY9qXSa9p5S6jK FMTTD8pJAOg8Bh2iy1L1Lq4m6q45n9MQuhSiJP2I32YKgYHsyyInBjI1vlYq/IEJ A17vv1ozVqQ42NWfyelQ+oHIqMNmVGsxmCfcCaHYeWOX72GgBr0PJQ== =IzLt -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Oct 9 09:07:07 2011 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 A41AA21F8B36 for ; Sun, 9 Oct 2011 09:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.715 X-Spam-Level: X-Spam-Status: No, score=0.715 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZi2hzLk18JQ for ; Sun, 9 Oct 2011 09:07:07 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F114321F8906 for ; Sun, 9 Oct 2011 09:07:06 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id A2EB8343A4 for ; Sun, 9 Oct 2011 12:06:00 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id C5D6598CAD; Sun, 9 Oct 2011 12:07:52 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id BCF2D98C90 for ; Sun, 9 Oct 2011 12:07:52 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 09 Oct 2011 12:07:52 -0400 Message-ID: <31922.1318176472@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] lifetime on prefixes vs lifetime of address grants 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, 09 Oct 2011 16:07:07 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Fred, I've changed the subject, I hope to shed more light. >>>>> "Fred" =3D=3D Fred Baker wrote: Fred> But also, the notion of tying the lifetime of a prefix on the Fred> LAN with the lifetime of the prefix grant seems Fred> ill-considered. The purpose of the lifetime on the prefix Fred> grant (RFC 3363) is to enable an upstream to not need to be I think you meant RFC3633 here right? (DHCP-PD) I think that we clarified in discussion that the lifetime of prefix advertised was limited to be no more than the lifetime in the PD. It could be much lower. Fred> asked every 30 seconds for something it wants to leave Fred> unchanged for a long period of time and yet make "a long time" Fred> not be "forever". That's reasonable. But in the case called Fred> out here, it seems like the lifetime of the prefix in an RA Fred> should be long enough that a host can miss an RA refresh and Fred> not lose the address, and short enough that we don't have to Fred> call in the national guard if someone trips over a cable or a Fred> power supply goes spitzensparken. Fred> What do we need to do to change that RFC 4861 requirement? If Fred> what is required is an Internet Draft in 6man (and I would Fred> expect it is), I'd be willing to write that draft. I'm trying to understand things here. We have, I think four lifes times around a homenet: 1) DHCPv6 PD 2) Router Lifetime. 3) Prefix Valid Lifetime 4) Prefix Preferred Lifetime We expect #1 to be large, on the order of weeks in most cases, lowered only to minutes in the cases where operators expect to move users around (such as rebalancing the load on the CMTS). I expect the router lifetime to be on the order of minutes so that a host stops using a route sooner. We could modify this more if a host follows the rules of RFC4191 Type C. I'm unaware of any Linux machines being Type C, and I haven't seen *BSD do this, although maybe OSX does. Except for being limited by #1, it seems that we want to have a Preferred Lifetime rather low only in the multi-router case.=20=20 Maybe the right answer is dynamic: as soon a router, see another LSA, they lower their Preferred Lifetime so that if there is a chance to survive a topology change, then the host has a better chance of doing so without having the wrong address for that link for too long. I admit that I still don't really understand how I should set my valid lifetimes. It seems that they can be quite high in general. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpHG2ICLcPvd0N1lAQIpsQgArJtgNIkXgmpzStU6aPtIjM4DgFVdKlfx zMPSIZimpF6C9/Qfvyqe1wF5/Ed44uFNWegWS083HisWHr7JkP77/vMDtw1VKxU0 6KZCIRFGOmotPa1Q3H0rMhLJFaV72ckpHriXz80ef75hFu8aoqQhSeNY4ehnBAj/ 2lrX/MYo0DeYA5eXst4qFco7CWWpHSXmWhMk6StPRlBKQ71Tti3Re3TOBDzo7p67 RY+eh50KDkDsWtm0WRa0GU2Nbjg6AzNQXEoGsCMXb+z3mYbRyDtPpmOKfUXp9hkb 62BsQ5vQSSWwN9rw2Weny+AEIWWNXBFqwismrrVrIyvYG3AbSEabgQ== =tLN6 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Oct 9 09:33:55 2011 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 CAF9121F8876 for ; Sun, 9 Oct 2011 09:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.605 X-Spam-Level: X-Spam-Status: No, score=0.605 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyGJjir68Lol for ; Sun, 9 Oct 2011 09:33:55 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 429B221F87C2 for ; Sun, 9 Oct 2011 09:33:55 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id DA8A6343A2; Sun, 9 Oct 2011 12:32:51 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 0794C98CAD; Sun, 9 Oct 2011 12:34:40 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 02A3698C90; Sun, 9 Oct 2011 12:34:40 -0400 (EDT) From: Michael Richardson To: Erik Nordmark In-Reply-To: <4E8F5E8B.4010102@cisco.com> References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 09 Oct 2011 12:34:39 -0400 Message-ID: <3456.1318178079@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 09 Oct 2011 16:33:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Erik" =3D=3D Erik Nordmark writes: >> I think it's reasonable to write to stable storage whenever you >> configure a new prefix or change an existing prefix (but not if >> you simply refresh it). If the router comes back up and nobody >> has the prefix, it would simply claim it back. If someone else >> has it, it would have to just form a new one using loop >> detection. Erik> In your view, if there is a single prefix assigned to the home Erik> by the ISP, and there are three routers connected to a Erik> particular link in the home, would each of those three routers Erik> assign a different prefix to the link? Erik> Am I missing something? If you had three routers concurrently, then using OSPF terminology, then only one router would become the Designated Router, and it would announce the prefix. The others would have to agree to remember that prefix for that link.=20 If, however, you decided to try three routers in a sequential way (trying each one out to see if you liked it...), then would get three prefixes assigned to that link, and remembered by each router. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpHNH4CLcPvd0N1lAQLGPAgAiJ1IzLFg88qYfrC1wb9/hG2Aq9vSnxCN 5CyOzf0FN63qgOeE2U6tkwXI8V0ABpnZGbN/lzOx/XslB7JNrpecGFQlVKzbZvxe 14pknudHLlfZdEk3H2lI6IpXJDVDRmrRM0l1TNlNs9cCA3mF+FsHhOVwBUhaYgBw t3UPbJPqcxPeoosRd7spDc1ox9/T9N60+7/0KrFUDtfawyuz905KXUpozaS9JxcJ 6aAMckgIBhO3jX7oPTwenV+NLifPCXmxWL0BMIuyT/VXPpmlJILO0tteuUe7nnxh Gk3t557IW/Yb5YIOGjkerEv2z7ucHGUwwXo1ijuHqZ0Oy+G5RF4j+A== =O7YC -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Oct 9 09:43:21 2011 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 B280A21F8B48 for ; Sun, 9 Oct 2011 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gRNn-9cqy4d for ; Sun, 9 Oct 2011 09:43:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E825721F86EE for ; Sun, 9 Oct 2011 09:43:20 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id E130E343B1 for ; Sun, 9 Oct 2011 12:42:16 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6362D98CAD; Sun, 9 Oct 2011 12:44:09 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5EDCB98C90 for ; Sun, 9 Oct 2011 12:44:09 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4E8F7B69.9000603@cisco.com> References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> <4E8F7B69.9000603@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 09 Oct 2011 12:44:09 -0400 Message-ID: <4831.1318178649@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Homenet strawman slides 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, 09 Oct 2011 16:43:21 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Erik" =3D=3D Erik Nordmark writes: Erik> I think what you are saying is that it is fine if the Erik> deployment of IPv6 encourages folks to create the R3/R2 loop Erik> above, even if that makes IPv4 fail. I think that the word "encourages" is wrong. "Permits" is the keyword. Joe can easily create a network today that does not work.=20=20 Just plug his DSL model into a LAN port on the "router", or confuse his 8-port switch with his 8-port home router. What we are saying is that, the IPv6 portion of the network SHOULD continue to work, even if the topology can never work for IPv4. We had a brief discussion (making it out-of-scope very quickly) about whether or not the loop detection that IPv6 would provide could be communicated (by a vendor, inside their box) to their IPv4 side, which would permit them to turn off the R3/R2 loop for IPv4, making things work. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpHPWYCLcPvd0N1lAQITlwgArhyEP02vw58mSxc6KHF62D3lAymwPxpP kII9z5U5BBVnNUzk9idZ9/EArF7lamSx+OTC93aKG8ps5tClMmXvouF5aFB0Im53 S9gx7nUCumMYMvq0sOECzO5a2gDT/1SJJgXOXYOVy8g/sT2Xm1Q2xn/B2lKPEQO6 QDvdIyxyOuknR0gE4IfpkIDUCc0CLKSBjleXKGNwNf9GnYz0wZ38kxdH6dMd5tTH f8KmGVUU6NSz72ma8/JzZeL6VmmjUhl/olW3Yg/6vBjCpSc070PUBhZ6KlSiXRiH 9D80VAFspqwAS5odBvAfnmkfoaH9HV0UP2RMQo/zeSyONCuxB5/nFA== =SqyK -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Oct 9 10:43:11 2011 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 CBB3721F867F; Sun, 9 Oct 2011 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.355 X-Spam-Level: X-Spam-Status: No, score=0.355 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1Tia8vNhmMw; Sun, 9 Oct 2011 10:43:08 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id EADA621F8672; Sun, 9 Oct 2011 10:43:07 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id A31B2343B0; Sun, 9 Oct 2011 13:42:03 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 7EBAD98CAD; Sun, 9 Oct 2011 13:43:55 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 7B50C98C90; Sun, 9 Oct 2011 13:43:55 -0400 (EDT) From: Michael Richardson To: Chris Elliott , "homenet@ietf.org" In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sun, 09 Oct 2011 13:43:55 -0400 Message-ID: <13281.1318182235@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: MANET IETF , "robert@raszuk.net" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 09 Oct 2011 17:43:11 -0000 >>>>> "Chris" == Chris Elliott writes: Robert> Why a wireless access point at the pool has to also be a Robert> router ? Isn't it sufficient to extend one or more layer 2 Robert> to it ? >> It's not much of an access point if it doesn't have a second >> interface, is it? If it's out at the pool, and it has no wired >> layer2, then it might well have a second radio (or a second >> ESSID), to relay. But, it might also be connected to the wired >> network in the pool house. Chris> Bridging works fine between 802.11 and 802.1--or another Chris> 802.11 link. No routing required. Chris> It works for the IETF meeting networks and pretty much how Chris> all Enterprise gear is setup. Chris, I've helped out at the IETF NOC a number of years ago. I know lots about the things you do to make the IETF network just work, mostly when I encounter other networks/conferences where things rarely work. Do you think that the average home user knows how to turn off multicast, or even why they should? And, once they do that, do they know why their service discovery protocols now fail? Jim Gettys has repeated many times that multicast on wireless occurs at much lower data rates (1Mb/s on links that otherwise do 100Mb/s). Others have said that some access points turn multicast into unicast frames, but I've not experienced this. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Sun Oct 9 10:45:27 2011 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 2A8B221F8495; Sun, 9 Oct 2011 10:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncLmxV5hkShw; Sun, 9 Oct 2011 10:45:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id BF22821F8491; Sun, 9 Oct 2011 10:45:26 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 199E0343B2; Sun, 9 Oct 2011 13:44:23 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 07C6498CAD; Sun, 9 Oct 2011 13:46:14 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id EA26C98C90; Sun, 9 Oct 2011 13:46:14 -0400 (EDT) From: Michael Richardson To: chelliot@pobox.com In-Reply-To: References: <3B359047-B693-4879-B1C6-13EF26437F73@cisco.com> <1D3C1E64-F7A3-4888-B77A-CFB6CE2BCD1D@townsley.net> <47090411-FEBF-4EE2-804D-25773DE879B8@cisco.com> <48464731-804A-47F4-BB5C-697A5E5F5797@cisco.com> <3B8B1C13-D999-4B58-94CF-5A0C64C41EF0@tony.li> <2004EB35-D6EA-48FC-B2B4-7E886F68D1E8@tony.li> <4E8A03A5.5080601@raszuk.net> <12856.1317691669@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sun, 09 Oct 2011 13:46:14 -0400 Message-ID: <13605.1318182374@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "Manfredi, Albert E" , "homenet@ietf.org" , MANET IETF , "robert@raszuk.net" , "rtgwg@ietf.org" Subject: Re: [homenet] [manet] Question for you 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, 09 Oct 2011 17:45:27 -0000 >>>>> "Chris" == Chris Elliott writes: Chris> Often you can buy an access point or a wireless router. Many Chris> wireless routers have several switched Ethernet ports and a Chris> single "WAN" Ethernet port. Just don't use the "WAN" port and Chris> you're bridged. And some wireless routers (the Apple Airport yes, and now you have two DHCP servers. IPv4 gives us no clues that we should turn off one of them. From curtis@occnc.com Sun Oct 9 11:44:18 2011 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 2960521F8AD9 for ; Sun, 9 Oct 2011 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_92=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCeXre1rOH0g for ; Sun, 9 Oct 2011 11:44:17 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id F404621F8906 for ; Sun, 9 Oct 2011 11:44:16 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p99Ii4u8093672; Sun, 9 Oct 2011 11:44:04 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p99Ii4u8093672 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318185845; bh=oXfwIh4kbK8NtNM4BEztieucn2IICNYnlqn+/YONGaI=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=jMkqk+9dlmnyyUESxbElvHVYyjH5mqHs+FwHa5auT+z6eFuwIer7P/OfHOQUSx1f6 93RMDtaSgNIwm1vQz2jgaAPz8Chu08SWztTGNygaLbYgIGWnq1ye3qQOCLwbHc5Z4b jEskfWUx27l/hTyXyytmbapy1oCWRnkNX2Sn9E4Q= Message-Id: <201110091844.p99Ii4u8093672@gateway.ipv6.occnc.com> To: Joel jaeggli From: Curtis Villamizar In-reply-to: Your message of "Fri, 07 Oct 2011 14:09:06 PDT." <4E8F6A72.5000802@bogus.com> Date: Sun, 09 Oct 2011 11:44:04 -0700 Cc: homenet@ietf.org, james woodyatt , curtis@occnc.com Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 18:44:18 -0000 In message <4E8F6A72.5000802@bogus.com> Joel jaeggli writes: > On 10/7/11 12:55 , Curtis Villamizar wrote: > > In message <4E8EA2E8.6000508@bogus.com> > > Joel jaeggli writes: > > > >> On 10/4/11 16:17 , james woodyatt wrote: > >>> On Oct 3, 2011, at 9:00 PM, Thomas Herbst wrote: > >>>> > >>>> There will be wide area network providers who interwork with the > >>>> home network but do not provide global connectivity. Two mentioned > >>>> so far are utility networks and 3g providers. One of the outputs > >>>> of the wg should be to define how they should be configured to > >>>> perform their role without messing up Internet communication. > >>> > >>> Those utility networks have a fundamental problem that I contend is > >>> beyond the scope and charter of HOMENET. > >> > >> every-time I connect my split-tunneled vpn to my home network, I am > >> attaching a non-dfz-connected inter-network behind my home network, I > >> don't think of this as rare or particularly exceptional problem (it's > >> not confined to utility networks). it does have the potential for > >> address collisions (as built currently)in ipv4 due to the extensive if > >> not quite complete use of rfc-1918 used within the scope of that private > >> internetwork. > > > > > > Joel, > > > > Being new to this WG I may have it wrong, but a point of this WG may > > be to change the use of RFC1918 space to IPv6 space. > > I've got a little experience numbering networks... Yes I know. > My observation which apparently you missed was in response to James > Woodyatt's point about whether the interconnection of private > inter-networks (e.g. those without internet routes for example a utility > such as an elecritc provider) was is scope for homenet. So why would the elecritc provider not support IPv6 if they wanted to use the same internet infrastructure provided by the homenet? The model today is the the meter contacts the elecritc provider (this works with NAT). With IPv6, the electric provider could poll the meters, as long as they know the meter's IPv6 address. If anything, the meter could push a new IPv6 address on installation and each time it saw a new address assigned to it (as is done in mobility applications, but this should not be often for a stationary meter). Of course some reasonable authentication is needed. The point is that once IPv6 is supported, everything has a global address, things like this are easier (either end can initiate interaction). The example of electric meters is a trivial one but the same can apply to other things. The example of checking a thermostat or other thing in the home from a mobile phone is a better example of a need to initiate interaction from outside the homenet, where global address space is helpful. Others uses where having a global IPv6 address are nice are the home KDC, plus CVS, SVN, or GIT server, etc. These may not be common in the average home. :-) So the answer may be it is out of scope if the utility has some hack over some private infrastructre like IP over the power lines that is not connected to the homenet, in scope if they are using global addressing and taking advantage of the homenet. Maybe water meter or gas meter would be better examples since I don't know of IP over water pipes. In a lot of places these meters use a twisted pait that goes who knows where and might be better served with a WiFi chip or low power WPAN or plain ol' Ethernet and using the homenet. It may be possible to work something out with the local provider (MSO or ILEC) if the homeowner takes down their Internet access or doesn't want Internet. For example, leave the wires and local provider low end router in place, but with filters (where they can't be tampered with) only allowing access to the meters. IMHO: these sort of arrangements are well out of scope. The homenet is just a connection to the global Internet. IMO: The homenet equipment needs to be prepared for an IPv4 only provider. a native IPv6 only provider, or a dual stack provider. For IPv4, expect to most often get one address from the provider for local use (via DHCP) and enable NAT by default, or have multiple addresses configured (and optionally also have NAT configured). With IPv6, expect to get more than will ever be needed (a /64). Note that you *can* subdivide a /64 in a homenet as long as any advertisement to the provider (globally routable prefix) is /64 or shorter. [I'm using /112 and /96 (each on 2 byte boundaries) within a /64 and it works fine]. If there is no native IPv6, the homenet equipment must support a configured 6to4 tunnel or other configured tunnel. Whether to automatically bring up a 6to4 tunnel in the absense of native IPv6 and the absense of configuration, is an issue worth discussing. I think no, since it may overload 6to4 servers, but I'm willing to be persuaded. > > For example, not > > only your computers, but your home thermostats, your electic meter, > > your entertainment systems, SIP phones, etc can each have global IPv6 > > addresses. Beats "go check the thermostat at 10.0.0.1" from your > > mobile phone. Authentication will be an issue for product (but > > from the charter, not in scope for the WG). > > > > With an IPv6 only home network you don't need to use rfc1918 number > > space. You can put your /64 behind a firewall if you like. You can > > use RFC3142 as one means to reach the IPv4 world at least for anything > > based on TCP (SMTP, HTTP, etc). Or you can use application gateways > > (what I use). The benefit over using net 10/8 or other rfc1918 space > > is that if your hosts at different sites use IPv6 and if your laptop > > in a IPv4 only site can at least get a 6to4 tunnel, you can use a > > globally routable IPv6 number space. > > > > Try using IPv6 instead of rfc1918. (for example, see mail headers). > > > > If the provider side of the WAN connection just hands the home router > > an IPv6 prefix, then some form of autoconfiguration is possible. If > > not, IPv4 rfc1918 autoconfiguration can be used with NAT unless a > > tunnel is configured. It wouldn't hurt to do both IPv4 rfc1918 > > autoconfiguration with NAT and IPv6 autoconfiguration with a native > > prefix or with a configured tunnel (or with 6to4 enabled). > > > > Curtis Curtis From fred@cisco.com Sun Oct 9 13:16:26 2011 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 829DD21F8B16 for ; Sun, 9 Oct 2011 13:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.369 X-Spam-Level: X-Spam-Status: No, score=-100.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8faNd5xJJ7Re for ; Sun, 9 Oct 2011 13:16:25 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BFAB921F8AFF for ; Sun, 9 Oct 2011 13:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4347; q=dns/txt; s=iport; t=1318191385; x=1319400985; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=fhmQah+Zurvzs1ul4O521dFmAmzOgZpSK8r9OQE7vTY=; b=POynjoEnOOhBebvMve2qsAeQAmh/EIwN+TzaUTNzSugxIDg09qsIBmlz fgRdOaNmVFsEEUlAlWN7o8fzmh+70yZDp9REwO+iGDPam14TnJG4kVqXt YXegki9S3qpH+nDMsL/D3xqiRCL4alZaUu0yKVbQOF+pOIPjRnwoZIPa8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFADEAkk6rRDoI/2dsb2JhbABDpWKCNoEFgVMBAQEDAQEBAQ8BJzQLBQsLDgouHAswBhMZCYdcB5hYAZBtjCSGYmEEhj6IGQEBhR6FKYVjhmE X-IronPort-AV: E=Sophos;i="4.68,513,1312156800"; d="scan'208";a="6835172" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 09 Oct 2011 20:16:25 +0000 Received: from Freds-Computer.local (sjc-vpn7-1782.cisco.com [10.21.150.246]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p99KGOKZ014696; Sun, 9 Oct 2011 20:16:24 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 09 Oct 2011 16:16:25 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 09 Oct 2011 16:16:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <31922.1318176472@marajade.sandelman.ca> Date: Sun, 9 Oct 2011 16:16:14 -0400 Message-Id: <8CCC353A-1782-41AE-88AD-F673B48CE7B1@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> <31922.1318176472@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] lifetime on prefixes vs lifetime of address grants 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, 09 Oct 2011 20:16:26 -0000 On Oct 9, 2011, at 12:07 PM, Michael Richardson wrote: >=20 > Fred, I've changed the subject, I hope to shed more light. >=20 >>>>>> "Fred" =3D=3D Fred Baker wrote: > Fred> But also, the notion of tying the lifetime of a prefix on the > Fred> LAN with the lifetime of the prefix grant seems > Fred> ill-considered. The purpose of the lifetime on the prefix > Fred> grant (RFC 3363) is to enable an upstream to not need to be >=20 > I think you meant RFC3633 here right? (DHCP-PD) yes; typo... > I think that we clarified in discussion that the lifetime of prefix > advertised was limited to be no more than the lifetime in the PD. > It could be much lower. Yes. One would hope that it would be on the order of two announcement = cycles; allow for losing one RA announcement, but call foul if two are = lost in succession. > Fred> asked every 30 seconds for something it wants to leave > Fred> unchanged for a long period of time and yet make "a long = time" > Fred> not be "forever". That's reasonable. But in the case called > Fred> out here, it seems like the lifetime of the prefix in an RA > Fred> should be long enough that a host can miss an RA refresh and > Fred> not lose the address, and short enough that we don't have to > Fred> call in the national guard if someone trips over a cable or a > Fred> power supply goes spitzensparken. >=20 > Fred> What do we need to do to change that RFC 4861 requirement? If > Fred> what is required is an Internet Draft in 6man (and I would > Fred> expect it is), I'd be willing to write that draft. Going back to my previous note, the issue was that Lorenzo stated that = Linux (and he presumed all other implementations) - considered only the RA most recently received - developed an address in that prefix ONLY - used it until the prefix announcement expired. That is of course not per RFC 4861. 4861 instructs that an address is = calculated in every prefix received and held for possible use until it = expires. RFC 3484 goes on to give instructions about the choice among = such addresses. Thomas, later in that thread, asserts that Linux' = correct operation per RFC 4861 has been tested and shown in various = certification tests including USG. At this point, I think the ball is in Lorenzo's court. If Linux in fact = does something different (and therefore the certification is voided), = that needs to be shown. > I'm trying to understand things here. > We have, I think four lifes times around a homenet: > 1) DHCPv6 PD > 2) Router Lifetime. > 3) Prefix Valid Lifetime > 4) Prefix Preferred Lifetime >=20 > We expect #1 to be large, on the order of weeks in most cases, lowered > only to minutes in the cases where operators expect to move users = around > (such as rebalancing the load on the CMTS). >=20 > I expect the router lifetime to be on the order of minutes so that a > host stops using a route sooner. We could modify this more if a host > follows the rules of RFC4191 Type C. I'm unaware of any Linux = machines > being Type C, and I haven't seen *BSD do this, although maybe OSX = does. >=20 > Except for being limited by #1, it seems that we want to have a > Preferred Lifetime rather low only in the multi-router case. =20 >=20 > Maybe the right answer is dynamic: as soon a router, see another LSA, > they lower their Preferred Lifetime so that if there is a chance to > survive a topology change, then the host has a better chance of doing = so > without having the wrong address for that link for too long. >=20 > I admit that I still don't really understand how I should set my valid > lifetimes. It seems that they can be quite high in general. >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ > Kyoto Plus: watch the video = > then sign the petition.=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From ot@cisco.com Sun Oct 9 14:59:22 2011 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 C87D321F8B14 for ; Sun, 9 Oct 2011 14:59:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29p5-kaFI84A for ; Sun, 9 Oct 2011 14:59:22 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9922521F8B13 for ; Sun, 9 Oct 2011 14:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=4268; q=dns/txt; s=iport; t=1318197561; x=1319407161; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BVGIuKTq5NVln/JUwu3L4YfCTOi5A+lINIivh9dnbFY=; b=TafFvZLTRdYLU/ur8sm2sQWAZe26PqPerCDZF7HEH0KjUn8CRmw+isO7 nTFx9HElU2hBUqMBIm2KCKu3Ti2Z7TxSyU5EUIhphOTSMeH9f3crSVSQ6 Law9ypLBGLXdWZ6FjRdkZxoniJGc+OaaO8ytZY4tzC6pRe8mvWNfI4nu5 U=; X-IronPort-AV: E=Sophos;i="4.68,513,1312156800"; d="scan'208";a="57415341" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 09 Oct 2011 21:59:20 +0000 Received: from dhcp-10-61-100-153.cisco.com (dhcp-10-61-100-153.cisco.com [10.61.100.153]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p99LxKVN010773; Sun, 9 Oct 2011 21:59:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <8CCC353A-1782-41AE-88AD-F673B48CE7B1@cisco.com> Date: Sun, 9 Oct 2011 23:59:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <5AE8173E-214F-4314-BE97-53CE2C06FFE3@cisco.com> <31922.1318176472@marajade.sandelman.ca> <8CCC353A-1782-41AE-88AD-F673B48CE7B1@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Michael Richardson Subject: Re: [homenet] lifetime on prefixes vs lifetime of address grants 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, 09 Oct 2011 21:59:22 -0000 [...] >> I think that we clarified in discussion that the lifetime of prefix >> advertised was limited to be no more than the lifetime in the PD. >> It could be much lower. >=20 > Yes. One would hope that it would be on the order of two announcement = cycles; allow for losing one RA announcement, but call foul if two are = lost in succession. please no. this makes for unstable addresses. addresses !=3D routing. >> Fred> asked every 30 seconds for something it wants to leave >> Fred> unchanged for a long period of time and yet make "a long = time" >> Fred> not be "forever". That's reasonable. But in the case called >> Fred> out here, it seems like the lifetime of the prefix in an RA >> Fred> should be long enough that a host can miss an RA refresh and >> Fred> not lose the address, and short enough that we don't have to >> Fred> call in the national guard if someone trips over a cable or a >> Fred> power supply goes spitzensparken. a host should verify that its address is valid triggered by an L2 event. I think we need some new work with regards to 'flash renumbering'. cheers, Ole >> Fred> What do we need to do to change that RFC 4861 requirement? If >> Fred> what is required is an Internet Draft in 6man (and I would >> Fred> expect it is), I'd be willing to write that draft. >=20 > Going back to my previous note, the issue was that Lorenzo stated that = Linux (and he presumed all other implementations) > - considered only the RA most recently received > - developed an address in that prefix ONLY > - used it until the prefix announcement expired. >=20 > That is of course not per RFC 4861. 4861 instructs that an address is = calculated in every prefix received and held for possible use until it = expires. RFC 3484 goes on to give instructions about the choice among = such addresses. Thomas, later in that thread, asserts that Linux' = correct operation per RFC 4861 has been tested and shown in various = certification tests including USG. >=20 > At this point, I think the ball is in Lorenzo's court. If Linux in = fact does something different (and therefore the certification is = voided), that needs to be shown. >=20 >> I'm trying to understand things here. >> We have, I think four lifes times around a homenet: >> 1) DHCPv6 PD >> 2) Router Lifetime. >> 3) Prefix Valid Lifetime >> 4) Prefix Preferred Lifetime >>=20 >> We expect #1 to be large, on the order of weeks in most cases, = lowered >> only to minutes in the cases where operators expect to move users = around >> (such as rebalancing the load on the CMTS). >>=20 >> I expect the router lifetime to be on the order of minutes so that a >> host stops using a route sooner. We could modify this more if a host >> follows the rules of RFC4191 Type C. I'm unaware of any Linux = machines >> being Type C, and I haven't seen *BSD do this, although maybe OSX = does. >>=20 >> Except for being limited by #1, it seems that we want to have a >> Preferred Lifetime rather low only in the multi-router case. =20 >>=20 >> Maybe the right answer is dynamic: as soon a router, see another LSA, >> they lower their Preferred Lifetime so that if there is a chance to >> survive a topology change, then the host has a better chance of doing = so >> without having the wrong address for that link for too long. >>=20 >> I admit that I still don't really understand how I should set my = valid >> lifetimes. It seems that they can be quite high in general. >>=20 >> --=20 >> ] He who is tired of Weird Al is tired of life! | = firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >> Kyoto Plus: watch the video = >> then sign the petition.=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 From ot@cisco.com Sun Oct 9 15:04:31 2011 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 72C7521F8B46 for ; Sun, 9 Oct 2011 15:04:31 -0700 (PDT) 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=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNV7ssOvQCXA for ; Sun, 9 Oct 2011 15:04:30 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A0EEF21F8B45 for ; Sun, 9 Oct 2011 15:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=766; q=dns/txt; s=iport; t=1318197870; x=1319407470; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5OEYJafDZhF4hMr1ExRGMvtobdFXcbEE/TTxWg9tR+M=; b=Rk87RLegR+tQeXw7H4abXOgfaQLAQhAK9jU3+4t17VZi/lxA6jlSWui/ tliTuZaQf6GtLX0BqPF2OtM1b5v6k9gcQlQWyZX454GfCOogzcWS7aAH8 D8Fj3JCbX6fTJqlBsCV+wqL95yZBwe95X4EK2qiXE0Ug6rR7CmHOVePHG I=; X-IronPort-AV: E=Sophos;i="4.68,513,1312156800"; d="scan'208";a="638000" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 09 Oct 2011 22:04:29 +0000 Received: from dhcp-10-61-100-153.cisco.com (dhcp-10-61-100-153.cisco.com [10.61.100.153]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p99M4Tel011720; Sun, 9 Oct 2011 22:04:29 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E8F8368.5070304@cisco.com> Date: Mon, 10 Oct 2011 00:04:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A652F83-36A2-4B33-88B6-1FA4FA202BA8@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> <4E8F8368.5070304@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Jari Arkko , Fred Baker Subject: Re: [homenet] Thoughts about routing 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, 09 Oct 2011 22:04:31 -0000 Erik, > The zospf appears to have an approach for router ID collisions, but = that probably isn't (widely) implemented. indeed. zospf or whatever combination of zeroconf OSPF plus OSPF prefix = assignment is new work. > (In any case, we'd need to figure out what it means to have stable = prefixes allocated - to interfaces or to links - but that is the prefix = autoconfig part of the problem as opposed to the router config part of = the problem.) right. we should aim for a stable prefix given no topology changes. if a = link partitions and merges there will have to be renumbering. I think this will require stable storage, regardless of this being done = via DHCP and a God server or via an autonomous approach like zOSPF. cheers, Ole From shtsuchi@cisco.com Sun Oct 9 15:16:56 2011 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 A25E321F85B9 for ; Sun, 9 Oct 2011 15:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.02 X-Spam-Level: * X-Spam-Status: No, score=1.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_43=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr1anfj5IHvW for ; Sun, 9 Oct 2011 15:16:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ED2CA21F8593 for ; Sun, 9 Oct 2011 15:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=973; q=dns/txt; s=iport; t=1318198616; x=1319408216; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=gqrt92YpS5pb7b1NE79p3DEfkVEXucwKzFQva8c6ikk=; b=gjREGKDN6xEoDBR/cXfbi32T6WfNq7W6P1GoMYU4VdBGV7ng98JvzM1g rssq+DkE1yUtBcjiS3FMBGW1B7JKqH1YEm0aFDO1DkefwtyE5/fStK3ZO IrAipSMWOBOSSACW5KZkglt7Ja8QgVO1RvOQgrQ9Gwg9Pi/RuH2bhz6mF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYGAA4dkk6tJV2a/2dsb2JhbABChHWUPo5lgQWBbAEOAVY1AwUWCgMLAwIBAgFYCAEBHodjl26BJgGMQgGQVoEphQOBFwSHe4ZcAYUfhSmMNw X-IronPort-AV: E=Sophos;i="4.68,513,1312156800"; d="scan'208";a="27110482" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 09 Oct 2011 22:16:52 +0000 Received: from [10.82.232.4] (rtp-vpn5-4.cisco.com [10.82.232.4]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p99MGoxx027653 for ; Sun, 9 Oct 2011 22:16:51 GMT Message-ID: <4E90CBC6.2030005@cisco.com> Date: Sun, 09 Oct 2011 07:16:38 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [homenet] Does ND Proxy useful for 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: Sun, 09 Oct 2011 22:16:56 -0000 Hi I was considering whether ND proxy would be useful for homenet environment,when Fred's presentation. http://trac.tools.ietf.org/wg/homenet/trac/raw-attachment/wiki/WikiStart/Homenet Routing.pdf The reason are -address usage efficiency 2^64 host address space would be too enough for homenet. -prefix delegation ND proxy does not require delegate prefix to upstream router. -Security ND proxy would be security point. -running code ND proxy(RFC4389) is experimental,but there is running code. http://tools.ietf.org/html/rfc4389 Especially in Japan,some vendors(maybe 2 or 3) already supported very similar function as RA proxy. As you may know,NTT East/West has been assigned IPv6 address for their wall garden since Feb. 2007. CPE supports this by two method. -Ether-type(0x86DD) bridge,it called IPv6 path-though -RA Proxy RA proxy router can inspect of IPv6 data packets as theoretical. I would appreciate any comments. Regards, -Shishio From ot@cisco.com Sun Oct 9 15:38:32 2011 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 D3A8721F8B0D for ; Sun, 9 Oct 2011 15:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijW+gUmzcBmn for ; Sun, 9 Oct 2011 15:38:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 00BFE21F8B0C for ; Sun, 9 Oct 2011 15:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=1481; q=dns/txt; s=iport; t=1318199912; x=1319409512; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=pLeheMf+7Oy0iN3MB1JdprFhMn70EMYoK4LIlg0itCw=; b=dRp3sVvTVYaQUIv7Bs5gaJqNW37TGdtjB86vB2A7phGq+AqpmIdRI/9h cH81m1R7Q+sIB/nGyv2s8HUCv2QvN0TSOKqPW735EpSid/Zhi1OlQzrGU LdDQzLvKeWKLn/0v/znbFg6UHNswT6Qm+p2YD7W9ZTv4YI2mUOO13/FeX M=; X-IronPort-AV: E=Sophos;i="4.68,514,1312156800"; d="scan'208";a="118661430" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2011 22:38:28 +0000 Received: from dhcp-10-61-100-153.cisco.com (dhcp-10-61-100-153.cisco.com [10.61.100.153]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p99McSox028126; Sun, 9 Oct 2011 22:38:28 GMT From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 00:38:28 +0200 Message-Id: To: Erik Nordmark Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org Subject: [homenet] Multilink subnet routing (MLSRv2) 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, 09 Oct 2011 22:38:32 -0000 Erik, et al, to expand on the ideas I presented on MLSR (or rather MLSRv2 as it = hasn't really been described anywhere) as a method for numbering a = routed home. please let me be clear that I'm not convinced this is a = good idea. i.e. why not just get < /64? I do think we could get something working though. routers can be in an arbitrary topology. all routers running a routing = protocol. the site prefix (/64) is either advertised in the IGP with a new LSA or = proxying of RA messages is done (split horizon). a router advertises the same /64 prefix (in a PIO) on all of its = interfaces. L bit is 0. the link model here is that all hosts are off link from each other. = link-local scope is restricted to only the physical link. multicast = link-local scope as well. a host uses SLAAC (or DHCP) to create an address, then does DAD as = normal. the first hop router uses it's routing topology database to check for conflicts. similar mechanisms described in SAVI are used to = glean address information from the host. the SAVI binding database is then used to inject host routes into the IGP. this requires no flooding of ND, or any other changes to on-link = protocols for loop detection. no changes in hosts either. only downside is that it requires a host to have sent a packet of some = form for the SAVI binding to be initiated. it might also be possible to support host mobility with the home with = this mechanism. cheers, Ole From shtsuchi@cisco.com Sun Oct 9 15:41:21 2011 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 D1DAA21F8B0C for ; Sun, 9 Oct 2011 15:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFK+z-+v3XC7 for ; Sun, 9 Oct 2011 15:41:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 304EC21F8AD9 for ; Sun, 9 Oct 2011 15:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1320; q=dns/txt; s=iport; t=1318200081; x=1319409681; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=O4FZI7nCYzoK8zgFDRYW0VCt5am8BhNmhB6Z1wGMiIY=; b=laLsZ1b9vZd5ut7BSTOxKLdeg2gEnYaxlky/3uOBVIiFXPmxqj2P4GXY Q4NVhInvRV7obB4HWLyqk1dHWm1srKzqK50vl2XfC/wAsndAjJCQDsZnw C5BFPLfnr9eLJj37gX/90/EIQXq//ce2MJmBAXjPGiQEcsvwzpa0OdZ6i I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgGAB8ikk6tJXG9/2dsb2JhbABChHWUPo5lgQWBUwEBAQQBAQEPAQ4BTAoRCxgBAwUWCgMCCQMCAQIBFTATBgIBAR6HY5kyAYxCAZBagSmFA4EXBId7hlwBAYUehSmMNw X-IronPort-AV: E=Sophos;i="4.68,514,1312156800"; d="scan'208";a="27103072" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2011 22:41:20 +0000 Received: from [10.82.253.173] (rtp-vpn6-1448.cisco.com [10.82.253.173]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p99MfJSX030693 for ; Sun, 9 Oct 2011 22:41:20 GMT Message-ID: <4E92230F.7030009@cisco.com> Date: Mon, 10 Oct 2011 07:41:19 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <4E90CBC6.2030005@cisco.com> In-Reply-To: <4E90CBC6.2030005@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Does ND Proxy useful for 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: Sun, 09 Oct 2011 22:41:21 -0000 Ups. Sorry please discard this mail. I made this mail,before current discussion. (2011/10/09 7:16), Shishio Tsuchiya (shtsuchi) wrote: > Hi > I was considering whether ND proxy would be useful for homenet environment,when Fred's presentation. > http://trac.tools.ietf.org/wg/homenet/trac/raw-attachment/wiki/WikiStart/Homenet Routing.pdf > > The reason are > -address usage efficiency > 2^64 host address space would be too enough for homenet. > -prefix delegation > ND proxy does not require delegate prefix to upstream router. > -Security > ND proxy would be security point. > -running code > ND proxy(RFC4389) is experimental,but there is running code. > http://tools.ietf.org/html/rfc4389 > Especially in Japan,some vendors(maybe 2 or 3) already supported very similar function as RA proxy. > As you may know,NTT East/West has been assigned IPv6 address for their wall garden since Feb. 2007. > CPE supports this by two method. > -Ether-type(0x86DD) bridge,it called IPv6 path-though > -RA Proxy > > RA proxy router can inspect of IPv6 data packets as theoretical. > > I would appreciate any comments. > > Regards, > -Shishio > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From acee.lindem@ericsson.com Sun Oct 9 17:01:48 2011 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 26F3B21F8B80 for ; Sun, 9 Oct 2011 17:01:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9cuUWMxLDEX for ; Sun, 9 Oct 2011 17:01:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3D21F8B7E for ; Sun, 9 Oct 2011 17:01:47 -0700 (PDT) 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 p9A01hjp025779; Sun, 9 Oct 2011 19:01:44 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 9 Oct 2011 20:01:38 -0400 From: Acee Lindem To: Fred Baker Date: Sun, 9 Oct 2011 20:01:35 -0400 Thread-Topic: [homenet] Thoughts about routing Thread-Index: AcyG38e+AA3sWe/oRbySsPa6SZV6PQ== Message-ID: <002E7F7F-FB96-455A-A0A8-A11BC65C1187@ericsson.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> <4E8F8368.5070304@cisco.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: Erik Nordmark , Jari Arkko , "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 00:01:48 -0000 On Oct 7, 2011, at 10:17 PM, Fred Baker wrote: >=20 > On Oct 7, 2011, at 6:55 PM, Erik Nordmark wrote: >=20 >> On 10/7/11 3:28 AM, Fred Baker wrote: >>> The other parameters in question include >>> - the interface prefix itself, which could be derived as in zospf, >>> - the area number (I'd suggest it default to zero), >>> - the router ID (a random 32 bit number), and >>> - security information. >>=20 >> Fred, >>=20 >> Do existing OSPF implementations have the ability to pick a random route= r ID, and detect when there is a router ID collision? >=20 > OSPFv2 implementations generally pick one of the IPv4 addresses of the sy= stem. Not sure I can make a general comment on OSPFv3. Since OSPFv3 also uses a 4 byte router ID, our implementation will use the = same algorithm for picking a router ID as OSPFv2.=20 >=20 >> One benefit of using IS-IS is that the router ID is longer and based on = a factory-assigned IEEE MAC address. >=20 >> The zospf appears to have an approach for router ID collisions, but that= probably isn't (widely) implemented. >=20 > ZOSPF is, AFAIK, an internet draft that has never been implemented. Agreed. The 2002 draft died with its expiration in 2003.=20 Acee >=20 >> (In any case, we'd need to figure out what it means to have stable prefi= xes allocated - to interfaces or to links - but that is the prefix autoconf= ig part of the problem as opposed to the router config part of the problem.= ) >>=20 >> Erik >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From fred@cisco.com Sun Oct 9 17:41:40 2011 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 9F75721F8B57 for ; Sun, 9 Oct 2011 17:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.011 X-Spam-Level: X-Spam-Status: No, score=-102.011 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AiCA1YmtqbM for ; Sun, 9 Oct 2011 17:41:40 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0465A21F8B4C for ; Sun, 9 Oct 2011 17:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=261; q=dns/txt; s=iport; t=1318207298; x=1319416898; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=RGstg2WsvGBB0WK8a2p1HGhoQnj/DFI0ntMPOjtjmIo=; b=XgRq09KXYwkHIA4KHLRPni+PKTMebzAqQhF7iwkmSYP5FX1ZYgfpAiu1 UK8ETjHTWtMVbGoM01xt567IcZ+pgWpjEizXcgA6iXfG8Nj8KxyK+akWo 0RkqV5HQLZkIkUqJDbfht80KCKCSOw2L9eOF06CDhvV+NKjvgb99VTQw8 w=; X-IronPort-AV: E=Sophos;i="4.68,514,1312156800"; d="scan'208";a="6854395" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 10 Oct 2011 00:41:37 +0000 Received: from Freds-Computer.local (sjc-vpn7-1782.cisco.com [10.21.150.246]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9A0el2S031145; Mon, 10 Oct 2011 00:41:36 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 09 Oct 2011 20:41:36 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 09 Oct 2011 20:41:36 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <002E7F7F-FB96-455A-A0A8-A11BC65C1187@ericsson.com> Date: Sun, 9 Oct 2011 20:41:36 -0400 Message-Id: <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> <4E8F8368.5070304@cisco.com> <002E7F7F-FB96-455A-A0A8-A11BC65C1187@ericsson.com> To: Acee Lindem X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , Jari Arkko , "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 00:41:40 -0000 On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote: > Since OSPFv3 also uses a 4 byte router ID, our implementation will use = the same algorithm for picking a router ID as OSPFv2.=20 which is to say "any old thing it wants, quite often an IPv4 address"?= From acee.lindem@ericsson.com Sun Oct 9 17:53:31 2011 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 1755C21F8B7E for ; Sun, 9 Oct 2011 17:53:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za5x0F0CPk6V for ; Sun, 9 Oct 2011 17:53:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9345E21F8B62 for ; Sun, 9 Oct 2011 17:53:30 -0700 (PDT) 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 p9A0rMbG026953; Sun, 9 Oct 2011 19:53:27 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 9 Oct 2011 20:53:16 -0400 From: Acee Lindem To: Fred Baker Date: Sun, 9 Oct 2011 20:53:15 -0400 Thread-Topic: [homenet] Thoughts about routing Thread-Index: AcyG5v74idWB0JddQ9qEKZrv/fKfyw== Message-ID: References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> <4E8F8368.5070304@cisco.com> <002E7F7F-FB96-455A-A0A8-A11BC65C1187@ericsson.com> <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> In-Reply-To: <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.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: Erik Nordmark , Jari Arkko , "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 00:53:31 -0000 On Oct 9, 2011, at 8:41 PM, Fred Baker wrote: >=20 > On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote: >=20 >> Since OSPFv3 also uses a 4 byte router ID, our implementation will use t= he same algorithm for picking a router ID as OSPFv2.=20 >=20 > which is to say "any old thing it wants, quite often an IPv4 address"? Correct, it uses the best or only configured IPv4 address in the context (a= ka, virtual router). Of course, we'd want to use something else for true au= to-configuration.=20 Thanks, Acee = From mark@townsley.net Sun Oct 9 21:18:32 2011 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 3586C21F8B09 for ; Sun, 9 Oct 2011 21:18:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c49AWv6w3WL for ; Sun, 9 Oct 2011 21:18:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A55A21F8AF4 for ; Sun, 9 Oct 2011 21:18:31 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5357021vcb.31 for ; Sun, 09 Oct 2011 21:18:30 -0700 (PDT) Received: by 10.52.28.211 with SMTP id d19mr11700671vdh.92.1318220308769; Sun, 09 Oct 2011 21:18:28 -0700 (PDT) Received: from [192.168.5.230] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id x19sm17370904vdf.10.2011.10.09.21.18.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Oct 2011 21:18:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Mon, 10 Oct 2011 00:18:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <17D930D0-572C-482E-8BE7-E782E493069C@townsley.net> References: To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: Erik Nordmark , homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 04:18:32 -0000 it would seem that we only have 3 choices once we run out of /64s to = give out on links that for whatever reason we cannot bridge on. 1. No IPv6 2. NAT IPv6=20 3. MLSRv2 (if what you propose works, I don't yet see why it wouldn't) I think this is a case of what is the least bad option. We shouldn't = ignore the problem though. - Mark On Oct 9, 2011, at 6:38 PM, Ole Troan wrote: > Erik, et al, >=20 > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it = hasn't really been described anywhere) as a method for numbering a = routed home. please let me be clear that I'm not convinced this is a = good idea. i.e. why not just get < /64? > I do think we could get something working though. >=20 > routers can be in an arbitrary topology. all routers running a routing = protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA = or proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its = interfaces. L bit is 0. >=20 > the link model here is that all hosts are off link from each other. = link-local scope is restricted to only the physical link. multicast = link-local scope as well. >=20 > a host uses SLAAC (or DHCP) to create an address, then does DAD as = normal. the first hop router uses it's routing topology database > to check for conflicts. similar mechanisms described in SAVI are used = to glean address information from the host. the SAVI binding > database is then used to inject host routes into the IGP. >=20 > this requires no flooding of ND, or any other changes to on-link = protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some = form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with = this mechanism. >=20 > cheers, > Ole >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Sun Oct 9 21:49:01 2011 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 051B621F85B9 for ; Sun, 9 Oct 2011 21:49:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cEbAOoxDMap for ; Sun, 9 Oct 2011 21:49:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D39B21F8483 for ; Sun, 9 Oct 2011 21:49:00 -0700 (PDT) Received: by vws5 with SMTP id 5so5373072vws.31 for ; Sun, 09 Oct 2011 21:48:58 -0700 (PDT) Received: by 10.52.70.242 with SMTP id p18mr12199871vdu.28.1318222137132; Sun, 09 Oct 2011 21:48:57 -0700 (PDT) Received: from [192.168.5.230] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id cx10sm8303456vdb.11.2011.10.09.21.48.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Oct 2011 21:48:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Mon, 10 Oct 2011 00:48:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11A7346A-2607-468B-BD4F-84928FB1182E@townsley.net> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> <4E8F8368.5070304@cisco.com> <002E7F7F-FB96-455A-A0A8-A11BC65C1187@ericsson.com> <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> To: Acee Lindem X-Mailer: Apple Mail (2.1084) Cc: Erik Nordmark , "homenet@ietf.org" , Jari Arkko , Fred Baker Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 04:49:01 -0000 On Oct 9, 2011, at 8:53 PM, Acee Lindem wrote: >=20 > On Oct 9, 2011, at 8:41 PM, Fred Baker wrote: >=20 >>=20 >> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote: >>=20 >>> Since OSPFv3 also uses a 4 byte router ID, our implementation will = use the same algorithm for picking a router ID as OSPFv2.=20 >>=20 >> which is to say "any old thing it wants, quite often an IPv4 = address"? >=20 >=20 > Correct, it uses the best or only configured IPv4 address in the = context (aka, virtual router). Of course, we'd want to use something = else for true auto-configuration.=20 And, homenet is of course required to be able to operate in absence of = IPv4 as well as dual-stack.... - Mark >=20 > Thanks, > Acee=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From swmike@swm.pp.se Sun Oct 9 23:16:22 2011 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 A0A4721F84AB for ; Sun, 9 Oct 2011 23:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke-Gk0fun8VV for ; Sun, 9 Oct 2011 23:16:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBE721F84AE for ; Sun, 9 Oct 2011 23:16:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DA7E89E; Mon, 10 Oct 2011 08:16:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D725E9A; Mon, 10 Oct 2011 08:16:17 +0200 (CEST) Date: Mon, 10 Oct 2011 08:16:17 +0200 (CEST) From: Mikael Abrahamsson To: Shishio Tsuchiya In-Reply-To: <4E90CBC6.2030005@cisco.com> Message-ID: References: <4E90CBC6.2030005@cisco.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] Does ND Proxy useful for 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: Mon, 10 Oct 2011 06:16:22 -0000 On Sun, 9 Oct 2011, Shishio Tsuchiya wrote: > 2^64 host address space would be too enough for homenet. I would just like to comment on this even though you retracted your question. As an ISP, I do not want to participate in a home with hundreds or thousands of active IPv6 addresses that I need to keep state for. Most likely, when we have central equipment participating in a home network, we'll implement a limit on number of neighbours it'll allow on the subnet. Doing ND/NS a lot takes resources. If customer wants to use more IPv6 addresses, we'll require them to get a home router and PD address space to it to distribute the ND/NS load. -- Mikael Abrahamsson email: swmike@swm.pp.se From pthubert@cisco.com Mon Oct 10 00:33:59 2011 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 F01C021F8558 for ; Mon, 10 Oct 2011 00:33:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlw1khBStmdO for ; Mon, 10 Oct 2011 00:33:57 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5347721F8551 for ; Mon, 10 Oct 2011 00:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2642; q=dns/txt; s=iport; t=1318232037; x=1319441637; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=E1xNgJO2AxpkRa8Ka2/U0q8k/3+Ni3QEhzX4EcEZJrM=; b=lh1opGHRKaoLmjjtWUiEbLq4fliO0CkB8rCOV6FoLuo1mtIDi6NgnUlH Ewllju3aUDPyyvT88s2xz3zFd0MW4unUFdG5eSaZX3dLbGkOdNKd0LPeI 1wM+ZwzWtuQAPVdXd6JCP7Mkbm+lyMcckuLPF0+psoesFvz5nVgxa+ZST 0=; X-IronPort-AV: E=Sophos;i="4.68,515,1312156800"; d="scan'208";a="663500" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 10 Oct 2011 07:33:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9A7Xu4p019568; Mon, 10 Oct 2011 07:33:56 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 09:33:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 09:33:55 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] Multilink subnet routing (MLSRv2) Thread-Index: AcyG1C/RVDifxpdVQPGXOfSm/A6BmQARqOtQ References: From: "Pascal Thubert (pthubert)" To: "Ole Troan" X-OriginalArrivalTime: 10 Oct 2011 07:33:56.0503 (UTC) FILETIME=[F7EACA70:01CC871E] Cc: homenet@ietf.org, "Erik Nordmark \(nordmark\)" Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 07:33:59 -0000 Hi Ole: I think you're getting closer and closer to the models that were discussed in RPL, 6LoWPAN and Autoconf. There are several components to the solution that was proposed there: - capability to register an IPv6 address using ND extensions - capability to extend a subnet over multiple hops (RPL DIO prefix option)=20 - capability to redistribute ND registration into the MLSN routing protocol - capability to use the ND registrar (and/or) the routing protocol for DAD - capability for the registrar to proxy ND over a backbone in order to interact with classical ND clients See: http://tools.ietf.org/html/rfc5889=20 http://tools.ietf.org/html/draft-ietf-6lowpan-nd=20 http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router cheers, Pascal -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Ole Troan Sent: lundi 10 octobre 2011 00:38 To: Erik Nordmark (nordmark) Cc: homenet@ietf.org Subject: [homenet] Multilink subnet routing (MLSRv2) Erik, et al, to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't really been described anywhere) as a method for numbering a routed home. please let me be clear that I'm not convinced this is a good idea. i.e. why not just get < /64? I do think we could get something working though. routers can be in an arbitrary topology. all routers running a routing protocol. the site prefix (/64) is either advertised in the IGP with a new LSA or proxying of RA messages is done (split horizon). a router advertises the same /64 prefix (in a PIO) on all of its interfaces. L bit is 0. the link model here is that all hosts are off link from each other. link-local scope is restricted to only the physical link. multicast link-local scope as well. a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. the first hop router uses it's routing topology database to check for conflicts. similar mechanisms described in SAVI are used to glean address information from the host. the SAVI binding database is then used to inject host routes into the IGP. this requires no flooding of ND, or any other changes to on-link protocols for loop detection. no changes in hosts either. only downside is that it requires a host to have sent a packet of some form for the SAVI binding to be initiated. it might also be possible to support host mobility with the home with this mechanism. cheers, Ole _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From v6ops@globis.net Mon Oct 10 00:38:47 2011 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 61F8D21F8B0E for ; Mon, 10 Oct 2011 00:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGb+OTZNw-Vx for ; Mon, 10 Oct 2011 00:38:46 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 082B621F8531 for ; Mon, 10 Oct 2011 00:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4A03B8700B4; Mon, 10 Oct 2011 09:38:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1djr-7yInVfI; Mon, 10 Oct 2011 09:38:36 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A2AC087005F; Mon, 10 Oct 2011 09:38:36 +0200 (CEST) Message-ID: <4E92A0FC.5060406@globis.net> Date: Mon, 10 Oct 2011 09:38:36 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Curtis Villamizar Content-Type: multipart/alternative; boundary="------------010201040502040205000001" Cc: homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 10 Oct 2011 07:38:47 -0000 This is a multi-part message in MIME format. --------------010201040502040205000001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > The example of electric meters is a trivial one but the same can apply to other things. I can assure you that the requirements and IT issues surrounding smart electric meters are far from "trivial." You talk about "the electric company" being singular and monolithic. In reality there are many separate parties with interests in obtaining access to that data and controlling that meter (the home owner, multiple production/ delivery companies, meter data management company, meter management company, high voltage distribution company, medium voltage distribution company, regulators, micro generation .... ) That can add up to 15 different roles, and many different message types. See e.g. /EBSII White Paper: "Smart European Energy Architecture" or http://www.google.nl/url?sa=t&source=web&cd=4&ved=0CC0QFjAD&url=http%3A%2F%2Fwww.esmig.eu%2Fnewsstor%2Fnews-file-store%2FEU-MeteringV4.pdf%2Fat_download%2Ffile&rct=j&q=EBSII%20White%20Paper%3A%20%E2%80%9CSmart%20European%20Energy%20Architecture%E2%80%9D&ei=JZ-STvnTLMmg-wbm6qHTCg&usg=AFQjCNGpFWhNfa1HeBA24wlVPwLEFB0T6A&sig2=CT0FCDXVmniyxMoSup9SPw&cad=rja regards, RayH / --------------010201040502040205000001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >  The example of electric meters is a trivial one but the same can apply to other things.

I can assure you that the requirements and IT issues surrounding smart electric meters are far from "trivial."

You talk about "the electric company" being singular and monolithic. In reality there are many separate parties with interests in obtaining access to that data and controlling that meter (the home owner, multiple production/ delivery companies, meter data management company, meter management company, high voltage distribution company, medium voltage distribution company, regulators, micro generation .... ) That can add up to 15 different roles, and many different message types.

See e.g. EBSII White Paper: “Smart European Energy Architecture”

or

http://www.google.nl/url?sa=t&source=web&cd=4&ved=0CC0QFjAD&url=http%3A%2F%2Fwww.esmig.eu%2Fnewsstor%2Fnews-file-store%2FEU-MeteringV4.pdf%2Fat_download%2Ffile&rct=j&q=EBSII%20White%20Paper%3A%20%E2%80%9CSmart%20European%20Energy%20Architecture%E2%80%9D&ei=JZ-STvnTLMmg-wbm6qHTCg&usg=AFQjCNGpFWhNfa1HeBA24wlVPwLEFB0T6A&sig2=CT0FCDXVmniyxMoSup9SPw&cad=rja


regards,
RayH

 --------------010201040502040205000001-- From fred@cisco.com Mon Oct 10 02:02:31 2011 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 7CD0121F8B2F for ; Mon, 10 Oct 2011 02:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8n9079tPwJj for ; Mon, 10 Oct 2011 02:02:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EA13E21F8B23 for ; Mon, 10 Oct 2011 02:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1324; q=dns/txt; s=iport; t=1318237351; x=1319446951; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=oLY/iwH6zzY0Blq3I1t5LTxA3bqTE9MOrSxtzrG70iA=; b=f7sN5REThf2H41fNG8QfTpY9r3b6lErPVOt/5sFYF2MsQ5cwe8YMnE/O WhT0wndtkTHUmAfc6+CO+rUBt7wjhnQB9fKuqYAtUN/QFpbvGCffPITnF QF475eMb5czFbdrigdU7IHvtBqPrKQF+uwEE52Ug2wWwnWDSqr+DHkHtF Q=; X-IronPort-AV: E=Sophos;i="4.68,516,1312156800"; d="scan'208";a="6891954" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 10 Oct 2011 09:02:30 +0000 Received: from Freds-Computer.local (sjc-vpn7-1782.cisco.com [10.21.150.246]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9A92Top017339; Mon, 10 Oct 2011 09:02:30 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 10 Oct 2011 05:02:30 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 10 Oct 2011 05:02:30 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 10 Oct 2011 05:02:19 -0400 Message-Id: <80BAE82D-8FA0-45AF-B393-AB66CAE211BF@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8EC599.4050200@piuha.net> <4E8F8368.5070304@cisco.com> <002E7F7F-FB96-455A-A0A8-A11BC65C1187@ericsson.com> <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> To: Acee Lindem X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , Jari Arkko , "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 09:02:31 -0000 On Oct 9, 2011, at 8:53 PM, Acee Lindem wrote: > Correct, it uses the best or only configured IPv4 address in the = context (aka, virtual router). Of course, we'd want to use something = else for true auto-configuration.=20 Yes. For my money, in the absence of an IPv4 configuration, that's = probably derived from a MAC Address, a serial number, or something else = that is an attribute of the bit of equipment. But apart from observing = on possible sources, Jon Moy would probably put on an animated look and = observe that the router id is a 32 bit number unique in the routing = domain, not necessarily an address of any kind. A tiny bit of history here. Back in 1991 when we were doing the testing = that resulted in RFC 1246, we (the implementers of 23 different = implementations, many of which were derivative from the Maryland = Prototype, e.g. Rob Coltun's code) had a discussion about where the = router id should come from, and I commented that I had doctored my = implementation to select one of the IPv4 addresses in the area. What I = just described was the discussion that followed. Maybe everyone else had = already made the same choice, or maybe they changed their code soon = after, but using one of the IPv4 addresses in the area was suddenly a = pretty common solution. :-) From ot@cisco.com Mon Oct 10 04:25:21 2011 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 4011221F8496 for ; Mon, 10 Oct 2011 04:25:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaBvuGi2vd65 for ; Mon, 10 Oct 2011 04:25:20 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 431F621F848E for ; Mon, 10 Oct 2011 04:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=3149; q=dns/txt; s=iport; t=1318245920; x=1319455520; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7rfW6ZpGxaG+Z4X/nH+LMVONkKXE3HnBu73WTUjqIXY=; b=ZT6pGnS2O2GoE+i9Dbke8XeoGd35vueFR8Lw4cxJ+yU2WrJ+4CtCt+0c B77jL4xbZvcLY30Bfwc1iyZQXeay66TvsmnWhfjD/Id+pTZLNO1r19DZJ tHNOQ1glC1zmTV9cWvqorX6F16MS7kopS4ZwPx/4s1C8fRJB3+LLqvb4p k=; X-IronPort-AV: E=Sophos;i="4.68,516,1312156800"; d="scan'208";a="684596" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 10 Oct 2011 11:25:19 +0000 Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com [64.103.53.235]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9ABPJx5016773; Mon, 10 Oct 2011 11:25:19 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 10 Oct 2011 13:25:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1EF79398-29B8-4CDB-A2C9-1224A6F6DF76@cisco.com> References: To: "Pascal Thubert \(pthubert\)" X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, "Erik Nordmark \(nordmark\)" Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 11:25:21 -0000 Pascal, we (as in homenet) do not want to require host changes. I also think the issues with flooding ND has been explored in RFC4903. cheers, Ole On Oct 10, 2011, at 9:33 , Pascal Thubert (pthubert) wrote: > Hi Ole: > > I think you're getting closer and closer to the models that were > discussed in RPL, 6LoWPAN and Autoconf. > > There are several components to the solution that was proposed there: > - capability to register an IPv6 address using ND extensions > - capability to extend a subnet over multiple hops (RPL DIO prefix > option) > - capability to redistribute ND registration into the MLSN routing > protocol > - capability to use the ND registrar (and/or) the routing protocol for > DAD > - capability for the registrar to proxy ND over a backbone in order to > interact with classical ND clients > > See: > http://tools.ietf.org/html/rfc5889 > http://tools.ietf.org/html/draft-ietf-6lowpan-nd > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > > cheers, > > Pascal > > > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On > Behalf Of Ole Troan > Sent: lundi 10 octobre 2011 00:38 > To: Erik Nordmark (nordmark) > Cc: homenet@ietf.org > Subject: [homenet] Multilink subnet routing (MLSRv2) > > Erik, et al, > > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it > hasn't really been described anywhere) as a method for numbering a > routed home. please let me be clear that I'm not convinced this is a > good idea. i.e. why not just get < /64? > I do think we could get something working though. > > routers can be in an arbitrary topology. all routers running a routing > protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA or > proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its > interfaces. L bit is 0. > > the link model here is that all hosts are off link from each other. > link-local scope is restricted to only the physical link. multicast > link-local scope as well. > > a host uses SLAAC (or DHCP) to create an address, then does DAD as > normal. the first hop router uses it's routing topology database to > check for conflicts. similar mechanisms described in SAVI are used to > glean address information from the host. the SAVI binding database is > then used to inject host routes into the IGP. > > this requires no flooding of ND, or any other changes to on-link > protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some > form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with > this mechanism. > > cheers, > Ole > > _______________________________________________ > 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 cb.list6@gmail.com Mon Oct 10 07:06:52 2011 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 D6AFC21F8B26 for ; Mon, 10 Oct 2011 07:06:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcrOzQF-vHGL for ; Mon, 10 Oct 2011 07:06:52 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 144BA21F84A8 for ; Mon, 10 Oct 2011 07:06:52 -0700 (PDT) Received: by qyk33 with SMTP id 33so4624242qyk.10 for ; Mon, 10 Oct 2011 07:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Js9XvPuI9by8kGgJwlgGVFrLU9eRjyLSnNs+jickI/A=; b=SWL0XgakACE2yxI8czdewuSpZ1NOCpjvNxgLIorYm15avBYw/CP0UjLzEhWL3AFTNk oGC4FL/1R768HclFmiddi3DkYVDwt+41RWA6RecBgIpK+4MeLz3xRVXhRbn+cfHu94Gn VlEleG7anBVFIh/OWF4Dwyr49IX7+PWNH8T6U= MIME-Version: 1.0 Received: by 10.68.13.40 with SMTP id e8mr37381407pbc.111.1318255611284; Mon, 10 Oct 2011 07:06:51 -0700 (PDT) Received: by 10.142.195.15 with HTTP; Mon, 10 Oct 2011 07:06:50 -0700 (PDT) Received: by 10.142.195.15 with HTTP; Mon, 10 Oct 2011 07:06:50 -0700 (PDT) In-Reply-To: References: <4E90CBC6.2030005@cisco.com> Date: Mon, 10 Oct 2011 07:06:50 -0700 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec5215f7d6f0bf604aef24d58 Cc: homenet@ietf.org, Shishio Tsuchiya Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 14:06:53 -0000 --bcaec5215f7d6f0bf604aef24d58 Content-Type: text/plain; charset=ISO-8859-1 On Oct 9, 2011 11:16 PM, "Mikael Abrahamsson" wrote: > > On Sun, 9 Oct 2011, Shishio Tsuchiya wrote: > >> 2^64 host address space would be too enough for homenet. > > > I would just like to comment on this even though you retracted your question. > > As an ISP, I do not want to participate in a home with hundreds or thousands of active IPv6 addresses that I need to keep state for. Most likely, when we have central equipment participating in a home network, we'll implement a limit on number of neighbours it'll allow on the subnet. Doing ND/NS a lot takes resources. > > If customer wants to use more IPv6 addresses, we'll require them to get a home router and PD address space to it to distribute the ND/NS load. > Agreed. But I think it is worth noting that nd-proxy is practical in mobile networks where each subscriber gets a unique /64. Mobile network attachment has popped up a few times in homenet discussions. Cb > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --bcaec5215f7d6f0bf604aef24d58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Oct 9, 2011 11:16 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Sun, 9 Oct 2011, Shishio Tsuchiya wrote:
>
>> 2^64 host address space would be too enough for homenet.
>
>
> I would just like to comment on this even though you retracted your qu= estion.
>
> As an ISP, I do not want to participate in a home with hundreds or tho= usands of active IPv6 addresses that I need to keep state for. Most likely,= when we have central equipment participating in a home network, we'll = implement a limit on number of neighbours it'll allow on the subnet. Do= ing ND/NS a lot takes resources.
>
> If customer wants to use more IPv6 addresses, we'll require them t= o get a home router and PD address space to it to distribute the ND/NS load= .
>

Agreed. But I think it is worth noting that nd-proxy is=A0 practical in = mobile networks where each subscriber gets a unique /64.

Mobile network attachment has popped up a few times in homenet discussio= ns.

Cb
> --
> Mikael Abrahamsson =A0 =A0email: s= wmike@swm.pp.se
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--bcaec5215f7d6f0bf604aef24d58-- From bs7652@att.com Mon Oct 10 07:19:06 2011 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 ADE5421F8B02 for ; Mon, 10 Oct 2011 07:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POAeLHwOrasW for ; Mon, 10 Oct 2011 07:19:06 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id E5D5921F8AFD for ; Mon, 10 Oct 2011 07:19:05 -0700 (PDT) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1318256343!43513907!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4751 invoked from network); 10 Oct 2011 14:19:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Oct 2011 14:19:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9AEHfcb019011; Mon, 10 Oct 2011 10:17:42 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p9AEHaB1018887; Mon, 10 Oct 2011 10:17:36 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 10:18:14 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 10:18:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 10:18:56 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1FC292D1@crexc50p> In-Reply-To: <4E8F829C.9040902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] Thoughts about routing Thread-Index: AcyFQ582UBMVMiszS0qpt7Zplke6WQCCFaLg References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8F829C.9040902@cisco.com> From: "STARK, BARBARA H" To: "Erik Nordmark" , "Fred Baker" X-OriginalArrivalTime: 10 Oct 2011 14:18:14.0206 (UTC) FILETIME=[72A285E0:01CC8757] Cc: Thomas Narten , homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 14:19:06 -0000 The subset of tree topology where a consumer places ones router behind another router is *extremely* common. Statistics I saw several years ago suggested that probably about 60% of ADSL customers in the US use this topology. The most common cause for this topology is where the service provider supplies a free ADSL router with a single port to a subscriber, and the subscriber then puts their own multi-port router behind that router. The ADSL router is configured to do the PPPoE, and is also configured to automatically provide whatever public IP address it gets to whatever is behind it (via DHCPv4, as a sort of automatic DMZ function -- the ADSL router also uses that public IP address for its needs). The ADSL router is often set to provide only that one address, and not to support a full network of devices. Which is why consumers are forced to use their own router. This also tends to be how VoIP router + consumer's wireless router topology works. I'm sure some people would like to argue as to why this is bad, or it shouldn't be done. I'm not going to get into that argument. That argument is irrelevant. The fact is that it's very, very common.=20 I agree with those who say that we *don't* need to make sure IPv4 works everywhere that IPv6 works. But I think it's an absolute requirement that IPv6 MUST work everywhere that IPv4 works. And this is a very common case where IPv4 works. When going to IPv6, the ADSL router will also be the device that establishes the IPv6 connection. Because the credentials are the same as for IPv4, and the secondary router doesn't have those credentials. And the consumer forgot the credentials long ago, and doesn't remember how to configure this stuff anyway. IMO, I believe that the best approach would be to solve tree generically. Which means that the probability of "tree network" would actually be "common, perhaps 30th percentile" (dividing my "60% in ADSL networks" by 2). Barbara > -----Original Message----- > On 10/7/11 12:48 AM, Fred Baker wrote: > > I suggested that the probability of use of each of the scenarios on > slide 4 were > > single router network: 90th percentile > > tree network: unusual > > multi-router: perhaps 5th percentile > > multihomed: unusual >=20 > Fred, >=20 > are the above numbers based on any survey data? >=20 > Reason I'm asking is that I have two consumer devices with IPv4 NAT in > my home (a VoIP box and a backup device) where the instructions said: > 1. Insert between or existing router (or PC if you have no router) and > the DSL/cable modem > 2. Insert between your PC and your existing router (or modem if you > have > no router) >=20 > Those consumer instructions naturally result in a daisy-chain of IPv4 > RGs/NATs, which is a subset of a tree topology. >=20 > I can't be the only person who have a VoIP box or a Time Capsule. >=20 > Erik > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From victor.kuarsingh@gmail.com Mon Oct 10 07:26:06 2011 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 4C1F221F8A55 for ; Mon, 10 Oct 2011 07:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFjMdWbzC7oW for ; Mon, 10 Oct 2011 07:26:05 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A74A921F8801 for ; Mon, 10 Oct 2011 07:26:05 -0700 (PDT) Received: by ggnk3 with SMTP id k3so5648831ggn.31 for ; Mon, 10 Oct 2011 07:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=ZxhFsBQPcaFQHFMqAOCYOQFtpO4wtlpuLZiGlB3Ijj0=; b=ORYnahEcq2R+1jJeElSZB9DuIbVkbAkqQIqTfRIUYI1AuCi1Lzy8iLHmTExNpEAPH+ txGp+BCTbt+orZHX9XLaZlrcmQ44zjLxPCr++3b8GA0TcZINrSt5mhuYSkQcIQxxp61b tdIyui99OmVkEMssQaG4Em/e9aBBn9+hiE+ns= Received: by 10.236.181.131 with SMTP id l3mr13551085yhm.105.1318256764120; Mon, 10 Oct 2011 07:26:04 -0700 (PDT) Received: from [192.168.1.2] ([74.198.164.26]) by mx.google.com with ESMTPS id u45sm26238678yhh.8.2011.10.10.07.26.00 (version=SSLv3 cipher=OTHER); Mon, 10 Oct 2011 07:26:02 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 10 Oct 2011 10:25:54 -0400 From: Victor Kuarsingh To: Cameron Byrne , Mikael Abrahamsson Message-ID: Thread-Topic: [homenet] Does ND Proxy useful for homenet? In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3401087164_17112961" Cc: homenet@ietf.org, Shishio Tsuchiya Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 14:26:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3401087164_17112961 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit >> On Sun, 9 Oct 2011, Shishio Tsuchiya wrote: >> >>> 2^64 host address space would be too enough for homenet. >> >> >> I would just like to comment on this even though you retracted your question. >> >> As an ISP, I do not want to participate in a home with hundreds or thousands of active IPv6 addresses that I need to keep state for. Most likely, when we have central equipment participating in a home network, we'll implement a limit on number of neighbours it'll allow on the subnet. Doing ND/NS a lot takes resources. >> >> If customer wants to use more IPv6 addresses, we'll require them to get a home router and PD address space to it to distribute the ND/NS load. >> >Agreed. But I think it is worth noting that nd-proxy is practical in mobile networks where each subscriber gets a unique /64. >Mobile network attachment has popped up a few times in homenet discussions. Yes, this will useful in a number of use cases with mobile attachment. Tethering and other like operations come to mind. A good reference is - draft-ietf-v6ops-3gpp-eps for mobile operation. Victor K >Cb >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> _______________________________________________ >> 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 --B_3401087164_17112961 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

>> On Sun, 9 Oct 2011, Shishio Tsuchiya wrote:
>= ;>
>>> 2^64 host address space would be too enough for homene= t.
>>
>>
>> I would just like to comment on this = even though you retracted your question.
>>
>> As an ISP, = I do not want to participate in a home with hundreds or thousands of active = IPv6 addresses that I need to keep state for. Most likely, when we have cent= ral equipment participating in a home network, we'll implement a limit on nu= mber of neighbours it'll allow on the subnet. Doing ND/NS a lot takes resour= ces.
>>
>> If customer wants to use more IPv6 addresses, w= e'll require them to get a home router and PD address space to it to distrib= ute the ND/NS load.
>>

>Agreed. But I think it is worth no= ting that nd-proxy is  practical in mobile networks where each subscrib= er gets a unique /64.

>Mobile network attachment has popped up a f= ew times in homenet discussions.


Yes, this wil= l useful in a number of use cases with mobile attachment.  Tethering an= d other like operations come to mind.  
A good reference is -=  draft-ietf-v6ops-3gpp-eps for mobile operation.

Victor K

>Cb>> --
>> Mikael Abrahamsson    email: swmike@swm.pp.se
>>
>> ________= _______________________________________
>> homenet mailing list
= >> homenet@ietf.org
>> = https://www.ietf.org= /mailman/listinfo/homenet

_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.or= g/mailman/listinfo/homenet --B_3401087164_17112961-- From jari.arkko@piuha.net Mon Oct 10 08:10:33 2011 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 34F9921F8520 for ; Mon, 10 Oct 2011 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.37 X-Spam-Level: X-Spam-Status: No, score=-101.37 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo-ObgFZI85O for ; Mon, 10 Oct 2011 08:10:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A0DCB21F863E for ; Mon, 10 Oct 2011 08:10:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 651872D543; Mon, 10 Oct 2011 18:10:31 +0300 (EEST) 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 Nz1N1YjKuqmU; Mon, 10 Oct 2011 18:10:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BEC892CE32; Mon, 10 Oct 2011 18:10:30 +0300 (EEST) Message-ID: <4E930AE6.9010206@piuha.net> Date: Mon, 10 Oct 2011 18:10:30 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: homenet@ietf.org, "Stark, Barbara" References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8F829C.9040902@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F1FC292D1@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1FC292D1@crexc50p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 15:10:33 -0000 Barbara, Thank you very much for providing a concrete data point! I also agree with what you say below: > I'm sure some people would like to argue as to why this is bad, or it > shouldn't be done. I'm not going to get into that argument. That > argument is irrelevant. The fact is that it's very, very common. > > I agree with those who say that we*don't* need to make sure IPv4 works > everywhere that IPv6 works. > But I think it's an absolute requirement that IPv6 MUST work everywhere > that IPv4 works. Jari From pthubert@cisco.com Mon Oct 10 08:33:04 2011 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 E7ECE21F8B4A for ; Mon, 10 Oct 2011 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=4.470, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu-A2+SMXfwj for ; Mon, 10 Oct 2011 08:33:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81321F8B35 for ; Mon, 10 Oct 2011 08:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=5474; q=dns/txt; s=iport; t=1318260782; x=1319470382; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UPyb8pKADGWX7Y9nJanCOC/FQzjM2Ho1LnUigf1RG2U=; b=UyvkK0ziDkkHi0X/ilhlEOKnF7TgRWWY+y+nZUzK+qPjANZEWpLstDkL iHOlUJPJ04f8FAQ+kg6WgeY1IP6BqWWN+WgF+vpN7WQVHwyiNOxz6q+LV 63vMaPuN0VlGwLL5w0K0qUh/rW4X6NoqTOdZs3LwNZcQm0KhFZf7h/3IR k=; X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="118737522" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2011 15:33:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9AFX11W013793; Mon, 10 Oct 2011 15:33:01 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 17:33:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 17:33:00 +0200 Message-ID: In-Reply-To: <1EF79398-29B8-4CDB-A2C9-1224A6F6DF76@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] Multilink subnet routing (MLSRv2) Thread-Index: AcyHP1f0yfWg9a9CTOiSykUHi8NGOwAFVdvg References: <1EF79398-29B8-4CDB-A2C9-1224A6F6DF76@cisco.com> From: "Pascal Thubert (pthubert)" To: "Ole Troan" X-OriginalArrivalTime: 10 Oct 2011 15:33:01.0565 (UTC) FILETIME=[E54F2AD0:01CC8761] Cc: homenet@ietf.org, "Erik Nordmark \(nordmark\)" Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 15:33:05 -0000 Hi Ole > we (as in homenet) do not want to require host changes. And when hosts get smarter we (as in people living in homes) should benefit from it.=20 The case of plain hosts was long debated but it would have overloaded the specs quite a bit. What we have so far: The backbone router proxies ND between a L2 backbone and one or more MLSN extensions; this allows a plain (classical) host connected to the backbone to transparently reach devices that are located over the MLSN.=20 Things get touchy if we want to support the case of a plain device that would attach deep into the MLSN. You will not find that support specified in current RPL or 6LoWPAN specs. There's a good start though since RPL is designed to transport the material that is required by the leaf router to build RAs, so for the purpose of forming an address we can make believe that the plain host is really connected to the subnet.=20 But the question is how the formed address can be DADed and routed. In the absence of an explicit and maintained registration, the attachment router/switch has to snoop and then proxy, either as an ND registration or as redistribution into the routing protocol; If the device as a unique, P2P connection with the router, then we can reuse what we learnt in SAVI to maintain states in the router on behalf of the plain host. If the device is connected to multiple routers and/or the device is mobile and changes that point(s) of attachment over time, things can get a lot messier. > I also think the issues with flooding ND has been explored in RFC4903. Thanks for pointing this. RFC 4903 explores a number of aspects, not just ND, and in particular, TTL and link scope multicast. Specifically focusing on ND, the scope and propagation of multicast already required a new protocol. RPL started as an ND extension if you care to browse the early drafts. The work that I listed below addresses for a large part the problem of ND over MLSN, yet does a limited job for generic link scope multicast. Then again there is a good start with the optimized flooding with trickle that is good for all nodes and all routers, and a support for a multicast tree along the RPL DAG for generic multicast. Cheers, Pascal On Oct 10, 2011, at 9:33 , Pascal Thubert (pthubert) wrote: > Hi Ole: >=20 > I think you're getting closer and closer to the models that were=20 > discussed in RPL, 6LoWPAN and Autoconf. >=20 > There are several components to the solution that was proposed there: > - capability to register an IPv6 address using ND extensions > - capability to extend a subnet over multiple hops (RPL DIO prefix > option) > - capability to redistribute ND registration into the MLSN routing=20 > protocol > - capability to use the ND registrar (and/or) the routing protocol for > DAD > - capability for the registrar to proxy ND over a backbone in order to > interact with classical ND clients >=20 > See: > http://tools.ietf.org/html/rfc5889 > http://tools.ietf.org/html/draft-ietf-6lowpan-nd > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >=20 > cheers, >=20 > Pascal >=20 >=20 > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On=20 > Behalf Of Ole Troan > Sent: lundi 10 octobre 2011 00:38 > To: Erik Nordmark (nordmark) > Cc: homenet@ietf.org > Subject: [homenet] Multilink subnet routing (MLSRv2) >=20 > Erik, et al, >=20 > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it=20 > hasn't really been described anywhere) as a method for numbering a=20 > routed home. please let me be clear that I'm not convinced this is a=20 > good idea. i.e. why not just get < /64? > I do think we could get something working though. >=20 > routers can be in an arbitrary topology. all routers running a routing > protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA=20 > or proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its=20 > interfaces. L bit is 0. >=20 > the link model here is that all hosts are off link from each other. > link-local scope is restricted to only the physical link. multicast=20 > link-local scope as well. >=20 > a host uses SLAAC (or DHCP) to create an address, then does DAD as=20 > normal. the first hop router uses it's routing topology database to=20 > check for conflicts. similar mechanisms described in SAVI are used to=20 > glean address information from the host. the SAVI binding database is=20 > then used to inject host routes into the IGP. >=20 > this requires no flooding of ND, or any other changes to on-link=20 > protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some > form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with=20 > this mechanism. >=20 > cheers, > Ole >=20 > _______________________________________________ > 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 mcr@sandelman.ca Mon Oct 10 08:50:23 2011 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 4355021F84BD for ; Mon, 10 Oct 2011 08:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[AWL=1.140, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN5Fzgwu696c for ; Mon, 10 Oct 2011 08:50:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7121F84BA for ; Mon, 10 Oct 2011 08:50:22 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 9B5503439F for ; Mon, 10 Oct 2011 11:49:17 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id B21EB98CAD; Mon, 10 Oct 2011 11:51:10 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id AE56B98C90 for ; Mon, 10 Oct 2011 11:51:10 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 10 Oct 2011 11:51:10 -0400 Message-ID: <30133.1318261870@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 10 Oct 2011 15:50:23 -0000 >>>>> "james" == james woodyatt writes: >> There will be wide area network providers who interwork with the >> home network but do not provide global connectivity. Two >> mentioned so far are utility networks and 3g providers. One of >> the outputs of the wg should be to define how they should be >> configured to perform their role without messing up Internet >> communication. james> Those utility networks have a fundamental problem that I james> contend is beyond the scope and charter of HOMENET. james> Utility networks of that sort do not provide transit to the james> Internet default-free zone. They must therefore obtain their james> routes to residential networks bilaterally. This implies james> that these utility networks could be-- and would do well to james> be-- numbered with ULA prefixes, and that they should use of If you said, "ULA-Central" I would agree. I do not want to debug random packets on someone's network without whois. >> A wg Chair from the Internet area did accuse me of "breaking the >> Internet model" because the utility networks my company builds do >> not provide global connectivity to users with our 100kb to the >> node. james> That's really not the problem, if you want my humble opinion. james> The problem, I would say, is that these utility networks james> insist on extending their private routing domains into our james> home networks where they don't belong and they aren't james> welcome. It does break the *I*nternet model: the one where the ISPs control everything like the telcos did before, and I need to beg to be allowed to receive SYN packets. Why do I care if it breaks the business plans of some ISPs? But the IETF needs to spend more time worrying about the *Internet Protocols* rather than just the *I*nternet. >> [...] 6. The lookup of foo.ispA.net works over either DNS and >> returns the same IP address, but the application-layer content is >> completely different (e.g., a "subscriber" view when connecting >> over the ISP-A connection). james> This is the basic problem faced by any multi-homed host, james> e.g. a personal computer with a 3G interface and a Wi-fi james> interface that are simultaneously active, along with a james> split-tunnel VPN interface [or three] running on one or both james> interfaces. james> It is a problem for host operating systems and applications james> developers. I suggest HOMENET should steer well clear of it, james> and just about every related problem that is too easily james> conflated with it. What is the set of problems left for homenet then? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Mon Oct 10 10:05:37 2011 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 274A721F8558 for ; Mon, 10 Oct 2011 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WB61ZBkhNmv for ; Mon, 10 Oct 2011 10:05:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8421F84FC for ; Mon, 10 Oct 2011 10:05:35 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 874FC343B3; Mon, 10 Oct 2011 13:04:30 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6A03098CAD; Mon, 10 Oct 2011 13:06:23 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6244198C90; Mon, 10 Oct 2011 13:06:23 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4E8A658B.9060200@cisco.com> References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 10 Oct 2011 13:06:23 -0400 Message-ID: <8438.1318266383@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Erik Nordmark Subject: [homenet] walled garden DNS 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, 10 Oct 2011 17:05:37 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Erik" =3D=3D Erik Nordmark writes: Erik> 4. Looking up foo.ispA.net works when asking the DNS server at Erik> ISP-A, but fails (NXDOMAIN) when asking ISP-B. Erik> 5. The lookup of foo.ispA.net works over either DNS and Erik> returns the same IP address, but fails (due to firewalls) for Erik> packets that are sent out via ISP-B. Erik> 6. The lookup of foo.ispA.net works over either DNS and Erik> returns the same IP address, but the application-layer content Erik> is completely different (e.g., a "subscriber" view when Erik> connecting over the ISP-A connection). We have heard requests for a facility to provide hosts information of the sort: when looking for an FQDN that has suffix "X", please contact server "Y" And my question is: isn't that what an NS record is? It seems to me that we can solve all of the walled garden DNS in IPv6 land, with an arrangement like: example.com NS reachable by the world. garden.example.com NS pointing to AAAA record, where IPv6 address is only reachable from garden. television.garden.example.com AAAA returned from garden.example.com name server (above) This solution works perfectly in IPv4 land, but due to lack of IPv4 global address space, the NS for garden.example.com winds up pointing to RFC1918 address, and not only does this look bad, but it can in fact cause failures if there really is a DNS server at that address. It seems to me that we just don't need anything else in IPv6, except easily *available* non-connected PI address space (whether it's ULA-C, some recognized part of 2000::/3, or an entirely new space). NOTE: the existing ingress filtering problem means that one must assume that walled gardens will have to provide address space to the home that will be used to talk to them. A challenge to the walled garden people's thought process is that they might be thinking that they need 1-IP per customer, when in fact, they need to have at least a /60 per customer. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpMmDoCLcPvd0N1lAQK1Rgf/brj5f4KPG6ISaV6Dj5i+tQkixUwn5kr7 xjhnvk9ObxgU8hVbcjC+ntQVxTgtm/b7/JGuzrcDHhCy53PV8TDpWaWJycj4QdoN dGxq2qqALIvCeDN+jO2BxW5D1ZSH8I/srUoidc/+JyCU3sfbmk/9zrDEyECLjqq5 lyufFjuc1HR3b+eO6fcGFLtKtTpxutrwmpJSQSraFfzyT+qeNMwkY1qJQUdopnfT PnaNNJngG0QPI6ZIVGVYczPYXbNtCluOH4YuHOjmHoYMsdu7IPLhAWfjS7UuywYI FaeSo6+lZpOIA+3u0XRs158uDP4fFmMAtMMF+ha5jYBoxsfJ39F7jQ== =MrxZ -----END PGP SIGNATURE----- --=-=-=-- From fred@cisco.com Mon Oct 10 10:18:37 2011 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 0B3D321F8C4C for ; Mon, 10 Oct 2011 10:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qdd1lu32hFY for ; Mon, 10 Oct 2011 10:18:36 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7321F8C4B for ; Mon, 10 Oct 2011 10:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3333; q=dns/txt; s=iport; t=1318267116; x=1319476716; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=60GwfBlj2rB/J5NovXjhZrz6r7GAGYggBYsToZ7CSN0=; b=WTtrBtVQI4d70ySUWQBnCauuB2Iqn9/9aZfBp4eDJ5kFce+JqIwDDZUs quP2edyBI3INgW9rh52xVGoM0DRswKGxPanemTxZ6ioynyTAlxZ3Xh1mR I2Wr9qQXx5MWt0CMHpndFOfWWnKWXLK0kQTHuRu/zT3nkdoBOE29YDkD9 8=; X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="7007464" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 10 Oct 2011 17:18:36 +0000 Received: from Freds-Computer.local ([10.21.118.39]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9AHIZ1K023503; Mon, 10 Oct 2011 17:18:35 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 10 Oct 2011 13:18:35 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 10 Oct 2011 13:18:35 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1FC292D1@crexc50p> Date: Mon, 10 Oct 2011 13:18:25 -0400 Message-Id: <26CE370B-20B2-4FF1-8DC0-1071668197C0@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8F829C.9040902@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F1FC292D1@crexc50p> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Erik Nordmark , homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 17:18:37 -0000 Thanks. That is a big update to my numbers, but one that is important here. On Oct 10, 2011, at 10:18 AM, STARK, BARBARA H wrote: > The subset of tree topology where a consumer places ones router behind > another router is *extremely* common. Statistics I saw several years ago > suggested that probably about 60% of ADSL customers in the US use this > topology. The most common cause for this topology is where the service > provider supplies a free ADSL router with a single port to a subscriber, > and the subscriber then puts their own multi-port router behind that > router. The ADSL router is configured to do the PPPoE, and is also > configured to automatically provide whatever public IP address it gets > to whatever is behind it (via DHCPv4, as a sort of automatic DMZ > function -- the ADSL router also uses that public IP address for its > needs). The ADSL router is often set to provide only that one address, > and not to support a full network of devices. Which is why consumers are > forced to use their own router. This also tends to be how VoIP router + > consumer's wireless router topology works. > > I'm sure some people would like to argue as to why this is bad, or it > shouldn't be done. I'm not going to get into that argument. That > argument is irrelevant. The fact is that it's very, very common. > > I agree with those who say that we *don't* need to make sure IPv4 works > everywhere that IPv6 works. > But I think it's an absolute requirement that IPv6 MUST work everywhere > that IPv4 works. > > And this is a very common case where IPv4 works. When going to IPv6, the > ADSL router will also be the device that establishes the IPv6 > connection. Because the credentials are the same as for IPv4, and the > secondary router doesn't have those credentials. And the consumer forgot > the credentials long ago, and doesn't remember how to configure this > stuff anyway. > > IMO, I believe that the best approach would be to solve tree > generically. Which means that the probability of "tree network" would > actually be "common, perhaps 30th percentile" (dividing my "60% in ADSL > networks" by 2). > Barbara > >> -----Original Message----- >> On 10/7/11 12:48 AM, Fred Baker wrote: >>> I suggested that the probability of use of each of the scenarios on >> slide 4 were >>> single router network: 90th percentile >>> tree network: unusual >>> multi-router: perhaps 5th percentile >>> multihomed: unusual >> >> Fred, >> >> are the above numbers based on any survey data? >> >> Reason I'm asking is that I have two consumer devices with IPv4 NAT in >> my home (a VoIP box and a backup device) where the instructions said: >> 1. Insert between or existing router (or PC if you have no router) and >> the DSL/cable modem >> 2. Insert between your PC and your existing router (or modem if you >> have >> no router) >> >> Those consumer instructions naturally result in a daisy-chain of IPv4 >> RGs/NATs, which is a subset of a tree topology. >> >> I can't be the only person who have a VoIP box or a Time Capsule. >> >> Erik >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet From swmike@swm.pp.se Mon Oct 10 10:39:08 2011 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 9F2BF21F8C71 for ; Mon, 10 Oct 2011 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT3blVP4uf2a for ; Mon, 10 Oct 2011 10:39:08 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 491A821F8C6E for ; Mon, 10 Oct 2011 10:38:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 163509E; Mon, 10 Oct 2011 19:38:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 13DBF9A; Mon, 10 Oct 2011 19:38:51 +0200 (CEST) Date: Mon, 10 Oct 2011 19:38:51 +0200 (CEST) From: Mikael Abrahamsson To: Cameron Byrne In-Reply-To: Message-ID: References: <4E90CBC6.2030005@cisco.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, Shishio Tsuchiya Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 17:39:08 -0000 On Mon, 10 Oct 2011, Cameron Byrne wrote: > Agreed. But I think it is worth noting that nd-proxy is practical in > mobile networks where each subscriber gets a unique /64. > > Mobile network attachment has popped up a few times in homenet > discussions. I think ND proxy has some use even in other cases, I would just like to be sure that there is consensus that this won't scale to a home with lots and lots of devices. The number 10 or 16 simulatenous active IPv6 addresses comes to mind, after that I don't want to know what they have in their home anymore, they'll have to route it themselves. -- Mikael Abrahamsson email: swmike@swm.pp.se From mcr@sandelman.ca Mon Oct 10 11:00:26 2011 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 785EA21F8508 for ; Mon, 10 Oct 2011 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R93I1StMOmuN for ; Mon, 10 Oct 2011 11:00:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id EEC7021F8507 for ; Mon, 10 Oct 2011 11:00:25 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 25E63343AE; Mon, 10 Oct 2011 13:59:21 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6545B98CAD; Mon, 10 Oct 2011 14:01:14 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 599D798C90; Mon, 10 Oct 2011 14:01:14 -0400 (EDT) From: Michael Richardson To: Ole Troan In-Reply-To: <1EF79398-29B8-4CDB-A2C9-1224A6F6DF76@cisco.com> References: <1EF79398-29B8-4CDB-A2C9-1224A6F6DF76@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 10 Oct 2011 14:01:14 -0400 Message-ID: <16075.1318269674@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "Erik Nordmark \(nordmark\)" , "Pascal Thubert \(pthubert\)" , homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 18:00:26 -0000 >>>>> "Ole" == Ole Troan writes: Ole> we (as in homenet) do not want to require host changes. I also Ole> think the issues with flooding ND has been explored in RFC4903. RPL benefits from host changes, but if you provide proxy-ND for the hosts which have not changed, then it much the same as MLSRv2, I think. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From nordmark@cisco.com Mon Oct 10 11:12:03 2011 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 A277A21F8C51 for ; Mon, 10 Oct 2011 11:12:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HSLrdzrKJzL for ; Mon, 10 Oct 2011 11:12:02 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6278221F8C4B for ; Mon, 10 Oct 2011 11:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1410; q=dns/txt; s=iport; t=1318270322; x=1319479922; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4Nag4wvrCqDFxa8AdYEUgqlEMY3zMGPHxPOh0wwPbVE=; b=HxbNsQ5JYGREQHvKtmOk7/dQ2KKq7aV/vS10I1N7h8INkrOod3M94Uj+ OmtwWTjCjUQyfLow2n6f9F/I9RD/YVBz8Ly89TqKcX8BILaXjv05IiK0+ 1UZ6ioGrnwiBpHDpykw1w0wb2879RAzQk7LPd9vwLkYKdy5RiyTz1g995 Y=; X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="7002975" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 10 Oct 2011 18:12:02 +0000 Received: from [128.107.115.155] ([128.107.115.155]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9AIC1Wq024259; Mon, 10 Oct 2011 18:12:02 GMT Message-ID: <4E93358F.7050907@cisco.com> Date: Mon, 10 Oct 2011 11:12:31 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jari Arkko References: <4E904C5D.5090908@piuha.net> In-Reply-To: <4E904C5D.5090908@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 10 Oct 2011 18:12:03 -0000 On 10/8/11 6:13 AM, Jari Arkko wrote: > I like this, with the possible exception of using ULAs and your desire > to deprecate prefixes as soon as connectivity goes down. (Speaking as > someone whose prefixes got invalidated two months ago but who hasn't > been home long enough to fix the problem, but my devices still happily > communicate with each other using the old prefixes :-) I also agree with > Erik that loop and arbitrary topologies is not really required. But the > people in the interim at least seemed to say yesterday that we want to > go there. I think there are different scopes being discussed. The one I put forth is how to enable existing IPv4 NATting consumer home routers (which all have a designated uplink port, and support multiple home routers by nested NATting) have a way to support IPv6 without requiring any IPv6 NATs. That doesn't seem to be a difficult problem (which perhaps makes it uninteresting for some of us), but to me it seems like an important short-term problem to solve. The larger scope is around arbitrary topologies, no designated uplink port, and perhaps also multihoming. Plenty of problems to solve around autoconfiguring routing protocols, stable prefix assignment to links, multihoming, etc. Some things are common across the two; security (determining the boundary of the home), DNS, and service discovery. Erik From nordmark@cisco.com Mon Oct 10 11:19:37 2011 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 D808321F8BDE for ; Mon, 10 Oct 2011 11:19:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL+vlQw+Umow for ; Mon, 10 Oct 2011 11:19:37 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEE021F8BD8 for ; Mon, 10 Oct 2011 11:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1792; q=dns/txt; s=iport; t=1318270777; x=1319480377; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Rqm6PBQDgBHG0dM4vm3sGIM1NcMBOn1R/CjF+JWaXoM=; b=CFJHT1gAYOZdzr5WSSvjGhGwuOUXwzctQuoKZObdL3wb+CWcD2OSaxFI 9E5iizVvhNco0kL2fGdzvc7R5WpRKFqrYXWwatQz6IBwKDmJaoKouEJI7 6Gc+vzaI159aaTPfu9QzFj47sl+zR47C4DYboAx9EYliL83q0FWYf2vYJ Y=; X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="7021110" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 10 Oct 2011 18:19:37 +0000 Received: from [128.107.115.155] ([128.107.115.155]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9AIJbYt002579; Mon, 10 Oct 2011 18:19:37 GMT Message-ID: <4E933756.30506@cisco.com> Date: Mon, 10 Oct 2011 11:20:06 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jari Arkko References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> <4E8F7873.4050505@cisco.com> <4E904CD2.1080705@piuha.net> In-Reply-To: <4E904CD2.1080705@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ole Troan , homenet@ietf.org, Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 10 Oct 2011 18:19:38 -0000 On 10/8/11 6:14 AM, Jari Arkko wrote: >> I think we first need to agree on what we think are the requirements >> on prefix stability. What if one of the routers attached to the link >> fails and is replaced by a different router? >> What if a link partitions? And later merges? >> What the user intentionally splits (partitions) a link (e.g., to >> create a separate link for the teenage game room); should the network >> automatically pick a new prefix for that new link? (How does that >> interact with the prefix being in stable storage on the router.) > > We talked about the stability requirements on Thursday a bit. From my > perspective the requirement is that crashes, power outages/recycles, and > addition of new devices must not cause existing allocations to change. > Other changes.... they may, and I think it would be too much effort and > complexity to try to prevent all changes in all situations. I suspect that if we can solve the above cases (e.g., for a link with two routers that crash, get powered off and on, and then later the user adds a third router to connect up with the garage network), then we will end up with something rather complete. There might be some more difficult aspects if we want to allow a router or its interfaces to be repurposed, such as splitting an existing link into two separate links. In that case it might be hard to avoid renumbering. The requirements question is whether the system needs to be able to detect that the link is now (intentionally) partitioned and as a result there are two separate prefixes needed for the two separate links, or whether the user needs to be able to push the "reset to factory defaults" if the user is going to reconfigure the topology in such ways. Erik From nordmark@cisco.com Mon Oct 10 11:24:05 2011 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 D9EB521F8C29 for ; Mon, 10 Oct 2011 11:24:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWh6XvDvX0Kv for ; Mon, 10 Oct 2011 11:24:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9D95A21F8BE5 for ; Mon, 10 Oct 2011 11:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1241; q=dns/txt; s=iport; t=1318271044; x=1319480644; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/9yyrMFgFgJYute9EO0DDVyigwBPEX4Y5LjBO3b8g6U=; b=cYcI7Ct/A3PK2FdIP5qKzbkH/S8MBKVJ9HGuZ/qnyLaNlahFAhXIcxb5 o7FpVZ68rkSDBKbfoDvJ7Tc+tEAhPAlOMCewJ8TL2UqyBR8jCpxt+QN/N bBiX2z6MaTbWNjSE1B59gAEvsql4ntWdHXzEHyN7ZlBWOCfrbar2qlgxt A=; X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="27293436" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 10 Oct 2011 18:24:04 +0000 Received: from [128.107.115.155] ([128.107.115.155]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9AIO4qR014042; Mon, 10 Oct 2011 18:24:04 GMT Message-ID: <4E933861.4040402@cisco.com> Date: Mon, 10 Oct 2011 11:24:33 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Michael Richardson References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8F829C.9040902@cisco.com> <27415.1318174417@marajade.sandelman.ca> In-Reply-To: <27415.1318174417@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 18:24:06 -0000 On 10/9/11 8:33 AM, Michael Richardson wrote: > >>>>>> "Erik" == Erik Nordmark writes: > Erik> Reason I'm asking is that I have two consumer devices with > Erik> IPv4 NAT in my home (a VoIP box and a backup device) where the > Erik> instructions said: 1. Insert between or existing router (or PC > Erik> if you have no router) and the DSL/cable modem 2. Insert > Erik> between your PC and your existing router (or modem if you have > Erik> no router) > > Erik> Those consumer instructions naturally result in a daisy-chain > Erik> of IPv4 RGs/NATs, which is a subset of a tree topology. > > That's a good point: many VoIP ATAs want to be the first device so that > they can control the QoS, and ideally get the public IP address. > > Does your VoIP box do PPPoE as well? Yes. It is basically a home gateway (without WiFi - wired Ethernet only) with a SIM slot and a phone connector added. Thus it has all the usual protocols and knobs for Internet connectivity. The backup device takes the same approach - start with a home gateway and add something (in that case a disk plus file sharing software) but don't remove anything. Erik From nordmark@cisco.com Mon Oct 10 11:42:57 2011 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 BC4AE21F8B9D for ; Mon, 10 Oct 2011 11:42:57 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrmPhxEOTEju for ; Mon, 10 Oct 2011 11:42:57 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCB821F8B00 for ; Mon, 10 Oct 2011 11:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=2470; q=dns/txt; s=iport; t=1318272177; x=1319481777; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wohEoCQXdpFxD5BethZpjmXWfAksklJVV2cgF4PltSM=; b=F5rjXDLbjFxaHJMA5md1J1OO9Zoj43Cw9AWEOfvXCI+N+0NHVd7O+q+j gcHRSfxeIXiWUc3977hOpo0feGkEBeC3kAdrt0nje/a+2vY5PckWT8zUB 5icymwm5H4wiKW6pzJb/qrxURDxTAkjzeDdYDlrHkyJfE8+DBJrCJGa6H E=; X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="7005761" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 10 Oct 2011 18:42:56 +0000 Received: from [128.107.115.155] ([128.107.115.155]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9AIguOP030614; Mon, 10 Oct 2011 18:42:56 GMT Message-ID: <4E933CCE.6020606@cisco.com> Date: Mon, 10 Oct 2011 11:43:26 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ole Troan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 18:42:57 -0000 On 10/9/11 3:38 PM, Ole Troan wrote: > Erik, et al, > > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't really been described anywhere) as a method for numbering a routed home. please let me be clear that I'm not convinced this is a good idea. i.e. why not just get< /64? > I do think we could get something working though. > > routers can be in an arbitrary topology. all routers running a routing protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA or proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its interfaces. L bit is 0. > > the link model here is that all hosts are off link from each other. link-local scope is restricted to only the physical link. multicast link-local scope as well. And I assume the routers would pass around /128 routes for the hosts in the home, and would automatically inject such a route when the SAVI-style table learns about a new address. Are those assumptions correct? > a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. the first hop router uses it's routing topology database > to check for conflicts. similar mechanisms described in SAVI are used to glean address information from the host. the SAVI binding > database is then used to inject host routes into the IGP. What happens when the router crashes - does it loose its SAVI-style table? Does it keep it in stable storage? If it looses it, then nobody would know on what link the hosts are, since the hosts aren't required to periodically send any announcement to the routers. What happens when a packet arrives for an IP address that is in the /64 prefix for the home, but there is no /128 route for it? Flood everywhere? Drop? We looked that this when we worked on 6lowpan-nd, and concluded that by doing explicit registrations from hosts to routers (the Address Registration Option) with a lifetime we can make such networks work well without requiring stable storage. But that implies a host change. Erik > this requires no flooding of ND, or any other changes to on-link protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with this mechanism. > > cheers, > Ole > From townsley@cisco.com Mon Oct 10 12:19:24 2011 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 DA23121F8C73 for ; Mon, 10 Oct 2011 12:19:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ711x2Lza3L for ; Mon, 10 Oct 2011 12:19:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF3C21F8C72 for ; Mon, 10 Oct 2011 12:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=3013; q=dns/txt; s=iport; t=1318274364; x=1319483964; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ag5G13s49rnsO05pB10qDw7gicPlcKbWX/TF+OpjZ28=; b=QILYk6Xg880PScWmm8J129MHeK/FFW/iV5llMAfq1RsyExlXmwCOJZTL KTIciJ9Q0wWMmfSw4OhSQGvCkTlqzOyGK7Qlh/ZME7JAQbzvGJ60iruUu wHthUkKLWFwI7d4cSZvLdeWU2aF4HybT4Ygl83CTe1sL4/8khpZ89UVgK c=; X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="27331985" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 10 Oct 2011 19:19:23 +0000 Received: from dhcp-222-127.meetings.nanog.org (rtp-vpn3-1701.cisco.com [10.82.222.172]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9AJJNAu031357; Mon, 10 Oct 2011 19:19:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4E933CCE.6020606@cisco.com> Date: Mon, 10 Oct 2011 15:19:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <87D31944-1AA0-4A4E-9EF4-1630F3A00823@cisco.com> References: <4E933CCE.6020606@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: Ole Troan , homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 19:19:25 -0000 On Oct 10, 2011, at 2:43 PM, Erik Nordmark wrote: > On 10/9/11 3:38 PM, Ole Troan wrote: >> Erik, et al, >>=20 >> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it = hasn't really been described anywhere) as a method for numbering a = routed home. please let me be clear that I'm not convinced this is a = good idea. i.e. why not just get< /64? >> I do think we could get something working though. >>=20 >> routers can be in an arbitrary topology. all routers running a = routing protocol. >> the site prefix (/64) is either advertised in the IGP with a new LSA = or proxying of RA messages is done (split horizon). >> a router advertises the same /64 prefix (in a PIO) on all of its = interfaces. L bit is 0. >>=20 >> the link model here is that all hosts are off link from each other. = link-local scope is restricted to only the physical link. multicast = link-local scope as well. >=20 > And I assume the routers would pass around /128 routes for the hosts = in the home, and would automatically inject such a route when the = SAVI-style table learns about a new address. > Are those assumptions correct? >=20 >> a host uses SLAAC (or DHCP) to create an address, then does DAD as = normal. the first hop router uses it's routing topology database >> to check for conflicts. similar mechanisms described in SAVI are used = to glean address information from the host. the SAVI binding >> database is then used to inject host routes into the IGP. >=20 > What happens when the router crashes - does it loose its SAVI-style = table? Does it keep it in stable storage? >=20 > If it looses it, then nobody would know on what link the hosts are, = since the hosts aren't required to periodically send any announcement to = the routers. >=20 > What happens when a packet arrives for an IP address that is in the = /64 prefix for the home, but there is no /128 route for it? Flood = everywhere? Drop? >=20 > We looked that this when we worked on 6lowpan-nd, and concluded that = by doing explicit registrations from hosts to routers (the Address = Registration Option) with a lifetime we can make such networks work well = without requiring stable storage. I heard a lot about stable storage being a requirement for a homenet = router... and not much objection from the vendor reps. Perhaps that is a = difference between homenet and lowpan. - Mark >=20 > But that implies a host change. >=20 > Erik >=20 >> this requires no flooding of ND, or any other changes to on-link = protocols for loop detection. no changes in hosts either. >> only downside is that it requires a host to have sent a packet of = some form for the SAVI binding to be initiated. >> it might also be possible to support host mobility with the home with = this mechanism. >>=20 >> cheers, >> Ole >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Mon Oct 10 12:40:24 2011 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 A1E5E21F8AF8 for ; Mon, 10 Oct 2011 12:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlwkLpI7AKez for ; Mon, 10 Oct 2011 12:40:24 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 141D021F8ADE for ; Mon, 10 Oct 2011 12:40:23 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id EE9CE343B1 for ; Mon, 10 Oct 2011 15:39:17 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 4793C98CAD; Mon, 10 Oct 2011 15:41:11 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4119398C90 for ; Mon, 10 Oct 2011 15:41:11 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: References: <4E90CBC6.2030005@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 10 Oct 2011 15:41:11 -0400 Message-ID: <30101.1318275671@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 19:40:24 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mikael" =3D=3D Mikael Abrahamsson writes: >> Agreed. But I think it is worth noting that nd-proxy is practical >> in mobile networks where each subscriber gets a unique /64. >>=20 >> Mobile network attachment has popped up a few times in homenet >> discussions. Mikael> I think ND proxy has some use even in other cases, I would Mikael> just like to be sure that there is consensus that this won't Mikael> scale to a home with lots and lots of devices. The number 10 Mikael> or 16 simulatenous active IPv6 addresses comes to mind, Mikael> after that I don't want to know what they have in their home Mikael> anymore, they'll have to route it themselves. So, I think that most of us were thinking that proxy-ND is what the home does when the home runs out of it's /60. I don't see why the ISP would ever see this.=20=20=20 Or are you saying a mobile device (a smartphone) will only ever get a /64 to share? =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpNKV4CLcPvd0N1lAQL77wf/V2w2sjrOAS4MJVbwPoFjXUHZ7lunSwoL oTwz5yLkFNG+1UMLjV/IM6k0A2EKchHZu6dh6uoGfpNuwcpf0yvPLezfmT/TQWeB fTojnSpYLqL6uxS/g9AsBv1WVaKNitJehq1iSTB0g1xgTbXMKvXZ3b54V+29m+gM 6BgT7fc6UgkPMU1GROdajrjH+M3vEzCZ1iHzdlr7kziZXW0p6ZsGsd2l5dbPBGtm j3/UaY78vpNvCamy8uLu3UxOQ9M14e9uAS8Hnzy5+m0fDIUd7qQmMtwKaXgoTW5z nK0veNv+XEZzDiBvmja2jMW9BXv1chMn+MIRXFG0enXY4sAR7nQRHw== =nFYw -----END PGP SIGNATURE----- --=-=-=-- From cb.list6@gmail.com Mon Oct 10 12:59:41 2011 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 9099921F8C48 for ; Mon, 10 Oct 2011 12:59:41 -0700 (PDT) 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.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRQ1D59U-sdK for ; Mon, 10 Oct 2011 12:59:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4A8E21F8C1A for ; Mon, 10 Oct 2011 12:59:40 -0700 (PDT) Received: by vws5 with SMTP id 5so6127086vws.31 for ; Mon, 10 Oct 2011 12:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hYtRSbsg4OhULRN9uXPDVCqJ9mphX+3+oBi13AxN4Fc=; b=Lx7t5POan2Raf3R7jhYkRngWX5C34XkI3AXino6qSWHCqozae3Y9F5YNDxjR/2L9OE 5T53Fet7uqvGucJZjbmFAMsm7UA4EVzBsug/tpelq3FCz8N446UU91lW6eKl1QWLd2CY rOjrI2EIyl5KnEsR1clc2IPwEyhfDHQZLNbyI= MIME-Version: 1.0 Received: by 10.68.31.132 with SMTP id a4mr39885726pbi.26.1318276779748; Mon, 10 Oct 2011 12:59:39 -0700 (PDT) Received: by 10.142.195.15 with HTTP; Mon, 10 Oct 2011 12:59:39 -0700 (PDT) In-Reply-To: <30101.1318275671@marajade.sandelman.ca> References: <4E90CBC6.2030005@cisco.com> <30101.1318275671@marajade.sandelman.ca> Date: Mon, 10 Oct 2011 12:59:39 -0700 Message-ID: From: Cameron Byrne To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 19:59:41 -0000 On Mon, Oct 10, 2011 at 12:41 PM, Michael Richardson wro= te: > >>>>>> "Mikael" =3D=3D Mikael Abrahamsson writes: > =A0 =A0>> Agreed. But I think it is worth noting that nd-proxy is practic= al > =A0 =A0>> in mobile networks where each subscriber gets a unique /64. > =A0 =A0>> > =A0 =A0>> Mobile network attachment has popped up a few times in homenet > =A0 =A0>> discussions. > > =A0 =A0Mikael> I think ND proxy has some use even in other cases, I would > =A0 =A0Mikael> just like to be sure that there is consensus that this won= 't > =A0 =A0Mikael> scale to a home with lots and lots of devices. The number = 10 > =A0 =A0Mikael> or 16 simulatenous active IPv6 addresses comes to mind, > =A0 =A0Mikael> after that I don't want to know what they have in their ho= me > =A0 =A0Mikael> anymore, they'll have to route it themselves. > > So, I think that most of us were thinking that proxy-ND is what the home > does when the home runs out of it's /60. =A0I don't see why the ISP would > ever see this. > > Or are you saying a mobile device (a smartphone) will only ever get a > /64 to share? > Today, yes. GSM/UMTS/LTE devices today only support local /64 from the mobile network, AFAIK... and I have seen implementations of ND Proxy. I have not seen anything aside from providing one network provided IPv4 address per mobile device (then the mobile will do its own NAT44 of that address)... but i may just be missing something there. My infrastructure is only setup to provide 1 IPv4 address and/or 1 /64 of IPv6. Some future spec's from 3GPP will allow for DHCPv6-PD, but that is forthcoming standards work and implementations. Cameron > -- > ] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 = =A0 =A0 | =A0firewalls =A0[ > ] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|ne= t architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device d= river[ > =A0 Kyoto Plus: watch the video > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition. > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > From townsley@cisco.com Mon Oct 10 13:01:05 2011 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 9F0CB21F84C9 for ; Mon, 10 Oct 2011 13:01:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksQ82pLwJhbb for ; Mon, 10 Oct 2011 13:01:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 920F121F84C3 for ; Mon, 10 Oct 2011 13:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=1849; q=dns/txt; s=iport; t=1318276864; x=1319486464; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+a967gDQ/fxTylWQDAz/F7HsEdNkAuHFrN9chOdpHEM=; b=lttaENILKLDNDiwGb6Xq2T4Tc9MLldOmvQBRybc/90ISKHxHK/xm8i3N bLZDydtuAEXfwR5si7c0A1Vlt98JIHzsoBAGMpjvn8L1mOF7l3DbUrIzV 07aHHcPXgJ5qAfZ7mj6B6aq37FxpxuH7Zv8UZGw4yEyq/JyQOXwLOl8bF Q=; X-IronPort-AV: E=Sophos;i="4.68,519,1312156800"; d="scan'208";a="27330045" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 10 Oct 2011 20:01:04 +0000 Received: from dhcp-222-127.meetings.nanog.org (rtp-vpn3-1701.cisco.com [10.82.222.172]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9AK14qW016728; Mon, 10 Oct 2011 20:01:04 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <30101.1318275671@marajade.sandelman.ca> Date: Mon, 10 Oct 2011 16:01:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93AB0566-AB67-4A2E-9AD5-026A0D186EAF@cisco.com> References: <4E90CBC6.2030005@cisco.com> <30101.1318275671@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) Cc: "Rajeev Koodli \(rkoodli\)" , homenet@ietf.org Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 20:01:05 -0000 On Oct 10, 2011, at 3:41 PM, Michael Richardson wrote: >=20 >>>>>> "Mikael" =3D=3D Mikael Abrahamsson writes: >>> Agreed. But I think it is worth noting that nd-proxy is practical >>> in mobile networks where each subscriber gets a unique /64. >>>=20 >>> Mobile network attachment has popped up a few times in homenet >>> discussions. >=20 > Mikael> I think ND proxy has some use even in other cases, I would > Mikael> just like to be sure that there is consensus that this = won't > Mikael> scale to a home with lots and lots of devices. The number = 10 > Mikael> or 16 simulatenous active IPv6 addresses comes to mind, > Mikael> after that I don't want to know what they have in their = home > Mikael> anymore, they'll have to route it themselves. >=20 > So, I think that most of us were thinking that proxy-ND is what the = home > does when the home runs out of it's /60. I don't see why the ISP = would > ever see this. =20 >=20 > Or are you saying a mobile device (a smartphone) will only ever get a > /64 to share? My (limited) understanding of the various 3/4G standards are that a PD = for a phone is something that is very, very, recent. Perhaps Rajeev = (cc'd) or someone else here can elucidate.=20 - Mark >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ > Kyoto Plus: watch the video = > then sign the petition.=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From townsley@cisco.com Mon Oct 10 13:04:19 2011 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 E089821F8B49 for ; Mon, 10 Oct 2011 13:04:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3h5Wpl+U+Bh for ; Mon, 10 Oct 2011 13:04:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3182721F8B52 for ; Mon, 10 Oct 2011 13:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=2643; q=dns/txt; s=iport; t=1318277059; x=1319486659; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Oay7cOJct7WJvyRlO0hL7EZhnyldrqfKJ+IH2VQTFBs=; b=HwPW3sPL34i0D+9zZYTu/HsvzCGuCOmKIi2ayHzhYUdcVGQdV+iiq7Wt DH6UkYxUuWSdldEgGibRLaxovCFM7WvwjFXepQm1I4fDmNiyqrPR55fWf m5I+MbukVNQw1OxCefkduWnkE56S25CZx+k3XqSa+100HSbvcO8pQR0G8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAFlPk06tJXG//2dsb2JhbABDpWuCN4EFgVMBAQEDAQEBAQ8BJzQLBQsLDgouHAswBhMZCYdcB5ogAZBtjUWGYmEEhj6IGQEBhR6LDYZh X-IronPort-AV: E=Sophos;i="4.68,519,1312156800"; d="scan'208";a="27330779" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 10 Oct 2011 20:04:17 +0000 Received: from dhcp-222-127.meetings.nanog.org (rtp-vpn3-1701.cisco.com [10.82.222.172]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9AK4Gan027929; Mon, 10 Oct 2011 20:04:16 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Mon, 10 Oct 2011 16:04:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41CEB5EF-2B9C-4B3D-980E-1B21335D86E3@cisco.com> References: <4E90CBC6.2030005@cisco.com> <30101.1318275671@marajade.sandelman.ca> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Michael Richardson Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 20:04:20 -0000 On Oct 10, 2011, at 3:59 PM, Cameron Byrne wrote: > On Mon, Oct 10, 2011 at 12:41 PM, Michael Richardson = wrote: >>=20 >>>>>>> "Mikael" =3D=3D Mikael Abrahamsson writes: >> >> Agreed. But I think it is worth noting that nd-proxy is = practical >> >> in mobile networks where each subscriber gets a unique /64. >> >> >> >> Mobile network attachment has popped up a few times in homenet >> >> discussions. >>=20 >> Mikael> I think ND proxy has some use even in other cases, I would >> Mikael> just like to be sure that there is consensus that this = won't >> Mikael> scale to a home with lots and lots of devices. The number = 10 >> Mikael> or 16 simulatenous active IPv6 addresses comes to mind, >> Mikael> after that I don't want to know what they have in their = home >> Mikael> anymore, they'll have to route it themselves. >>=20 >> So, I think that most of us were thinking that proxy-ND is what the = home >> does when the home runs out of it's /60. I don't see why the ISP = would >> ever see this. >>=20 >> Or are you saying a mobile device (a smartphone) will only ever get a >> /64 to share? >>=20 >=20 > Today, yes. GSM/UMTS/LTE devices today only support local /64 from > the mobile network, AFAIK... and I have seen implementations of ND > Proxy. I have not seen anything aside from providing one network > provided IPv4 address per mobile device (then the mobile will do its > own NAT44 of that address)... but i may just be missing something > there. My infrastructure is only setup to provide 1 IPv4 address > and/or 1 /64 of IPv6. >=20 > Some future spec's from 3GPP will allow for DHCPv6-PD, but that is > forthcoming standards work and implementations. Cameron not only beat me with an answer, he provided a more informed = one. Thanks! - Mark >=20 > Cameron >=20 >=20 >> -- >> ] He who is tired of Weird Al is tired of life! | = firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >> Kyoto Plus: watch the video = >> then sign the petition. >>=20 >>=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 mcr@sandelman.ca Mon Oct 10 13:16:56 2011 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 8538E21F8CAF for ; Mon, 10 Oct 2011 13:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ4OtlQbib7M for ; Mon, 10 Oct 2011 13:16:56 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 25AC021F8CAE for ; Mon, 10 Oct 2011 13:16:56 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id ADF3B3439F for ; Mon, 10 Oct 2011 16:15:50 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 1318898CAD; Mon, 10 Oct 2011 16:17:44 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0B5F898C90 for ; Mon, 10 Oct 2011 16:17:44 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4E933756.30506@cisco.com> References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> <4E8F7873.4050505@cisco.com> <4E904CD2.1080705@piuha.net> <4E933756.30506@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 10 Oct 2011 16:17:44 -0400 Message-ID: <2834.1318277864@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Homenet strawman slides 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, 10 Oct 2011 20:16:56 -0000 >>>>> "Erik" == Erik Nordmark writes: Erik> There might be some more difficult aspects if we want to allow Erik> a router or its interfaces to be repurposed, such as splitting Erik> an existing link into two separate links. In that case it Erik> might be hard to avoid renumbering. The requirements question Moving/repurposing a router without a factory reset seems like the perhaps the most important source of conflict in the architecture that we discussed. Particularly if the router is put into a junk drawer for a few months until it is needed. So, we might need to consider if we can expire persisted settings after some long (from the point of view of the network) time, like 1 week... -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From curtis@occnc.com Mon Oct 10 13:50:19 2011 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 1B41E21F84AB for ; Mon, 10 Oct 2011 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIOHBySgAcXp for ; Mon, 10 Oct 2011 13:50:17 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9A00821F8CE8 for ; Mon, 10 Oct 2011 13:50:17 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9AKoDdP055011; Mon, 10 Oct 2011 13:50:14 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9AKoDdP055011 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318279814; bh=JosL67J/0EfwTktODBU68avEIRa7/G0TSHy9m7dAQXM=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=WNfbJ9jmhbX5c1Sdph9BBvo41BrdiIqoEgN/6SYQCYch56CItThS+pJvUO98eEOk9 61g5lzumFGtOsyylrZYn8JG3lBDLWWc8Jao5md5YebujghMP/oMXxG9cgaHGwt8i3L e51lVLi9HPs+pec91eP4n6I/vvuntBnS9a/wFYvw= Message-Id: <201110102050.p9AKoDdP055011@gateway.ipv6.occnc.com> To: Ole Troan From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 00:38:28 +0200." Date: Mon, 10 Oct 2011 13:50:13 -0700 Cc: Erik Nordmark , homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:50:19 -0000 In message Ole Troan writes: > Erik, et al, > > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it > hasn't really been described anywhere) as a method for numbering a > routed home. please let me be clear that I'm not convinced this is a > good idea. i.e. why not just get < /64? I do think we could get > something working though. Having missed the meeting, anything more recent on MLSR than this: draft-ietf-ipv6-multilink-subnets-00 Multi-link Subnet Support in IPv6 (2002-07-08, Expired) draft-thaler-ipngwg-multilink-subnets-02 Multi-link Subnet Support in IPv6 (2001-11-29, Expired) The only reference to MLSR in an RFC is in an IAB RFC, RFC4903: There was also a proposal to define multi-link subnets [MLSR] for IPv6. However, this notion was abandoned by the IPv6 WG due to the issues discussed in this memo, and that proposal was replaced by a different mechanism that preserves the notion that a subnet spans only one link [RFC4389]. As to the second comment regarding /64: The magic /64 boundary should be interpreted as follows: Anything shorter than or equal to /64 can be globally routable. Anything longer than /64 may not be globally routable. For core routers the usual behaviour (or at least goal) is: Anything shorter than or equal to /64 can be forwarded at full speed, even for long bursts of very small packets. For anything matching a 64 bit "local subnet" address, look at the bottom /64 and still forward at full speed, even for long bursts of very small packets. For everything else (ie: not in a local subnet, and longer than /64 prefix) forward anyway, but maybe not at full speed. The whole purpose of this is that longer LPM lookups take time and at high speed like like 10 Gb/s or 100 Gb/s (or more), it is really hard to go faster without a high cost in silicon die area and power (and worse yet for anything using external TCAM, two external lookups). The /64 boundary was rather arbitrary. (And IMNSHO further evidence that 128 bit addrseeses was a bone headed choice and much too long, but it is way too late by about a decade or more to change that). There is no reasons that homenets (generally supporting 1 Gb/s or less) can't further subnet a /64. > routers can be in an arbitrary topology. all routers running a routing > protocol. the site prefix (/64) is either advertised in the IGP with > a new LSA or proxying of RA messages is done (split horizon). a > router advertises the same /64 prefix (in a PIO) on all of its > interfaces. L bit is 0. > > the link model here is that all hosts are off link from each > other. link-local scope is restricted to only the physical > link. multicast link-local scope as well. Not a good assumption. There will still be dumb Ethernet switches and bridging only WiFi hubs out there for a long time, so multiple hosts on a subnet/link. > a host uses SLAAC (or DHCP) to create an address, then does DAD as > normal. the first hop router uses it's routing topology database to > check for conflicts. similar mechanisms described in SAVI are used to > glean address information from the host. the SAVI binding database is > then used to inject host routes into the IGP. Neither SLAAC (rfc2462) or DHCP6 (rfc3315) supports allocation of a non-link-local prefix for the purpose of subdividing a prefix. For example, in DHCP6, the IA_TA and IA_NA are assumed to be link-local. The IA-PD added this capability to DHCP6, but there is no corresponding addition to SLAAC, so DHCP6 is preferred for routers. Where multiple routers exist, all will initially be sending an IA-PD request to each other. If there is no connectivity to a service provider who responds to an IA-PD, and none of the routers are configured, then none should respond (can't sub allocate what you don't have). If the provider sends an IA-PD, response with a /64, then that border router can respond with suballocations. There is no guidance in rfc3633 as to what to initially send in a IA-PD, but I suggest the following (which lacks loop suppression): send 0/112 (65K addressses) initially send 0/[len+8] if the following are both true: the router has received an IA-PD request from another router, and the router already has a prefix assignment, and the existing prefix assignment is too small, and len is the longest prefix length it has What is needed then is request loop suppression. A new IA-PD would be needed. One possibility is a new IA-PD option in which the set of IA-PD requestors is listed. This creates a path vector loop suppression, much like BGP using AS numbers. If a router gets two replies, prefer the one with the shorter path. Having set up one or more prefixes, a router can then select a router-Id (non-trivial) and start running a link state IGP (or link state IGP with specialized metric for LLN or whatever). That will have to be the topic of another thread (please). Another issue brought up is a multihomed connection. If the provider is smart, both of the connections will respond with the same /64 to an IA-PD request. That would be set up at service provisioning time. If the client was also smart, the border routers would not even bother with an IA-PD request and have the /64 configured. Absent of this, then the homenet would have two /64s to allocate from and would allocate from both. There is no harm in a subnet having more than one prefix allocated to it. If a routing protocol is running, then any arbitrary fault, short of a partition, would maintain connectivity. With a partition, bad things can happen. Do we solve that? > this requires no flooding of ND, or any other changes to on-link > protocols for loop detection. no changes in hosts either. only > downside is that it requires a host to have sent a packet of some form > for the SAVI binding to be initiated. it might also be possible to > support host mobility with the home with this mechanism. The other down side is you essentially have host routes. I'm definitely not in favor of making homenets run more like bridged networks which is what MLSR does (afaik). ND Proxy (rfc4389) is also making a network look more like a bridged networks (no traceroute support, does not always use shortest path, less than robust zero configuration loop suppression, etc. IMHO ND Proxy should also not be considered. > cheers, > Ole cheers, Curtis From curtis@occnc.com Mon Oct 10 14:16:52 2011 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 7413A21F8C69 for ; Mon, 10 Oct 2011 14:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBRU166elT7I for ; Mon, 10 Oct 2011 14:16:51 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83521F8C51 for ; Mon, 10 Oct 2011 14:16:51 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9ALGj83055597; Mon, 10 Oct 2011 14:16:45 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9ALGj83055597 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318281406; bh=RmMOryReV8SzB0k9m6ZNMdL1Nw/qH9wchXP6aQ2LGjM=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=c6YMsLPb+a2MyOL1XxHU2G1/tBwbbINst1t/zsrLBgt9oMe6s2RB6/wcvJ5VTjiNz ZhiZTrCKT7XgX0giajoTB5p0kuNGOOEEmeQwnl+Zdg2Ssi9iQd0Z1lu/NUjByHXnIM Gds6UUlGZwZzD1TgY5XaPJgBGRv2I9WW3Qf4Jjvs= Message-Id: <201110102116.p9ALGj83055597@gateway.ipv6.occnc.com> To: Fred Baker From: Curtis Villamizar In-reply-to: Your message of "Sun, 09 Oct 2011 20:41:36 EDT." <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> Date: Mon, 10 Oct 2011 14:16:45 -0700 Cc: Acee Lindem , "homenet@ietf.org" , Jari Arkko , Erik Nordmark Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:16:52 -0000 In message <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> Fred Baker writes: > On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote: > > > Since OSPFv3 also uses a 4 byte router ID, our implementation will > > use the same algorithm for picking a router ID as OSPFv2. > > which is to say "any old thing it wants, quite often an IPv4 address"? A practical solution (of days past) using OSPF was to configure an address that was not a link address, and then configure it as an alias to the loopback and also advertise it as a /32 stub, and then tweak applications to bind to that address. This loopback address was reachable even if an Ethernet subnet was partitioned (common). Providers have all done this on their IPv4-only routers, allocating the router-id from one or more small prefix which within the network was all host routes. That was fine for small number of routers (hundreds or thousands) and lots of global prefixes (hundreds of thousand) [note: "or" in the first case; "of" in the second case]. In the absense of this configuration or in an IPv6 network, the assumption that the router-id is a reachable address is not a good one. It is also discouraged by the standards. An IPv6 /64 has 2 sets of 4 bytes in every address even after tossing out the top 64 bits. So picking an address won't work. What is really needed is a means to recover from a router-id collision. One router can detect another using the same router-id easily enough. An extension is needed to indicate a collision (there is a denial of service potential with this). The behaviour could be for each router using that router-id (and supporting the extension) to make another pick and readvertise. It means taking down adjacencies and bringing them back up, but perhaps a graceful restart extension could smooth this. This is putting lots of code in the little homenet router, particularly if graceful restart is used. Random number selection for router-id and this sort of recovery would solve the zero config OSPF issue related to router-id selection. Not yet solved in existing zospf draft (afaik) but solvable. Curtis From curtis@occnc.com Mon Oct 10 14:18:24 2011 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 5FFA821F8CC4 for ; Mon, 10 Oct 2011 14:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP0SKvNhOjH8 for ; Mon, 10 Oct 2011 14:18:24 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D92F421F8C8F for ; Mon, 10 Oct 2011 14:18:23 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9ALIJl9055617; Mon, 10 Oct 2011 14:18:19 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9ALIJl9055617 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318281499; bh=3TIUnExUXC6oopw48rakkQadz/ApldOgBlYgqYpkrGc=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=X0bXUNb+jLo6lqM+g6/Ii94WnzzVZj8gIDO+QAVoT0GXxY1GYYXhWTnQ82oiXVayQ YOAxoZQTPEgy56f4cNYihlq/TzR6Mz263eAtq/V0AIxH0n4fVOVN9ZR9xnzmGZqHuJ v+rrIQYRstpnd7Fm3/qmIbG7ma+CFphiHnF9aeTo= Message-Id: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> To: Acee Lindem From: Curtis Villamizar In-reply-to: Your message of "Sun, 09 Oct 2011 20:53:15 EDT." Date: Mon, 10 Oct 2011 14:18:18 -0700 Cc: Erik Nordmark , "homenet@ietf.org" , Jari Arkko , Fred Baker Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:18:24 -0000 In message Acee Lindem writes: On Oct 9, 2011, at 8:41 PM, Fred Baker wrote: > > > > On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote: > > > >> Since OSPFv3 also uses a 4 byte router ID, our implementation will > >> use the same algorithm for picking a router ID as OSPFv2. > > > > which is to say "any old thing it wants, quite often an IPv4 address"? > > > Correct, it uses the best or only configured IPv4 address in the > context (aka, virtual router). Of course, we'd want to use something > else for true auto-configuration. > > Thanks, > Acee And on an IPv6 only homenet with no configured addresses it does what? Curtis From curtis@occnc.com Mon Oct 10 14:21:03 2011 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 14C7821F8CE7 for ; Mon, 10 Oct 2011 14:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNHKDPWUAMRC for ; Mon, 10 Oct 2011 14:21:02 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 433B221F8CEE for ; Mon, 10 Oct 2011 14:21:01 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9ALKx7S055655; Mon, 10 Oct 2011 14:20:59 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9ALKx7S055655 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318281659; bh=WbhJqgB417a+HgBGsBaFQJ9z7RKWzJzkd1aT3sQsvZE=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=nFI0lu4km8HZkA9gXcpYWrJDG9m7MmDlvXnChioJcQWelsUaiywh4Ex2tKsbkKGL4 zmdfBpVuAbg+LzX+dfqUJN7DO7ymxK5W2HRrESHjJcC0HH4k0giDhyFhz+ZPSfiyCb vLGJ71052c1ecH66ZMqst/SvwGGSiARz0eAtPTWY= Message-Id: <201110102120.p9ALKx7S055655@gateway.ipv6.occnc.com> To: Mark Townsley From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 00:18:27 EDT." <17D930D0-572C-482E-8BE7-E782E493069C@townsley.net> Date: Mon, 10 Oct 2011 14:20:59 -0700 Cc: Ole Troan , Erik Nordmark , homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:21:03 -0000 In message <17D930D0-572C-482E-8BE7-E782E493069C@townsley.net> Mark Townsley writes: > > it would seem that we only have 3 choices once we run out of /64s to > give out on links that for whatever reason we cannot bridge on. > > 1. No IPv6 > 2. NAT IPv6 > 3. MLSRv2 (if what you propose works, I don't yet see why it wouldn't) > > I think this is a case of what is the least bad option. We shouldn't > ignore the problem though. > > - Mark There is no reason to give out /64 or shorter to every link. A prefix longer than /64 is not *globally* routeable. It is locally routeable. > On Oct 9, 2011, at 6:38 PM, Ole Troan wrote: > > > Erik, et al, > > > > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't really been described anywhere) as a method for numbering a routed home. please let me be clear that I'm not convinced this is a good idea. i.e. why not just get < /64? > > I do think we could get something working though. > > > > routers can be in an arbitrary topology. all routers running a routing protocol. > > the site prefix (/64) is either advertised in the IGP with a new LSA or proxying of RA messages is done (split horizon). > > a router advertises the same /64 prefix (in a PIO) on all of its interfaces. L bit is 0. > > > > the link model here is that all hosts are off link from each other. link-local scope is restricted to only the physical link. multicast link-local scope as well. > > > > a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. the first hop router uses it's routing topology database > > to check for conflicts. similar mechanisms described in SAVI are used to glean address information from the host. the SAVI binding > > database is then used to inject host routes into the IGP. > > > > this requires no flooding of ND, or any other changes to on-link protocols for loop detection. no changes in hosts either. > > only downside is that it requires a host to have sent a packet of some form for the SAVI binding to be initiated. > > it might also be possible to support host mobility with the home with this mechanism. > > > > cheers, > > Ole From curtis@occnc.com Mon Oct 10 14:24:10 2011 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 1C4B921F8D01 for ; Mon, 10 Oct 2011 14:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iqZpF+wUOrp for ; Mon, 10 Oct 2011 14:24:09 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 3015B21F8CCD for ; Mon, 10 Oct 2011 14:24:07 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9ALO4D7055811; Mon, 10 Oct 2011 14:24:04 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9ALO4D7055811 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318281845; bh=aQ54Q89AwvcMK8vliuRrMCJYQmDIcLpwPrLgrst9TXg=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=mnIBmbGGF/NfEyNpL4pw+wMLPgqLuM8pse82dzJQkcisNTiosLxHVH3zNjFE6bdOo KkNYqitXU0UuKBjkwfexZFY34N02IBzgyogbJJFkWjrTyqL/NME/YRyWTZxe91dg5O 7O39jwkyc+QqdQbBRAHtZDlBfZ7sFKB3/jbGuEr4= Message-Id: <201110102124.p9ALO4D7055811@gateway.ipv6.occnc.com> To: Mikael Abrahamsson From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 08:16:17 +0200." Date: Mon, 10 Oct 2011 14:24:04 -0700 Cc: homenet@ietf.org, Shishio Tsuchiya Subject: Re: [homenet] Does ND Proxy useful for homenet? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:24:10 -0000 In message Mikael Abrahamsson writes: > On Sun, 9 Oct 2011, Shishio Tsuchiya wrote: > > > 2^64 host address space would be too enough for homenet. > > I would just like to comment on this even though you retracted your > question. > > As an ISP, I do not want to participate in a home with hundreds or > thousands of active IPv6 addresses that I need to keep state for. Most > likely, when we have central equipment participating in a home network, > we'll implement a limit on number of neighbours it'll allow on the subnet. > Doing ND/NS a lot takes resources. > > If customer wants to use more IPv6 addresses, we'll require them to get a > home router and PD address space to it to distribute the ND/NS load. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se +1 violent agreement, etc IMO the ground rules are: The ISP provides one prefix. The homenet subdivides it only if there are multiple subnets. The ISP doesn't see the longer prefixes that exist only within the homenet. Curtis From curtis@occnc.com Mon Oct 10 14:35:28 2011 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 2912021F8C86 for ; Mon, 10 Oct 2011 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPz8qTfXlvyF for ; Mon, 10 Oct 2011 14:35:27 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4E221F8C85 for ; Mon, 10 Oct 2011 14:35:27 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9ALZPCd056031; Mon, 10 Oct 2011 14:35:25 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9ALZPCd056031 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318282525; bh=Zsh/H7JcOCfthQtIrf1s5FGwYLpOyC5A90GHtQtBG1Y=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=JMg1bzBa4W1UCW9UT9d9y696QLj8j3LvaDKKtWsdk9hWf8f5239DmG2YxGO/W/6aI 91Ehaf8+bx+orEG/eCtRsEPuuCe8Sv2bSv6hMxzJg8IUxFkQ6abLpWjbkQF8vMv/P0 B8YQ7fB5cHT8+FdLLjYI6TyePAGvsmKX9jBLrxaE= Message-Id: <201110102135.p9ALZPCd056031@gateway.ipv6.occnc.com> To: "Pascal Thubert (pthubert)" From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 09:33:55 +0200." Date: Mon, 10 Oct 2011 14:35:25 -0700 Cc: Ole Troan , homenet@ietf.org, "Erik Nordmark \(nordmark\)" Subject: Re: [homenet] Multilink subnet routing (MLSRv2) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:35:28 -0000 In message "Pascal Thubert (pthubert)" writes: > Hi Ole: > > I think you're getting closer and closer to the models that were > discussed in RPL, 6LoWPAN and Autoconf. > > There are several components to the solution that was proposed there: > - capability to register an IPv6 address using ND extensions > - capability to extend a subnet over multiple hops (RPL DIO prefix > option) > - capability to redistribute ND registration into the MLSN routing > protocol > - capability to use the ND registrar (and/or) the routing protocol for > DAD > - capability for the registrar to proxy ND over a backbone in order to > interact with classical ND clients > > See: > http://tools.ietf.org/html/rfc5889 > http://tools.ietf.org/html/draft-ietf-6lowpan-nd > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > > cheers, > > Pascal IMHO - Any attempts to use ND Proxy masquerading as a light weight routing protocol are doomed. Failing to deal with the problems of loops in the topology and multiple attachments to the provider will just push the problem from protocol definition to customer support (when the customer's network doesn't work). It is better to get it 100% right in protocol definition, than 90% right with the other 10% going to support calls. Curtis > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On > Behalf Of Ole Troan > Sent: lundi 10 octobre 2011 00:38 > To: Erik Nordmark (nordmark) > Cc: homenet@ietf.org > Subject: [homenet] Multilink subnet routing (MLSRv2) > > Erik, et al, > > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it > hasn't really been described anywhere) as a method for numbering a > routed home. please let me be clear that I'm not convinced this is a > good idea. i.e. why not just get < /64? > I do think we could get something working though. > > routers can be in an arbitrary topology. all routers running a routing > protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA or > proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its > interfaces. L bit is 0. > > the link model here is that all hosts are off link from each other. > link-local scope is restricted to only the physical link. multicast > link-local scope as well. > > a host uses SLAAC (or DHCP) to create an address, then does DAD as > normal. the first hop router uses it's routing topology database to > check for conflicts. similar mechanisms described in SAVI are used to > glean address information from the host. the SAVI binding database is > then used to inject host routes into the IGP. > > this requires no flooding of ND, or any other changes to on-link > protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some > form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with > this mechanism. > > cheers, > Ole From acee.lindem@ericsson.com Mon Oct 10 14:49:45 2011 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 A98DD21F8CFE for ; Mon, 10 Oct 2011 14:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2W53j+uBOtl for ; Mon, 10 Oct 2011 14:49:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2524A21F8CF8 for ; Mon, 10 Oct 2011 14:49:45 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p9ALnfL3009129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2011 16:49:42 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 10 Oct 2011 17:49:40 -0400 From: Acee Lindem To: "curtis@occnc.com" Date: Mon, 10 Oct 2011 17:49:38 -0400 Thread-Topic: [homenet] Thoughts about routing Thread-Index: AcyHloKYJ7dlxZvpSm2AuUgN+Nj0BQ== Message-ID: <0EDB3E2D-40F1-4BC8-9057-FE1D70F17FAD@ericsson.com> References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> In-Reply-To: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-19-673761884"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Erik Nordmark , Jari Arkko , "homenet@ietf.org" , Fred Baker Subject: Re: [homenet] Thoughts about routing 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, 10 Oct 2011 21:49:45 -0000 --Apple-Mail-19-673761884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 10, 2011, at 5:18 PM, Curtis Villamizar wrote: >=20 > In message > Acee Lindem writes: >=20 >=20 > On Oct 9, 2011, at 8:41 PM, Fred Baker wrote: >=20 >>>=20 >>> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote: >>>=20 >>>> Since OSPFv3 also uses a 4 byte router ID, our implementation will >>>> use the same algorithm for picking a router ID as OSPFv2. >>>=20 >>> which is to say "any old thing it wants, quite often an IPv4 = address"? >>=20 >>=20 >> Correct, it uses the best or only configured IPv4 address in the >> context (aka, virtual router). Of course, we'd want to use something >> else for true auto-configuration. >>=20 >> Thanks, >> Acee=20 >=20 >=20 > And on an IPv6 only homenet with no configured addresses it does what? Our Ericsson SmartEdge routers were never meant to be deployed in the = home or to support complete auto-configuration - I was just responding = to Fred's query as to what OSPFv3 implementations do today.=20 If there is no IPv4 address available and no OSPFv3 Router-ID is = explicitly configured, we'll log an error and shut the OSPFv3 instance = down until such time as an IPv4 address or explicit router-id are = configured. A new draft is required for OSPFv3 auto-configuration.=20 Thanks, Acee >=20 > Curtis > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-19-673761884 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAxMDIxNDkzOFowIwYJKoZI hvcNAQkEMRYEFCTzwFPiUbqdBuNbHEDUlWTXzyZqMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgHb0YdXd6IyNH/FYuNz/JBdMVHI8sLVYVtQuG+yNZnPgPWuc2NAgck2f/jCK1Lvx g7IriRV6l+QY8ZIZckYWZ6QRfPZPfeI21AXcQkF2E54lKGygbR6ALh4/oQYC3XCQESz30w4EhGJN OPA2WQ/4rm6JDkcqbBVsL9cbqifS7VRJAAAAAAAA --Apple-Mail-19-673761884-- From curtis@occnc.com Mon Oct 10 15:02:43 2011 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 B1F5821F8C73 for ; Mon, 10 Oct 2011 15:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQdiJLSxPL42 for ; Mon, 10 Oct 2011 15:02:39 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBEC21F8C72 for ; Mon, 10 Oct 2011 15:02:39 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9AM2XXo056616; Mon, 10 Oct 2011 15:02:34 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9AM2XXo056616 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318284154; bh=+XDiGgvwRIasYIaQifKpduuDyQYuY6onjVr1xv2S2Ac=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=EoKVwfA2f2XKMNkNp/a28Q0ycLKUgK5EbZDPPafihHXoRV5AEFH1TWTWNdYtWLdCA dvbdxttfUOmYXnBqFqbJb9Xw5iGL0SQA7TCg3jTI80evh9XTEPttzmjcYFYAkaVloS c9yEs3LGkyZiMAJSR1L2etSNDmFY59TCuA5m9lAc= Message-Id: <201110102202.p9AM2XXo056616@gateway.ipv6.occnc.com> To: Ray Hunter From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 09:38:36 +0200." <4E92A0FC.5060406@globis.net> Date: Mon, 10 Oct 2011 15:02:33 -0700 Cc: homenet@ietf.org, Curtis Villamizar Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 22:02:43 -0000 In message <4E92A0FC.5060406@globis.net> Ray Hunter writes: > > The example of electric meters is a trivial one but the same can > > apply to other things. > > I can assure you that the requirements and IT issues surrounding smart > electric meters are far from "trivial." > > You talk about "the electric company" being singular and monolithic. In > reality there are many separate parties with interests in obtaining > access to that data and controlling that meter (the home owner, multiple > production/ delivery companies, meter data management company, meter > management company, high voltage distribution company, medium voltage > distribution company, regulators, micro generation .... ) That can add > up to 15 different roles, and many different message types. > > See e.g. /EBSII White Paper: "Smart European Energy Architecture" > > or > > http://www.google.nl/url?sa=t&source=web&cd=4&ved=0CC0QFjAD&url=http%3A%2F%2Fwww.esmig.eu%2Fnewsstor%2Fnews-file-store%2FEU-MeteringV4.pdf%2Fat_download%2Ffile&rct=j&q=EBSII%20White%20Paper%3A%20%E2%80%9CSmart%20European%20Energy%20Architecture%E2%80%9D&ei=JZ-STvnTLMmg-wbm6qHTCg&usg=AFQjCNGpFWhNfa1HeBA24wlVPwLEFB0T6A&sig2=CT0FCDXVmniyxMoSup9SPw&cad=rja > > > regards, > RayH OK - modify that statement to: The example *as stated* of electric meters is a trivial one but the same can apply to other things. *However never underestimate an industry's ability to make a simple problem highly complex*. :-) Either way the mess the electrical industry is making for itself is out of scope here. Curtis From ot@cisco.com Mon Oct 10 15:46:20 2011 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 A769D21F8C00 for ; Mon, 10 Oct 2011 15:46:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLqtVj411FKy for ; Mon, 10 Oct 2011 15:46:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 652A921F8BFE for ; Mon, 10 Oct 2011 15:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=2692; q=dns/txt; s=iport; t=1318286779; x=1319496379; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kUqBnGhwrjTvbmmO78fRHaEVuhZm0RZA22DATs7I4n8=; b=FwT4Sydv28Qq+IBZyN9Xi8ZKWNbUczABBeswX9Xc7mSICw1l1ZWSYKgv hQPI098+/S4+6xrNr8L6by4vIirEgRLAYuY44aGRlBpUyozyVuZ19G5xf zFpZ5NB2jNGpMkSRoqCyuqORofRH4uU/exCrL4/ZNKJ6pJzHI/KDrW+in o=; X-IronPort-AV: E=Sophos;i="4.68,519,1312156800"; d="scan'208";a="57500683" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 10 Oct 2011 22:46:17 +0000 Received: from ams3-vpn-dhcp6322.cisco.com (ams3-vpn-dhcp6322.cisco.com [10.61.88.177]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9AMkFMI012353; Mon, 10 Oct 2011 22:46:16 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E933CCE.6020606@cisco.com> Date: Tue, 11 Oct 2011 00:46:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E933CCE.6020606@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 10 Oct 2011 22:46:20 -0000 Erik, >> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it = hasn't really been described anywhere) as a method for numbering a = routed home. please let me be clear that I'm not convinced this is a = good idea. i.e. why not just get< /64? >> I do think we could get something working though. >>=20 >> routers can be in an arbitrary topology. all routers running a = routing protocol. >> the site prefix (/64) is either advertised in the IGP with a new LSA = or proxying of RA messages is done (split horizon). >> a router advertises the same /64 prefix (in a PIO) on all of its = interfaces. L bit is 0. >>=20 >> the link model here is that all hosts are off link from each other. = link-local scope is restricted to only the physical link. multicast = link-local scope as well. >=20 > And I assume the routers would pass around /128 routes for the hosts = in the home, and would automatically inject such a route when the = SAVI-style table learns about a new address. > Are those assumptions correct? yes. >> a host uses SLAAC (or DHCP) to create an address, then does DAD as = normal. the first hop router uses it's routing topology database >> to check for conflicts. similar mechanisms described in SAVI are used = to glean address information from the host. the SAVI binding >> database is then used to inject host routes into the IGP. >=20 > What happens when the router crashes - does it loose its SAVI-style = table? Does it keep it in stable storage? it could. > If it looses it, then nobody would know on what link the hosts are, = since the hosts aren't required to periodically send any announcement to = the routers. indeed. directly connected hosts would get a L2 event. in the more creative department you could run with low timers, and you = could enforce a direct mapping between MAC address, link-local address = and global address. thereby being able to recreate global address binding state just from a = link-local addresses. > What happens when a packet arrives for an IP address that is in the = /64 prefix for the home, but there is no /128 route for it? Flood = everywhere? Drop? drop I'd imagine. > We looked that this when we worked on 6lowpan-nd, and concluded that = by doing explicit registrations from hosts to routers (the Address = Registration Option) with a lifetime we can make such networks work well = without requiring stable storage. >=20 > But that implies a host change. yes, registration makes this safer. I just intended to point out that this could be one tool in the toolbox. = not that we should necessarily build homenets this way. cheers, Ole From jhw@apple.com Mon Oct 10 16:41:04 2011 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 DA91B21F8B65 for ; Mon, 10 Oct 2011 16:41:04 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeslIJRj2Lx9 for ; Mon, 10 Oct 2011 16:41:04 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 786F221F8B3C for ; Mon, 10 Oct 2011 16:41:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LSV000X7J31UM32@mail-out.apple.com> for homenet@ietf.org; Mon, 10 Oct 2011 16:41:03 -0700 (PDT) X-AuditID: 11807137-b7c6bae00000222c-1d-4e9384732f29 Received: from [17.153.16.118] (Unknown_Domain [17.153.16.118]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id B1.4B.08748.374839E4; Mon, 10 Oct 2011 16:49:07 -0700 (PDT) From: james woodyatt In-reply-to: <30133.1318261870@marajade.sandelman.ca> Date: Mon, 10 Oct 2011 16:40:20 -0700 Message-id: <34789394-DDBF-4CA6-85EF-9449BADBB77E@apple.com> References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <625F39517869164ABE7DB2FFB4CA66A7314CAAE3@IT-EXMB-01.silverspringnet.com> <85C59458-E0F8-48BA-873B-26553C3D0EFE@apple.com> <30133.1318261870@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiOFOgTLe4ZbKfwY5pshbvFx1isZjXcJnJ gcljyZKfTB4tc/YwBzBFcdmkpOZklqUW6dslcGX8fbiDqeACT8Wy/tVMDYwNXF2MnBwSAiYS j250sUDYYhIX7q1n62Lk4hASmMokceLTD8YuRg4OYQFbifbXhiAmr4CxxOt/TCDlzAJaEjf+ vQSz2QRUJL5dvgtmcwqYSvz9sZURxGYRUJV4Pfk7M0S9iMTWj6eherUlli18DRbnFbCRuDt/ PQvE2leMEjMWHGAHSYgIaEocmdnOBHGbvMTils+MExj5ZyGcMQvJGbOQjF3AyLyKUbAoNSex 0tBML7GgICdVLzk/dxMjKOQaCs13MG7/K3eIUYCDUYmH96HdJD8h1sSy4srcQ4wSHMxKIrxZ IZP9hHhTEiurUovy44tKc1KLDzFKc7AoifOGOwKlBNITS1KzU1MLUotgskwcnFINjOc33QzZ dDX6cOb2V2ct1x2uZYid92B5qohzjFz+yo/eNp/Ltmff/y1XlbWhuW9G7NJ3ny54PE/J6PMN eZmv4pg7M8b/69nd20MYCkQmSFRuYRJ8wvjRUO9op3d6iYP58rs33mUfv60hrvVlWWQ6Z+EE Xr41k2MKdI4tn3HzSlzAqvm3J/+coaPEUpyRaKjFXFScCADCRjqkNQIAAA== Cc: homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 10 Oct 2011 23:41:05 -0000 On Oct 10, 2011, at 08:51 , Michael Richardson wrote: > > It does break the *I*nternet model: the one where the ISPs control > everything like the telcos did before, and I need to beg to be allowed > to receive SYN packets. Why do I care if it breaks the business plans > of some ISPs? I hate to break the news to you, but it isn't the ISPs that are making you beg to receive a SYN packet from anywhere on the Internet. It's the home gateway vendors, who are following the advice of RFC 4864 to implement stateful default-deny simple security mechanisms, and who follow the advice of myriad other 'experts' who insist that these functions be enabled by default. Shorter james: it's your residential subscribers who insisting that your devices need to beg for permission to receive inbound SYN packets from arbitrary remote addresses. The IETF is in the process of specifying a protocol to let you beg for incoming packets, c.f. I-D.ietf-pcp-base. I wish you all the luck in the world convincing the average home networking gear buyer that they shouldn't need any of this craziness. Sincerely. I tried that. Been there, done that, got the T-shirt, ended up buffing the car with it, donated the car to charity when the car wore out... in other words, I am done struggling against what you call "the Internet model" because from my perspective that's like to trying to bail out San Francisco bay with a tea cup. Have fun storming the castle though... -- james woodyatt member of technical staff, core os networking From curtis@occnc.com Mon Oct 10 16:47:45 2011 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 6F77A21F8BFB for ; Mon, 10 Oct 2011 16:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwU4gLfBQivh for ; Mon, 10 Oct 2011 16:47:44 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE5921F8BE7 for ; Mon, 10 Oct 2011 16:47:44 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9ANlh39058653; Mon, 10 Oct 2011 16:47:43 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9ANlh39058653 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318290463; bh=ViVwKPqub8fd7+xfRaB8mKBnISmWAsmZ2Oj90f14JFI=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=BreCF5X+BoeYjxQKqWBV1iva40aS5ffUmExW3QDiNNZfakbpfQeyqMLSGeCA5AtIF m1tgctDX5Mlvmp/WGgrJEzHZjOOwp8mAXpgB6PwXdMpEVElYCP6ZY6aP4tTh+QMkFr trjkcnpvLqhg3PAeui4Ylaoeld8HWD/92ORlcADc= Message-Id: <201110102347.p9ANlh39058653@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 11:51:10 EDT." <30133.1318261870@marajade.sandelman.ca> Date: Mon, 10 Oct 2011 16:47:43 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 23:47:45 -0000 In message <30133.1318261870@marajade.sandelman.ca> Michael Richardson writes: > > >>>>> "james" == james woodyatt writes: > >> There will be wide area network providers who interwork with the > >> home network but do not provide global connectivity. Two > >> mentioned so far are utility networks and 3g providers. One of > >> the outputs of the wg should be to define how they should be > >> configured to perform their role without messing up Internet > >> communication. > > james> Those utility networks have a fundamental problem that I > james> contend is beyond the scope and charter of HOMENET. > > james> Utility networks of that sort do not provide transit to the > james> Internet default-free zone. They must therefore obtain their > james> routes to residential networks bilaterally. This implies > james> that these utility networks could be-- and would do well to > james> be-- numbered with ULA prefixes, and that they should use of > > If you said, "ULA-Central" I would agree. > I do not want to debug random packets on someone's network without > whois. > > >> A wg Chair from the Internet area did accuse me of "breaking the > >> Internet model" because the utility networks my company builds do > >> not provide global connectivity to users with our 100kb to the > >> node. > > james> That's really not the problem, if you want my humble opinion. > james> The problem, I would say, is that these utility networks > james> insist on extending their private routing domains into our > james> home networks where they don't belong and they aren't > james> welcome. > > It does break the *I*nternet model: the one where the ISPs control > everything like the telcos did before, and I need to beg to be allowed > to receive SYN packets. Why do I care if it breaks the business plans > of some ISPs? > > But the IETF needs to spend more time worrying about the *Internet > Protocols* rather than just the *I*nternet. I completely agree with the WG chair on this one. If the utility network wants to share a common homenet infrastructure but remain disjoint from the Internet, then it must do so in a way that doesn't break the other uses of the homenet. One way may be to identify (somehow) those hosts that are using the homenet for the purpose of connecting to the utility network, such as the home heating system, the water header, etc and only offer addressing and routing to that subset of equipment. Another even simpler solution is to have the utility gateway stop serving as an ND or DHCP server completely if it detects connectivity to the Internet and just use that connectivity. Surely the utility can afford an Internet connection. Use the Internet if it is there, otherwise use the utility network. OTOH - If the reason for avoiding the Internet is because an industry came up with a meter protocol with no security assuming it was only going to be used on a walled off private network, then that is not a homenet WG issue either. > >> [...] 6. The lookup of foo.ispA.net works over either DNS and > >> returns the same IP address, but the application-layer content is > >> completely different (e.g., a "subscriber" view when connecting > >> over the ISP-A connection). > > james> This is the basic problem faced by any multi-homed host, > james> e.g. a personal computer with a 3G interface and a Wi-fi > james> interface that are simultaneously active, along with a > james> split-tunnel VPN interface [or three] running on one or both > james> interfaces. > > james> It is a problem for host operating systems and applications > james> developers. I suggest HOMENET should steer well clear of it, > james> and just about every related problem that is too easily > james> conflated with it. > > What is the set of problems left for homenet then? Certainly not solving the broken utility network issues. Curtis From curtis@occnc.com Mon Oct 10 17:07:44 2011 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 F215B21F8C39 for ; Mon, 10 Oct 2011 17:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQS47O9w0lEH for ; Mon, 10 Oct 2011 17:07:43 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id F17F621F8C3E for ; Mon, 10 Oct 2011 17:07:42 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9B07ejV059082; Mon, 10 Oct 2011 17:07:40 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9B07ejV059082 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318291660; bh=GY/OXbPJshAvdaqKp0FnQoZIE62xcx4tn/7bB08U3pg=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=TK5q1Tvgsqo/M+olCo6ikIIcdtxplBChWi2QMq+dO5irVuS1W7SLC2DnfwzJZMKAF WV3Akmrc2lN3YpDSmcALilEF/yjY9FNhQtGWQktcMwo8Pv61TY6CtsI7cHMZ0+Wmyu 6mOFBIFw0cGqsn96QK/UxJDs+Hb5cRCTKKhIiwXY= Message-Id: <201110110007.p9B07ejV059082@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 13:06:23 EDT." <8438.1318266383@marajade.sandelman.ca> Date: Mon, 10 Oct 2011 17:07:40 -0700 Cc: homenet@ietf.org, Erik Nordmark Subject: Re: [homenet] walled garden DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 00:07:44 -0000 In message <8438.1318266383@marajade.sandelman.ca> Michael Richardson writes: > > >>>>> "Erik" =3D=3D Erik Nordmark writes: > Erik> 4. Looking up foo.ispA.net works when asking the DNS server at > Erik> ISP-A, but fails (NXDOMAIN) when asking ISP-B. > > Erik> 5. The lookup of foo.ispA.net works over either DNS and > Erik> returns the same IP address, but fails (due to firewalls) for > Erik> packets that are sent out via ISP-B. > > Erik> 6. The lookup of foo.ispA.net works over either DNS and > Erik> returns the same IP address, but the application-layer content > Erik> is completely different (e.g., a "subscriber" view when > Erik> connecting over the ISP-A connection). > > We have heard requests for a facility to provide hosts information of > the sort: > when looking for an FQDN that has suffix "X", please contact server "Y" > > And my question is: isn't that what an NS record is? > > It seems to me that we can solve all of the walled garden DNS in IPv6 > land, with an arrangement like: > > example.com NS reachable by the world. > garden.example.com NS pointing to AAAA record, where IPv6 > address is only reachable from garden. > television.garden.example.com AAAA returned from > garden.example.com name server (above) > > This solution works perfectly in IPv4 land, but due to lack of IPv4 > global address space, the NS for garden.example.com winds up pointing to > RFC1918 address, and not only does this look bad, but it can in fact > cause failures if there really is a DNS server at that address. > > It seems to me that we just don't need anything else in IPv6, except > easily *available* non-connected PI address space (whether it's ULA-C, > some recognized part of 2000::/3, or an entirely new space). > > NOTE: the existing ingress filtering problem means that one must assume > that walled gardens will have to provide address space to the home > that will be used to talk to them. A challenge to the walled > garden people's thought process is that they might be thinking > that they need 1-IP per customer, when in fact, they need to have > at least a /60 per customer. If this is a walled garden within the home, would it be simple enough to use a 6to4 address space for one globally unique IPv4 address and just not bring up a 6to4 tunnel? Instant walled garden. With private DNS. Alternately bring up the 6to4 tunnel but don't propogate or forward on the garden side. If garden.example.com is the A record for the 6to4 and also has an AAAA record, and it is also the DNS server within the garden, then the DNS records are availabel both inside and outside but connectivity is inside only. Walled gardens always seem like a bad idea. And probably always are a bad idea. If you have control over both the DHCP (4 or 6) server and the DNS server, you can make DNS look like anything you want within the garden. [Except for those hosts who do their own DNS from root or have configured a DNS forwarder from elsewhere. Only the geeks.] The original question seems to be whether the same dns query (for example, garden.example.com) could be made to resolve differently in ISP-A and ISP-B and the answer is "yes" with no changes but with the exception within [] in the prior paragraph. Curtis From curtis@occnc.com Mon Oct 10 17:33:44 2011 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 CAAF421F8C42 for ; Mon, 10 Oct 2011 17:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+Gx8UEtcGuu for ; Mon, 10 Oct 2011 17:33:44 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8E21F8C1E for ; Mon, 10 Oct 2011 17:33:44 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9B0XZwa059653; Mon, 10 Oct 2011 17:33:36 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9B0XZwa059653 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318293217; bh=+TeZ1MKC89fsJhQr641pEPSWfq8LmJUeJmfjuymUH/8=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=VgXNx4PV1Xe8sKeeFaiQByjDBfOC1yvfrQcSqQnJ8z3m+Lc3bohYFNoSd/u6QAQbE Bb8OEYhptTV1r+shSL7XXhJNyG/903J60sHBUIpprkp/enUNZPgsSwMt1Frs4ML1Zf 9Exgf6+sbmDiWqW0PPiUJpLtWju4RXGDuZeuuPDM= Message-Id: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> To: Erik Nordmark From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 11:12:31 PDT." <4E93358F.7050907@cisco.com> Date: Mon, 10 Oct 2011 17:33:35 -0700 Cc: homenet@ietf.org, Jari Arkko , Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 00:33:44 -0000 In message <4E93358F.7050907@cisco.com> Erik Nordmark writes: > On 10/8/11 6:13 AM, Jari Arkko wrote: > > I like this, with the possible exception of using ULAs and your desire > > to deprecate prefixes as soon as connectivity goes down. (Speaking as > > someone whose prefixes got invalidated two months ago but who hasn't > > been home long enough to fix the problem, but my devices still happily > > communicate with each other using the old prefixes :-) I also agree with > > Erik that loop and arbitrary topologies is not really required. But the > > people in the interim at least seemed to say yesterday that we want to > > go there. > > I think there are different scopes being discussed. > > The one I put forth is how to enable existing IPv4 NATting consumer home > routers (which all have a designated uplink port, and support multiple > home routers by nested NATting) have a way to support IPv6 without > requiring any IPv6 NATs. That doesn't seem to be a difficult problem > (which perhaps makes it uninteresting for some of us), but to me it > seems like an important short-term problem to solve. > > The larger scope is around arbitrary topologies, no designated uplink > port, and perhaps also multihoming. Plenty of problems to solve around > autoconfiguring routing protocols, stable prefix assignment to links, > multihoming, etc. Erik, I really don't know how many support calls are just the consumer plugging the computer into the wrong Ethernet port on the NAT box and the uplink on the other port and then not being able to figure out what is wrong. All the cables fit in the connector. It should work! If all the ports are the same, no designated uplink, that is better. If you get an IP address via DHCP on one and none of the others, it may be the uplink and try doing NAT. What may be needed is a IPv4 equivalent to the IPv6 IA_PD and a provider DSL or docsis modem/router that knows how to respond to it. The other routers ask for a IA_PD and the provider modem/router responds with part of 10/8 on each interface (and does NAT). The same loop tolerance can then be built into the IPv4 homenet using 16M addresses provided by NAT as can be provided for the IPv6 subnet using a globally routable /64 (with its 4B^2 addresses). The idea is that the consumer can plug things in in arbitrarily stupid way and it will all still work well enough to not require a support call. It might work better if set up right, but good enough if set up wrong. Perhaps GbE can be preferred over 100baseT over 10baseT and somewhere between 100baseT over 10baseT or after 10baseT fits WiFi. Beyond that metrics for multiple WiFi hops can be channel aware. > Some things are common across the two; security (determining the > boundary of the home), DNS, and service discovery. > > Erik The security boundary of WiFi for non-open WiFi is separate issue. That can't easily be zero config. Perhaps two devices can "bond" (in the "fall in love" analogy sense) over an Ethernet or USB connection as one way around the configuring WPA issue. Curtis From jmh@joelhalpern.com Mon Oct 10 17:57:06 2011 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 3EAB721F8C89 for ; Mon, 10 Oct 2011 17:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLb-Oej1LW+e for ; Mon, 10 Oct 2011 17:57:05 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id D1DDF21F8C88 for ; Mon, 10 Oct 2011 17:57:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BA5E4430033; Mon, 10 Oct 2011 17:57:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-145.clppva.btas.verizon.net [71.161.52.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9229E43001B; Mon, 10 Oct 2011 17:57:03 -0700 (PDT) Message-ID: <4E939458.5070109@joelhalpern.com> Date: Mon, 10 Oct 2011 20:56:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110102124.p9ALO4D7055811@gateway.ipv6.occnc.com> In-Reply-To: <201110102124.p9ALO4D7055811@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Shishio Tsuchiya , Mikael Abrahamsson Subject: Re: [homenet] Does ND Proxy useful for 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, 11 Oct 2011 00:57:06 -0000 Curtis, I would not call what you describe "ground rules." They are a valid and useful operating premise, used by many residential service providers. Other service providers prefrer other architectures and state maintenance, in exchange for other capabilities. While I would not want to insist that all edge home routers must be bridges, I find it unfortunate that folks seem to be insisting that they must be routers. Yours, Joel M. Halpern On 10/10/2011 5:24 PM, Curtis Villamizar wrote: > > In message > Mikael Abrahamsson writes: > >> On Sun, 9 Oct 2011, Shishio Tsuchiya wrote: >> >>> 2^64 host address space would be too enough for homenet. >> >> I would just like to comment on this even though you retracted your >> question. >> >> As an ISP, I do not want to participate in a home with hundreds or >> thousands of active IPv6 addresses that I need to keep state for. Most >> likely, when we have central equipment participating in a home network, >> we'll implement a limit on number of neighbours it'll allow on the subnet. >> Doing ND/NS a lot takes resources. >> >> If customer wants to use more IPv6 addresses, we'll require them to get a >> home router and PD address space to it to distribute the ND/NS load. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se > > > +1 > violent agreement, etc > > IMO the ground rules are: The ISP provides one prefix. The homenet > subdivides it only if there are multiple subnets. The ISP doesn't see > the longer prefixes that exist only within the homenet. > > Curtis > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From curtis@occnc.com Mon Oct 10 18:52:10 2011 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 657FD21F8CC3 for ; Mon, 10 Oct 2011 18:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr6O0yPRI4Su for ; Mon, 10 Oct 2011 18:52:09 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id A218821F8CC4 for ; Mon, 10 Oct 2011 18:52:09 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9B1q7R4061766; Mon, 10 Oct 2011 18:52:08 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9B1q7R4061766 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318297928; bh=0IK8ffENm0wjIHM3j+glCH5/B6rZ8pquESYf/hy2TR0=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=ItLpZaQQI2/W41UTmNPOurjGk5tW4VbXebBgNWlk6F4hdgxHGKdzYOCl2X5Lge1wF NH7+V2/wzc187J8fdlHWZW5gMl/xYzi6fmJVAcR4ac3J2jOryIAZph1XIv/oHa7Ey/ jLg2TbtClRJE+Ft23Ti+4A1RFTZ4u3w1kVzF4K78= Message-Id: <201110110152.p9B1q7R4061766@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 16:17:44 EDT." <2834.1318277864@marajade.sandelman.ca> Date: Mon, 10 Oct 2011 18:52:07 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 01:52:10 -0000 In message <2834.1318277864@marajade.sandelman.ca> Michael Richardson writes: > > >>>>> "Erik" == Erik Nordmark writes: > Erik> There might be some more difficult aspects if we want to allow > Erik> a router or its interfaces to be repurposed, such as splitting > Erik> an existing link into two separate links. In that case it > Erik> might be hard to avoid renumbering. The requirements question > > Moving/repurposing a router without a factory reset seems like the > perhaps the most important source of conflict in the architecture that > we discussed. Particularly if the router is put into a junk drawer for > a few months until it is needed. > > So, we might need to consider if we can expire persisted settings after > some long (from the point of view of the network) time, like 1 week... If it is zero config and its persistent store is DHCP leases, then they will expire. OSPF advertisements would have aged out long ago. It might be worth redoing the router-id selection if it is well past the maxage limit and there are no adjacencies. If the router is just power cycled when moving, it should ask for certain IA-PD and may not get them (or make DHCPv4 requests for a specific address). The same link local requestors (or MAC on DHCPv4) would not be on the new LANs and so the old granted leases that had not expired would also do no harm. What persistent storage, beside configuration by the user would last more than a week? AFAIK just having DHCP leases lasting more than a week would also require some user configuration. Curtis From rkoodli@cisco.com Mon Oct 10 13:38:03 2011 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 E229821F8CD6 for ; Mon, 10 Oct 2011 13:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prnNnfFr1Cyu for ; Mon, 10 Oct 2011 13:38:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1134321F8CC5 for ; Mon, 10 Oct 2011 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=532; q=dns/txt; s=iport; t=1318279083; x=1319488683; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=jVSc+E2u3500Q27nf6utFGEEJWegkYKhv8629Q4An5I=; b=bWd3y7GdBNzYNxeRCS8YsdGLbF2NiRlFbJV9Ju91bOkBMKxpqtlJDigo wxkIoNRfryL1trkVRnPPxyg/HxQQrjn1nErRUd0cHcvv/dJNAlyhFrqiM 9AFk07DYzz5Kpv7O7tPftef4zD4F6gOyheeobCWMjpaPFtBR9q/SpxZ2Q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAC5Xk06tJV2Y/2dsb2JhbABDqCWBBYFTAQEBBBIBJwIBPBIBCIEdAQEEAQ0FIqJuAZ4th0MEh32LenWEPYxA X-IronPort-AV: E=Sophos;i="4.68,519,1312156800"; d="scan'208";a="27348084" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 10 Oct 2011 20:38:02 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9AKc2nI004102; Mon, 10 Oct 2011 20:38:02 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 15:38:01 -0500 Received: from 10.21.126.88 ([10.21.126.88]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Oct 2011 20:38:01 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 10 Oct 2011 13:51:23 -0700 From: Rajeev Koodli To: Mark Townsley , Michael Richardson Message-ID: Thread-Topic: [homenet] Does ND Proxy useful for homenet? Thread-Index: AcyHjl6mro1pDQHDtkiFkEGz7Ri2WQ== In-Reply-To: <93AB0566-AB67-4A2E-9AD5-026A0D186EAF@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Oct 2011 20:38:01.0985 (UTC) FILETIME=[8135A710:01CC878C] X-Mailman-Approved-At: Mon, 10 Oct 2011 18:56:18 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Does ND Proxy useful for 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: Mon, 10 Oct 2011 20:38:04 -0000 Hi, The smartphone will only get a /64 in the current 3G/4G releases (rel-8, rel-9). Prefix delegation is specified in Rel-10. -Rajeev On 10/10/11 1:01 PM, "Mark Townsley" wrote: >> >> Or are you saying a mobile device (a smartphone) will only ever get a >> /64 to share? > > My (limited) understanding of the various 3/4G standards are that a PD for a > phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or > someone else here can elucidate. > > - Mark > From curtis@occnc.com Mon Oct 10 19:07:09 2011 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 7CB2721F8CB9 for ; Mon, 10 Oct 2011 19:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75gYvldsQRE8 for ; Mon, 10 Oct 2011 19:07:09 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id CF2E321F8CA0 for ; Mon, 10 Oct 2011 19:07:08 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9B271LL062165; Mon, 10 Oct 2011 19:07:01 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9B271LL062165 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318298821; bh=dY/rxXKmA72nD0BeBsCHR/BPHAuf7jB6KC9WG5o3/i0=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=EIpZ6tMwqez2KoIE6BEAS8oiHtxpsZs2hGDqCLCTOMpfFfZSSs01NtjwWdp/a7Aya JMnTv/B7puYk16wffp0taophOQ+53G10RvTBdG6Pwy4FhJN6QFCV2zoSAnAM4Rermt sNes1+X1kQq9OBS3L27YoAyNE71qDC9TVntyNKfE= Message-Id: <201110110207.p9B271LL062165@gateway.ipv6.occnc.com> To: Acee Lindem From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 17:49:38 EDT." <0EDB3E2D-40F1-4BC8-9057-FE1D70F17FAD@ericsson.com> Date: Mon, 10 Oct 2011 19:07:01 -0700 Cc: Erik Nordmark , Fred Baker , Jari Arkko , "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 02:07:09 -0000 In message <0EDB3E2D-40F1-4BC8-9057-FE1D70F17FAD@ericsson.com> Acee Lindem writes: > On Oct 10, 2011, at 5:18 PM, Curtis Villamizar wrote: > > >=20 > > In message > > Acee Lindem writes: > >=20 > >=20 > > On Oct 9, 2011, at 8:41 PM, Fred Baker wrote: > >=20 > >>>=20 > >>> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote: > >>>=20 > >>>> Since OSPFv3 also uses a 4 byte router ID, our implementation will > >>>> use the same algorithm for picking a router ID as OSPFv2. > >>>=20 > >>> which is to say "any old thing it wants, quite often an IPv4 = > address"? > >>=20 > >>=20 > >> Correct, it uses the best or only configured IPv4 address in the > >> context (aka, virtual router). Of course, we'd want to use something > >> else for true auto-configuration. > >>=20 > >> Thanks, > >> Acee=20 > >=20 > >=20 > > And on an IPv6 only homenet with no configured addresses it does what? > > Our Ericsson SmartEdge routers were never meant to be deployed in the = > home or to support complete auto-configuration - I was just responding = > to Fred's query as to what OSPFv3 implementations do today.=20 > If there is no IPv4 address available and no OSPFv3 Router-ID is = > explicitly configured, we'll log an error and shut the OSPFv3 instance = > down until such time as an IPv4 address or explicit router-id are = > configured. > A new draft is required for OSPFv3 auto-configuration.=20 > Thanks, > Acee > > >=20 > > Curtis Acee, I'll have to confess that my most recent employer's equipement was also not intended for the home. :-) I'm sure you saw the suggestions I made in another response. The fix for autoconfig may be to pick a random number and create an OSPF extension to advertise the detection of a collision on a given router-id, then respond to the collision. Any device using autoconfig would have to support this extension. If colliding with a router that did not support the extension, that other router would do nothing, but the autoconfig router would pick a new router-id. The point is you can't make a unique 32 bit number out of a 48 bit number or a 64 bit number or an 80 bit number (for a /48). So you might as well accept low probability of collision and define a way to fix the situation. The absolute worst case is a stomped on LSA that an old router doesn't update until maxage expires. That would be bad so maybe we need to figure out what a legacy OSPF router would do on such a collision where it got from a neighbor something it did not send as its own LSA. Hopefully it would readvertise the right stuff and try to withdraw the bad stuff. The autoconfig router would just pick a new router-id. It all sounds fine except maybe the backwards compatibility with no changes. Your the OSPF expert so ... Curtis From curtis@occnc.com Mon Oct 10 19:46:03 2011 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 AC24821F8C6E for ; Mon, 10 Oct 2011 19:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziEO5Pw16JDX for ; Mon, 10 Oct 2011 19:46:03 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D3C2B21F8C6D for ; Mon, 10 Oct 2011 19:46:02 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9B2jttR062934; Mon, 10 Oct 2011 19:45:56 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9B2jttR062934 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318301158; bh=VjousZHPjoIr8hPNVoHQm29zGBjUFLnFTBHdjs8jRso=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=kDehMI0NOWU2Z5USQnAyoR8sKKxLzXVCBLusv83ogN7S4wjI+ElGswTgLt7RwuOYo QOGWmVBzFrlOEA+MrdER4sEXtZHh5zGS55N1/duHmXC6zhOQBwKTc870XlxsaCz7iW 9mbuXJdwkc/qahbDVHXl3LZwZLygwFOmN5SU+T/8= Message-Id: <201110110245.p9B2jttR062934@gateway.ipv6.occnc.com> To: james woodyatt From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Oct 2011 16:40:20 PDT." <34789394-DDBF-4CA6-85EF-9449BADBB77E@apple.com> Date: Mon, 10 Oct 2011 19:45:55 -0700 Cc: homenet@ietf.org, Michael Richardson Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 02:46:03 -0000 In message <34789394-DDBF-4CA6-85EF-9449BADBB77E@apple.com> james woodyatt writes: > On Oct 10, 2011, at 08:51 , Michael Richardson wrote: > > > > It does break the *I*nternet model: the one where the ISPs control > > everything like the telcos did before, and I need to beg to be allowed > > to receive SYN packets. Why do I care if it breaks the business plans > > of some ISPs? > > I hate to break the news to you, but it isn't the ISPs that are making > you beg to receive a SYN packet from anywhere on the Internet. It's > the home gateway vendors, who are following the advice of RFC 4864 to > implement stateful default-deny simple security mechanisms, and who > follow the advice of myriad other 'experts' who insist that these > functions be enabled by default. > > Shorter james: it's your residential subscribers who insisting that > your devices need to beg for permission to receive inbound SYN packets > from arbitrary remote addresses. > > The IETF is in the process of specifying a protocol to let you beg for > incoming packets, c.f. I-D.ietf-pcp-base. I wish you all the luck in > the world convincing the average home networking gear buyer that they > shouldn't need any of this craziness. Sincerely. I tried that. Been > there, done that, got the T-shirt, ended up buffing the car with it, > donated the car to charity when the car wore out... in other words, I > am done struggling against what you call "the Internet model" because > from my perspective that's like to trying to bail out San Francisco > bay with a tea cup. Have fun storming the castle though... All of this is only true for IPv4 but not for IPv6. If you need a SYN from outside, then you need a globally routable address and then practically speaking you need IPv6. The most simple solution is 6to4 but that means replacing the border router if it doesn't support 6to4. The other way is to accept the rfc1918 address you got from the NAT and TCP tunnel through the NAT. For an electrical meter with extremely low throughput needs and very high delay tolerance, this seems easy enough. The meter simply need to know the IP address of its electrical transmission provider. If that IP addres is not configured right at installation, the power never comes on and someone would notice. The electrical transmission provider can then provide an IPv6 address and a gateway to IPv6. The cost is a tiny flow of TCP keepalives but if the ISP complains, tell them to support IPv6. It is a shame that you can't get a SYN from outside into a home network that is behind an IPV4 only NAT44, but use of NAT is not a situation that the IETF encouraged. We can't change that so we can only try to move forward on a better path. btw- ietf-pcp-base is just yet another hack built onto NAT44 to try to extend its life. For the last 15 years the IPv4 sky was falling. Now it finally really is falling as the NAT hacks are coming undone in many ways and the ISPs can't get addresses to build infrastructure. The good news is now we can get something done with IPv6. Curtis From jhw@apple.com Mon Oct 10 20:07:31 2011 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 F1C8721F8CD9 for ; Mon, 10 Oct 2011 20:07:30 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAxPL9HvPvyW for ; Mon, 10 Oct 2011 20:07:30 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 91E8A21F8CD8 for ; Mon, 10 Oct 2011 20:07:30 -0700 (PDT) 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 Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LSV00932SNJUTQ1@mail-out.apple.com> for homenet@ietf.org; Mon, 10 Oct 2011 20:07:01 -0700 (PDT) X-AuditID: 11807130-b7cb3ae000006822-c6-4e93b2006f37 Received: from [17.153.16.118] (Unknown_Domain [17.153.16.118]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 5C.B4.26658.002B39E4; Mon, 10 Oct 2011 20:03:28 -0700 (PDT) From: james woodyatt In-reply-to: <201110110245.p9B2jttR062934@gateway.ipv6.occnc.com> Date: Mon, 10 Oct 2011 20:07:01 -0700 Message-id: References: <201110110245.p9B2jttR062934@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUiOFOgTJdh02Q/g399BhaHD0xnt3i/6BCL A5PHkiU/mTwWf/ELYIrisklJzcksSy3St0vgypjx/xJrQTNrxaSbC1gaGH8zdzFyckgImEgs OfCUEcIWk7hwbz1bFyMXh5DAVCaJV82n2bsYOTiEBWwl2l8bgpi8AsYSr/8xgZQzC2hJ3Pj3 EsxmE1CR+Hb5LpjNKeAosf3CNbCRLAKqEjf3LGOFqBeR2PrxNFSvtsSyha+ZIUbaSMy6oAAS FhJwkPi4YzFYiQhQ+Y9fO6GulJdY3PKZcQIj/yyEI2YhOWIWkqELGJlXMQoWpeYkVhoa6iUW FOSk6iXn525iBAVbQ6HBDsa1P/kPMQpwMCrx8EZ2TvYTYk0sK67MPcQowcGsJMKbFQIU4k1J rKxKLcqPLyrNSS0+xCjNwaIkzjvXDiglkJ5YkpqdmlqQWgSTZeLglGpgNNnzWNnyISeP9IWV M9Wvyq9/lMY9+9SdJav2KZc/+cD+b1Vyq0jAr3Wbwj9fqymbGph8dk3Zh4uG25dHh5Ubb/4t tqG1aWb1x85wsSCJsIVK3DYux/zuBXy6fjtqR+CPyLdzKoQ6j/x7ePipd+yXu+sf5sgHqOc8 K3mmnRn7fte2fQkanw4fXK/EUpyRaKjFXFScCABKqREzMgIAAA== Cc: homenet@ietf.org Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 11 Oct 2011 03:07:31 -0000 On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote: > > All of this is only true for IPv4 but not for IPv6. I wasn't talking about IPv4 at all. My comments are relevant in a world entirely comprising IPv6-only service providers. The IPv6 Internet will be saddled with all of the problems of the IPv4 Internet with respect to devices on homenets having to beg the gateways to allow inbound packets from arbitrary remote destinations. It has nothing to do with NAT, and everything to do with firewalls and stateful filters. -- james woodyatt member of technical staff, core os networking From jari.arkko@piuha.net Mon Oct 10 21:05:21 2011 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 86B7121F8513 for ; Mon, 10 Oct 2011 21:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.879 X-Spam-Level: X-Spam-Status: No, score=-101.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2wCrkbErs-B for ; Mon, 10 Oct 2011 21:05:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id EF69521F84DF for ; Mon, 10 Oct 2011 21:05:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B99F42CEFF; Tue, 11 Oct 2011 07:05:10 +0300 (EEST) 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 U5R6fOmqhBl7; Tue, 11 Oct 2011 07:05:09 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D80A12CE32; Tue, 11 Oct 2011 07:05:09 +0300 (EEST) Message-ID: <4E93C075.30400@piuha.net> Date: Tue, 11 Oct 2011 07:05:09 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: curtis@occnc.com References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> In-Reply-To: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Acee Lindem , "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 11 Oct 2011 04:05:21 -0000 Home routers would also have MAC addresses, but again, if we need a 32-bit quantity then shortened 48/64 bit identifiers may (theoretically) have collisions. That being said, if the home routers have to discover their IPv6 prefix through a protocol and store it in flash, they could probably do so also for a router ID. Unless there was some chicken and egg problem that required the router ID for all this discovery to work... Jari From peter@denic.de Mon Oct 10 23:08:19 2011 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 D478421F8D86 for ; Mon, 10 Oct 2011 23:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imJjfqkMjGPh for ; Mon, 10 Oct 2011 23:08:19 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAD921F8D85 for ; Mon, 10 Oct 2011 23:08:19 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RDVVh-0007PX-MZ; Tue, 11 Oct 2011 08:08:17 +0200 Received: from localhost by x27.adm.denic.de with local id 1RDVVh-0002Uc-Fg; Tue, 11 Oct 2011 08:08:17 +0200 Date: Tue, 11 Oct 2011 08:08:17 +0200 From: Peter Koch To: homenet@ietf.org Message-ID: <20111011060817.GK28724@x27.adm.denic.de> Mail-Followup-To: homenet@ietf.org References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <8438.1318266383@marajade.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8438.1318266383@marajade.sandelman.ca> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [homenet] walled garden DNS 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, 11 Oct 2011 06:08:19 -0000 On Mon, Oct 10, 2011 at 01:06:23PM -0400, Michael Richardson wrote: > example.com NS reachable by the world. > garden.example.com NS pointing to AAAA record, where IPv6 > address is only reachable from garden. > television.garden.example.com AAAA returned from > garden.example.com name server (above) > > This solution works perfectly in IPv4 land, but due to lack of IPv4 it works, but nowhere near perfectly. Whenever a querying system changes its intended name space (resolution context) from $local to the global one, resolution of names in garden.example.com will just time out. Encoding this user experience in the design looks like a suboptimal choice to me. For resolution from the inside, you'd likely be dependent on access to the external delegation, which may not be feasible, either. > It seems to me that we just don't need anything else in IPv6, except > easily *available* non-connected PI address space (whether it's ULA-C, > some recognized part of 2000::/3, or an entirely new space). While ULAs would "reduce" collisions, the general issues would be the same as with RFC1918 space. A single "local" context won't be enough. -Peter From pthubert@cisco.com Tue Oct 11 05:07:16 2011 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 5326121F8D66 for ; Tue, 11 Oct 2011 05:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APUQrosXHsjG for ; Tue, 11 Oct 2011 05:07:15 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id DEA7F21F8B05 for ; Tue, 11 Oct 2011 05:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4283; q=dns/txt; s=iport; t=1318334835; x=1319544435; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7mi3xAlgshhWU7HZL3iA7XqqWhbzSPD5yrV3EpvLma0=; b=XIc+hBinSxEP1tdINk3cVYL0rsr3Z+nltzk7OL4vx3aGDUXoKWtwO2tQ r3YQpxiDyi0MTz8+eWFIpwfOI2I5+t18h6IwCrB+SocasW4nQ6o7w7Muv SM0ASWq03bFTscdImIXPEiks2eodTHd/vhKIRIcIxzcfZpLYatgBjDi76 s=; X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208";a="775763" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 11 Oct 2011 12:07:14 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9BC7E95015430; Tue, 11 Oct 2011 12:07:14 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 14:07:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2011 14:07:12 +0200 Message-ID: In-Reply-To: <201110102135.p9ALZPCd056031@gateway.ipv6.occnc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] Multilink subnet routing (MLSRv2) Thread-Index: AcyHlIji4Md5f+QYT9mst1bfZYA4+AAd3+lA References: Your message of "Mon, 10 Oct 2011 09:33:55 +0200." <201110102135.p9ALZPCd056031@gateway.ipv6.occnc.com> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 11 Oct 2011 12:07:14.0215 (UTC) FILETIME=[5020D370:01CC880E] Cc: Ole Troan , homenet@ietf.org, "Erik Nordmark \(nordmark\)" Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 11 Oct 2011 12:07:16 -0000 Hi Curtis; Makes sense, and you'll find that the backbone router draft does not say otherwise if you take the time to parse it. The approach in the draft is to proxy only at the L2 backbone from which the MLSN roots. You'll note that RPL leaves are not plain hosts but need to actively register to the routing. Some work has started to map ND registration into RPL host advertisements but there are issues, in particular when the hosts moves. The discussion is whether we'd like to proxy again for plain hosts at the MLSN edge routers (eg RPL leaf routers) and my further mail was to indicate that this is really asking for trouble. I think that Erik 's mail leads to similar conclusions. Cheers, Pascal -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: lundi 10 octobre 2011 23:35 To: Pascal Thubert (pthubert) Cc: Ole Troan; homenet@ietf.org; Erik Nordmark (nordmark) Subject: Re: [homenet] Multilink subnet routing (MLSRv2) In message "Pascal Thubert (pthubert)" writes: =20 > Hi Ole: > =20 > I think you're getting closer and closer to the models that were=20 > discussed in RPL, 6LoWPAN and Autoconf. > =20 > There are several components to the solution that was proposed there: > - capability to register an IPv6 address using ND extensions > - capability to extend a subnet over multiple hops (RPL DIO prefix > option) > - capability to redistribute ND registration into the MLSN routing=20 > protocol > - capability to use the ND registrar (and/or) the routing protocol for > DAD > - capability for the registrar to proxy ND over a backbone in order to > interact with classical ND clients > =20 > See: > http://tools.ietf.org/html/rfc5889 > http://tools.ietf.org/html/draft-ietf-6lowpan-nd > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > =20 > cheers, > =20 > Pascal IMHO - Any attempts to use ND Proxy masquerading as a light weight routing protocol are doomed. Failing to deal with the problems of loops in the topology and multiple attachments to the provider will just push the problem from protocol definition to customer support (when the customer's network doesn't work). It is better to get it 100% right in protocol definition, than 90% right with the other 10% going to support calls. Curtis > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On=20 > Behalf Of Ole Troan > Sent: lundi 10 octobre 2011 00:38 > To: Erik Nordmark (nordmark) > Cc: homenet@ietf.org > Subject: [homenet] Multilink subnet routing (MLSRv2) > =20 > Erik, et al, > =20 > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it=20 > hasn't really been described anywhere) as a method for numbering a=20 > routed home. please let me be clear that I'm not convinced this is a=20 > good idea. i.e. why not just get < /64? > I do think we could get something working though. > =20 > routers can be in an arbitrary topology. all routers running a routing > protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA=20 > or proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its=20 > interfaces. L bit is 0. > =20 > the link model here is that all hosts are off link from each other. > link-local scope is restricted to only the physical link. multicast=20 > link-local scope as well. > =20 > a host uses SLAAC (or DHCP) to create an address, then does DAD as=20 > normal. the first hop router uses it's routing topology database to=20 > check for conflicts. similar mechanisms described in SAVI are used to=20 > glean address information from the host. the SAVI binding database is=20 > then used to inject host routes into the IGP. > =20 > this requires no flooding of ND, or any other changes to on-link=20 > protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some > form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with=20 > this mechanism. > =20 > cheers, > Ole From fred@cisco.com Tue Oct 11 05:26:34 2011 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 6812021F8C22 for ; Tue, 11 Oct 2011 05:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqGrzysge5G3 for ; Tue, 11 Oct 2011 05:26:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AAEAE21F8B94 for ; Tue, 11 Oct 2011 05:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1379; q=dns/txt; s=iport; t=1318335993; x=1319545593; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=e0raidb8Tr7CV9rX/jZh9SbVOuR2vHhr0td2ed+vj0A=; b=B/NAVdvVYZArfkdTVbA4XMDddcUEYYFrA8J0h8dqvw9mHcyQfJ0dtnCr Uub9/Uny9ZZ2YugQGB6sM0559nxSsV3OxM3TVRg/EuFzUJLuUpwmnethh DtvlsEG0ZHhXPsnN6E5RHnjWBBRg31ccUoMmW99C2/ARMd0BO3YvPaFWu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALs1lE6tJV2Y/2dsb2JhbABDqCaBBYFTAQEBAwESASc/BQsLRlcGNYdcmlIBnlOGa2EEk3WFKIxG X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208";a="27498893" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 11 Oct 2011 12:26:33 +0000 Received: from Freds-Computer.local (rtp-vpn4-1640.cisco.com [10.82.214.104]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9BCQWrt030689; Tue, 11 Oct 2011 12:26:32 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 11 Oct 2011 08:26:32 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 11 Oct 2011 08:26:32 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E93C075.30400@piuha.net> Date: Tue, 11 Oct 2011 08:26:23 -0400 Message-Id: <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Acee Lindem , "homenet@ietf.org" , curtis@occnc.com Subject: Re: [homenet] Thoughts about routing 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, 11 Oct 2011 12:26:34 -0000 On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote: > That being said, if the home routers have to discover their IPv6 = prefix through a protocol and store it in flash, they could probably do = so also for a router ID. Unless there was some chicken and egg problem = that required the router ID for all this discovery to work... (z)ospf requires the router to have a router id in order to join the = network, which it has to do before it can receive the LSAs from other = routers in the area to inspect their subnet prefixes. So making the = router id dependent on the prefix doesn't make a lot of sense to me. While a MAC Address is not guaranteed to be globally unique, it is = intended to be; places where duplicates have been seen tend to be = manufacturing errors. =46rom that perspective, grabbing the least = significant 32 bits from a MAC address as a first guess seems = reasonable. What one would then need to do is=20 1) receive the LS Database 2) inspect for other instances of the same router id 3a) if found, attempt to flush the LSA (it might be an old LSA from the = same router) 3b) if flushed and it is then re-advertised back, there is a collision = and the other router is asserting ownership; pick a random number One obviously doesn't actually announce any LSAs using the router ID = until a unique router id is established.= From mcr@sandelman.ca Tue Oct 11 06:44:31 2011 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 F329221F8DBA for ; Tue, 11 Oct 2011 06:44:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVQ8lf78IjAZ for ; Tue, 11 Oct 2011 06:44:30 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63D21F8DB9 for ; Tue, 11 Oct 2011 06:44:30 -0700 (PDT) Received: from marajade.sandelman.ca (office.nvanjou.isp.novavision.ca [38.102.81.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 01AC3343B1; Tue, 11 Oct 2011 09:43:23 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id AF95D98CB3; Tue, 11 Oct 2011 07:48:25 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A3C2C98CB2; Tue, 11 Oct 2011 07:48:25 -0400 (EDT) From: Michael Richardson To: curtis@occnc.com In-Reply-To: <201110110007.p9B07ejV059082@gateway.ipv6.occnc.com> References: <201110110007.p9B07ejV059082@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 07:48:25 -0400 Message-ID: <30142.1318333705@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org, Erik Nordmark Subject: Re: [homenet] walled garden DNS 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, 11 Oct 2011 13:44:31 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Curtis" =3D=3D Curtis Villamizar writes: Curtis> If this is a walled garden within the home, would it be simple = enough Curtis> to use a 6to4 address space for one globally unique IPv4 addres= s and Curtis> just not bring up a 6to4 tunnel? Curtis> Instant walled garden. With private DNS. I think that this might well be a great way to get walled garden address space. We should probably emphasize that 2002: space is part of 2000::/3, and should not be treated differently by routers. However, I'm afraid that hosts might already have rules (due to happy eyeballs) that make 2002: useable. I hope i am wrong here. Curtis> If you have control over both the DHCP (4 or 6) server and the = DNS Curtis> server, you can make DNS look like anything you want within the Curtis> garden. [Except for those hosts who do their own DNS from root= or have Curtis> configured a DNS forwarder from elsewhere. Only the geeks.] Or anyone running DNSSEC, and I expect DNSSEC to be required for anything working with .gov or .mil or their equivalents in other countries.=20 Curtis> The original question seems to be whether the same dns query (f= or Curtis> example, garden.example.com) could be made to resolve different= ly in Curtis> ISP-A and ISP-B and the answer is "yes" with no changes but wit= h the Curtis> exception within [] in the prior paragraph. Yes, the dns server can give out different answers to different query origins. This interacts very poorly with DNS caches, including the ones on hosts. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpQtCYCLcPvd0N1lAQLXmQf/VKk6UqdPQomCnzjU2lQ7vtagV+4+i4Ut 18OCo5Bz8zkDirvi7m9W1I5g1NwIGV84CZq9vmwLnAc2xEKrWQHeVx/bJvgJBF1L HIoE2FtCrC8nBBx8iWYIfgVnpBSNuJg5DjHwy2FgmGitJKEqLP756fPEX0AkI6v6 wNAioY0DU927t1I/2OaPMazXxynbIzCT207b+TYlPLZqZ3/4K2V8wQEmrdAtk3Ms vnAMtfKtStT4/sWZj7dy3d+vAtGAz6T/0adW96iWgS0dP36JRQeNS0OXpo+iebK9 GghscObIE3XtapBoTPmxsLP5BNQyyx8WVapl1ZaMRiJcEitpKYAVJA== =KXfP -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Oct 11 06:44:32 2011 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 8DD8621F8DBD for ; Tue, 11 Oct 2011 06:44:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssZ9Eoajy1-P for ; Tue, 11 Oct 2011 06:44:32 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5E58B21F8DB5 for ; Tue, 11 Oct 2011 06:44:30 -0700 (PDT) Received: from marajade.sandelman.ca (office.nvanjou.isp.novavision.ca [38.102.81.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 9271D343B0 for ; Tue, 11 Oct 2011 09:43:22 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 9AC5698CB5; Tue, 11 Oct 2011 08:11:33 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9446B98CB4 for ; Tue, 11 Oct 2011 08:11:33 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <20111011060817.GK28724@x27.adm.denic.de> References: <4E7A46EC.8080109@globis.net> <4E8A658B.9060200@cisco.com> <8438.1318266383@marajade.sandelman.ca> <20111011060817.GK28724@x27.adm.denic.de> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 08:11:33 -0400 Message-ID: <895.1318335093@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] walled garden DNS 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, 11 Oct 2011 13:44:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Peter" =3D=3D Peter Koch writes: >> example.com NS reachable by the world. >> garden.example.com NS pointing to AAAA record, where IPv6 >> address is only reachable from garden. >> television.garden.example.com AAAA returned from >> garden.example.com name server (above) >>=20 >> This solution works perfectly in IPv4 land, but due to lack of IPv4 Peter> it works, but nowhere near perfectly. Whenever a querying system Peter> changes its intended name space (resolution context) from $local Peter> to the global one, resolution of names in garden.example.com Peter> will just time out. Encoding this user experience in the design = looks Peter> like a suboptimal choice to me. yes, but what is being asked for now, is that the host equivalent of /etc/resolv.conf be extended with a list of suffixes. We are told that mobile operators (who still think they own the handsets) will be deploying various application layer systems whereby the application will always do some DNS requests over 4G, and some content will only be available that way. So, this failure you describe will still occur, but instead of "timeout" the user will get "host not found" >> It seems to me that we just don't need anything else in IPv6, except >> easily *available* non-connected PI address space (whether it's ULA-= C, >> some recognized part of 2000::/3, or an entirely new space). Peter> While ULAs would "reduce" collisions, the general issues would b= e the same Peter> as with RFC1918 space. Thus why I said ULA-C. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpQydYCLcPvd0N1lAQI5FAgAq2YSm4Zc0SiSPO/D34DKmyDNcLrmPZrx QXcEiJY+b7DxF8SIyBujyRbmM3mAV2fyOWIBdt9Xwma/Hy1mJIQPYynEd/5cU9DO HykIoP2GPIMPsHuHIevV3cp8SssR8yQ7U6/eP+P+jTMjTCkv7m0k73rOZOVnkQdi fX2CkrFaEn2OsP060cmVMI1grwaZjJCTuZ6m9yDmBaU1Ds5e687AempAZBtsuh6N CVY9g7leH8w4mr8bwi0LcsdAcZ2dYc0BDgTb3eaKbhNSdw+o/UlWBhpJrzxjqILw heDZd8pBh8+LYbMaOyAeiDbAOMd1oRWUlqjhUIP0UkSKQgWKv93fBw== =f4IS -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Oct 11 06:46:36 2011 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 8779921F8C6E for ; Tue, 11 Oct 2011 06:46:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6fA4aO3NdIF for ; Tue, 11 Oct 2011 06:46:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id DF71E21F8C83 for ; Tue, 11 Oct 2011 06:46:35 -0700 (PDT) Received: from marajade.sandelman.ca (office.nvanjou.isp.novavision.ca [38.102.81.98]) by relay.sandelman.ca (Postfix) with ESMTPS id EC8D3343A0; Tue, 11 Oct 2011 09:45:31 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2324098C90; Tue, 11 Oct 2011 09:47:26 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 1EE059817F; Tue, 11 Oct 2011 09:47:26 -0400 (EDT) From: Michael Richardson To: curtis@occnc.com In-Reply-To: <201110110152.p9B1q7R4061766@gateway.ipv6.occnc.com> References: <201110110152.p9B1q7R4061766@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 11 Oct 2011 09:47:26 -0400 Message-ID: <6775.1318340846@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 11 Oct 2011 13:46:36 -0000 >>>>> "Curtis" == Curtis Villamizar writes: Curtis> If it is zero config and its persistent store is DHCP leases, then Curtis> they will expire. OSPF advertisements would have aged out long ago. Curtis> It might be worth redoing the router-id selection if it is well past Curtis> the maxage limit and there are no adjacencies. So, I think you are right in general... the IA-PD might last more than a week. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From wbeebee@cisco.com Tue Oct 11 06:46:59 2011 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 D673A21F8D9A for ; Tue, 11 Oct 2011 06:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFIx9tgN6vV1 for ; Tue, 11 Oct 2011 06:46:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B921F8C1F for ; Tue, 11 Oct 2011 06:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=878; q=dns/txt; s=iport; t=1318340819; x=1319550419; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=x4CerZRh5+iEYsFnZyFiK0on7MT2LdGZKy1xz699Bio=; b=JiVCxuFA/LhbAOZ0rwzzGy+HSpy35lPmGQji029uyZxnofp3JIMjnMwW oWbt2YWrOLeGU9QmBquPgcy6ozoFnXaxXB9r6KyUjCfG0+YlIodB2y8Gx 6YnzJEdzKAMuuUPFfzs220o6lPdYTBNzJfB60/WMK9piz89B2H/+KQQNo U=; X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208";a="27529033" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 11 Oct 2011 13:46:58 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9BDkwM2018102; Tue, 11 Oct 2011 13:46:58 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 08:46:58 -0500 Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Tue, 11 Oct 2011 13:46:57 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Tue, 11 Oct 2011 09:46:55 -0400 From: Wes Beebee To: , Ole Troan Message-ID: Thread-Topic: [homenet] Multilink subnet routing (MLSRv2) Thread-Index: AcyIHDz0HWmwLYQeYEGxNGoYBRjxyQ== In-Reply-To: <201110102050.p9AKoDdP055011@gateway.ipv6.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Oct 2011 13:46:58.0107 (UTC) FILETIME=[3ECE48B0:01CC881C] Cc: Erik Nordmark , homenet@ietf.org Subject: Re: [homenet] Multilink subnet routing (MLSRv2) 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, 11 Oct 2011 13:46:59 -0000 > Having missed the meeting, anything more recent on MLSR than this: > > draft-ietf-ipv6-multilink-subnets-00 > Multi-link Subnet Support in IPv6 (2002-07-08, Expired) > > draft-thaler-ipngwg-multilink-subnets-02 > Multi-link Subnet Support in IPv6 (2001-11-29, Expired) > > The only reference to MLSR in an RFC is in an IAB RFC, RFC4903: > > There was also a proposal to define multi-link subnets [MLSR] for > IPv6. However, this notion was abandoned by the IPv6 WG due to the > issues discussed in this memo, and that proposal was replaced by a > different mechanism that preserves the notion that a subnet spans > only one link [RFC4389]. Note that there is a subset of the multi-link subnet problem that can be solved using an "off-link" model as described in RFC 5942, and is currently deployed in DOCSIS networks. - Wes From russw@riw.us Tue Oct 11 06:50:25 2011 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 80EC921F85B1 for ; Tue, 11 Oct 2011 06:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvgv0oflzGZe for ; Tue, 11 Oct 2011 06:50:25 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id B788C21F8586 for ; Tue, 11 Oct 2011 06:50:23 -0700 (PDT) Received: from dhcp-64-102-202-124.cisco.com ([64.102.202.124]:52524) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RDcis-0007tS-5D for homenet@ietf.org; Tue, 11 Oct 2011 09:50:22 -0400 Message-ID: <4E944989.5070801@riw.us> Date: Tue, 11 Oct 2011 09:50:01 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <20110921113700.25835.21217.idtracker@ietfa.amsl.com> <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk> <9C518B43-38DD-4733-8B00-5E57EA7EE82F@cisco.com> In-Reply-To: <9C518B43-38DD-4733-8B00-5E57EA7EE82F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] draft-chown-homenet-arch-00.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, 11 Oct 2011 13:50:25 -0000 > We would like to get plenty of review and comment. Rather than dealing with individual edits, I'd rather start with a general philosophy question. I understand that the IETF thinks NATs are evil, but I also think there shouldn't be so much emphasis on "homenets are not NAT," in an architecture document. Can we sideline the entire discussion over NATs. They're going to be there no matter what. My second concern is that while I understand the "end-to-end principle," I also know that it's not realistic in many situations --and the home is one place where it's probably not. I know, I know, this is all heresy, but hear me out for a second before you hit reply and tell me how stupid I am being. This one line illustrates the entire concept in a nutshell: > Security perimeters can of > course restrict the end-to-end communications, but it is > easier to block certain nodes from communicating than it is to re- > enable nodes to communicate if they have been hidden behind > address translation devices. Is this really true? When I want to secure a physical space, I block off all access, then put in carefully thought out access control points. I don't pile all my goods in the middle of the street, and then actively monitor every person who walks by, hiring more people to do the monitoring as needed. And I would point out that the problem is even worse in the network world --it's a large risk to come into my house and try to rob me, because of the physical danger involved. There is physical risk for the person breaking and entering, in other words. Breaking into me network has no risk whatsoever, and the gain could be huge --larger than stealing what I have in my living room. Instead of stealing my television, could steal my identity --and all at no physical risk, with trivial effort (you don't have to actually go to my house, etc.). So my posture on the network side is actually "stronger," and "more suspicious," than it is on the physical side. I think we should be a little more realistic about network security. We'd all like to live in a world where there are no identity thieves, and there are no viruses, and there is no-one trying to harm you, or invade your privacy. But that's just not real. And I know I'm about to get all sorts of stories about how someone has had their computer connected to the internet for x number of years, no nat, no firewall, and they've never caught anything, nor had anyone steal anything. Maybe you just need to lead a more interesting life if that's the case. And I'm happy for you, but when I actually administered a large network, I had virus incidents constantly --and I know I face it all the time in customer networks. So, IMHO: 1. Stop the screed against NAT. 2. Set out positive requirements, rather than negative ones. 3. Be realistic about security --the default should be _nothing_ reaches into my home, and I should have an easily managable way to allow what I want to allow. The default should not be an open door to anyone from anyplace at any time, and then "we'll put in advanced monitoring to block activity." Just my 2c. :-) Russ From mcr@sandelman.ca Tue Oct 11 06:53:16 2011 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 0262221F8BA6 for ; Tue, 11 Oct 2011 06:53:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfwGxvQ7XmKR for ; Tue, 11 Oct 2011 06:53:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6090A21F8B75 for ; Tue, 11 Oct 2011 06:53:15 -0700 (PDT) Received: from marajade.sandelman.ca (office.nvanjou.isp.novavision.ca [38.102.81.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 76D01343A4 for ; Tue, 11 Oct 2011 09:43:22 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2B4BC98CB6; Tue, 11 Oct 2011 08:23:31 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 23B3198CB4 for ; Tue, 11 Oct 2011 08:23:31 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> References: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 08:23:31 -0400 Message-ID: <2584.1318335811@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Homenet strawman slides 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, 11 Oct 2011 13:53:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Curtis" =3D=3D Curtis Villamizar writes: Curtis> I really don't know how many support calls are just the consumer Curtis> plugging the computer into the wrong Ethernet port on the NAT b= ox and Curtis> the uplink on the other port and then not being able to figure = out Curtis> what is wrong. All the cables fit in the connector. It should= work! So, I was interrupted yesterday, reading homenet email, in order to go to my neighbour's house and sort out this EXACT problem.=20=20 =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpQ1QoCLcPvd0N1lAQLqgAf/c5IlYRCdY0mlOGIgZB8/sW9aHZ496dDz jSrkcJPgiioORLo0kNQSrwkPuxrC+MU+2UoLE6bgd+IW4i7NdrFF9pL/Af0MpY1i W0L0UGbCEqtdRtortbh0RlmoLoJ8Pk3IuhLq8BqtDzTKrBun7euAkvHVELAd7Hit 2fRiUIZzHQyeb6NlW+KsV4Je0KTSx3sleupWLyXqSlinK9XLOFTR6yanSgW9fZDh 8Jnxvh12PI5ScG6FM2U9OIbTbxtYKb5XkyxpMKfk8YdPmd5LojNBJke3Kx7JsDJF LxlP0yI22ZC1jt2rvhzciRi6Mwmd/5qbEjpVuWsdVJYrGP2CAfSC6g== =QqWY -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Oct 11 07:26:39 2011 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 70FDC21F8D9A for ; Tue, 11 Oct 2011 07:26:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL5AuMfvFTAX for ; Tue, 11 Oct 2011 07:26:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id C0E7D21F8BF8 for ; Tue, 11 Oct 2011 07:26:36 -0700 (PDT) Received: from marajade.sandelman.ca (office.nvanjou.isp.novavision.ca [38.102.81.98]) by relay.sandelman.ca (Postfix) with ESMTPS id C5684343AE for ; Tue, 11 Oct 2011 10:25:31 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2EC1E98C90; Tue, 11 Oct 2011 10:27:26 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 27ACD9817F for ; Tue, 11 Oct 2011 10:27:26 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 10:27:26 -0400 Message-ID: <12544.1318343246@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Thoughts about routing 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, 11 Oct 2011 14:26:39 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Fred" =3D=3D Fred Baker writes: Fred> On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote: >> That being said, if the home routers have to discover their IPv6 >> prefix through a protocol and store it in flash, they could >> probably do so also for a router ID. Unless there was some >> chicken and egg problem that required the router ID for all this >> discovery to work... Fred> (z)ospf requires the router to have a router id in order to Fred> join the network, which it has to do before it can receive the Fred> LSAs from other routers in the area to inspect their subnet Fred> prefixes. So making the router id dependent on the prefix Fred> doesn't make a lot of sense to me. Fred> While a MAC Address is not guaranteed to be globally unique, Fred> it is intended to be; places where duplicates have been seen Fred> tend to be manufacturing errors. From that perspective, Fred> grabbing the least significant 32 bits from a MAC address as a Fred> first guess seems reasonable. What one would then need to do Fred> is What do we do in that rare case where the bottom 32 of the MAC are duplicated?=20=20=20 Also consider that virtual switches (VMware, XEN, etc.) all pretty much use the same set of MAC addresses. VMware has a 50: prefix that they use, XEN has another, and did you know that 10:00:00 (curisously like 10/8) is reserved for private use...=20 So, it would be good for zospf text to say something about this. I think that we can use 32-bits of MAC address in most cases. Fred> One obviously doesn't actually announce any LSAs using the Fred> router ID until a unique router id is established. okay. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpRSTYCLcPvd0N1lAQIZngf+McTjI88Pp78/oTJi4Al2wkI/h33/d6BY Py2k/TAZL0lmKB8gYXyWY15czgzSSdUx6I66K9oj2fKG5FaFMt49pHobR5QYAP65 rTEBN9r3dj4dtRq564P9eQdktw8LaobiggpqtqA42bKICC1hbK6+j0Ol/aWnKPru 85aOW2xHLzr6Gf4TOGo6xLvM1UFZPnbpWLbJN9ppE2qX5JNWneueoiCv72QPP9nw 4L7BS3eCokiHBKaHuuYerTLorbIVKja8Lo+6H71Chvctm+UU81VeXpIW4CEL4ACQ yde/3jkRgBurH7Mg8DT8WYUlEgfnrPODUKFr6ns5n+fJa8+haoUdlg== =H84v -----END PGP SIGNATURE----- --=-=-=-- From acee.lindem@ericsson.com Tue Oct 11 08:02:22 2011 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 A9D1321F8E0D for ; Tue, 11 Oct 2011 08:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX-z6I+hD8nS for ; Tue, 11 Oct 2011 08:02:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E2CCE21F8CD6 for ; Tue, 11 Oct 2011 08:02:21 -0700 (PDT) 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 p9BF2Bq3008350; Tue, 11 Oct 2011 10:02:21 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 11 Oct 2011 11:02:09 -0400 From: Acee Lindem To: Michael Richardson Date: Tue, 11 Oct 2011 11:02:07 -0400 Thread-Topic: [homenet] Thoughts about routing Thread-Index: AcyIJr+imNgsgepOSyivibYTG9IIvg== Message-ID: References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> <12544.1318343246@marajade.sandelman.ca> In-Reply-To: <12544.1318343246@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-5-735711728"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 11 Oct 2011 15:02:22 -0000 --Apple-Mail-5-735711728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 11, 2011, at 10:27 AM, Michael Richardson wrote: >=20 >>>>>> "Fred" =3D=3D Fred Baker writes: > Fred> On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote: >=20 >>> That being said, if the home routers have to discover their IPv6 >>> prefix through a protocol and store it in flash, they could >>> probably do so also for a router ID. Unless there was some >>> chicken and egg problem that required the router ID for all this >>> discovery to work... >=20 > Fred> (z)ospf requires the router to have a router id in order to > Fred> join the network, which it has to do before it can receive = the > Fred> LSAs from other routers in the area to inspect their subnet > Fred> prefixes. So making the router id dependent on the prefix > Fred> doesn't make a lot of sense to me. >=20 > Fred> While a MAC Address is not guaranteed to be globally unique, > Fred> it is intended to be; places where duplicates have been seen > Fred> tend to be manufacturing errors. =46rom that perspective, > Fred> grabbing the least significant 32 bits from a MAC address as = a > Fred> first guess seems reasonable. What one would then need to do > Fred> is >=20 > What do we do in that rare case where the bottom 32 of the MAC are > duplicated? =20 The conflict must be resolved with one router selecting a different = Router-ID. That is a problem that would need to be handled in any OSPFv3 = auto-configuration draft. You cannot have two routers in the same routing domain with the same = OSPFv3 Router ID since their LSAs cannot be differentiated from one = another and the two routers with the same Router-ID will get into a = flooding war. =20 Thanks, Acee >=20 > Also consider that virtual switches (VMware, XEN, etc.) all pretty = much > use the same set of MAC addresses. VMware has a 50: prefix that they > use, XEN has another, and did you know that 10:00:00 (curisously like > 10/8) is reserved for private use...=20 >=20 > So, it would be good for zospf text to say something about this. > I think that we can use 32-bits of MAC address in most cases. >=20 > Fred> One obviously doesn't actually announce any LSAs using the > Fred> router ID until a unique router id is established. >=20 > okay. >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ > Kyoto Plus: watch the video = > then sign the petition.=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-5-735711728 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAxMTE1MDIwOFowIwYJKoZI hvcNAQkEMRYEFJlnwfDUlOSOU4rcWfVa9cyol08fMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgIAfvJwLrdzwjeLOjYtv4o5f5CeB52hZoH0sUggr2mtZQyp39v/zUewMLMHDQ83U ZgIVt53j1D7yaPfVD2RUO7CMvTZtf843SbTVvX8BMHmZYcVfYyXA4gVaYM5QE4jUB8g3Xm21gB8k uU20tcILh/wepNKKeJSzGNwDhtRaiS8eAAAAAAAA --Apple-Mail-5-735711728-- From fred@cisco.com Tue Oct 11 08:57:16 2011 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 BE91621F8E44 for ; Tue, 11 Oct 2011 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hitSLWy9tj1I for ; Tue, 11 Oct 2011 08:57:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A88F621F8E34 for ; Tue, 11 Oct 2011 08:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2906; q=dns/txt; s=iport; t=1318348635; x=1319558235; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=MZ38UI78m66exgwxEEL+uLcgMoKM3VRMMiwLUpuE0Os=; b=YEm5Q+a7P6amX/Srg42xjQJB7GYTXMqmqYS8nl27+RtM8nFzHxdCKRFS AbtQhdDYJL/g5BEBVatN5CCQC47Qtx9cMmdNGJsGWO3pyS/6wYDXKTHmx qi+mgTCxAYzixkxWkdr7ayR6lOQ9cacCI3NoBQPDiKS2wXoewGNMPzOoE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEtmlE6tJXHA/2dsb2JhbABDpXd7gTaBBYFTAQEBAwEBAQEPASc0CwULCw4KLhwLMAYTGQmHXAeaGwGQbY1uhmthBIY/jTaFKIVlhmE X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208";a="27567242" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 11 Oct 2011 15:57:15 +0000 Received: from Freds-Computer.local (rtp-vpn2-837.cisco.com [10.82.243.69]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9BFvEbb010145; Tue, 11 Oct 2011 15:57:14 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 11 Oct 2011 11:57:15 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 11 Oct 2011 11:57:15 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <12544.1318343246@marajade.sandelman.ca> Date: Tue, 11 Oct 2011 11:56:53 -0400 Message-Id: <2B0914DE-6E6D-47B2-9B6B-D6A3F4338752@cisco.com> References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> <12544.1318343246@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 11 Oct 2011 15:57:16 -0000 On Oct 11, 2011, at 10:27 AM, Michael Richardson wrote: >=20 >>>>>> "Fred" =3D=3D Fred Baker writes: > Fred> On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote: >=20 >>> That being said, if the home routers have to discover their IPv6 >>> prefix through a protocol and store it in flash, they could >>> probably do so also for a router ID. Unless there was some >>> chicken and egg problem that required the router ID for all this >>> discovery to work... >=20 > Fred> (z)ospf requires the router to have a router id in order to > Fred> join the network, which it has to do before it can receive = the > Fred> LSAs from other routers in the area to inspect their subnet > Fred> prefixes. So making the router id dependent on the prefix > Fred> doesn't make a lot of sense to me. >=20 > Fred> While a MAC Address is not guaranteed to be globally unique, > Fred> it is intended to be; places where duplicates have been seen > Fred> tend to be manufacturing errors. =46rom that perspective, > Fred> grabbing the least significant 32 bits from a MAC address as = a > Fred> first guess seems reasonable. What one would then need to do > Fred> is >=20 > What do we do in that rare case where the bottom 32 of the MAC are > duplicated? =20 Pick a random number. Note that we agree it is a rare case. If it's a = router, it probably has more than one MAC Address... > Also consider that virtual switches (VMware, XEN, etc.) all pretty = much > use the same set of MAC addresses. VMware has a 50: prefix that they > use, XEN has another, and did you know that 10:00:00 (curisously like > 10/8) is reserved for private use...=20 Yes, and homes frequently use virtual switches. To be really honest, yes, it would be good for zospf - if we recommend = that - to make some suggestions. That said, there is no reason for the = suggestions to be normative. What OSPF requires is that the RID is = unique in the area. It does not require that it be derived from any = given datum. > So, it would be good for zospf text to say something about this. > I think that we can use 32-bits of MAC address in most cases. >=20 > Fred> One obviously doesn't actually announce any LSAs using the > Fred> router ID until a unique router id is established. >=20 > okay. >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | = firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ > Kyoto Plus: watch the video = > then sign the petition.=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nordmark@cisco.com Tue Oct 11 10:53:04 2011 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 1ABB621F8F54 for ; Tue, 11 Oct 2011 10:53:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wM8KziaF9xI for ; Tue, 11 Oct 2011 10:53:03 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4B321F8F77 for ; Tue, 11 Oct 2011 10:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=4751; q=dns/txt; s=iport; t=1318355583; x=1319565183; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/lKOjJ2sy/YvFpit9asbR8xR8eP05IxLKJVpHqBG5WA=; b=PjfudYwvIrT7bmjs6wWW3nJ/+76BEv8c4idh5DGENttba+1n8IrhOaDQ vegzUFHUlMhL5M3E49pw8VnE75lI3ITo1i/q6+c0XOrhMzwpUXt6Twcpq 3exKtDWMBPN0cK2X9tckYjaUVMLUpKxQfE9esP6KKwyyAncas1a4dtxHj U=; X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208";a="7232635" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 11 Oct 2011 17:53:03 +0000 Received: from [128.107.115.235] ([128.107.115.235]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9BHr2nO002927; Tue, 11 Oct 2011 17:53:02 GMT Message-ID: <4E94829E.2010403@cisco.com> Date: Tue, 11 Oct 2011 10:53:34 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> In-Reply-To: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Jari Arkko , Lorenzo Colitti Subject: Re: [homenet] Homenet strawman slides 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, 11 Oct 2011 17:53:04 -0000 On 10/10/11 5:33 PM, Curtis Villamizar wrote: > In message<4E93358F.7050907@cisco.com> > Erik Nordmark writes: > >> On 10/8/11 6:13 AM, Jari Arkko wrote: >>> I like this, with the possible exception of using ULAs and your desire >>> to deprecate prefixes as soon as connectivity goes down. (Speaking as >>> someone whose prefixes got invalidated two months ago but who hasn't >>> been home long enough to fix the problem, but my devices still happily >>> communicate with each other using the old prefixes :-) I also agree with >>> Erik that loop and arbitrary topologies is not really required. But the >>> people in the interim at least seemed to say yesterday that we want to >>> go there. >> >> I think there are different scopes being discussed. >> >> The one I put forth is how to enable existing IPv4 NATting consumer home >> routers (which all have a designated uplink port, and support multiple >> home routers by nested NATting) have a way to support IPv6 without >> requiring any IPv6 NATs. That doesn't seem to be a difficult problem >> (which perhaps makes it uninteresting for some of us), but to me it >> seems like an important short-term problem to solve. >> >> The larger scope is around arbitrary topologies, no designated uplink >> port, and perhaps also multihoming. Plenty of problems to solve around >> autoconfiguring routing protocols, stable prefix assignment to links, >> multihoming, etc. > > > Erik, > > I really don't know how many support calls are just the consumer > plugging the computer into the wrong Ethernet port on the NAT box and > the uplink on the other port and then not being able to figure out > what is wrong. All the cables fit in the connector. It should work! It sure would be good to try to find some data on this. > If all the ports are the same, no designated uplink, that is better. While I can see that we can build the internals of the home network with devices without a designated uplink (automatically configure prefixes, the routing protocol etc), what I don't understand is how the connectivity to the ISP would happen. How do you see that working? Will each router try the protocols it would use against the ISP (PPPOE, DHCP PD, etc) on every port? Or on every port where it doesn't find a OSPF (or whatever home routing protocol we choose) neighbor? Or does the user have to configure the Customer Edge Router to say "port eth0 is the WAN port?" FWIW I haven't seen any discussion to try to automate this. The manual configuration would be just as error prone as making the distinction between the yellow WAN port and the blue LAN ports on current home gear. > If you get an IP address via DHCP on one and none of the others, it > may be the uplink and try doing NAT. What may be needed is a IPv4 > equivalent to the IPv6 IA_PD and a provider DSL or docsis modem/router > that knows how to respond to it. The other routers ask for a IA_PD > and the provider modem/router responds with part of 10/8 on each > interface (and does NAT). Presumably DHCP could be used within the home for address (and potentially prefix) configuration, thus I don't think we can assume that just because some neighbor on some port responds to a DHCP packet that it is the WAN port. For all we know, the neighbor might be a DHCP relay for the home network. > The idea is that the consumer can plug things in in arbitrarily stupid > way and it will all still work well enough to not require a support > call. It might work better if set up right, but good enough if set up > wrong. Perhaps GbE can be preferred over 100baseT over 10baseT and > somewhere between 100baseT over 10baseT or after 10baseT fits WiFi. > Beyond that metrics for multiple WiFi hops can be channel aware. I don't think arbitrarily stupid way can possibly work, since that doesn't ensure that the home network is internally connected. If the user connects three routers in the den together, but those are not connect to the rest of the house, then no protocol we come up with can fix that. If the user wants to have sufficient redundancy (e.g., so that their teenagers can power off all the gear in the game room with breaking the Internet connectivity for half of the devices in the home, then clearly there is a need to understand the topology (wired or wireless) to know where there are potential single points of failure. Supporting arbitrary topology (as opposed to just trees) is good in that it enables redundant internal topologies. But getting to a redundant topology requires a deeper knowledge by the users than mandating a tree. More rope. Doesn't mean it is simpler for the users. Erik From ot@cisco.com Tue Oct 11 11:03:55 2011 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 0339C21F8BBF for ; Tue, 11 Oct 2011 11:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.524 X-Spam-Level: X-Spam-Status: No, score=-9.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuHnhU+IPJ6Q for ; Tue, 11 Oct 2011 11:03:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AE25C21F8B77 for ; Tue, 11 Oct 2011 11:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=1169; q=dns/txt; s=iport; t=1318356232; x=1319565832; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=V0RkgIKMvYMBezoNXzWgPBAMSz65CXQxgAzU4aVhq/s=; b=aZx6UGfykBHAoCVFqtf2T+OohOzwsuMcyXMfadOy57u3LA2hhD7E6NbY v78iHpPcwNx+5Cvqz9b2UTJm0Ydmcnmu/ZXKbQajH+qHiy+cAppMDCQmb TSqSOXaEKaijU8JWlew0WxtLw38E7oPKyrkg0bgn/RrzOfgoATv6j1Ubk c=; X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208";a="57580193" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 11 Oct 2011 18:03:51 +0000 Received: from dhcp-10-55-91-179.cisco.com (dhcp-10-55-91-179.cisco.com [10.55.91.179]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9BI3qUT016729; Tue, 11 Oct 2011 18:03:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E94829E.2010403@cisco.com> Date: Tue, 11 Oct 2011 20:03:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> <4E94829E.2010403@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Lorenzo Colitti , Jari Arkko , curtis@occnc.com Subject: Re: [homenet] Homenet strawman slides 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, 11 Oct 2011 18:03:55 -0000 Erik, >> If all the ports are the same, no designated uplink, that is better. >=20 > While I can see that we can build the internals of the home network = with devices without a designated uplink (automatically configure = prefixes, the routing protocol etc), what I don't understand is how the = connectivity to the ISP would happen. >=20 > How do you see that working? > Will each router try the protocols it would use against the ISP = (PPPOE, DHCP PD, etc) on every port? Or on every port where it doesn't = find a OSPF (or whatever home routing protocol we choose) neighbor? Or = does the user have to configure the Customer Edge Router to say "port = eth0 is the WAN port?" >=20 > FWIW I haven't seen any discussion to try to automate this. The manual = configuration would be just as error prone as making the distinction = between the yellow WAN port and the blue LAN ports on current home gear. this is the problem we named "border discovery" during the interim. there were a few ideas of how that could be done. either implicit or = explicit. nothing concluded, and I agree this is an important problem to = tackle. cheers, Ole= From russw@riw.us Tue Oct 11 11:50:41 2011 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 1760F21F8CBF for ; Tue, 11 Oct 2011 11:50:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfOm8M3tN8eD for ; Tue, 11 Oct 2011 11:50:40 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id EC35721F8CBB for ; Tue, 11 Oct 2011 11:50:39 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:59950 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RDhPS-00029Q-Gi for homenet@ietf.org; Tue, 11 Oct 2011 14:50:38 -0400 Message-ID: <4E948FE9.8050101@riw.us> Date: Tue, 11 Oct 2011 14:50:17 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> <12544.1318343246@marajade.sandelman.ca> In-Reply-To: <12544.1318343246@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Thoughts about routing 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, 11 Oct 2011 18:50:41 -0000 > What do we do in that rare case where the bottom 32 of the MAC are > duplicated? > > Also consider that virtual switches (VMware, XEN, etc.) all pretty much > use the same set of MAC addresses. VMware has a 50: prefix that they > use, XEN has another, and did you know that 10:00:00 (curisously like > 10/8) is reserved for private use... > > So, it would be good for zospf text to say something about this. > I think that we can use 32-bits of MAC address in most cases. > > Fred> One obviously doesn't actually announce any LSAs using the > Fred> router ID until a unique router id is established. > > okay. You need a unique identifier at the equipment level for anything you intend to auto-configure --autoconfiguring uniqueness is a very hard, probably impossible, problem on a global scale. So we need to count on this one thing, no matter what else we might need to back in to. Now, it might be possible to some hash over a GPS location for a "base," and then add on MAC addresses, or some such, but IMHO, homenet should start with the assumption of having some sort of "unique id" in every device deployed, available through some sort of local API, and work from there. Let's solve problems that can actually be solved... :-) :-) Russ From gettysjim@gmail.com Tue Oct 11 12:11:14 2011 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 25D601F0C3C for ; Tue, 11 Oct 2011 12:11:14 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4Fdqqiu1vHK for ; Tue, 11 Oct 2011 12:11:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5B41F0C35 for ; Tue, 11 Oct 2011 12:11:01 -0700 (PDT) Received: by vws5 with SMTP id 5so7287934vws.31 for ; Tue, 11 Oct 2011 12:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CJHyj98rwQ5yPoRb9H/HzxTihpcjxhpk7wXNFOFdKkY=; b=gXxC6I+zazwGWil60N9rQCiN+RPbhkruSjvgiyGOr+5BrOfVTBy6IX34Xw2HSwxc8y kTkGNzRJECaS5W/nKyJ3lQf0omlzWAcP36/VDgnjKsOxtqATJ+CMiXVcekadgN+I98Wj COApyklROjFXEKC2PHXRMQ3ILM2ImBGhkZj1Y= Received: by 10.52.72.196 with SMTP id f4mr20155555vdv.68.1318360236169; Tue, 11 Oct 2011 12:10:36 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id jo8sm23365070vdb.20.2011.10.11.12.10.34 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 12:10:35 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E9494A9.4030901@freedesktop.org> Date: Tue, 11 Oct 2011 15:10:33 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Fred Baker References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> In-Reply-To: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , homenet@ietf.org, homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing - trends 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, 11 Oct 2011 19:11:14 -0000 On 10/07/2011 03:48 AM, Fred Baker wrote: > 4) The use of OLSR in mesh network scenarios > > Jim Gettys commented on the fact of OLSR use. The general sense of the room was that OLSRv2 is interesting but out of scope for this discussion as mesh networks are quite different from typical residential and SOHO networks. > Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my area of expertise. Babel/BabelZ is appearing in CeroWrt today as the people who are interested in such things are doing the work (we don't need a routing protocol in the simple single home router case), and it provided the functionality we needed. For those who want something else, quagga is in the CeroWrt build for your hacking pleasure. And I'm not advocating the homenet working group do anything unusual about routing at this date; as I said, it's not my area of expertise. Having said this, I do note the following technological trends: 1) As soon as we get real "plug and play" routers that don't need manual configuration that work, we'll see a lot more routers in a home environment. Other radio technologies (e.g. zigbee) may encourage this trend. It seemed like the working group agreed that getting to the point that just hooking things together would really "just worked" was a fundamental requirement (and I agree entirely with this sentiment, as it reflects reality of what already happens in the homes of hackers and non-hackers alike). 2) wireless is much cheaper to implement than wired networking, particularly in most houses where pulling cable is hard. I know this first hand, where I've pulled a lot of cat 6 and wish I could get it to places I don't have it. Unless power line networking really works, I believe that this trend isn't going to change. Is there any progress in this area? I've seen many promises, and few reliable working products. 3) As soon as you have two routers, you have at least two paths; the wired connection between them and the wireless. You may have 3 paths, if you have both 2.4 and 5ghz radios. Frequency diversity routing becomes immediately interesting, along with using your ethernet when it's available in preference to wireless. 4) an apartment building look like a mesh, and possibly with multiple backhauls possibly with multiple ISP's. One should at least think about what happens when you have "homes", in such a building, and make sure nothing breaks. Wireless is messy: it isn't limited to where a wire goes. Taking down an entire apartment building/blocks/city would not be fun. I know, I've been there (at least to the point of taking down buildings, and came within a week of a much larger scale disaster). If you believe 1 + 2 + 3 +4 (as I do), then if you look a few years out, you end up with something in the "home" that begins to resemble very strongly what the community mesh networking folks are doing at a higher scale geographically and in terms of # of nodes today, with many/most of the same concerns and solutions. Understanding the problems they've faced/are facing is therefore worth a bit of investment; Radio diversity is one of the concerns, and interference (of various sorts). Julius' talk about why frequency diversity is an issue is here: http://www.youtube.com/watch?v=1VNzm0shSA8 While the issues outlined above are not where home networking is today, my gut feel is they will be in five years. If there is *anything* I can urge on the group, is to respect the scaling problems that can/will occur, and to internalise wireless !=wired: wireless goes where wireless goes and does not behave like ethernet. The group needs to ensure nothing "bad" happens when people start building systems in ways you don't expect, particularly in an apartment building. The challenge is balancing the reality of how wireless works, with "just works" automatic configuration, with "fail safe" behaviour. - Jim From touch@isi.edu Tue Oct 11 12:18:24 2011 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 B829021F8B4A for ; Tue, 11 Oct 2011 12:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzl5cBtwKexr for ; Tue, 11 Oct 2011 12:18:24 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7A21F8B48 for ; Tue, 11 Oct 2011 12:18:24 -0700 (PDT) Received: from [198.123.60.152] ([198.123.60.152]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p9BJHWV5003946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Oct 2011 12:17:50 -0700 (PDT) Message-ID: <4E94964D.202@isi.edu> Date: Tue, 11 Oct 2011 12:17:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "STARK, BARBARA H" References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E8F829C.9040902@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F1FC292D1@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1FC292D1@crexc50p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Thomas Narten , Erik Nordmark , homenet@ietf.org, Fred Baker Subject: Re: [homenet] Thoughts about routing 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, 11 Oct 2011 19:18:24 -0000 On 10/10/2011 7:18 AM, STARK, BARBARA H wrote: > The subset of tree topology where a consumer places ones router behind > another router is *extremely* common. Statistics I saw several years ago > suggested that probably about 60% of ADSL customers in the US use this > topology. The most common cause for this topology is where the service > provider supplies a free ADSL router with a single port to a subscriber, > and the subscriber then puts their own multi-port router behind that > router. The ADSL router is configured to do the PPPoE, and is also > configured to automatically provide whatever public IP address it gets > to whatever is behind it (via DHCPv4, as a sort of automatic DMZ > function -- the ADSL router also uses that public IP address for its > needs). The ADSL router is often set to provide only that one address, > and not to support a full network of devices. Which is why consumers are > forced to use their own router. ... They also do this commonly to introduce or upgrade their WiFi service at home without needing to reconfigure the subscriber access box. To a lot of consumers, IF things can be plugged together, then they WILL BE. > This also tends to be how VoIP router + > consumer's wireless router topology works. That too... Joe From stephen.farrell@cs.tcd.ie Tue Oct 11 15:13:50 2011 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 E296621F8E2C for ; Tue, 11 Oct 2011 15:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bplCDGbIAzYA for ; Tue, 11 Oct 2011 15:13:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3111421F8E29 for ; Tue, 11 Oct 2011 15:13:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 236B4171C45 for ; Tue, 11 Oct 2011 23:13:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1318371218; bh=UKdknVCH0RoWAAWOGTl86rHf IMHv75BG5Q+pWMRI20M=; b=D9BEL50Yez4rxzC5tj5b+NCteZBWn6Av/uk0N8dt /77DdMqhT8eQ15Op+co1ad0vJWupi3ueEWylSq+E84Xr41cwE9/ucnBc9yjU0xZD OPb9Q7ipti9OW37Iek+v1oMnJFuGKLkmi+2lobwZap0oxaVat5itV/HKKudjAq+j jBM/WCMVq9aSrHPBSiN8kPMd686vGgOicAZAqi2LKOV0ZiEJCONRe6E+yLT+VeX4 udJumjsBxBeKsI2Q824z5USHLHi90gBzJCVBo6e7+MbNNKR+ENyQiCpDG/FEMhYj lH0IcO2X44e3+k4OrX/amuZCrbFykTnwcwL/JDi6h3vIwg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id f4Qa732a+r7n for ; Tue, 11 Oct 2011 23:13:38 +0100 (IST) Received: from [10.87.48.10] (unknown [86.41.15.232]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id ADDF2171C3F for ; Tue, 11 Oct 2011 23:13:38 +0100 (IST) Message-ID: <4E94BF91.4060807@cs.tcd.ie> Date: Tue, 11 Oct 2011 23:13:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.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] security question for zeroconf stuff inside the 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, 11 Oct 2011 22:13:50 -0000 Hi, I've been reading the list with interest and have a question. When various devices in the home figure out which does what, and do that periodically to handle changes, there's clearly the potential that a zombied host tries to try take over stuff with undesirable consequences. My question is whether this group are planning to think about that now, or later, or never? (Or don't even think there's a problem worth attempting to address.) Note - I'm not trying to argue for any particular level of security and certainly not for some unachievable fort knox everywhere, I'm just asking what's the plan? S. From john.mann@monash.edu Tue Oct 11 17:33:26 2011 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 8525821F8CAC for ; Tue, 11 Oct 2011 17:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhpybyRXsVOe for ; Tue, 11 Oct 2011 17:33:25 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 3696C21F8CCC for ; Tue, 11 Oct 2011 17:33:25 -0700 (PDT) Received: from mail-qw0-f52.google.com ([209.85.216.52]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP; Tue, 11 Oct 2011 17:33:25 PDT Received: by qadz2 with SMTP id z2so665018qad.25 for ; Tue, 11 Oct 2011 17:33:24 -0700 (PDT) Received: by 10.182.136.68 with SMTP id py4mr849503obb.39.1318379604080; Tue, 11 Oct 2011 17:33:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.182.72 with HTTP; Tue, 11 Oct 2011 17:33:04 -0700 (PDT) In-Reply-To: <4E944989.5070801@riw.us> References: <20110921113700.25835.21217.idtracker@ietfa.amsl.com> <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk> <9C518B43-38DD-4733-8B00-5E57EA7EE82F@cisco.com> <4E944989.5070801@riw.us> From: John Mann Date: Wed, 12 Oct 2011 11:33:04 +1100 Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=e89a8f647903faf73604af0f2bdf Cc: homenet@ietf.org Subject: Re: [homenet] draft-chown-homenet-arch-00.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, 12 Oct 2011 00:33:26 -0000 --e89a8f647903faf73604af0f2bdf Content-Type: text/plain; charset=ISO-8859-1 Hi, On 12 October 2011 00:50, Russ White wrote: > > > We would like to get plenty of review and comment. > > Rather than dealing with individual edits, I'd rather start with a > general philosophy question. I understand that the IETF thinks NATs are > evil, but I also think there shouldn't be so much emphasis on "homenets > are not NAT," in an architecture document. Can we sideline the entire > discussion over NATs. They're going to be there no matter what. > > My second concern is that while I understand the "end-to-end principle," > I also know that it's not realistic in many situations --and the home is > one place where it's probably not. I know, I know, this is all heresy, > but hear me out for a second before you hit reply and tell me how stupid > I am being. > > This one line illustrates the entire concept in a nutshell: > > > > Security perimeters can of > > course restrict the end-to-end communications, but it is > > easier to block certain nodes from communicating than it is to re- > > enable nodes to communicate if they have been hidden behind > > address translation devices. > I think you are quoting from the "Transparent End-to-End Communications" section on pages 14/15 which is to do with communications _within_ the home network. > Is this really true? When I want to secure a physical space, I block off > all access, then put in carefully thought out access control points. I > don't pile all my goods in the middle of the street, and then actively > monitor every person who walks by, hiring more people to do the > monitoring as needed. > ... Generally speaking, I want open access within my home network, but may add specific rules to stop e.g. guest wi-fi getting to certain servers. I don't want layers of NAT within my home network, which is what you can get if you plug the WAN port of a IPv4 network device into the LAN port of another device. So, IMHO: > > 1. Stop the screed against NAT. > > 2. Set out positive requirements, rather than negative ones. > > 3. Be realistic about security --the default should be _nothing_ reaches > into my home, and I should have an easily managable way to allow what I > want to allow. The default should not be an open door to anyone from > anyplace at any time, and then "we'll put in advanced monitoring to > block activity." > See " Security, Borders, and the elimination of NAT" section on page 5. --- [RFC6092] provides recommendations for an IPv6 firewall that applies "limitations on end-to-end transparency where security considerations are deemed important to promote local and Internet security." The firewall operation is "simple" in that there is an assumption that traffic which is to be blocked by default is defined in the RFC and not expected to be updated by the user or otherwise. The RFC also discusses an option for CPEs to have an option to be put into a "transparent mode" of operation. It is important to distinguish between addressability and reachability; i.e. IPv6 through use of globally unique addressing in the home makes all devices potentially reachable from anywhere. Whether they are or not should depend on firewall or filtering behaviour, and not the presence or use of NAT. ... --- Does this address you concerns? John --e89a8f647903faf73604af0f2bdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 12 October 2011 00:50, Russ White = <russw@riw.us><= /span> wrote:

> We would like to get plenty of review and comment.

Rather than dealing with individual edits, I'd rather start with = a
general philosophy question. I understand that the IETF thinks NATs are
evil, but I also think there shouldn't be so much emphasis on "hom= enets
are not NAT," in an architecture document. Can we sideline the entire<= br> discussion over NATs. They're going to be there no matter what.

My second concern is that while I understand the "end-to-end principle= ,"
I also know that it's not realistic in many situations --and the home i= s
one place where it's probably not. I know, I know, this is all heresy,<= br> but hear me out for a second before you hit reply and tell me how stupid I am being.

This one line illustrates the entire concept in a nutshell:


> Security perimeters can of
> =A0 =A0 =A0 course restrict the end-to-end communications, but it is > =A0 =A0 =A0 easier to block certain nodes from communicating than it i= s to re-
> =A0 =A0 =A0 enable nodes to communicate if they have been hidden behin= d
> =A0 =A0 =A0 address translation devices.

I think you are quoting from the "Transparent End-to-End Communicati= ons" section on pages 14/15
which is t= o do with communications _within_ the home network.
=A0
Is this really true? When I want to secure a physical space, I block off all access, then put in carefully thought out access control points. I
don't pile all my goods in the middle of the street, and then actively<= br> monitor every person who walks by, hiring more people to do the
monitoring as needed.
...

Generally speaking, I want open access = within my home network,
but may add specific rules to stop e.g. g= uest wi-fi getting to certain servers.

I don't= want layers of NAT within my home network, which is what you can get if yo= u plug the WAN port of a IPv4 network device into the LAN port of another d= evice.

So, IMHO:

1. Stop the screed against NAT.

2. Set out positive requirements, rather than negative ones.

3. Be realistic about security --the default should be _nothing_ reaches into my home, and I should have an easily managable way to allow what I
want to allow. The default should not be an open door to anyone from
anyplace at any time, and then "we'll put in advanced monitoring t= o
block activity."

See "=A0Security,= Borders, and the elimination of NAT" section on page 5.
---
=A0 =A0 =A0 [RFC6092] provides recommendations for an IPv6 firewall that
=A0 =A0 =A0 applies "limitations on end-= to-end transparency where security
=A0 =A0 = =A0 considerations are deemed important to promote local and Internet
=A0 =A0 =A0 security." =A0The firewall oper= ation is "simple" in that there is an
=A0 =A0 =A0 assumption that traffic which is to be blocked by default = is
=A0 =A0 =A0 defined in the RFC and not expected to be updated by the user o= r
=A0 =A0 =A0 ot= herwise. =A0The RFC also discusses an option for CPEs to have an
=A0 =A0 =A0 option to be put into a "transparent mode" of operati= on.

= =A0 =A0 =A0 It is important to distinguish between addressability and
=
=A0 =A0 =A0 reachability; i.e. =A0IPv6 through use of globally unique addre= ssing
=A0 =A0 =A0 in the home makes all dev= ices potentially reachable from anywhere.
= =A0 =A0 =A0 Whether they are or not should depend on firewall or filtering<= /div>
=A0 =A0 =A0 behaviour, and not the presence or u= se of NAT. ...
---

Does this address you= concerns?

=A0 =A0 Joh= n
--e89a8f647903faf73604af0f2bdf-- From mcr@sandelman.ca Tue Oct 11 17:35:10 2011 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 4FAA621F8CCC for ; Tue, 11 Oct 2011 17:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE9gPGIp7O2N for ; Tue, 11 Oct 2011 17:35:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 75CB621F8CAC for ; Tue, 11 Oct 2011 17:35:09 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 43622343B0; Tue, 11 Oct 2011 20:34:01 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 0EE7698C90; Tue, 11 Oct 2011 20:35:57 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0B93198B2E; Tue, 11 Oct 2011 20:35:57 -0400 (EDT) From: Michael Richardson To: Erik Nordmark In-Reply-To: <4E94829E.2010403@cisco.com> References: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> <4E94829E.2010403@cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 20:35:56 -0400 Message-ID: <17350.1318379756@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org, Lorenzo Colitti , Jari Arkko , curtis@occnc.com Subject: Re: [homenet] Homenet strawman slides 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, 12 Oct 2011 00:35:10 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Erik" =3D=3D Erik Nordmark writes: >> Erik, >>=20 >> I really don't know how many support calls are just the consumer >> plugging the computer into the wrong Ethernet port on the NAT box >> and the uplink on the other port and then not being able to >> figure out what is wrong. All the cables fit in the connector. >> It should work! Erik> It sure would be good to try to find some data on this. But, for many many years, ISPs did not support having a sharing device. Not that they do, ISP insist that the box be *their* box, and as that box is sometimes broken, limited, etc. the customer has to provide their own. Again, if the ISP is called, it's "not their problem". Erik> While I can see that we can build the internals of the home Erik> network with devices without a designated uplink Erik> (automatically configure prefixes, the routing protocol etc), Erik> what I don't understand is how the connectivity to the ISP Erik> would happen. Erik> How do you see that working? Will each router try the Erik> protocols it would use against the ISP (PPPOE, DHCP PD, etc) Erik> on every port? Or on every port where it doesn't find a OSPF Erik> (or whatever home routing protocol we choose) neighbor? Or Erik> does the user have to configure the Customer Edge Router to Erik> say "port eth0 is the WAN port?" Basically what you suggest. For Cable and any access link that uses DHCP and Ethernet directly, the fact that you get a DHCP with a PD is a clue that this is the WAN link. For DSL using PPPoE (those who pay a bit more can have DSL without PPPoE), then a username/password is required, and yes, the user has to configure this.=20=20 However. in many cases, this is pre-configured by the ISP, as the "router" and DSL modem is combined into a single box. Often this also means that you can't plug it in wrong, as the uplink is an RJ11 rather than RJ45. Erik> I don't think arbitrarily stupid way can possibly work, since Erik> that doesn't ensure that the home network is internally Erik> connected. If the user connects three routers in the den Erik> together, but those are not connect to the rest of the house, Erik> then no protocol we come up with can fix that. a) That's okay, because the three routers in the Den plugged in that way won't affect the router in the basement which is doing fine. b) Actually, the three routers in the Den might see the wifi from the basement, and might join it. Erik> Supporting arbitrary topology (as opposed to just trees) is Erik> good in that it enables redundant internal topologies. But Erik> getting to a redundant topology requires a deeper knowledge by Erik> the users than mandating a tree. More rope. Doesn't mean it is Erik> simpler for the users. It's not enough to support only a tree. It is way too easy to wind up with loops without really intending it. My laptop has four interfaces: wir= ed, wireless, USB ethernet (to mobile phone), and internal bridge to a VM. Similarily, my phone has three interfaces: USB ethernet, wifi, and 3G. So my laptop and phone can instantly create two links: wifi and USB. My phone + AP + laptop can also have a loop via wifi + wired.=20=20 I don't need all these links up, but I really do want these devices smart enough to just bring up connectivity whenever they can. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpTg7ICLcPvd0N1lAQKD/Af/WGANXsyxilwqjD4rOpeZxTCDwrKAcqHL kLkBcoXuoDLylUiU/OZRFaFmSsReYGw7X+2OxqWQ8C9c/vXcDpYoGQHKsaIjGD0Q 6K+q5n0wzjFMZ3lIOoke4ycXXhmvzD4LZmZIBnqLQJK2WDnEtOUf3nVv0xM9hEWb rnPp2AEZfBd00I26KVIg2SKHevb9uKv84iAHMmKn3ZQTleGLl7hjQvQFLIpxidZ1 9lmishMidoLJIQhy51RRGofAjaT+W7+yftii0FTZpgTWKkhRrXAkuacBPLvOc2L2 jIOM85LyBCFPk4w2+IVdKke0CyGNDD4HiFiA3Jv/1mRexWOtbHCJog== =FVhr -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Oct 11 17:38:10 2011 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 8B49421F8C1C for ; Tue, 11 Oct 2011 17:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzh2n40X4DCu for ; Tue, 11 Oct 2011 17:38:10 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4921F8C19 for ; Tue, 11 Oct 2011 17:38:10 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id BF0A93439E for ; Tue, 11 Oct 2011 20:37:05 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 5DC7F98C90; Tue, 11 Oct 2011 20:38:59 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5AE7298B2E for ; Tue, 11 Oct 2011 20:38:59 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4E948FE9.8050101@riw.us> References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> <12544.1318343246@marajade.sandelman.ca> <4E948FE9.8050101@riw.us> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 20:38:59 -0400 Message-ID: <17786.1318379939@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Thoughts about routing 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, 12 Oct 2011 00:38:10 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Russ" =3D=3D Russ White writes: Russ> You need a unique identifier at the equipment level for Russ> anything you intend to auto-configure --autoconfiguring Russ> uniqueness is a very hard, probably impossible, problem on a Russ> global scale. So we need to count on this one thing, no matter Russ> what else we might need to back in to. Russ> Now, it might be possible to some hash over a GPS location for Russ> a "base," and then add on MAC addresses, or some such, but We've assumed a unique MAC, which is 48 bits long.=20 But OSPF router-id is 32 bits. What is the likelyhood of a collision=20 in the bottom 32-bits of the MAC?=20 =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpTho4CLcPvd0N1lAQIxPAgAoziCfHSLYwlnOl2lr9MWrZPfdWM00Xn9 q0BQTabX4zMBDDA6BOES9I3kOAlcqNfe07PWLcw0I9lGvagIdllwkh8LJYL37N+I nC+/GENbvodenz61wwEPNd6xmfWfTH2TlPCTySn2fa3Ryhf2/qETyR1aQ323xbgX PREUFgzWCkpfxleF5i9DKgUXurbGQ1XXmdmKgubnoEYiaC0abWYOVF9DO8ntn2mw F0Mzow89sG+3MYucy8N9VbaUWLVhcLSlvSiQ5GluFKofD73wtxYZ8U1Ch3PweaQH Ri79w3Azu7T6tuU1REuH971G6kfjuuos+jnpYopJEi/sVD4NN3KkWQ== =MPd/ -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Oct 11 18:02:50 2011 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 6DB5221F8CAC for ; Tue, 11 Oct 2011 18:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dHGZOlbIg5A for ; Tue, 11 Oct 2011 18:02:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0621F8C97 for ; Tue, 11 Oct 2011 18:02:50 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id AFB16343B1 for ; Tue, 11 Oct 2011 21:01:45 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 7A86F98C90; Tue, 11 Oct 2011 21:03:41 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 7757798B2E for ; Tue, 11 Oct 2011 21:03:41 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4E94BF91.4060807@cs.tcd.ie> References: <4E94BF91.4060807@cs.tcd.ie> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 21:03:41 -0400 Message-ID: <21171.1318381421@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 01:02:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Stephen" =3D=3D Stephen Farrell writes: Stephen> I've been reading the list with interest and have a question. Stephen> When various devices in the home figure out which does what, Stephen> and do that periodically to handle changes, there's clearly Stephen> the potential that a zombied host tries to try take over Stephen> stuff with undesirable consequences. We have throught about this. Stephen> My question is whether this group are planning to think Stephen> about that now, or later, or never? (Or don't even think Stephen> there's a problem worth attempting to address.) We think that the most sophisticated security we can hope for is that all pieces of equipment can be provided with a "network password" For devices which have WIFI, this will essentially be the WPA/PSK key, but used to key other protocols as well. However, I am thinking that we can perhaps bootstrap equipment that has never been configured (or has been factory reset) in some fashion such that if the equipment is "virginal" that it can essentially always try some default keys, and bring up enough networking to let all equipment be discovered and identified. There would be strong nag screens to get the user to up a network password. At this point, I think that many users are used to having a network password.=20 Stephen> Note - I'm not trying to argue for any particular level of Stephen> security and certainly not for some unachievable fort knox Stephen> everywhere, I'm just asking what's the plan? I agree: we need something. It needs to be just enough, and it's okay if there are ways of subverting the system if you have physical access. Having said that, I'd like to see optional (MAY) support for stronger systems, for the Bill Gates-type/Yari Arko-type home... --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpTnbYCLcPvd0N1lAQJ5Fwf/UFQKhtdgu8UXLZ6T3SDyBRH01OC4nwAY 77azqqh6HH3cS/1lFfow2/uLiJglfYbIiyjZkd/ggg4H9W9wHVOASaVjaNvldo69 mjHR4Wj3OOxWkaLgCMLTnai8BJ/yPq0Q5BxSuuJcJNByV4Bhm9LIDjv2W+bTCUJ/ Ah2P1nwIN/Ep6aQgnvP4amUhdErNbcLTlMbFnRj+0wDhyU+VX59lR8yUNoTxRqms lMr7gfazceijyQEX30rw+ba0hUwhloYeEIhcO5v3JxdBnQNKuGU5TWfxSHLFcGWY i/LwuH/EOeKorDJOSFoqPRL7qvP1TBeZbJY7KAPGSSl1hWKL+z1zdA== =QXTS -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Tue Oct 11 18:38:24 2011 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 D026621F8C74 for ; Tue, 11 Oct 2011 18:38:24 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMmciJmOK0ne for ; Tue, 11 Oct 2011 18:38:24 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 55AF421F8C6F for ; Tue, 11 Oct 2011 18:38:24 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:352c:8c39:dcd2:575d] (unknown [IPv6:2001:470:1f07:1486:352c:8c39:dcd2:575d]) by toccata.fugue.com (Postfix) with ESMTPSA id 4C89E2381E5A; Tue, 11 Oct 2011 21:38:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_0E59E890-DD91-4EF5-B94D-92832CFD999A" From: Ted Lemon In-Reply-To: <21171.1318381421@marajade.sandelman.ca> Date: Tue, 11 Oct 2011 21:38:18 -0400 Message-Id: <159DBF45-107C-4C12-AE01-9BB494E8EEAE@fugue.com> References: <4E94BF91.4060807@cs.tcd.ie> <21171.1318381421@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1244.3) Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 01:38:24 -0000 --Apple-Mail=_0E59E890-DD91-4EF5-B94D-92832CFD999A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: > However, I am thinking that we can perhaps bootstrap equipment that = has > never been configured (or has been factory reset) in some fashion such > that if the equipment is "virginal" that it can essentially always try > some default keys, and bring up enough networking to let all equipment > be discovered and identified. There would be strong nag screens to = get > the user to up a network password. A pre-shared key that is pre-shared to every device is the same as no = key. So you might as well not bother with that complexity. = Conceivably CGA could be used to publish public/private key pairs = allowing devices to automatically recognize each other and present their = relationships in a UI for the end user to approve, but that's not = precisely plug and play. I think the simplest thing would be to require that each device be able = to talk to a USB drive. Each device collects all the public keys on = the USB drive, and stores their own there. Devices then share their = public key with other devices identified on the USB drive, so that as = each device joins the network, the other devices learn about it. This = isn't bulletproof=97an infected PC that's configured with these keys = could be used to gain access to the keys, for example. But it's a lot = better than a well-known key. Of course, this isn't quite as plug and play as you seem to want, and it = requires that each device have a USB port, which might not be = acceptable. Plus, it would mean that the IETF would have to talk about = hardware, which seems like a bit of a non-starter. But I think it's = the right way to solve the problem. --Apple-Mail=_0E59E890-DD91-4EF5-B94D-92832CFD999A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 However, I am = thinking that we can perhaps bootstrap equipment that has
never been = configured (or has been factory reset) in some fashion such
that if = the equipment is "virginal" that it can essentially always try
some = default keys, and bring up enough networking to let all equipment
be = discovered and identified.  There would be strong nag screens to = get
the user to up a network = password.

A pre-shared key that is = pre-shared to every device is the same as no key.   So you might as = well not bother with that complexity.   Conceivably CGA could be = used to publish public/private key pairs allowing devices to = automatically recognize each other and present their relationships in a = UI for the end user to approve, but that's not precisely plug and = play.

I think the simplest thing would be to = require that each device be able to talk to a USB drive.   Each = device collects all the public keys on the USB drive, and stores their = own there.   Devices then share their public key with other devices = identified on the USB drive, so that as each device joins the network, = the other devices learn about it.   This isn't bulletproof=97an = infected PC that's configured with these keys could be used to gain = access to the keys, for example.   But it's a lot better than a = well-known key.

Of course, this isn't quite as = plug and play as you seem to want, and it requires that each device have = a USB port, which might not be acceptable.   Plus, it would mean = that the IETF would have to talk about hardware, which seems like a bit = of a non-starter.   But I think it's the right way to solve the = problem.

= --Apple-Mail=_0E59E890-DD91-4EF5-B94D-92832CFD999A-- From joelja@bogus.com Tue Oct 11 18:45:27 2011 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 9892921F86A1 for ; Tue, 11 Oct 2011 18:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99yT7A6iTxdx for ; Tue, 11 Oct 2011 18:45:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8B921F867F for ; Tue, 11 Oct 2011 18:45:27 -0700 (PDT) Received: from zorch.lan (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 p9C1jD00051163 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 12 Oct 2011 01:45:14 GMT (envelope-from joelja@bogus.com) Message-ID: <4E94F129.8020205@bogus.com> Date: Tue, 11 Oct 2011 18:45:13 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4E94BF91.4060807@cs.tcd.ie> <21171.1318381421@marajade.sandelman.ca> <159DBF45-107C-4C12-AE01-9BB494E8EEAE@fugue.com> In-Reply-To: <159DBF45-107C-4C12-AE01-9BB494E8EEAE@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 12 Oct 2011 01:45:14 +0000 (UTC) Cc: homenet@ietf.org, Michael Richardson Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 01:45:27 -0000 On 10/11/11 18:38 , Ted Lemon wrote: > On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: >> However, I am thinking that we can perhaps bootstrap equipment that has >> never been configured (or has been factory reset) in some fashion such >> that if the equipment is "virginal" that it can essentially always try >> some default keys, and bring up enough networking to let all equipment >> be discovered and identified. There would be strong nag screens to get >> the user to up a network password. > > A pre-shared key that is pre-shared to every device is the same as no > key. Not really, it could serve an important hygenic function, notionaly, it could be filtered by default on all non-home-network gear. that is serves the purpose of identifying a well-known-service. there are of course other perhaps better ways to implment that. > So you might as well not bother with that complexity. > Conceivably CGA could be used to publish public/private key pairs > allowing devices to automatically recognize each other and present their > relationships in a UI for the end user to approve, but that's not > precisely plug and play. > > I think the simplest thing would be to require that each device be able > to talk to a USB drive. Each device collects all the public keys on > the USB drive, and stores their own there. Devices then share their > public key with other devices identified on the USB drive, so that as > each device joins the network, the other devices learn about it. This > isn't bulletproof—an infected PC that's configured with these keys could > be used to gain access to the keys, for example. But it's a lot better > than a well-known key. > > Of course, this isn't quite as plug and play as you seem to want, and it > requires that each device have a USB port, which might not be > acceptable. Plus, it would mean that the IETF would have to talk about > hardware, which seems like a bit of a non-starter. But I think it's > the right way to solve the problem. > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From ulrich@herberg.name Tue Oct 11 20:01:53 2011 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 EB3C221F8B72 for ; Tue, 11 Oct 2011 20:01:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB9TiNNxPCyt for ; Tue, 11 Oct 2011 20:01:53 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D81C21F8B3E for ; Tue, 11 Oct 2011 20:01:52 -0700 (PDT) Received: by bkbzv3 with SMTP id zv3so104421bkb.31 for ; Tue, 11 Oct 2011 20:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=kYzUC/+ZucQwAufeDla1T1ibJ9vQkdHkWNW+gbxxpI4=; b=bMN72vIYAD1/hmQXG43gI+W5OfmxkOWZJGsr803DaDCLECx3ntj2Ab5CRbsJ/sYVHR sKqgjSqYa/Mlx88vWqtIdH+PnOYzUgsv7y0HCVuK6XjvKrNXsUr6VgJ1UfxgApOqbl6A HTXVzfzEembniLndNp9pjzYPjT93e0u0mwLqo= Received: by 10.223.62.16 with SMTP id v16mr45217015fah.35.1318388510243; Tue, 11 Oct 2011 20:01:50 -0700 (PDT) Received: from h151.tum.vpn.lrz.de (h151.tum.vpn.lrz.de. [129.187.173.151]) by mx.google.com with ESMTPS id h16sm1208170fab.19.2011.10.11.20.01.47 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 20:01:49 -0700 (PDT) Message-ID: <4E950318.8000109@herberg.name> Date: Wed, 12 Oct 2011 11:01:44 +0800 From: Ulrich Herberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E9494A9.4030901@freedesktop.org> In-Reply-To: <4E9494A9.4030901@freedesktop.org> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Thoughts about routing - trends 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, 12 Oct 2011 03:01:54 -0000 Hi Jim, I fully agree with you. Declaring OLSRv2 etc. out of scope just because "a home is not a mesh network" seems simplistic to me. As you explained in your mail, many of the problems that mesh networks already solve successfully today, can be very similar in a home: dynamic topology, no skilled network operator centrally managing the devices, wireless and wired devices, limited resources on the routers etc. These were exactly the motivation for developing such protocols in MANET. Best regards Ulrich On 10/12/11 3:10 AM, Jim Gettys wrote: > On 10/07/2011 03:48 AM, Fred Baker wrote: >> 4) The use of OLSR in mesh network scenarios >> >> Jim Gettys commented on the fact of OLSR use. The general sense of the room was that OLSRv2 is interesting but out of scope for this discussion as mesh networks are quite different from typical residential and SOHO networks. >> > Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my > area of expertise. > > Babel/BabelZ is appearing in CeroWrt today as the people who are > interested in such things are doing the work (we don't need a routing > protocol in the simple single home router case), and it provided the > functionality we needed. > > For those who want something else, quagga is in the CeroWrt build for > your hacking pleasure. > > And I'm not advocating the homenet working group do anything unusual > about routing at this date; as I said, it's not my area of expertise. > > Having said this, I do note the following technological trends: > > 1) As soon as we get real "plug and play" routers that don't need manual > configuration that work, we'll see a lot more routers in a home > environment. Other radio technologies (e.g. zigbee) may encourage this > trend. It seemed like the working group agreed that getting to the > point that just hooking things together would really "just worked" was a > fundamental requirement (and I agree entirely with this sentiment, as it > reflects reality of what already happens in the homes of hackers and > non-hackers alike). > > 2) wireless is much cheaper to implement than wired networking, > particularly in most houses where pulling cable is hard. I know this > first hand, where I've pulled a lot of cat 6 and wish I could get it to > places I don't have it. > > Unless power line networking really works, I believe that this trend > isn't going to change. Is there any progress in this area? I've seen > many promises, and few reliable working products. > > 3) As soon as you have two routers, you have at least two paths; the > wired connection between them and the wireless. You may have 3 paths, > if you have both 2.4 and 5ghz radios. Frequency diversity routing > becomes immediately interesting, along with using your ethernet when > it's available in preference to wireless. > > 4) an apartment building look like a mesh, and possibly with multiple > backhauls possibly with multiple ISP's. One should at least think about > what happens when you have "homes", in such a building, and make sure > nothing breaks. Wireless is messy: it isn't limited to where a wire > goes. Taking down an entire apartment building/blocks/city would not be > fun. I know, I've been there (at least to the point of taking down > buildings, and came within a week of a much larger scale disaster). > > If you believe 1 + 2 + 3 +4 (as I do), then if you look a few years > out, you end up with something in the "home" that begins to resemble > very strongly what the community mesh networking folks are doing at a > higher scale geographically and in terms of # of nodes today, with > many/most of the same concerns and solutions. Understanding the problems > they've faced/are facing is therefore worth a bit of investment; Radio > diversity is one of the concerns, and interference (of various sorts). > > Julius' talk about why frequency diversity is an issue is here: > > http://www.youtube.com/watch?v=1VNzm0shSA8 > > While the issues outlined above are not where home networking is today, > my gut feel is they will be in five years. > > If there is *anything* I can urge on the group, is to respect the > scaling problems that can/will occur, and to internalise wireless > !=wired: wireless goes where wireless goes and does not behave like > ethernet. The group needs to ensure nothing "bad" happens when people > start building systems in ways you don't expect, particularly in an > apartment building. The challenge is balancing the reality of how > wireless works, with "just works" automatic configuration, with "fail > safe" behaviour. > - Jim > > > > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From ulrich@herberg.name Tue Oct 11 20:14:46 2011 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 7715F21F8C8C for ; Tue, 11 Oct 2011 20:14:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dM-rMIv6eJj for ; Tue, 11 Oct 2011 20:14:45 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B16C21F8C8A for ; Tue, 11 Oct 2011 20:14:45 -0700 (PDT) Received: by bkbzv3 with SMTP id zv3so114929bkb.31 for ; Tue, 11 Oct 2011 20:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3dUuXZaMdjmju9XgYHZZViEXTDaXKE9vlwCLWaZZfl8=; b=ZXK6VSuMAKHvQCLd0wS8G2/jIJSMZ8byHXSSyNIAKNqHDs8SEnsBqCXhTDdtD9A+ft R6p6hVWsSXH2n1qIGengAJ6YDQkBFKWu9e7LAohgxy7hTigq3xuDGQah+kH5FYS6T+S6 YEswrjF7haAwhb3517JxAf19wjRoPobmhCrac= Received: by 10.223.1.131 with SMTP id 3mr45119091faf.30.1318389284316; Tue, 11 Oct 2011 20:14:44 -0700 (PDT) Received: from h151.tum.vpn.lrz.de (h151.tum.vpn.lrz.de. [129.187.173.151]) by mx.google.com with ESMTPS id k26sm1234083fab.12.2011.10.11.20.14.41 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 20:14:43 -0700 (PDT) Message-ID: <4E95061C.7040108@herberg.name> Date: Wed, 12 Oct 2011 11:14:36 +0800 From: Ulrich Herberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> <12544.1318343246@marajade.sandelman.ca> <4E948FE9.8050101@riw.us> <17786.1318379939@marajade.sandelman.ca> In-Reply-To: <17786.1318379939@marajade.sandelman.ca> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [homenet] Thoughts about routing 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, 12 Oct 2011 03:14:46 -0000 Hi, On 10/12/11 8:38 AM, Michael Richardson wrote: >>>>>> "Russ" =3D=3D Russ White writes: > Russ> You need a unique identifier at the equipment level for > Russ> anything you intend to auto-configure --autoconfiguring > Russ> uniqueness is a very hard, probably impossible, problem on a > Russ> global scale. So we need to count on this one thing, no matte= r > Russ> what else we might need to back in to. > > Russ> Now, it might be possible to some hash over a GPS location fo= r > Russ> a "base," and then add on MAC addresses, or some such, but > > We've assumed a unique MAC, which is 48 bits long.=20 > But OSPF router-id is 32 bits. What is the likelyhood of a collision= =20 > in the bottom 32-bits of the MAC?=20 It seems to me that this discussion about duplicate addresses / unique MAC tool already place in the IETF a number of years ago, e.g. as reflected in RFC 4862 (IPv6 Stateless Autoconfiguration, section 5.4), where duplicate address detection is mandatory. It wouldn't have to be if the assumption holds that all MAC addresses are unique. Even though the probability of collisions may be low, because of manufacturer errors / virtual interfaces and virtual machines / reduction from 48bits to 32bits, there could be collisions. I am not convinced that we can make Russ' assumption that we need unique identifiers at equipment level (or at least that seems inconsistent with previous IETF decisions, so we would need to make a strong case what has changed since then). I do agree with Russ, though, that verifying uniqueness is hard. Regards Ulrich From ulrich@herberg.name Tue Oct 11 20:28:54 2011 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 1997721F8CA8 for ; Tue, 11 Oct 2011 20:28:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qOBX3f9GSbP for ; Tue, 11 Oct 2011 20:28:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 335CC21F8CA6 for ; Tue, 11 Oct 2011 20:28:53 -0700 (PDT) Received: by eyg24 with SMTP id 24so288967eyg.31 for ; Tue, 11 Oct 2011 20:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=negJ4W+LY/I739+s0uSVQCzZc01AS0vnTEJuy/6w//I=; b=B4cF4TlYXFRQ0YNXNQRfeMKOj3BOMeQuAa7FIdMRQGZFw8BBd36ibwX1uEAjdy88Z8 eE0hfK8WJ7VqHOJ/7h6WVagkaW0KhqYmcXQlIlP7BmYxntAwQ8OIHGiYcqKFPkZRYseI eUAlqUTF0KYFu66MvmuDLvnSJ1Bo9didXh7VE= Received: by 10.223.5.3 with SMTP id 3mr43795718fat.4.1318390132312; Tue, 11 Oct 2011 20:28:52 -0700 (PDT) Received: from h151.tum.vpn.lrz.de (h151.tum.vpn.lrz.de. [129.187.173.151]) by mx.google.com with ESMTPS id f25sm1273729faf.7.2011.10.11.20.28.49 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 20:28:51 -0700 (PDT) Message-ID: <4E95096E.5020907@herberg.name> Date: Wed, 12 Oct 2011 11:28:46 +0800 From: Ulrich Herberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> In-Reply-To: <4E93C075.30400@piuha.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Thoughts about routing 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, 12 Oct 2011 03:28:54 -0000 Jari, On 10/11/11 12:05 PM, Jari Arkko wrote: > Home routers would also have MAC addresses, but again, if we need a > 32-bit quantity then shortened 48/64 bit identifiers may > (theoretically) have collisions. > > That being said, if the home routers have to discover their IPv6 > prefix through a protocol and store it in flash, they could probably > do so also for a router ID. Unless there was some chicken and egg > problem that required the router ID for all this discovery to work... I agree. Since we need to configure unique prefixes to each router in the home anyway, it should not be any problem to do the same for a router ID (or even just use an address from the configured prefix as router ID, which should then be unique). A while ago, there were some plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop network for configuring prefixes in the network. As in a home network, I assume there is always at least one border router with the global prefix, specifying something like that seems to be reasonable for me (in a MANET, that can be more difficult, because there is not necessarily such a central entity as the border router). Regards Ulrich From c.chauvenet@watteco.com Wed Oct 12 00:45:07 2011 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 DF21521F8A6F for ; Wed, 12 Oct 2011 00:45:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CP4JyZ2L7Me for ; Wed, 12 Oct 2011 00:45:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0784421F8C65 for ; Wed, 12 Oct 2011 00:45:06 -0700 (PDT) Received: from mail18-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Oct 2011 07:45:06 +0000 Received: from mail18-ch1 (localhost.localdomain [127.0.0.1]) by mail18-ch1-R.bigfish.com (Postfix) with ESMTP id D8F5FC203D8; Wed, 12 Oct 2011 07:45:05 +0000 (UTC) X-SpamScore: -35 X-BigFish: VPS-35(zzbb2dK9371Kc89bh1432N98dKzz1202hzz1033ILc704dh8275bh8275dhz2dh2a8h668h839h8aah946h) X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB016.red002.local; RD:none; EFVD:NLI X-FB-SS: 0,13, Received: from mail18-ch1 (localhost.localdomain [127.0.0.1]) by mail18-ch1 (MessageSwitch) id 131840547553186_1504; Wed, 12 Oct 2011 07:44:35 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail18-ch1.bigfish.com (Postfix) with ESMTP id F24DE18D804F; Wed, 12 Oct 2011 07:44:34 +0000 (UTC) Received: from IE2RD2HUB016.red002.local (213.199.187.153) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 12 Oct 2011 07:44:34 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB016.red002.local ([10.43.198.14]) with mapi; Wed, 12 Oct 2011 00:44:03 -0700 From: C Chauvenet To: Jim Gettys Date: Wed, 12 Oct 2011 00:44:02 -0700 Thread-Topic: [homenet] Thoughts about routing - trends Thread-Index: AcyIsrZ1ezmHf1KqTzC56cwzeF5S/g== Message-ID: References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E9494A9.4030901@freedesktop.org> In-Reply-To: <4E9494A9.4030901@freedesktop.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: Thomas Narten , "homenet@ietf.org" , "homenet-ads@tools.ietf.org" , Fred Baker Subject: Re: [homenet] Thoughts about routing - trends 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, 12 Oct 2011 07:45:08 -0000 Hi Jim,=20 I agree with you. Let me just add a few words on #2 :=20 You are absolutely right that pulling cable is hard and expensive. That is the rationale of PLC : Using existing wires. PLC is already used reliabily for high speed networking, but you are correc= t that it is not as popular as Wireless. Mostly because networking devices already embed= a Wifi and/Or Ethernet interface, rather than a PLC interface.=20 So people don't see the need of buying additional material for a connectivi= ty they already have=85 Though people use PLC because they feel surrounded by RF, or they cannot re= ach some point of the network with wireless,=20 or the PLC device is provided by their ISP (like in France). (There are others reasons for using PLC outside the home, but I think it is= out of the scope of Homenet). PLC also suffers from a lack of standardization, and different technologies= /Standards are often non-interoperable, or simply cannot coexist on the sam= e electrical grid. An effort is ongoing in IEEE P1901.2 to create a standard for low frequency= narrowband PLC. Just my 2 cts, C=E9dric. Le 11 oct. 2011 =E0 21:10, Jim Gettys a =E9crit : > On 10/07/2011 03:48 AM, Fred Baker wrote: >> 4) The use of OLSR in mesh network scenarios=20 >>=20 >> Jim Gettys commented on the fact of OLSR use. The general sense of the r= oom was that OLSRv2 is interesting but out of scope for this discussion as = mesh networks are quite different from typical residential and SOHO network= s. >>=20 > Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my > area of expertise.=20 >=20 > Babel/BabelZ is appearing in CeroWrt today as the people who are > interested in such things are doing the work (we don't need a routing > protocol in the simple single home router case), and it provided the > functionality we needed. >=20 > For those who want something else, quagga is in the CeroWrt build for > your hacking pleasure. >=20 > And I'm not advocating the homenet working group do anything unusual > about routing at this date; as I said, it's not my area of expertise. >=20 > Having said this, I do note the following technological trends: >=20 > 1) As soon as we get real "plug and play" routers that don't need manual > configuration that work, we'll see a lot more routers in a home > environment. Other radio technologies (e.g. zigbee) may encourage this > trend. It seemed like the working group agreed that getting to the > point that just hooking things together would really "just worked" was a > fundamental requirement (and I agree entirely with this sentiment, as it > reflects reality of what already happens in the homes of hackers and > non-hackers alike). >=20 > 2) wireless is much cheaper to implement than wired networking, > particularly in most houses where pulling cable is hard. I know this > first hand, where I've pulled a lot of cat 6 and wish I could get it to > places I don't have it. >=20 > Unless power line networking really works, I believe that this trend > isn't going to change. Is there any progress in this area? I've seen > many promises, and few reliable working products. >=20 > 3) As soon as you have two routers, you have at least two paths; the > wired connection between them and the wireless. You may have 3 paths, > if you have both 2.4 and 5ghz radios. Frequency diversity routing > becomes immediately interesting, along with using your ethernet when > it's available in preference to wireless. >=20 > 4) an apartment building look like a mesh, and possibly with multiple > backhauls possibly with multiple ISP's. One should at least think about > what happens when you have "homes", in such a building, and make sure > nothing breaks. Wireless is messy: it isn't limited to where a wire > goes. Taking down an entire apartment building/blocks/city would not be > fun. I know, I've been there (at least to the point of taking down > buildings, and came within a week of a much larger scale disaster). >=20 > If you believe 1 + 2 + 3 +4 (as I do), then if you look a few years > out, you end up with something in the "home" that begins to resemble > very strongly what the community mesh networking folks are doing at a > higher scale geographically and in terms of # of nodes today, with > many/most of the same concerns and solutions. Understanding the problems > they've faced/are facing is therefore worth a bit of investment; Radio > diversity is one of the concerns, and interference (of various sorts). >=20 > Julius' talk about why frequency diversity is an issue is here: >=20 > http://www.youtube.com/watch?v=3D1VNzm0shSA8 >=20 > While the issues outlined above are not where home networking is today, > my gut feel is they will be in five years. >=20 > If there is *anything* I can urge on the group, is to respect the > scaling problems that can/will occur, and to internalise wireless > !=3Dwired: wireless goes where wireless goes and does not behave like > ethernet. The group needs to ensure nothing "bad" happens when people > start building systems in ways you don't expect, particularly in an > apartment building. The challenge is balancing the reality of how > wireless works, with "just works" automatic configuration, with "fail > safe" behaviour. > - Jim >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From ot@cisco.com Wed Oct 12 00:49:32 2011 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 9443F21F8C6C for ; Wed, 12 Oct 2011 00:49:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eifs1J6cqXz3 for ; Wed, 12 Oct 2011 00:49:32 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id DFB7B21F8C66 for ; Wed, 12 Oct 2011 00:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=253; q=dns/txt; s=iport; t=1318405772; x=1319615372; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ygsFBi93ZLcL+nO/2I+QxspwQVqJ/hg8PP/238WXZPE=; b=Nhbm2u1HkLIBlX1wnVrLVdrAWAJd0hRZ1OSciGS1lF4YABe8qkjlQSnG lsTFN3b/9QtPC/+FuKLP5qeeekQ1zMSSEXh1zUnOJx7RvwgR3zYU68+VK +jWEezxb4FVViAdzQ6llZx8YLilwREin2yTUhEEwsuTQ2maBI6hXfg1z3 M=; X-IronPort-AV: E=Sophos;i="4.69,333,1315180800"; d="scan'208";a="839015" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 12 Oct 2011 07:49:31 +0000 Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com [64.103.53.235]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9C7nUSP022581; Wed, 12 Oct 2011 07:49:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E94829E.2010403@cisco.com> Date: Wed, 12 Oct 2011 09:49:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D9E4CFB-42F7-4397-98FC-9740F69E11A5@cisco.com> References: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> <4E94829E.2010403@cisco.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Lorenzo Colitti , Jari Arkko , curtis@occnc.com Subject: Re: [homenet] Homenet strawman slides 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, 12 Oct 2011 07:49:32 -0000 Erik, btw, "border discovery" needs to be done regardless of topology or = prefix assignment solution choice. on a border you (may) want firewall on, you want a ULA border, you want = a organisational or site multicast border... cheers, Ole= From framefritti@gmail.com Wed Oct 12 01:38:01 2011 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 2556221F8BF3 for ; Wed, 12 Oct 2011 01:38:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8Vnw6tPN+8g for ; Wed, 12 Oct 2011 01:38:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44DE821F8BA0 for ; Wed, 12 Oct 2011 01:38:00 -0700 (PDT) Received: by ggnk3 with SMTP id k3so560871ggn.31 for ; Wed, 12 Oct 2011 01:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XC4YWbuN0E/UaE0iOHZy30Z+1jkS45pV2OYs7CjQA+w=; b=nTDvK2X4vskFE66s0eN2bmLIANvLcc0tkroxQWK/Ji8Akuva8N4CiyGJkW2DMDjxng dlhmhsdnRsiX9y+v4Oc0BD++D7oa+BzEQIRrEWi5EJNn3F76bSDkH7FS7c5+orTYP5/Z zKYVya1nA9j/TZDnfWrqTxD4syPICAnFnsGlI= MIME-Version: 1.0 Received: by 10.100.213.16 with SMTP id l16mr5241169ang.72.1318408678673; Wed, 12 Oct 2011 01:37:58 -0700 (PDT) Received: by 10.100.104.6 with HTTP; Wed, 12 Oct 2011 01:37:58 -0700 (PDT) In-Reply-To: <4E94F129.8020205@bogus.com> References: <4E94BF91.4060807@cs.tcd.ie> <21171.1318381421@marajade.sandelman.ca> <159DBF45-107C-4C12-AE01-9BB494E8EEAE@fugue.com> <4E94F129.8020205@bogus.com> Date: Wed, 12 Oct 2011 10:37:58 +0200 Message-ID: From: Riccardo Bernardini To: homenet@ietf.org Content-Type: multipart/alternative; boundary=00504502b8e4f60b9d04af15f04d Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 08:38:01 -0000 --00504502b8e4f60b9d04af15f04d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2011/10/12 Joel jaeggli > On 10/11/11 18:38 , Ted Lemon wrote: > > On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: > >> However, I am thinking that we can perhaps bootstrap equipment that ha= s > >> never been configured (or has been factory reset) in some fashion such > >> that if the equipment is "virginal" that it can essentially always try > >> some default keys, and bring up enough networking to let all equipment > >> be discovered and identified. There would be strong nag screens to ge= t > >> the user to up a network password. > > > > A pre-shared key that is pre-shared to every device is the same as no > > key. > > Not really, it could serve an important hygenic function, notionaly, it > could be filtered by default on all non-home-network gear. that is > serves the purpose of identifying a well-known-service. there are of > course other perhaps better ways to implment that. > > > So you might as well not bother with that complexity. > > Conceivably CGA could be used to publish public/private key pairs > > allowing devices to automatically recognize each other and present thei= r > > relationships in a UI for the end user to approve, but that's not > > precisely plug and play. > > > > I think the simplest thing would be to require that each device be able > > to talk to a USB drive. Each device collects all the public keys on > > the USB drive, and stores their own there. Devices then share their > > public key with other devices identified on the USB drive, so that as > > each device joins the network, the other devices learn about it. This > > isn't bulletproof=97an infected PC that's configured with these keys co= uld > > be used to gain access to the keys, for example. But it's a lot bette= r > > than a well-known key. > What about ID-based signature? Just improvising (so forgive me for any naivety): the ID of the device coul= d be a triplet (producer-ID, product-ID, serial-number); the "key generator" could be the producer itself (avoiding in this way the key escrow problem related to ID-based cryptography) and a certificate with the public key of the producer could be downloadable from some well-known host (alternatively= , the key of most known producers could be "built in" the device). The authentication procedure would follow the usual challenge scheme: the device receives a challenge string, it appends to it a nonce and signs the result with its private key (hardwired at production time). If the authentication is positive, then you know that you are talking to that type of device, produced by that producer (if you trust the producer is another matter). Of course, this simple scheme would fall to a device-in-the-middl= e attack, but maybe in this context it is not a likely attack. > > > Of course, this isn't quite as plug and play as you seem to want, and i= t > > requires that each device have a USB port, which might not be > > acceptable. Plus, it would mean that the IETF would have to talk abou= t > > hardware, which seems like a bit of a non-starter. But I think it's > > the right way to solve the problem. > > > > > > > > _______________________________________________ > > 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 > --00504502b8e4f60b9d04af15f04d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2011/10/12 Joel jaeggli <joelja@bogus.com>
On 10/11/11 18:38 , Ted Lemon wrote:
> On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
>> However, I am thinking that we can perhaps bootstrap equipment tha= t has
>> never been configured (or has been factory reset) in some fashion = such
>> that if the equipment is "virginal" that it can essentia= lly always try
>> some default keys, and bring up enough networking to let all equip= ment
>> be discovered and identified. =A0There would be strong nag screens= to get
>> the user to up a network password.
>
> A pre-shared key that is pre-shared to every device is the same as no<= br> > key.

Not really, it could serve an important hygenic function, notionaly, = it
could be filtered by default on all non-home-network gear. that is
serves the purpose of identifying a well-known-service. there are of
course other perhaps better ways to implment that.

> =A0So you might as well not bother with that complexity.
> Conceivably CGA could be used to publish public/private key pairs
> allowing devices to automatically recognize each other and present the= ir
> relationships in a UI for the end user to approve, but that's not<= br> > precisely plug and play.
>
> I think the simplest thing would be to require that each device be abl= e
> to talk to a USB drive. =A0 Each device collects all the public keys o= n
> the USB drive, and stores their own there. =A0 Devices then share thei= r
> public key with other devices identified on the USB drive, so that as<= br> > each device joins the network, the other devices learn about it. =A0 T= his
> isn't bulletproof=97an infected PC that's configured with thes= e keys could
> be used to gain access to the keys, for example. =A0 But it's a lo= t better
> than a well-known key.

What = about ID-based signature? =A0

Just improvising (so= forgive me for any=A0naivety): the ID of the device could be a triplet (pr= oducer-ID, product-ID, serial-number); the "key generator" could = be the producer itself (avoiding in this way the key escrow problem related= to ID-based cryptography) and a certificate with the public key of the pro= ducer could be downloadable from some well-known host (alternatively, the k= ey of most known producers could be "built in" the device).=A0

The authentication procedure would follow =A0the usual = challenge scheme: the device receives a challenge string, it appends to it = a nonce and signs the result with its private key (hardwired at production = time). =A0If the authentication is positive, then you know that you are tal= king to that type of device, produced by that producer (if you trust the pr= oducer is another matter). =A0Of course, this simple scheme would fall to a= device-in-the-middle attack, but maybe=A0in this =A0context=A0it is not a = likely attack.

>
> Of course, this isn't quite as plug and play as you seem to want, = and it
> requires that each device have a USB port, which might not be
> acceptable. =A0 Plus, it would mean that the IETF would have to talk a= bout
> hardware, which seems like a bit of a non-starter. =A0 But I think it&= #39;s
> the right way to solve the problem.
>
>
>
> ______________________________= _________________
> 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

--00504502b8e4f60b9d04af15f04d-- From ot@cisco.com Wed Oct 12 01:48:02 2011 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 1B90821F8C34 for ; Wed, 12 Oct 2011 01:48:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-U9EX7YTqVo for ; Wed, 12 Oct 2011 01:48:01 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 603F321F8C14 for ; Wed, 12 Oct 2011 01:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=1501; q=dns/txt; s=iport; t=1318409281; x=1319618881; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eE102rf+njgDgtRb+ayPGMeYottx21COvz+jcqt9aaE=; b=CZ2O7/fCIdSqJ0Wy1V7GYe5V63CV8d44Rc24mRm+Io8n4MhlS2trEViZ DJSzDkNjLp0CTRsv5CrV4Zu1/OHbXv42nLhs+7CJ5MR12JjVzwr7FJuAU xApQ5P6mU++iLkPzGoDj7yz2JSGM8b8Xp6sKYhlVN/8jCuSiqOwevhA6X k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMRTlU6Q/khL/2dsb2JhbABDqCqBBYFTAQEBAwESASc/BQsLRlcGNYdcmWIBnmCGd2EEk3WRVg X-IronPort-AV: E=Sophos;i="4.69,333,1315180800"; d="scan'208";a="844517" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 12 Oct 2011 08:48:00 +0000 Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com [64.103.53.235]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9C8m0bL005239; Wed, 12 Oct 2011 08:48:00 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E94BF91.4060807@cs.tcd.ie> Date: Wed, 12 Oct 2011 10:48:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> References: <4E94BF91.4060807@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 08:48:02 -0000 > I've been reading the list with interest and have a question. >=20 > When various devices in the home figure out which does what, > and do that periodically to handle changes, there's clearly > the potential that a zombied host tries to try take over > stuff with undesirable consequences. >=20 > My question is whether this group are planning to think > about that now, or later, or never? (Or don't even think > there's a problem worth attempting to address.) >=20 > Note - I'm not trying to argue for any particular level of > security and certainly not for some unachievable fort knox > everywhere, I'm just asking what's the plan? can we explore some fundamental principles of how and what we need to = "secure"? using the electricity network as an analogy, can we make a distinction = between "safety" and "security"? the electricity network in the home is somewhat self protecting with = breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged = into it, in any topology, external and internal attacks and so on. I don't think it is the networks job to control who has access to the = pictures of my grandmother or who can print to my printer. that's = application policy. is it the networks job to control who has access to the network? no, I = think that is a layer 2 function. I think homenet should focus on L3. (and be clear on what it expects = from the other layers with regards to security). cheers, Ole From fred@cisco.com Wed Oct 12 01:50:47 2011 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 8F12121F8560 for ; Wed, 12 Oct 2011 01:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et6BfmOc5Hkf for ; Wed, 12 Oct 2011 01:50:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7D06F21F8557 for ; Wed, 12 Oct 2011 01:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=617; q=dns/txt; s=iport; t=1318409444; x=1319619044; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=gp1sqtk00ESrv+7KKyLaomB5eVh3W6yfVSytAzLHDaU=; b=GhghMcpJnZAWW/XqpR6vl3fqpkc57yRs2mX/dDV9J0X3haCBt1whVp1R 41i/nzw2sYQl0ovHjKMhSPdVdvNqNGOgyZaESRFcVkfO+5gBb+nYLo/tj VJVxhPocCUj1bCpxh+nZXlOnecCpWfCBwR+wPuqhYkMg/RWJOo1LXjoS3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMRTlU6tJV2Y/2dsb2JhbABDqCqBBYFTAQEBAwESASc/BQsLNRFXBjWHXJliAZ5ghndhBJN1hSiMSA X-IronPort-AV: E=Sophos;i="4.69,333,1315180800"; d="scan'208";a="27784747" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 12 Oct 2011 08:50:44 +0000 Received: from Freds-Computer.local (rtp-vpn2-218.cisco.com [10.82.240.218]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9C8ohsj025655; Wed, 12 Oct 2011 08:50:43 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 12 Oct 2011 04:50:43 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 12 Oct 2011 04:50:43 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 12 Oct 2011 04:50:34 -0400 Message-Id: <5E02E5EF-B801-44C5-A6A7-FAF17CDBFCBB@cisco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E9494A9.4030901@freedesktop.org> To: C Chauvenet X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , homenet@ietf.org, Jim Gettys Subject: Re: [homenet] Thoughts about routing - trends 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, 12 Oct 2011 08:50:47 -0000 On Oct 12, 2011, at 3:44 AM, C Chauvenet wrote: > You are absolutely right that pulling cable is hard and expensive. Pulling cable is indeed hard and expensive. In my experience, it is the = right thing for some applications, such as TV and my home office. = Personally, I have both wired and wireless throughout the house; my = personal rule is that I use the shared wireless network for activities = that move around, to provide convenience at the expense of consistency = and bandwidth, and wired for things that stand still, to provide stable = bandwidth at the price of a one-time wiring effort.= From stephen.farrell@cs.tcd.ie Wed Oct 12 02:23:47 2011 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 8367021F8922 for ; Wed, 12 Oct 2011 02:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prNndR6HGlTz for ; Wed, 12 Oct 2011 02:23:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id DC88221F886A for ; Wed, 12 Oct 2011 02:23:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 445A4171CEF; Wed, 12 Oct 2011 10:23:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1318411421; bh=1wbmXjcE2YbbXe Nqcy68O1pK46f7Nj8EXn2qrWRnqBg=; b=fTT8iERyK1JikiMTNywHFT8wpRRRNT 7r6sTwJalUU1klEtfGAzkhVh9y9ePDUvgelX9WsCBK/nYIwdvgggyk6LC4qF7rM2 rjDa+1Zzqm0nruSp5AKS/l7IyP26BjucReIp5X2Dy6CG0L0LaNo3W5Ymwbzu/ljZ iVSAw8w693HRq1ML52xMpFIjDV9x1xXTlNEH8aMu63r2QnBKMdePmkxg3WNThXtl 7BwY6l972dM8JHCZ/mDqVbuQtbUZhbGC8+wREp5e9zca++u1vMhubjBiAM0ayjla 5y2MNpvS2T2poqVvee5GVdiW+l4v+AqRVJSsrwxEGnpS69+TjWf2bY6g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ysUwONhPIqOs; Wed, 12 Oct 2011 10:23:41 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DB283171C43; Wed, 12 Oct 2011 10:23:41 +0100 (IST) Message-ID: <4E955C94.3060707@cs.tcd.ie> Date: Wed, 12 Oct 2011 10:23:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ole Troan References: <4E94BF91.4060807@cs.tcd.ie> <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> In-Reply-To: <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 09:23:47 -0000 On 10/12/2011 09:48 AM, Ole Troan wrote: >> I've been reading the list with interest and have a question. >> >> When various devices in the home figure out which does what, >> and do that periodically to handle changes, there's clearly >> the potential that a zombied host tries to try take over >> stuff with undesirable consequences. >> >> My question is whether this group are planning to think >> about that now, or later, or never? (Or don't even think >> there's a problem worth attempting to address.) >> >> Note - I'm not trying to argue for any particular level of >> security and certainly not for some unachievable fort knox >> everywhere, I'm just asking what's the plan? > > can we explore some fundamental principles of how and what we need to "secure"? > > using the electricity network as an analogy, can we make a distinction between "safety" and "security"? > the electricity network in the home is somewhat self protecting with breakers and earthing. > a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks > and so on. > > I don't think it is the networks job to control who has access to the pictures of my grandmother or who can print to my printer. that's application policy. > > is it the networks job to control who has access to the network? no, I think that is a layer 2 function. > > I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security). Reasonable points. However, if the zeroconf stuff provides an easy way for a bad device to take over the homenet and get everything interesting routed via it, that seems like a bad thing. That's really what I was asking about, not application layer security, nor layer 2 (though some layer 2 security can probably help a bit if its turned on). Again, I'm not asking for some complex new scheme to be invented here, I'm just asking whether the group are planning to address this issue and roughly when. (In the hope that the answers are something close to "yes" and "as an integrated part of the work":-) S. From russw@riw.us Wed Oct 12 04:51:52 2011 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 F0EB221F8BC4 for ; Wed, 12 Oct 2011 04:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SVH9DST-t1u for ; Wed, 12 Oct 2011 04:51:52 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 27FA621F851F for ; Wed, 12 Oct 2011 04:51:52 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:54430 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RDxLj-00036U-3S for homenet@ietf.org; Wed, 12 Oct 2011 07:51:51 -0400 Message-ID: <4E957F43.1060207@riw.us> Date: Wed, 12 Oct 2011 07:51:31 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E9494A9.4030901@freedesktop.org> <5E02E5EF-B801-44C5-A6A7-FAF17CDBFCBB@cisco.com> In-Reply-To: <5E02E5EF-B801-44C5-A6A7-FAF17CDBFCBB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Thoughts about routing - trends 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, 12 Oct 2011 11:51:53 -0000 >> You are absolutely right that pulling cable is hard and expensive. > > Pulling cable is indeed hard and expensive. In my experience, it is the right thing for some applications, such as TV and my home office. Personally, I have both wired and wireless throughout the house; my personal rule is that I use the shared wireless network for activities that move around, to provide convenience at the expense of consistency and bandwidth, and wired for things that stand still, to provide stable bandwidth at the price of a one-time wiring effort. I do the same --I pull cable for televisions, and even for locations where a desktop or laptop is going to be sitting on a regular basis. So I think we should expect wired and wireless as the norm, rather than expecting wireless all the time. While I wouldn't want to rule OLSRv2 completely out, I think it should compete head to head with an extended OSPF and an extended IS-IS, or even other efforts afoot. I'd rather see requirements first, and a good solid evaluation of what's available against those requirements, rather than choosing technologies out of the gate. :-) Russ From c.chauvenet@watteco.com Wed Oct 12 04:57:51 2011 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 7C1C021F8C94 for ; Wed, 12 Oct 2011 04:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb6d5lnybuUw for ; Wed, 12 Oct 2011 04:57:51 -0700 (PDT) Received: from VA3EHSOBE007.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id D6FE221F8C41 for ; Wed, 12 Oct 2011 04:57:50 -0700 (PDT) Received: from mail88-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Oct 2011 11:57:50 +0000 Received: from mail88-va3 (localhost.localdomain [127.0.0.1]) by mail88-va3-R.bigfish.com (Postfix) with ESMTP id 12D263900DE; Wed, 12 Oct 2011 11:57:50 +0000 (UTC) X-SpamScore: -26 X-BigFish: VPS-26(zzc89bh1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB020.red002.local; RD:none; EFVD:NLI Received: from mail88-va3 (localhost.localdomain [127.0.0.1]) by mail88-va3 (MessageSwitch) id 1318420669575710_27051; Wed, 12 Oct 2011 11:57:49 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.248]) by mail88-va3.bigfish.com (Postfix) with ESMTP id 8411C26804D; Wed, 12 Oct 2011 11:57:49 +0000 (UTC) Received: from IE2RD2HUB020.red002.local (213.199.187.153) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 12 Oct 2011 11:57:49 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB020.red002.local ([10.43.198.98]) with mapi; Wed, 12 Oct 2011 04:57:33 -0700 From: C Chauvenet To: Russ White Date: Wed, 12 Oct 2011 04:57:32 -0700 Thread-Topic: [homenet] Thoughts about routing - trends Thread-Index: AcyI1iCL2RqPxU6oRlmganhLppXGNA== Message-ID: <679AEC6F-D61A-4EF4-8EE4-3D88E7D218C2@watteco.com> References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E9494A9.4030901@freedesktop.org> <5E02E5EF-B801-44C5-A6A7-FAF17CDBFCBB@cisco.com> <4E957F43.1060207@riw.us> In-Reply-To: <4E957F43.1060207@riw.us> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing - trends 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, 12 Oct 2011 11:57:51 -0000 Le 12 oct. 2011 =E0 13:51, Russ White a =E9crit : >=20 >>> You are absolutely right that pulling cable is hard and expensive. >>=20 >> Pulling cable is indeed hard and expensive. In my experience, it is the = right thing for some applications, such as TV and my home office. Personall= y, I have both wired and wireless throughout the house; my personal rule is= that I use the shared wireless network for activities that move around, to= provide convenience at the expense of consistency and bandwidth, and wired= for things that stand still, to provide stable bandwidth at the price of a= one-time wiring effort. >=20 > I do the same --I pull cable for televisions, and even for locations > where a desktop or laptop is going to be sitting on a regular basis. So > I think we should expect wired and wireless as the norm, rather than > expecting wireless all the time. I agree. I may have precised "pulling *NEW* cable is hard and expensive" in my sente= nce. >=20 > While I wouldn't want to rule OLSRv2 completely out, I think it should > compete head to head with an extended OSPF and an extended IS-IS, or > even other efforts afoot. I'd rather see requirements first, and a good > solid evaluation of what's available against those requirements, rather > than choosing technologies out of the gate. >=20 > :-) I think it is a good process, for each competing protocol. >=20 > Russ C=E9dric. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From russw@riw.us Wed Oct 12 04:58:56 2011 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 AA7F521F8C9F for ; Wed, 12 Oct 2011 04:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4osNYTRubpxx for ; Wed, 12 Oct 2011 04:58:56 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19121F8C41 for ; Wed, 12 Oct 2011 04:58:56 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:54517 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RDxSJ-00019s-EH; Wed, 12 Oct 2011 07:58:39 -0400 Message-ID: <4E9580DC.1090509@riw.us> Date: Wed, 12 Oct 2011 07:58:20 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Mann References: <20110921113700.25835.21217.idtracker@ietfa.amsl.com> <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk> <9C518B43-38DD-4733-8B00-5E57EA7EE82F@cisco.com> <4E944989.5070801@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: homenet@ietf.org Subject: Re: [homenet] draft-chown-homenet-arch-00.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, 12 Oct 2011 11:58:56 -0000 > I think you are quoting from the "Transparent End-to-End Communications" > section on pages 14/15 which is to do with communications _within_ the home network. Yes... I understand the rational behind not wanting a NAT within the home, but the text reads in a much larger way. And the anti-NAT bits aren't just limited to that one section, but rather scattered throughout. So I would say -- 1. Take out the bits about "we don't want NAT." 2. Replace them with a single section detailing exactly what you want in terms of "transparent end-to-end communications" specifically within the home. > Is this really true? When I want to secure a physical space, I block off > all access, then put in carefully thought out access control points. I > don't pile all my goods in the middle of the street, and then actively > monitor every person who walks by, hiring more people to do the > monitoring as needed. > ... > > Generally speaking, I want open access within my home network, > but may add specific rules to stop e.g. guest wi-fi getting to certain > servers. You want guests to be able to get to all servers by default, unless you specifically go into a configuration on some device? What's really needed is the ability to divide things into "domains," probably requiring some form of local directory server, and then controlling who is in what domain. Anything within a domain can access anything else within the same domain by default, and cannot access anything in the other domain by default, including network connections. > See " Security, Borders, and the elimination of NAT" section on page 5. > --- > [RFC6092] provides recommendations for an IPv6 firewall that > applies "limitations on end-to-end transparency where security > considerations are deemed important to promote local and Internet > security." The firewall operation is "simple" in that there is an > assumption that traffic which is to be blocked by default is > defined in the RFC and not expected to be updated by the user or > otherwise. The RFC also discusses an option for CPEs to have an > option to be put into a "transparent mode" of operation. > > It is important to distinguish between addressability and > reachability; i.e. IPv6 through use of globally unique addressing > in the home makes all devices potentially reachable from anywhere. > Whether they are or not should depend on firewall or filtering > behaviour, and not the presence or use of NAT. ... > --- > > Does this address you concerns? No, not really, because it assumes just what I don't want to assume --that end-to-end reachability is the default, and I must take specific actions in order to block specific pieces of reachability. If you want, I'll try and suggest wording later today or tomorrow. :-) Russ From henk@uijterwaal.nl Wed Oct 12 05:01:48 2011 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 A758C21F8C14 for ; Wed, 12 Oct 2011 05:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHkYB2RK0taz for ; Wed, 12 Oct 2011 05:01:47 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7A11321F8C2A for ; Wed, 12 Oct 2011 05:01:47 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id p9CC1BZC029268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Oct 2011 14:01:16 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4E954AC5.4080306@uijterwaal.nl> Date: Wed, 12 Oct 2011 10:07:33 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110110033.p9B0XZwa059653@gateway.ipv6.occnc.com> <2584.1318335811@marajade.sandelman.ca> In-Reply-To: <2584.1318335811@marajade.sandelman.ca> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [homenet] Homenet strawman slides 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, 12 Oct 2011 12:01:48 -0000 On 11/10/2011 14:23, Michael Richardson wrote: > >>>>>> "Curtis" == Curtis Villamizar writes: > Curtis> I really don't know how many support calls are just the consumer > Curtis> plugging the computer into the wrong Ethernet port on the NAT box > and Curtis> the uplink on the other port and then not being able to figure > out Curtis> what is wrong. All the cables fit in the connector. It should > work! > > So, I was interrupted yesterday, reading homenet email, in order to go to > my neighbour's house and sort out this EXACT problem. My box and the cables at home have connectors in different colors, making it easy to plug the right cable in the right port. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From russw@riw.us Wed Oct 12 05:10:12 2011 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 1FCD621F8CA1 for ; Wed, 12 Oct 2011 05:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5zGMPpEFipf for ; Wed, 12 Oct 2011 05:10:11 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 7044E21F8C9F for ; Wed, 12 Oct 2011 05:10:11 -0700 (PDT) Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:1856 helo=[10.117.153.99]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RDxcu-0008PU-Qo for homenet@ietf.org; Wed, 12 Oct 2011 08:09:36 -0400 Message-ID: <4E95836D.4020307@riw.us> Date: Wed, 12 Oct 2011 08:09:17 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <01233F99-34FA-4AE3-94B3-1ECAF190B248@cisco.com> <12544.1318343246@marajade.sandelman.ca> <4E948FE9.8050101@riw.us> <17786.1318379939@marajade.sandelman.ca> In-Reply-To: <17786.1318379939@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Thoughts about routing 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, 12 Oct 2011 12:10:12 -0000 > Russ> You need a unique identifier at the equipment level for > Russ> anything you intend to auto-configure --autoconfiguring > Russ> uniqueness is a very hard, probably impossible, problem on a > Russ> global scale. So we need to count on this one thing, no matter > Russ> what else we might need to back in to. > > Russ> Now, it might be possible to some hash over a GPS location for > Russ> a "base," and then add on MAC addresses, or some such, but > > We've assumed a unique MAC, which is 48 bits long. > But OSPF router-id is 32 bits. What is the likelyhood of a collision > in the bottom 32-bits of the MAC? Ah, I see the problem... There is a pretty high likelihood of a collision, actually, at least as long as you use multiple vendors in your home network. It's bound to happen to someone, someplace. So, a suggestion to resolve this: 1. Use the lower 32 bits of one of the mac addresses on the box as the initial id. 2. Add a new field to the router capabilities that carries the full 48 bit mac address, or even some munged together "longer id," based on multiple mac addresses on the device, or some such. 3. During initial setup, if you receive a capability that appears to be from yourself, you open this secondary id section to find out if it's really you, or someone else who happens to have the same 32 bit id. 4. If it's really you, discard the packet. 5. If it's not really you, and if the other router's "large id" is lower than yours, choose another mac address from which to take your local id, and restart your ospf process. 6. If it's not really you, and the other router's "large id" is higher than yours, then send a router capabilities LSA unicast to this "other router," so the "other router" knows to change its id. I don't think IS-IS would have this problem. :-) Russ From mellon@fugue.com Wed Oct 12 05:36:05 2011 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 8F68121F8ABB for ; Wed, 12 Oct 2011 05:36:05 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Tg-BMcnU0Fs for ; Wed, 12 Oct 2011 05:36:05 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 106FE21F8AAF for ; Wed, 12 Oct 2011 05:36:05 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:784c:a4d3:e399:bf29] (unknown [IPv6:2001:470:1f07:1486:784c:a4d3:e399:bf29]) by toccata.fugue.com (Postfix) with ESMTPSA id 257EE2381C90; Wed, 12 Oct 2011 08:33:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_5703F516-D349-4207-B20E-234221B01FAD" From: Ted Lemon In-Reply-To: <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> Date: Wed, 12 Oct 2011 08:33:19 -0400 Message-Id: References: <4E94BF91.4060807@cs.tcd.ie> <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1244.3) Cc: homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 12:36:05 -0000 --Apple-Mail=_5703F516-D349-4207-B20E-234221B01FAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 12, 2011, at 4:48 AM, Ole Troan wrote: > using the electricity network as an analogy, can we make a distinction = between "safety" and "security"? > the electricity network in the home is somewhat self protecting with = breakers and earthing. > a home network must protect 'itself', i.e. handle any device plugged = into it, in any topology, external and internal attacks > and so on. I am highly sympathetic to the desire not to try to solve this problem. = However, unfortunately network topology isn't the same as electrical = topology, for a couple of reasons. The first reason is that electrical systems are generally set up by = professionals. Yes, you plug devices into the electrical wiring of = your house, but someone skilled set it up (or if not, I hope you sleep = in asbestos pajamas). The devices we are talking about are more = analogous to circuit distribution panels than to toasters. The second reason is that electrical systems are essentially = topology-free. Any point on the system is essentially equivalent to = any other. This is not true of a home network with routing. What we = are talking about is essentially the possibility of rogue distribution = panels intentionally or accidentally being connected to your = distribution system. =20 Which is a result of the third reason: home networks are typically = wireless, or partially wireless, and so there is no physical security, = unlike an electrical network in a house, which is secure by virtue of = being entirely enclosed by the house. I think what you are getting at is that we cannot be responsible for = securing the network. And that is probably true. But if the system = doesn't have a built-in mechanism for distinguishing between friend and = stranger, the autoconfiguration mechanism will create topologies that = aren't desired, either by accident or because a stranger wants access to = the network. --Apple-Mail=_5703F516-D349-4207-B20E-234221B01FAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii using the = electricity network as an analogy, can we make a distinction between = "safety" and "security"?
the electricity network in the home is = somewhat self protecting with breakers and earthing.
a home network = must protect 'itself', i.e. handle any device plugged into it, in any = topology, external and internal attacks
and so = on.
I am highly sympathetic to the = desire not to try to solve this problem.   However, unfortunately = network topology isn't the same as electrical topology, for a couple of = reasons.

The first reason is that electrical = systems are generally set up by professionals.   Yes, you plug = devices into the electrical wiring of your house, but someone skilled = set it up (or if not, I hope you sleep in asbestos pajamas).   The = devices we are talking about are more analogous to circuit distribution = panels than to toasters.

The second reason is = that electrical systems are essentially topology-free.   Any point = on the system is essentially equivalent to any other.   This is not = true of a home network with routing.   What we are talking about is = essentially the possibility of rogue distribution panels intentionally = or accidentally being connected to your distribution system. =   

Which is a result of the third = reason: home networks are typically wireless, or partially wireless, and = so there is no physical security, unlike an electrical network in a = house, which is secure by virtue of being entirely enclosed by the = house.

I think what you are getting at is that = we cannot be responsible for securing the network.   And that is = probably true.   But if the system doesn't have a built-in = mechanism for distinguishing between friend and stranger, the = autoconfiguration mechanism will create topologies that aren't desired, = either by accident or because a stranger wants access to the = network.

= --Apple-Mail=_5703F516-D349-4207-B20E-234221B01FAD-- From ot@cisco.com Wed Oct 12 05:46:29 2011 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 D127621F8CB9 for ; Wed, 12 Oct 2011 05:46:29 -0700 (PDT) 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=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJwgsDRsrKFj for ; Wed, 12 Oct 2011 05:46:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D323121F8CB6 for ; Wed, 12 Oct 2011 05:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=2229; q=dns/txt; s=iport; t=1318423589; x=1319633189; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=S+jDIBsEbcs4U4om8Vpjcb4u4732ekrj/fHt7bzqDow=; b=VztUPa+MY2XQUduMSRg612xL6d2mhfIzI9PDjzc7MgTc4J9AmAyifs/0 ugNDgOUOZxiFRB4VExjKr4CBbi8kC72x0k5ek8ae/g3IODU2visS1OJ2I Bx3fxI+HFEiJprV2rQjJX1VH8F2wwYpbkJevGnujArIDOioNi5KEiLj+Q I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMKKlU6Q/khR/2dsb2JhbABDqC+BBYFTAQEBAwESASc/EAsOOFcGNYdcmwsBnmiGd2EEk3WRVg X-IronPort-AV: E=Sophos;i="4.69,334,1315180800"; d="scan'208";a="118929499" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2011 12:46:25 +0000 Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com [64.103.53.235]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9CCkO7a005446; Wed, 12 Oct 2011 12:46:25 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 12 Oct 2011 14:46:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E94BF91.4060807@cs.tcd.ie> <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 12:46:29 -0000 Ted, >> using the electricity network as an analogy, can we make a = distinction between "safety" and "security"? >> the electricity network in the home is somewhat self protecting with = breakers and earthing. >> a home network must protect 'itself', i.e. handle any device plugged = into it, in any topology, external and internal attacks >> and so on. >=20 > I am highly sympathetic to the desire not to try to solve this = problem. However, unfortunately network topology isn't the same as = electrical topology, for a couple of reasons. >=20 > The first reason is that electrical systems are generally set up by = professionals. Yes, you plug devices into the electrical wiring of = your house, but someone skilled set it up (or if not, I hope you sleep = in asbestos pajamas). The devices we are talking about are more = analogous to circuit distribution panels than to toasters. >=20 > The second reason is that electrical systems are essentially = topology-free. Any point on the system is essentially equivalent to = any other. This is not true of a home network with routing. What we = are talking about is essentially the possibility of rogue distribution = panels intentionally or accidentally being connected to your = distribution system. =20 >=20 > Which is a result of the third reason: home networks are typically = wireless, or partially wireless, and so there is no physical security, = unlike an electrical network in a house, which is secure by virtue of = being entirely enclosed by the house. >=20 > I think what you are getting at is that we cannot be responsible for = securing the network. And that is probably true. But if the system = doesn't have a built-in mechanism for distinguishing between friend and = stranger, the autoconfiguration mechanism will create topologies that = aren't desired, either by accident or because a stranger wants access to = the network. I do agree with that. I think we can figure out a way of "pairing" devices. whatever layer = that ends up being done at. it will be much more difficult to protect against hostiles injecting = default routes, or pretending to be DHCP servers and so on. cheers, Ole= From nordmark@cisco.com Wed Oct 12 09:03:21 2011 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 80CC021F8BE7 for ; Wed, 12 Oct 2011 09:03:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxTfFJe+ELit for ; Wed, 12 Oct 2011 09:03:20 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EB61F21F8B98 for ; Wed, 12 Oct 2011 09:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1028; q=dns/txt; s=iport; t=1318435401; x=1319645001; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=H92VW12E4S8d4/Uv7v0O+2rspXnJcrZAIApwtIlRTAs=; b=VpiCkdf2BgJnjy0z6+DDgDX1g4+h4bdQn/0ZhwpEpd42f4y9GzVD28sG DHz5u4he1eJKD6ReqKqy/U0nnpSoOHIujeGsJojAZK4xD8lBl8jJu4FPZ hpkVW0kqE4Vp2l5H+LyNxn72MdMq6MM1A40C+FP9G9hQm4Jro+85XeFKg g=; X-IronPort-AV: E=Sophos;i="4.69,335,1315180800"; d="scan'208";a="7453915" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 Oct 2011 16:03:21 +0000 Received: from [10.0.1.12] (sjc-vpn6-1384.cisco.com [10.21.125.104]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9CG3K2t016017; Wed, 12 Oct 2011 16:03:20 GMT Message-ID: <4E95BA69.6090507@cisco.com> Date: Wed, 12 Oct 2011 09:03:53 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Michael Richardson References: <4E8F441D.9070202@cisco.com> <4E8F5E8B.4010102@cisco.com> <4E8F7873.4050505@cisco.com> <4E904CD2.1080705@piuha.net> <4E933756.30506@cisco.com> <2834.1318277864@marajade.sandelman.ca> In-Reply-To: <2834.1318277864@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 12 Oct 2011 16:03:21 -0000 On 10/10/11 1:17 PM, Michael Richardson wrote: > >>>>>> "Erik" == Erik Nordmark writes: > Erik> There might be some more difficult aspects if we want to allow > Erik> a router or its interfaces to be repurposed, such as splitting > Erik> an existing link into two separate links. In that case it > Erik> might be hard to avoid renumbering. The requirements question > > Moving/repurposing a router without a factory reset seems like the > perhaps the most important source of conflict in the architecture that > we discussed. Particularly if the router is put into a junk drawer for > a few months until it is needed. > > So, we might need to consider if we can expire persisted settings after > some long (from the point of view of the network) time, like 1 week... FWIW My existing IPv4 NATting home routers don't need to be quaranteened for a week; I can just rewire. At worst I have to power cycle. I thought IPv6 would make things better ;-) Erik From victor.kuarsingh@gmail.com Wed Oct 12 09:05:03 2011 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 2A87D21F8BF7 for ; Wed, 12 Oct 2011 09:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEMsfSXY54rL for ; Wed, 12 Oct 2011 09:05:02 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62FDF21F8BEC for ; Wed, 12 Oct 2011 09:05:02 -0700 (PDT) Received: by eyg24 with SMTP id 24so952104eyg.31 for ; Wed, 12 Oct 2011 09:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=2SF4gTb8pYHF/7zDVszKjsToTuhn85MSwbXJxltLwzw=; b=qq3GHZ9Z4HPX1cAHxo28lsCaW6Y8w19wlTJiatWTYT3bDXLa5noLnin7wxaTiqMAo+ ZMfAT8Vlbr/jpApku5PomzuKV63JS9GTD2VNJcYzxiwE7ZfgbFZb2ej1Wk7QFGF24B1T gWJMiXIj8pgE1fYEpK3rY0z13WBMhy+rWtJ40= Received: by 10.14.7.138 with SMTP id 10mr935453eep.27.1318435500008; Wed, 12 Oct 2011 09:05:00 -0700 (PDT) Received: from [25.31.206.78] ([74.198.87.78]) by mx.google.com with ESMTPS id y11sm6571107eej.5.2011.10.12.09.04.52 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 09:04:57 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 12 Oct 2011 12:04:53 -0400 From: Victor Kuarsingh To: Rajeev Koodli , Mark Townsley , Michael Richardson Message-ID: Thread-Topic: [homenet] Does ND Proxy useful for homenet? 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] Does ND Proxy useful for 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, 12 Oct 2011 16:05:03 -0000 Mark, A few points on this topic. As noted, the Cell system will have PD capabilities until a future 3GPP release (Rel-10) as noted. Although, even when the functionality is in place (generally), small devices like Smartphone and the mini gateways (3G/LTE devices which allow for 4-5 hosts to attached to Cell system) - PDs may not be used. Many of these devices (I.e in the case of the smartphone) have modes of operation where they "tether", which turns them into a mini gateway. They are not likely to be be full blown gateways equivalent to what you see common CPEs. In the IPv4 case, these devices "NAT" the IPv4 private addresses used by hosts behind the device to the network assigned address. In the case of IPv6, it will have access to the network assigned ::/64. PCs (maybe other devices) behind such devices will need access to the IPv6 network, but may not have access to PD space. This was one of the specific use cases I was eluding to before. These devices (in such operating modes) are however not likely to participate in a home network (as the gateway device or a router) and it's very unlikely to be the head of home network. With this explanation, I am not sure if this should/would be considered as such in HomeNet. These devices technically become gateways/bridges to the Internet. And the hosts that use them are often the same type of devices which connect to common home networks. Regards, Victor K On 11-10-10 4:51 PM, "Rajeev Koodli" wrote: > >Hi, > >The smartphone will only get a /64 in the current 3G/4G releases (rel-8, >rel-9). > >Prefix delegation is specified in Rel-10. > >-Rajeev > > > >On 10/10/11 1:01 PM, "Mark Townsley" wrote: > >>> >>> Or are you saying a mobile device (a smartphone) will only ever get a >>> /64 to share? >> >> My (limited) understanding of the various 3/4G standards are that a PD >>for a >> phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or >> someone else here can elucidate. >> >> - Mark >> > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From gettysjim@gmail.com Wed Oct 12 09:11:46 2011 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 8F60821F8C10 for ; Wed, 12 Oct 2011 09:11:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxma1HwEBqqc for ; Wed, 12 Oct 2011 09:11:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD2BA21F8BDE for ; Wed, 12 Oct 2011 09:11:45 -0700 (PDT) Received: by vws5 with SMTP id 5so871110vws.31 for ; Wed, 12 Oct 2011 09:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nHqcyaSC1n9M9q6BU1Qp28QTbo5vx0gpVZ/+/92yc8Y=; b=AUto/qtC0Ir02ptYMqhp5AURBdueaykFHgxTfdD+Jhc8EQQyBB/ygy1zNK4rONfjEY 5TewGsBci3RllrsUYhpkXDWx0IuegEf2O60R34h1iN1/VXQUpDv3HO1+49nJIPFDmeXB zAsjt6kC5LQwrI0CyTRzTY4G685s9acMlDV4c= Received: by 10.52.36.41 with SMTP id n9mr24233163vdj.41.1318435905334; Wed, 12 Oct 2011 09:11:45 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id l4sm518392vdv.4.2011.10.12.09.11.43 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 09:11:44 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E95BC3E.9000208@freedesktop.org> Date: Wed, 12 Oct 2011 12:11:42 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Fred Baker References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> In-Reply-To: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , homenet@ietf.org, homenet-ads@tools.ietf.org Subject: Re: [homenet] Thoughts about routing - scaling 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, 12 Oct 2011 16:11:46 -0000 I've alluded to having suffered from routing problems in the past, and urged people to be very careful about scaling, and interacting with unexpected/unintended neighbours, something that seldom happens in wired networking. I thought I'd elaborate slightly to help people focus on the problems. Both of these experiences come from my tenure at OLPC, which attempted to deploy mesh networking, where I worried about the base system software (but not the networking, in particular; Michailis Bletsas was in charge of that). Both added grey hair to my head and scars to our backs. 1) we had a situation, in which one of our machines tickled a bug in existing routers being used in an apartment building causing most all of the home networks in the apartment building to crash, to the point of needing reboot. It wasn't our bug; but it was sure our problem :-(. This is about all I can say on an open list about what happened here. The moral: lots of people can hear the packets you transmit; ensuring nothing bad will happen is "interesting". The packets escape into the "ether" and may have consequences you don't anticipate. And just because you think that there are only a few participants in a conversation doesn't make it so. 2) The 802.11s committee, in their infinite wisdom, specified a routing protocol at layer 2. At least in the draft standard we were working from, the properties of this routing algorithm had the consequence of N^2 messages where N was determined by the number of machines that could hear each other simultaneously (each machine that heard you looking for the exit to the mesh would each turn around and send another message). I don't know if the current version of the standard is so brain-dead or not: the committee had ruled the scaling problem "out of scope" for the group: after all, no one would ever think of running a mesh in such a circumstance. Reality is that kids show up at school at the same time, (or people enter a conference room at the same time), and it happens. Let us not suffer from the attitude the IEEE did with 802.11s. It doesn't take many machines (somewhere between 15 and 30), that can hear each other to fry your channel entirely. It was so bad that we could only get about 14-16 bits into the preamble of the message before someone else would transmit and step on the attempted transmission: another words, the network completely collapsed with scale. We called this the "dense mesh" problem. Any routing protocol used on wireless should be evaluated for its scaling properties carefully. Your first ARP would, of course, trigger this melt down. The third problem we had in networking we didn't figure out at all: that awaited my personal encounter with bufferbloat to understand. - Jim From gettysjim@gmail.com Wed Oct 12 09:37:10 2011 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 44A8A21F8C39 for ; Wed, 12 Oct 2011 09:37:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdr5C5zGcdhv for ; Wed, 12 Oct 2011 09:37:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80B4821F8BEF for ; Wed, 12 Oct 2011 09:37:09 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so907215vcb.31 for ; Wed, 12 Oct 2011 09:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LfgMRmbzSce7qV1s6+qfijRgYiznXSovGn0LM6N7N08=; b=JylNnYrNiAszuXEvcoI/qBkDbveA6QWwpFQ3vguwWr1iUPRbEYLiX7m4sWp0pl/4/G IOyI8Smycuxrg8eEUHFOhevumrsIOn9ikuBFaV+XM/F4DLs7Af3rGghTAoA2yj/OJm/p 5hZXlIRvvqbNgdtnvN8DzwiRr6TEeR9xMpQX8= Received: by 10.220.141.75 with SMTP id l11mr2134434vcu.186.1318437429014; Wed, 12 Oct 2011 09:37:09 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ey9sm560803vdc.19.2011.10.12.09.37.06 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 09:37:07 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E95C231.5030102@freedesktop.org> Date: Wed, 12 Oct 2011 12:37:05 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Jari Arkko References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> In-Reply-To: <4E93C075.30400@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Acee Lindem , "homenet@ietf.org" , curtis@occnc.com Subject: Re: [homenet] Thoughts about routing - flash/stable storage constraints 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, 12 Oct 2011 16:37:10 -0000 On 10/11/2011 12:05 AM, Jari Arkko wrote: > Home routers would also have MAC addresses, but again, if we need a > 32-bit quantity then shortened 48/64 bit identifiers may > (theoretically) have collisions. > > That being said, if the home routers have to discover their IPv6 > prefix through a protocol and store it in flash, they could probably > do so also for a router ID. Unless there was some chicken and egg > problem that required the router ID for all this discovery to work... As to storing in flash, since most in homenet have not typically worked on embedded systems, worse luck... There is typically a read/write file system that can store state on a current Linux home router (e.g. OpenWrt); it may or may not mapped over the entire flash (which is desirable, as you'd like wear levelling to use all blocks on the flash). The bulk of the firmware is likely contained in a read-only file system called Squashfs, which does LZW compression on a per file basis; overlayed on top may be a read/write file system. Most commonly the read/write file system has been a file system called jffs2 over bare flash, originally implemented on the Compaq iPAQ handheld, a project I helped lead after I got sick of HTTP. And OLPC had a gigabyte of flash (which pushes jffs2 to/beyond it's design limits). There are later flash file systems under development, but I don't have first hand experience with any of them. Flash has the characteristic that write is relatively slow, and erase is generally glacial. Most interesting flash file systems try to do lazy erasure (erase freed blocks when they have a chance later, rather than at the time you may free a file). Since you don't want to wear out the flash, the jffs2 does journaling; one write will commit (potentially) a bunch of changes to multiple files, rather than each write generating one write. How many writes you get depends on the flash technology, whether the flash is "bare" or has some "smart" controller, and the wear levelling technology (if any) in use, along with whether all blocks participate in the wear levelling or not (jffs2 does good wear levelling; but using a big squashfs file system + a very small jffs2 file system will reduce the effectiveness; some cheap USB storage devices only do wear levelling on the free blocks, and try to hide the fact it is flash from the system above. I put "smart" in quotes, because they've often been hideously stupid, with their smarts limited to looking like IDE with a very lame flash translation layer. The most recent "smart" flash disks for laptops are actually getting very smart, with some help from the OS to help with the erasure problem. But they still cost substantially more, I suspect. I think most home routers currently use bare flash, though it's not clear to me if this will continue or not since the volume market may make the economics change. In any case, with flash of any sort, you don't want to sit there and demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime, for example). All this being said, storing state at the rate of machines/routers appearing or disappearing on a home network, or your ISP going down, isn't likely to cause a problem. You just have to be careful enough to not do anything really stupid; e.g. you map daemons with chatty logs to run their logs to /dev/null, or to tempfs in RAM. And you might take a big latency hit if you have to guarantee the write is stable before continuing an algorithm (if you run into needing to erase a block for some reason). And obviously you don't write tons of data when you don't half to. And update in place may be a bad idea relative to other techniques (which is why journaling file systems such as jffs2 are so desirable). - Jim From mellon@fugue.com Wed Oct 12 10:50:34 2011 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 E3FBC21F8C58 for ; Wed, 12 Oct 2011 10:50:34 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-H-vvVTUYjl for ; Wed, 12 Oct 2011 10:50:34 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 803CE21F8B86 for ; Wed, 12 Oct 2011 10:50:34 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:a187:2c10:f618:f107] (unknown [IPv6:2001:470:1f07:1486:a187:2c10:f618:f107]) by toccata.fugue.com (Postfix) with ESMTPSA id 9CC642381CA6; Wed, 12 Oct 2011 13:50:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_AF58DCC3-D93F-4ACD-B881-B3FB955E5F72" From: Ted Lemon In-Reply-To: Date: Wed, 12 Oct 2011 13:50:25 -0400 Message-Id: <83104EE3-2F13-4900-AE2C-89FB5E027E89@fugue.com> References: <4E94BF91.4060807@cs.tcd.ie> <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1244.3) Cc: homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 12 Oct 2011 17:50:35 -0000 --Apple-Mail=_AF58DCC3-D93F-4ACD-B881-B3FB955E5F72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 12, 2011, at 8:46 AM, Ole Troan wrote: > I think we can figure out a way of "pairing" devices. whatever layer = that ends up being done at. > it will be much more difficult to protect against hostiles injecting = default routes, or pretending to be DHCP servers and so on. I think pairing and general network security are largely the same = problem. Of course if someone is granted access to the network, they = can then inject routes or pretend to be a DHCP server, but that's not = the issue I'm concerned with. I'm more concerned with the scenario Jim = Gettys talked about in a subsequent message, where a bunch of things = clump together and start talking to each other essentially accidentally. = And of course I'm also somewhat concerned about attackers, although I = think that's probably going to happen less often than accidental = clumping. --Apple-Mail=_AF58DCC3-D93F-4ACD-B881-B3FB955E5F72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think we = can figure out a way of "pairing" devices. whatever layer that ends up = being done at.
it will be much more difficult to protect against = hostiles injecting default routes, or pretending to be DHCP servers and = so on.

I think pairing and general = network security are largely the same problem.   Of course if = someone is granted access to the network, they can then inject routes or = pretend to be a DHCP server, but that's not the issue I'm concerned = with.   I'm more concerned with the scenario Jim Gettys talked = about in a subsequent message, where a bunch of things clump together = and start talking to each other essentially accidentally.   And of = course I'm also somewhat concerned about attackers, although I think = that's probably going to happen less often than accidental = clumping.

= --Apple-Mail=_AF58DCC3-D93F-4ACD-B881-B3FB955E5F72-- From jhw@apple.com Wed Oct 12 12:27:07 2011 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 99DA521F8C2A for ; Wed, 12 Oct 2011 12:27:07 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev2+yaPUzZyd for ; Wed, 12 Oct 2011 12:27:07 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1C96F21F8B9E for ; Wed, 12 Oct 2011 12:27:07 -0700 (PDT) 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 Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LSY001HZWOG5EJ1@mail-out.apple.com> for homenet@ietf.org; Wed, 12 Oct 2011 12:26:57 -0700 (PDT) X-AuditID: 11807130-b7cb3ae000006822-7c-4e95e928a2e2 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 47.44.26658.829E59E4; Wed, 12 Oct 2011 12:23:20 -0700 (PDT) From: james woodyatt In-reply-to: <4E9580DC.1090509@riw.us> Date: Wed, 12 Oct 2011 12:26:56 -0700 Message-id: <47F25766-19DD-4F45-8CCF-07D326F17541@apple.com> References: <20110921113700.25835.21217.idtracker@ietfa.amsl.com> <6EE1C499-F8AB-4740-899A-2E90813EF065@ecs.soton.ac.uk> <9C518B43-38DD-4733-8B00-5E57EA7EE82F@cisco.com> <4E944989.5070801@riw.us> <4E9580DC.1090509@riw.us> To: Russ White X-Mailer: Apple Mail (2.1401) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUieJDvpq7Gy6l+Bns2C1u8X3SIxWLd3APs DkweS5b8ZPI4/XAyewBTFJdNSmpOZllqkb5dAlfGjXmT2Qo+CFRMOvucsYGxg7eLkZNDQsBE YuXt98wQtpjEhXvr2boYuTiEBFYwScxbsYoNJMEsoCVx499LJhCbV8BQ4vWVn2ANwgJmEs/e H2IFsdkEVCS+Xb4LVsMpoCbRs3QVWJxFQFVi65MPUHP0JXr3PISytSWWLXzNDDHTRuLlmTYW iMWzmSXm9t0CGyQiICvRcX87E8R1shLtP5oZJzDyz0Jy0ywkN81CMncBI/MqRsGi1JzESkND vcSCgpxUveT83E2MoMBrKDTYwbj2J/8hRgEORiUeXo/LU/2EWBPLiitzDzFKcDArifBeXgMU 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzlv/bIqfkEB6YklqdmpqQWoRTJaJg1OqgVHQPV/GIJdh w7tXmu+Z+E/N3ue7ItVse0NiV3FEt/OdLaumvW2b93CvVJdJ47akftnNrLwvdM9fMbuydvrv ZaqdL/1v3DvJHBDP4/3+Oav239UulfULeMJSmtZlRb1aeIrJ2XvOAhff4lv5HzVWyh6tTmxO fi3k32JZb1Vn9OM8l7SF1Wa59UosxRmJhlrMRcWJAFeQJxg4AgAA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-chown-homenet-arch-00.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, 12 Oct 2011 19:27:07 -0000 On Oct 12, 2011, at 4:58 AM, Russ White wrote: > No, not really, because it assumes just what I don't want to assume > --that end-to-end reachability is the default, and I must take specific > actions in order to block specific pieces of reachability. Those of us who still bear the scars of the debate over RFC 6092 well remember that the Simple Security document takes great pains to make no such assumption. >> 1.2. Use of Normative Keywords >> >> NOTE WELL: This document is not a standard, and conformance with >> it is not required in order to claim conformance with IETF >> standards for IPv6. It uses the normative keywords defined in the >> previous section only for precision. >> >> Particular attention is drawn to recommendation REC-49, which calls >> for an easy way to set a gateway to a transparent mode of operation. >> >> [...] >> 3.4. Passive Listeners >> >> REC-49: Internet gateways with IPv6 simple security capabilities MUST >> provide an easily selected configuration option that permits a >> "transparent mode" of operation that forwards all unsolicited flows >> regardless of forwarding direction, i.e., not to use the IPv6 simple >> security capabilities of the gateway. The transparent mode of >> operation MAY be the default configuration. >> >> In general, "transparent mode" will enable more flexibility and >> reliability for applications that require devices to be contacted >> inside the home directly, particularly in the absence of a protocol >> as described in REC-48. Operating in transparent mode may come at >> the expense of security if there are IPv6 nodes in the home that do >> not have their own host-based firewall capability and require a >> firewall in the gateway in order not to be compromised. The "MAY" in that recommendation was the subject of about two years of teeth gnashing and garment rending, which I hope this working group shall not repeat. -- james woodyatt member of technical staff, core os networking From curtis@occnc.com Wed Oct 12 13:52:48 2011 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 278DB21F8B05 for ; Wed, 12 Oct 2011 13:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe-TmtRUCE5X for ; Wed, 12 Oct 2011 13:52:46 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 8866421F8B00 for ; Wed, 12 Oct 2011 13:52:46 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9CKqNkl033845; Wed, 12 Oct 2011 13:52:24 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9CKqNkl033845 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318452744; bh=GsRovx8CI0deJVL5Iozrepf3UQ371flWGXMS369F3fg=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=EuFttI20LWdE2dKnS4hfLOLvjYMlzd1rgPp7Wc5ZPVVP4dpCehflIu8ZXTwJ4G2on rl7V/iYRYbc+Ir0TiRDTbnS0k3N2w2mCkxEcz/7WUo5yawHr2M6zhxeGemkba+m3Yp vOLH7BvTd7fbMrEpW/hOeLzp/fgDFkN0l6n2EDRY= Message-Id: <201110122052.p9CKqNkl033845@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Oct 2011 20:35:56 EDT." <17350.1318379756@marajade.sandelman.ca> Date: Wed, 12 Oct 2011 13:52:22 -0700 Cc: Erik Nordmark , Lorenzo Colitti , Jari Arkko , homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] Homenet strawman slides X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 20:52:48 -0000 In message <17350.1318379756@marajade.sandelman.ca> Michael Richardson writes: > We may all be in violent agreement. > > >>>>> "Erik" =3D=3D Erik Nordmark writes: > >> Erik, > >> > >> I really don't know how many support calls are just the consumer > >> plugging the computer into the wrong Ethernet port on the NAT box > >> and the uplink on the other port and then not being able to > >> figure out what is wrong. All the cables fit in the connector. > >> It should work! > > Erik> It sure would be good to try to find some data on this. > > But, for many many years, ISPs did not support having a sharing device. > > Not that they do, ISP insist that the box be *their* box, and as that > box is sometimes broken, limited, etc. the customer has to provide their > own. Again, if the ISP is called, it's "not their problem". The ISP often has a dumb box that gets a DHCP allocation when turned on and then does NAT. For small business service, it may also get a fixed single IPv4 address, or less often a block and have the ability to accept an ARP from the customer side in that range (no DHCP). By default it does NAT and DHCP for everything else. If the ISP is an MSO and doing VOIP, their staff usually plugs it in. Otherwise if left to the customer, they would get the call. If it Vonage or similar VOIP provider, then they get the call. > Erik> While I can see that we can build the internals of the home > Erik> network with devices without a designated uplink > Erik> (automatically configure prefixes, the routing protocol etc), > Erik> what I don't understand is how the connectivity to the ISP > Erik> would happen. > > Erik> How do you see that working? Will each router try the > Erik> protocols it would use against the ISP (PPPOE, DHCP PD, etc) > Erik> on every port? Or on every port where it doesn't find a OSPF > Erik> (or whatever home routing protocol we choose) neighbor? Or > Erik> does the user have to configure the Customer Edge Router to > Erik> say "port eth0 is the WAN port?" > > Basically what you suggest. > For Cable and any access link that uses DHCP and Ethernet directly, the > fact that you get a DHCP with a PD is a clue that this is the WAN link. > For DSL using PPPoE (those who pay a bit more can have DSL without > PPPoE), then a username/password is required, and yes, the user has to > configure this. This is generally the case. A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere. If it gets a real address (not a PI), then that should be preferred over some device that handed out a NAT address with a default route to itself even though it had no uplink. Case in point: DHCP is not a routing protocol. You have one shot to hand over a default route. If its wrong it can be bandaided with ICMP redirects for hosts that don't have a zero config routing protocol running. But that is the best that can be done with the NAT and DHCP kludge that is in place today. We can whine about it or we can define something better with sufficient backwards compatibility. > However. in many cases, this is pre-configured by the ISP, as the > "router" and DSL modem is combined into a single box. Often this also > means that you can't plug it in wrong, as the uplink is an RJ11 rather > than RJ45. This is true only where where "it" is a VOIP product giving you an RJ11 and it is integrated into the same box as the DOCSIS or DSL modem and home router. > Erik> I don't think arbitrarily stupid way can possibly work, since > Erik> that doesn't ensure that the home network is internally > Erik> connected. If the user connects three routers in the den > Erik> together, but those are not connect to the rest of the house, > Erik> then no protocol we come up with can fix that. > > a) That's okay, because the three routers in the Den plugged in that way > won't affect the router in the basement which is doing fine. > > b) Actually, the three routers in the Den might see the wifi from the > basement, and might join it. That would be nice. I think Erik's point is that the audio system should still get a DHCP address and a (bogus) default route so that it can talk to the wireless speakers in the room which also get addresses. Michaels point about going through the WiFi is interesting in that in the current model this wouldn't work. An access point doesn't talk to another access point over the radio by default. They usually pick different channels specifically to avoid each other. If the access point was integral to or hanging off the routers by a Ethernet, in the uplink model, it wouldn't help even if they did talk to each other. > Erik> Supporting arbitrary topology (as opposed to just trees) is > Erik> good in that it enables redundant internal topologies. But > Erik> getting to a redundant topology requires a deeper knowledge by > Erik> the users than mandating a tree. More rope. Doesn't mean it is > Erik> simpler for the users. > > It's not enough to support only a tree. It is way too easy to wind up > with loops without really intending it. My laptop has four interfaces: wired, > wireless, USB ethernet (to mobile phone), and internal bridge to a VM. > Similarily, my phone has three interfaces: USB ethernet, wifi, and 3G. Yep. Good example. > So my laptop and phone can instantly create two links: wifi and USB. > My phone + AP + laptop can also have a loop via wifi + wired.=20=20 > I don't need all these links up, but I really do want these devices > smart enough to just bring up connectivity whenever they can. There just needs to be a preference. A zero config routing protocol can deal with your laptop going out of WiFi range or the Ethernet wire getting pulled when you leave a desk and fall back to the phone USB Ethernet, with the phone doing the same. The NAT situation has made quite a mess of this. NAT plus a default route through a routing protocol would be a big step forward. A routing protocol can change the default route and cost quickly as opposed to DHCP which can't change the default and has no concept of changing a route preference. All of this has to be zero config such that the consumer just plugs it in and it all works. Otherwise it just makes a support nightmare. Curtis From curtis@occnc.com Wed Oct 12 14:38:57 2011 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 4DA7021F8C16 for ; Wed, 12 Oct 2011 14:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY75Z-ZM2AtR for ; Wed, 12 Oct 2011 14:38:56 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id BC88C21F8C14 for ; Wed, 12 Oct 2011 14:38:53 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9CLcWwi035280; Wed, 12 Oct 2011 14:38:33 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9CLcWwi035280 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318455513; bh=15h5V86iOa6AI4Xc/HLJ3u6UX+Nqk0+F5GcCfiAjVd4=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=W6peSu5+16plLcF9b6mgzNgkmhLKPUV4f6W1VjyYKiqgACStdrDV6wd9YtFXkObkX L8l955H/AnO8/YS5vOAVJ/O8iiXu20LZIz2DuWz2OW1yntwKAOyG3dRjEpHjoX9tiC TLIBfiOEBsuDIcMOsgr61yM8b5ZVHfU8w6pYZu18= Message-Id: <201110122138.p9CLcWwi035280@gateway.ipv6.occnc.com> To: Jim Gettys From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 12:37:05 EDT." <4E95C231.5030102@freedesktop.org> Date: Wed, 12 Oct 2011 14:38:31 -0700 Cc: Acee Lindem , Jari Arkko , "homenet@ietf.org" , curtis@occnc.com Subject: Re: [homenet] Thoughts about routing - flash/stable storage constraints X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 21:38:57 -0000 In message <4E95C231.5030102@freedesktop.org> Jim Gettys writes: > On 10/11/2011 12:05 AM, Jari Arkko wrote: > > Home routers would also have MAC addresses, but again, if we need a > > 32-bit quantity then shortened 48/64 bit identifiers may > > (theoretically) have collisions. > > > > That being said, if the home routers have to discover their IPv6 > > prefix through a protocol and store it in flash, they could probably > > do so also for a router ID. Unless there was some chicken and egg > > problem that required the router ID for all this discovery to work... > As to storing in flash, since most in homenet have not typically worked > on embedded systems, worse luck... > > There is typically a read/write file system that can store state on a > current Linux home router (e.g. OpenWrt); it may or may not mapped over > the entire flash (which is desirable, as you'd like wear levelling to > use all blocks on the flash). > > The bulk of the firmware is likely contained in a read-only file system > called Squashfs, which does LZW compression on a per file basis; > overlayed on top may be a read/write file system. > > Most commonly the read/write file system has been a file system called > jffs2 over bare flash, originally implemented on the Compaq iPAQ > handheld, a project I helped lead after I got sick of HTTP. And OLPC > had a gigabyte of flash (which pushes jffs2 to/beyond it's design > limits). There are later flash file systems under development, but I > don't have first hand experience with any of them. > > Flash has the characteristic that write is relatively slow, and erase is > generally glacial. Most interesting flash file systems try to do lazy > erasure (erase freed blocks when they have a chance later, rather than > at the time you may free a file). > > Since you don't want to wear out the flash, the jffs2 does journaling; > one write will commit (potentially) a bunch of changes to multiple > files, rather than each write generating one write. > > How many writes you get depends on the flash technology, whether the > flash is "bare" or has some "smart" controller, and the wear levelling > technology (if any) in use, along with whether all blocks participate in > the wear levelling or not (jffs2 does good wear levelling; but using a > big squashfs file system + a very small jffs2 file system will reduce > the effectiveness; some cheap USB storage devices only do wear levelling > on the free blocks, and try to hide the fact it is flash from the system > above. I put "smart" in quotes, because they've often been hideously > stupid, with their smarts limited to looking like IDE with a very lame > flash translation layer. The most recent "smart" flash disks for > laptops are actually getting very smart, with some help from the OS to > help with the erasure problem. But they still cost substantially more, > I suspect. > > I think most home routers currently use bare flash, though it's not > clear to me if this will continue or not since the volume market may > make the economics change. > > In any case, with flash of any sort, you don't want to sit there and > demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime, > for example). > > All this being said, storing state at the rate of machines/routers > appearing or disappearing on a home network, or your ISP going down, > isn't likely to cause a problem. You just have to be careful enough to > not do anything really stupid; e.g. you map daemons with chatty logs to > run their logs to /dev/null, or to tempfs in RAM. And you might take a > big latency hit if you have to guarantee the write is stable before > continuing an algorithm (if you run into needing to erase a block for > some reason). And obviously you don't write tons of data when you don't > half to. And update in place may be a bad idea relative to other > techniques (which is why journaling file systems such as jffs2 are so > desirable). > > - Jim Jim, Nice reminder on the limitations of flash and some of the workarounds. Some neat hardware does erase on write and buffers the write itself, and can store enough energy in a small battery to flush the writes on power down. Its faster and maximized flash life. Its essentially a RAM front ended flash. I think it was expensive for consumer use. For provider equipement it makes logging to flash feasible thereby avoiding spinning media which may object to a 65 C ambient. Routing protocols are even less stateful than DHCP in this regard. There is no "lease" to be preserved between boots. The configuration (today in non-zero-config situations) is not sufficiently immuatable to put in a squashfs but may not be changed for months or years. Any old filesystem over bare flash is OK for that. Everthing else in a routing protocol is acquired at run time and therefore should be in RAM (ramfs or in application space RAM). With a zero config routing protocol at worst there would be a small amount of information that would generally be updated only once if at all on a reboot. Using a random number for router ID and remembering it across reboots and supporting a router ID collision repair would support this, since the collision on reboot would be rare even if the router was moved within the topology. If the router ID was not tied to an address it would not have to change when moved within the topology. Even the interesting problem of moving a router wire by wire would work. The adjacency and any address allocation acquired over it would be lost with each wire pulled. When plugged in elsewhere, new addressing would be needed and it would bring up a new adjacency or set of adjacencies (or more correctly participate in DR election and adjacency with the DR and BDR if there was a dumb switch in there and it were a true BCAST subnet). An interesting observation is that two addresses can be requested if the DR election is among two parties and after election it is apparent that they are the only two. If a third is added it is not a point to point link and a larger block can be requested. Curtis From jhw@apple.com Wed Oct 12 15:23:25 2011 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 A792A21F8CE1 for ; Wed, 12 Oct 2011 15:23:25 -0700 (PDT) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm0O8o6U+21a for ; Wed, 12 Oct 2011 15:23:25 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2F46B21F8CDE for ; Wed, 12 Oct 2011 15:23:25 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CngSXmDTe5UalzSOMU+O0Q)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LSZ001BX4TY5E12@mail-out.apple.com> for homenet@ietf.org; Wed, 12 Oct 2011 15:23:05 -0700 (PDT) X-AuditID: 11807136-b7c7fae00000458f-09-4e9618aed4f5 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 9D.38.17807.EA8169E4; Wed, 12 Oct 2011 15:46:06 -0700 (PDT) From: james woodyatt Date: Wed, 12 Oct 2011 15:23:04 -0700 In-reply-to: <201110122052.p9CKqNkl033845@gateway.ipv6.occnc.com> To: "homenet@ietf.org Group" References: <201110122052.p9CKqNkl033845@gateway.ipv6.occnc.com> Message-id: <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUieJDvpu46iWl+BrcP8Vu8X3SIxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRO/vWMreKte8al5O3MD4wylLkYODgkBE4nlN+K7GDmBTDGJ C/fWs3UxcnEICaxgktj3fy4bSIJNQEXi2+W7TCD1vALGEq//MYGEmQUSJGYc38QCYgsL6ElM fHKEHcRmEVCVOLPjNiOIzSngKLFs6i2wehEBfYmnR36BjRQScJC41LibGWKkjcS395kQJ8hL LG75zDiBkXcWwrJZSJZB2NoSyxa+ZgYpYRbQkZi8kBFVGML+eP4I0wJGtlWMgkWpOYmVhqZ6 iQUFOal6yfm5mxhBAddQaLaDccdfuUOMAhyMSjy8P65P9RNiTSwrrsw9xCjBwawkwruHd5qf EG9KYmVValF+fFFpTmrxIUZpDhYlcd6Nb6b4CQmkJ5akZqemFqQWwWSZODilGhilFzjNvRzs U7WCR0GV+xtT0LmjwgJRIaVLnTXuXZII8WCv7uVrCT3zpC777tWZIfe4pPT4VY0+nedNLj+y WUcn8oqu4UqBTLebd5Qz7/zrtysONg/rCEx5ExwVXZ63zKngeuZ5nZa2Y7fPdp3Tm9P+cvm3 o9t+lHzRMf0Sdan8sFHN1JDudUosxRmJhlrMRcWJAP8Rv+40AgAA Subject: Re: [homenet] Homenet strawman slides 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, 12 Oct 2011 22:23:25 -0000 --Boundary_(ID_CngSXmDTe5UalzSOMU+O0Q) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote: > > A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere. Some routers need to do this, i.e. home routers where service providers charge prohibitive rates for always-on Internet dial-tone and expect subscribers to connect on demand and disconnect after an appropriate idle time. For IPv4 today, these routers typically use PPPoE on the WAN and they often handle this by assigning RFC 1918 address to the LAN hosts and using DNS queries to signal PPPoE to establish the WAN link. For IPv6, I'm not sure what they should do, but I have some ideas. Basically, the router should advertise as a default router with a single ULA prefix and a DNS server at the router's ULA interface address with RFC 6106 and optionally RFC 3736. When the DNS query signals PPPoE to establish the WAN link, the DHCPv6 client will ask for a IA_PD and update the prefix advertised on the LAN accordingly. I'm not sure this model can be made to work with IPv6, but I wouldn't put it past the telcos to try. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_CngSXmDTe5UalzSOMU+O0Q) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
A router = should not start handing out PD or even IPv4 NAT space until it = gets and address from = elsewhere.

Some routers = need to do this, i.e. home routers where service providers charge = prohibitive rates for always-on Internet dial-tone and expect = subscribers to connect on demand and disconnect after an appropriate = idle time.

For IPv4 today, these routers = typically use PPPoE on the WAN and they often handle this by assigning = RFC 1918 address to the LAN hosts and using DNS queries to signal PPPoE = to establish the WAN link.

For IPv6, I'm not = sure what they should do, but I have some ideas.  Basically, the = router should advertise as a default router with a single ULA prefix and = a DNS server at the router's ULA interface address with RFC 6106 and = optionally RFC 3736.  When the DNS query signals PPPoE to establish = the WAN link, the DHCPv6 client will ask for a IA_PD and update the = prefix advertised on the LAN accordingly.

I'm = not sure this model can be made to work with IPv6, but I wouldn't put it = past the telcos to try.


--
james woodyatt <jhw@apple.com>
member of technical staff, core os = networking

= --Boundary_(ID_CngSXmDTe5UalzSOMU+O0Q)-- From curtis@occnc.com Wed Oct 12 16:00:49 2011 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 753ED21F8AED for ; Wed, 12 Oct 2011 16:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f2YZtRwq8CQ for ; Wed, 12 Oct 2011 16:00:48 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 20F3A21F8AE6 for ; Wed, 12 Oct 2011 16:00:48 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9CN0H6l074496; Wed, 12 Oct 2011 16:00:17 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9CN0H6l074496 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318460418; bh=iAVTjL/EL74hodji6wlaP4RiQPb1XWnPtjVmT0ImqYE=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=jXYsT19+JPbE3ACIQF2C9Q2isY+53R47wv/mUJ7Y27JD2jsflXoLrrI2g2Hy3twxT iZD8rNb1xwG7YNNXNVnyaP8mgJeqf5NF9uxMWxam07hp5djPGBjhjOTG2bXK4ZRWyP qb/wfI7iSIrpwvRiEQyOs/8+4iO3NL3VICGg8K7k= Message-Id: <201110122300.p9CN0H6l074496@gateway.ipv6.occnc.com> To: Erik Nordmark From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Oct 2011 10:53:34 PDT." <4E94829E.2010403@cisco.com> Date: Wed, 12 Oct 2011 16:00:15 -0700 Cc: homenet@ietf.org, Lorenzo Colitti , Jari Arkko , curtis@occnc.com Subject: Re: [homenet] Homenet strawman slides X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 23:00:49 -0000 In message <4E94829E.2010403@cisco.com> Erik Nordmark writes: > On 10/10/11 5:33 PM, Curtis Villamizar wrote: > > In message<4E93358F.7050907@cisco.com> > > Erik Nordmark writes: > > > >> On 10/8/11 6:13 AM, Jari Arkko wrote: > >>> I like this, with the possible exception of using ULAs and your desire > >>> to deprecate prefixes as soon as connectivity goes down. (Speaking as > >>> someone whose prefixes got invalidated two months ago but who hasn't > >>> been home long enough to fix the problem, but my devices still happily > >>> communicate with each other using the old prefixes :-) I also agree with > >>> Erik that loop and arbitrary topologies is not really required. But the > >>> people in the interim at least seemed to say yesterday that we want to > >>> go there. > >> > >> I think there are different scopes being discussed. > >> > >> The one I put forth is how to enable existing IPv4 NATting consumer home > >> routers (which all have a designated uplink port, and support multiple > >> home routers by nested NATting) have a way to support IPv6 without > >> requiring any IPv6 NATs. That doesn't seem to be a difficult problem > >> (which perhaps makes it uninteresting for some of us), but to me it > >> seems like an important short-term problem to solve. > >> > >> The larger scope is around arbitrary topologies, no designated uplink > >> port, and perhaps also multihoming. Plenty of problems to solve around > >> autoconfiguring routing protocols, stable prefix assignment to links, > >> multihoming, etc. > > > > > > Erik, > > > > I really don't know how many support calls are just the consumer > > plugging the computer into the wrong Ethernet port on the NAT box and > > the uplink on the other port and then not being able to figure out > > what is wrong. All the cables fit in the connector. It should work! > > It sure would be good to try to find some data on this. > > > If all the ports are the same, no designated uplink, that is better. > > While I can see that we can build the internals of the home network with > devices without a designated uplink (automatically configure prefixes, > the routing protocol etc), what I don't understand is how the > connectivity to the ISP would happen. > > How do you see that working? > Will each router try the protocols it would use against the ISP (PPPOE, > DHCP PD, etc) on every port? Or on every port where it doesn't find a > OSPF (or whatever home routing protocol we choose) neighbor? Or does the > user have to configure the Customer Edge Router to say "port eth0 is the > WAN port?" On a DOCSIS or DSL router the provider connection will always (maybe always) need some configuration, if for no other reason the provider wants to see an account name and password. If the provider ships out the DOCSIS or DSL router or installs it, then they would do that configuration. Everything *on the homenet side* would be autoconfig and would never have a need to run certain protocols such as PPPOE. If the user chooses to set the SSIDs and enable security on WiFi, that would have to be optional if we wanted true zero config. > FWIW I haven't seen any discussion to try to automate this. The manual > configuration would be just as error prone as making the distinction > between the yellow WAN port and the blue LAN ports on current home gear. The goal is to get zero configuration on the homenet side of homenet/provider demarc. If the provider supplies equipment, then the demarc is that equipment with the homenet side of the homenet/provider link configured ethernets the ethernets and any routers/hosts on the homenet side zero config. > > If you get an IP address via DHCP on one and none of the others, it > > may be the uplink and try doing NAT. What may be needed is a IPv4 > > equivalent to the IPv6 IA_PD and a provider DSL or docsis modem/router > > that knows how to respond to it. The other routers ask for a IA_PD > > and the provider modem/router responds with part of 10/8 on each > > interface (and does NAT). > > Presumably DHCP could be used within the home for address (and > potentially prefix) configuration, thus I don't think we can assume that > just because some neighbor on some port responds to a DHCP packet that > it is the WAN port. For all we know, the neighbor might be a DHCP relay > for the home network. The reason that a routing protocol is needed is DHCP is quite dumb about this and DHCP proxy and ARP proxy, and ND proxy provide at most very limited kludges. Let us separate DHCP6 from DHCP4 for the moment. In DHCP4 the assumption is that the client is always a host (excluding proxy) and returns a single address. In DHCP6 link local communication is possible without an uplink. With link local and a routing protocol, a default route can be discoverd if there is one (or more). Only when one of the routers on (or adjacent to, depending on demarc style) acquires a globally routeable prefix (IA_PD or configured, doesn't matter) can it begin responding to DHCP6 IA-PD requests. Since IPv6 hosts and routers add aliases (or are supposed to) in the presence of multiple routeable prefixes returned via IA_PD, if one demarc goes down, there still should be a route to the rest of the world, even for the prefix that provider demarc provided. IPv4 becomes a big kludge because it doesn't have the tools to do this right. DHCPv4 and NAT were successful, but to some extent made mistakes so lets not reuse the parts that didn't work for IPv6. For IPv4, you'll likely have to give out PI space in the absense of a clear uplink. A cycle with no true uplink can end up being a NAT loop without some changes. A path vector addition can at least break the loop (an allocation with no uplink in mind has no path). If there is a possible uplink (another router provided a DHCP response), the subnet of that uplink can go in the path. If the response came with a path, the subnet is added. If your subnet is already in the path, don't accept it as an uplink. A big improvement would also be an IPv4 equivalent to IA_PD and a routing protocol. At least the loop could end up with a different set of subnets of net 10 such that routing could work and no NAT. Then if a real uplink comes along it will already know what PI subnets are allocated in the routed portion. If there are dumb routers that want to reNAT, then they can't be part of a loop. Its no worse than now. > > The idea is that the consumer can plug things in in arbitrarily stupid > > way and it will all still work well enough to not require a support > > call. It might work better if set up right, but good enough if set up > > wrong. Perhaps GbE can be preferred over 100baseT over 10baseT and > > somewhere between 100baseT over 10baseT or after 10baseT fits WiFi. > > Beyond that metrics for multiple WiFi hops can be channel aware. > > I don't think arbitrarily stupid way can possibly work, since that > doesn't ensure that the home network is internally connected. If the > user connects three routers in the den together, but those are not > connect to the rest of the house, then no protocol we come up with can > fix that. Link local addresses and a routing protocol works. Age out the link local advertisements when allocated a routable prefix. Routers can fake proxy ND (just like proxy ARP today) for host that need to think the link local addresses really are local. > If the user wants to have sufficient redundancy (e.g., so that their > teenagers can power off all the gear in the game room with breaking the > Internet connectivity for half of the devices in the home, then clearly > there is a need to understand the topology (wired or wireless) to know > where there are potential single points of failure. Its more common than that. The scope is also supposed to be home and small home office. > Supporting arbitrary topology (as opposed to just trees) is good in that > it enables redundant internal topologies. But getting to a redundant > topology requires a deeper knowledge by the users than mandating a tree. > More rope. Doesn't mean it is simpler for the users. > > Erik Supporting arbitrary topology with zero config is not hard for IPv6 but if you start out making it a non-goal for no good reason it won't be accomplished, at least by this WG. I do agree though that right now configuring today's two main LS routing protocols is way too onerous to ever be successful in the consumer market. But I think it is a solvable problem. Curtis From curtis@occnc.com Wed Oct 12 16:29:50 2011 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 1879621F8B59 for ; Wed, 12 Oct 2011 16:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTtqEancIFr6 for ; Wed, 12 Oct 2011 16:29:48 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id B2A2921F8B04 for ; Wed, 12 Oct 2011 16:29:48 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9CNTfxr022316; Wed, 12 Oct 2011 16:29:41 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9CNTfxr022316 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318462185; bh=zrKeh+gLSHdUDPMFyjRNgruDw7nXtOiz3haZVedeEuw=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=LQ3lHwLZAIH+/G8tI8RqDKM75BfL+mYmys0S0wLTDTvtNIUo6ftaOnFYKVBTgmO+v kkBgd/a+u8Vdd2kfUV1/5cjbEAYc72N8Q3Vg5uArT4VULVPQYi+qMnZn1YwZrUwggN 41CTAwtbjk9CnwhH86JG7r3Mb0Xd9GGYERuCkX+w= Message-Id: <201110122329.p9CNTfxr022316@gateway.ipv6.occnc.com> To: Jim Gettys From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Oct 2011 15:10:33 EDT." <4E9494A9.4030901@freedesktop.org> Date: Wed, 12 Oct 2011 16:29:40 -0700 Cc: Thomas Narten , homenet@ietf.org, homenet-ads@tools.ietf.org, Fred Baker Subject: Re: [homenet] Thoughts about routing - trends X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 23:29:50 -0000 In message <4E9494A9.4030901@freedesktop.org> Jim Gettys writes: > Having said this, I do note the following technological trends: > > 1) As soon as we get real "plug and play" routers that don't need manual > configuration that work, we'll see a lot more routers in a home > environment. Other radio technologies (e.g. zigbee) may encourage this > trend. It seemed like the working group agreed that getting to the > point that just hooking things together would really "just worked" was a > fundamental requirement (and I agree entirely with this sentiment, as it > reflects reality of what already happens in the homes of hackers and > non-hackers alike). > > 2) wireless is much cheaper to implement than wired networking, > particularly in most houses where pulling cable is hard. I know this > first hand, where I've pulled a lot of cat 6 and wish I could get it to > places I don't have it. > > Unless power line networking really works, I believe that this trend > isn't going to change. Is there any progress in this area? I've seen > many promises, and few reliable working products. > > 3) As soon as you have two routers, you have at least two paths; the > wired connection between them and the wireless. You may have 3 paths, > if you have both 2.4 and 5ghz radios. Frequency diversity routing > becomes immediately interesting, along with using your ethernet when > it's available in preference to wireless. > > 4) an apartment building look like a mesh, and possibly with multiple > backhauls possibly with multiple ISP's. One should at least think about > what happens when you have "homes", in such a building, and make sure > nothing breaks. Wireless is messy: it isn't limited to where a wire > goes. Taking down an entire apartment building/blocks/city would not be > fun. I know, I've been there (at least to the point of taking down > buildings, and came within a week of a much larger scale disaster). > > If you believe 1 + 2 + 3 +4 (as I do), then if you look a few years > out, you end up with something in the "home" that begins to resemble > very strongly what the community mesh networking folks are doing at a > higher scale geographically and in terms of # of nodes today, with > many/most of the same concerns and solutions. Understanding the problems > they've faced/are facing is therefore worth a bit of investment; Radio > diversity is one of the concerns, and interference (of various sorts). Very good points. Much of the discussion has been focused on the single home in isolation. Curtis From curtis@occnc.com Wed Oct 12 16:40:52 2011 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 6C39721F853E for ; Wed, 12 Oct 2011 16:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy2xQzmdVElF for ; Wed, 12 Oct 2011 16:40:51 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id B5CC621F8500 for ; Wed, 12 Oct 2011 16:40:51 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9CNdUEB036107; Wed, 12 Oct 2011 16:39:31 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9CNdUEB036107 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318462771; bh=5vqF3+gqHWeKjQax2nExi2YaKZB34x+qeZU6K2GF4/g=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=Q8C3sSHadXhulNAz8ypK9s6pUqME+aa9wOWEDGA51EcPdnwOsBuzMLMl5im10clx+ mSel5Rq2V8+Zms/knsHVZuyc4fwPP564fn9LKA4JMYExR5zuKxwDvAQmmo0rob4HEx lhhE09tKYX1Yf8RvLCgs/oG9lSpmpcHie5HOcAPc= Message-Id: <201110122339.p9CNdUEB036107@gateway.ipv6.occnc.com> To: Stephen Farrell From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Oct 2011 23:13:37 BST." <4E94BF91.4060807@cs.tcd.ie> Date: Wed, 12 Oct 2011 16:39:30 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 23:40:52 -0000 In message <4E94BF91.4060807@cs.tcd.ie> Stephen Farrell writes: > > Hi, > > I've been reading the list with interest and have a question. > > When various devices in the home figure out which does what, > and do that periodically to handle changes, there's clearly > the potential that a zombied host tries to try take over > stuff with undesirable consequences. > > My question is whether this group are planning to think > about that now, or later, or never? (Or don't even think > there's a problem worth attempting to address.) > > Note - I'm not trying to argue for any particular level of > security and certainly not for some unachievable fort knox > everywhere, I'm just asking what's the plan? > > S. Watch out for autoconfig of microphones and cameras. :-) I call it bonding. Some ritual has to be performed before specific types of devices trust each other. Like the garage door opener and the clicker thingie. Same should be true of the audio system and the wireless speakers. The TV and remote use IR. The routers just route, but they need to be a bit more picky about who can configure them. Curtis From curtis@occnc.com Wed Oct 12 17:04:34 2011 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 0F4FC21F8AEE for ; Wed, 12 Oct 2011 17:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-MqBNDG8XV4 for ; Wed, 12 Oct 2011 17:04:33 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 4086D21F8AD8 for ; Wed, 12 Oct 2011 17:04:33 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D04VcQ009412; Wed, 12 Oct 2011 17:04:31 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D04VcQ009412 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318464271; bh=ba8Z/e0wXANN4PWTxqlCfcrzMNQ5qTGo/OBRrJv2Xx4=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=HwlQAXVH3gZqtODf6C9ARpkI3grldCoASDeEPsxHytujyCWGYKA939Sap8FRa+xjn TKHXecHzcJ6rVXiJ3NDuMBB1wIaKcaHv253FhAwf7cgDnZ0AmT2T7PRygxdoSjEssx LF3RVNL7vBHkFlYCfwzJa4mlWQMt6YBkTnXuHXGE= Message-Id: <201110130004.p9D04VcQ009412@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Oct 2011 20:38:59 EDT." <17786.1318379939@marajade.sandelman.ca> Date: Wed, 12 Oct 2011 17:04:30 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 00:04:34 -0000 In message <17786.1318379939@marajade.sandelman.ca> Michael Richardson writes: > >>>>> "Russ" =3D=3D Russ White writes: > Russ> You need a unique identifier at the equipment level for > Russ> anything you intend to auto-configure --autoconfiguring > Russ> uniqueness is a very hard, probably impossible, problem on a > Russ> global scale. So we need to count on this one thing, no matter > Russ> what else we might need to back in to. > > Russ> Now, it might be possible to some hash over a GPS location for > Russ> a "base," and then add on MAC addresses, or some such, but > > We've assumed a unique MAC, which is 48 bits long.=20 > But OSPF router-id is 32 bits. What is the likelyhood of a collision=20 > in the bottom 32-bits of the MAC?=20 Each organization has one or more unique OUI which includes one of the bottom four bytes. The next three (of those four) are unique only within the OUI which is the top three bytes (but with two bits given special meaning). So what are the chances that two organization start numbering the bottom bits at zero and work their way up until the bottom three bits are filled. Since there are way more than 256 organizations that have an OUI, collisions, while rare, can happen. If there is a way to recover from a collision, then its a complete non-issue and a random number can be used. Curtis From mcr@sandelman.ca Wed Oct 12 17:40:49 2011 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 07E8121F8548 for ; Wed, 12 Oct 2011 17:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhsICyxt0l3X for ; Wed, 12 Oct 2011 17:40:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9C821F853B for ; Wed, 12 Oct 2011 17:40:47 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id AF835343A2 for ; Wed, 12 Oct 2011 20:39:40 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 4A85198CAD; Wed, 12 Oct 2011 20:41:36 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4506098B2E for ; Wed, 12 Oct 2011 20:41:36 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 12 Oct 2011 20:41:36 -0400 Message-ID: <19820.1318466496@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Does ND Proxy useful for 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: Thu, 13 Oct 2011 00:40:49 -0000 >>>>> "Victor" == Victor Kuarsingh writes: Victor> These devices (in such operating modes) are however not Victor> likely to participate in a home network (as the gateway Victor> device or a router) and it's very unlikely to be the head of Victor> home network. I STRONGLY DISAGREE. Not only will smartphones be pressed into use whenever the primary ISP is down (I've done this three times in 18 months since I got a smartphone), but whenever there is an ad-hoc gathering of people who need network, they will insist that their smartphones be smart. I expect my smartphone to provide network to my Personal Area Network (whether via Bluetooth PAN or Zigbee), and I further expect that PAN to have an alternate exit via my HAN. I want to further point out that 3GPP and the mobile operators are no longer in control of what phones do. They are network devices. The only thing they can control is the protocol on the wire, and if they piss of the consumer, the consumer will simply tunnel. It's good that 3G will have PD in the future. I know that new versions of SIXXS AICCU now include it. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From curtis@occnc.com Wed Oct 12 17:51:18 2011 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 8F54F21F8B24 for ; Wed, 12 Oct 2011 17:51:18 -0700 (PDT) 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.080, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKjBThi4c-Ku for ; Wed, 12 Oct 2011 17:51:17 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id AD2C921F8B23 for ; Wed, 12 Oct 2011 17:51:17 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D0p2Xu071520; Wed, 12 Oct 2011 17:51:03 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D0p2Xu071520 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318467063; bh=ZRvlZ3yvy5yGM45RzQuf1cOvhAzXjzFWTnbrASFSFiM=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=RXK0RCSRApqB8f7NVoUIdmDb1L1WuXqUvMgYNY79Mgn+emP8U3f36TYoyFzkv9dsT bfRnN9DYX8m2A5NhW/8qd3Cjly6Bbv5yJksEBtSoh5BiVQbboQlkn1ngbI4ojQBUYl PUl6D/EG4Ta6pdIHj8GwJktrJkFozkZLEx3lkM2U= Message-Id: <201110130051.p9D0p2Xu071520@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Oct 2011 21:38:18 EDT." <159DBF45-107C-4C12-AE01-9BB494E8EEAE@fugue.com> Date: Wed, 12 Oct 2011 17:51:01 -0700 Cc: homenet@ietf.org, Michael Richardson Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 00:51:18 -0000 In message <159DBF45-107C-4C12-AE01-9BB494E8EEAE@fugue.com> Ted Lemon writes: > On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: > > However, I am thinking that we can perhaps bootstrap equipment that has > > never been configured (or has been factory reset) in some fashion such > > that if the equipment is "virginal" that it can essentially always try > > some default keys, and bring up enough networking to let all equipment > > be discovered and identified. There would be strong nag screens to get > > the user to up a network password. > > A pre-shared key that is pre-shared to every device is the same as no > key. So you might as well not bother with that complexity. > Conceivably CGA could be used to publish public/private key pairs > allowing devices to automatically recognize each other and present > their relationships in a UI for the end user to approve, but that's > not precisely plug and play. Agree completely on this. For example, having bumping the factory default button on a wireless camera open access to everyone would really be a bad idea. > I think the simplest thing would be to require that each device be > able to talk to a USB drive. Each device collects all the public keys > on the USB drive, and stores their own there. Devices then share > their public key with other devices identified on the USB drive, so > that as each device joins the network, the other devices learn about > it. This isn't bulletproof=97an infected PC that's configured with > these keys could be used to gain access to the keys, for example. But > it's a lot better than a well-known key. > > Of course, this isn't quite as plug and play as you seem to want, and > it requires that each device have a USB port, which might not be > acceptable. Plus, it would mean that the IETF would have to talk > about hardware, which seems like a bit of a non-starter. But I think > it's the right way to solve the problem. Mandating USB is not practical. For example I have a set of DECT phones with a single SIP base station. You can bond the phone to the base station but you have to enter a menu on the phone and do something on the base station (through the web interface or otherwise) within 10 seconds. Not perfect, but it works. There are too many cases like bonding the garage door opener to the clicker, or bonding the speakers to the audio system, etc, don't need to store keys on a USB as a boot strap. For some things USB would be fine. And my water heater, as facinating as it might be to the electrical utility, need not have the key to my garage door opener or my audio speakers, even though I might want to turn the hot water up or down a few degrees through a remote device some day. I would say that reinventing the kerberos KDC with ticket granting tickets and service tickets is probably overkill and should be out of scope. But it would be a truly wonderful thing if the interface could be made simple enough for a consumer to set up. Curtis From curtis@occnc.com Wed Oct 12 18:01:12 2011 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 66D3B21F8A67 for ; Wed, 12 Oct 2011 18:01:12 -0700 (PDT) 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.076, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFgX1ZqfLyc7 for ; Wed, 12 Oct 2011 18:01:11 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9523321F8801 for ; Wed, 12 Oct 2011 18:01:11 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D119Vc094661; Wed, 12 Oct 2011 18:01:09 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D119Vc094661 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318467669; bh=KzoLccEC3Z21maRCQkPAQkZgDm3XNGzhBT0S0Jnu/2c=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=fOTbwfuwffuYRtAjERa88Op7orYPqo7YnfCCdVazUFQ+2TB3I4W+74AakFX8thwWq qUhah85FkKDhXDr7QSD2e6SXiXBg/8oUMrq7nNcqCKDySbeEBIBu06LNOGlVi81CIG A7AD3ttF6tPAnqWRskKPaslEaSl+R1qlzxLqjXZQ= Message-Id: <201110130101.p9D119Vc094661@gateway.ipv6.occnc.com> To: Ulrich Herberg From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 11:28:46 +0800." <4E95096E.5020907@herberg.name> Date: Wed, 12 Oct 2011 18:01:08 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 01:01:12 -0000 In message <4E95096E.5020907@herberg.name> Ulrich Herberg writes: > Jari, > > On 10/11/11 12:05 PM, Jari Arkko wrote: > > Home routers would also have MAC addresses, but again, if we need a > > 32-bit quantity then shortened 48/64 bit identifiers may > > (theoretically) have collisions. > > > > That being said, if the home routers have to discover their IPv6 > > prefix through a protocol and store it in flash, they could probably > > do so also for a router ID. Unless there was some chicken and egg > > problem that required the router ID for all this discovery to work... > I agree. Since we need to configure unique prefixes to each router in > the home anyway, it should not be any problem to do the same for a > router ID (or even just use an address from the configured prefix as > router ID, which should then be unique). A while ago, there were some > plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop > network for configuring prefixes in the network. As in a home network, I > assume there is always at least one border router with the global > prefix, specifying something like that seems to be reasonable for me (in > a MANET, that can be more difficult, because there is not necessarily > such a central entity as the border router). > > Regards > Ulrich Ulrich, Whatever ends up being specified should require no configuration and work when there are: zero border routers providing a prefix (outage and/or partition) one border router providing a prefix (the easy case) multiple border routers providing a prefix For the large apartment building example that Jim gave, we really should consider scaling behavior when there are a large number of border routers providing a prefix within a given mesh. Curtis From marka@isc.org Wed Oct 12 18:19:45 2011 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 0ABB821F8B2A for ; Wed, 12 Oct 2011 18:19:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpYob8tXmUw8 for ; Wed, 12 Oct 2011 18:19:44 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 88E6C21F8B27 for ; Wed, 12 Oct 2011 18:19:44 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id A189AC9428 for ; Thu, 13 Oct 2011 01:19:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6A65C216C6C for ; Thu, 13 Oct 2011 01:19:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1F7051527D8B for ; Thu, 13 Oct 2011 12:19:29 +1100 (EST) To: homenet@ietf.org From: Mark Andrews References: <201110130101.p9D119Vc094661@gateway.ipv6.occnc.com> In-reply-to: Your message of "Wed, 12 Oct 2011 18:01:08 PDT." <201110130101.p9D119Vc094661@gateway.ipv6.occnc.com> Date: Thu, 13 Oct 2011 12:19:29 +1100 Message-Id: <20111013011929.1F7051527D8B@drugs.dv.isc.org> Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 01:19:45 -0000 While talking about hardware. These these devices all need a battery backed clock or all the crypto will be broken. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Oct 12 18:27:58 2011 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 9136A21F8B43 for ; Wed, 12 Oct 2011 18:27:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+rTDr+o8siN for ; Wed, 12 Oct 2011 18:27:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE3421F8B35 for ; Wed, 12 Oct 2011 18:27:58 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 79671C941E; Thu, 13 Oct 2011 01:27:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 41984216C6A; Thu, 13 Oct 2011 01:27:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9E687152810E; Thu, 13 Oct 2011 12:27:31 +1100 (EST) To: Jim Gettys From: Mark Andrews References: <201110130101.p9D119Vc094661@gateway.ipv6.occnc.com> <20111013011929.1F7051527D8B@drugs.dv.isc.org> <669F4202-6FD4-4F13-AE7B-E725D53AD874@gmail.com> In-reply-to: Your message of "Wed, 12 Oct 2011 21:22:51 EDT." <669F4202-6FD4-4F13-AE7B-E725D53AD874@gmail.com> Date: Thu, 13 Oct 2011 12:27:31 +1100 Message-Id: <20111013012731.9E687152810E@drugs.dv.isc.org> Cc: "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 01:27:58 -0000 In message <669F4202-6FD4-4F13-AE7B-E725D53AD874@gmail.com>, Jim Gettys writes: > Or you solve the time problem some other way... > > Batteries die too... > Jim Indeed. It should be a user servicable part. As to solving it other way, "leap of faith" springs to mind. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From curtis@occnc.com Wed Oct 12 18:38:16 2011 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 16E1B21F8B03 for ; Wed, 12 Oct 2011 18:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6LLAjjdw8aX for ; Wed, 12 Oct 2011 18:38:15 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17E21F8AF9 for ; Wed, 12 Oct 2011 18:38:15 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D1apKR032133; Wed, 12 Oct 2011 18:36:51 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D1apKR032133 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318469811; bh=WNj28t8NJ1omFlnaKRPuxX8JCmOW/Pwp/hzq3JyQ1IU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=RExCqG4c2eqeVUFGf3XHKl1d5Z+qTvOZ3Ftn2ujJP7fVk5V3QGsJQpmpYmX7GJNyH vXEG8ivN610JMnynr1kTijojfjD30jIRYpMVil5ZsgIWKPcUqcqQOFOxUmlbRdpo5k be5MxQlSBFtHb1jojo9CJXQzbZvEe3r+kNpEZTc4= Message-Id: <201110130136.p9D1apKR032133@gateway.ipv6.occnc.com> To: Ole Troan From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 10:48:00 +0200." <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> Date: Wed, 12 Oct 2011 18:36:50 -0700 Cc: homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 01:38:16 -0000 In message <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> Ole Troan writes: > > I've been reading the list with interest and have a question. > > > > When various devices in the home figure out which does what, > > and do that periodically to handle changes, there's clearly > > the potential that a zombied host tries to try take over > > stuff with undesirable consequences. > > > > My question is whether this group are planning to think > > about that now, or later, or never? (Or don't even think > > there's a problem worth attempting to address.) > > > > Note - I'm not trying to argue for any particular level of > > security and certainly not for some unachievable fort knox > > everywhere, I'm just asking what's the plan? > > can we explore some fundamental principles of how and what we need to > "secure"? Yes. Please do. > using the electricity network as an analogy, can we make a distinction > between "safety" and "security"? the electricity network in the home > is somewhat self protecting with breakers and earthing. a home > network must protect 'itself', i.e. handle any device plugged into it, > in any topology, external and internal attacks and so on. > > I don't think it is the networks job to control who has access to the > pictures of my grandmother or who can print to my printer. that's > application policy. Exactly. This is a multi-decade old debate. Should the applications be insecure and rely on a firewall? (Microsoft advocated this in the 1990s and it has stuck to a large extent). Or should the network be open and the applications secure? I'm strongly with you on this. The applications should take care of any security that is necessary *for that application*. > is it the networks job to control who has access to the network? no, I > think that is a layer 2 function. No. No. No. Security is not a layer-2 function. Security is an application function. You had it right the first time. Key exchanges and certificates are not layer-2 functions. It is entirely possible that the same computer has pictures of Grandma that I'm OK with you seeing and has a printer hanging off it that I don't want anyone in the world to be able to print on. Same MAC address. So that can't be a layer-2 function. And port filtering at a firewall is a lame excuse for security. The bug in relying on a firewall in an enterprise (a little less so for a home) is that once any one user downloads malware, that malware has access to everthing behind the firewall largely because of the assumption that security is not needed because there is a firewall. Lets not enshine the dumbest practices of the IT world. > I think homenet should focus on L3. (and be clear on what it expects > from the other layers with regards to security). > > cheers, > Ole Curtis From ulrich@herberg.name Wed Oct 12 18:44:19 2011 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 7038321F8B0D for ; Wed, 12 Oct 2011 18:44:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzUq3leSVsps for ; Wed, 12 Oct 2011 18:44:18 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48E4721F8B0C for ; Wed, 12 Oct 2011 18:44:18 -0700 (PDT) Received: by bkbzv3 with SMTP id zv3so844959bkb.31 for ; Wed, 12 Oct 2011 18:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=KG1rYQJsYozn487ov7WkVn7iJ7DCv3izcvMhkpjIhIM=; b=anGxOl9UY2qlq8BcGzpk79CdR013H68sz8wVY2dvqZ89aez3S5FrNjlRTbDQg3VIMN QxlHC5yrrR0AYn4M0zmIIZoxSMO1LPDIkW9ukZDMR2nybPcjHaUlNu7krXxIKUh359wn KnihVGRg2c8cf+KvepqYhrRuOFWcQ4xke5lVk= Received: by 10.223.65.68 with SMTP id h4mr2524568fai.24.1318470257213; Wed, 12 Oct 2011 18:44:17 -0700 (PDT) Received: from g008.tum.vpn.lrz.de (g008.tum.vpn.lrz.de. [129.187.100.8]) by mx.google.com with ESMTPS id a7sm7265459fam.22.2011.10.12.18.44.14 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 18:44:16 -0700 (PDT) Message-ID: <4E96426B.9010100@herberg.name> Date: Thu, 13 Oct 2011 09:44:11 +0800 From: Ulrich Herberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <9D653F74-E89B-4FBD-AF72-A01B2229943E@cisco.com> <4E9494A9.4030901@freedesktop.org> <5E02E5EF-B801-44C5-A6A7-FAF17CDBFCBB@cisco.com> <4E957F43.1060207@riw.us> In-Reply-To: <4E957F43.1060207@riw.us> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Thoughts about routing - trends 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, 13 Oct 2011 01:44:19 -0000 On 10/12/11 7:51 PM, Russ White wrote: > [...] > > While I wouldn't want to rule OLSRv2 completely out, I think it should > compete head to head with an extended OSPF and an extended IS-IS, or > even other efforts afoot. I'd rather see requirements first, and a good > solid evaluation of what's available against those requirements, rather > than choosing technologies out of the gate. Hi Russ, I fully agree. There should be an evaluation against the requirements. My point was just not to rule out OLSRv2 (or other protocols) based on the fact that a protocol is used, amongst other, in mesh network deployments. Ulrich From curtis@occnc.com Wed Oct 12 19:08:57 2011 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 7980621F8A4E for ; Wed, 12 Oct 2011 19:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNRiYQFHV90j for ; Wed, 12 Oct 2011 19:08:56 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 8E13D21F893C for ; Wed, 12 Oct 2011 19:08:56 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D27S1O081717; Wed, 12 Oct 2011 19:07:29 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D27S1O081717 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318471650; bh=RAaaAXj58+D682r3aNoEHOVhSSoA8nb99B/zLMnJOOE=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=AZkimSQt92IFHkuaIf0QL70bnS7Ea78ZSShde3IbvNL0MzYT0e+sIf5nP6GSriCOu nwSPO/rYOO2K+MBpIEk9NdGSEDlGnTlInICQN8z+tsD+yu3eMN4SRaqyT9wa4zeO0/ jfe29zLMpoPpXVxun9/ZrAvqjh1zCgwbmPpUOyTo= Message-Id: <201110130207.p9D27S1O081717@gateway.ipv6.occnc.com> To: Stephen Farrell From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 10:23:32 BST." <4E955C94.3060707@cs.tcd.ie> Date: Wed, 12 Oct 2011 19:07:28 -0700 Cc: Ole Troan , homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 02:08:57 -0000 In message <4E955C94.3060707@cs.tcd.ie> Stephen Farrell writes: > On 10/12/2011 09:48 AM, Ole Troan wrote: > >> I've been reading the list with interest and have a question. > >> > >> When various devices in the home figure out which does what, > >> and do that periodically to handle changes, there's clearly > >> the potential that a zombied host tries to try take over > >> stuff with undesirable consequences. > >> > >> My question is whether this group are planning to think > >> about that now, or later, or never? (Or don't even think > >> there's a problem worth attempting to address.) > >> > >> Note - I'm not trying to argue for any particular level of > >> security and certainly not for some unachievable fort knox > >> everywhere, I'm just asking what's the plan? > > > > can we explore some fundamental principles of how and what we need to "secure"? > > > > using the electricity network as an analogy, can we make a distinction between "safety" and "security"? > > the electricity network in the home is somewhat self protecting with breakers and earthing. > > a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks > > and so on. > > > > I don't think it is the networks job to control who has access to the pictures of my grandmother or who can print to my printer. that's application policy. > > > > is it the networks job to control who has access to the network? no, I think that is a layer 2 function. > > > > I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security). > > Reasonable points. However, if the zeroconf stuff provides an easy > way for a bad device to take over the homenet and get everything > interesting routed via it, that seems like a bad thing. That's > really what I was asking about, not application layer security, > nor layer 2 (though some layer 2 security can probably help a bit > if its turned on). > > Again, I'm not asking for some complex new scheme to be invented > here, I'm just asking whether the group are planning to address > this issue and roughly when. (In the hope that the answers are > something close to "yes" and "as an integrated part of the work":-) > > S. You concern may boil down to. Should we be worried that Grandma is still running Windows 98? [Or that the same company that gave us Windows 95 and 98 can't get their act together with security after being beat up about it for over a decade.] Application layer security over a sound foundation is the right place for security. A practical consequence of horribly insecure OS code from one major supplier for more than a decade is that firewall functionality is also more than just nice to have in enterprise and home network equipment. OTOH - If the PC user runs flash for example, there is no way the network can protect them from the myriad of security holes that keep popping up and getting fixed all too slowly. ... and then there are the discount brokerages that run flash on their web sites insuring that their users will have flash installed and enabled and probably won't disable it when going elsewhere on the web. [oh well]. The network cannot protect the world from really bad application (or OS) programmers. Recognizing this may be a first step to solving it the right way - with a robust OS and more secure applications. Curtis From curtis@occnc.com Wed Oct 12 19:28:37 2011 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 797C321F8B0A for ; Wed, 12 Oct 2011 19:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VDbsFt8Y0UO for ; Wed, 12 Oct 2011 19:28:36 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE4F21F8B09 for ; Wed, 12 Oct 2011 19:28:36 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D2SY8E085862; Wed, 12 Oct 2011 19:28:35 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D2SY8E085862 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318472915; bh=FobQUui8X5uv0ct5lhsHCl6X624QTwTNbDqfEzCE2Mk=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=dR3HTe8io/V2Y9WGsDiZlUzvKpw8xAXlzaum4KOu8E9oEDFFPqopD/sKRBDqDyxQ8 WckiTnuxCv8lmMq6NUWYae+OISPPhu7RtiwiOx1CYXMksgMuI1hxM+8nm2HGbVtlZX 8UwKZlsZhd6WvD6eyjBDxOn3BlQdYsi3uF/IbAN0= Message-Id: <201110130228.p9D2SY8E085862@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 07:51:31 EDT." <4E957F43.1060207@riw.us> Date: Wed, 12 Oct 2011 19:28:34 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing - trends X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 02:28:37 -0000 In message <4E957F43.1060207@riw.us> Russ White writes: > > >> You are absolutely right that pulling cable is hard and expensive. > > Pulling cable is indeed hard and expensive. In my experience, it is > > the right thing for some applications, such as TV and my home > > office. Personally, I have both wired and wireless throughout the > > house; my personal rule is that I use the shared wireless network > > for activities that move around, to provide convenience at the > > expense of consistency and bandwidth, and wired for things that > > stand still, to provide stable bandwidth at the price of a one-time > > wiring effort. > > I do the same --I pull cable for televisions, and even for locations > where a desktop or laptop is going to be sitting on a regular > basis. So I think we should expect wired and wireless as the norm, > rather than expecting wireless all the time. > > While I wouldn't want to rule OLSRv2 completely out, I think it should > compete head to head with an extended OSPF and an extended IS-IS, or > even other efforts afoot. I'd rather see requirements first, and a > good solid evaluation of what's available against those requirements, > rather than choosing technologies out of the gate. > > :-) > > Russ Russ, At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted pair. [Well someone pulled it, but not me.] Anyone remember vampire taps in 10base2? What a reliability headache! I pulled 10base5 coax at home before I pulled twisted pair and before trying the early DEC Wavlan stuff that preceeded WiFi (again, at home). Too bad I moved and had to pull wire again (but I like the result). Back on topic: I do think we should consider OSPF (not so keen on ISIS, but OK) and should not rule out OLSRv2 or other LLN related work and MANET work (though I'm far from an expert on LLN or MANET). We will have to extend OSPF to make zero config possible. The extensions should be completely backwards compatible if at all possible. Curtis From curtis@occnc.com Wed Oct 12 19:47:01 2011 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 38F8421F8C60 for ; Wed, 12 Oct 2011 19:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PmEj2-M8DsV for ; Wed, 12 Oct 2011 19:47:00 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 53F5A21F8C53 for ; Wed, 12 Oct 2011 19:47:00 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D2kwmM086317; Wed, 12 Oct 2011 19:46:59 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D2kwmM086317 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318474019; bh=NLqwXf7yPMQqRUWa+1MJv+KhC1wUE3NdA4tt/5UrymY=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=dt0to1qDNq1/mhUiSkdxF0Gf48OdImzJtGm/LMbreU00bfdEVuatG+Fo12yddJvrb 7oQx7wra1LM8HcvcZJ/39iG3xQ78SahnzUTTwbuXRBgtr864aGpg8VcQS7V6HmP0Oc G04dg3MhwS+lxg9WnMAvD/tJmfgmyMrFVyziRfC0= Message-Id: <201110130246.p9D2kwmM086317@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 08:09:17 EDT." <4E95836D.4020307@riw.us> Date: Wed, 12 Oct 2011 19:46:58 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 02:47:01 -0000 In message <4E95836D.4020307@riw.us> Russ White writes: > > > Russ> You need a unique identifier at the equipment level for > > Russ> anything you intend to auto-configure --autoconfiguring > > Russ> uniqueness is a very hard, probably impossible, problem on a > > Russ> global scale. So we need to count on this one thing, no matter > > Russ> what else we might need to back in to. > > > > Russ> Now, it might be possible to some hash over a GPS location for > > Russ> a "base," and then add on MAC addresses, or some such, but > > > > We've assumed a unique MAC, which is 48 bits long. > > But OSPF router-id is 32 bits. What is the likelyhood of a collision > > in the bottom 32-bits of the MAC? > > Ah, I see the problem... There is a pretty high likelihood of a > collision, actually, at least as long as you use multiple vendors in > your home network. It's bound to happen to someone, someplace. > > So, a suggestion to resolve this: > > 1. Use the lower 32 bits of one of the mac addresses on the box as the > initial id. > > 2. Add a new field to the router capabilities that carries the full 48 > bit mac address, or even some munged together "longer id," based on > multiple mac addresses on the device, or some such. Not backwards compatible. The older OSPF routers will see only the non-unique 32 bits and the network won't work. > 3. During initial setup, if you receive a capability that appears to be > from yourself, you open this secondary id section to find out if it's > really you, or someone else who happens to have the same 32 bit id. > > 4. If it's really you, discard the packet. > > 5. If it's not really you, and if the other router's "large id" is lower > than yours, choose another mac address from which to take your local id, > and restart your ospf process. > > 6. If it's not really you, and the other router's "large id" is higher > than yours, then send a router capabilities LSA unicast to this "other > router," so the "other router" knows to change its id. > > I don't think IS-IS would have this problem. > > :-) > > Russ If the other router doesn't implement the extension you've described, the network is hosed forever. If you have more than one link you should receive the LSA (or LSPDU) that you advertised. If you have one link, you won't. If you receive a LSA (or LSPDU) that clearly you didn't advertise, then you have a collision. *Both* routers should pick a new router-id if this condition is detected and they implement this extension. Don't even bother using a MAC address for the router-id. Use a random number. If a collision occurs, use a different random number. This should also work for interfaces without a MAC (not that many homes run POS today, but maybe some layer-2 in the future). Here is where it if fuzzy if one router is a legacy router. It may not look at LSA (or LSPDU) apparently from itself or may just log a problem and continue. When backing off, the bogus advertisements need to be withdrawn. A possible backward compatibility wrinkle exists if the legacy router does not readvertise (being legacy it will not pick a new router-id). The problem could persist for maxage. Better than forever but still not good. Don't use a non-configured router-id if you don't support this ability to back off. (Routers today don't pick a random router-id and they shouldn't unless they can backoff). Curtis From curtis@occnc.com Wed Oct 12 19:58:55 2011 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 A872E21F8C92 for ; Wed, 12 Oct 2011 19:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOEAnZr-QToC for ; Wed, 12 Oct 2011 19:58:55 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id CFFFB21F8C7B for ; Wed, 12 Oct 2011 19:58:54 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D2vJO5086601; Wed, 12 Oct 2011 19:57:19 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D2vJO5086601 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318474640; bh=GnUJxGcVyQxMSjomEQbYfhzdkWi6kRcNadR2Efq3yY4=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=nCTi/COmDThrBO7xttxHtFBU9uAp6zx2XU2318LDihFKakmAHSYujP4mC6EyhdMuX 2PuTGTRxDylP65uXDoA1UgzFkqXMu/04fGosuVRq0tLasYIltGylMSFf7GiLmeFLcU 89am92Nbgtw3OQbnbfWagOdKsnI1SqBfQ6Ggdoyc= Message-Id: <201110130257.p9D2vJO5086601@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 08:33:19 EDT." Date: Wed, 12 Oct 2011 19:57:18 -0700 Cc: Ole Troan , homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 02:58:55 -0000 In message Ted Lemon writes: > On Oct 12, 2011, at 4:48 AM, Ole Troan wrote: > > using the electricity network as an analogy, can we make a > > distinction between "safety" and "security"? > > the electricity network in the home is somewhat self protecting with > > breakers and earthing. > > a home network must protect 'itself', i.e. handle any device plugged > >into it, in any topology, external and internal attacks > > and so on. > > I am highly sympathetic to the desire not to try to solve this > problem. However, unfortunately network topology isn't the same as > electrical topology, for a couple of reasons. > > The first reason is that electrical systems are generally set up by > professionals. Yes, you plug devices into the electrical wiring of > your house, but someone skilled set it up (or if not, I hope you sleep > in asbestos pajamas). The devices we are talking about are more > analogous to circuit distribution panels than to toasters. > > The second reason is that electrical systems are essentially > topology-free. Any point on the system is essentially equivalent to > any other. This is not true of a home network with routing. What we > are talking about is essentially the possibility of rogue distribution > panels intentionally or accidentally being connected to your > distribution system. =20 The electricity analogy is not very useful. Maybe best to drop it. > Which is a result of the third reason: home networks are typically > wireless, or partially wireless, and so there is no physical security, > unlike an electrical network in a house, which is secure by virtue of > being entirely enclosed by the house. > > I think what you are getting at is that we cannot be responsible for > securing the network. And that is probably true. But if the system > doesn't have a built-in mechanism for distinguishing between friend > and stranger, the autoconfiguration mechanism will create topologies > that aren't desired, either by accident or because a stranger wants > access to the network. If applications are secure, the only threat to a wide open network is theft of service. WPA provides a knob to stop that. The only question is whether WPA or any WiFi security should be enabled by default. Is it better to leave the possibility of theft of service or is it better to have the device unusable by default (until configured)? For provider equipment that is always configured, the latter (unusable until configured). For home equipment where the customer wants to unpack the box, plug it in and use it, the former is better (make it usabled but allow possible theft of service). Every WiFi product I ever bought was open WiFi as shipped. Curtis From curtis@occnc.com Wed Oct 12 20:04:57 2011 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 54B7221F8C95 for ; Wed, 12 Oct 2011 20:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP3NGXZ9S0yA for ; Wed, 12 Oct 2011 20:04:56 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1821F8C92 for ; Wed, 12 Oct 2011 20:04:56 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D34qCL086856; Wed, 12 Oct 2011 20:04:52 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D34qCL086856 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318475093; bh=OcLt6oxbWLKI52WIbqMi4QE/Ykqzw0EoctNDXOYBcxo=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=EdX3Pyu0qmzvgcghiZYLMSzo11NN37Ol5mKUWl1u1igrEVRQ6UOztR8RUew9MNsX1 FJJ0PBVqn3wbWgRHI8Ht/ECF1VqsjJhJJRkC/6EVokVjQtPsR4CR47c+A2ecpnvKyV kreQ3EtkrIQ/XWkvX6WpFD2gKR3Jr9D6kmlkqZ2U= Message-Id: <201110130304.p9D34qCL086856@gateway.ipv6.occnc.com> To: Victor Kuarsingh From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 12:04:53 EDT." Date: Wed, 12 Oct 2011 20:04:51 -0700 Cc: Rajeev Koodli , homenet@ietf.org, Michael Richardson , Mark Townsley Subject: Re: [homenet] Does ND Proxy useful for homenet? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 03:04:57 -0000 In message Victor Kuarsingh writes: > Mark, > > A few points on this topic. > > As noted, the Cell system will have PD capabilities until a future 3GPP > release (Rel-10) as noted. Although, even when the functionality is in > place (generally), small devices like Smartphone and the mini gateways > (3G/LTE devices which allow for 4-5 hosts to attached to Cell system) - > PDs may not be used. > > Many of these devices (I.e in the case of the smartphone) have modes of > operation where they "tether", which turns them into a mini gateway. They > are not likely to be be full blown gateways equivalent to what you see > common CPEs. > > In the IPv4 case, these devices "NAT" the IPv4 private addresses used by > hosts behind the device to the network assigned address. In the case of > IPv6, it will have access to the network assigned ::/64. PCs (maybe other > devices) behind such devices will need access to the IPv6 network, but may > not have access to PD space. This was one of the specific use cases I was > eluding to before. > > These devices (in such operating modes) are however not likely to > participate in a home network (as the gateway device or a router) and it's > very unlikely to be the head of home network. > > With this explanation, I am not sure if this should/would be considered as > such in HomeNet. These devices technically become gateways/bridges to the > Internet. And the hosts that use them are often the same type of devices > which connect to common home networks. > > Regards, > > Victor K Victor, And if I'm at home with WiFi at home and my laptop plugged into the Internet and plug in the USB (or other tether) to update my contacts list on the phone, because its easier/faster, we have the situation described, even though the intent was not to use the phone as an IP gateway. This gets back to users plugging things in in seemingly arbitrary way that made sense to them at the time for some reason. Curtis > On 11-10-10 4:51 PM, "Rajeev Koodli" wrote: > > > > >Hi, > > > >The smartphone will only get a /64 in the current 3G/4G releases (rel-8, > >rel-9). > > > >Prefix delegation is specified in Rel-10. > > > >-Rajeev > > > > > > > >On 10/10/11 1:01 PM, "Mark Townsley" wrote: > > > >>> > >>> Or are you saying a mobile device (a smartphone) will only ever get a > >>> /64 to share? > >> > >> My (limited) understanding of the various 3/4G standards are that a PD > >>for a > >> phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or > >> someone else here can elucidate. > >> > >> - 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 From victor.kuarsingh@gmail.com Wed Oct 12 20:38:36 2011 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 402DE21F8ACA for ; Wed, 12 Oct 2011 20:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrq4JLyl79Qe for ; Wed, 12 Oct 2011 20:38:34 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD0621F8A71 for ; Wed, 12 Oct 2011 20:38:34 -0700 (PDT) Received: by pzk37 with SMTP id 37so1641382pzk.9 for ; Wed, 12 Oct 2011 20:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xsk/NMuE3Y1u8EDryj3f+wkI8wis/d8tCFS4Dnx60xI=; b=kwnAEYv7D9YuciM0rQlli0dyCDk+Do+sCGMYiNwWFC/axPhhJREjj8CoZJ/Ny5t4Fo kpe2uz9Unh1n/zuWiDuuWj/dgvR5aE89OfBmlw2OXaX/+Soe3KiNfKr0+TeBuWEr4QOy uDqpfG2y31KrmsW1aVAIivxb+7j5WkDzi2Ydc= MIME-Version: 1.0 Received: by 10.68.38.8 with SMTP id c8mr5623742pbk.42.1318477111368; Wed, 12 Oct 2011 20:38:31 -0700 (PDT) Received: by 10.68.59.226 with HTTP; Wed, 12 Oct 2011 20:38:31 -0700 (PDT) In-Reply-To: <19820.1318466496@marajade.sandelman.ca> References: <19820.1318466496@marajade.sandelman.ca> Date: Wed, 12 Oct 2011 23:38:31 -0400 Message-ID: From: Victor Kuarsingh To: Michael Richardson Content-Type: multipart/alternative; boundary=bcaec51dd579de1deb04af25df95 Cc: homenet@ietf.org Subject: Re: [homenet] Does ND Proxy useful for 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: Thu, 13 Oct 2011 03:38:36 -0000 --bcaec51dd579de1deb04af25df95 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 12, 2011 at 8:41 PM, Michael Richardson wrote: > > >>>>> "Victor" == Victor Kuarsingh writes: > Victor> These devices (in such operating modes) are however not > Victor> likely to participate in a home network (as the gateway > Victor> device or a router) and it's very unlikely to be the head of > Victor> home network. > > I STRONGLY DISAGREE. > That's fine. My statement was based on an aggregate set of behaviors over millions of endpoints. Corner cases always exist (and perhaps not so corner in the future). > > Not only will smartphones be pressed into use whenever the primary ISP > is down (I've done this three times in 18 months since I got a > smartphone), but whenever there is an ad-hoc gathering of people who > need network, they will insist that their smartphones be smart. > Sure, a number of people seem to do this and tether their phones for Internet Access. Although performance is somewhat degraded as Smartphones don't seem to make very good routers (performance wise - but this may change). Notice I did not say "never", I said "not likely". > > I expect my smartphone to provide network to my Personal Area Network > (whether via Bluetooth PAN or Zigbee), and I further expect that PAN to > have an alternate exit via my HAN. > Understood. However is that what most people will expect? Perhaps one can argue yes. > > I want to further point out that 3GPP and the mobile operators are no > longer in control of what phones do. They are network devices. I guess this is true to some extent. There is value in having standards in this area which make things work in a relatively complex environment. > The > only thing they can control is the protocol on the wire, and if they > piss of the consumer, the consumer will simply tunnel. > I guess some may tunnel. Not sure if most would. > It's good that 3G will have PD in the future. > I know that new versions of SIXXS AICCU now include it. > > PD is in the spec. But when it sees the light of day in actual deployments (network + devices) is the key. regards, Victor K -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > then sign the petition. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --bcaec51dd579de1deb04af25df95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 12, 2011 at 8:41 PM, Michael= Richardson <mcr@s= andelman.ca> wrote:

>>>>> "Victor" =3D=3D Victor Kuarsingh <victor.kuarsingh@gmail.com> w= rites:
=A0 =A0Victor> These devices (in such operating modes) are however not<= br> =A0 =A0Victor> likely to participate in a home network (as the gateway<= br> =A0 =A0Victor> device or a router) and it's very unlikely to be the= head of
=A0 =A0Victor> home network.

I STRONGLY DISAGREE.

That's fine. M= y statement was based on an aggregate set of behaviors over millions of end= points. =A0Corner cases always exist (and perhaps not so corner in the futu= re).
=A0

Not only will smartphones be pressed into use whenever the primary ISP
is down (I've done this three times in 18 months since I got a
smartphone), but whenever there is an ad-hoc gathering of people who
need network, they will insist that their smartphones be smart.

Sure, a number of people seem to do this and tethe= r their phones for Internet Access. =A0Although=A0performance=A0is somewhat= =A0degraded=A0as=A0Smartphones=A0don't seem to make very good routers (= performance wise - but this may change). =A0Notice I did not say "neve= r", I said "not=A0likely".
=A0

I expect my smartphone to provide network to my Personal Area Network
(whether via Bluetooth PAN or Zigbee), and I further expect that PAN to
have an alternate exit via my HAN.

Unde= rstood. =A0However is that what most people will expect? =A0Perhaps one can= argue yes.
=A0

I want to further point out that 3GPP and the mobile operators are no
longer in control of what phones do. =A0They are network devices.

I guess this is true to some extent. =A0There is va= lue in having standards in this area which make things work in a=A0relative= ly=A0complex=A0environment.
=A0
=A0The
only thing they can control is the protocol on the wire, and if they
piss of the consumer, the consumer will simply tunnel.

I guess some may tunnel. =A0Not sure if most would.
=A0
=A0
It's good that 3G will have PD in the future.
I know that new versions of SIXXS AICCU now include it.


PD is in the s= pec. =A0But when it sees the light of day in actual deployments (network=A0= +=A0devices) is the key.



=

regards,

Victor K=A0

=
--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.
___________________________________= ____________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--bcaec51dd579de1deb04af25df95-- From victor.kuarsingh@gmail.com Wed Oct 12 20:48:34 2011 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 4DAB221F8B1C for ; Wed, 12 Oct 2011 20:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKZRvUtrqi7d for ; Wed, 12 Oct 2011 20:48:33 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0FF321F8B19 for ; Wed, 12 Oct 2011 20:48:33 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1642697ggn.31 for ; Wed, 12 Oct 2011 20:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RMgHZDhMM5Q1oCdtb1I+NEF+szq3WiTM52Z8M0c12VU=; b=yBPsqM5fhvO1tm68sHURINNhC8kXIjEzVuyGFJ2IxxKYJv8Zg/peTSsJiFMY5Qt4f4 T3z5raoxsVRxotxEszUd+KAjm3pZpiR3WAkDsKOAx+9MR9YF+enCxpDMGEE12k7e+8Rd wfSHNdUDidOGNtXSLFXglfijSmTnhE40X8kMI= MIME-Version: 1.0 Received: by 10.68.27.227 with SMTP id w3mr5647934pbg.59.1318477712795; Wed, 12 Oct 2011 20:48:32 -0700 (PDT) Received: by 10.68.59.226 with HTTP; Wed, 12 Oct 2011 20:48:32 -0700 (PDT) In-Reply-To: <201110130304.p9D34qCL086856@gateway.ipv6.occnc.com> References: <201110130304.p9D34qCL086856@gateway.ipv6.occnc.com> Date: Wed, 12 Oct 2011 23:48:32 -0400 Message-ID: From: Victor Kuarsingh To: curtis@occnc.com Content-Type: multipart/alternative; boundary=bcaec520eab5b7285204af260340 Cc: Rajeev Koodli , homenet@ietf.org, Michael Richardson , Mark Townsley Subject: Re: [homenet] Does ND Proxy useful for 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: Thu, 13 Oct 2011 03:48:34 -0000 --bcaec520eab5b7285204af260340 Content-Type: text/plain; charset=ISO-8859-1 > > > > And if I'm at home with WiFi at home and my laptop plugged into the > Internet and plug in the USB (or other tether) to update my contacts > list on the phone, because its easier/faster, we have the situation > described, even though the intent was not to use the phone as an IP > gateway. > I can see your point. So in this case.. I guess your computer/laptop would belong to two networks (wired USB and Home Network over WiFi). Not sure if this example shows how the two networks join - unless the computer bridges/routes traffic. > > This gets back to users plugging things in in seemingly arbitrary way > that made sense to them at the time for some reason. > Would you say this example adds merits to ND for the smartphone gateway function, or the opposite? regards, Victor K > Curtis > > > --bcaec520eab5b7285204af260340 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


And if I'm at home with WiFi at home and my laptop plugged into the
Internet and plug in the USB (or other tether) to update my contacts
list on the phone, because its easier/faster, we have the situation
described, even though the intent was not to use the phone as an IP
gateway.

I can see your point. So in th= is case.. I guess your computer/laptop would belong to two networks (wired = USB and Home Network over WiFi). =A0Not sure if this=A0example=A0shows how = the two networks join - unless the computer bridges/routes traffic.
=A0

This gets back to users plugging things in in seemingly arbitrary way
that made sense to them at the time for some reason.
<= br>
Would you say this example adds merits to ND for the smartpho= ne gateway function, or the opposite?

=A0
regards,

Victor K


Curtis


<= /div> --bcaec520eab5b7285204af260340-- From curtis@occnc.com Wed Oct 12 20:57:46 2011 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 DA69C21F8B1F for ; Wed, 12 Oct 2011 20:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdUSEAjfi5KB for ; Wed, 12 Oct 2011 20:57:46 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 09F1421F8B1E for ; Wed, 12 Oct 2011 20:57:45 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D3vg1S088885; Wed, 12 Oct 2011 20:57:42 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D3vg1S088885 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318478263; bh=7acvqBC7yGdPGdebwg59sVD9OJGKRWwtCk2CTblLfr4=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=DwChL8qbOLK2/Mu5lx6LoqI1NEfuwOEUFub09pgeZKm2EqRw9ENyDODI9WKIQYlka On31e54+wgyMq/W4sCnF9Yy5fn5Bv8MjNdwZLk/JH/8RJVy6wN6UJRuHrsAhNLag4v 39IzJW77mCSzRboIJ0yJBT2AN4+f/R5fQsVYyWhI= Message-Id: <201110130357.p9D3vg1S088885@gateway.ipv6.occnc.com> To: james woodyatt From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 15:23:04 PDT." <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> Date: Wed, 12 Oct 2011 20:57:41 -0700 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet strawman slides X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 03:57:47 -0000 In message <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> james woodyatt writes: > On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote: > > > > A router should not start handing out PD or even IPv4 NAT space > > until it gets and address from elsewhere. btw - the valid point about serving the site needs was brought up, so some assignment would be needed in absense of an uplink. > Some routers need to do this, i.e. home routers where service > providers charge prohibitive rates for always-on Internet dial-tone > and expect subscribers to connect on demand and disconnect after an > appropriate idle time. For on-demand routing, it makes sense for the router to hand out an address while not being connected. I personally haven't seen that since 56K modems, but OK. (And I had FR back then). For the DSL and MSO services I've used, the service was "always up", unless of course you powered down the CPE. > For IPv4 today, these routers typically use PPPoE on the WAN and they > often handle this by assigning RFC 1918 address to the LAN hosts and > using DNS queries to signal PPPoE to establish the WAN link. OK. Client does DNS and that is the "on demand" part. Fine. In in absence of DNS, a ping or TCP SYN would bring it up. > For IPv6, I'm not sure what they should do, but I have some ideas. > Basically, the router should advertise as a default router with a > single ULA prefix and a DNS server at the router's ULA interface > address with RFC 6106 and optionally RFC 3736. When the DNS query > signals PPPoE to establish the WAN link, the DHCPv6 client will ask > for a IA_PD and update the prefix advertised on the LAN accordingly. > > I'm not sure this model can be made to work with IPv6, but I wouldn't > put it past the telcos to try. With IPv6 there is no reason that the CPE can't be assigned a persistant address but bring the connection down. On power up it could connect and get it, then bring the link down in the absence of traffic. Usually if it is powered up it is because someone want to use it, so this would be fine. There is no reason not to hold the IA_PD assignment at the CPE when an on demand link is down. That prefix can be requested in the IA_PD request when there is demand again, just to refresh it and confirm. The same DNS query can be used as the trigger in on-demand IPv6 as well. Curtis From curtis@occnc.com Wed Oct 12 21:08:24 2011 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 86A4921F89B8 for ; Wed, 12 Oct 2011 21:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSubaX2gvyyf for ; Wed, 12 Oct 2011 21:08:24 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C883221F8AF9 for ; Wed, 12 Oct 2011 21:08:23 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D48MRN089221; Wed, 12 Oct 2011 21:08:23 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D48MRN089221 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318478903; bh=CbUB+HbJowDWhBGJqWfObnmiWSl1Vcbto6ZgFwGOZmA=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=X5EfwK5HqOyV4YiieJ0sXQVWlb+FwKVkBD/Cf9FmPk4U+TNSr8vu8JcZTYPanDqaV /ldkAQonch+usmj6cwe6e38CAAOT5mC/FAu0jUMoPHihsz+a+lGyhOjzAfYTIYD7hO tSDR5C2ZJ2ffo0NNKhfIehsAlI7/9vls9YAHTg9o= Message-Id: <201110130408.p9D48MRN089221@gateway.ipv6.occnc.com> To: Mark Andrews From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 12:19:29 +1100." <20111013011929.1F7051527D8B@drugs.dv.isc.org> Date: Wed, 12 Oct 2011 21:08:22 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 04:08:24 -0000 In message <20111013011929.1F7051527D8B@drugs.dv.isc.org> Mark Andrews writes: > > While talking about hardware. These these devices all need a battery > backed clock or all the crypto will be broken. Having a clock is not hard but I don't think your statement is true. Some crypto does not require time, but rather just entropy (a nonce or challenge). For crypto that does require time the former can be a bootstrap of sorts, possibly to get ntp going if very accurate time is needed (for some reason). For example ssh with rsa or dsa does not require time. You need to know what month and year it is to be good enough as far as checking certificates. A lot of the KARP work does require knowing the time to prevent replay attack. Curtis From curtis@occnc.com Wed Oct 12 21:37:54 2011 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 2574B21F86FF for ; Wed, 12 Oct 2011 21:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHntAgnzhRZs for ; Wed, 12 Oct 2011 21:37:53 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 4665B21F869E for ; Wed, 12 Oct 2011 21:37:53 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9D4biqg090942; Wed, 12 Oct 2011 21:37:45 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9D4biqg090942 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318480665; bh=xUdXDJrwxv84cKS0OhBQYzHbRf206sqbukPiM1SUGsw=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=mSmQhhV4u6sebzc9LrijP3MWPMxNj7CGxyVXn++WDu66rd5dKOAHgyiYK4NFt0feC KsHZCJFyey562vv50RD63lFb4NuNzo0NVb+YVvG+aK8giCxF59TKwcEfxkUzgMFxMB +Q3nZ++HAHr/i8Q9Adr2jvmaY40N7TI9i9DkVKEY= Message-Id: <201110130437.p9D4biqg090942@gateway.ipv6.occnc.com> To: Victor Kuarsingh From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Oct 2011 23:48:32 EDT." Date: Wed, 12 Oct 2011 21:37:44 -0700 Cc: Mark Townsley , Rajeev Koodli , homenet@ietf.org, Michael Richardson , curtis@occnc.com Subject: Re: [homenet] Does ND Proxy useful for homenet? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 04:37:54 -0000 In message Victor Kuarsingh writes: > > > > And if I'm at home with WiFi at home and my laptop plugged into the > > Internet and plug in the USB (or other tether) to update my contacts > > list on the phone, because its easier/faster, we have the situation > > described, even though the intent was not to use the phone as an IP > > gateway. > > I can see your point. So in this case.. I guess your computer/laptop > would belong to two networks (wired USB and Home Network over WiFi). > Not sure if this example shows how the two networks join - unless the > computer bridges/routes traffic. Good point. The computer would have three ways to pick from. Maybe the phone acting as a WiFi was a better example. > > This gets back to users plugging things in in seemingly arbitrary way > > that made sense to them at the time for some reason. > > Would you say this example adds merits to ND for the smartphone > gateway function, or the opposite? ND just finds the link local addresses. Figuring out which way to go with packets is another story. You need a routing protocol if there is a loss of connectivity more than one hop away. At that point the addresses are still valid, but the path to the default route has changed. There is no fast withdraw in ARP proxy, DHCP proxy, ND proxy. In a routing protocol, the flooding of bad news is fast. Plus arbitrary topologies can be supported. And as Jim pointed out, we need to be careful about the scalability of flooding for WiFi networks that may be come dense. > regards, > > Victor K Regards, Curtis From russw@riw.us Wed Oct 12 22:12:41 2011 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 1DF4D21F86FF for ; Wed, 12 Oct 2011 22:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pdJwDVliaRS for ; Wed, 12 Oct 2011 22:12:40 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0F86521F86A4 for ; Wed, 12 Oct 2011 22:12:40 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:54734 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RDxni-0006t6-7V for homenet@ietf.org; Wed, 12 Oct 2011 08:20:46 -0400 Message-ID: <4E95860B.5020901@riw.us> Date: Wed, 12 Oct 2011 08:20:27 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110102118.p9ALIJl9055617@gateway.ipv6.occnc.com> <4E93C075.30400@piuha.net> <4E95096E.5020907@herberg.name> In-Reply-To: <4E95096E.5020907@herberg.name> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 05:12:41 -0000 > I agree. Since we need to configure unique prefixes to each router in > the home anyway, it should not be any problem to do the same for a > router ID (or even just use an address from the configured prefix as > router ID, which should then be unique). A while ago, there were some > plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop > network for configuring prefixes in the network. As in a home network, I > assume there is always at least one border router with the global > prefix, specifying something like that seems to be reasonable for me (in > a MANET, that can be more difficult, because there is not necessarily > such a central entity as the border router). I think there will be, by default, multiple "border routers." In my house I currently have 6 devices that provide internet connectivity, and I assume that number is going nowhere but up. Each of these devices could, in theory, be a "border router," in some way. What saves the day is that I don't allow 4 of them to "talk" on the internal network, and the other two are carefully segregated. But there's no reason for any of this --there's no reason I shouldn't be able to use all of them, especially as some of them might be able to reach outside networks in addition to the Internet at large that others might not be able to. :-) Russ From pthubert@cisco.com Wed Oct 12 22:33:11 2011 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 AB4C421F8AFE for ; Wed, 12 Oct 2011 22:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9LZoN3VONfg for ; Wed, 12 Oct 2011 22:33:11 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B570721F8AFB for ; Wed, 12 Oct 2011 22:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1942; q=dns/txt; s=iport; t=1318483990; x=1319693590; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=q3GZTeNIDnONBEUdj583hfRB/duflBg4vhloLuoaU/U=; b=bp2hAbbDYxBK4tyyqKp0z7OMv4Bwhema07fZAg6sIov6B3mX7OiqF1ER 5LpzPzgyaEYvkk4JPPtJesh7/5SmJwPt3RQrmJbXtZIGgBT22457zmZ4I AUjuiNr0SedvGQW6lucF4q7fDlDE5I7QRGW38Xb1+KO27CfoL+NeS6M4C c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAMN3lk6Q/khM/2dsb2JhbABDphSCMIEFgVMBAQEBAwEBAQ8BHQo0FwQCAQgOAwQBAQsGFwEGARsFBh8JCAEBBAESCBEJh2SZYQGQbY0/hndhBIY/kmeEe2KGSA X-IronPort-AV: E=Sophos;i="4.69,338,1315180800"; d="scan'208";a="912796" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 13 Oct 2011 05:33:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9D5X9oQ013370; Thu, 13 Oct 2011 05:33:09 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 07:33:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2011 07:33:08 +0200 Message-ID: In-Reply-To: <19820.1318466496@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] Does ND Proxy useful for homenet? Thread-Index: AcyJQMOiNal1dLmCS6OrlCHDDD2/IgAKMJtg References: <19820.1318466496@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , X-OriginalArrivalTime: 13 Oct 2011 05:33:09.0522 (UTC) FILETIME=[979E7F20:01CC8969] Subject: Re: [homenet] Does ND Proxy useful for 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: Thu, 13 Oct 2011 05:33:11 -0000 +1 -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Michael Richardson Sent: jeudi 13 octobre 2011 02:42 To: homenet@ietf.org Subject: Re: [homenet] Does ND Proxy useful for homenet? >>>>> "Victor" =3D=3D Victor Kuarsingh = writes: Victor> These devices (in such operating modes) are however not Victor> likely to participate in a home network (as the gateway Victor> device or a router) and it's very unlikely to be the head of Victor> home network. I STRONGLY DISAGREE. Not only will smartphones be pressed into use whenever the primary ISP is down (I've done this three times in 18 months since I got a smartphone), but whenever there is an ad-hoc gathering of people who need network, they will insist that their smartphones be smart.=20 I expect my smartphone to provide network to my Personal Area Network (whether via Bluetooth PAN or Zigbee), and I further expect that PAN to have an alternate exit via my HAN. I want to further point out that 3GPP and the mobile operators are no longer in control of what phones do. They are network devices. The only thing they can control is the protocol on the wire, and if they piss of the consumer, the consumer will simply tunnel. It's good that 3G will have PD in the future. I know that new versions of SIXXS AICCU now include it. --=20 ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.=20 _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From jeff.tantsura@ericsson.com Wed Oct 12 22:52:39 2011 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 7CC1D21F8AF4 for ; Wed, 12 Oct 2011 22:52:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB-hfxQNZXz9 for ; Wed, 12 Oct 2011 22:52:39 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id DC2F421F8AF8 for ; Wed, 12 Oct 2011 22:52:38 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p9D5qTos009452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Oct 2011 00:52:29 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 13 Oct 2011 01:52:28 -0400 From: Jeff Tantsura To: "curtis@occnc.com" Date: Thu, 13 Oct 2011 01:52:26 -0400 Thread-Topic: [homenet] Thoughts about routing - trends Thread-Index: AcyJT9QIaTpP7KmZTLKjgPoNR0Q/MAAHBVcg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF618178E8D2D@EUSAACMS0701.eamcs.ericsson.se> References: Your message of "Wed, 12 Oct 2011 07:51:31 EDT." <4E957F43.1060207@riw.us> <201110130228.p9D2SY8E085862@gateway.ipv6.occnc.com> In-Reply-To: <201110130228.p9D2SY8E085862@gateway.ipv6.occnc.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" Subject: Re: [homenet] Thoughts about routing - trends 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, 13 Oct 2011 05:52:39 -0000 Curtis, At about same time you were moving/re-wiring your new house, I've started t= o use Ethernet over power and have been using it since then :) Regards, Jeff =20 -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Curtis Villamizar Sent: Wednesday, October 12, 2011 19:29 To: Russ White Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing - trends In message <4E957F43.1060207@riw.us> Russ White writes: =20 > =20 > >> You are absolutely right that pulling cable is hard and expensive. > > Pulling cable is indeed hard and expensive. In my experience, it is > > the right thing for some applications, such as TV and my home > > office. Personally, I have both wired and wireless throughout the > > house; my personal rule is that I use the shared wireless network > > for activities that move around, to provide convenience at the > > expense of consistency and bandwidth, and wired for things that > > stand still, to provide stable bandwidth at the price of a one-time > > wiring effort. > =20 > I do the same --I pull cable for televisions, and even for locations > where a desktop or laptop is going to be sitting on a regular > basis. So I think we should expect wired and wireless as the norm, > rather than expecting wireless all the time. > =20 > While I wouldn't want to rule OLSRv2 completely out, I think it should > compete head to head with an extended OSPF and an extended IS-IS, or > even other efforts afoot. I'd rather see requirements first, and a > good solid evaluation of what's available against those requirements, > rather than choosing technologies out of the gate. > =20 > :-) > =20 > Russ Russ, At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted pair. [Well someone pulled it, but not me.] Anyone remember vampire taps in 10base2? What a reliability headache! I pulled 10base5 coax at home before I pulled twisted pair and before trying the early DEC Wavlan stuff that preceeded WiFi (again, at home). Too bad I moved and had to pull wire again (but I like the result). Back on topic: I do think we should consider OSPF (not so keen on ISIS, but OK) and should not rule out OLSRv2 or other LLN related work and MANET work (though I'm far from an expert on LLN or MANET). We will have to extend OSPF to make zero config possible. The extensions should be completely backwards compatible if at all possible. Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Thu Oct 13 01:40:34 2011 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 C93A321F8B57 for ; Thu, 13 Oct 2011 01:40:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql4Qq4Roxt0H for ; Thu, 13 Oct 2011 01:40:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7721F8B4E for ; Thu, 13 Oct 2011 01:40:33 -0700 (PDT) Received: by wwf22 with SMTP id 22so921778wwf.13 for ; Thu, 13 Oct 2011 01:40:33 -0700 (PDT) Received: by 10.227.39.160 with SMTP id g32mr92104wbe.17.1318495232986; Thu, 13 Oct 2011 01:40:32 -0700 (PDT) Received: from [192.168.0.108] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id es10sm4681290wbb.4.2011.10.13.01.40.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Oct 2011 01:40:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10-880981662 From: Mark Townsley In-Reply-To: <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> Date: Thu, 13 Oct 2011 03:23:17 -0400 Message-Id: <2AA0F4AE-CADE-4DD3-9701-FC067171262C@townsley.net> References: <201110122052.p9CKqNkl033845@gateway.ipv6.occnc.com> <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet strawman slides 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, 13 Oct 2011 08:40:34 -0000 --Apple-Mail-10-880981662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 12, 2011, at 6:23 PM, james woodyatt wrote: > On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote: >>=20 >> A router should not start handing out PD or even IPv4 NAT space until = it gets and address from elsewhere. Every IPv4 home router I have ever seen hands out RFC 1918 space = regardless of whether an ISP connection is active. This is needed, if = nothing else, to manage the router with the classic IPv4 literal in a = web browser (yes, this could be done with link-local, but that's not = something you can hard-code in documentation or a sticker on the side of = the box).=20 >=20 > Some routers need to do this, i.e. home routers where service = providers charge prohibitive rates for always-on Internet dial-tone and = expect subscribers to connect on demand and disconnect after an = appropriate idle time. >=20 > For IPv4 today, these routers typically use PPPoE on the WAN and they = often handle this by assigning RFC 1918 address to the LAN hosts and = using DNS queries to signal PPPoE to establish the WAN link. >=20 > For IPv6, I'm not sure what they should do, but I have some ideas. = Basically, the router should advertise as a default router with a single = ULA prefix and a DNS server at the router's ULA interface address with = RFC 6106 and optionally RFC 3736. When the DNS query signals PPPoE to = establish the WAN link, the DHCPv6 client will ask for a IA_PD and = update the prefix advertised on the LAN accordingly. "Update" or just advertise the new global prefix alongside the ULA? - Mark >=20 > I'm not sure this model can be made to work with IPv6, but I wouldn't = put it past the telcos to try. >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-10-880981662 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 12, 2011, at = 1:52 PM, Curtis Villamizar wrote:

A router = should not start handing out PD or even IPv4 NAT space until it = gets and address from = elsewhere.

Every IPv4 home router I have ever seen hands out RFC 1918 space = regardless of whether an ISP connection is active. This is needed, if = nothing else, to manage the router with the classic IPv4 literal in a = web browser (yes, this could be done with link-local, but that's not = something you can hard-code in documentation or a sticker on the side of = the box). 


Some = routers need to do this, i.e. home routers where service providers = charge prohibitive rates for always-on Internet dial-tone and expect = subscribers to connect on demand and disconnect after an appropriate = idle time.

For IPv4 today, these routers = typically use PPPoE on the WAN and they often handle this by assigning = RFC 1918 address to the LAN hosts and using DNS queries to signal PPPoE = to establish the WAN link.

For IPv6, I'm not = sure what they should do, but I have some ideas.  Basically, the = router should advertise as a default router with a single ULA prefix and = a DNS server at the router's ULA interface address with RFC 6106 and = optionally RFC 3736.  When the DNS query signals PPPoE to establish = the WAN link, the DHCPv6 client will ask for a IA_PD and update the = prefix advertised on the LAN = accordingly.

"Update" or = just advertise the new global prefix alongside the = ULA?

- Mark


I'm = not sure this model can be made to work with IPv6, but I wouldn't put it = past the telcos to try.


--
james woodyatt <jhw@apple.com>
member of technical staff, core os = networking
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail-10-880981662-- From sander@steffann.nl Thu Oct 13 01:54:50 2011 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 A8D9D21F8B43 for ; Thu, 13 Oct 2011 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbH3QBt97c8g for ; Thu, 13 Oct 2011 01:54:50 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7621F8AFD for ; Thu, 13 Oct 2011 01:54:49 -0700 (PDT) Received: from [192.168.1.34] (unknown [193.176.191.19]) by mail.sintact.nl (Postfix) with ESMTP id C0A042005; Thu, 13 Oct 2011 10:54:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_051D3BE3-BB29-4C19-9920-6040E9DB3BED"; protocol="application/pkcs7-signature"; micalg=sha1 From: Sander Steffann In-Reply-To: <2AA0F4AE-CADE-4DD3-9701-FC067171262C@townsley.net> Date: Thu, 13 Oct 2011 10:54:48 +0200 Message-Id: <78E6CFA3-8E45-4DE9-B5DB-E10DA03A325E@steffann.nl> References: <201110122052.p9CKqNkl033845@gateway.ipv6.occnc.com> <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> <2AA0F4AE-CADE-4DD3-9701-FC067171262C@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1244.3) Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Homenet strawman slides 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, 13 Oct 2011 08:54:50 -0000 --Apple-Mail=_051D3BE3-BB29-4C19-9920-6040E9DB3BED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >> For IPv6, I'm not sure what they should do, but I have some ideas. = Basically, the router should advertise as a default router with a single = ULA prefix and a DNS server at the router's ULA interface address with = RFC 6106 and optionally RFC 3736. When the DNS query signals PPPoE to = establish the WAN link, the DHCPv6 client will ask for a IA_PD and = update the prefix advertised on the LAN accordingly. >=20 > "Update" or just advertise the new global prefix alongside the ULA? Alongside. The ULA addresses should be stable so that they can always be = used internally, independent on the link to the ISP. - Sander --Apple-Mail=_051D3BE3-BB29-4C19-9920-6040E9DB3BED Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4 MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1 /SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE 74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMTEwMTMwODU0NDhaMCMGCSqGSIb3DQEJBDEWBBTGUTVCAqtDDzu1ljhkXMP0ahXDlzCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG SIb3DQEBAQUABIGABW+5mRWBN0u6xmBNz0zPDfM3lfqxlr/QWJptZfKCCW7P1C7yhB04hf/rcuj1 b5tNy/A/+Nrr5Goq1hcgR/IYP/CabGISbGhZ9h+HPwiudhllBzi7CJy/dVabQ5JP5XNhHNgJuLn2 q5/m0Up3AcXKSeHJCtLB4ikuoSsAvXE3wekAAAAAAAA= --Apple-Mail=_051D3BE3-BB29-4C19-9920-6040E9DB3BED-- From acee.lindem@ericsson.com Thu Oct 13 02:55:20 2011 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 0847721F8BA9 for ; Thu, 13 Oct 2011 02:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diaLKMLNfHvP for ; Thu, 13 Oct 2011 02:55:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1DA21F8BAA for ; Thu, 13 Oct 2011 02:55:19 -0700 (PDT) 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 p9D9tEMe032461; Thu, 13 Oct 2011 04:55:16 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 13 Oct 2011 05:55:09 -0400 From: Acee Lindem To: "curtis@occnc.com" Date: Thu, 13 Oct 2011 05:55:07 -0400 Thread-Topic: [homenet] Thoughts about routing Thread-Index: AcyJjjEgolENUaoBRCWVEncJQZVkQQ== Message-ID: <1E8BBE2E-357A-4681-BB84-4E694AFD9B1C@ericsson.com> References: <201110130246.p9D2kwmM086317@gateway.ipv6.occnc.com> In-Reply-To: <201110130246.p9D2kwmM086317@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-49-890091399"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Russ White , "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 09:55:20 -0000 --Apple-Mail-49-890091399 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One assumption could be that a legacy router would not support = auto-config and, if deployed, would have to be configured with a unique = Router ID (as they are today). =20 Thanks, Acee On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote: >=20 > In message <4E95836D.4020307@riw.us> > Russ White writes: >=20 >>=20 >>> Russ> You need a unique identifier at the equipment level for >>> Russ> anything you intend to auto-configure --autoconfiguring >>> Russ> uniqueness is a very hard, probably impossible, problem on = a >>> Russ> global scale. So we need to count on this one thing, no = matter >>> Russ> what else we might need to back in to. >>>=20 >>> Russ> Now, it might be possible to some hash over a GPS location = for >>> Russ> a "base," and then add on MAC addresses, or some such, but >>>=20 >>> We've assumed a unique MAC, which is 48 bits long.=20 >>> But OSPF router-id is 32 bits. What is the likelyhood of a = collision=20 >>> in the bottom 32-bits of the MAC?=20 >>=20 >> Ah, I see the problem... There is a pretty high likelihood of a >> collision, actually, at least as long as you use multiple vendors in >> your home network. It's bound to happen to someone, someplace. >>=20 >> So, a suggestion to resolve this: >>=20 >> 1. Use the lower 32 bits of one of the mac addresses on the box as = the >> initial id. >>=20 >> 2. Add a new field to the router capabilities that carries the full = 48 >> bit mac address, or even some munged together "longer id," based on >> multiple mac addresses on the device, or some such. >=20 > Not backwards compatible. The older OSPF routers will see only the > non-unique 32 bits and the network won't work. >=20 >> 3. During initial setup, if you receive a capability that appears to = be >> from yourself, you open this secondary id section to find out if it's >> really you, or someone else who happens to have the same 32 bit id. >>=20 >> 4. If it's really you, discard the packet. >>=20 >> 5. If it's not really you, and if the other router's "large id" is = lower >> than yours, choose another mac address from which to take your local = id, >> and restart your ospf process. >>=20 >> 6. If it's not really you, and the other router's "large id" is = higher >> than yours, then send a router capabilities LSA unicast to this = "other >> router," so the "other router" knows to change its id. >>=20 >> I don't think IS-IS would have this problem. >>=20 >> :-) >>=20 >> Russ >=20 > If the other router doesn't implement the extension you've described, > the network is hosed forever. >=20 > If you have more than one link you should receive the LSA (or LSPDU) > that you advertised. If you have one link, you won't. >=20 > If you receive a LSA (or LSPDU) that clearly you didn't advertise, > then you have a collision. *Both* routers should pick a new router-id > if this condition is detected and they implement this extension. >=20 > Don't even bother using a MAC address for the router-id. Use a random > number. If a collision occurs, use a different random number. This > should also work for interfaces without a MAC (not that many homes run > POS today, but maybe some layer-2 in the future). >=20 > Here is where it if fuzzy if one router is a legacy router. It may > not look at LSA (or LSPDU) apparently from itself or may just log a > problem and continue. When backing off, the bogus advertisements need > to be withdrawn. A possible backward compatibility wrinkle exists if > the legacy router does not readvertise (being legacy it will not pick > a new router-id). The problem could persist for maxage. Better than > forever but still not good. >=20 > Don't use a non-configured router-id if you don't support this ability > to back off. (Routers today don't pick a random router-id and they > shouldn't unless they can backoff). >=20 > Curtis > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-49-890091399 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAxMzA5NTUwOFowIwYJKoZI hvcNAQkEMRYEFKXiVW7TdtC/XpxP0IXzerjlRPzwMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgEYOrFvyzSBG7f+/xUwhtTvH3pLR5e1bEs6IfHrIvzzO+rT47I2L31P9SdhlT8BN +WJyX5clLx1Nj83WR7O3GUxcg7TC4A0bkKwAM7NicATZqopS28Vgfs+Q/JRBwaJ0R8bU1tLRqovI 4UkvyNnrdNanktVJp8EP4rzkWnDYklEnAAAAAAAA --Apple-Mail-49-890091399-- From russw@riw.us Thu Oct 13 04:41:30 2011 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 5C54021F8B71 for ; Thu, 13 Oct 2011 04:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoafDZVw8utH for ; Thu, 13 Oct 2011 04:41:29 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id BAB2621F8B4C for ; Thu, 13 Oct 2011 04:41:29 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:57872 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1REJfE-0005Iv-LC for homenet@ietf.org; Thu, 13 Oct 2011 07:41:28 -0400 Message-ID: <4E96CE51.7020600@riw.us> Date: Thu, 13 Oct 2011 07:41:05 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110130136.p9D1apKR032133@gateway.ipv6.occnc.com> In-Reply-To: <201110130136.p9D1apKR032133@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 11:41:30 -0000 > Should the applications be insecure and rely on a firewall? > (Microsoft advocated this in the 1990s and it has stuck to a large > extent). Or should the network be open and the applications secure? > > I'm strongly with you on this. The applications should take care of > any security that is necessary *for that application*. In other words, we should abandon door locks and make certain that anything you don't want stolen is individually secured --because only the device manufacturer could ever know how valuable it is, and how best to prevent it being stolen? In your own words: > No. No. No. Security is layered in the physical world, and it should be layered in the network, as well. That I argue for a default "domain based" posture, where all machines within a given "domain" are all fully reachable, but those outside the "domain" are not reachable unless specific actions are taken to make them reachable, doesn't mean I don't think individual computers need security at all, or that all security should rely on the firewall. "All security must be on the firewall or in the applications" is a false dichotomy. > Security is not a layer-2 function. Security is an application > function. You had it right the first time. Key exchanges and > certificates are not layer-2 functions. Security is an application function, yes. Security is also a network function, and security is a machine level function. All of these have a role to play in security. :-) Russ > > It is entirely possible that the same computer has pictures of Grandma > that I'm OK with you seeing and has a printer hanging off it that I > don't want anyone in the world to be able to print on. Same MAC > address. So that can't be a layer-2 function. > > And port filtering at a firewall is a lame excuse for security. The > bug in relying on a firewall in an enterprise (a little less so for a > home) is that once any one user downloads malware, that malware has > access to everthing behind the firewall largely because of the > assumption that security is not needed because there is a firewall. > > Lets not enshine the dumbest practices of the IT world. > >> I think homenet should focus on L3. (and be clear on what it expects >> from the other layers with regards to security). >> >> cheers, >> Ole > > Curtis > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From russw@riw.us Thu Oct 13 04:44:32 2011 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 CF38421F8BF3 for ; Thu, 13 Oct 2011 04:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp1J13tODwSl for ; Thu, 13 Oct 2011 04:44:32 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 682DB21F8BEF for ; Thu, 13 Oct 2011 04:44:32 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:57947 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1REJiB-0002p5-GC for homenet@ietf.org; Thu, 13 Oct 2011 07:44:31 -0400 Message-ID: <4E96CF0B.8060909@riw.us> Date: Thu, 13 Oct 2011 07:44:11 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110130257.p9D2vJO5086601@gateway.ipv6.occnc.com> In-Reply-To: <201110130257.p9D2vJO5086601@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 11:44:32 -0000 > Is it better to leave the possibility of theft of service or is it > better to have the device unusable by default (until configured)? This is a false dichotomy, as well... It is best to find some reasonable ground where 90% of the people in the world will find the security acceptable, and then let the 10% who care configure the rest. But I would also point out that the argument you're making can be applied to applications as well as network gear. :-) Russ From russw@riw.us Thu Oct 13 04:47:16 2011 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 05BAA21F8B53 for ; Thu, 13 Oct 2011 04:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDP9q7SO2cs9 for ; Thu, 13 Oct 2011 04:47:15 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9DA21F8B8C for ; Thu, 13 Oct 2011 04:47:15 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:58024 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1REJko-0000Wx-03 for homenet@ietf.org; Thu, 13 Oct 2011 07:47:14 -0400 Message-ID: <4E96CFAD.6090901@riw.us> Date: Thu, 13 Oct 2011 07:46:53 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110122052.p9CKqNkl033845@gateway.ipv6.occnc.com> <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> In-Reply-To: <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Homenet strawman slides 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, 13 Oct 2011 11:47:16 -0000 >> A router should not start handing out PD or even IPv4 NAT space until >> it gets and address from elsewhere. In other words, your home network should be unusable unless at least one edge device is connected to the "real world." I can just imagine the support calls the local provider will get when they have a local outage. "I'm sorry, sir, but that's the way it works --you can't print or stream movies from your console unless your internet connection is up." Yeah, that's going to fly. :-) Russ From russw@riw.us Thu Oct 13 04:50:06 2011 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 780B121F8BFB for ; Thu, 13 Oct 2011 04:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iavmQfMpCCAO for ; Thu, 13 Oct 2011 04:50:06 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id E262621F8BF8 for ; Thu, 13 Oct 2011 04:50:05 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:58083 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1REJnY-0006A9-U9 for homenet@ietf.org; Thu, 13 Oct 2011 07:50:05 -0400 Message-ID: <4E96D052.3050108@riw.us> Date: Thu, 13 Oct 2011 07:49:38 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <19820.1318466496@marajade.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] Does ND Proxy useful for 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: Thu, 13 Oct 2011 11:50:06 -0000 > >>>>> "Victor" == Victor Kuarsingh > writes: > Victor> These devices (in such operating modes) are however not > Victor> likely to participate in a home network (as the gateway > Victor> device or a router) and it's very unlikely to be the head of > Victor> home network. > > I STRONGLY DISAGREE. > > That's fine. My statement was based on an aggregate set of behaviors > over millions of endpoints. Corner cases always exist (and perhaps not > so corner in the future). This won't be the "corner case," it will be the "common case," in most all homes. The electricity providers are seeing to that right now, as well as the cell phone providers. In a few years, someone is going to say, "you only have one internet connection? You poor soul, we need to find some government program to help you." :-) Russ From russw@riw.us Thu Oct 13 04:54:03 2011 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 7DEEB21F8B2B for ; Thu, 13 Oct 2011 04:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqbspZXcM5lS for ; Thu, 13 Oct 2011 04:54:03 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 14C7221F87C9 for ; Thu, 13 Oct 2011 04:54:03 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:58182 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1REJrN-0006Ns-WE; Thu, 13 Oct 2011 07:54:02 -0400 Message-ID: <4E96D145.5090609@riw.us> Date: Thu, 13 Oct 2011 07:53:41 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110130228.p9D2SY8E085862@gateway.ipv6.occnc.com> In-Reply-To: <201110130228.p9D2SY8E085862@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing - trends 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, 13 Oct 2011 11:54:03 -0000 > At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted > pair. [Well someone pulled it, but not me.] Anyone remember vampire > taps in 10base2? What a reliability headache! Pulled from cable hanging in a "plenum" in a secure building... Because there was no way to get cable floor to floor other than through that single shaft. For a Xerox Star system. Then there was the token bus for the little Novell network over in legal --another disaster. > Back on topic: I do think we should consider OSPF (not so keen on > ISIS, but OK) and should not rule out OLSRv2 or other LLN related work > and MANET work (though I'm far from an expert on LLN or MANET). IS-IS is easier to get to "zero config," and it's actually simpler in operation... Which is why I brought it up. :-) > We will have to extend OSPF to make zero config possible. The > extensions should be completely backwards compatible if at all > possible. Yes, I agree... Or we need w new wired/wireless protocol that jumps both worlds, and would actually be acceptable and implemented by a large number of vendors. But that's another entire problem space... :-) Russ From mellon@fugue.com Thu Oct 13 06:37:41 2011 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 8701521F8B4B for ; Thu, 13 Oct 2011 06:37:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm8tUJe4odAu for ; Thu, 13 Oct 2011 06:37:35 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CE34021F8B46 for ; Thu, 13 Oct 2011 06:37:35 -0700 (PDT) Received: from [10.1.10.11] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 14D942380964; Thu, 13 Oct 2011 09:37:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <201110130207.p9D27S1O081717@gateway.ipv6.occnc.com> Date: Thu, 13 Oct 2011 09:37:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8031F94C-66BF-4748-AA97-5EFA12BB87ED@fugue.com> References: <201110130207.p9D27S1O081717@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1244.3) Cc: Ole Troan , homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 13:37:41 -0000 If you autoconfigure a routing topology, you have to make sure that you = don't accidentally autoconfigure it to include routers that weren't = intended to have been included. The concern is not for grandma running Windows 98, and the whole hard = shell/gooey center debate is completely beside the point. From mcr@sandelman.ca Thu Oct 13 06:49:23 2011 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 6ED1721F8C07 for ; Thu, 13 Oct 2011 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EumTj-4UctF3 for ; Thu, 13 Oct 2011 06:49:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 980B821F85A1 for ; Thu, 13 Oct 2011 06:49:22 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 4BF60343A1 for ; Thu, 13 Oct 2011 09:48:14 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6426098CAD; Thu, 13 Oct 2011 09:49:32 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5D5F698B2E for ; Thu, 13 Oct 2011 09:49:32 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: <20111013012731.9E687152810E@drugs.dv.isc.org> References: <201110130101.p9D119Vc094661@gateway.ipv6.occnc.com> <20111013011929.1F7051527D8B@drugs.dv.isc.org> <669F4202-6FD4-4F13-AE7B-E725D53AD874@gmail.com> <20111013012731.9E687152810E@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 13 Oct 2011 09:49:32 -0400 Message-ID: <14861.1318513772@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 13:49:23 -0000 >>>>> "Mark" == Mark Andrews writes: >> Or you solve the time problem some other way... >> >> Batteries die too... Jim Mark> Indeed. It should be a user servicable part. Mark> As to solving it other way, "leap of faith" springs to mind. DHCP has an NTP server option. Does IP6CP? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Thu Oct 13 06:54:52 2011 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 1C4F721F8B77 for ; Thu, 13 Oct 2011 06:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aYn0TL5WDGa for ; Thu, 13 Oct 2011 06:54:51 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85621F8B53 for ; Thu, 13 Oct 2011 06:54:51 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 322FE34385; Thu, 13 Oct 2011 09:53:46 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 46BD198CAD; Thu, 13 Oct 2011 09:55:04 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 41A6F98B2E; Thu, 13 Oct 2011 09:55:04 -0400 (EDT) From: Michael Richardson To: curtis@occnc.com In-Reply-To: <201110130246.p9D2kwmM086317@gateway.ipv6.occnc.com> References: <201110130246.p9D2kwmM086317@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 13 Oct 2011 09:55:04 -0400 Message-ID: <15691.1318514104@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Russ White , homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 13:54:52 -0000 >>>>> "Curtis" == Curtis Villamizar writes: >> 2. Add a new field to the router capabilities that carries the >> full 48 bit mac address, or even some munged together "longer >> id," based on multiple mac addresses on the device, or some such. Curtis> Not backwards compatible. The older OSPF routers will see Curtis> only the non-unique 32 bits and the network won't work. There are no zOSPF routers today. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Thu Oct 13 07:05:30 2011 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 2418421F8AB8 for ; Thu, 13 Oct 2011 07:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFIURT-tdER6 for ; Thu, 13 Oct 2011 07:05:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9278C21F8A96 for ; Thu, 13 Oct 2011 07:05:29 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 70DDC343B2 for ; Thu, 13 Oct 2011 10:04:24 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6A64198CAD; Thu, 13 Oct 2011 10:05:42 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6460D98B2E for ; Thu, 13 Oct 2011 10:05:42 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <201110130408.p9D48MRN089221@gateway.ipv6.occnc.com> References: <201110130408.p9D48MRN089221@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 13 Oct 2011 10:05:42 -0400 Message-ID: <17165.1318514742@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] time service and DNSSEC 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, 13 Oct 2011 14:05:30 -0000 >>>>> "Curtis" == Curtis Villamizar writes: >> While talking about hardware. These these devices all need a >> battery backed clock or all the crypto will be broken. Curtis> Having a clock is not hard but I don't think your statement Curtis> is true. Curtis> Some crypto does not require time, but rather just entropy Curtis> (a nonce or challenge). For crypto that does require time Curtis> the former can be a bootstrap of sorts, possibly to get ntp Curtis> going if very accurate time is needed (for some reason). Curtis, Mark, as a DNSSEC implementer knows of what he speaks. DNSSEC requires time. Not to the second or even minute, but at least hour. DNSSEC is a core protocol at this point, and we need to be aware of it. It doesn't matter today, because we have a broken home DNS system, but that's within homenet to fix. Bootstraping time enough to get DNSSEC to work is important. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From gettysjim@gmail.com Thu Oct 13 07:40:23 2011 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 4AC5221F8B76 for ; Thu, 13 Oct 2011 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kanuEq5nhgoQ for ; Thu, 13 Oct 2011 07:40:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C176A21F8B65 for ; Thu, 13 Oct 2011 07:40:22 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so91935vcb.31 for ; Thu, 13 Oct 2011 07:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qB4+rDSWmVwqOBakfMaKi3g/0hRrOII20UWSmbCKWOI=; b=spCnzq85nKsACYpSwChXwvmpFs4voBo2QGEzoxo+IHRPG8UIlj91sk50vxKSAJCNeB 1xTL/cFVyZFthBUeHdA2MI9DoxwdTvPr+6fSzoSLscjN57ZrpCJcf8suyBj9v+PBiui/ Zju/DPhVVmMxTO864BJJC3UAbkgIZMztUzmPg= Received: by 10.52.30.79 with SMTP id q15mr3948621vdh.111.1318516822045; Thu, 13 Oct 2011 07:40:22 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id v8sm4130546vdg.22.2011.10.13.07.40.20 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 07:40:21 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E96F853.8050309@freedesktop.org> Date: Thu, 13 Oct 2011 10:40:19 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Michael Richardson References: <201110130408.p9D48MRN089221@gateway.ipv6.occnc.com> <17165.1318514742@marajade.sandelman.ca> In-Reply-To: <17165.1318514742@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] time service and DNSSEC 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, 13 Oct 2011 14:40:23 -0000 On 10/13/2011 10:05 AM, Michael Richardson wrote: >>>>>> "Curtis" == Curtis Villamizar writes: > >> While talking about hardware. These these devices all need a > >> battery backed clock or all the crypto will be broken. > > > Curtis> Having a clock is not hard but I don't think your statement > Curtis> is true. > > Curtis> Some crypto does not require time, but rather just entropy > Curtis> (a nonce or challenge). For crypto that does require time > Curtis> the former can be a bootstrap of sorts, possibly to get ntp > Curtis> going if very accurate time is needed (for some reason). > > Curtis, Mark, as a DNSSEC implementer knows of what he speaks. > DNSSEC requires time. Not to the second or even minute, but at least > hour. > > DNSSEC is a core protocol at this point, and we need to be aware of it. > It doesn't matter today, because we have a broken home DNS system, but > that's within homenet to fix. > > Bootstraping time enough to get DNSSEC to work is important. > Yup. And DNSSEC does not require precise time as you note. In the short term, in CeroWrt, which has running DNSSEC, Dave plans to do insecure lookups initially to resolve NTP server addresses to get the time, and then switch over to secure once time has been established. There may be other options possible. Ideally, something like a well known anycast address we can get approximate time on would suffice, for some high velocity hand waving. - Jim From mcr@sandelman.ca Thu Oct 13 08:01:02 2011 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 861F021F85AA for ; Thu, 13 Oct 2011 08:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo-7Jcj3pXEr for ; Thu, 13 Oct 2011 08:01:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 232F221F84FA for ; Thu, 13 Oct 2011 08:01:02 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id D51F4343A2; Thu, 13 Oct 2011 10:59:52 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 0314698CAD; Thu, 13 Oct 2011 11:01:11 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0176D98B2E; Thu, 13 Oct 2011 11:01:10 -0400 (EDT) From: Michael Richardson To: Russ White In-Reply-To: <4E96CFAD.6090901@riw.us> References: <201110122052.p9CKqNkl033845@gateway.ipv6.occnc.com> <4C6C6FC3-D1A9-4663-A1E1-802D1A6D0216@apple.com> <4E96CFAD.6090901@riw.us> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 13 Oct 2011 11:01:10 -0400 Message-ID: <25181.1318518070@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides 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, 13 Oct 2011 15:01:02 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Russ" =3D=3D Russ White writes: >>> A router should not start handing out PD or even IPv4 NAT space unt= il >>> it gets and address from elsewhere. Russ> In other words, your home network should be unusable unless at Russ> least one=20 Russ> edge device is connected to the "real world." I can just imagine = the Russ> support calls the local provider will get when they have a Russ> local outage.=20 Russ> "I'm sorry, sir, but that's the way it works --you can't print Russ> or stream=20 Russ> movies from your console unless your internet connection is up." Russ> Yeah, that's going to fly. Please don't mistake idle comments about the history of some devices on the mailing list for requirements! I think that we are pretty much in agreement that the home network has to operate independently of the ISP(s), which is one of the reasons for ULA, and RFC6204 (Basic Requirements for IPv6 Customer Edge Routers) already provides for this. At the 10,000ft level, homenet is "Advanced Requirements for ..." =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpb9NoCLcPvd0N1lAQIBMQf/cMpaOC+6ZIwYuIHyk7cMKdDXF62+v6pB nF+ekIFtFitHxyTH6cAbXArJ/rpRBdmu/pNQBDgVbVhdhUI8Cnset8jApZ3azQvq vIaPGTuoBhaLS3BgQ7wc2G8dpAOAv4HrrZM7UjZT4vD8K8JHSA4yUwXuliF5goSJ +tJtHB/P9x7yPQYF4wi8qAQQ1SNAotdwInfm7atGjrNauHSV9ymrKC5F7bKrBQc6 7xtjip/74HLKKfVpQjuEkKqRy895aZcUuFW9/kGflCnAF86Zt+vfeEEjhHRVt/81 S23+6vhuzLwxhgJZ+8UC3JvkgLoGur4vUFAriGYJ6r98ARWoFJaoIg== =y8/Z -----END PGP SIGNATURE----- --=-=-=-- From gettysjim@gmail.com Wed Oct 12 18:22:55 2011 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 2D11321F8B0D for ; Wed, 12 Oct 2011 18:22:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uVsSU7bSLNQ for ; Wed, 12 Oct 2011 18:22:54 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08F4521F8B0B for ; Wed, 12 Oct 2011 18:22:53 -0700 (PDT) Received: by vws5 with SMTP id 5so1361630vws.31 for ; Wed, 12 Oct 2011 18:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=pHk0Gsxt4XjYJUHuFe7CUyluqRoJY3THbFHj/ycJHdg=; b=xLBOtkJTaEALBABPRKOw+SeeuhvKC13WXV3uQgDSB4rwevxL3m3a5e6XiFzRuShFXf EoGnYa+GQVDZlV/UuCCN3IVMUwOTGmmQy2U+V/N5SEv6m9mrgVrYzEYbKb/BDR5JUspy xc0ePyFP/XPiL4uZkzKYqUFq5NHEiu6sORWFg= Received: by 10.52.187.199 with SMTP id fu7mr1507307vdc.109.1318468973380; Wed, 12 Oct 2011 18:22:53 -0700 (PDT) Received: from [192.168.1.5] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ie2sm2210635vdb.1.2011.10.12.18.22.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 18:22:52 -0700 (PDT) References: <201110130101.p9D119Vc094661@gateway.ipv6.occnc.com> <20111013011929.1F7051527D8B@drugs.dv.isc.org> In-Reply-To: <20111013011929.1F7051527D8B@drugs.dv.isc.org> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <669F4202-6FD4-4F13-AE7B-E725D53AD874@gmail.com> X-Mailer: iPad Mail (8L1) From: Jim Gettys Date: Wed, 12 Oct 2011 21:22:51 -0400 To: Mark Andrews X-Mailman-Approved-At: Thu, 13 Oct 2011 08:15:27 -0700 Cc: "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 01:22:55 -0000 Or you solve the time problem some other way... Batteries die too... Jim On Oct 12, 2011, at 9:19 PM, Mark Andrews wrote: > > While talking about hardware. These these devices all need a battery > backed clock or all the crypto will be broken. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Thu Oct 13 11:11:30 2011 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 D20F921F8A70 for ; Thu, 13 Oct 2011 11:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwo+vpprsA1x for ; Thu, 13 Oct 2011 11:11:29 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id AC4BC21F8A62 for ; Thu, 13 Oct 2011 11:11:28 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DIBE9i021327; Thu, 13 Oct 2011 11:11:14 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DIBE9i021327 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318529475; bh=teMnbdNIw6JVMfR0qunUiPL0g4DM+M9rq3V0bopbYnA=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=M9i4ODEjqrVmZof9NyOWYyTZZQWTd8EaoH+lAf1ehcs5U/6zIxMC5P+8cFY/FXY+C xHP5p6l/ATK2wnOBpJxaNDT1gm0c13gvVzNzctzagweflCIgjThPXkcxTGMJKHLQpL fesP/PqXanzcr7B4v9/2IR+ozloAJQm2XtNO0AMo= Message-Id: <201110131811.p9DIBE9i021327@gateway.ipv6.occnc.com> To: Acee Lindem From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 05:55:07 EDT." <1E8BBE2E-357A-4681-BB84-4E694AFD9B1C@ericsson.com> Date: Thu, 13 Oct 2011 11:11:14 -0700 Cc: Russ White , "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:11:30 -0000 In message <1E8BBE2E-357A-4681-BB84-4E694AFD9B1C@ericsson.com> Acee Lindem writes: > One assumption could be that a legacy router would not support > auto-config and, if deployed, would have to be configured with a > unique Router ID (as they are today). Got that. Don't use a non-configured router-id if you don't support this ability to back off. (Routers today don't pick a random router-id and they shouldn't unless they can backoff). > Thanks, > Acee The key uncertainty is the effect of a collision on a legacy router. This looks like it is covered. (indentation changed) [RFC2328] 13.4. Receiving self-originated LSAs It is a common occurrence for a router to receive self- originated LSAs via the flooding procedure. A self-originated LSA is detected when either 1) the LSA's Advertising Router is equal to the router's own Router ID or 2) the LSA is a network- LSA and its Link State ID is equal to one of the router's own IP interface addresses. However, if the received self-originated LSA is newer than the last instance that the router actually originated, the router must take special action. The reception of such an LSA indicates that there are LSAs in the routing domain that were originated by the router before the last time it was restarted. In most cases, the router must then advance the LSA's LS sequence number one past the received LS sequence number, and originate a new instance of the LSA. [...] In all these cases, instead of updating the LSA, the LSA should be flushed from the routing domain by incrementing the received LSA's LS age to MaxAge and reflooding (see Section 14.1). [RFC5340] 4.5.1. Receiving Link State Update Packets [...] In IPv4, eight steps are executed for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows: [stub or nssa or reserved scope changes] It seems then that if the auto-config router picks a new router-id, the legacy router will correct any damage. Perhaps the legacy router will do this for the wrong reasons (collisions, not stale leftovers from a restart elsewhere), but it seems like it will take action to fix it. Acee - should this move to OSPF? Others - No cross posting please. Curtis > On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote: > > > > > In message <4E95836D.4020307@riw.us> > > Russ White writes: > > > >> > >>> Russ> You need a unique identifier at the equipment level for > >>> Russ> anything you intend to auto-configure --autoconfiguring > >>> Russ> uniqueness is a very hard, probably impossible, problem on a > >>> Russ> global scale. So we need to count on this one thing, no matter > >>> Russ> what else we might need to back in to. > >>> > >>> Russ> Now, it might be possible to some hash over a GPS location for > >>> Russ> a "base," and then add on MAC addresses, or some such, but > >>> > >>> We've assumed a unique MAC, which is 48 bits long. > >>> But OSPF router-id is 32 bits. What is the likelyhood of a collision > >>> in the bottom 32-bits of the MAC? > >> > >> Ah, I see the problem... There is a pretty high likelihood of a > >> collision, actually, at least as long as you use multiple vendors in > >> your home network. It's bound to happen to someone, someplace. > >> > >> So, a suggestion to resolve this: > >> > >> 1. Use the lower 32 bits of one of the mac addresses on the box as the > >> initial id. > >> > >> 2. Add a new field to the router capabilities that carries the full 48 > >> bit mac address, or even some munged together "longer id," based on > >> multiple mac addresses on the device, or some such. > > > > Not backwards compatible. The older OSPF routers will see only the > > non-unique 32 bits and the network won't work. > > > >> 3. During initial setup, if you receive a capability that appears to be > >> from yourself, you open this secondary id section to find out if it's > >> really you, or someone else who happens to have the same 32 bit id. > >> > >> 4. If it's really you, discard the packet. > >> > >> 5. If it's not really you, and if the other router's "large id" is lower > >> than yours, choose another mac address from which to take your local id, > >> and restart your ospf process. > >> > >> 6. If it's not really you, and the other router's "large id" is higher > >> than yours, then send a router capabilities LSA unicast to this "other > >> router," so the "other router" knows to change its id. > >> > >> I don't think IS-IS would have this problem. > >> > >> :-) > >> > >> Russ > > > > If the other router doesn't implement the extension you've described, > > the network is hosed forever. > > > > If you have more than one link you should receive the LSA (or LSPDU) > > that you advertised. If you have one link, you won't. > > > > If you receive a LSA (or LSPDU) that clearly you didn't advertise, > > then you have a collision. *Both* routers should pick a new router-id > > if this condition is detected and they implement this extension. > > > > Don't even bother using a MAC address for the router-id. Use a random > > number. If a collision occurs, use a different random number. This > > should also work for interfaces without a MAC (not that many homes run > > POS today, but maybe some layer-2 in the future). > > > > Here is where it if fuzzy if one router is a legacy router. It may > > not look at LSA (or LSPDU) apparently from itself or may just log a > > problem and continue. When backing off, the bogus advertisements need > > to be withdrawn. A possible backward compatibility wrinkle exists if > > the legacy router does not readvertise (being legacy it will not pick > > a new router-id). The problem could persist for maxage. Better than > > forever but still not good. > > > > Don't use a non-configured router-id if you don't support this ability > > to back off. (Routers today don't pick a random router-id and they > > shouldn't unless they can backoff). > > > > Curtis From curtis@occnc.com Thu Oct 13 11:36:45 2011 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 88AA621F8520 for ; Thu, 13 Oct 2011 11:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XytR1CC96MJZ for ; Thu, 13 Oct 2011 11:36:44 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C119621F84FD for ; Thu, 13 Oct 2011 11:36:44 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DIZ6Ob021750; Thu, 13 Oct 2011 11:35:06 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DIZ6Ob021750 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318530906; bh=+hYl4CTTg6Q4vIaAzPToZvkyI4nzOpxm0PXfEpmGVpY=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=I9rmZXqUjSDDlzLvNS6GsolnRRCIfcqvEs5bBudOVs4qNhqWG/td+/y3NY5Lsi4hx W/lQby403HSUVl9HMgghXqxJjNuq3XYQwDs8F0fJsbOVVZuidhSPekDEHUV4p31DW9 m6XX9FIFbw/irYPmmU2iPU4+qtgRBAdge4XKBlEQ= Message-Id: <201110131835.p9DIZ6Ob021750@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 09:37:33 EDT." <8031F94C-66BF-4748-AA97-5EFA12BB87ED@fugue.com> Date: Thu, 13 Oct 2011 11:35:05 -0700 Cc: Ole Troan , homenet@ietf.org, Stephen Farrell , curtis@occnc.com Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:36:45 -0000 In message <8031F94C-66BF-4748-AA97-5EFA12BB87ED@fugue.com> Ted Lemon writes: > If you autoconfigure a routing topology, you have to make sure that > you don't accidentally autoconfigure it to include routers that > weren't intended to have been included. > > The concern is not for grandma running Windows 98, and the whole hard > shell/gooey center debate is completely beside the point. You've said what the problem *isn't*, so what *is* the problem on a homenet? Surely the provider is not going to accept a unauthenticated auto-config hello request and start peering, nor will it accept a hello from a legacy router configured with router-id and a "be adjacent to anything" policy. If the electric meter wants to be a router with a slow link on the power line, then it needs to act like a provider router, but perhaps only advertising reachability to the electric utility, not the whole Internet. The more specific prefix (than default) should get the attention of the water heater if it has to try to reach the electric utility. Curtis From curtis@occnc.com Thu Oct 13 11:42:40 2011 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 E174021F85F2 for ; Thu, 13 Oct 2011 11:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIkgJvqZL2w8 for ; Thu, 13 Oct 2011 11:42:39 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8021F85B1 for ; Thu, 13 Oct 2011 11:42:39 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DIgaDg021801; Thu, 13 Oct 2011 11:42:36 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DIgaDg021801 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318531357; bh=6IWTsRePiYVsR/xO2vYXFF5ov1TIvlyAkBWxjfCkHpU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=C8DF2GAFy4c1iraIEYVZ26gN6LO/O/arXT8qbnDj5r4svPWoheFIaKj3i4i18nHmc 76B+OTkzKMvd9xCrIHpHUTYYugZRvaXqX8g3RktiSO6L6mrhzcQaOGvBYkFux0tqie 8Wg0eODuozDRdBI72pb6vXIZy76nLCmD+BjtMRic= Message-Id: <201110131842.p9DIgaDg021801@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 09:55:04 EDT." <15691.1318514104@marajade.sandelman.ca> Date: Thu, 13 Oct 2011 11:42:36 -0700 Cc: Russ White , homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:42:41 -0000 In message <15691.1318514104@marajade.sandelman.ca> Michael Richardson writes: > >>>>> "Curtis" == Curtis Villamizar writes: > >> 2. Add a new field to the router capabilities that carries the > >> full 48 bit mac address, or even some munged together "longer > >> id," based on multiple mac addresses on the device, or some such. > > Curtis> Not backwards compatible. The older OSPF routers will see > Curtis> only the non-unique 32 bits and the network won't work. > > There are no zOSPF routers today. Yes and there are/were ATM switches that implement RFC1577, LANE, MPOA, and NHRP. None of that worked very well and it all is essentially abandoned work now. Pre-existence alone is not a worth while evaluation criteria. If zOSPF works perfectly, including in the presence of legacy routers which don't look at a new 48 bit mac address router-id extension, we have no reason to continue the discussion. We just indicate "use zOSPF" and we're done. There seems to be consensus that we're not done. Curtis From mellon@fugue.com Thu Oct 13 11:42:48 2011 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 DF69B21F8A4B for ; Thu, 13 Oct 2011 11:42:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCQckrEUe9Iz for ; Thu, 13 Oct 2011 11:42:48 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7D85121F88A0 for ; Thu, 13 Oct 2011 11:42:48 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:149d:b432:5d33:83ce] (unknown [IPv6:2001:470:1f07:1486:149d:b432:5d33:83ce]) by toccata.fugue.com (Postfix) with ESMTPSA id 0A5E02381795; Thu, 13 Oct 2011 14:42:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C5DC8EF-A1EF-4E60-BC7D-B75155F983A9" From: Ted Lemon In-Reply-To: <201110131835.p9DIZ6Ob021750@gateway.ipv6.occnc.com> Date: Thu, 13 Oct 2011 14:42:45 -0400 Message-Id: <300CE19E-B3D6-4742-82ED-02F8167C9F16@fugue.com> References: <201110131835.p9DIZ6Ob021750@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1251.1) Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 18:42:49 -0000 --Apple-Mail=_6C5DC8EF-A1EF-4E60-BC7D-B75155F983A9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote: > You've said what the problem *isn't*, so what *is* the problem on a > homenet? I did say what the problem is: >> If you autoconfigure a routing topology, you have to make sure that >> you don't accidentally autoconfigure it to include routers that >> weren't intended to have been included. --Apple-Mail=_6C5DC8EF-A1EF-4E60-BC7D-B75155F983A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii You've said = what the problem *isn't*, so what *is* the problem on = a
homenet?
I did say what the = problem is:

If you autoconfigure a routing topology, you have to make = sure that
you don't = accidentally autoconfigure it to include routers = that
weren't intended to have = been included.

= --Apple-Mail=_6C5DC8EF-A1EF-4E60-BC7D-B75155F983A9-- From gettysjim@gmail.com Thu Oct 13 12:03:37 2011 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 C7DB321F8B3A for ; Thu, 13 Oct 2011 12:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY8bLd6FhzS2 for ; Thu, 13 Oct 2011 12:03:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3F3121F8B39 for ; Thu, 13 Oct 2011 12:03:36 -0700 (PDT) Received: by vws5 with SMTP id 5so429239vws.31 for ; Thu, 13 Oct 2011 12:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9z/L3wrkx/pI6vpv+PJ2nMQaHX5trRqXwlJVV1tyZcU=; b=eRUqCA1g5ZbnRzGcIDTlcLwgibVPTXmadTGIgt/CzP/mivNBK/aZbltt44p01X9bY0 dS34AFjbW1zUGuNM+fiO9tNI+SmQFWtRmqyPFTWcaYeztHQO3U21CrYtfjj/cjEt5sgi yQy28wphXRc5AArXh5eN/Eniiz9Hy+QLVz5NM= Received: by 10.52.75.73 with SMTP id a9mr5314302vdw.27.1318532616227; Thu, 13 Oct 2011 12:03:36 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id em2sm5064313vdc.2.2011.10.13.12.03.34 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 12:03:34 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E973605.50309@freedesktop.org> Date: Thu, 13 Oct 2011 15:03:33 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: curtis@occnc.com References: <201110131842.p9DIgaDg021801@gateway.ipv6.occnc.com> In-Reply-To: <201110131842.p9DIgaDg021801@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Russ White , homenet@ietf.org, Michael Richardson Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 19:03:37 -0000 On 10/13/2011 02:42 PM, Curtis Villamizar wrote: > > Yes and there are/were ATM switches that implement RFC1577, LANE, > MPOA, and NHRP. None of that worked very well and it all is > essentially abandoned work now. Pre-existence alone is not a worth > while evaluation criteria. > > If zOSPF works perfectly, including in the presence of legacy routers > which don't look at a new 48 bit mac address router-id extension, we > have no reason to continue the discussion. We just indicate "use > zOSPF" and we're done. > > There seems to be consensus that we're not done. > On my part, I'm interested in understanding the following: o scaling properties: I worry about the apartment building case, and related dense mesh case. o behaviour when routing both wired and wireless networks. o multicast behaviour and impact on wireless networks. o running code And I'll ask the same about any other routing protocol you wish to name. I'm an equal opportunity parade rainer... - Jim From curtis@occnc.com Thu Oct 13 12:32:48 2011 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 15A0821F8B17 for ; Thu, 13 Oct 2011 12:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+HomKpn-HON for ; Thu, 13 Oct 2011 12:32:47 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 15C6121F8AC3 for ; Thu, 13 Oct 2011 12:32:46 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DJWhFx022889; Thu, 13 Oct 2011 12:32:44 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DJWhFx022889 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318534364; bh=DF9phHysS6TwR6drpkVCWPKnqZUKxorjNaFBixO3BBU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=jgaWiVzjVLTynNXECcm+MtK/MxgUMbsULgRnIMmfh/xiL1ny4A7PjQdCWXKNK0M8o HKe0Q09t6UQ1PsJHEMfK/lPTfflUZ/adFBfGUDWxOjDVVmJ81RT5Ojw+kIGKUfgnLA +In15YJP19OX8rlTayCMgUkPwn5eKfh1Y8nREDxU= Message-Id: <201110131932.p9DJWhFx022889@gateway.ipv6.occnc.com> To: Mark Townsley From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 03:23:17 EDT." <2AA0F4AE-CADE-4DD3-9701-FC067171262C@townsley.net> Date: Thu, 13 Oct 2011 12:32:43 -0700 Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Homenet strawman slides X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:32:48 -0000 In message <2AA0F4AE-CADE-4DD3-9701-FC067171262C@townsley.net> Mark Townsley writes: > On Oct 12, 2011, at 6:23 PM, james woodyatt wrote: > > > On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote: > >> > >> A router should not start handing out PD or even IPv4 NAT space until > >> it gets and address from elsewhere. > > Every IPv4 home router I have ever seen hands out RFC 1918 space > regardless of whether an ISP connection is active. This is needed, if > nothing else, to manage the router with the classic IPv4 literal in a > web browser (yes, this could be done with link-local, but that's not > something you can hard-code in documentation or a sticker on the side > of the box). For IPv4, routes can be installed for non-local link-local addresses or ULA prefixes can be used if no address is available. The practice of using 192.168.1.1 should be changed. The change could be as simple as a DNS mapping of "local-router." to the link local addres. A DHCP host query would get an offer of a DNS server which would respond with a DNS entry for local-router. The dot is significant though if omitted the domain search list would be used with the last entry presumed blank. As long as there is no "local-router." TLD glogally defined this should be OK. A user with multiple routers on the subnet can just paste the link-local address in place. Maybe routers can look for others and offer a "local-router-N." for each other router detected. Then "http://"local-router." or "http://"local-router-N." can be used if the user does need to do any config. There could also be some improvement on the common practice of allowing a default password on any port except the designated uplink. In an auto-config router this would never change. Perhaps this could be enabled only 10 seconds or so after power up if the factory default password is in place, at least limiting the exposure. This could fit in the manual and maybe even on a sticker. But yes, IPv4 must hand out a PI address if it has nothing else to hand out. > > Some routers need to do this, i.e. home routers where service > > providers charge prohibitive rates for always-on Internet dial-tone > > and expect subscribers to connect on demand and disconnect after an > > appropriate idle time. > > > > For IPv4 today, these routers typically use PPPoE on the WAN and > > they often handle this by assigning RFC 1918 address to the LAN > > hosts and using DNS queries to signal PPPoE to establish the WAN > > link. > > > > For IPv6, I'm not sure what they should do, but I have some ideas. > > Basically, the router should advertise as a default router with a > > single ULA prefix and a DNS server at the router's ULA interface > > address with RFC 6106 and optionally RFC 3736. When the DNS query > > signals PPPoE to establish the WAN link, the DHCPv6 client will ask > > for a IA_PD and update the prefix advertised on the LAN > > accordingly. > > "Update" or just advertise the new global prefix alongside the ULA? > > - Mark I meant "update" in the context of refreshing the IA_PD request at the provider DHCP server that handed it out the last time the demand circuit was up. If the prefix was held while the demand circuit was unused and down, then no change is needed on the homenet side when the demand circuit comes back up. Curtis From curtis@occnc.com Thu Oct 13 12:59:28 2011 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 E7C3521F8BA0 for ; Thu, 13 Oct 2011 12:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEhHGGe6U61V for ; Thu, 13 Oct 2011 12:59:28 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id E56DD21F8B9B for ; Thu, 13 Oct 2011 12:59:27 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DJxPkW024565; Thu, 13 Oct 2011 12:59:25 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DJxPkW024565 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318535965; bh=RqaL//u9eeSVAugVC+02jpYdhIFrQ+SiJW8WByHmyrU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=cMeHsOCfpES1GJkuxfHkZME7LFYrAdsew6UZiWJgty9ZfRJS6cN9ejHhNW5hxrn2r SyHixTIhzEVXHJeeqgKS6sal0H3qS7t0NihTgPxF8G4iS9lbCgIZLzoJh5L612sJRs KM4sePesljiYmDPjtz9XI1T631odtfujwRI0xuYY= Message-Id: <201110131959.p9DJxPkW024565@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 07:41:05 EDT." <4E96CE51.7020600@riw.us> Date: Thu, 13 Oct 2011 12:59:25 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:59:29 -0000 In message <4E96CE51.7020600@riw.us> Russ White writes: > > > Should the applications be insecure and rely on a firewall? > > (Microsoft advocated this in the 1990s and it has stuck to a large > > extent). Or should the network be open and the applications secure? > > > > I'm strongly with you on this. The applications should take care of > > any security that is necessary *for that application*. > > In other words, we should abandon door locks and make certain that > anything you don't want stolen is individually secured --because only > the device manufacturer could ever know how valuable it is, and how best > to prevent it being stolen? Following that analogy, the door locks built my certain OS vendors are both flimsy and easily picked. And we should not enable tftp and point it at the root directory and hope that some smart network appliance will somehow firewall us. > In your own words: > > > No. No. No. > > Security is layered in the physical world, and it should be layered in > the network, as well. That I argue for a default "domain based" posture, > where all machines within a given "domain" are all fully reachable, but > those outside the "domain" are not reachable unless specific actions are > taken to make them reachable, doesn't mean I don't think individual > computers need security at all, or that all security should rely on the > firewall. > > "All security must be on the firewall or in the applications" is a false > dichotomy. Ideally the firewall should be unnecessary. In some cases a firewall is out of the question. For example, a router cannot rely on sitting behind a firewall. That is not to say that packet filters at the border don't serve as a valuable denial of service protection against pure traffic based attacks. Firewalls more often get in the way than do any good. They also give a false sense of security which results in the occasional "our LAN is currently swamped as a result of the latest virus run amuck on our LAN" coming from IT. > > Security is not a layer-2 function. Security is an application > > function. You had it right the first time. Key exchanges and > > certificates are not layer-2 functions. > > Security is an application function, yes. Security is also a network > function, and security is a machine level function. All of these have a > role to play in security. > > :-) > > Russ The operations staff for the T3-NSFNET had no firewall and was security audited by some of the best in the field. Of course we did not allow the use of a PC with Windows in operations. No such thing could sit on the same subnet. Another division in ANS that relied on a firewall was the only part of the company that even had to have all computers taken down and scrubbed before they could be used again. [Requirement at that time of having certain government customers]. Every computer had to be physically removed, rebooted from other media, backed up, reinstalled, user files restored from a backup prior to the breach, and returned to the rack or the user's desk. Users had to fetch any lost work from the backups and were supposed to insure that no changes where made to recovered source code. Sound painful and costly? It was! Network protection of insecure host applications is false security. It takes just one host breach to compromise the whole internal network. I've seen it first hand many times. [not quite first hand since my computers never relied on a firewall for security but a few times on the corporate LAN they were sitting on.] IPSEC also got it wrong. The application really is the right place for security. :-) btw- Anti-virus software is a cruel hoax. [that someone makes money on] :-) > > It is entirely possible that the same computer has pictures of Grandma > > that I'm OK with you seeing and has a printer hanging off it that I > > don't want anyone in the world to be able to print on. Same MAC > > address. So that can't be a layer-2 function. > > > > And port filtering at a firewall is a lame excuse for security. The > > bug in relying on a firewall in an enterprise (a little less so for a > > home) is that once any one user downloads malware, that malware has > > access to everthing behind the firewall largely because of the > > assumption that security is not needed because there is a firewall. > > > > Lets not enshine the dumbest practices of the IT world. > > > >> I think homenet should focus on L3. (and be clear on what it expects > >> from the other layers with regards to security). > >> > >> cheers, > >> Ole > > > > Curtis From curtis@occnc.com Thu Oct 13 13:05:35 2011 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 6607621F8B7E for ; Thu, 13 Oct 2011 13:05:35 -0700 (PDT) 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.044, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVx-bQud4ojs for ; Thu, 13 Oct 2011 13:05:34 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id AD01821F8B72 for ; Thu, 13 Oct 2011 13:05:34 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DK5Xw5027053; Thu, 13 Oct 2011 13:05:34 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DK5Xw5027053 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318536334; bh=xStKjFidiNbbIVN1xYadlLBxwJiWFmLTvp+tC6LE+Vc=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=FZfgucjrXG30qX75U/9Pk9Rl07YfBp43oZz973+uFom6gQB6rzcSZRQ1K0uYqLh/D o+TjTImw1uYjQGGGtytkESGos5GQ8QeuyiRDx7VF18VXkQISJi5l4Skk2e9VbvL6DG 9muqnEutRohFDZ37B9wlD1/uVFD0GZHcENjRz+Pk= Message-Id: <201110132005.p9DK5Xw5027053@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 07:44:11 EDT." <4E96CF0B.8060909@riw.us> Date: Thu, 13 Oct 2011 13:05:33 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:05:35 -0000 In message <4E96CF0B.8060909@riw.us> Russ White writes: > > > Is it better to leave the possibility of theft of service or is it > > better to have the device unusable by default (until configured)? > > This is a false dichotomy, as well... > > It is best to find some reasonable ground where 90% of the people in > the world will find the security acceptable, and then let the 10% who > care configure the rest. > > But I would also point out that the argument you're making can be > applied to applications as well as network gear. > > :-) > > Russ We are talking about whether to bring up routing. The risk is theft of service. This is like locking the screen door if the inside door deadbolt is already locked. It is only an issue if the inside door has no locks or has very ineffective locks and even then locking the screen door doesn't really help much anyway. Every WiFi product I ever bought was open WiFi as shipped. Curtis From curtis@occnc.com Thu Oct 13 13:09:16 2011 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 6A27E21F8669 for ; Thu, 13 Oct 2011 13:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRNMs6ym-84l for ; Thu, 13 Oct 2011 13:09:16 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D1EFE21F84A3 for ; Thu, 13 Oct 2011 13:09:15 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DK9Ett028295; Thu, 13 Oct 2011 13:09:14 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DK9Ett028295 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318536554; bh=pLlsbSbd6RQMty0Des85Z/A/jYGao3YabB4jAfXD/Vw=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=O5M52rWpW+oEHCDvRQRTASF8vVvd/jTmbGmyouTImk1NTXWFMjARlhh8GdSQ4s8d5 b8HwPhDM9kip3e4xdDWIzyknbsD9zw0KthRqMwZ6+SFV/mrpSfP+bWbkmbSIkBdajc vnoPOcJVUL3XIojGPxnAr99aeMyDvoWH9oKs2Irs= Message-Id: <201110132009.p9DK9Ett028295@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 07:46:53 EDT." <4E96CFAD.6090901@riw.us> Date: Thu, 13 Oct 2011 13:09:13 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Homenet strawman slides X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:09:16 -0000 In message <4E96CFAD.6090901@riw.us> Russ White writes: > > >> A router should not start handing out PD or even IPv4 NAT space until > >> it gets and address from elsewhere. > > In other words, your home network should be unusable unless at least one > edge device is connected to the "real world." I can just imagine the > support calls the local provider will get when they have a local outage. > > "I'm sorry, sir, but that's the way it works --you can't print or stream > movies from your console unless your internet connection is up." > > Yeah, that's going to fly. > > :-) > > Russ Maybe mail crossed. IPv6 can function with just link local and ULA until it gets a routeable prefix. IPv4 is stuck handing out a NAT address if it has no other configuration so modify the second part of that sentence. Curtis From curtis@occnc.com Thu Oct 13 13:18:48 2011 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 EC20421F8AE6 for ; Thu, 13 Oct 2011 13:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONbPpDGVal3d for ; Thu, 13 Oct 2011 13:18:48 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 5375321F8772 for ; Thu, 13 Oct 2011 13:18:48 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DKIjWo031144; Thu, 13 Oct 2011 13:18:46 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DKIjWo031144 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318537126; bh=J0Z0kVUmllIuVp1oBlCSn6KDN5QKPwkiae5TDQnVrXI=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=R2OedcCxVSgfj1aBNGNqjVjw4ZRWNRbzRDaC/nyZ6d8RDUqw/w2nLFGp3AgI4DP1K HsayXO8V9NefFvgbAvXOnqfVesGWKqF8V+/iIYKiJ4uGzO9imZ3+QMRhuKMTcmwadI Tj1dLTy3yhsY8yC8VmGqDYQ9UcrhqdkE8T5ajVho= Message-Id: <201110132018.p9DKIjWo031144@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 07:53:41 EDT." <4E96D145.5090609@riw.us> Date: Thu, 13 Oct 2011 13:18:45 -0700 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] Thoughts about routing - trends X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:18:49 -0000 Off list. In message <4E96D145.5090609@riw.us> Russ White writes: > > > At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted > > pair. [Well someone pulled it, but not me.] Anyone remember vampire > > taps in 10base2? What a reliability headache! > > Pulled from cable hanging in a "plenum" in a secure building... Because > there was no way to get cable floor to floor other than through that > single shaft. For a Xerox Star system. Then there was the token bus for > the little Novell network over in legal --another disaster. I managed to avoid token ring and novell. > > Back on topic: I do think we should consider OSPF (not so keen on > > ISIS, but OK) and should not rule out OLSRv2 or other LLN related work > > and MANET work (though I'm far from an expert on LLN or MANET). > > IS-IS is easier to get to "zero config," and it's actually simpler in > operation... Which is why I brought it up. :-) I've used both. Why do you think ISIS is simpler in operation? Because people love to deal with NSAPs? > > We will have to extend OSPF to make zero config possible. The > > extensions should be completely backwards compatible if at all > > possible. > > Yes, I agree... Or we need w new wired/wireless protocol that jumps both > worlds, and would actually be acceptable and implemented by a large > number of vendors. But that's another entire problem space... We agree on something. That's good. :-) The clueless vendor problem space is a tough one. > :-) > > Russ Curtis From curtis@occnc.com Thu Oct 13 13:30:51 2011 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 2E8E821F84D1 for ; Thu, 13 Oct 2011 13:30:51 -0700 (PDT) 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.259, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nuu3wI-qzgDC for ; Thu, 13 Oct 2011 13:30:50 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA0C21F849A for ; Thu, 13 Oct 2011 13:30:50 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DKUnG5033164; Thu, 13 Oct 2011 13:30:49 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DKUnG5033164 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318537849; bh=fz45dUHg+aGiv1hzXUvIuB0D6Wdk/yr146sjfz6dXlo=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=KmNKzYykKuMzROs+xSUCG7A8+Y/hVqxPjnww1o+gbMrML5PI53pR1dTAsSA7TbQKB 3dGsBdSUkruEG2hMMguwq1/TRRkQ8Ji0tTgpHn2cRmofI2hl0G4mswiZK6onQANa2t xuHhtWhN64/AFlblN91O0AOaiPVD2J9lRqME2ZEw= Message-Id: <201110132030.p9DKUnG5033164@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 09:49:32 EDT." <14861.1318513772@marajade.sandelman.ca> Date: Thu, 13 Oct 2011 13:30:48 -0700 Cc: "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:30:51 -0000 In message <14861.1318513772@marajade.sandelman.ca> Michael Richardson writes: > >>>>> "Mark" == Mark Andrews writes: > >> Or you solve the time problem some other way... > >> > >> Batteries die too... Jim > > Mark> Indeed. It should be a user servicable part. > > Mark> As to solving it other way, "leap of faith" springs to mind. > > DHCP has an NTP server option. Does IP6CP? If you are trying to validate keys or certificates or proteocol extensions that require knowing the time of day, then using the DHCP supplied NTP server might not be a great idea. I'm not fond of protocols that rely on time or monotonically increasing reboot counts and have no fallback. I advocated in OSPF discussions relevant to KARP (to no avail) having at least a fallback to a mechanism in which time of day or reboot count was not significant. This means no certificate expiration check is possible for the fallback but its better than no connectivity. The lack of certificate expiration can be compensated for by creating an explicit revokation after the key expires and storing that. Curtis From curtis@occnc.com Thu Oct 13 13:41:54 2011 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 BCE0C21F8ACE for ; Thu, 13 Oct 2011 13:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkU97FbB8e95 for ; Thu, 13 Oct 2011 13:41:54 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 10D3C21F8726 for ; Thu, 13 Oct 2011 13:41:53 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DKfrv4033626; Thu, 13 Oct 2011 13:41:53 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DKfrv4033626 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318538513; bh=hrQVspj5Xyn42FU+VlMoZyLW7O3gu1pIsZs3B+F/hfk=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=jETv2aBUmPACXVaABt9bffyQRwkXWR/oFQozYmxwCc3oapzKpUDw+f27NGUtt0xY1 cQf+6wOvsj9+H1O5z5mtOtqgqecan8mEC0Hhpgjnq1wgKyE996oWc1pI3kT4h9CqyM UNYGY1XwS/E7oFvXnEZ8XCSvHZSsHHfBzw7uOWmM= Message-Id: <201110132041.p9DKfrv4033626@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 10:05:42 EDT." <17165.1318514742@marajade.sandelman.ca> Date: Thu, 13 Oct 2011 13:41:52 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] time service and DNSSEC X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:41:54 -0000 In message <17165.1318514742@marajade.sandelman.ca> Michael Richardson writes: > >>>>> "Curtis" == Curtis Villamizar writes: > >> While talking about hardware. These these devices all need a > >> battery backed clock or all the crypto will be broken. > > > Curtis> Having a clock is not hard but I don't think your statement > Curtis> is true. > > Curtis> Some crypto does not require time, but rather just entropy > Curtis> (a nonce or challenge). For crypto that does require time > Curtis> the former can be a bootstrap of sorts, possibly to get ntp > Curtis> going if very accurate time is needed (for some reason). > > Curtis, Mark, as a DNSSEC implementer knows of what he speaks. DNSSEC > requires time. Not to the second or even minute, but at least hour. > > DNSSEC is a core protocol at this point, and we need to be aware of > it. It doesn't matter today, because we have a broken home DNS > system, but that's within homenet to fix. > > Bootstraping time enough to get DNSSEC to work is important. I was thinking routing protocols and KARP. We are talking about routers and relying on DNS to get routing up is always a really bad idea. Relying on NTP to get routing up is also a bad idea. Neither KARP, as defined, or DNSSEC, are candidates for zero configuration. If the user can configure KARP and DNSSEC they are perfectly capable of using a backdoor, like ssh, to set the time of day after a reboot that lost time-of-day. Sorry, but I lost track of why this is an issue for homenet. What zero config crypto are we talking about that may care if it loses time of day? Curtis From gettysjim@gmail.com Thu Oct 13 13:44:09 2011 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 F3A1321F8B30 for ; Thu, 13 Oct 2011 13:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKy2L7FOimIA for ; Thu, 13 Oct 2011 13:44:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64F8821F8ACE for ; Thu, 13 Oct 2011 13:44:08 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so545920vcb.31 for ; Thu, 13 Oct 2011 13:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m2UZJd8aLhjmvy0KzhldE5Tgm+GlqQM8s0cXH7mCQLo=; b=em51VDbfKUaNLKaZHL9Xak3Jlk8fIqWucXPg/UNLVf/0BYCnfU7M4xzKIffrPQsyVo 94FaS9b+Y69EE7qZGNqBITWzQhVZGMAXPChWgRXnP1VzfWPOxffMP9UUo1Dz1KnHBVCP ameOMxrKradbfXd6Y+FOt+6V6Z07QAnX/VOAU= Received: by 10.52.174.107 with SMTP id br11mr5754743vdc.12.1318538647943; Thu, 13 Oct 2011 13:44:07 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ey9sm5346380vdc.19.2011.10.13.13.44.06 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 13:44:07 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E974D95.3000801@freedesktop.org> Date: Thu, 13 Oct 2011 16:44:05 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: curtis@occnc.com References: <201110132041.p9DKfrv4033626@gateway.ipv6.occnc.com> In-Reply-To: <201110132041.p9DKfrv4033626@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Michael Richardson Subject: Re: [homenet] time service and DNSSEC 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, 13 Oct 2011 20:44:09 -0000 On 10/13/2011 04:41 PM, Curtis Villamizar wrote: > In message <17165.1318514742@marajade.sandelman.ca> > Michael Richardson writes: > >>>>>>> "Curtis" == Curtis Villamizar writes: >> >> While talking about hardware. These these devices all need a >> >> battery backed clock or all the crypto will be broken. >> >> >> Curtis> Having a clock is not hard but I don't think your statement >> Curtis> is true. >> >> Curtis> Some crypto does not require time, but rather just entropy >> Curtis> (a nonce or challenge). For crypto that does require time >> Curtis> the former can be a bootstrap of sorts, possibly to get ntp >> Curtis> going if very accurate time is needed (for some reason). >> >> Curtis, Mark, as a DNSSEC implementer knows of what he speaks. DNSSEC >> requires time. Not to the second or even minute, but at least hour. >> >> DNSSEC is a core protocol at this point, and we need to be aware of >> it. It doesn't matter today, because we have a broken home DNS >> system, but that's within homenet to fix. >> >> Bootstraping time enough to get DNSSEC to work is important. > > I was thinking routing protocols and KARP. > > We are talking about routers and relying on DNS to get routing up is > always a really bad idea. Relying on NTP to get routing up is also a > bad idea. > > Neither KARP, as defined, or DNSSEC, are candidates for zero > configuration. If the user can configure KARP and DNSSEC they are > perfectly capable of using a backdoor, like ssh, to set the time of > day after a reboot that lost time-of-day. > > Sorry, but I lost track of why this is an issue for homenet. What > zero config crypto are we talking about that may care if it loses time > of day? > DNSSEC. And as routers are already being attacked, getting DNSSEC secure end-to-end seems like the right strategy. - Jim From curtis@occnc.com Thu Oct 13 14:23:42 2011 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 A395321F8B72 for ; Thu, 13 Oct 2011 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw18u9M6XlQ8 for ; Thu, 13 Oct 2011 14:23:41 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 367AF21F8A56 for ; Thu, 13 Oct 2011 14:23:40 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DLNNIw035197; Thu, 13 Oct 2011 14:23:24 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DLNNIw035197 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318541004; bh=J/rWNtVkpXd+NFXd8/oEt0tEBTsvve8vgVfEd81ynxA=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=dRO1EyII1dTo/GHd5QygfqyvqAWcVRy8iv9srlgSK5Qsg8LKGSyfHuUSs3kLgGJE7 bh15UCoBOmnBI5nWzRAszkwKU5VxcgeFgTpe8idK/RgPUrSWXnX3NJQXviyCR+DY3M DxQMiptyEOvOt0fgnzx/Df0CynQtFB2Tyy21LrMI= Message-Id: <201110132123.p9DLNNIw035197@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 14:42:45 EDT." <300CE19E-B3D6-4742-82ED-02F8167C9F16@fugue.com> Date: Thu, 13 Oct 2011 14:23:23 -0700 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:23:42 -0000 In message <300CE19E-B3D6-4742-82ED-02F8167C9F16@fugue.com> Ted Lemon writes: > On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote: > > You've said what the problem *isn't*, so what *is* the problem on a > > homenet? > > I did say what the problem is: > > >> If you autoconfigure a routing topology, you have to make sure that > >> you don't accidentally autoconfigure it to include routers that > >> weren't intended to have been included. And I responded to that in the same email and you trimmed that part of the response in this email. Curtis From townsley@cisco.com Thu Oct 13 14:25:43 2011 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 C046C21F84A7 for ; Thu, 13 Oct 2011 14:25:43 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0X5pygXFI1t for ; Thu, 13 Oct 2011 14:25:43 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E322F21F84A2 for ; Thu, 13 Oct 2011 14:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=954; q=dns/txt; s=iport; t=1318541143; x=1319750743; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PQTnfmxkgcTXBicIK+fqo6mKUDhVYdbZZAmDhAI1p2c=; b=QxoMKw/0kKK5HSsJn96zcHA0W4cquvUwJaaWXd4zNWEPO7s1/KLt75YO GujpqlXFVX4OR2Mvz5fO4c5QikBwcLiXKzu8hXqAW3HTvbbGp0XIt3uEi zWhYvPC0GWYoL+Z77lKgd0zoSDTEdffqwW52Fb9PE42E5dDZ29w+8dSbF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAIANxWl06Q/khL/2dsb2JhbABDmXiOY4EFgVMBAQEDAQEBAQ8BJzQLEAsYLicwGSKHXAiZEwGeKQOHDGEEk3iRcQ X-IronPort-AV: E=Sophos;i="4.69,342,1315180800"; d="scan'208";a="57757959" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 13 Oct 2011 21:25:40 +0000 Received: from ams-townsley-8716.cisco.com (ams-townsley-8716.cisco.com [10.55.233.231]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9DLPejh027007; Thu, 13 Oct 2011 21:25:40 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <201110132123.p9DLNNIw035197@gateway.ipv6.occnc.com> Date: Thu, 13 Oct 2011 17:25:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110132123.p9DLNNIw035197@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, Ted Lemon Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 21:25:43 -0000 On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote: >=20 > In message <300CE19E-B3D6-4742-82ED-02F8167C9F16@fugue.com> > Ted Lemon writes: >=20 >> On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote: >>> You've said what the problem *isn't*, so what *is* the problem on a >>> homenet? >>=20 >> I did say what the problem is: >>=20 >>>> If you autoconfigure a routing topology, you have to make sure that >>>> you don't accidentally autoconfigure it to include routers that >>>> weren't intended to have been included. That's part of the "border discovery" aspect that, if we can't nail = down, everything else we do is pretty much moot.=20 - Mark >=20 >=20 > And I responded to that in the same email and you trimmed that part of > the response in this email. >=20 > Curtis > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Thu Oct 13 14:29:38 2011 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 1973121F8B95 for ; Thu, 13 Oct 2011 14:29:38 -0700 (PDT) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYqXoTg-5tLQ for ; Thu, 13 Oct 2011 14:29:37 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id AE53821F8ADE for ; Thu, 13 Oct 2011 14:29:37 -0700 (PDT) Received: from [10.1.10.11] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 9E6B52381795; Thu, 13 Oct 2011 17:29:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_D34AFD78-BFF3-4E2E-B610-65C96D46BAB7" From: Ted Lemon In-Reply-To: <201110132123.p9DLNNIw035197@gateway.ipv6.occnc.com> Date: Thu, 13 Oct 2011 17:29:30 -0400 Message-Id: <7D42549B-0EC1-463E-8E62-765C295A29B4@fugue.com> References: <201110132123.p9DLNNIw035197@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1251.1) Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 21:29:38 -0000 --Apple-Mail=_D34AFD78-BFF3-4E2E-B610-65C96D46BAB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote: > And I responded to that in the same email and you trimmed that part of > the response in this email. The problem has to do with customer-owned devices and = customer-neighbor-owned devices forming networks together. It's got = nothing to do with the ISP. Chances are, the ISP link is the one thing = that won't be gotten wrong here, because only one device you own will be = connected to it (at least in typical networks today). Of course, if your devices unintentionally include your neighbor in the = home network topology, your network will suddenly be multihomed, but = this is an artifact of the failure mode I'm talking about. Eliminating = that failure mode would solve the multihoming problem as well. --Apple-Mail=_D34AFD78-BFF3-4E2E-B610-65C96D46BAB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii And I = responded to that in the same email and you trimmed that part of
the = response in this email.
The problem = has to do with customer-owned devices and customer-neighbor-owned = devices forming networks together.   It's got nothing to do with = the ISP.   Chances are, the ISP link is the one thing that won't be = gotten wrong here, because only one device you own will be connected to = it (at least in typical networks today).

Of = course, if your devices unintentionally include your neighbor in the = home network topology, your network will suddenly be multihomed, but = this is an artifact of the failure mode I'm talking about. =  Eliminating that failure mode would solve the multihoming problem = as well.

= --Apple-Mail=_D34AFD78-BFF3-4E2E-B610-65C96D46BAB7-- From Ray.Bellis@nominet.org.uk Thu Oct 13 14:32:40 2011 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 00AB121F8A7D for ; Thu, 13 Oct 2011 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj6Yz9GfoDSg for ; Thu, 13 Oct 2011 14:32:39 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1EC21F8564 for ; Thu, 13 Oct 2011 14:32:38 -0700 (PDT) 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=c8nuIZoNP10eH5pcVHaaU+fltnYnKLd5Ie0DwsDoaNCCYgxhd5+Xl6qD HwaB+pHuTk5ikfVEuTHWNAWuVMThdIVKYQJwrVVRbwpNaAoNQp9EyXU6o CHdjx5qY8VqX+qi; 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=1318541559; x=1350077559; 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]=20security=20question=20for =20zeroconf=20stuff=20inside=20the=0D=0A=20homenet... |Date:=20Thu,=2013=20Oct=202011=2021:32:35=20+0000 |Message-ID:=20<857A0AA1-7F09-488D-A7B2-E9529529927E@nomi net.org.uk>|To:=20Stephen=20Farrell=20|CC:=20""=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20|In-Reply-To:=20<4E94BF91.4060807@cs.tcd.ie> |References:=20<4E94BF91.4060807@cs.tcd.ie>; bh=p9+5OKuqBrx7ES+1FVO1KUhPVzXlOSvHzuE0iAf4Zyk=; b=C8SLKJ9341tfRRfEDja6Zco9qQ7+qljISSIcaIkdOhK0rCWeu9YdkHyu 0RaLVGYz7faIaHGo8MxcDELvYljLkBnOHchQLkzZPy8iTNTv16vU2Vn35 rHelKFaUsCOxdPB; X-IronPort-AV: E=Sophos;i="4.69,342,1315177200"; d="scan'208";a="28972983" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 13 Oct 2011 22:32:37 +0100 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%19]) with mapi; Thu, 13 Oct 2011 22:32:37 +0100 From: Ray Bellis To: Stephen Farrell Thread-Topic: [homenet] security question for zeroconf stuff inside the homenet... Thread-Index: AQHMiGMU1dPGCBAKvkSDUtN7JpT7MZV3sxyA Date: Thu, 13 Oct 2011 21:32:35 +0000 Message-ID: <857A0AA1-7F09-488D-A7B2-E9529529927E@nominet.org.uk> References: <4E94BF91.4060807@cs.tcd.ie> In-Reply-To: <4E94BF91.4060807@cs.tcd.ie> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 21:32:40 -0000 On 11 Oct 2011, at 18:13, Stephen Farrell wrote: > When various devices in the home figure out which does what, > and do that periodically to handle changes, there's clearly > the potential that a zombied host tries to try take over > stuff with undesirable consequences. >=20 > My question is whether this group are planning to think > about that now, or later, or never? (Or don't even think > there's a problem worth attempting to address.) >=20 > Note - I'm not trying to argue for any particular level of > security and certainly not for some unachievable fort knox > everywhere, I'm just asking what's the plan? We're certainly expecting to think about it. However mandating any particular mechanism for how a device can identify it= self as part of the "trusted" home would likely be out of scope. Ray From curtis@occnc.com Thu Oct 13 14:40:38 2011 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 657C921F8B50 for ; Thu, 13 Oct 2011 14:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZZvpjKdOn6s for ; Thu, 13 Oct 2011 14:40:37 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 970D621F8B66 for ; Thu, 13 Oct 2011 14:40:37 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DLeYN3035491; Thu, 13 Oct 2011 14:40:34 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DLeYN3035491 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318542034; bh=OCULO3iDfi+n59NALu6Xgi+t2w3awYILDgaSkBe9iCk=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=NhkJImwtANpInDkmreeLC1k63oPC++yQdaGNS80UgvrDnC10Z4icKj92hxe2B5t+g gCzZEpA9ccNgYQ6jRiSgHpS+vMk101JhoGwVEYJrqoYb1hBe2KD/QdXtIXktERdxID Xhc2Y5y5WcmDD8Ul0Ee6bm80rm96sL2f2sNLu0TQ= Message-Id: <201110132140.p9DLeYN3035491@gateway.ipv6.occnc.com> To: Jim Gettys From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 15:03:33 EDT." <4E973605.50309@freedesktop.org> Date: Thu, 13 Oct 2011 14:40:34 -0700 Cc: Russ White , homenet@ietf.org, Michael Richardson , curtis@occnc.com Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:40:38 -0000 In message <4E973605.50309@freedesktop.org> Jim Gettys writes: > On 10/13/2011 02:42 PM, Curtis Villamizar wrote: > > > > Yes and there are/were ATM switches that implement RFC1577, LANE, > > MPOA, and NHRP. None of that worked very well and it all is > > essentially abandoned work now. Pre-existence alone is not a worth > > while evaluation criteria. > > > > If zOSPF works perfectly, including in the presence of legacy routers > > which don't look at a new 48 bit mac address router-id extension, we > > have no reason to continue the discussion. We just indicate "use > > zOSPF" and we're done. > > > > There seems to be consensus that we're not done. > > > On my part, I'm interested in understanding the following: > o scaling properties: I worry about the apartment building case, and > related dense mesh case. Yep. OSPF as is may not be appropriate for wireless mesh. WG needs to consider this. > o behaviour when routing both wired and wireless networks. > o multicast behaviour and impact on wireless networks. > o running code Running code is too seldom available when the IETF rushes forward these days. A reference implementation would be great. I know which code base you have in mind. > And I'll ask the same about any other routing protocol you wish to > name. I'm an equal opportunity parade rainer... > - Jim I haven't checked cerowrt to see how much configuration is required of OSPF. If it is quagga, then a router-id has to be configured and each interface has to have OSPF explicitly enabled all with a Cisco style line oriented config. Curtis From curtis@occnc.com Thu Oct 13 15:15:41 2011 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 0091821F8C10 for ; Thu, 13 Oct 2011 15:15:41 -0700 (PDT) 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.044, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7GHMF78dWz4 for ; Thu, 13 Oct 2011 15:15:40 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 05EDC21F8BBA for ; Thu, 13 Oct 2011 15:15:39 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DMFXgX036263; Thu, 13 Oct 2011 15:15:34 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DMFXgX036263 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318544134; bh=cUHR5HDekSTU2sLcmrx46jvVTbxBnF8bi7/i7WnFctM=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=BvCcPQ8IvLynITdVRjFeKQaPwysWEsiK5jZkd+XtNWx3NzlMV7FjAgVCeNO1Ibq8e WjQ+Yyo624BUy4SjA8IxH38/gdlWy5Of/H+26q/lumfV4Jjq20+BNRfTKmlDpuOG+9 cgPWuOVJDjZntY6OHA8k6FtoL4vNhJEGip+72rPo= Message-Id: <201110132215.p9DMFXgX036263@gateway.ipv6.occnc.com> To: Jim Gettys From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 16:44:05 EDT." <4E974D95.3000801@freedesktop.org> Date: Thu, 13 Oct 2011 15:15:33 -0700 Cc: homenet@ietf.org, Michael Richardson , curtis@occnc.com Subject: Re: [homenet] time service and DNSSEC X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 22:15:41 -0000 In message <4E974D95.3000801@freedesktop.org> Jim Gettys writes: > > > > Sorry, but I lost track of why this is an issue for homenet. What > > zero config crypto are we talking about that may care if it loses time > > of day? > > > DNSSEC. > > And as routers are already being attacked, getting DNSSEC secure > end-to-end seems like the right strategy. > - Jim Trimmed response. I don't follow the logic here. I don't see any relationship between "routers are already being attacked" and DNSSEC. The homenet user is not going to get DNS or DNSSEC configured for the LAN addresses on their network so I'm not sure why the topic is even relevant to homenet. Back in the days when I was involved in big-I Internet operations routers purposely didn't run rely on DNS to avoid a chicken and egg problem (router can't reach DNS therefore routing is down). Even logs used IP addresses and could be translated after the fact if need be. I'm quite knowledgeable in routers getting attacked. The homenet routing protocol would be wise to use GTSM on things like OSPF. Open routing on wireless might still be a bad idea. Maybe keys or shared secret has to be added for wireless making it non-zero config. Curtis From curtis@occnc.com Thu Oct 13 16:02:50 2011 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 EFD7F21F8BE9 for ; Thu, 13 Oct 2011 16:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFVfZylaBdb7 for ; Thu, 13 Oct 2011 16:02:50 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 135BE21F8BE8 for ; Thu, 13 Oct 2011 16:02:49 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9DN2Wgi037732; Thu, 13 Oct 2011 16:02:33 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9DN2Wgi037732 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318546954; bh=MGQmqxqrSL85JMm15Zqo18A7dp/RLATfpJ/zr4WR4O0=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=OqK63s1ZVs/3+2QGSoF7H5uZISUHkSyJzdz5MlawfSgLjFmXk73wT38uYEYRZZpjG v8vlXYdU0mU343Nj06eOoODZNWQWWgpBBlySmHcb01hKadI1rMx4cXv9jQuS30+n/p 4hh/6Yua9HtIfZxZ312evR8daytKm6dlyExIsvLc= Message-Id: <201110132302.p9DN2Wgi037732@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 17:29:30 EDT." <7D42549B-0EC1-463E-8E62-765C295A29B4@fugue.com> Date: Thu, 13 Oct 2011 16:02:32 -0700 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 23:02:51 -0000 In message <7D42549B-0EC1-463E-8E62-765C295A29B4@fugue.com> Ted Lemon writes: > On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote: > > And I responded to that in the same email and you trimmed that part of > > the response in this email. > > The problem has to do with customer-owned devices and > customer-neighbor-owned devices forming networks together. It's got > nothing to do with the ISP. Chances are, the ISP link is the one > thing that won't be gotten wrong here, because only one device you own > will be connected to it (at least in typical networks today). And therefore risk there is mostly theft of service as I have already pointed out. A WiFi AP will not connect to another AP and wireless routers are typically AP by default. So if two wireless routers autoconfig to being AP and using open routing, then there is only a risk if something that is an WiFi client is also a configured to be a router. > Of course, if your devices unintentionally include your neighbor in > the home network topology, your network will suddenly be multihomed, > but this is an artifact of the failure mode I'm talking about. > Eliminating that failure mode would solve the multihoming problem as > well. Some would call that a feature, not a failure mode. :-) But it usually does violate the service provider agreement and therefore open routing (or bridging) over wireless creates a potential theft of service. Ignoring that AP don't talk to AP. This is really an issue for wireless not for wired and is nothing new. AFAIK all wireless products today ship "open" and configured as an "AP" and have to be changed to enable some form of authentication. And many users never bother to change this. So what is new about a wireless router vs existing wireless bridges that do this? Curtis From gettysjim@gmail.com Thu Oct 13 16:15:13 2011 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 2642921F8B75 for ; Thu, 13 Oct 2011 16:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re+XuHZwmfpS for ; Thu, 13 Oct 2011 16:15:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 883A221F8B72 for ; Thu, 13 Oct 2011 16:15:12 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so650805vcb.31 for ; Thu, 13 Oct 2011 16:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EQ+sy8nguUaAmtEWEceSQyF4NffZfR3D5dBOXZ/LROk=; b=Na8SBDTcCmDQxAZJWxiRgV9MPIwkoVVowsuA7TSINyn5vWxiM0yLgrlBi7vEcWAo33 3/dMGTkN+t3LNqIHvKJYVED+f522dJuNchuePP7UqreVIS7rPwkWI2hevyvLY9rcDzE7 umieQoHKre/apvmYKMo2QD7GdvV6QCuvpfIJE= Received: by 10.220.153.69 with SMTP id j5mr421452vcw.212.1318547710950; Thu, 13 Oct 2011 16:15:10 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id jo8sm5733460vdb.20.2011.10.13.16.15.09 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 16:15:10 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E9770FC.8050602@freedesktop.org> Date: Thu, 13 Oct 2011 19:15:08 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: curtis@occnc.com References: <201110132215.p9DMFXgX036263@gateway.ipv6.occnc.com> In-Reply-To: <201110132215.p9DMFXgX036263@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Michael Richardson Subject: Re: [homenet] time service and DNSSEC 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, 13 Oct 2011 23:15:13 -0000 On 10/13/2011 06:15 PM, Curtis Villamizar wrote: > In message <4E974D95.3000801@freedesktop.org> > Jim Gettys writes: >>> Sorry, but I lost track of why this is an issue for homenet. What >>> zero config crypto are we talking about that may care if it loses time >>> of day? >>> >> DNSSEC. >> >> And as routers are already being attacked, getting DNSSEC secure >> end-to-end seems like the right strategy. >> - Jim > > Trimmed response. > > I don't follow the logic here. > > I don't see any relationship between "routers are already being > attacked" and DNSSEC. > > The homenet user is not going to get DNS or DNSSEC configured for the > LAN addresses on their network so I'm not sure why the topic is even > relevant to homenet. Why not? Plug in a named computer, and publish it's name into the global DNS... Proof of principle was demonstrated by Dave Taht and Evan Hunt when they brought up bind on CeroWrt even if it isn't in today's CeroWrt build. It isn't that hard... > > Back in the days when I was involved in big-I Internet operations > routers purposely didn't run rely on DNS to avoid a chicken and egg > problem (router can't reach DNS therefore routing is down). Even logs > used IP addresses and could be translated after the fact if need be. > > I'm quite knowledgeable in routers getting attacked. The homenet > routing protocol would be wise to use GTSM on things like OSPF. Open > routing on wireless might still be a bad idea. Maybe keys or shared > secret has to be added for wireless making it non-zero config. Could be. I have no clue what the community networking people are doing about routing protocol security in OLSR or other protocols. I certainly *hope* they are doing something, as some of their networks are now in the hundreds or even thousands of nodes... - Jim From mellon@fugue.com Thu Oct 13 16:28:10 2011 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 7933221F8B7E for ; Thu, 13 Oct 2011 16:28:10 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pvgbkc2II23 for ; Thu, 13 Oct 2011 16:28:10 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEF121F8B75 for ; Thu, 13 Oct 2011 16:28:10 -0700 (PDT) Received: from [10.0.1.8] (unknown [64.215.212.152]) by toccata.fugue.com (Postfix) with ESMTPSA id AAAA82381795; Thu, 13 Oct 2011 19:28:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_B819BFCC-6E32-43AA-A8F7-327A48A1C6F5" From: Ted Lemon In-Reply-To: <201110132302.p9DN2Wgi037732@gateway.ipv6.occnc.com> Date: Thu, 13 Oct 2011 19:28:07 -0400 Message-Id: References: <201110132302.p9DN2Wgi037732@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1251.1) Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 13 Oct 2011 23:28:10 -0000 --Apple-Mail=_B819BFCC-6E32-43AA-A8F7-327A48A1C6F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 13, 2011, at 7:02 PM, Curtis Villamizar wrote: > And therefore risk there is mostly theft of service as I have already > pointed out. No, that is a side issue. The risk is that two networks will = self-configure into a single topology without being told to do so.=20 > Some would call that a feature, not a failure mode. :-) Your optimism is charming. However, the more likely case is that the = network topology that automatically forms will not work, or will direct = all traffic out a single internet link and go over someone's service = limits. And there will be nobody within shouting distance of this = fiasco who will be qualified to even guess what might be happening, much = less fix it. --Apple-Mail=_B819BFCC-6E32-43AA-A8F7-327A48A1C6F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii And therefore = risk there is mostly theft of service as I have already
pointed = out.
No, that is a side issue.   = The risk is that two networks will self-configure into a single topology = without being told to do so. 

Some would call that a feature, not a failure mode. =  :-)

Your optimism is charming. =   However, the more likely case is that the network topology that = automatically forms will not work, or will direct all traffic out a = single internet link and go over someone's service limits.   And = there will be nobody within shouting distance of this fiasco who will be = qualified to even guess what might be happening, much less fix = it.

= --Apple-Mail=_B819BFCC-6E32-43AA-A8F7-327A48A1C6F5-- From touch@isi.edu Thu Oct 13 16:38:13 2011 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 5208C21F8B37 for ; Thu, 13 Oct 2011 16:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOSRkylAOeY8 for ; Thu, 13 Oct 2011 16:38:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DE7A521F8ADE for ; Thu, 13 Oct 2011 16:38:12 -0700 (PDT) Received: from [68.181.28.14] (wireless-028-014.usc.edu [68.181.28.14]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p9DNbksR023418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Oct 2011 16:37:56 -0700 (PDT) References: <201110132030.p9DKUnG5033164@gateway.ipv6.occnc.com> In-Reply-To: <201110132030.p9DKUnG5033164@gateway.ipv6.occnc.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (9A334) From: Joe Touch Date: Thu, 13 Oct 2011 16:37:45 -0700 To: "curtis@occnc.com" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "homenet@ietf.org" , Michael Richardson Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 23:38:13 -0000 On Oct 13, 2011, at 1:30 PM, Curtis Villamizar wrote: > I'm not fond of protocols that rely on time or monotonically > increasing reboot counts and have no fallback. +1 Let's not add time as an attack vector. Joe From gettysjim@gmail.com Thu Oct 13 16:50:10 2011 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 34A1C21F8BB1 for ; Thu, 13 Oct 2011 16:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXd8i-e7ZiPA for ; Thu, 13 Oct 2011 16:50:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9198921F8BA0 for ; Thu, 13 Oct 2011 16:50:09 -0700 (PDT) Received: by vws5 with SMTP id 5so675889vws.31 for ; Thu, 13 Oct 2011 16:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eeD2csSczPB7Tb2iv1D/kOp07U53axPg43JXG1SGZGA=; b=AXxQVJLNwhXnbr3USdnrveqN6tqJ5Lqrq1SHZYymiY2+I3mGXToj4zTk2MNwR7uVLP tZ2Kf3kL1Z0NPyST+0M5BRZEGDjMx0GceYKjHF8hc7qSpK4EVV7BGdu9h7DXqZt5NeVP I+TPkqjTO/TuUS2dOv49JLW6dFm1tCw5PWAps= Received: by 10.52.34.100 with SMTP id y4mr6181888vdi.66.1318549809103; Thu, 13 Oct 2011 16:50:09 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id l4sm5854411vdv.4.2011.10.13.16.50.07 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 16:50:08 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E97792E.9000704@freedesktop.org> Date: Thu, 13 Oct 2011 19:50:06 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: curtis@occnc.com References: <201110132140.p9DLeYN3035491@gateway.ipv6.occnc.com> In-Reply-To: <201110132140.p9DLeYN3035491@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Russ White , homenet@ietf.org, Michael Richardson Subject: Re: [homenet] Thoughts about routing 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, 13 Oct 2011 23:50:10 -0000 On 10/13/2011 05:40 PM, Curtis Villamizar wrote: > In message <4E973605.50309@freedesktop.org> > Jim Gettys writes: > >> On 10/13/2011 02:42 PM, Curtis Villamizar wrote: >>> Yes and there are/were ATM switches that implement RFC1577, LANE, >>> MPOA, and NHRP. None of that worked very well and it all is >>> essentially abandoned work now. Pre-existence alone is not a worth >>> while evaluation criteria. >>> >>> If zOSPF works perfectly, including in the presence of legacy routers >>> which don't look at a new 48 bit mac address router-id extension, we >>> have no reason to continue the discussion. We just indicate "use >>> zOSPF" and we're done. >>> >>> There seems to be consensus that we're not done. >>> >> On my part, I'm interested in understanding the following: >> o scaling properties: I worry about the apartment building case, and >> related dense mesh case. > Yep. OSPF as is may not be appropriate for wireless mesh. WG needs > to consider this. > >> o behaviour when routing both wired and wireless networks. >> o multicast behaviour and impact on wireless networks. >> o running code > Running code is too seldom available when the IETF rushes forward > these days. A reference implementation would be great. I know which > code base you have in mind. I've been badly burned by standards committees in the past on this topic. Happens to be the IEEE folks, however. Ergo my belief in both running code and testing in diverse environments outside of laboratories and meeting rooms. And, in the case of the home router market, code has to come from some place. Advocating something that has to be built from scratch seems like a losing strategy. > >> And I'll ask the same about any other routing protocol you wish to >> name. I'm an equal opportunity parade rainer... >> - Jim > I haven't checked cerowrt to see how much configuration is required of > OSPF. All Dave did was build and package quagga so that others could conveniently start to play. > If it is quagga, then a router-id has to be configured and each > interface has to have OSPF explicitly enabled all with a Cisco style > line oriented config. Quagga has been packaged. You can build other stuff and packaged it too, and the code is available to be modified. - Jim From russw@riw.us Thu Oct 13 17:26:55 2011 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 1010F21F8BB1 for ; Thu, 13 Oct 2011 17:26:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgRvkBFYhJT1 for ; Thu, 13 Oct 2011 17:26:54 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB721F8BA0 for ; Thu, 13 Oct 2011 17:26:54 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:61729 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1REVbw-0006Tf-5K; Thu, 13 Oct 2011 20:26:52 -0400 Message-ID: <4E9781B5.5090307@riw.us> Date: Thu, 13 Oct 2011 20:26:29 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110131959.p9DJxPkW024565@gateway.ipv6.occnc.com> In-Reply-To: <201110131959.p9DJxPkW024565@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Fri, 14 Oct 2011 00:26:55 -0000 > Following that analogy, the door locks built my certain OS vendors are > both flimsy and easily picked. > > And we should not enable tftp and point it at the root directory and > hope that some smart network appliance will somehow firewall us. My point is that you need both. This is not an either/or situation, it's a both/and situation. The network needs to provide some pieces of the security, and the devices some more, and the applications some more. Putting all your eggs in one basket will just mean a lot more broken eggs in the end. > The operations staff for the T3-NSFNET had no firewall and was > security audited by some of the best in the field. Of course we did > not allow the use of a PC with Windows in operations. No such thing > could sit on the same subnet. And you're willing to lend out that staff, free, to anyone and everyone who needs a secure network? Again, throwing the security problem at the application isn't a good solution. :-) Russ From russw@riw.us Thu Oct 13 17:29:20 2011 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 458DD21F849A for ; Thu, 13 Oct 2011 17:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3LGIT7VgCv0 for ; Thu, 13 Oct 2011 17:29:19 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id CF6D121F8491 for ; Thu, 13 Oct 2011 17:29:19 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:61758 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1REVeI-0003Py-3H; Thu, 13 Oct 2011 20:29:18 -0400 Message-ID: <4E978247.6040503@riw.us> Date: Thu, 13 Oct 2011 20:28:55 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110132005.p9DK5Xw5027053@gateway.ipv6.occnc.com> In-Reply-To: <201110132005.p9DK5Xw5027053@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: homenet@ietf.org Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Fri, 14 Oct 2011 00:29:20 -0000 >> It is best to find some reasonable ground where 90% of the people in >> the world will find the security acceptable, and then let the 10% who >> care configure the rest. >> >> But I would also point out that the argument you're making can be >> applied to applications as well as network gear. > We are talking about whether to bring up routing. The risk is theft > of service. This is like locking the screen door if the inside door > deadbolt is already locked. No, we're talking about what sort of reachability to provide once routing is up. > It is only an issue if the inside door has no locks or has very > ineffective locks and even then locking the screen door doesn't really > help much anyway. I completely disagree. Even a screen door can be an effective component of an overall security system. Having a system is the key, not a single component that handles all security of all types in all situations. :-) Russ From victor.kuarsingh@gmail.com Thu Oct 13 17:57:27 2011 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 B131621F8B37 for ; Thu, 13 Oct 2011 17:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0Z8CF2xIGmC for ; Thu, 13 Oct 2011 17:57:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09A4321F8B34 for ; Thu, 13 Oct 2011 17:57:26 -0700 (PDT) Received: by ggnk3 with SMTP id k3so688580ggn.31 for ; Thu, 13 Oct 2011 17:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=b7T8I9IC0D+3TAGTiyumEgr/VYShduUcviVE5+ichh8=; b=BbDYtO2A6XKzFxD/WKx8qMNKbCPp0U9GxiTQp06DRPGAIGnN5DOkbQHWl9eA8vLChY xjyefsYnEv1KjC0+nyl4IL19PSsyavqHz+ll65aafeFooj6rGk+pUtlpmYgWR0litrVb MO4HaQLluvi/eh66rybR8tj+2rMt8etUULsK4= Received: by 10.236.157.229 with SMTP id o65mr8529251yhk.73.1318553845554; Thu, 13 Oct 2011 17:57:25 -0700 (PDT) Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id 15sm1243623anz.16.2011.10.13.17.57.22 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 17:57:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 13 Oct 2011 20:57:20 -0400 From: Victor Kuarsingh To: Russ White , Message-ID: Thread-Topic: [homenet] Does ND Proxy useful for homenet? In-Reply-To: <4E96D052.3050108@riw.us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [homenet] Does ND Proxy useful for 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: Fri, 14 Oct 2011 00:57:27 -0000 On 11-10-13 7:49 AM, "Russ White" wrote: > >> >>>>> "Victor" == Victor Kuarsingh > > writes: >> Victor> These devices (in such operating modes) are however not >> Victor> likely to participate in a home network (as the gateway >> Victor> device or a router) and it's very unlikely to be the >>head of >> Victor> home network. >> >> I STRONGLY DISAGREE. >> >> That's fine. My statement was based on an aggregate set of behaviors >> over millions of endpoints. Corner cases always exist (and perhaps not >> so corner in the future). > >This won't be the "corner case," it will be the "common case," in most >all homes. The electricity providers are seeing to that right now, as >well as the cell phone providers. In a few years, someone is going to >say, "you only have one internet connection? You poor soul, we need to >find some government program to help you." Russ, I agree the mobile network will be used widely in home networks by the residential and business customers (as you noted electricity providers). Although I would suppose those connections will not be using cell phones for connectivity, but more gateway style devices with a 2G/3G/4G connection. Most of these devices tend to be somewhat stationary (I.e. Meters, parking kiosks, etc). Some devices are nomadic but those tend to be end points themselves with built in radios. The corner case I was talking about was the use of a smartphone (generally nomadic device) as a gateway with the expectation that when at home becomes an active part of the home network fabric and exchanges routing information. When the person turns off their phone, leaves the house, etc - the device would then be removed from the network (assuming it attached in the first place). Assuming for now that this will be common case (my iPHone/Android Phone is part of my home network when I show up at home and then disappears when I leave) - I would have some concerns if this was all automatic with absolutely no user intervention or permission. I can imagine a use cases where a bunch of friends show up at a house party and become a mesh network with many attachments to the network (assuming all automatic and happens without user intervention - as one of the previous comments had noted was a possibility). Not sure how that would work - and I would not want to be the guy who's phone was chosen (automatically) to be the gateway for all (my bill may be quite large that month). All that said, I would likely lean toward the notion that smartphone vendors, if they make their devices full gateways for such use, would not just make this fully automatic such that it would happen by accident. A simple "do you want to attach to X" popup/message may be warranted. If so, then the phone can move from "I am a lone gateway with small local network mode" to "I am now a router in a larger network" and augment functions accordingly. The former case, which is very common now, needs to be addressed (and for a while may have not PD). I would not also want to assume that all the smartphone vendors will build amazing gateways for such uses (vendors who always maximize CPU/Memory to make sure the user has all the power they will ever need and never cheap out to squeeze as much profit by lowering COGs). I would at minimum assume that some smart phones will be very smart and may attach to bigger networks (I hope with some type of prompt) and others will be less smart and built to provide bare minimum gateway functionality. Regards, Victor K > >:-) > >Russ > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From lorenzo@google.com Thu Oct 13 18:10:18 2011 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 5C42A21F8BBD for ; Thu, 13 Oct 2011 18:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2BWIsteCzXF for ; Thu, 13 Oct 2011 18:10:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8492D21F8BA0 for ; Thu, 13 Oct 2011 18:10:12 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p9E1A0Rs012693 for ; Thu, 13 Oct 2011 18:10:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318554601; bh=FtK9ueZ+gKIXyfE1gRgbIsR6Py0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=B/mHuNTaQACjlZgr/au5as2p4xPvB9mOIfxh+ZKFN+WcYFWctvXyd2dKNb3KBl9Q/ XtkxgmapDHJpATAlPhH/w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=JxzTdMq5dyA5Ccj9Y4TFms3kQPU4Qe3h6ex/66PAJQYyQt8HLxjIF5u33kvPWYe4F wlnAPTTSvFa7mx6zLXGtQ== Received: from ywm39 (ywm39.prod.google.com [10.192.13.39]) by wpaz24.hot.corp.google.com with ESMTP id p9E19s9V005725 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 13 Oct 2011 18:09:54 -0700 Received: by ywm39 with SMTP id 39so2663464ywm.2 for ; Thu, 13 Oct 2011 18:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=y06IH/E7z6JxT6/iJ8ocBFNDC4pVehmTTwPisUmmjuc=; b=NwwaIvt2r/C6TwHAcDKTAmXNIkVfThL5URVhYIwdhSPjsoSUk71UVm6hacYRirQvYl tdYOu6pbO2w29/XU5E7A== Received: by 10.150.206.6 with SMTP id d6mr6834295ybg.60.1318554594331; Thu, 13 Oct 2011 18:09:54 -0700 (PDT) Received: by 10.150.206.6 with SMTP id d6mr6834280ybg.60.1318554594142; Thu, 13 Oct 2011 18:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Thu, 13 Oct 2011 18:09:33 -0700 (PDT) In-Reply-To: <201110102116.p9ALGj83055597@gateway.ipv6.occnc.com> References: <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> <201110102116.p9ALGj83055597@gateway.ipv6.occnc.com> From: Lorenzo Colitti Date: Thu, 13 Oct 2011 18:09:33 -0700 Message-ID: To: curtis@occnc.com Content-Type: multipart/alternative; boundary=000e0cd404d0336da104af37eaac X-System-Of-Record: true Cc: Erik Nordmark , Acee Lindem , "homenet@ietf.org" , Jari Arkko , Fred Baker Subject: Re: [homenet] Thoughts about routing 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, 14 Oct 2011 01:10:18 -0000 --000e0cd404d0336da104af37eaac Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar wrote: > Random number selection for router-id and this sort of recovery would > solve the zero config OSPF issue related to router-id selection. > > Not yet solved in existing zospf draft (afaik) but solvable. zOSPF says what do do in the case of collisions if the router with duplicate ID is on the same link, but not if it is elsewhere. However, I think it can be made to work like this: 1. On startup, choose the router ID you had on last boot (if available) or a random number. 2. Start OSPF with this router ID. 3. If you see a hello packet from a neighbour with your own router ID, you have a collision on the local link. Change it and back off. 4. If you see a router LSA listing you as a neighbour, but the router ID that originated this LSA is not a neighbour of yours, you have a duplicate router ID. Change it and back off. Are there any cases this does not cover? As to what to do if there is a collision, I'm not sure. zOSPF says what you and your neighbours should do if the colliding router is on your link, but I don't know if that's enough if the colliding router is elsewhere. Any OSPF experts know the answer to this? --000e0cd404d0336da104af37eaac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar= <curtis@occnc.com> wrote:
Random number selection for router-id and this sort of recovery would
solve the zero config OSPF issue related to router-id selection.

Not yet solved in existing zospf draft (afaik) but solvable.

zOSPF says what do do in the case of collisions if the ro= uter with duplicate ID is on the same link, but not if it is elsewhere. How= ever, I think it can be made to work like this:

1. On startup, choose the router ID you had on last boo= t (if available) or a random number.
2. Start OSPF with this rout= er ID.
3. If you see a hello packet from a neighbour with your ow= n router ID, you have a collision on the local link. Change it and back off= .
4. If you see a router LSA listing you as a neighbour, but the router = ID that originated this LSA is not a neighbour of yours, you have a duplica= te router ID. Change it and back off.

Are there an= y cases this does not cover?

As to what to do if there is a collision, I'm not s= ure. zOSPF says what you and your neighbours should do if the colliding rou= ter is on your link, but I don't know if that's enough if the colli= ding router is elsewhere. Any OSPF experts know the answer to this?
--000e0cd404d0336da104af37eaac-- From lorenzo@google.com Thu Oct 13 18:13:50 2011 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 5C89521F8B38 for ; Thu, 13 Oct 2011 18:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id US+5MEEiNkVU for ; Thu, 13 Oct 2011 18:13:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4C21F86AA for ; Thu, 13 Oct 2011 18:13:49 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p9E1DSlI014353 for ; Thu, 13 Oct 2011 18:13:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318554816; bh=AzhE84SPWhp05UtaNNjyWlYcIkY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=SGbnWqHbiBJQBBcNjcTGgE1W0fa7APSepx+k0oFqLCqpLZby9WjzYfhY1Cskoo5Bp /eAy2OEgsh2ljcybGCdUg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=SOWaWWlRkPdAb5JpYEFUd+6W0pExb0hR6tEtoDgsGhZ3iXJYqCJIipNY/oxbbvTfX 84FRjFNW0V40q1eZf2TLA== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by hpaq2.eem.corp.google.com with ESMTP id p9E1BLZQ000461 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 13 Oct 2011 18:13:27 -0700 Received: by gyf1 with SMTP id 1so815560gyf.8 for ; Thu, 13 Oct 2011 18:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=JynFHDG03xyYVxJWySUsaJ5oTR6SaCg9rnIqgOXu9to=; b=FbTud5L8SKGWZ3AyK0/tmq5mD/bfDM2sBXHwWqtOH7NYzuxFSp3MGGYNDgrPazYT8b DWnJ3ucT9qhdTqbPj3tw== Received: by 10.151.38.20 with SMTP id q20mr1370647ybj.90.1318554807323; Thu, 13 Oct 2011 18:13:27 -0700 (PDT) Received: by 10.151.38.20 with SMTP id q20mr1370627ybj.90.1318554807115; Thu, 13 Oct 2011 18:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Thu, 13 Oct 2011 18:13:07 -0700 (PDT) In-Reply-To: References: <4E94BF91.4060807@cs.tcd.ie> <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> From: Lorenzo Colitti Date: Thu, 13 Oct 2011 18:13:07 -0700 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175707f0e521bf04af37f60d X-System-Of-Record: true Cc: Ole Troan , homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Fri, 14 Oct 2011 01:13:50 -0000 --0015175707f0e521bf04af37f60d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 12, 2011 at 05:33, Ted Lemon wrote: > The second reason is that electrical systems are essentially topology-free. > Any point on the system is essentially equivalent to any other. This is > not true of a home network with routing. What we are talking about is > essentially the possibility of rogue distribution panels intentionally or > accidentally being connected to your distribution system. > I'd say that electrical systems are as susceptible to rogue devices just as much as zeroconf routing systems are. If you plug a short into a socket, you trip a circuit breaker and you deny service to other appliances (i.e., "your house goes dark"). --0015175707f0e521bf04af37f60d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 12, 2011 at 05:33, Ted Lemon <mellon@fugue.com>= wrote:
The second = reason is that electrical systems are essentially topology-free. =A0 Any po= int on the system is essentially equivalent to any other. =A0 This is not t= rue of a home network with routing. =A0 What we are talking about is essent= ially the possibility of rogue distribution panels intentionally or acciden= tally being connected to your distribution system. =A0=A0

I'd say that electri= cal systems are as susceptible to rogue devices just as much as zeroconf ro= uting systems are. If you plug a short into a socket, you trip a circuit br= eaker and you deny service to other appliances (i.e., "your house goes= dark").
--0015175707f0e521bf04af37f60d-- From mellon@fugue.com Thu Oct 13 18:24:45 2011 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 6106F21F8BB1 for ; Thu, 13 Oct 2011 18:24:45 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5UGToOhFsul for ; Thu, 13 Oct 2011 18:24:45 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 052B421F8678 for ; Thu, 13 Oct 2011 18:24:45 -0700 (PDT) Received: from [10.0.1.8] (unknown [64.215.212.152]) by toccata.fugue.com (Postfix) with ESMTPSA id 4E79B2381795; Thu, 13 Oct 2011 21:24:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_52CF225B-4C1B-48BA-8E3A-EFFC8BB93013" From: Ted Lemon In-Reply-To: Date: Thu, 13 Oct 2011 21:24:42 -0400 Message-Id: References: <4E94BF91.4060807@cs.tcd.ie> <78CE7D95-48C9-4DE4-9707-F11AC2A051AC@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1251.1) Cc: Ole Troan , homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Fri, 14 Oct 2011 01:24:45 -0000 --Apple-Mail=_52CF225B-4C1B-48BA-8E3A-EFFC8BB93013 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 13, 2011, at 9:13 PM, Lorenzo Colitti wrote: > I'd say that electrical systems are as susceptible to rogue devices = just as much as zeroconf routing systems are. If you plug a short into a = socket, you trip a circuit breaker and you deny service to other = appliances (i.e., "your house goes dark"). This is true, but I think I hear the sound of shrieking as you torture = this poor analogy... :) --Apple-Mail=_52CF225B-4C1B-48BA-8E3A-EFFC8BB93013 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I'd say that = electrical systems are as susceptible to rogue devices just as much as = zeroconf routing systems are. If you plug a short into a socket, you = trip a circuit breaker and you deny service to other appliances (i.e., = "your house goes dark").
This is true, = but I think I hear the sound of shrieking as you torture this poor = analogy...   :)

= --Apple-Mail=_52CF225B-4C1B-48BA-8E3A-EFFC8BB93013-- From mcr@sandelman.ca Thu Oct 13 19:27:11 2011 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 87F9C21F8BF4 for ; Thu, 13 Oct 2011 19:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rAYbaRERR39 for ; Thu, 13 Oct 2011 19:27:10 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2F21F8AAF for ; Thu, 13 Oct 2011 19:27:10 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 9886134385; Thu, 13 Oct 2011 22:26:01 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 73F8498C90; Thu, 13 Oct 2011 22:27:58 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6D0D498B2E; Thu, 13 Oct 2011 22:27:58 -0400 (EDT) From: Michael Richardson To: curtis@occnc.com In-Reply-To: <201110132041.p9DKfrv4033626@gateway.ipv6.occnc.com> References: <201110132041.p9DKfrv4033626@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 13 Oct 2011 22:27:58 -0400 Message-ID: <17498.1318559278@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] time service and DNSSEC 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, 14 Oct 2011 02:27:11 -0000 >>>>> "Curtis" == Curtis Villamizar writes: Curtis> Neither KARP, as defined, or DNSSEC, are candidates for zero Curtis> configuration. If the user can configure KARP and DNSSEC Curtis> they are perfectly capable of using a backdoor, like ssh, to Curtis> set the time of day after a reboot that lost time-of-day. huh? DNSSEC just requires the . key be distributed in the router's firmware. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Thu Oct 13 19:42:20 2011 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 4189A21F8B8A for ; Thu, 13 Oct 2011 19:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbYSGny7xny0 for ; Thu, 13 Oct 2011 19:42:19 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D552F21F8B7E for ; Thu, 13 Oct 2011 19:42:19 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 44ACC343B2 for ; Thu, 13 Oct 2011 22:41:14 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id C919898C90; Thu, 13 Oct 2011 22:43:12 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C1F6A98B2E for ; Thu, 13 Oct 2011 22:43:12 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: References: <201110132030.p9DKUnG5033164@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 13 Oct 2011 22:43:12 -0400 Message-ID: <19594.1318560192@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Thoughts about routing 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, 14 Oct 2011 02:42:20 -0000 --=-=-= >>>>> "Joe" == Joe Touch writes: Joe> On Oct 13, 2011, at 1:30 PM, Curtis Villamizar Joe> wrote: >> I'm not fond of protocols that rely on time or monotonically >> increasing reboot counts and have no fallback. Joe> +1 Joe> Let's not add time as an attack vector. So, hypothetical attacks via DHCP, which require access to impersonate the DHCP or PPP server of the ISP are more important than getting a notion about time so you can prevent DNS attacks? Tet's talk about what other things you can do if you can hijack the network connection like that... and how many of them are resolved if DNSSEC can be used. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpehwICLcPvd0N1lAQICwQf9HTBPCXgMnyQvk0LIsdexFQvn+HkHwcPF 2kGbIFiiiIXFhXF3efRz0F21mjHy2dTGfNHpfdR1d29C1bEA5klhjkH14zOHnIXg 5cZfmEB2N7NQLLgVZ/KLsnKLM46O/UOYkQz1w1xSEv3g9r1xoZ3SNUzVLW3ZgQ+i dk2RnjyB8Wxe7dGbFmVVk2QJt4SgBuDyfNbXJnoqO5xHdjVgpHKTakjTJt4rxFlt i65JELNqemoG266tDWQqk6YYteCsnxb3ETT8LNTHOoqq43jVG+wJRKH17WH7NShd OZyXrmrV0blaTX0QSFLFXn3gytCkybxfJZnkkOIX5SEEkh8LSw8XNA== =dpRK -----END PGP SIGNATURE----- --=-=-=-- From curtis@occnc.com Thu Oct 13 20:28:20 2011 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 9F54321F8C0D for ; Thu, 13 Oct 2011 20:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79fpJnzuGaL5 for ; Thu, 13 Oct 2011 20:28:20 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 43CCC21F8BF4 for ; Thu, 13 Oct 2011 20:28:13 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9E3SA17046093; Thu, 13 Oct 2011 20:28:10 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9E3SA17046093 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318562890; bh=6zP0AEgbcUs2V4hCrGW7gpmlSunjZ1D4tW61UKW8qZU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=bO2spNw4H7JdulH7dIrx3m5Ci5fdJ+d5kR0Nql957Z405Cl29qWzKmZKrfBlaBUHA EKNcozY7k04RsbirWV3GH3gDdr5PQ7/nSnyisHkrorTbExtiTgkuod3ON9+efW9LH2 ETAELW0eqn2RHp6RW/mRmr9dn+UPO15QAkGg01hE= Message-Id: <201110140328.p9E3SA17046093@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Oct 2011 22:27:58 EDT." <17498.1318559278@marajade.sandelman.ca> Date: Thu, 13 Oct 2011 20:28:09 -0700 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] time service and DNSSEC X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 03:28:20 -0000 In message <17498.1318559278@marajade.sandelman.ca> Michael Richardson writes: > > >>>>> "Curtis" == Curtis Villamizar writes: > Curtis> Neither KARP, as defined, or DNSSEC, are candidates for zero > Curtis> configuration. If the user can configure KARP and DNSSEC > Curtis> they are perfectly capable of using a backdoor, like ssh, to > Curtis> set the time of day after a reboot that lost time-of-day. > > huh? > DNSSEC just requires the . key be distributed in the router's firmware. duh. I'm thinking about acting as a NS and signing the zone. Never mind. For DNSSEC resolver no configuration is needed. For that purpose getting time of day through NTP or even timed (not suggesting timed) would be fine. Curtis From acee.lindem@ericsson.com Fri Oct 14 09:45:32 2011 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 16A7421F8C74 for ; Fri, 14 Oct 2011 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPai9DeK-9GI for ; Fri, 14 Oct 2011 09:45:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 95A3721F8C6B for ; Fri, 14 Oct 2011 09:45:31 -0700 (PDT) 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 p9EGjGti008171; Fri, 14 Oct 2011 11:45:17 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 14 Oct 2011 12:45:14 -0400 From: Acee Lindem To: Lorenzo Colitti Date: Fri, 14 Oct 2011 12:45:12 -0400 Thread-Topic: [homenet] Thoughts about routing Thread-Index: AcyKkKUxSC+EJyN8SpWmQtaaCVHLLQ== Message-ID: <69B39036-B982-46E2-A444-FC1A4141F416@ericsson.com> References: <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> <201110102116.p9ALGj83055597@gateway.ipv6.occnc.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: Erik Nordmark , "homenet@ietf.org" , Jari Arkko , Fred Baker , "curtis@occnc.com" Subject: Re: [homenet] Thoughts about routing 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, 14 Oct 2011 16:45:32 -0000 On Oct 13, 2011, at 9:09 PM, Lorenzo Colitti wrote: On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar > wrote: Random number selection for router-id and this sort of recovery would solve the zero config OSPF issue related to router-id selection. Not yet solved in existing zospf draft (afaik) but solvable. zOSPF says what do do in the case of collisions if the router with duplicat= e ID is on the same link, but not if it is elsewhere. However, I think it c= an be made to work like this: 1. On startup, choose the router ID you had on last boot (if available) or = a random number. 2. Start OSPF with this router ID. 3. If you see a hello packet from a neighbour with your own router ID, you = have a collision on the local link. Change it and back off. 4. If you see a router LSA listing you as a neighbour, but the router ID th= at originated this LSA is not a neighbour of yours, you have a duplicate ro= uter ID. Change it and back off. Are there any cases this does not cover? As to what to do if there is a collision, I'm not sure. zOSPF says what you= and your neighbours should do if the colliding router is on your link, but= I don't know if that's enough if the colliding router is elsewhere. Any OS= PF experts know the answer to this? A new OSPFv3 mechanism is required in support of this. Today, any LSA recei= ved with the OSPFv3 router's Router-ID is considered to be a stale self-ori= ginated LSA. Thanks, Acee From fred@cisco.com Fri Oct 14 09:48:31 2011 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 40FB321F8CB4 for ; Fri, 14 Oct 2011 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.539 X-Spam-Level: X-Spam-Status: No, score=-104.539 tagged_above=-999 required=5 tests=[AWL=2.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7T7BL+Xc10k for ; Fri, 14 Oct 2011 09:48:30 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 91FEE21F8CB2 for ; Fri, 14 Oct 2011 09:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3087; q=dns/txt; s=iport; t=1318610908; x=1319820508; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Sit2fkGPFMlScCOl3lrJ6CD1sdNZEJ0mmjU+SLyXdFA=; b=Rn7s02GmNr9UnGytLtN+ZyDWw11Oo0TVdQYOrSSgEGlWOCzjsb43LfgO 5ipKoIAlElqa8/Kq7/1dGolivls3x6dzkTOcyzDI18oXAoe3UEieGrP9X 3h6+0t5wHWwkEc1WWHcSPi8Jb7Q5KRq82LLD0FKGJ3U5t+fqHhN5PNLVd s=; X-IronPort-AV: E=Sophos;i="4.69,347,1315180800"; d="scan'208";a="7943341" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 14 Oct 2011 16:48:10 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9EGm9HB002720; Fri, 14 Oct 2011 16:48:09 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 14 Oct 2011 09:48:10 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 14 Oct 2011 09:48:10 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 14 Oct 2011 09:48:00 -0700 Message-Id: <0651F29F-C816-4A23-BD6F-C791CE89BB11@cisco.com> References: <635C3A25-7265-402D-A708-3A07B08EF51B@cisco.com> <201110102116.p9ALGj83055597@gateway.ipv6.occnc.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , Acee Lindem , Jari Arkko , "homenet@ietf.org" , curtis@occnc.com Subject: Re: [homenet] Thoughts about routing 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, 14 Oct 2011 16:48:31 -0000 On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote: > On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar = wrote: > Random number selection for router-id and this sort of recovery would > solve the zero config OSPF issue related to router-id selection. >=20 > Not yet solved in existing zospf draft (afaik) but solvable. >=20 > zOSPF says what do do in the case of collisions if the router with = duplicate ID is on the same link, but not if it is elsewhere. However, I = think it can be made to work like this: >=20 > 1. On startup, choose the router ID you had on last boot (if = available) or a random number. > 2. Start OSPF with this router ID. > 3. If you see a hello packet from a neighbour with your own router ID, = you have a collision on the local link. Change it and back off. > 4. If you see a router LSA listing you as a neighbour, but the router = ID that originated this LSA is not a neighbour of yours, you have a = duplicate router ID. Change it and back off. >=20 > Are there any cases this does not cover? On number 3, there is a race condition. If the router took some time to = boot, this takes care of itself; if this is a flash restart (OSPF = started up within one or two HELLO intervals of going down) there is = some possibility that the neighbor simply has some old state. Note that = the OSPF Spec has the router initially send a HELLO and then start = looking for HELLOs from peers that announce it; it would be good for = OSPF to instead wait for one HELLO interval so that it sees the HELLOs = from other routers on the LAN before announcing itself if it's not sure = about the uniqueness of its RID. On number 4, that would be a Router LSA or Network LSA; in a LAN subnet, = the RIDs of the routers in the subnet are in the Network LSA. > As to what to do if there is a collision, I'm not sure. zOSPF says = what you and your neighbours should do if the colliding router is on = your link, but I don't know if that's enough if the colliding router is = elsewhere. Any OSPF experts know the answer to this? What the router needs to do is=20 (1) NOT send an LSA using the RID into the LS database, as this will = confuse everyone else=20 (2) it would be good etiquette to announce one more HELLO in which it = lists no neighbors so that all of its neighbors, and especially the DR, = think it's going down. That way it doesn't get into the Network LSA, or = if it already did, it will be removed. (3) It has to change its RID and start from the beginning. The good news is that it now has some subset of the LSA Database, so the = second exchange will be somewhat quicker, and it already knows who the = DR is in at least that subnet. "Random number" is a good description of the source for the RID. MAC = Addresses and equipment serial numbers tend to be reasonable seeds, and = a router will usually have more than one such. If it used one MAC = address and that didn't play, it might try another. If push comes to = shove, a call to random() is probably in order.= From curtis@occnc.com Sat Oct 15 18:35:27 2011 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 48E9321F851A for ; Sat, 15 Oct 2011 18:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6NBI0HJuhCe for ; Sat, 15 Oct 2011 18:35:26 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3521F8515 for ; Sat, 15 Oct 2011 18:35:25 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9G1Z8S8023584; Sat, 15 Oct 2011 18:35:08 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9G1Z8S8023584 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318728911; bh=SI6J4MrYiQ6LiVO0E2/JGILN+1eN3G1BR0sKrIfxqPw=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=ZNWr3C4YvGBvTi0UPdRx7donwbXshuGNVLACg7yHsmmhRkbC/REbbs7fT+XU0Uoj6 z2TL97D/7jtYT69rwJyFivVPQBTDJc5wIzMRTICA4eKpsm1bheAnZLf5Pmd02vbVqJ RTa27dN42/k5CyZLUo/eM+MzPI06rsJ9bre1mMMk= Message-Id: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> To: Fred Baker From: Curtis Villamizar In-reply-to: Your message of "Fri, 14 Oct 2011 09:48:00 PDT." <0651F29F-C816-4A23-BD6F-C791CE89BB11@cisco.com> Date: Sat, 15 Oct 2011 18:35:08 -0700 Cc: Erik Nordmark , curtis@occnc.com, Acee Lindem , Jari Arkko , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 01:35:27 -0000 In message <0651F29F-C816-4A23-BD6F-C791CE89BB11@cisco.com> Fred Baker writes: > > On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote: > > > On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar wrote: > > Random number selection for router-id and this sort of recovery would > > solve the zero config OSPF issue related to router-id selection. > > > > Not yet solved in existing zospf draft (afaik) but solvable. > > > > zOSPF says what do do in the case of collisions if the router with > > duplicate ID is on the same link, but not if it is > > elsewhere. However, I think it can be made to work like this: > > > > 1. On startup, choose the router ID you had on last boot (if > > available) or a random number. > > 2. Start OSPF with this router ID. > > 3. If you see a hello packet from a neighbour with your own router > > ID, you have a collision on the local link. Change it and back off. > > 4. If you see a router LSA listing you as a neighbour, but the > > router ID that originated this LSA is not a neighbour of yours, you > > have a duplicate router ID. Change it and back off. > > > > Are there any cases this does not cover? > > On number 3, there is a race condition. If the router took some time > to boot, this takes care of itself; if this is a flash restart (OSPF > started up within one or two HELLO intervals of going down) there is > some possibility that the neighbor simply has some old state. Note > that the OSPF Spec has the router initially send a HELLO and then > start looking for HELLOs from peers that announce it; it would be good > for OSPF to instead wait for one HELLO interval so that it sees the > HELLOs from other routers on the LAN before announcing itself if it's > not sure about the uniqueness of its RID. > > On number 4, that would be a Router LSA or Network LSA; in a LAN > subnet, the RIDs of the routers in the subnet are in the Network LSA. An ISIS LSPDU fragment is *really big*. To avoid having to check the whole thing to see if it changed, ISIS routers checksum relevant parts of the LSPDU and compare to the checksum to the prior advertisements. That is how they tell if they might have a new LSPDU fragement and might have to reflood it and update the LSDB. Brute force compare works too but just takes a lot longer. OSPF LSA are smaller but more numerous, but there is no reason that the LSA can't be checksumed. Any OSPF router should know what LSA it originated. If an LSA doesn't resemble anything it originated, pick another router-id. If it was a stale LSA, it does no long term harm to pick a new LSA after a reboot. Every LSA has "Advertising Router" starting at byte 8 for both OSPFv2 or OSPFv3. The packet formats are in Appendix A in both rfc2328 and rfc5340. If "Advertising Router" equals "me" and this LSA looks bogus, there is likely to be a router-id collision. Or it could be a stale LSA from a fast reboot, but so what, just pick another router-id and start over. > > As to what to do if there is a collision, I'm not sure. zOSPF says > > what you and your neighbours should do if the colliding router is on > > your link, but I don't know if that's enough if the colliding router > > is elsewhere. Any OSPF experts know the answer to this? > > What the router needs to do is > > (1) NOT send an LSA using the RID into the LS database, as this will > confuse everyone else > (2) it would be good etiquette to announce one more HELLO in which it > lists no neighbors so that all of its neighbors, and especially the > DR, think it's going down. That way it doesn't get into the Network > LSA, or if it already did, it will be removed. > (3) It has to change its RID and start from the beginning. All adjacencies have to go down to change router-id. The other end of the adjacency will withdraw its side of the adjacency. If the other user of the router-id is not adjacent, the problem will be discovered after the initial hello handshake and during the database exchange, but it should occur before the first adjacency is completely up. The adjacency isn't up until the database exchange is complete. Any LSA that were advertised will be seen as stale by the former user of that router-id. They will be withdrawn. > The good news is that it now has some subset of the LSA Database, so > the second exchange will be somewhat quicker, and it already knows who > the DR is in at least that subnet. > > "Random number" is a good description of the source for the RID. MAC > Addresses and equipment serial numbers tend to be reasonable seeds, > and a router will usually have more than one such. If it used one MAC > address and that didn't play, it might try another. If push comes to > shove, a call to random() is probably in order. Did anyone read my prior email in which I cited the RFCs and section numbers and quoted the relevant text? If not, look for: Message-Id: <201110131811.p9DIBE9i021327@gateway.ipv6.occnc.com> To: Acee Lindem cc: "curtis@occnc.com" , Russ White , "homenet@ietf.org" Reply-To: curtis@occnc.com From: Curtis Villamizar Subject: Re: [homenet] Thoughts about routing In-reply-to: Your message of "Thu, 13 Oct 2011 05:55:07 EDT." <1E8BBE2E-357A-4681-BB84-4E694AFD9B1C@ericsson.com> Date: Thu, 13 Oct 2011 11:11:14 -0700 We should probably pick up this thread from that message (which had relevant detail, but no one replied to it). Curtis From fred@cisco.com Sat Oct 15 21:27:59 2011 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 2E92C21F84DC for ; Sat, 15 Oct 2011 21:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.985 X-Spam-Level: X-Spam-Status: No, score=-104.985 tagged_above=-999 required=5 tests=[AWL=1.614, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqUpx-wbfstZ for ; Sat, 15 Oct 2011 21:27:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A80C421F84DB for ; Sat, 15 Oct 2011 21:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=303; q=dns/txt; s=iport; t=1318739278; x=1319948878; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+Ne9NJJXV9CvV6a3ssAP48blooNQw1jABbbi8DOzqEk=; b=GWOS0kRWdKl5l5UTZMzlimwk5pDeOcdBeBIG5sEXEWcCbaqEewzo54/u yN8u+Kf2aSFJNCY+EKaSWdaZyvhGiJYE2cHqfJvvX34V7XAUlIJq5kfhq JiZdYYik3ESuUD6CBcDFm3maUg+1H/zXolyU6LLxqqH32bm5cUL5cZg8X E=; X-IronPort-AV: E=Sophos;i="4.69,352,1315180800"; d="scan'208";a="8149254" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 Oct 2011 04:27:58 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9G4Rwvo001135; Sun, 16 Oct 2011 04:27:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> Date: Sat, 15 Oct 2011 21:27:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1084) Cc: Erik Nordmark , "homenet@ietf.org" , Jari Arkko , Acee Lindem , Lorenzo Colitti Subject: Re: [homenet] Thoughts about routing 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, 16 Oct 2011 04:27:59 -0000 On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote: > All adjacencies have to go down to change router-id. The other end of > the adjacency will withdraw its side of the adjacency. well, yes, and if I change my routerid, all adjacencies will go down. = Not sure what the point here is...= From robert@raszuk.net Sat Oct 15 22:06:36 2011 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 9547F21F84DF for ; Sat, 15 Oct 2011 22:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g8IjSSPFckW for ; Sat, 15 Oct 2011 22:06:36 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id C0C4721F84DB for ; Sat, 15 Oct 2011 22:06:35 -0700 (PDT) Received: (qmail 24209 invoked by uid 399); 16 Oct 2011 05:06:34 -0000 Received: from unknown (HELO ?10.0.1.3?) (216.31.254.135) by mail37.opentransfer.com with SMTP; 16 Oct 2011 05:06:34 -0000 Message-ID: <4E9A6657.70705@raszuk.net> Date: Sun, 16 Oct 2011 07:06:31 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Fred Baker References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Erik Nordmark , curtis@occnc.com, Acee Lindem , Jari Arkko , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 05:06:36 -0000 Hi Fred, I think the point is that in your algorithm you stated this step: > (3) It has to change its RID and start from the beginning. I would say (perhaps in line with Curtis comment) that this step is unrealistic. RID for many reasons (for example mpls-te) is hard configured in link state IGPs. Worse - some vendors - do base on this their very cool hack to forward v6 traffic over v4 TE LSPs. So I think statement that router has to change it's RID is operationally non starter. Cheers, R. > On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote: > >> All adjacencies have to go down to change router-id. The other end of >> the adjacency will withdraw its side of the adjacency. > > well, yes, and if I change my routerid, all adjacencies will go down. Not sure what the point here is... > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > From dave.taht@gmail.com Sun Oct 16 00:47:52 2011 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 2DB3921F8562 for ; Sun, 16 Oct 2011 00:47:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf0zoAE9GRZl for ; Sun, 16 Oct 2011 00:47:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 011CC21F8560 for ; Sun, 16 Oct 2011 00:47:50 -0700 (PDT) Received: by wwe6 with SMTP id 6so492071wwe.13 for ; Sun, 16 Oct 2011 00:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=4aS2SGTzMjLz9n9GRcm3aih/4nXUrmK+bH1HLyPVCTw=; b=QYFVqTE5kP3qvab7a9XlzMUvNSzYCmsVhy9idLn3+WpZhyTpVGJ3elUtYSJUJ2Srrm 9tK1c28ZviagTXkVvNYj1eQvLUK9wiWp30UwC04eGLbPaypOlYiNJBdOtxToaM2LsFqZ uYpkavc5Ksz46u2ChnxXxQiJDjTrVtIjKqI1U= Received: by 10.216.55.210 with SMTP id k60mr4998502wec.61.1318751269904; Sun, 16 Oct 2011 00:47:49 -0700 (PDT) Received: from [10.192.168.28] (LNeuilly-152-23-2-89.w193-252.abo.wanadoo.fr. [193.252.33.89]) by mx.google.com with ESMTPS id j18sm23977775wbo.6.2011.10.16.00.47.43 (version=SSLv3 cipher=OTHER); Sun, 16 Oct 2011 00:47:48 -0700 (PDT) Message-ID: <4E9A8C15.2030605@gmail.com> Date: Sun, 16 Oct 2011 09:47:33 +0200 From: =?ISO-8859-1?Q?David_T=E4ht?= Organization: Bufferbloat.net User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: homenet@ietf.org References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> In-Reply-To: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> Content-Type: multipart/mixed; boundary="------------060006090708000009080205" Subject: Re: [homenet] Thoughts about routing 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, 16 Oct 2011 07:47:52 -0000 This is a multi-part message in MIME format. --------------060006090708000009080205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 10/16/2011 03:35 AM, Curtis Villamizar wrote: > In message <0651F29F-C816-4A23-BD6F-C791CE89BB11@cisco.com> > Fred Baker writes: > >> >> On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote: >> >>> On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar wrote: >>> Random number selection for router-id and this sort of recovery would >>> solve the zero config OSPF issue related to router-id selection. >>> >>> Not yet solved in existing zospf draft (afaik) but solvable. Just as a data point, the babel and AHCP protocols creates a router-id from a EUI-64. problem solved, there. -- Dave Täht --------------060006090708000009080205 Content-Type: text/x-vcard; charset=utf-8; name="dave_taht.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dave_taht.vcf" begin:vcard fn;quoted-printable:Dave T=C3=A4ht n;quoted-printable:T=C3=A4ht;Dave email;internet:dave.taht@gmail.com tel;home:1-239-829-5608 tel;cell:0638645374 x-mozilla-html:FALSE version:2.1 end:vcard --------------060006090708000009080205-- From dave.taht@gmail.com Sun Oct 16 03:47:52 2011 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 1ED1521F8A69 for ; Sun, 16 Oct 2011 03:47:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4NtV+dGWpnu for ; Sun, 16 Oct 2011 03:47:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F37921F87FC for ; Sun, 16 Oct 2011 03:47:49 -0700 (PDT) Received: by wwe6 with SMTP id 6so557768wwe.13 for ; Sun, 16 Oct 2011 03:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=EB9ig1TzzIjsiLAsjJ2wy9NjzyVmpac7P9iSbyVRX28=; b=F5jZiugY7eAASoiyjxRxx3XiqEa6ZlMopdKnq9kg8mr8VVxMdCvybRT/LGnDwYuqEu Kq+hmLvPmDDqwa6hzSmg3XwU9g0l+LgsmpcXOPLxFleItZP3qZkuJsPTnaHW/kquOxS/ i2YZzgibEWz+jT/XXfF9CBUjQzmlPeRUDVaRg= Received: by 10.227.2.69 with SMTP id 5mr5601352wbi.16.1318762064949; Sun, 16 Oct 2011 03:47:44 -0700 (PDT) Received: from [10.192.168.28] (LNeuilly-152-23-2-89.w193-252.abo.wanadoo.fr. [193.252.33.89]) by mx.google.com with ESMTPS id fo7sm24646583wbb.20.2011.10.16.03.47.40 (version=SSLv3 cipher=OTHER); Sun, 16 Oct 2011 03:47:44 -0700 (PDT) Message-ID: <4E9AB641.7050201@gmail.com> Date: Sun, 16 Oct 2011 12:47:29 +0200 From: =?ISO-8859-1?Q?David_T=E4ht?= Organization: Bufferbloat.net User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: homenet@ietf.org References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> In-Reply-To: <4E9A8C15.2030605@gmail.com> Content-Type: multipart/mixed; boundary="------------050009040004050609020909" Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 16 Oct 2011 10:47:52 -0000 This is a multi-part message in MIME format. --------------050009040004050609020909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In reviewing this enormous thread it appears to have got off-track again, discussing esoterica of various routing protocols and not focused on the big picture. There's been too many comments for me to comment individually on the messages. However, overall trends on this list are discouraging. 1) Getting IPv6 working well inside the home is a hard problem! It helps to actually try to make something work, to see the relevant details. I'd like it very much if at an upcomin I've built 3 such networks, and am in the process of building several more - as well as making available code on a cheap, 120 dollar, platform to make it possible to actually go and set one up yourself to play with, so the more devilish, detailed problems become apparent. I've done my best to make sure 6to4, at least, works right out of the box. Native (no PD yet!) works pretty well, too - but getting the 6to4/ipv6 native to co-exist better is going to take slightly more work. http://www.bufferbloat.net/projects/cerowrt/wiki/OCEAN_CITY_INSTALLATION_GUIDE There's babel, batman, rip, radvd, ospf, ospfv6, is-is, and bgp all available. Go play. I'd like it very much if at an upcoming meeting or event someone or someones were to demonstrate working code... 2) Now, in reviewing this thread, I was disappointed to see that my ipv6 routing protocol of choice (babel) has not been discussed so far to any extent. While this protocol is somewhat new, an rfc and working code both exist, and working code has existed for several years. http://tools.ietf.org/html/rfc6126 http://www.pps.jussieu.fr/~jch/software/babel/ Of late there has been a great deal of work on creating a metric that does diversity routing - accounting for the differences in performance between contested wireless channels and ethernet to some extent. It seems to me that that babel has got lumped in a mental catagory of 'mesh networking protocol' - which it is - but it is better described as 'rip on speed' as it works across normal wired, wireless, AND mesh networks - something no other routing protocol does well (IMHO!). Things like 802.11s are targetted at wireless only. The future inside the home is mostly wireless, not wired... and as many of the assumptions built into ipv6, dhcp, dhcpv6, ra announcements, etc completely predate the rise of wireless everywhere, they tend to be, well... wrong. Here are the current routing tables from bloatlab #1 http://www.bufferbloat.net/projects/cerowrt/wiki/BloatLab_1 http://www.teklibre.com/~d/labroutes/ I am using CIDR networks (/27 netmasks) on the ipv4 side to reduce the broadcast/multicast problem that wireless-n has, and a variety of IP address distribution mechanisms on the ipv6 side - autoconfig/ra and ahcp. Some notes: 0) It took me multiple years of fiddling with the ipv6 routing protocols available to settle on babel. Babel is definitely not finished or perfect, but thankfully it has a pluggable metric. 1) Babel treats IPv6 as a first class object - ipv4 and ipv6 routes are distributed in the same message - and within the same daemon and configuration files. I had used olsr in an earlier attempt at convincing ipv6 to work well on a previously pure ipv4 - the size of the 2 daemons required, the doubling of packets sent, and the complexity of the conf files all deterred me. 2) Setup is devestatingly simple compared to any other routing protocol I've tried. For example, it uses a EUI-64 equivalent as a router-id, no setup required. Now I actually use, in the home, a setup that dumps dhcp, dhcpv6, and ra entirely, replacing them with a combination of AHCP and babel - AHCP also distributes ipv4 and ipv6 in the same message, and also (when done right) gives the ability to transparently move between wired and multiple wireless links without dropping connections. Stepping back into what others think as the real world... in the office - is often a shock - I unplug and... "oh damn, I just lost 20+ windows and the movie I was streaming..." where that *doesn't happen* when using the above two protocols at home.... AHCP uses /128 netmasks which makes subnetting a single ipv6/64 allocation a breeze. I can think of a few more compelling advantages for considering new ideas such as these protocols inside the home, but this is almost enough for today. I'll talk to the more generic problems with prefix based routing in a mixed 6to4 and native scenario, the dns naming problem, and the ip address expiry problem some other day... but you can see those for yourself with a little investment of time and hardware in trying to actually make something - anything! - actually work. -- Dave Täht --------------050009040004050609020909 Content-Type: text/x-vcard; charset=utf-8; name="dave_taht.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dave_taht.vcf" begin:vcard fn;quoted-printable:Dave T=C3=A4ht n;quoted-printable:T=C3=A4ht;Dave email;internet:dave.taht@gmail.com tel;home:1-239-829-5608 tel;cell:0638645374 x-mozilla-html:FALSE version:2.1 end:vcard --------------050009040004050609020909-- From dave.taht@gmail.com Sun Oct 16 04:34:49 2011 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 5448821F8A69 for ; Sun, 16 Oct 2011 04:34:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVSUsg-xtKcq for ; Sun, 16 Oct 2011 04:34:48 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB321F8713 for ; Sun, 16 Oct 2011 04:34:47 -0700 (PDT) Received: by wwe6 with SMTP id 6so575158wwe.13 for ; Sun, 16 Oct 2011 04:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type; bh=SR4F3L6/QgAH5hZoubp3zzfUPoLeBlOIJN+NOYk4/ig=; b=qt4QMKAJP7VnT3HsNfRuXmOkOJhnUxXWrnzgd0H/EFSbZ85Ldn42oxwqUWpdvnmuaS 83Lt0zmFT0EOyxmrHspUnJEocFsN/OTNNPpuXXf+1X8M3WA4MY/Omo1kJRfMSnjZLZSp 45Q0nE0QonuNSirXYYGxS6ddtLEWJMb6zY7l0= Received: by 10.227.170.68 with SMTP id c4mr3096224wbz.62.1318764887099; Sun, 16 Oct 2011 04:34:47 -0700 (PDT) Received: from [10.192.168.28] (LNeuilly-152-23-2-89.w193-252.abo.wanadoo.fr. [193.252.33.89]) by mx.google.com with ESMTPS id z9sm24851577wbn.19.2011.10.16.04.34.31 (version=SSLv3 cipher=OTHER); Sun, 16 Oct 2011 04:34:46 -0700 (PDT) Message-ID: <4E9AC13F.6070107@gmail.com> Date: Sun, 16 Oct 2011 13:34:23 +0200 From: =?ISO-8859-1?Q?David_T=E4ht?= Organization: Bufferbloat.net User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: homenet@ietf.org, each@isc.org Content-Type: multipart/mixed; boundary="------------080300000000040502050605" Subject: [homenet] time service and DNSSEC (code) 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, 16 Oct 2011 11:34:49 -0000 This is a multi-part message in MIME format. --------------080300000000040502050605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In message <17165.1318514742 at marajade.sandelman.ca> Michael Richardson writes: > >>>>> "Curtis" == Curtis Villamizar writes: > >> While talking about hardware. These these devices all need a > >> battery backed clock or all the crypto will be broken. > > > Curtis> Having a clock is not hard but I don't think your statement > Curtis> is true. > > Curtis> Some crypto does not require time, but rather just entropy > Curtis> (a nonce or challenge). For crypto that does require time > Curtis> the former can be a bootstrap of sorts, possibly to get ntp > Curtis> going if very accurate time is needed (for some reason). > > Curtis, Mark, as a DNSSEC implementer knows of what he speaks. DNSSEC > requires time. Not to the second or even minute, but at least hour. > > DNSSEC is a core protocol at this point, and we need to be aware of > it. It doesn't matter today, because we have a broken home DNS > system, but that's within homenet to fix. > > Bootstrapping time enough to get DNSSEC to work is important. A version of the scripts evan created to generate valid DNS entries for IPv6 views is in the dhcp-next package in the ceropackages repository https://github.com/dtaht/ceropackages which leverages isc-dhcp's scripting abilities: https://github.com/dtaht/ceropackages/blob/master/net/bind-dhcp-hooks/files/etc/ddns6.sh I note that we did do another innovative thing here. By using a DHCPv4 server and constructing a working EUI-64 from the known prefix and mac address we were able to insert valid ipv6 entries into the DNS that matched the naming scheme of the ipv4 client. more work is required to generalize this solution, as evan's setup did not use subdomains for the dns views, nor have I got around to making a script like this work well for a dnsmasq hook, rather than isc-dhcp hook. (isc-dhcp is presently rather too large for a home router, so we use dnsmasq in cerowrt) I note: we did this hack over a weekend. as for bootstrapping DNSSEC with invalid time... bufferbloat.net and the main router for the lab (jupiter.lab.bufferbloat.net) are also generating DNSSEC signed DNS.Yes, it's a home router, and I do find it comforting to see DNSSEC working in various places with tools in my browser such as the firefox dnssec plugin. Cerowrt is currently shipping with DNSSEC enabled, and the 'get time to within an hour problem' is currently handled with a very hacky script that disables DNSSEC until valid time is acquired. More elegant solutions are outlined on: http://www.bufferbloat.net/issues/113 http://www.bufferbloat.net/issues/205 and also discussed on the bloat list: https://lists.bufferbloat.net/pipermail/bloat-devel/2011-July/000206.html I think the consensus there for DNSSEC is the 'right thing to do' - for all devices, not just home gateways - is to add a flag to c libraries to getaddrinfo and friends to ask it to not validate the results, and have ntp (and related tools such as rdate) - try this when first attempting to slew the time. It's an awful large amount of work to get this single bit used correctly throughout the c stack, but it seems like the right thing. it is mildly easier to link the dnsval library for apps that need to be slightly more dnssec aware - but... I've been too absorbed by beating bufferbloat to tackle this one too, but no matter the approach, having dnssec work mo better everywhere looks quite feasible, and would benefit from someone actually attempting the work. -- Dave Täht --------------080300000000040502050605 Content-Type: text/x-vcard; charset=utf-8; name="dave_taht.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dave_taht.vcf" begin:vcard fn;quoted-printable:Dave T=C3=A4ht n;quoted-printable:T=C3=A4ht;Dave email;internet:dave.taht@gmail.com tel;home:1-239-829-5608 tel;cell:0638645374 x-mozilla-html:FALSE version:2.1 end:vcard --------------080300000000040502050605-- From fred@cisco.com Sun Oct 16 17:36:48 2011 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 5D7B521F8783 for ; Sun, 16 Oct 2011 17:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.032 X-Spam-Level: X-Spam-Status: No, score=-105.032 tagged_above=-999 required=5 tests=[AWL=1.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi0Dm8Osz6f5 for ; Sun, 16 Oct 2011 17:36:47 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CCC1821F8770 for ; Sun, 16 Oct 2011 17:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1404; q=dns/txt; s=iport; t=1318811807; x=1320021407; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WqG1S2/LGiKlze3uSY/z46RD1iy15NNW2hle3kpo+Lg=; b=lbQaaUhpoJcmaF+pbWjdcBnrSLPhiO7ZIllmnxTHmlBljzbWhTI7EuB3 kVa3NifC8kReLmZw3xzronpMrtWpCHVoFyIOOqRjqcOgQWNABT9m649/T PLMulChZga2fZTjk7lIVOg4jTFjEraS5A/Bb3UHNuobYfIvFm/f7Iieq9 I=; X-IronPort-AV: E=Sophos;i="4.69,355,1315180800"; d="scan'208";a="8201904" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Oct 2011 00:36:47 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9H0al24000766; Mon, 17 Oct 2011 00:36:47 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4E9A6657.70705@raszuk.net> Date: Sun, 16 Oct 2011 17:36:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C1398A9-2E34-458E-9922-8157AD95991B@cisco.com> References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A6657.70705@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) Cc: Erik Nordmark , curtis@occnc.com, Acee Lindem , Jari Arkko , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Thoughts about routing 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, 17 Oct 2011 00:36:48 -0000 On Oct 15, 2011, at 10:06 PM, Robert Raszuk wrote: > RID for many reasons (for example mpls-te) is hard configured in link = state IGPs. >=20 > Worse - some vendors - do base on this their very cool hack to forward = v6 traffic over v4 TE LSPs. We appear to have a fundamental "you're on a misconfigured wavelength" = problem. How many routers do you find using traffic-engineered MPLS LSPs = within people's homes? How much do you find "hard configured" in a "zero = configuration" environment? Earth to Robert... > So I think statement that router has to change it's RID is = operationally non starter. If the router, operating in a zero configuration environment and = concocting its RID from some form of random process starting from an = equipment differentiable seed, finds that its RID duplicates another = router's RID, it has three choices. It can - not change it and screw up the network, which creates an unhappy = customer and probably blows the entire margin in the router on a = customer support call.=20 - not change it and effectively brick itself, which creates an unhappy = customer and probably blows the entire margin in the router on a = customer support call.=20 - change the router id, making the network work as the customer = expects, resulting in a happy customer and the margin staying in the = vendor's pocket.=20 Pick one.= From lorenzo@google.com Sun Oct 16 19:44:54 2011 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 72FE111E8073 for ; Sun, 16 Oct 2011 19:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.896 X-Spam-Level: X-Spam-Status: No, score=-104.896 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6radRK9V61p for ; Sun, 16 Oct 2011 19:44:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D511E8080 for ; Sun, 16 Oct 2011 19:44:53 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p9H2iqF0030403 for ; Sun, 16 Oct 2011 19:44:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318819492; bh=TWrZMcUc1YwCK49705akNLFW6hw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mGj9azsUtdgQhvIt7czgOd6TyYCFZJ88XWEr+Z7QdjS5at73SpaSoLZziGjv8Jvhw okdJ9ISjhbv8IZBLg9aiw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=QloW1OrBKr7NY1spzYD0G/lKuyvwzCw83hKhNbct96FHYprEho+1EO9xWlVjrrq0G smlhR7k+Rg5CnK9u+Dnyg== Received: from vcbfk14 (vcbfk14.prod.google.com [10.220.204.14]) by wpaz33.hot.corp.google.com with ESMTP id p9H2f2Wx029527 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 16 Oct 2011 19:44:51 -0700 Received: by vcbfk14 with SMTP id fk14so4551059vcb.2 for ; Sun, 16 Oct 2011 19:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pHIdcOwwXAwvqdpm0u+WveoaXblGvilT2DdabjZwCcc=; b=jvq+LgMx0bT2rEQW89edTrEJMYb7oNUHL/OzNyLcZznqJ+/sD8W8yyJQJJIJM8nlO7 umxWtAb/Ls21pfGY8rOg== Received: by 10.150.218.11 with SMTP id q11mr16011192ybg.105.1318819491260; Sun, 16 Oct 2011 19:44:51 -0700 (PDT) Received: by 10.150.218.11 with SMTP id q11mr16011179ybg.105.1318819491108; Sun, 16 Oct 2011 19:44:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Sun, 16 Oct 2011 19:44:31 -0700 (PDT) In-Reply-To: <4E9A8C15.2030605@gmail.com> References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> From: Lorenzo Colitti Date: Mon, 17 Oct 2011 11:44:31 +0900 Message-ID: To: =?ISO-8859-1?Q?David_T=E4ht?= Content-Type: multipart/alternative; boundary=000e0cd1f86e4a563604af7597ff X-System-Of-Record: true Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing 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, 17 Oct 2011 02:44:54 -0000 --000e0cd1f86e4a563604af7597ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Oct 16, 2011 at 16:47, David T=E4ht wrote: > Just as a data point, the babel and AHCP protocols creates a router-id > from a EUI-64. problem solved, there. And when there is a collision, what happens? The network breaks? Note that I say "when" there is a collision and not "if" because: - MAC addresses are supposed to be unique, but in practice, there are duplicates. - If a home router supports MAC address cloning, then there are more duplicates. - When you try to fit a 64-bit EUI-64 into 32 bits, sooner or later there will be a collision, because, as my mother used to say, "you can't fit a quart into a pint pot". --000e0cd1f86e4a563604af7597ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 16, 2011 at 16:47, David T=E4ht <dave.taht@gmail.co= m> wrote:
Just as a data point, the babel and AHCP protocols create= s a router-id
from a EUI-64. problem solved, there.

And when there is a collision, what happens? The network breaks= ?

Note that I say "when" there is a collision and not &quo= t;if" because:

- MAC addresses are supposed to be uni= que, but in practice, there are duplicates.
- If a home router supports = MAC address cloning, then there are more duplicates.
- When you try= to fit a 64-bit EUI-64 into 32 bits, sooner or later there will be a colli= sion, because, as my mother used to say, "you can't fit a quart in= to a pint pot".
--000e0cd1f86e4a563604af7597ff-- From robert@raszuk.net Sun Oct 16 21:22:00 2011 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 D87871F0C36 for ; Sun, 16 Oct 2011 21:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THcl0yTvtJov for ; Sun, 16 Oct 2011 21:22:00 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 285641F0C35 for ; Sun, 16 Oct 2011 21:22:00 -0700 (PDT) Received: (qmail 9947 invoked by uid 399); 17 Oct 2011 04:21:59 -0000 Received: from unknown (HELO ?10.0.1.3?) (216.31.254.135) by mail37.opentransfer.com with SMTP; 17 Oct 2011 04:21:59 -0000 Message-ID: <4E9BAD66.8000905@raszuk.net> Date: Mon, 17 Oct 2011 06:21:58 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com, Fred Baker References: <201110170232.p9H2WgkP073058@gateway.ipv6.occnc.com> In-Reply-To: <201110170232.p9H2WgkP073058@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 04:22:01 -0000 Fred and Curtis, Many thx for your emails. Indeed perhaps my example of MPLS-TE hack was a bit unreal for this alias - you are right. However I intended (apparently quite poorly) to express two points which while following from time to time this group I keep struggle myself with. Point #1: If we are dealing with "zero configuration" network why do I need routing protocols ? Why do I need in fact more then one gateway or two in the case of multi-homed Grandma ? If I want to build some subnets inside I will get an extra router or two, but I see no magic how those routers even if coming from the most brilliant vendor will be able to guess out of the box my intentions. Point #2: If I need more then reliable exit to the internet and need to have few subnets at home (like I do today) Fred can call me UFO, but I fail to see how difficult is to type two lines to establish a loopback address (which I will use from time to time to ssh to the box to check why it is not working) or to type 4 more lines to enable any IGP - if ever needed. So if there is any document already written which I may have missed which has the answer to the above I appreciate sharing a pointer. Automation is great we should have it where needed .. it is just that I am completely not convinced that it is needed here. Best regards, R. > In message<4E9A6657.70705@raszuk.net> > Robert Raszuk writes: > >> Hi Fred, >> >> I think the point is that in your algorithm you stated this step: >> >> > (3) It has to change its RID and start from the beginning. >> >> I would say (perhaps in line with Curtis comment) that this step is >> unrealistic. RID for many reasons (for example mpls-te) is hard >> configured in link state IGPs. > > If it is hard configured, then is has to be configured correctly. > Otherwise you have a conflict among two configured RID, then you have > a persistent non-working network. > > If a autoconfig guy comes along and stomps on it, then only the > autoconfig guy backs off. > >> Worse - some vendors - do base on this their very cool hack to forward >> v6 traffic over v4 TE LSPs. >> >> So I think statement that router has to change it's RID is >> operationally non starter. > > So you are saying that a vendor has a hack (private undocumented > extension might be the market-speak) that is not backwards compatible > to other implementations *of a full standard* and we can't create a > backwards compatible extension because it would interfere with the > hack? (which you think is a very cool extension?) > >> Cheers, >> R. >> >>> On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote: >>> >>>> All adjacencies have to go down to change router-id. The other end of >>>> the adjacency will withdraw its side of the adjacency. >>> >>> well, yes, and if I change my routerid, all adjacencies will go >>> down. Not sure what the point here is... > > Curtis > > From rogerj@gmail.com Mon Oct 17 03:33:37 2011 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 25CAF21F8783 for ; Mon, 17 Oct 2011 03:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-slrcIh-lgV for ; Mon, 17 Oct 2011 03:33:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6A321F877F for ; Mon, 17 Oct 2011 03:33:35 -0700 (PDT) Received: by bkas6 with SMTP id s6so4567016bka.31 for ; Mon, 17 Oct 2011 03:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6+PevL2c0OkRgsvz3atXf31OyvKgXNqnmesUzrUmAoQ=; b=nz8AhlKphadpov21OMXFxXkYvCy0aHgSvOggLhGBxsdOrl2zineoQn+xQYp9i1zyS9 oKkF6OwRN7zGLUHA1U4IMPbaJRmdKnNwumFwOOiLBWbtei49JacmqJEc9mHPUoSzNDCc ID6ekqXe8MzLXeihfeIUbTVDGHcozzLKuuy18= MIME-Version: 1.0 Received: by 10.204.129.146 with SMTP id o18mr13848350bks.95.1318847614450; Mon, 17 Oct 2011 03:33:34 -0700 (PDT) Received: by 10.204.25.7 with HTTP; Mon, 17 Oct 2011 03:33:34 -0700 (PDT) Date: Mon, 17 Oct 2011 12:33:34 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: homenet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rogerj@gmail.com Subject: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing 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, 17 Oct 2011 10:33:37 -0000 I've been on my way to write this, most of all for myself, for a while so here we go... This is how _I_ understand most of the ongoing discussions and where we are going, our goal. It is not at all technical on the protocol level, it is a high-level view/design/scenario... I'll try to summarize how I understand homenet with breaking it down to three part/layers. 1.) uplink towards "internet" 2.) internal routing/mesh/something 3.) end-user facing connection (wireless/wired) about #1 - uplink towards "internet" I believe we can quite safely assume we have to support more than two uplinks from our homenet device, at least we need to support it. Probably a mix of wired and wireless, any mix really and any way. Those links need some protocol to make connection to it's other side (ISP/provider). That part is covered afaik but we might want to make them more advance on the "routing" side but not our biggest concern.... I would assume it would be useful in the zeroconf mindset for the uplink(s) to know if it's alone or not. One could be wired and one wireless toward the same provider. There are already providers selling that type of connection as a product, ADSL combined with a backup 3G link.... work like a charm. But of course, they've hidden the routing and linknet part behind a VPN/MPLS-alike system :) What should happen if the in-use uplink goes down, I guess it should back-off, tell the other "hi, my uplink(s) are down", then pull back all of the prefixes it use and let the other uplink take over... somehow through some magic/undefined system:-) ... or maybe the uplink just tell layer #2, "hi I'm down" and let that part solve it? And another scenario, maybe not all of the uplinks are towards what we call Internet, maybe only one of them have the full view of Internet while the other two are toward other closed network? So we need some sort of routing here to... about #2 - internal routing Can be the same box, or another, but a bit different tasks to be executed. The same here as for uplinks, there are quite likely to be more than one LAN. Guest network vs normal network are the two most common... Combined with two uplinks we are talking about the possibilities to have more than two prefixes in use (IPv6) and more than one NAT segments (LAN). Somehow this layer need to know where to send the traffic, or where not to send it. And if said uplink 1 goes down, then maybe that prefix need to be revoked and instead use the prefix from uplink 2 ? Not to forget the network some of us have, more than two LAN with routing and not NAT, three uplink (2 IPv6 and one IPv4), wireless, wired, wireless-bridge between wired network etc... we need to be able to manual overrule some options and add custom configuration. Tons of other problems here to but it's "just" routing :-) ... there is also the problem of any end-user equipment having both wired and wireless connection, multihoming really :-) But that really is for the next part to handle. about #3 - end-user connection Users can have both wired and wireless connection. Which one should the device (end user facing part) prefer? I'm quite sure we should rule out letting the end-user choice :-) Not that it will be easy to detect a device being connected both on the wire and over wireless... What happen if the in-use prefix change? Like if we move from one uplink to another but from different ISP. How do we even pick an ISP in the beginning when we have two or more?! Use prefixes (IPv6) from all of them and announce several default gateways or? Either this layer, or layer 2 - routing has to make a decision on which prefix that should be announced to the user. Not to forget that wired behave different than wireless in a number of ways as mention by others... And to make matter a bit more complex, I believe the user, you're average Joe or you're grandma, should be able to connect the homenet device pretty much anyway the equipment fits together and the devices should just figure out the rest between them self. Guess we need some sort of way to mark ports on the devices as uplink or downlink, but preferable they should be able to sort it out between them.... Not to forget we need some sort of bootstrap system to get things up'n'running when we're connecting the homenet device for the first time. Todays system where you connect to the device on a given and clearly visible (well, sometimes at least) address to make some very basic configuration are probably doable in the future to. As other have mention, the use of 192.168.0.1 or similar cannot continue, we should use the DHCP/DNS options and let The Device you are connected to always by default have the name router.local or anything along the same line. That will remove the confusion I can quite clearly imagine when a user are asked to type in an IPv6 address..... (and if there are more than one device in your network the System It Self will give them a name since it already know about all other devices in the network, let local DHCP/DNS give them names like uplink1.local, uplink2.local,routing1.local etc... ) and probably quite a few other issues I haven't mention on just the high level... --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From curtis@occnc.com Mon Oct 17 17:03:32 2011 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 68A8411E80B9 for ; Mon, 17 Oct 2011 17:03:32 -0700 (PDT) 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.040, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiPwMN5nOM7V for ; Mon, 17 Oct 2011 17:03:30 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3D811E80AE for ; Mon, 17 Oct 2011 17:03:29 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9HNOWHl056025; Mon, 17 Oct 2011 16:24:32 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9HNOWHl056025 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318893873; bh=UWkd3TUuvAdCJtMvfgW66BdaxojfMnT0oNfXI/F6QhM=; h=To:cc:Reply-To:Subject:From:Date; b=kHDE85+JscGO8vnZsHdmi63tdUzs0L9eDnvyPWnQb8Cs5qpIoeHUlEbsV6PZi8S0z 84jMhb3Wat3R6xuM7+YSL0yCMVK10TRXuv4PQu+P+vfcbAXdihvApqb3GfToIT5ezD MkQEAqWGiIAsvS9B5K7iJR0XGR39GkDoXWc0yWp4= Message-Id: <201110172324.p9HNOWHl056025@gateway.ipv6.occnc.com> To: homenet@ietf.org, Jari Arkko , Tim Chown , Jason Weil , Ole Troan From: Curtis Villamizar Date: Mon, 17 Oct 2011 16:24:32 -0700 Cc: curtis@occnc.com Subject: [homenet] comments on draft-chown-homenet-arch-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:03:32 -0000 First of all I would like to thank the four authors for putting this draft together. It seems to be as a reasonable starting point. We have had quite a bit of good discussion on list, but not specifically about the drafts we have available. I've read this and have mostly nits about is there. That is best put in diffs. I think we can add a lot which is best not done as diffs. Below are unified diffs on the txt version indented an extra four spaces. The indenting should still be OK with SMTP line wrapping (still under 78). Annotation is not indented. [ to extract just the diffs "grep -v '^ ' | sed 's/^ //'". ] --- draft-chown-homenet-arch-00.txt 2011-09-21 11:34:00.000000000 -0700 +++ draft-chown-homenet-arch-00.chg 2011-10-13 10:20:04.000000000 -0700 @@ -121,12 +121,14 @@ networking technology in an increasingly broad range of devices and media. This evolution in scale and diversity sets requirements on IETF protocols. Some of these requirements relate to the need for - multiple subnets for private and guest networks, the introduction of + multiple subnets, for example for private and guest networks, + the introduction of IPv6, and the introduction of specialized networks for home automation and sensors. While advanced home networks have been built, most operate based on - IPv4, employ solutions that we would like to avoid such as network + IPv4, employ solutions that we would like to avoid such as cascaded + network address translation (NAT), or require expert assistance to set up. The architectural constructs in this document are focused on the problems to be solved when introducing IPv6 with a eye towards a Nit: Multiple subnets are needed for other reasons as well. Nit: IPv4 NAT is OK and needed in some cases. We want to avoid cascaded NAT. This may remove some of the objections to anti-NAT wording. @@ -183,13 +185,13 @@ routing and security policies. Documents that provide some more specific background and depth on - this topic include: [I-D.herbst-v6ops-cpeenhancements], + this topic include: [I-D.herbst-v6ops-cpeenhancements expired], [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. In addition to routing, rather than NATing, between subnets, there are issues of when and how to extend mechanisms such as service discovery which currently rely on link-local addressing to limit - scope. + scope. [prefix scoped anycast?] The presence of a multiple segment, multi-router network implies that there is some kind of automatic routing mechanism in place. Nit: Just a note that the draft has expired. Comment/discussion: I agree that some mechanism is needed. This sound like anycast with some limitations. Some reasonable limitations might be the globally routable prefix of the home network or the prefix of the PI address. There is no prefix scoped anycast (AFAIK) and this is not a candidate for TTL based anycast. OTOH, routing information can provide a bounds on TTL and the anycast can ask for "any within " doing a second pruning at the application layer, or the anycast can be filtered at provider uplinks. @@ -353,7 +355,7 @@ | Router | | Provider +-------+-------+ | network | / - | Customer / + demarc #1 ------- | Customer / | Internet connection / | +------+--------+ \ @@ -361,7 +363,7 @@ | Customer Edge | \ | Router | / +------+--------+ / - | | End-User + demarc #2 ------- | | End-User Local Network | | network(s) ---+-----+-------+--- \ | | \ The above two diffs add an indication of two potential homenet/provider demarcations to the figure. @@ -380,6 +382,35 @@ operation this arrangement is considered equivalent to the topology in Figure 1. + Two possible demarcation points are illustrated in Figure 1. The + samepossible demarcation points, while not shown, are applicable to + Figure 2 as well. The demarcation line indicates which party is + responsible for configuration or autoconfiguration. + + Demarcation #1 makes the Customer Edge Router the responsibility of + the customer. This is only practical if the Customer Edge Router + can function with factory defaults installed. The Customer Edge + Router can be provided by the service provider with proper + authentication information installed, or if simple enough, the + customer can be relied upon to enter authentication information (at + most a supplied user name and password). Other mechanisms may be + possible such as the provider supplying a USB memory with a + certificate or private key file. + + Demarcation #2 makes the Customer Edge Router the responsibility of + the provider. This may be the more common case today. In IPv4 + only networks a consumer Customer Edge Router is very likely to be + set up only to provide NAT on the customer side. For a small + business service one globally routable IP address or a small block + of globally routable IP addresses may be made available on the + customer side. In the latter case, the customer hosts must be + configured to use a fixed address rather than use DHCP and their + ARP response is used to identify which hosts have been assigned a + globally routable IP address. + + Using either Demarcation #1 or Demarcation #2, this situation can + be improved with IPv6 using the PD prefix capability [RFC3633]. + This topology is also relatively well understood today [RFC6204], though it certainly presents additional demands with regards suitable firewall policies and limits the operation of certain applications I did this as a diff since I don't think there would be much argument over this except more nits on my suggested wording. Authors please comment. @@ -591,6 +622,14 @@ the same provider, but the associated subnet(s) are isolated. Some deployment scenarios may require this model. + The demarcation point in Figure 3 and Figure 4 may be on either + side of the Customer Edge Router. In Figure 4, a different + demarcation may be chosen by each of the two providers. Figure 5 + requires that the demarcation be on the provider side of the + Customer Edge Router due to one Customer Edge Router serving two + service provider attachments. Figure 5 is more likely to occur + with small to medium business service than with consumer services. + 3.2. Requirements [RFC6204] defines "basic" requirements for IPv6 Customer Edge I didn't mark up these figures. This is mostly a reminder that two providers may choose to put the demarcation in a different spot. Note that the provider configured router model (demarc #2) is more problematic on the homenet side than demarc #1, but I didn't indicate this. The demarc #2 model is why so often there are two NATs back to back today. @@ -619,12 +658,30 @@ o Network security + The configuration of filters can be problematic if the filters are + configured on the provider side of the customer/provider + administrative demarcation. This would be the Demarcation #2 + described in Section 3.1, which today is more common. Providing + flexibility may force a topology [we need a figure 2b - back to + back routers] where the Customer Edge Router is connected only to a + Customer Interior Router with the Customer Edge Router configured + for transparent mode and filtering provided by the Customer + Interior Router where the customer can make any changes necessary. + + A provider which prefers Demarcation #2 can offer two options to + their customers if simplicity is a goal. One option is a default + filtering configuration. The second option at the choice of the + customer is transparent mode, putting the responsibility of + filtering on the customer. + 3.3. Considerations This section lists some considerations for home networking that may affect the architecture depending on how or if they are included. Comments are certainly required here. + [Note: choice of demarcation issues could also go here] + Multihoming A home network may be multihomed to multiple providers. This may The first diff is a further discussion on the impact of the two places where the demarc can be placed. The second diff is a note that the prior addition could be moved to considerations or kept where it is. @@ -647,7 +704,7 @@ are necessary as described in [I-D.baker-fun-multi-router]. In the case of multiple exit routers, either the use of NAT66 [RFC6296] or an alternative approach may be needed, e.g. - [I-D.v6ops-multihoming-without-ipv6nat]. One could also argue + [I-D.v6ops-multihoming-without-ipv6nat expired]. One could also argue that a "happy eyeballs" viewpoint, not too dissimilar to that proposed for multiple interface (mif) scenarios is also acceptable. The central part of the arguments about IPv6 Nit: Another expired draft. I am also unclear as to what the "happy eyeballs" sentence is getting at. Could the wording please be made more clear. @@ -713,7 +770,7 @@ designing these networks in the correct manner. There is no implied priority by the order in which the principles are listed. - Reuse existing protocols + Reuse existing protocols where appropriate It is desirable to reuse existing protocols where possible, but at the same time to avoid consciously precluding the introduction of @@ -732,6 +789,15 @@ Do we wish to say anything about other home networking related standards or groups, e.g. DLNA? + Avoid repeating mistakes + + Where existing protocols or protocol usage have demonstrated + significant flaws, do not resuse as-is simply because of + precedence. In such cases, the protocol may need to be extended + or usage guidelines provided. In some cases a protocol or a + defined mechanism may need to be avoided. For example, avoiding + IPv6 NAT is an explicit goal. + Dual-stack Operation Any solutions for IPv6 must not adversely affect IPv4 operation. Nit: Don't require reuse of protocols if they don't fit the problem. Maybe the wording I have here is strong but the current situation with NAT boxes masquerading as home routers IMO is severely broken. You may have guessed that I'm also not fond of bridging solutions. @@ -747,6 +813,8 @@ Some discussion has also happened on mapping of external IPv6 addresses to internal IPv4 ones. + [Discussion IPv6 ULA plus IPv4 NAT as a transition tool.] + Largest Possible Subnets Today's IPv4 home networks generally have a single subnet, and There was a lot of discussion on IPv6 ULA plus IPv4 NAT. One thing that may be interesting is allowing an option to disable use of IPv4 on the internal side. Handing out IPv6 only and using NAT to reach the IPv4 world may become more common in the years (or decades) to come as transition to mostly IPv6 occurs. Does anyone on list have experience with this? @@ -881,15 +949,24 @@ home network, and thus at least all routing devices in the network. - Proxy or Extend? + Proxy or Extend or Robust Solution? Related to the above, it would be desirable to decide whether in general existing protocols that are designed to only work within a subnet are modified/extended to work across subnets, or whether proxy capabilities are defined for those functions. - - + Routing protocols have proven robust in topologies where proxy + solutions are known to fail. Integration of currently + link-local or anycast functionality with the scope of internal + routing may offer a solution. For functionality that is + currently link local, automatically configured proxy, with + minimal extensions may be able to use routing information to + limit scope and avoid proxy loops. For functionality that makes + use of anycast but is intended to be local, internal routing may + be an appropriate scope. Backwards compatibility is essential. + The impact of bridges and legacy routers must be considered. A + important goal is to require no host changes. Arkko, et al. Expires March 24, 2012 [Page 16] The solution should be robust in any arbitrary topology. This has been the topic of a lot of discussion on the mailing list, with no clear consensus on "the best routing protocol for all situations" because such a thing may not exits. The details of which routing protocol to use need not be explored in this document. @@ -915,13 +992,25 @@ on the availability of the ISP network at any given time, other than for connectivity to services or systems off the home network. + Zero configuration or minimal configuration + + Home networks are installed by home owners who have limited or + no technical knowledge of IP, bridging or routing. Networks + should be robust regardless of topology, using a default + configuration. Minimal configuration is change is acceptable + for specific tasks such as providing authentication necessary to + enable customer/provider connectivity. It should always be + possible to configure routers for specific customer needs, but + never necessary to do so in order to basic addressing, routing, + forwarding and naming functionality to work. + Intelligent Policy As the Internet continues to evolve, no part of the architecture or security design should depend on hard coding acceptable or unacceptable traffic patterns into the devices. Rather, these traffic patterns should be driven off up-to-date databases in the - Internet. + Internet. [?] This principle should also cover consideration to avoid hard coding IP literals or taking other actions that unnecessarily Zero config needs to be an explicit goal. The last sentence above where I added [?] seems like an odd and maybe misguided requirement. Its good to have a mechanism to update packet filters but this seems almost like asking to fetch a URL on boot or periodically. One thing about firewalls is unexpected change can be bad. Also an automatic update to filters seems like too obvious an attack vector. This is the end of the nits and comments on what is there in the document. I suggest the authors also take a good look at the email exchange between Peter and I and see if we can incorporate some of those ideas into this document. For example: Separation into the following issues: uplink discovery, address allocation, user attachment, security, routing. As a general comment, the existing draft has more questions than answers. As it was intended to stir up discussion, it may have served that sort of purpose, but if we are converging on an architecture, then we should provide a document that provides more answers than open questions. So my question to the authors is whether the intent is to morph this document into an architecture or create another document to replace this? Curtis From curtis@occnc.com Mon Oct 17 17:03:32 2011 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 8BA3E11E80B9 for ; Mon, 17 Oct 2011 17:03:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char F8 hex): To: Roger J\370rgensen ; Mon, 17 Oct 2011 17:03:31 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 340BA11E80AF for ; Mon, 17 Oct 2011 17:03:31 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9HILtKr048064; Mon, 17 Oct 2011 11:21:55 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9HILtKr048064 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318875715; bh=IcnUk9tsTJbmvzI/MVZgGWHPHXuT4CQU36uPcitq3wE=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=CH/ne9PbY6Pfa/u+m3orR16vs/DroU5gl1RsIAcJboO9IWUOV6j9SgDZg1GElay9m YCd2yS+pKJahssg0W/KNggmVYHC0qtbKIjnBJicN2kqaYypEhOg2NKnpvj0vk0K4vw 7DeCq47glA+2z2swEjBVLiUklJIfbigNC9w1le6Y= Message-Id: <201110171821.p9HILtKr048064@gateway.ipv6.occnc.com> To: Roger Jørgensen From: Curtis Villamizar In-reply-to: Your message of "Mon, 17 Oct 2011 12:33:34 +0200." Date: Mon, 17 Oct 2011 11:21:55 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:03:32 -0000 In message Roger Jørgensen writes: > > > I've been on my way to write this, most of all for myself, for a > while so here we go... > This is how _I_ understand most of the ongoing discussions and where > we are going, our goal. It is not at all technical on the protocol > level, it is a high-level view/design/scenario... > > > I'll try to summarize how I understand homenet with breaking it down > to three part/layers. > 1.) uplink towards "internet" > 2.) internal routing/mesh/something > 3.) end-user facing connection (wireless/wired) See below. Added a few. > about #1 - uplink towards "internet" > > I believe we can quite safely assume we have to support more than two > uplinks from our homenet device, at least we need to support it. > Probably a mix of wired and wireless, any mix really and any way. > Those links need some protocol to make connection to it's other side > (ISP/provider). That part is covered afaik but we might want to make > them more advance on the "routing" side but not our biggest > concern.... > > I would assume it would be useful in the zeroconf mindset for the > uplink(s) to know if it's alone or not. One could be wired and one > wireless toward the same provider. There are already providers selling > that type of connection as a product, ADSL combined with a backup 3G > link.... work like a charm. But of course, they've hidden the routing > and linknet part behind a VPN/MPLS-alike system :) > > What should happen if the in-use uplink goes down, I guess it should > back-off, tell the other "hi, my uplink(s) are down", then pull back > all of the prefixes it use and let the other uplink take over... > somehow through some magic/undefined system:-) > ... or maybe the uplink just tell layer #2, "hi I'm down" and let that > part solve it? > > And another scenario, maybe not all of the uplinks are towards what we > call Internet, maybe only one of them have the full view of Internet > while the other two are toward other closed network? So we need some > sort of routing here to... I do not except #1 as stated. 1. No built in assumptions about whether a router has an uplink port and if so, which port it is. a. there may temporarily be no uplink in the internal network. b. the router may be used as an internal router with one of more uplink elsewhere. c. the router may have one or more uplink, which does not rule out an uplink attached elsewhere in the same internal network. d. assumptions about uplinks may be learned (zero config) or configured. Note: a good rule would be if you are not sure you have an IPv6 uplink never give out a PD longer than /65. If a prefix is handed out (to you) that is /64 or shorter and globally routeable, assume it is an uplink to a provider. Note: at this point, no assumptions as to how this is accomplish. It is doable (my assertion, echoed by others, disputed by some, ... or maybe I'm echoing). > about #2 - internal routing > > Can be the same box, or another, but a bit different tasks to be > executed. The same here as for uplinks, there are quite likely to be > more than one LAN. Guest network vs normal network are the two most > common... > > Combined with two uplinks we are talking about the possibilities to > have more than two prefixes in use (IPv6) and more than one NAT > segments (LAN). Somehow this layer need to know where to send the > traffic, or where not to send it. And if said uplink 1 goes down, then > maybe that prefix need to be revoked and instead use the prefix from > uplink 2 ? > > Not to forget the network some of us have, more than two LAN with > routing and not NAT, three uplink (2 IPv6 and one IPv4), wireless, > wired, wireless-bridge between wired network etc... we need to be able > to manual overrule some options and add custom configuration. > > Tons of other problems here to but it's "just" routing :-) > > ... there is also the problem of any end-user equipment having both > wired and wireless connection, multihoming really :-) But that really > is for the next part to handle. No product sold as a router should do only bridging and NAT. That is a NAT appliance with bridging on the NATed side. We should be very clear about that. If it does not route, and it just does NAT, it is not a router. **That needs to be in an RFC.** Change from "routing" to "allocation". Keep routing separate. #2 internal address allocation a. temporary addressing For both IPv4 and IPv6, a means is needed to start out with a globally non-routable prefix and subdelegate addressing, then establish temporary routing. For IPv6 a means of doing this is defined in IA_PD requests in DHCP6, but maybe not meeting all requirements. Ask neighbors for addresses and then delay with randomization in the delay before creating a fresh allocation. Hopefully except in the case of bridging long time islands, the network will settle on a single base allocation. b. addressing based on uplink allocation For both IPv4 and IPv6 a means is needed to suballocate the prefix provided by an uplink. For DHCP{4,6} this is challenging in that there is no way to quickly remove a prior temporary prefix and replace it *except* giving short lease times to temporary prefixes. Global addresses must only originate from configured routers (usually the provider routers). Global prefixes must never be temporarily assigned by a provider. c. NAT based on temporary addressing An interim solution during the transition from (a) above to (b) above, is to offer NAT to users of the temporary addresses. For some hosts that cannot tolerate an address changing, it may be better to leave the NAT in place. If connections are open, the NAT and temporary allocation should remain in place. d. multihoming and allocation For IPv6 which explicitly supports DHCP aliasing of addresses, this is less of an issue. An address can be assigned for every uplink though it would be better to prune the addresses. e. prune addressing After one or more uplink has been established, prune addressing by allowing temporary addressing to expire. Prune global addresses such that the subnet allocation is based on where the default route (or least specific route) comes from. f. disappearing uplink Two cases exist regarding provider response. In one case the multihoming (generally for a business) is coordinated among providers and in the other case it is not. i. coordinated Prefix allocation and routing can be coordinated, such that regardless of who allocated the prefix (or both allocated a prefix and there are two of them) there is a globally advertised specific route to the address allocated by the other provider. This case must be configured. ii. uncoordinated If one uplink goes away, the network must temporarily NAT for that prefix. If not, the other provider will not route the return packets correctly. Any UDP or TCP connections that were already open when the uplink goes down will be lost. Using the pruning rule in (e) where pruning is based on route to default, prefixes assigned to the lost uplink will disappear as leases expire. g. too small an allocation In IPv4, the block is likely to be too small. It may be one host address. If so, a default can be advertised into routing and PI address space can be allocated. h. mix of configured addresses Both host addresses and a subset of prefixes may need to be configured. Once anything is configured, the uplinks need to be configured to avoid dynamic allocation of any of the fixed parts of the address block that has been assigned. This also means they can allocate routeable prefixes when the uplink is down, advertising a non-usable default (infinity minus one and a link cost of one makes it unusable). i. routing See #5 below. This gets complicated if routing types (DV and LS) and metric types are mixed. j. security See #4 below. > about #3 - end-user connection > > Users can have both wired and wireless connection. Which one should > the device (end user facing part) prefer? I'm quite sure we should > rule out letting the end-user choice :-) Not that it will be easy to > detect a device being connected both on the wire and over wireless... > > What happen if the in-use prefix change? Like if we move from one > uplink to another but from different ISP. How do we even pick an ISP > in the beginning when we have two or more?! Use prefixes (IPv6) from > all of them and announce several default gateways or? > Either this layer, or layer 2 - routing has to make a decision on > which prefix that should be announced to the user. > > Not to forget that wired behave different than wireless in a number of > ways as mention by others... We have to get rid of long lease times. If a connection goes up, its OK if NAT is used for a while. If a lease goes down, same is true. An extension to DHCP (or other allocation mechanism) that provides an immediate allocation withdrawl would be good. A refusal on the grounds of "in use" would also be good. A capability can identify legacy hosts which need to get one prefix and use it forever. It may be best to IPv4 NAT for legacy hosts and give them IPv6 real addresses when available. Note that legacy hosts which "listen" for connections are often confused if interfaces get renumbered. This would normally be a headache to enterprise users with services on internal servers. These applications would have to be smarter or the addresses configured. > And to make matter a bit more complex, I believe the user, you're > average Joe or you're grandma, should be able to connect the homenet > device pretty much anyway the equipment fits together and the devices > should just figure out the rest between them self. > Guess we need some sort of way to mark ports on the devices as uplink > or downlink, but preferable they should be able to sort it out > between them.... We agree on the first point. On the second point, there should be no designated uplink on a device. Any port can become an uplink. More than one port can become an uplink. It is also possible that none will be an uplink. > Not to forget we need some sort of bootstrap system to get things > up'n'running when we're connecting the homenet device for the first > time. > Todays system where you connect to the device on a given and clearly > visible (well, sometimes at least) address to make some very basic > configuration are probably doable in the future to. > As other have mention, the use of 192.168.0.1 or similar cannot > continue, we should use the DHCP/DNS options and let The Device you > are connected to always by default have the name router.local or > anything along the same line. That will remove the confusion I can > quite clearly imagine when a user are asked to type in an IPv6 > address..... > (and if there are more than one device in your network the System It > Self will give them a name since it already know about all other > devices in the network, let local DHCP/DNS give them names like > uplink1.local, uplink2.local,routing1.local etc... ) Some [NAT boxes masquerading as routers] already do this by offering themselves as DNS forwarder and providing a fake hostname in a fake TLD that is mapped to 192.168.1.1. That's OK for IPv4. It a little problematic when there are two uplinks and they both want to be 192.168.1.1. That is why the "ask first, then allocate" rule. Someone gets 192.168.1.1 but not both. A better method of locating and identifying these not yet configured routers is needed. > and probably quite a few other issues I haven't mention on just the > high level... Security is easier than routing (really!) so I gave it #4. Until the controversy of point (a) rears its ugly head. #4. security a. No filtering should be done on a link that is not identified as an uplink. b. By default strong filtering should be enabled on any uplink. c. Filtering can be weakenned, holes punched through, or disabled by configuration. d. [I would like to see any document that attempts to standardize the type of filtering clearly separated from the addressing and routing work. I don't think that is too much to ask.] #5 routing a. DV and LS routing can mixed within a domain. DV routes can be injected into LS routing (for example as OSPF ASE). LS prefixes can be injected into DV. Within a LS or DV region, a mechanism to prefer internal routes to the LS domain or DV domain is needed. (OSPF already prefers internal prefixes to ASE). b. For Ethernet or other wired media, LS is preferable. c. For wireless with an AP (infrastructure bss), further discussion is needed. Constrained DV has been proposed. OSPF with AP as the DR has been proposed. (Who gets to be the BDR or should the AP also fake another host and call it the BDR?). d. For wireless mesh (MBSS), further discussion is needed. This may be the domain of MANET and they have not converged (AFAIK) on a one best protocol. For (a) we should recommend one. OSPF is full standard and is cleaner but we have v2 for IPv4 and v3 for IPv6. ISIS has NSAPs as router ID (even uglier than IPv6 addresses or MACs and must be unique), sends around really big packets even for small changes, but supports both IPv4 and IPv6 in one instance and is (strongly) prefered by some. btw- I took some notes (as diffs) on draft-chown-homenet-arch-00 but have not had time to annotate the diffs and send them out. That document should be the base of discussions unless we decide it would be better to start over for some reason. Curtis From curtis@occnc.com Mon Oct 17 17:03:33 2011 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 066EC11E80B9 for ; Mon, 17 Oct 2011 17:03:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): To: David T\344ht ; Mon, 17 Oct 2011 17:03:32 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 6F36311E80AE for ; Mon, 17 Oct 2011 17:03:32 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9H334i3073776; Sun, 16 Oct 2011 20:03:04 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9H334i3073776 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318820584; bh=39x4brAFWcKI57J2/LTZVogpwyYWoaJhOXUj+PX5dqc=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=LI8p0XIH8eDBFZ7DySslzNDx23KgEWD3K8TS+NHT95FDvbhlENpzSoSC1vzBhm2mx ZdVLG/WgF8hIbTqlDf5d3rzzrO2n3WkLSPhefYBarF69Adj73/qQlAsLK2G93Bi4YA jSgvraW0Yd3FDJkl7P/z1APx4Ch7kxBou+XdTA0w= Message-Id: <201110170303.p9H334i3073776@gateway.ipv6.occnc.com> To: David Täht From: Curtis Villamizar In-reply-to: Your message of "Sun, 16 Oct 2011 09:47:33 +0200." <4E9A8C15.2030605@gmail.com> Date: Sun, 16 Oct 2011 20:03:04 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:03:33 -0000 In message <4E9A8C15.2030605@gmail.com> David Täht writes: > On 10/16/2011 03:35 AM, Curtis Villamizar wrote: > > In message <0651F29F-C816-4A23-BD6F-C791CE89BB11@cisco.com> > > Fred Baker writes: > > > >> > >> On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote: > >> > >>> On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar wrote: > >>> Random number selection for router-id and this sort of recovery would > >>> solve the zero config OSPF issue related to router-id selection. > >>> > >>> Not yet solved in existing zospf draft (afaik) but solvable. > > Just as a data point, the babel and AHCP protocols creates a router-id > from a EUI-64. problem solved, there. > > -- > Dave Täht When using a 64 bit value to create a unique 32 bit value there is a finite but small probability of a collision with OSPF. Babel is experimental and AHCP is a draft and we aren't going to drop a full standard because of a router-id issue. Not that I don't think Babel and AHCP are promising work. Certainly flooding in a dense wireless mesh is not a good thing as Jim pointed out but example so there are cases where OSPF or ISIS is not applicable. The topic at the moment is OSPF (and ISIS) so problem not solved by EUI-64. Curtis From curtis@occnc.com Mon Oct 17 17:03:33 2011 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 57FB211E80AE for ; Mon, 17 Oct 2011 17:03:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): To: David T\344ht ; Mon, 17 Oct 2011 17:03:32 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D34A711E80B8 for ; Mon, 17 Oct 2011 17:03:31 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9H4Nsoj075740; Sun, 16 Oct 2011 21:23:54 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9H4Nsoj075740 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318825434; bh=uElUgxp/AlZaeWLOtsCEDueqOFAZflUUlyfJbdWthDg=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=AUmS+pZQASuRZzHXyvRtm8JXOgk/8krt+ALPTPK5vNIlPN1HbBL0eZNxOwY5cTz9T WTWLGxaiopOPlf6OyV2vP5RoHZyVrlIv4lp49vKDbgvu1U28cqCFn+fSzU5GM1WM+M EhI0SIvPylh8ViLDQ1Kvq8F8ZVg0GkKOyzr7NHXU= Message-Id: <201110170423.p9H4Nsoj075740@gateway.ipv6.occnc.com> To: David Täht From: Curtis Villamizar In-reply-to: Your message of "Sun, 16 Oct 2011 12:47:29 +0200." <4E9AB641.7050201@gmail.com> Date: Sun, 16 Oct 2011 21:23:54 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:03:33 -0000 In message <4E9AB641.7050201@gmail.com> David Täht writes: > In reviewing this enormous thread it appears to have got off-track > again, discussing esoterica of various routing protocols and not focused > on the big picture. > > There's been too many comments for me to comment individually on the > messages. > > However, overall trends on this list are discouraging. > > 1) Getting IPv6 working well inside the home is a hard problem! It helps > to actually try to make something work, to see the relevant details. I'd > like it very much if at an upcomin > > I've built 3 such networks, and am in the process of building several > more - as well as making available code on a cheap, 120 dollar, platform > to make it possible to actually go and set one up yourself to play with, > so the more devilish, detailed problems become apparent. I've done my > best to make sure 6to4, at least, works right out of the box. Native (no > PD yet!) works pretty well, too - but getting the 6to4/ipv6 native to > co-exist better is going to take slightly more work. > > http://www.bufferbloat.net/projects/cerowrt/wiki/OCEAN_CITY_INSTALLATION_GUIDE > > There's babel, batman, rip, radvd, ospf, ospfv6, is-is, and bgp all > available. Go play. > > I'd like it very much if at an upcoming meeting or event someone or > someones were to demonstrate working code... > > 2) Now, in reviewing this thread, I was disappointed to see that my ipv6 > routing protocol of choice (babel) has not been discussed so far to any > extent. While this protocol is somewhat new, an rfc and working code > both exist, and working code has existed for several years. > > http://tools.ietf.org/html/rfc6126 > http://www.pps.jussieu.fr/~jch/software/babel/ > > Of late there has been a great deal of work on creating a metric that > does diversity routing - accounting for the differences in performance > between contested wireless channels and ethernet to some extent. > > It seems to me that that babel has got lumped in a mental catagory of > 'mesh networking protocol' - which it is - but it is better described as > 'rip on speed' as it works across normal wired, wireless, AND mesh > networks - something no other routing protocol does well (IMHO!). Things > like 802.11s are targetted at wireless only. > > The future inside the home is mostly wireless, not wired... and as many > of the assumptions built into ipv6, dhcp, dhcpv6, ra announcements, etc > completely predate the rise of wireless everywhere, they tend to be, > well... wrong. > > Here are the current routing tables from bloatlab #1 > > http://www.bufferbloat.net/projects/cerowrt/wiki/BloatLab_1 > > http://www.teklibre.com/~d/labroutes/ > > I am using CIDR networks (/27 netmasks) on the ipv4 side to reduce the > broadcast/multicast problem that wireless-n has, and a variety of IP > address distribution mechanisms on the ipv6 side - autoconfig/ra and ahcp. > > Some notes: > > 0) It took me multiple years of fiddling with the ipv6 routing protocols > available to settle on babel. Babel is definitely not finished or > perfect, but thankfully it has a pluggable metric. > > 1) Babel treats IPv6 as a first class object - ipv4 and ipv6 routes are > distributed in the same message - and within the same daemon and > configuration files. I had used olsr in an earlier attempt at convincing > ipv6 to work well on a previously pure ipv4 - the size of the 2 daemons > required, the doubling of packets sent, and the complexity of the conf > files all deterred me. > > 2) Setup is devestatingly simple compared to any other routing protocol > I've tried. For example, it uses a EUI-64 equivalent as a router-id, no > setup required. > > Now I actually use, in the home, a setup that dumps dhcp, dhcpv6, and ra > entirely, replacing them with a combination of AHCP and babel - AHCP > also distributes ipv4 and ipv6 in the same message, and also (when done > right) gives the ability to transparently move between wired and > multiple wireless links without dropping connections. Stepping back into > what others think as the real world... in the office - is often a shock > - I unplug and... "oh damn, I just lost 20+ windows and the movie I was > streaming..." where that *doesn't happen* when using the above two > protocols at home.... > > AHCP uses /128 netmasks which makes subnetting a single ipv6/64 > allocation a breeze. > > I can think of a few more compelling advantages for considering new > ideas such as these protocols inside the home, but this is almost enough > for today. > > I'll talk to the more generic problems with prefix based routing in a > mixed 6to4 and native scenario, the dns naming problem, and the ip > address expiry problem some other day... > > but you can see those for yourself with a little investment of time and > hardware in trying to actually make something - anything! - actually work. > > > -- > Dave Täht All very impressive. You still have quite a few routes for a network with very few hosts. At some point you have to wonder whether it might be better to arrange a OSPF style bcast network for mesh that turns out to be a cluster of many routers within a given very close range. IF the AP style (infrastructure bss) is used rather than mesh (MBSS) then this is a natural fit. DR election isn't all that painful and as long as the DR remains stable (hint: give the AP a high number in the DR election) then adding is fine. Multicast from the DR would be nice rather than multiple unicast. For now we have OSPF and ISIS (and BGP) running the global Internet on the one hand. They are well proven, but these may or may not be applicable to the homenet. On the other hand we (or you) have lots of promising work and some running code that isn't quite a mature and isn't (afaik) widely deployed. I don't think we should rule out either one. Protocols that are only applicable to specific circumstances tend to go away. I'm not yet convinced either way on the staying power of babel and AHCP. Perhaps I have a bias for link state protocols that has set in over the last nearly 20 years of using them. But it is hard to argue with running code once a lot of people are running with it. Curtis From curtis@occnc.com Mon Oct 17 17:03:34 2011 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 4FBE011E80C2 for ; Mon, 17 Oct 2011 17:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihSbKpoouR9z for ; Mon, 17 Oct 2011 17:03:33 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 026A411E80AF for ; Mon, 17 Oct 2011 17:03:32 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9H2OHcj073001; Sun, 16 Oct 2011 19:24:17 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9H2OHcj073001 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318818257; bh=1Hjkwcu1yHo5/V1bmUyepWoH/0jHpFclIpQOy3hG4vE=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=CmpZFVPk8T8KIkzrQ2IMsaHSb5XwEMRGAflxV+OSTrIuWlb3deZ08e19gYfWvnmhn sSH2yJwytwBSEKg8lw0l+CaE2tsZxuGeGw/yjF4iwyeuse8qbA/2Jf2pPQ20aukdiz 9Zz2gictTC1PZ8GDbN1Eu2uiKJOjTAEEHItnpHWo= Message-Id: <201110170224.p9H2OHcj073001@gateway.ipv6.occnc.com> To: Fred Baker From: Curtis Villamizar In-reply-to: Your message of "Sat, 15 Oct 2011 21:27:57 PDT." Date: Sun, 16 Oct 2011 19:24:17 -0700 Cc: Erik Nordmark , curtis@occnc.com, Acee Lindem , Jari Arkko , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:03:34 -0000 In message Fred Baker writes: > > On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote: > > > All adjacencies have to go down to change router-id. The other end of > > the adjacency will withdraw its side of the adjacency. > > well, yes, and if I change my routerid, all adjacencies will go > down. Not sure what the point here is... If you've just booted up and there is a one in a few million chance that you'll get half way on the database load on the first adjacency to come up and have to start over, then I don't think it is a big deal. If the point is what if you've been up and running for a while, then perhaps we need a holdup timer to see if the problem clear if one or more adjacencies has previously completed a full database load. This means that on a power up of everything, there will be merged islands with conflicts and the conflicts won't resolve until the holdup timer expires. Some advice on being slow to correct "staleness" in this situation would prevent the current OSPF staleness correction wars (each corrects the other as fast as it can if you manage to configure a conflict today - apparently common when people clone and edit configs but occasionally forget to change the router-id - I wouldn't know since we machine generated the configs where I used to play). Curtis From curtis@occnc.com Mon Oct 17 17:03:35 2011 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 4178611E80C8 for ; Mon, 17 Oct 2011 17:03:35 -0700 (PDT) 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.080, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGK3mCnyJ8KV for ; Mon, 17 Oct 2011 17:03:34 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8211E80C0 for ; Mon, 17 Oct 2011 17:03:34 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9H2WgkP073058; Sun, 16 Oct 2011 19:32:42 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9H2WgkP073058 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1318818762; bh=Ut+Us39qXwUwrwSWqwIShBkgaLw7VFmiG+8DruU3Gpw=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=BFLLeapapPPr9zsBy3ktR2hwr/mymjjiNueDYAw93LsDDucNGF11EboPRwPPgB3ij i1evlSvfHr7u+u0kmF/rmRyWRdGHhSG6O+dJEnNgrNZVAIPO7hPGLQSbttswJWDHo1 JRPh0G5DPp5BLcR1tfG7iw49/UWzEXL6w6JgDTBQ= Message-Id: <201110170232.p9H2WgkP073058@gateway.ipv6.occnc.com> To: robert@raszuk.net From: Curtis Villamizar In-reply-to: Your message of "Sun, 16 Oct 2011 07:06:31 +0200." <4E9A6657.70705@raszuk.net> Date: Sun, 16 Oct 2011 19:32:41 -0700 Cc: Erik Nordmark , curtis@occnc.com, Acee Lindem , Jari Arkko , Fred Baker , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:03:35 -0000 In message <4E9A6657.70705@raszuk.net> Robert Raszuk writes: > Hi Fred, > > I think the point is that in your algorithm you stated this step: > > > (3) It has to change its RID and start from the beginning. > > I would say (perhaps in line with Curtis comment) that this step is > unrealistic. RID for many reasons (for example mpls-te) is hard > configured in link state IGPs. If it is hard configured, then is has to be configured correctly. Otherwise you have a conflict among two configured RID, then you have a persistent non-working network. If a autoconfig guy comes along and stomps on it, then only the autoconfig guy backs off. > Worse - some vendors - do base on this their very cool hack to forward > v6 traffic over v4 TE LSPs. > > So I think statement that router has to change it's RID is > operationally non starter. So you are saying that a vendor has a hack (private undocumented extension might be the market-speak) that is not backwards compatible to other implementations *of a full standard* and we can't create a backwards compatible extension because it would interfere with the hack? (which you think is a very cool extension?) > Cheers, > R. > > > On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote: > > > >> All adjacencies have to go down to change router-id. The other end of > >> the adjacency will withdraw its side of the adjacency. > > > > well, yes, and if I change my routerid, all adjacencies will go > >down. Not sure what the point here is... Curtis From mark@townsley.net Tue Oct 18 03:12:32 2011 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 5475921F8C56 for ; Tue, 18 Oct 2011 03:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h87AcY6n3vG6 for ; Tue, 18 Oct 2011 03:12:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8BDA21F8C3F for ; Tue, 18 Oct 2011 03:12:30 -0700 (PDT) Received: by wyh22 with SMTP id 22so461527wyh.31 for ; Tue, 18 Oct 2011 03:12:29 -0700 (PDT) Received: by 10.216.134.82 with SMTP id r60mr604919wei.105.1318932749321; Tue, 18 Oct 2011 03:12:29 -0700 (PDT) Received: from [192.168.0.108] (dan75-4-82-239-58-63.fbx.proxad.net. [82.239.58.63]) by mx.google.com with ESMTPS id y10sm2575882wbm.14.2011.10.18.03.12.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Oct 2011 03:12:27 -0700 (PDT) From: Mark Townsley Content-Type: multipart/alternative; boundary=Apple-Mail-56--824357296 Date: Tue, 18 Oct 2011 12:12:22 +0200 Message-Id: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [homenet] Interim meeting minutes 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, 18 Oct 2011 10:12:32 -0000 --Apple-Mail-56--824357296 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Many thanks to Juan Carlos Zuniga for taking notes on the first day and = most of the second day. We're still waiting on input from other minute = takers, but here is what Juan sent in. Its untouched other than one edit = requested of Mark by Juan (marked as such in the notes).=20 - Mark & Ray IETF Homenet Interim Meeting Philadelphia, PA 6th and 7th of October, 2011 Chairs: Mark Townsley Ray Bellis Area Director: Ralph Droms Tech Advisor: Acee Lindem Slides at http://trac.tools.ietf.org/wg/homenet/trac/wiki Note Well Agenda Bashing 09:30 - 12:00 - Architecture Working Session (Timm Chown, Jari Arkko) Jari =96 Homenet Architecture draft-chown-homenet-arch Tim Chown, Jari Arkko, Jason Weil, Ole Troan Approaches to standardizing homenets: operational (works well for me), = implementation commonality (xyz have it), experience (we have enough = experience to recommend it), functionality (we need this feature), = specification (IETF has to make it) Authors are in operational experience List has pushed the envelope a little further Acee Lindem =96 Question on requirements: given the discussion on the = list, how do we reach consensus? JA =96 we have to present the case, understand and then make a decision Ralph Droms =96 How do you see the deliverables coming out? IETF = Recommendations? In service discovery there are many options. Are we = going to pick one and bless it, or are we going to look at all and = recommend how to make them work Michael R =96 Are we going to look at all flowers? RD =96 Any thoughts about the ones that are being implemented and sold = today? JA- We are not here to kill solutions. IETF normally produces = specifications and people choose. Here however we should provide a basic = recommendation (naming base).=20 We might push the envelope to sensor routing or service discovery Mark T =96 6204 could be seen as homenet v0.0. We are now more focused = on how we do it with multiple routers (at home). RD =96 most ISPs give a /64. I don=92t want to make assumptions that = this will be everywhere, as we could have more constrained scenarios. JA =96 good example. If we want to support multiple networks behind a = /64 we might get in trouble. Jim Witt =96 this is a deployment case today, but should not be like = this. JA =96 They provide this today but they are working hard to provide more = in the future. MT =96 I have not seen a recommendation for /64 at home. Probably there = is a 3gpp for handset. Jim =96 This is a place where running code should speak. JA =96 I meant this by conservative Lorenzo =96 Running code today does not do this. MT =96 there is, but you cannot get them off-the-shelf. In my company we = decided to put 6204 JA =96 it is reasonable to specify what should be done Lorenzo =96 There are routing problems that you cannot solve with RIP, = DHCP PD. So we need it Jim =96 Development goes in upstream OAM projects and often code is 5 = years old, e.g. linux kernels MT =96 Some companies do it differently. We do it and Apple does it too Lorenzo =96 are you suggesting write code and feed it in the upstream Jim =96 Yes Michael =96 you can have =93orange and blue=94 versions for specific = problems AL =96 a lot can be accomplished if the box at the edge it treated as = such Michael =96 1% of users with problems cause 50% of support calls Jim =96 badly home boxes create these problems. Cheap boxes use open = source codes. If we can create this code then =93hopefully=94 the small = guys will pick it up Michael =96 As ISP, we often replace the box at the users=92 premises by = a less costly box that actually works. Jari=92s view Probably we will create recommendations on Things that exist Things that are there but not used Things that need to be written Possible recommendations (2 slides): What I have: Run local DNS servers=85 What I should do: Prefix Distribution from ISP, Simple security 6092 Michael: How to select when I connect my phone to the PC, they both = connect and they do tethering.=20 You can only solve this if your support VM=20 Basic Network Architecture 6204, v6ops-ipv6-cpe-router-bis, draft-baker-* Network Topology Multihoming Mainly a problem for the host The home should support multiple exist routers, and should let the host = know which one to use JA - 484 ingress rules we can rely on Michel =96 tow home network Alex R =96 So are we considewring the Femto case out of scope? Lorenzo =96 the netorks cannot deal with end to end. This is a role of = the host Fred Baker- I don=92t agree, you can use 6296 (nat66) and maintain = connectivity. Lorenzo =96 how about applications that carry IP address in payload? FB =96 they are broken G =96 we have to make sure we replicate walled-garden services =93bring = the information all the way to the host=94 and let it decide (e.g. DNS = server selection for walled garden services from two providers) Jason Livingston 4191 Principles =96 Assumptions (Tim Presenting now) Dual stack (of course IPv6-nly too) IPv6, but not damaging to IPv4 operation Transition tools are covered elsewhere RD =96 We don=92t want to rule out the case when you have a NAT (even if = connected by mistake) AL =96 Do you want to do NAT64 in home or at provider? JA - We will not address transistion and will not overlap with other = groups. We can however have IPv6 only recommendations for home networks = that mention what other should be used or not. Lorenzo =96 Are we taking a versioned approach?=20 RD =96=20 JA - Not saying that we cannot solve everything. WE ahave to carefully = think what we can do o=20 Lorenzo =96 What users are going to find useful JCZ =96 802 service discovery? MT =96 for a Linksys discovering if you are connected to another Linksys = or to the internet=20 It would be interesting (e..g do I turn on Firewall, NAT or not?) Alex =96 FF and WBA We are going to assume how to connect the two = networks=20 MT =96 CEA, BBF, DLNA, 802 (service discovery) RD - ZigBee alliance, looking at service and naming discovery heavily (presentation) We should allow for different practices on the ISP side=20= /48, /56, but what about /64? Static/dynamic prefix delegation? Intelligent policy Do not hardcode addresses or security policies =96 problem with security = and prefixes Transparent end-to-end communications May expect to use PCP or uPnP What about ULAs with the use of NATs? MT =96 moving from link-local to multiple links in home, we can use ULA Ole =96 Are we considering a homenet without an ISP? RD =96 You can setup ULA without ISP and then as soon as you get ISP you = disable ULA MT =96 I don=92t agree, ULA could still work Alex =96 how about DHCP Michael =96 Similar to ULA Lorenzo- your printing job will be stopped when your DSL comes back=85 = not good We have identified advantages but there are drawbacks 6204 MT =96 if v6 can detect if this is a WAN or LAN port=20 RD =96 Are we going to require the v4 topology in v6? Eg v bridgeing v4 = routing? If they have to be congruent, no issue. If they don=92t have to = be congruent then we have to look at that ??? (black shirt) =96 this may not be possible due to chipsets in the = market Michael =96 in cheap boxes this is mainly in SW Jim =96 today chipsets do VLAN and many other things.=20 Existing protocols are subnet scoped (mDNS, LLMR, DNS-SD) JA =96 How about gaming? MT =96 Missing elements? (Black) =96 Energy aware elements in the protocol? Erik Nordmark (remote) =96 ?? MT =96 ?? EN =96 Can you construct loops that break v4? JA =96 This is a problem on itself and we cannot fix it MT =96 We need to understand how complex the solution is if we want to = handle loops and then decide if we want to address this problem or not Lunch 13:15 - 15:15 - Prefix Configuration Working Session (Ole Troan) Requirements list Are names specific? MANET and RPL OT =96 you might want to know if you want to assign a prefix a link to = out again JA =96 Do you need this? MT =96 Defection of boundary affects PA distribution and many other = things (blue and red cables) Arbitrary Topology =96 Must (for real cases) Nice (for pathological = cases) Multiple sources =96 Must (support for more than one ISP, Femto, etc) Stable prefix =96 Must=20 JA =96 resilient to crashes, reboots and lease expiry Jim =96 Stable addresses are not meaningful. Name stability is a = critical Multilink subnet routing Are we ok supporting /64 only? MT =96 Erik and Ole should analyse if this is valid without host changes Jason =96 we are safe assuming multiple subnets and more than /64 Michael =96 if one /64 addresses 90%, can we assume two /64 address = 99.9, or ISPs prefer /63? Lorenzo =96 current HW would override old PA and would assign the new = one Hierarchical DHCP Flat DHCP prefix delegation draft-baker-homenet + RFC 3633 RD =96 You can assume that routers will not assign orefixes on links = that already have FB =96 multiple routers on the same link JA =96 there is a fundamental question whether resources are taken from = a pool, or a distributed algorithm chooses resources not being used Zeroconfig OSPF Lorenzo, AL - Allows border discovery, could help passing key = information JA =96 only OSPF? MT =96 you could make it work in other protocols=20 Jim =96 writing information every few minutes is fine. Writing every few = seconds is bad Lorenzo =96 By widely delyed we mean open implementation that has been = accepted. MT =96 Timecheck: go back to table? Continue? Jim - OLSR is of use, as there are mesh wireless deployments in Europe = using these WiFi.net. The battlenets run one vs the other Ole =96 Question is de we overlay routing protocol and prefix = assignment? LC =96 link state is very useful. LC =96 how difficult is zeroconfig with OSPF? AL =96 not much JA =96 can we have one sngle thing that does all for you? MT =96 this would make it easier to implement JA =96 still you have to define extensions and options MT =96 but still one spec Break 15:45 - 17:30 - Routing Working Session (Fred Baker) Routing presentation =96 Fred Baker Some link layers have special requirements (e,g, 802.15.4) Analysis documents (IPv4 examples) Use cases Single router (simplest) Multiple routers (needs to be addressed in case user adds them even = without realizing) Multipath networks=20 Not great for RIP Good point for OSPF or ISIS =96 these can help prefix allocation Jim/Fred: we all have built this Multihoming=20 Multiple UL If you assume BCP 38: RFC 3704 :fix problem of packets on wrong router ISP will filter packets by source address (BCP 38) FB: source-based routing would wolve this. You can change the routing at = the host, or you can re-send the packet Lorenzo: do you assume IGP? FB: You need to solve the problem when you have OSPF lifetime of ~45 = min. You can detect loss in 40 sec, which is much better than 45 min. In = case of router failure, the best would be for the remaining router to = advertise RA with zero lifetime JA: there are other requirements for multihoming: utility devices = require a specific ISP, IPTv from one ISP and Internet from another. Lorenzo: We might need to do source address routing Michael: we need to support the case when one ISP goes down ?? (squared shirt): E911 needs to be handled Lee: the second ISP will get the call and you don=92t want it MT: we are back to 3484 and Japan problem FB: the argument tells me that we want to stay away from RIP and get = closer to OSPF/IS-IS Protocol Styles AL/Jim/Lee: the issue with the footprint of the code depends on the = vendor and business case. However, the code would eventually would need = to be made available Proactive vs reactive RIP, OSPF, IS-IS vs AODV and RPL (useful when routes change and = appropriate for 802.15.4 networks) Michael: There could be a use case for both FB: Today, I would recommend RIPng, OSPF and RPL Jim: why are the wireless use OLSR Lorenzo: if we wna tto be compatible with PA we need to support a = protocol with TLV FB: Then IS-IS? AL: You could do it with OSPF if the information is different to the = existing one Lee: so do we need a dynamic routing protocol? FB: RIPng would solve use cases 1 2 and 3. For 4 we have the timing = issue. Lee: 30 mint acceptable, but 3 probably. I don=92t know if we need to go = to the seconds RD: If you don=92t want the full dynamic protocol we have to compare to = a DHCPv6 and small protocol, in which case probably the size is not much = different Jim: the implementation details matter here. We need to see the size of = the compiled code and the amount of RAM it takes JA: I=92m ok with supporting OSPF and PA distribution. I=92m not sure = I=92m ok with all the multihoming requirements MT: If you don=92t care about these, then what would wyou care Lorenzo: In v4 no issue, but with v6 this is and will be an issue MT: Remarks =96 We are trying to tell how to do v6 in home before the = product managers realize they need to do it and decide to do the same = that was done in v4 09:00 doors open 09:30 - 12:00 - Architecture Working Session (Timm Chown, Jari Arkko) 12:00 - 13:15 - Lunch Friday October 7 09:00 doors open (ISP issues) Agenda Bashing 9:40 =96 10:15 Security (Mark) Mark Townsley Automatic Border Detection is essential For service discovery For prefix assignment and routing=20 For security Default filters (ULAs?) Firewall Mike: Smart grid borders? FB: Utility might want you to use RPL RD: Smart grid is an application=20 Lee: At least service discovery and security would be nice to have in = the same place AR:=20 MT: A link between two routers need to be identified.=20 Home-home Home-ISP Home-Utility network FB: We can have the home become a customer of a number of networks = (upstream). This menas ISP and Grid are outside. Outside can be to 1) = Internet and/or 2) services Japanese TV still a different animal MT: We might want to give some naming to these borders Detect incpming packets.=20 Allow incoming conections from your home Allow incoming connections from internet Providing borders with ULAs we can define this =93Local=94 security boundary defined by: ULAs Link-local Prefix pushed down by R Magic? Jim: state has to be distributed in case there are multiple routers Mike: LAN party? With smartphones today people can roam to your home LAN = and get access to your content (e.g. photos)? Lee: we need an authorization mechanism for L2 connectivity Lorenzo: Security is L7. For L3, visitor in your house is the same = network Ole: Mike: RAs will have to carry the ULAs JA: If service differentiation exist. Do we have quipment=20 James W: Some applications make sure that they are talking to a link = local address.=20 Lorenzo: Today with v4 we cannot limit access to link local=20 Sqare???: xbox would do application level discovery=20 MT: we are talking about single-homed, multiple routers, multiple = networks, that=92s why we are comparing ULA instead of link-local Advanced Security Lee: statefull firewall MT: It is a smart Firewall. IPS: Intruder Protection Security FB: You don=92t need to standardize this JA: you might need to standardize the format to configure James Woodward: Is security needed if it doesn=92t work Lee: existing mechanisms are insufficient, however, they are useful JA: we are defining how to transport magic, not the magic itself MT: even if we define the content, it still has a place in the = architecture definition Mike: I see UPnP and PCP.=20 Lee; are we discussing whether we need Advanced seciruty or whether it = is in scope difining it? MT: We agreed that we need to detect borders in general. We might need = to define how the borders communicate their existence to neighbours with = the protocols. (*** MT to check this wording and perhaps expand) (Inserted by MT):=20 I believe we agreed that the homenet arch document would outline 3 = possibilities: 1. =93Transparent mode=94 or =93end to end security=94 mode which may = have basic filters for ULAs, but does not restrict traffic flow based on = global addresses (e.g., =93no firewall=94) 2. Simple Security 3. Advanced Security There was little hope that the group would come to consensus on which of = the 3 options would be recommended when a border (e.g., homenet to ISP) = was detected, but that at least we should document the 3 alternatives = and associated tradeoffs.=20 10:15 =96 12 Naming/Discovery Working Session (Ray and Stuart via Skype) Michael: Why the difference to sometimes mention devices, sometimes = services? FB: we might need to discover both FB: in this homenet, these should be resolvable from anywhere within the = homenet Existing Protocols DNS-SD / mDNS LLMNR RFC4795 SSDP (UPnP) SLP RFC2608 All are typically link local only Unicast DNS Anything else? RD: Multicast DNS=20 Jim: in some cases you might want to do site-local m=92cast propagation = and in some cases you might not RD: Extension to site-local addresses for multicast might be needed FB: then you might need PIM RD: the question is the group definintion Ole: This is how m=92cast works Tim: well known addresses are defined, but the scope still is not Ole: what does this have to do with discovery? Ray: we need discovery for these=20 JA: DNS could us a trick to discover some addresses only, in a m=92cast = fashion Michael; Are there bozes that work as proxied between unicast DNS and = bonjour? Ray: uncertain mDNS uses =93.local=94 Do we recommend something like a =93.site=94? Mike: you can get site local names? Ray: Names can be resolved even if they cannot be browsed. Given its = service, how to reach it, and how to operate it More namespace ??: should not IETF register .site with IANA? Ray: at the RFC yes, but this is about single-label names RD: devices at the edge might name themselves as edge.router.com JA: is this in scope? Ray: if we encourage single-labels it would help JA: Are we then suggesting a change to networks and hosts? Ray->Olafur: is it worth encouraging their obsolescence Ray: Recommendation for a single register TLD Michael: are we going to discuss wall gardens as part of this? MT: they touch everything Michael: you don=92t know the name, you don=92t know the address. One = ISP is no issue. RD: MIF is addressing this issue about DNS selection Michael: we have to make na,es resolvable Lorenzo: if two wall gardens register =93television=94 there is nothing = you can do. If they register television.ntt then you can resolve. You = cannot have these registered Michael: Trying to reduce the pain of using wall gardens AR: connection managers can solve this issue Lorenzo: Only if you control the OS Michael: but how to get the walled garden info Lorenzo: if you pay, you get it Lee: but these services are outside the home Michael: but if I have to reolve a name, should I resolve the ISP, the = NTT television, or my own television. Even if they overlap, it should be = the site local television that wins Break and off-line conclusions Lunch Jim Witt =96 Running Code presentation Why CeroWrt? Test platform for bufferfloat work Development running in OpenWRT D-link: All APs do m=92cast over unicast for 802.11, since you have to = associate anyway. DNSsec issue for time, as you need it to run time, and you need time to = run it http://Cero2.bufferbloat.net/cerowrt Lorenzo Colitti =96 Architecture Strawman Connectivity goals: No host changes No NAT anywhere Allows communication between hosts even if ISP links are down Routing goals: Automatic configuration Addresses Firewalls Support arbitrary topologies including loops Survive loss of any router for any time period Works regardless of router boot order No tree topologies like ULA External connectivity goals Support multiple uplinks and ingress filetering Support uplinks that provide partial routing Walled garden networks Reasonable startup times Architecture (possible solution) One connected network, one naming scheme Routing protocols hold together ULA is =93inside=94 the network Links not in routing protocol (e.g.. ISP with DHCPv6 PD) constitute = security boundary (figure) Two accesses (CPE), two prefixes /56 ULA /48 Prefix assignment Mesh routers from /64 from aggregates Use routing protocol collision detection Assign /64 to routed interfaces When aggregate goes away, deprecate /64 Border routers inject aggregates into mesh DHCPv6 PD Walled garden ULA aggregate for local /48 Anchored to one of the routers RD: Why can=92t we do bridging anywhere but except in special cases? L: because there are special cases MT: I mentioned bridge where you can and route where you can, but in = Quebec people oppose heavily JA: But I don=92t have ULA nor bridging and it works L: You are not a typical example Michael: Whaever routing protocol we propose will be well received by = enterprises Routing Border routers inject destinations into mesh Ech route has =93Acceptable=94 prefix Do src+dst routing (s+d, or s, or d) Security If you are a BR, you turn on the firewall Block ULA across border, etc (simple security) If you hear routing protocol on interface, join the mesh Secure protocol MD5 Hash WPA=20 (one password or two buttons is acceptable to a user) Guest networks Add attribute to TLV Indicates string as =93guest=94 Rely on routers to firewalls between realms? Or just rely on src+dst routing MT: this guest network can be the utility, or your neighbor. This is a = third case in which between two networks you share some things Naming I know nothing about naming Two possibilities Local naming anchor similar to ULA anchor, DDNS Multicast DNS, anyone who has a name answers For external, walled garden names BRs get DNS dmoani from DHCPv6 Inject into mesh, like routing aggregates RD: this is similar to what MIF is doing Michael: is the host getting connection to several DNSs? L: Yes, you have to tell the truth to the host M: once we can provide the prefix, then we can provide the address that = will provide the service L: might need to multicast L: no way to mandate source address L: do we require a authDNS? How to get the info to the host about what = DNS to use? Routing protocol Zero-config Obviously Link-state State convergence Gives clear idea of who is in a who is out Src-dst routing Necessary for multihoming AL: not easy to have one password because you have to have the same one = in all devices L: I think that if you have a password than you can do it. Lee: you can say one thing is authorized without telling =93the thing=94 = that it is authorized Michael: your model is that users need to type one password on every = box. My model is that they plug things and type only one password. If = they need more functionality, then they have to type passwords and do = more AL: random id generation Japanese activity about home router guidelines Akira Guidelines version 1 and 2 (will send URL) 13:30 =96 15:30 Architecture Working Session II Architecture Discussion-Conclusions Jari Tim Similar to Lorenzo, but no ULA Key conclusions and non-conclusions Conclusions Focus on running code plus some improvements We could do baseline version and then add improvements later Route where you had an IPv4 NAT seems acceptable Running IPv6 only requires documenting additional considerations We understand the requirements for prefix assignment in a home network M: ISPs with two gwys in v4, v6can survive. We can do things that do not = work for v4 JA: it is fine, but we should not cause v4 to break M: we have to document it MT: it is in the charter R: is suggestion to only run v6 if v4 doesn=92t work JA: it would be bad to say what to do in v4, but ok to show the problem Link state routing protocols (OSPF) seems potentially doable to solve = prefix assignment and other LLN, virtual machines, etc can participate or map their internal = mechanisms AL: if you have lossy interfaces they will not participate=20 Ole: borders across links or borders across nodes M: It will probably be OSPF M: I agree LLN, but virtual machine is a router that should be part of = the homenet JA: Agree M: how to get loop avoidance if devices have another non-homenet below? L/JA/RD: not an issue M: machines running multiple instances shown no t use multiple prefixes If multihoming support, primarily about using right source address and = avoid ingress filtering, the rest is up to hosts and applications AR: Should we not include the DNS? JA: part of the walled garden etc, yes, we should add that this is the = MIF Not happy with Simple Security Need to Discover borders JA: Not clear is labeling is sufficient MT: you cannot avoid people making errors, so we need an automatic = mechanism. Eth to ISP and Eth to PC look the same (LAN/WAN) JA: are you happy with Lorenzo scheme? MT: it should be able to advertise something in the protocol JA: there is nothing today. Is Lorenzo=92s solution enough? M: can=92t you try all optional on all ports and then find out? ??: like try a routing protocol and then decide depending on whether it = works/not? JA/MT: Lorenzo=92s proposal is good, but need to analyse if there are = border cases Jim: how about if the upstream is a shared link? Apparently this might be a problem. Need to analyse Need to do discovery and naming across subnets Non-conclusions (To Be Continued by another minute taker=85) Conclusions and Next Steps --Apple-Mail-56--824357296 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

IETF Homenet Interim Meeting

6thth
= = Mark Townsley = <townsley@cisco.com>

Area Director: Ralph Droms = <rdroms.ietf@gmail.com>
Acee Lindem = <acee.lindem@ericsson.com>

Slides at

Note Well

Agenda = Bashing


  • Tim Chown, Jari Arkko, Jason Weil, Ole Troan

    Approaches to standardizing homenets: = operational (works well for me), implementation commonality (xyz have = it), experience (we have enough experience to recommend it), = functionality (we need this feature), specification (IETF has to make = it)

    Authors are in operational = experience
    List has pushed the = envelope a little further

    JA =96 we have to present the case, understand = and then make a decision
    Ralph Droms =96 How do you see the deliverables coming out? = IETF Recommendations? In service discovery there are many options. Are = we going to pick one and bless it, or are we going to look at all and = recommend how to make them work
    Michael R =96 Are we going to look at all = flowers?
    JA- We are not here = to kill solutions. IETF normally produces specifications and people = choose. Here however we should provide a basic recommendation (naming = base).
    RD =96 most ISPs give a /64. I don=92t = want to make assumptions that this will be everywhere, as we could have = more constrained scenarios.
    JA =96 good example. If we want to support multiple networks = behind a /64 we might get in trouble.
    Jim Witt =96 this is a deployment case today, = but should not be like this.
    JA =96 They provide this today but they are working hard to = provide more in the future.
    MT =96 I have not seen a recommendation for /64 at home. = Probably there is a 3gpp for handset.

    Jim =96 This is a place where running code should = speak.
    JA =96 I meant this = by conservative
    Lorenzo =96 Running = code today does not do this.
    MT =96 there is, but you cannot get them off-the-shelf. In = my company we decided to put 6204
    JA =96 it is reasonable to specify what should = be done
    Jim =96 Development goes in upstream OAM projects and often = code is 5 years old, e.g. linux kernels
    MT =96 Some companies do it = differently. We do it and Apple does it too
    Lorenzo =96 are you suggesting write = code and feed it in the upstream
    Jim =96 Yes

    Michael =96 you can have =93orange and blue=94 versions for = specific problems
    Jim =96 badly home = boxes create these problems. Cheap boxes use open source codes. If we = can create this code then =93hopefully=94 the small guys will pick it = up
    Michael =96 As ISP, = we often replace the box at the users=92 premises by a less costly box = that actually works.

    Things that exist
    Things that are there but not = used
    Things that need to = be written
    Possible = recommendations (2 slides):
    What I have: Run local DNS servers=85
    What I should do: Prefix Distribution = from ISP, Simple security 6092

    You can only solve this if your support VM =

    Basic Network = Architecture

    Network Topology

    Multihoming
    Mainly a problem for the host
    The home should support multiple = exist routers, and should let the host know which one to = use
    JA  - 484 = ingress rules we can rely on
    Michel =96 tow home network

    Alex  R =96 So are we considewring the = Femto case out of scope?
    Lorenzo =96 the netorks cannot deal with end to end. This is = a role of the host
    Fred Baker- I don=92t agree, you can use 6296 (nat66) and = maintain connectivity.
    Lorenzo =96 how about applications that carry IP address in = payload?

    Jason Livingston = 4191

    Principles =96 Assumptions (Tim = Presenting now)
    Dual stack (of course = IPv6-nly too)
    Transition tools are covered = elsewhere
    RD =96 We don=92t = want to rule out the case when you have a NAT (even if connected by = mistake)
    AL =96 Do you want to = do NAT64 in home or at provider?

    JA - We will not address transistion and will not overlap = with other groups. We can however have IPv6 only recommendations for = home networks that mention what other should be used or = not.

    Lorenzo =96 Are we taking a versioned = approach?
    JA - Not saying that = we cannot solve everything. WE ahave to carefully think what we can do o =
    Lorenzo =96 What = users are going to find useful

    MT =96 for a Linksys discovering if you are = connected to another Linksys or to the internet
    It would be interesting (e..g do I = turn on Firewall, NAT or not?)

    MT =96 CEA, BBF, = DLNA, 802 (service discovery)

    (presentation) We = should allow for different practices on the ISP side
    • Static/dynamic prefix = delegation?

    Intelligent policy
    • Do not hardcode = addresses or security policies =96 problem with security and = prefixes


    What about ULAs with = the use of NATs?


Ole =96 Are we = considering a homenet without an ISP?
RD =96 You can setup ULA without ISP and then = as soon as you get ISP you disable ULA
MT =96 I don=92t agree, ULA could still = work
Alex =96 how about = DHCP
Michael =96 Similar = to ULA
Lorenzo- your = printing job will be stopped when your DSL comes back=85 not = good


We have identified advantages but there are = drawbacks

MT =96 if v6 can detect if this is a = WAN or LAN port
??? (black shirt) =96 this may not be = possible due to chipsets in the market
Michael =96 in cheap boxes this is mainly in = SW
Jim =96 today = chipsets do VLAN and many other things.

Existing protocols are subnet scoped (mDNS, = LLMR, DNS-SD)



Erik Nordmark (remote) =96 ??
MT =96 ??
EN =96 Can you construct loops that = break v4?
MT =96 We need to = understand how complex the solution is if we want to handle loops and = then decide if we want to address this problem or not


Lunch
13:15 - 15:15 - = Prefix Configuration Working Session (Ole Troan)



MANET and RPL

MT =96 Defection of boundary affects PA distribution and = many other things (blue and red cables)

Arbitrary Topology =96 Must (for real cases) = Nice (for pathological cases)
Multiple sources =96 Must (support for more than one ISP, = Femto, etc)
JA =96 resilient to crashes, reboots and lease = expiry

Jim =96 Stable addresses are not = meaningful. Name stability is a critical


Multilink subnet routing

Are we ok supporting /64 only?
MT =96 Erik and Ole should analyse if = this is valid without host changes
Jason =96 we are safe assuming multiple subnets = and more than /64
Lorenzo =96 current HW would override old PA and would = assign the new one



RD =96 You can assume that routers = will not assign orefixes on links that already have
FB =96 multiple routers on the same = link
JA =96 there is a = fundamental question whether resources are taken from a pool, or a = distributed algorithm chooses resources not being used

Zeroconfig OSPF
Lorenzo, AL - Allows border = discovery, could help passing key information
JA =96 only OSPF?
MT =96 you could make it work in = other protocols
Lorenzo =96 By widely delyed we mean open implementation = that has been accepted.


Jim - OLSR is of use, as there are mesh = wireless deployments in Europe using these WiFi.net. The battlenets run one vs the = other

Ole =96 Question is de we overlay = routing protocol and prefix assignment?
LC =96 link state is very = useful.
LC =96 how difficult = is zeroconfig with OSPF?
AL =96 not much
JA =96 can we have one sngle thing that does all for = you?
MT =96 this would = make it easier to implement
JA =96 still you have to define extensions and = options


Break

15:45 - 17:30 - Routing Working Session (Fred = Baker)

  • Some link layers have special requirements = (e,g, 802.15.4)
    Analysis documents = (IPv4 examples)
    Use = cases
    • Single router = (simplest)
    • Multiple routers = (needs to be addressed in case user adds them even without = realizing)
    • Multipath networks =
      • Not great for RIP
      • Jim/Fred: we all have built this
        • Multiple = UL
        • If you assume BCP 38: RFC 3704 :fix = problem of packets on wrong router
        • FB: source-based routing would wolve this. You can change = the routing at the host, or you can re-send the packet
          Lorenzo: do you assume = IGP?
          FB: You need to solve = the problem when you have OSPF lifetime of ~45 min. You can detect loss = in 40 sec, which is much better than 45 min. In case of router failure, = the best would be for the remaining router to advertise RA with zero = lifetime
          JA: there are other = requirements for multihoming: utility devices require a specific ISP, = IPTv from one ISP and Internet from another.
          Lorenzo: We might need to do source = address routing
          Michael: we need to = support the case when one ISP goes down
          ?? (squared shirt): E911 needs to be = handled




          MT: we are back to = 3484 and Japan problem
          FB: the argument tells me that we want to stay away from RIP = and get closer to OSPF/IS-IS

          AL/Jim/Lee: the issue = with the footprint of the code depends on the vendor and business case. = However, the code would eventually would need to be made = available
          Proactive vs = reactive
          RIP, OSPF, IS-IS vs = AODV and RPL (useful when routes change and appropriate for 802.15.4 = networks)
          FB: Today, I would recommend RIPng, = OSPF and RPL
          Jim: why are the = wireless use OLSR
          Lorenzo: if we wna = tto be compatible with PA we need to support a protocol with = TLV
          FB: Then = IS-IS?
          AL: You could do it = with OSPF if the information is different to the existing = one

          Lee: so do we need a dynamic routing = protocol?
          Lee: 30 mint = acceptable, but 3 probably. I don=92t know if we need to go to the = seconds
          RD: If you don=92t = want the full dynamic protocol we have to compare to a DHCPv6 and small = protocol, in which case probably the size is not much = different

          JA: I=92m ok with supporting OSPF and PA = distribution. I=92m not sure I=92m ok with all the multihoming = requirements
          MT: If you don=92t = care about these, then what would wyou care
          Lorenzo: In v4 no issue, but with v6 = this is and will be an issue



          09:00 doors open
          09:30 - 12:00 - Architecture Working = Session (Timm Chown, Jari Arkko)
          12:00 - 13:15 - Lunch


          (ISP issues)

          9:40 =96 10:15 = Security (Mark)
          Mark = Townsley
          Automatic Border = Detection is essential
          • For service = discovery
          • For prefix assignment = and routing
          • For = security
            • Default filters = (ULAs?)
            • Mike: Smart grid borders?
              FB: Utility might want you to use = RPL
              RD: Smart grid is an = application
              MT: A link between = two routers need to be identified.
              • Home-Utility = network

              Japanese TV still a different animal
              MT: We might want to give some naming = to these borders
              Detect incpming = packets.
              • Allow incoming conections from your = home
              • Allow incoming connections from = internet

              Providing borders with ULAs we can define = this
              =93Local=94 security = boundary defined by:
              • ULAs
              • Prefix pushed down by = R
              • Magic?

              Jim: state has to be distributed in = case there are multiple routers
              Mike: LAN party? With smartphones today people = can roam to your home LAN and get access to your content (e.g. = photos)?
              Mike: RAs will have = to carry the ULAs
              James W: Some = applications make sure that they are talking to a link local address. =
              Lorenzo: Today with = v4 we cannot limit access to link local
              Sqare???: xbox would do application = level discovery
              Advanced = Security
              Lee: statefull = firewall
              JA: you might need to standardize the = format to configure
              James Woodward: Is security needed if it doesn=92t = work
              Lee: existing = mechanisms are insufficient, however, they are useful
              JA: we are defining how to transport = magic, not the magic itself
              MT: even if we define the content, it still has a place in = the architecture definition

              Lee; are we discussing whether we need Advanced seciruty or = whether it is in scope difining it?
              MT: We agreed that we need to detect borders in = general. We might need to define how the borders communicate their = existence to neighbours with the protocols.

              (*** MT to check this wording and perhaps = expand)
              (Inserted by MT):

              I believe we agreed that the homenet arch document would = outline 3 possibilities:


              2. Simple Security

              3. Advanced Security

              There was little hope that the group would come = to consensus on which of the 3 options would be recommended when a = border (e.g., homenet to ISP) was detected, but that at least we should = document the 3 alternatives and associated tradeoffs.


              10:15 =96 12 Naming/Discovery Working Session (Ray and = Stuart via Skype)


              Michael: Why the difference to sometimes = mention devices, sometimes services?
              FB: we might need to discover = both

              FB: in this homenet, these should be = resolvable from anywhere within the homenet

              Existing Protocols
              • LLMNR = RFC4795
              • SSDP (UPnP)
              • All are typically link local only
                • Anything = else?

                RD: Multicast DNS =
                Jim: in some cases = you might want to do site-local m=92cast propagation and in some cases = you might not
                FB: then you might = need PIM
                Ole: This is how m=92cast = works
                Tim: well known = addresses are defined, but the scope still is not
                Ole: what does this have to do with = discovery?
                JA: DNS could us a trick to discover some = addresses only, in a m=92cast fashion
                Michael; Are there bozes that work as proxied = between unicast DNS and bonjour?
                Ray: uncertain

                mDNS uses  =93.local=94
                Do we recommend something like a = =93.site=94?
                Mike: you can get = site local names?

                More namespace

                ??: should not IETF register .site with = IANA?
                Ray: at the RFC yes, = but this is about single-label names

                RD: devices at the edge might name themselves as edge.router.com

                JA: is this in scope?

                Ray: if we encourage single-labels it would = help

                JA: Are we then suggesting a change = to networks and hosts?


                Michael: are we going to discuss wall gardens = as part of this?

                Michael: we have to make na,es = resolvable
                Michael: Trying to reduce the pain of = using wall gardens
                AR: connection managers can solve this issue
                Lorenzo: Only if you control the = OS
                Michael: but how to = get the walled garden info
                Lorenzo: if you pay, you get it
                Lee: but these services are outside = the home
                Michael: but if I = have to reolve a name, should I resolve the ISP, the NTT television, or = my own television. Even if they overlap, it should be the site local = television that wins





                Jim Witt =96 Running Code presentation

                Why CeroWrt?

                Test platform for bufferfloat work

                Development running in OpenWRT

                D-link: All APs do m=92cast over unicast for = 802.11, since you have to associate anyway.

                DNSsec issue for time, as you need it to run = time, and you need time to run it

                http://Cero2.bufferbloat.net= /cerowrt


                Lorenzo Colitti =96 Architecture Strawman

                Connectivity goals:
                • No NAT = anywhere
                • Allows communication between hosts = even if ISP links are down


                Routing goals:
                • Automatic = configuration
                  • Firewalls

                • External connectivity goals
                  • Reasonable startup = times

                  Architecture = (possible solution)
                  • One connected = network, one naming scheme
                  • Routing protocols = hold together
                  • ULA is =93inside=94 = the network
                  • Links not in routing = protocol (e.g.. ISP with DHCPv6 PD) constitute security = boundary

                  (figure)
                  • Two accesses (CPE), = two prefixes /56
                  • ULA = /48

                  Prefix = assignment
                  • Mesh routers from /64 = from aggregates
                    • Use routing protocol = collision detection
                    • Assign /64 to routed = interfaces
                    • When aggregate goes away, deprecate = /64
                  • Border routers inject aggregates into = mesh
                    • DHCPv6 PD
                    • ULA aggregate for = local /48
                      • Anchored to one of = the routers


                    L: because there are = special cases
                    JA: But I don=92t have ULA nor bridging and it = works
                    L: You are not a = typical example
                    Michael: Whaever = routing protocol we propose will be well received by = enterprises
                    Routing

                    • Security
                      • If you are a BR, you = turn on the firewall
                        • Block ULA across = border, etc (simple security)
                      • Secure protocol = MD5
                        • Hash WPA =

                    (one password or two buttons is acceptable to a = user)

                    Guest networks
                    • Indicates string as = =93guest=94
                  • Rely on routers to = firewalls between realms?
                    • Or just rely on = src+dst routing

                  MT: this guest network can be the utility, or your neighbor. = This is a third case in which between two networks you share some = things

                  Naming
                  • Two = possibilities
                    • Local naming anchor = similar to ULA anchor, DDNS
                    • Multicast DNS, anyone = who has a name answers
                  • For external, walled = garden names
                    • BRs get DNS dmoani = from DHCPv6
                    • Inject into mesh, like routing = aggregates

                  RD: this is similar to what MIF is doing
                  Michael: is the host getting = connection to several DNSs?
                  L: Yes, you have to tell the truth to the = host
                  M: once we can = provide the prefix, then we can provide the address that will provide = the service
                  L: no way to mandate source address
                  L: do we require a authDNS? How to = get the info to the host about what DNS to use?

                  Routing protocol
                  • State = convergence
                  • Gives clear idea of who is in a who = is out
                • Src-dst = routing
                  • Necessary for = multihoming


                L: I think that if you have a password than you can do = it.
                Lee: you can say one = thing is authorized without telling =93the thing=94 that it is = authorized
                AL: random id = generation
                Japanese activity = about home router guidelines
                Akira
                Guidelines version 1 = and 2 (will send URL)


                Architecture = Discussion-Conclusions
                Jari Tim


                Key conclusions and non-conclusions

                Conclusions
                • Route where you had an IPv4 NAT seems = acceptable
                • Running IPv6 only = requires documenting additional considerations
                • M: we have to document = it
                  MT: it is in the = charter
                  JA: it would be bad to say what to do = in v4, but ok to show the problem
                  • Link state routing = protocols (OSPF) seems potentially doable to solve prefix assignment and = other
                  • LLN, virtual machines, etc can = participate or map their internal mechanisms

                  AL: if you have lossy interfaces they = will not participate
                  Ole: borders across links or borders across = nodes
                  M: It will probably = be OSPF
                  M: how to get loop = avoidance if devices have another non-homenet below?
                  L/JA/RD: not an issue
                  M: machines running multiple = instances shown no t use multiple prefixes

                  • JA: part of the walled garden etc, yes, we = should add that this is the MIF
                    • Not happy with Simple = Security
                    • Need to Discover = borders

                    MT: you cannot avoid people making = errors, so we need an automatic mechanism. Eth to ISP and Eth to PC look = the same (LAN/WAN)
                    JA: are you happy with Lorenzo scheme?
                    MT: it should be able to advertise = something in the protocol
                    JA: there is nothing today. Is Lorenzo=92s solution = enough?
                    ??: like try a = routing protocol and then decide depending on whether it = works/not?
                    Jim: how about if the = upstream is a shared link?


                    • Need to do discovery = and naming across subnets


                    Non-conclusions



                    Conclusions and Next Steps


                    = --Apple-Mail-56--824357296-- From townsley@cisco.com Tue Oct 18 08:36:37 2011 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 0609721F8678 for ; Tue, 18 Oct 2011 08:36:37 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNs0nPUgBWG7 for ; Tue, 18 Oct 2011 08:36:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D8BD721F86A5 for ; Tue, 18 Oct 2011 08:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=4610; q=dns/txt; s=iport; t=1318952195; x=1320161795; h=from:subject:date:references:to:message-id:mime-version; bh=RJ8LeV7VY6Z9usYRXWWn3PGz/qi2FVEJ2rFmU8aNN+E=; b=it9NuX7YxRRn08acncOkM57qhBXG/K9z6zA+26rtkjBGlO3oG5nyfs/u MRrPXNgl7UlppVr8Q90NKYe1sL+kJwFVxkfjN04xMkb5QHQeR+pJsO3Lj 0mZgE3inj8ZJ5vpHU1cWPQTqaYtp7LHYTzmoCf7YHX/GlqDqGQ9/7e1KA Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHycnU6Q/khN/2dsb2JhbABEqG6BBYFuAQEBAwESAV8MCw8RMVcGEyKHXpg/AZ57hzphBJN9kVg X-IronPort-AV: E=Sophos;i="4.69,365,1315180800"; d="scan'208,217";a="58037912" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 Oct 2011 15:36:27 +0000 Received: from ams-townsley-8716.cisco.com (ams-townsley-8716.cisco.com [10.55.233.231]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9IFaRBq005055 for ; Tue, 18 Oct 2011 15:36:27 GMT From: Mark Townsley Content-Type: multipart/alternative; boundary=Apple-Mail-62--804912896 Date: Tue, 18 Oct 2011 17:36:26 +0200 References: <10341.1318949537@marajade.sandelman.ca> To: "homenet@ietf.org Group" Message-Id: <6969836E-994B-42E5-B5EF-B8E9EC81B316@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [homenet] More notes from the interim... 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, 18 Oct 2011 15:36:37 -0000 --Apple-Mail-62--804912896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks to Michael Richardson for picking up where Juan Carlos left off = with the notes... I think we have forwarded all we received. If anyone else took notes, = please feel free to send them to the list. Thanks, - Mark & Ray > From: >=20 >=20 >=20 > security: we need to come up with a nomenclature for the different > kinds of borders. >=20 > instead of ISP/SmartGrid. > Lets talk about home being a customer of some number of networks. > In each case we have a border. >=20 > Network:Upstream >=20 > What abount apartment buildings where the north interface might be = shared > across many tenants? > Also what about university residents. >=20 > Jari Key Non-Conclusions > NOTE: we need End to End Security (MUST) > Simple Security (MAY) > Advanced Security (MAY) >=20 > Recap of name discovery vs boundary system. >=20 > What do we know about the problems of using ULA? > We either make ULAs work or rip them out of 6204. >=20 > What is the relationship between the Multicast and Unicast, do the > information passed between, and is there a cache for dozy/sleepy = devices. >=20 > How do local names that want to be in the global name space, get > pushed up. Could this be zeroconf in a vendor's ".net" space (e.g. = ".mac") >=20 > Yari's take-2 slide, discussion softened some of recommendation, > particularly Simple and Local DNS. >=20 >=20 > DTCP - television transmission. >=20 >=20 >=20 >=20 >=20 --Apple-Mail-62--804912896 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
                    =



                    security: we need = to come up with a nomenclature for the different
                    =          kinds of = borders.

                    instead of ISP/SmartGrid.
                    Lets talk about home being = a customer of some number of networks.
                    In each case we have a = border.

                    Network:Upstream

                    What abount apartment buildings = where the north interface might be shared
                    across many = tenants?
                    Also what about university residents.

                    Jari Key = Non-Conclusions
                    NOTE: we need End to End Security =       (MUST)
                    =             &n= bsp;Simple Security =           (MAY)
                    =             &n= bsp;Advanced Security =         (MAY)

                    Recap of = name discovery vs boundary system.

                    What do we know about the = problems of using ULA?
                    We either make ULAs work or rip them out of = 6204.

                    What is the relationship between the Multicast and Unicast, = do the
                    information passed between, and is there a cache for = dozy/sleepy devices.

                    How do local names that want to be in the = global name space, get
                    pushed up.  Could this be zeroconf in a = vendor's ".net" space (e.g. ".mac")

                    Yari's take-2 slide, = discussion softened some of recommendation,
                    =       particularly Simple and Local = DNS.


                    DTCP - television = transmission.






                    <= /html>= --Apple-Mail-62--804912896-- From mcr@sandelman.ca Tue Oct 18 20:20:40 2011 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 C8A0F11E8073 for ; Tue, 18 Oct 2011 20:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA3d0RzgorS9 for ; Tue, 18 Oct 2011 20:20:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 032251F0C49 for ; Tue, 18 Oct 2011 20:20:37 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 66C0F3418E; Tue, 18 Oct 2011 23:19:26 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id D178D98B2E; Tue, 18 Oct 2011 23:21:29 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C4C4D980D6; Tue, 18 Oct 2011 23:21:29 -0400 (EDT) From: Michael Richardson To: curtis@occnc.com In-Reply-To: <201110132302.p9DN2Wgi037732@gateway.ipv6.occnc.com> References: <201110132302.p9DN2Wgi037732@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 18 Oct 2011 23:21:29 -0400 Message-ID: <28269.1318994489@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org, Ted Lemon Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 19 Oct 2011 03:20:40 -0000 >>>>> "Curtis" == Curtis Villamizar writes: Curtis> A WiFi AP will not connect to another AP and wireless Curtis> routers are typically AP by default. So if two wireless Curtis> routers autoconfig to being AP and using open routing, then OUT OF THE BOX: not every device plugged into a home network have no prior configuration. For instance, someone bringing a newsed device to grandma's house. Curtis> there is only a risk if something that is an WiFi client is Curtis> also a configured to be a router. laptop, smartphone, wii, stereo mp3 player, ... -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From ot@cisco.com Wed Oct 19 00:44:01 2011 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 BF33021F8AFB for ; Wed, 19 Oct 2011 00:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=2.850, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzNoqsQ24ouK for ; Wed, 19 Oct 2011 00:44:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B490521F8564 for ; Wed, 19 Oct 2011 00:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=970; q=dns/txt; s=iport; t=1319010239; x=1320219839; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=AGzuSYUDe3Ba4we8ouBeCui2PSMWES1VZa6bcJeMZ/s=; b=GVVEZhI99RQqU1ck+PjcIs8w3uoHkX0uFivXD1jr3kB8rSRit7wktaT4 6CzZo2mWSQBbgRX3PsUZg/DjvtbVJCLPIcEdDPBX8cymT8D1DuW/Q5s0X 5Iqaz7OQhWOtQi3wT++POnTNCkzrCO9LfDiIDHavbvENLpwavznR2dqAI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHt/nk6Q/khN/2dsb2JhbABEqHKBBYFuAQEBAwESAScwDwULC0ZXBjWHXpZIAZ4whzphBJN+kVk X-IronPort-AV: E=Sophos;i="4.69,370,1315180800"; d="scan'208";a="119454849" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2011 07:43:58 +0000 Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com [64.103.53.235]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9J7hxXE027612; Wed, 19 Oct 2011 07:43:59 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E9AB641.7050201@gmail.com> Date: Wed, 19 Oct 2011 09:43:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> To: =?iso-8859-1?Q?David_T=E4ht?= X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 19 Oct 2011 07:44:01 -0000 > However, overall trends on this list are discouraging. >=20 > 1) Getting IPv6 working well inside the home is a hard problem! It = helps > to actually try to make something work, to see the relevant details. = I'd > like it very much if at an upcomin >=20 > I've built 3 such networks, and am in the process of building several > more - as well as making available code on a cheap, 120 dollar, = platform > to make it possible to actually go and set one up yourself to play = with, > so the more devilish, detailed problems become apparent. I've done my > best to make sure 6to4, at least, works right out of the box. Native = (no > PD yet!) works pretty well, too - but getting the 6to4/ipv6 native to > co-exist better is going to take slightly more work. you aren't helping things work better by doing 6to4. please disabled by default, if you absolutely want to support it at all, = hide it somewhere under the Wizard menus. cheers, Ole= From russw@riw.us Wed Oct 19 04:48:22 2011 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 5CC5F21F8A62 for ; Wed, 19 Oct 2011 04:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phOvqR5v6irD for ; Wed, 19 Oct 2011 04:48:21 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5A321F8B24 for ; Wed, 19 Oct 2011 04:48:21 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:61992 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RGUdA-0003Qk-Cy for homenet@ietf.org; Wed, 19 Oct 2011 07:48:20 -0400 Message-ID: <4E9EB8FD.2060306@riw.us> Date: Wed, 19 Oct 2011 07:48:13 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201110171821.p9HILtKr048064@gateway.ipv6.occnc.com> In-Reply-To: <201110171821.p9HILtKr048064@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing 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, 19 Oct 2011 11:48:22 -0000 > 1. No built in assumptions about whether a router has an uplink port > and if so, which port it is. > d. assumptions about uplinks may be learned (zero config) or > configured. The biggest problem with determining what's an "uplink" and what's not is simply what the word "uplink" actually means. One of the things we've been thinking about here is "walled gardens," networks which serve a special purpose, and hence don't have connectivity to the "world at large." There are probably only two solutions here: 1. The provider's device needs to tell you this information. 2. You need a set of "magic destinations," that the internal devices can use to orient themselves to the network topology around them. > We have to get rid of long lease times. If a connection goes up, its The problem here is that you're working against the rest of the world, which assumes an IP address is pretty much a permanent feature of a device, like a MAC address. I don't know how to change that mentality. > #4. security > > a. No filtering should be done on a link that is not identified as > an uplink. As long as you're okay with multiple layered devices each filtering on their uplinks (not necessarily a bad thing, by the way). I tend to think more in terms of domains, which included possible vertical divides as well as horizontal ones. > b. By default strong filtering should be enabled on any uplink. > > c. Filtering can be weakenned, holes punched through, or disabled > by configuration. Agreed. > a. DV and LS routing can mixed within a domain. DV routes can be In fact, OSPF already does this... What I hate is this entire idea of "redistribution." A single protocol that does both DV and LS in the right places would be ideal --but I also think the existing DV protocols can be modified to provide this sort of thing. > For (a) we should recommend one. OSPF is full standard and is cleaner > but we have v2 for IPv4 and v3 for IPv6. ISIS has NSAPs as router ID > (even uglier than IPv6 addresses or MACs and must be unique), sends > around really big packets even for small changes, but supports both > IPv4 and IPv6 in one instance and is (strongly) prefered by some. I would argue that the router ID situation in IS-IS is actually easier to deal with than the one in OSPF. With fragmented LSPs, I don't think the packet size in IS-IS is any worse than OSPF, either (?). :-) Russ From pthubert@cisco.com Wed Oct 19 06:04:11 2011 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 953B221F8BF7 for ; Wed, 19 Oct 2011 06:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.233 X-Spam-Level: X-Spam-Status: No, score=-8.233 tagged_above=-999 required=5 tests=[AWL=2.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+nuaqYXoRjA for ; Wed, 19 Oct 2011 06:04:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1362B21F8BB7 for ; Wed, 19 Oct 2011 06:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=5621; q=dns/txt; s=iport; t=1319029450; x=1320239050; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HUBnK7eTzgeX+BfWyP2z4Fpb94vid3gWs96B3nKldmw=; b=Z6NEbbEt0EgI9gd3d4y+bqK+8uJoySNgr5XJhEDTdl2MGU3oaxwWyXFt 9YWAiU+HFB562DCUaytRzB0/PRYIn7tMh0iZhJvTNPl9Mhzp51AyjtQOf amQa9tz6Co2xETRoTQdfnvgIaYxBQrgkP2ywcwLtTSOjGXEKQPhJQaqP0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALrJnk6Q/khR/2dsb2JhbABEqHSBBYFuAQEBBBIBHVkCAQgiBhgGAVYBAQQBGhqHZpVaAZ5KhzphBIdSkV+MJg X-IronPort-AV: E=Sophos;i="4.69,372,1315180800"; d="scan'208";a="58111118" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 19 Oct 2011 13:04:06 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9JD46eV027063; Wed, 19 Oct 2011 13:04:06 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 15:04:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2011 15:01:23 +0200 Message-ID: In-Reply-To: <4E9AB641.7050201@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] Thoughts about ipv6 routing (babel & AHCP) Thread-Index: AcyL8RL9F84Hrr3ASGCebcb7kF9OjQCXx8TA References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com><4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?David_T=E4ht?= , X-OriginalArrivalTime: 19 Oct 2011 13:04:06.0007 (UTC) FILETIME=[9504F870:01CC8E5F] Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 19 Oct 2011 13:04:11 -0000 Hello David [David>] Now, in reviewing this thread, I was disappointed to see that = my ipv6 routing protocol of choice (babel) has not been discussed so far = to any extent. While this protocol is somewhat new, an rfc and working = code both exist, and working code has existed for several years. [Pascal >] I can only confirm from almost 10 years of implementing and = experimenting the principles used in Babel that they are very sound (I = started using them with nested networks of mobile routers, see = http://tools.ietf.org/html/draft-thubert-tree-discovery ) And if you look at it, you'll find that BABEL builds its routing tree = towards a destination using the same base principles as RPL builds its = DODAG towards its root, DV operations with the same feasibility = conditions and sequenced updates. After that RPL provides a number of optimizations: - RPL recognizes that most traffic goes through a limited number of = gateways and only builds DODAGs off these gateways. This fits the = classical wiring in a house, which is mostly hub/spoke and in any case a = tree, simply because that's what electricians learn at school. From = there, the default route can be heavily used, which saves states and = more importantly states updates.=20 - RPL has triggered updates dampening for large / dense configs (based = on trickle); you'll note that there is no global triggered update (RPL = looks more like DSDV than BABEL for that matter), only local. These = local updates allow quick local repairs that avoid impacting the whole = network when the use plays with the wireless settings in its stereo = gear. - RPL has tunable elasticity on the feasibility conditions, which, when = used, may create loops. This is compensated by an in-band packet = validation. This adaptation is specialized for operations such as WSN = where there are very few packets and battery conservation is critical, = which is true for home automation, and can be turned off for more = classical operations. - RPL has another inheritance from DUAL which allows poisoning a = sub-DODAG by detaching it and then later reattaching it to the main = DODAG. The shape of the sub DODAG can be retained and routing is = maintained within, a feature that users might appreciate should a home = gateway reboot, which in my experience happens quite often. - With RPL, all routing inside the DODAG that is built for a given root = (gateway, backbone router) exploits the DODAG topology so there is only = one topology to maintain for all nodes in the DODAG as opposed to one = topology per destination. Routing might be stretched as packets have to = go up to the common parent and then down, but this allows a heavy = utilization of the default route which in turn saves states maintenance = and improves mobility. Users actually wear devices, move through the = house, and expect that we maintain enough connectivity to stream media.=20 - Instead of having different topologies per destination, RPL allows = multiple instances that build their own topologies for their goals and = constraints, and enables routing along those topologies. This solves in = particular the walled garden problem we already discussed in this list, = for instance for routing Utility packets from/to the Utility gateway = which happens naturally if the utility packets are placed onto the RPL = topology that is associated to the Utility.=20 - RPL is partially autonomic, in that it distributes its own = configuration as the DODAG builds off the root. If configuration is = required to indicate a certain optimization, then that configuration can = be pushed by the service provider onto the gateway, and it will be = passed on by the protocol. But I'd think that being autonomic is quite = critical. Interestingly, there's also intense research around that = subject in Europe, see for instance AFI at ETSI. - RPL is designed for multilink subnets, and in particular it = distributes the information that routers will need of they need to form = RAs, though the exact operation for doing it was taken off the spec. = MLSN is quite useful to avoid renumbering devices that move inside the = house, and it is seen as a MUST in industrial environments. - RPL is designed to be complemented by a task-specific plug-in called = objective function, which understands and adapts the operations to the = metrics and constraints. Built-in OFs are quite abstract because they = are very generic, but this group and others are free to define their own = OF to map their needs.=20 I have yet to understand which of the points above are required as = opposed to nice-to-have for the HOMENET as the groups sees it. [David>] The future inside the home is mostly wireless, not wired... = and as many of the assumptions built into ipv6, dhcp, dhcpv6, ra = announcements, etc completely predate the rise of wireless everywhere, = they tend to be, well... wrong. [Pascal >] I agree, with a twist that IPv6 is provenly quite capable to = adapt and survive. The work at 6LoWPAN on ND is ample demonstration of = that, isn't it? HOMENET might be a good place to evangelize that kind of = work and promote implementation in the major stacks. The most difficult = piece may be to change the mental image that we have of a network, from = a set of well managed wires to probabilistic connectivity, with = unpredictable interferences, movements, per-packet propagation = behaviors, and hard constraints like energy savings and bandwidth = limitations. Cheers, Pascal From gettysjim@gmail.com Wed Oct 19 06:34:30 2011 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 B265221F8AFE for ; Wed, 19 Oct 2011 06:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOzy05V8DJBb for ; Wed, 19 Oct 2011 06:34:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4D221F8AF9 for ; Wed, 19 Oct 2011 06:34:30 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1835251vcb.31 for ; Wed, 19 Oct 2011 06:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9DVsM1R264khNNB6r8djQ7E203iAKM72LUJvutd+ous=; b=cG/vY3fQs8b4hnBj8cabD5j/t/GJBCIfL+fmu+WEy0wdl4Gxp++9vPFsElgO/s7Gzn VIFY55KDQoSIbhnXzOAt2VVp7ckOlmJ+1EgeJFe8zyTaNmRM1JN5p9UWAnAYEn0LDIDf aQ4nMZIfRdVVnAO/RmS/YJKwpZJMjSCA7sg7E= Received: by 10.52.76.162 with SMTP id l2mr6191037vdw.64.1319031269563; Wed, 19 Oct 2011 06:34:29 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ja7sm5467837vdb.16.2011.10.19.06.34.26 (version=SSLv3 cipher=OTHER); Wed, 19 Oct 2011 06:34:27 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E9ED1E2.1040107@freedesktop.org> Date: Wed, 19 Oct 2011 09:34:26 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Ole Troan References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, =?ISO-8859-1?Q?David_T=E4ht?= Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 19 Oct 2011 13:34:30 -0000 On 10/19/2011 03:43 AM, Ole Troan wrote: > you aren't helping things work better by doing 6to4. > please disabled by default, if you absolutely want to support it at all, hide it somewhere under the Wizard menus. > > Actually, 6to4 works really well on Comcast since they installed production 6to4 relays that are geographically dispersed. Whether 6to4 should be on by default, given the lack of decent relays in many parts of the world is a different question we can discuss. I don't think hiding it entirely is a good idea, given that this is the largest ISP in the U.S. (world?). This is, of course soluble by ISP's; not having much IPv6 traffic is a self fulfilling prophesy if it doesn't get tested, and it won't get tested unless there is traffic, etc.... And without relays, 6to4 sucks, and so on... - Jim From curtis@occnc.com Wed Oct 19 12:31:00 2011 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 3AA5A21F84E5 for ; Wed, 19 Oct 2011 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiRS6buU0x+t for ; Wed, 19 Oct 2011 12:30:59 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 681F421F84DD for ; Wed, 19 Oct 2011 12:30:58 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9JJUajI047902; Wed, 19 Oct 2011 12:30:36 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9JJUajI047902 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319052639; bh=YsqMlIphgLdHelU9jRvo/vuEks2j4NpBLCyw3i2NjQI=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=EQMraSC+6SYx5fuFUwCeJjPMsYnqDmLnzB8HBCetAutAVPknCQKtrxpfpQYCmhwb/ 8Tg4bWyvjNl1GAvN0OLhTRXoMiHAFcImNdXHrwb1rbR9vemRAkfiBEEpf28btGBdnf 0RxacvIrgNXejNio+uPOXY6VyhnOrVGFpdo40SRY= Message-Id: <201110191930.p9JJUajI047902@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 18 Oct 2011 23:21:29 EDT." <28269.1318994489@marajade.sandelman.ca> Date: Wed, 19 Oct 2011 12:30:36 -0700 Cc: homenet@ietf.org, Ted Lemon , curtis@occnc.com Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:31:00 -0000 In message <28269.1318994489@marajade.sandelman.ca> Michael Richardson writes: > > >>>>> "Curtis" == Curtis Villamizar writes: > Curtis> A WiFi AP will not connect to another AP and wireless > Curtis> routers are typically AP by default. So if two wireless > Curtis> routers autoconfig to being AP and using open routing, then > > OUT OF THE BOX: not every device plugged into a home network have > no prior configuration. For instance, someone bringing a newsed > device to grandma's house. He who configures it needs to fix it. Or press the factory default button (if there is one). The example is two AP. Most AP can be restored to factory default with a button press. Grandma may toss it or call in a geek before figuring out some of the hidden "restore to factory default" procedures like the unmarked "press, hold, and power cylce while holding" trick. This is sort of like the old BIOS that had "secret" ways to get in, different across vendors. They now have a very clear "to enter BIOS do this" to avoid those support calls. > Curtis> there is only a risk if something that is an WiFi client is > Curtis> also a configured to be a router. > > laptop, smartphone, wii, stereo mp3 player, ... I don't have any windows systems or wii on hand (what's the plural of wii, wiii?). And my portable mp3 is (*really old* and only used occasionally on an airplane and ..) USB only. But ... On BSD and I suspect Linux as well, the default for: net.inet.ip.forwarding net.inet6.ip6.forwarding are both zero. A router forwards IP traffic. By default no routing protocols are enabled on a host such as a BSD or Linux system. Even if enabled, a host may run a routing protocol but not forward packets not destined to itself from one interface to another. I would be surprised if any of the devices you have listed above have forwarding enabled by default today, except a smartphone which has been configured to act as a WiFi hub (which itself is not a default). If we define the zeroconf defaults well, then it would be OK if they all forward. As I pointed out in a prior email, the best routing protocol for wired and the best for wireless may not be the same. There will be legacy stuff and we can be compatible with it. We can't work in any arbitrarily misconfigured legacy environment, because you can already make that not work without adding anything. Even with zeroconfig support, we can't work in any arbitrarily misconfigured environment, and maybe the best we can do is provide better hints on what is wrong. [example: a graphical dump of addressing/routing.] Curtis From touch@isi.edu Wed Oct 19 14:18:19 2011 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 DB7C41F0C51 for ; Wed, 19 Oct 2011 14:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLZe5NR0tbqA for ; Wed, 19 Oct 2011 14:18:19 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83421F8AE1 for ; Wed, 19 Oct 2011 14:18:19 -0700 (PDT) Received: from [172.16.38.64] (205.158.58.226.ptr.us.xo.net [205.158.58.226]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p9JLHT14016873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2011 14:17:38 -0700 (PDT) Message-ID: <4E9F3E69.90909@isi.edu> Date: Wed, 19 Oct 2011 14:17:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110191930.p9JJUajI047902@gateway.ipv6.occnc.com> In-Reply-To: <201110191930.p9JJUajI047902@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: homenet@ietf.org, Ted Lemon , Michael Richardson Subject: Re: [homenet] security question for zeroconf stuff inside the 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, 19 Oct 2011 21:18:20 -0000 On 10/19/2011 12:30 PM, Curtis Villamizar wrote: > > In message<28269.1318994489@marajade.sandelman.ca> > Michael Richardson writes: > >> >>>>>>> "Curtis" == Curtis Villamizar writes: >> Curtis> A WiFi AP will not connect to another AP and wireless >> Curtis> routers are typically AP by default. So if two wireless >> Curtis> routers autoconfig to being AP and using open routing, then >> >> OUT OF THE BOX: not every device plugged into a home network have >> no prior configuration. For instance, someone bringing a newsed >> device to grandma's house. > > He who configures it needs to fix it. Or press the factory default > button (if there is one). The example is two AP. Most AP can be > restored to factory default with a button press. What happens if you have two of them and they're BOTH configured to boot as the "master" home access point? ... >> Curtis> there is only a risk if something that is an WiFi client is >> Curtis> also a configured to be a router. Yes, but we want to assume that at least one of these will be configured as a router as a default, which means we KNOW someone will turn on two of them.... > On BSD and I suspect Linux as well, the default for: > > net.inet.ip.forwarding > net.inet6.ip6.forwarding > > are both zero. Right, but that cannot be the default for a homenet box. Joe From curtis@occnc.com Wed Oct 19 18:56:19 2011 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 D22ED11E80BF for ; Wed, 19 Oct 2011 18:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGyr7teRM875 for ; Wed, 19 Oct 2011 18:56:18 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 98EE511E80B6 for ; Wed, 19 Oct 2011 18:56:18 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9K1uGK5055361; Wed, 19 Oct 2011 18:56:17 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9K1uGK5055361 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319075777; bh=887ZT+ToyTiwsO4pF7MZNPJgd5D4VCTlITT2CW4k16c=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=lEyKP5uzxKghtQzeBQGzO+DGBRo4C7Xx/J2uH0EWpLPbPng5qefD1q8m69oPli7oc 9l8thMR8QxF01HJXm0A85fvClVWpqBiHqmxN4r5SZgZ0NHAG7d0YgXPr7RsY2QWTc6 AkWbno4zNaY6Y4A2zft+VkpxqwdQsL43xXRZGrY8= Message-Id: <201110200156.p9K1uGK5055361@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Wed, 19 Oct 2011 07:48:13 EDT." <4E9EB8FD.2060306@riw.us> Date: Wed, 19 Oct 2011 18:56:16 -0700 Cc: homenet@ietf.org Subject: Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 01:56:19 -0000 In message <4E9EB8FD.2060306@riw.us> Russ White writes: > > > 1. No built in assumptions about whether a router has an uplink port > > and if so, which port it is. > > > d. assumptions about uplinks may be learned (zero config) or > > configured. > > The biggest problem with determining what's an "uplink" and what's not > is simply what the word "uplink" actually means. One of the things we've > been thinking about here is "walled gardens," networks which serve a > special purpose, and hence don't have connectivity to the "world at > large." There are probably only two solutions here: > > 1. The provider's device needs to tell you this information. > 2. You need a set of "magic destinations," that the internal devices can > use to orient themselves to the network topology around them. Its easy to detect a walled garden if you are expecting a default route from a full uplink. Use the route to the whole Internet if one is available. Otherwise, use the walled garden connection if that is all you have. Walled gardens really suck. They suck even worse when they are sold as having access to the Internet when they don't. > > We have to get rid of long lease times. If a connection goes up, its > > The problem here is that you're working against the rest of the world, > which assumes an IP address is pretty much a permanent feature of a > device, like a MAC address. I don't know how to change that mentality. Yes. If plugging things arbitrarily and rearranging them without powering any of it down is going to work, handing out long leases to legacy devices can't be done. If a device supports taking back a lease, then that is better. Note that I had a perfectly fine workaround, which was to NAT for any device that wouldn't give up on using an old address if that address became stale. > > #4. security > > > > a. No filtering should be done on a link that is not identified as > > an uplink. > > As long as you're okay with multiple layered devices each filtering on > their uplinks (not necessarily a bad thing, by the way). I tend to think > more in terms of domains, which included possible vertical divides as > well as horizontal ones. An uplink is a connection to the provider. It is discovered, not identified as the port with the yellow connector. Reread the very first sentence you quoted: No built in assumptions about whether a router has an uplink port and if so, which port it is. > > b. By default strong filtering should be enabled on any uplink. > > > > c. Filtering can be weakenned, holes punched through, or disabled > > by configuration. > > Agreed. OK > > a. DV and LS routing can mixed within a domain. DV routes can be > > In fact, OSPF already does this... What I hate is this entire idea of > "redistribution." A single protocol that does both DV and LS in the > right places would be ideal --but I also think the existing DV protocols > can be modified to provide this sort of thing. I was trying to help come to a compromise on the "grand unified routing protocol problem" by stating that we don't need a one size fits all routing protocol. We can have one for wired, one for AP style wireless, one for mesh wireless. > > For (a) we should recommend one. OSPF is full standard and is cleaner > > but we have v2 for IPv4 and v3 for IPv6. ISIS has NSAPs as router ID > > (even uglier than IPv6 addresses or MACs and must be unique), sends > > around really big packets even for small changes, but supports both > > IPv4 and IPv6 in one instance and is (strongly) prefered by some. > > I would argue that the router ID situation in IS-IS is actually easier > to deal with than the one in OSPF. With fragmented LSPs, I don't think > the packet size in IS-IS is any worse than OSPF, either (?). On packet size: OSPF doesn't have a requirement to round every hello packet up MTU which ISIS does. OSPF can send only the LSA that changed. ISIS has to send the whole LSPDU fragment which contains the change and then the receiver has to check every TLV in the packet that didn't change and find the one that did change. Perhaps there can be a negociation with the zero config default being "a slight preference for X" where each vendor gets to pick X and the slight preference could be overridden by a configured (strong) preference. Perhaps distance to any router with a configured preference can be a tie breaker to switch over (with *lots* of hysteresis on the switch over). If we can't "pick one" then we have to make a network interoperate in a zero config situation with vendors that had different "slight preference" choices. It means two routing protocols with the increase in executable image and memory footprint. > :-) > > Russ Curtis From curtis@occnc.com Wed Oct 19 20:50:45 2011 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 B281111E80C5 for ; Wed, 19 Oct 2011 20:50:45 -0700 (PDT) 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.076, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5a-iVUM+4Ur for ; Wed, 19 Oct 2011 20:50:44 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id BF8CD11E80B6 for ; Wed, 19 Oct 2011 20:50:44 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9K3oQLX058090; Wed, 19 Oct 2011 20:50:26 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9K3oQLX058090 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319082626; bh=Z+WwDz6GYpn7LAN7JGb8Btgj6EcMROyJd7RKfVO4ULs=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=CSTqDDDAzIGz3tOHc0h999PtJduvr0wqhDfnMRRgJuMIiWQSUl5DAcD5TjCd17Sje SdM3mc5nPzWm27ECw6IQDM/aoGLv56bI1xIw9CRyjtugeO5QyhzfrbSSXc7DEA0sVs 2NDYJlR91LDzu0reyDMy/d1FxaEBx2ee73Yv6614= Message-Id: <201110200350.p9K3oQLX058090@gateway.ipv6.occnc.com> To: Joe Touch From: Curtis Villamizar In-reply-to: Your message of "Wed, 19 Oct 2011 14:17:29 PDT." <4E9F3E69.90909@isi.edu> Date: Wed, 19 Oct 2011 20:50:26 -0700 Cc: homenet@ietf.org, Ted Lemon , Michael Richardson , curtis@occnc.com Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 03:50:45 -0000 In message <4E9F3E69.90909@isi.edu> Joe Touch writes: > On 10/19/2011 12:30 PM, Curtis Villamizar wrote: > > > > In message<28269.1318994489@marajade.sandelman.ca> > > Michael Richardson writes: > > > >> > >>>>>>> "Curtis" == Curtis Villamizar writes: > >> Curtis> A WiFi AP will not connect to another AP and wireless > >> Curtis> routers are typically AP by default. So if two wireless > >> Curtis> routers autoconfig to being AP and using open routing, then > >> > >> OUT OF THE BOX: not every device plugged into a home network have > >> no prior configuration. For instance, someone bringing a newsed > >> device to grandma's house. > > > > He who configures it needs to fix it. Or press the factory default > > button (if there is one). The example is two AP. Most AP can be > > restored to factory default with a button press. > > What happens if you have two of them and they're BOTH configured to boot > as the "master" home access point? Master home access point? What is that? We are not talking about today's primitive NAT boxes that pretend to be routers. They either have a default route to the Internet or they don't. If they have a defailt route and they are at equal distance to that default route, then there are some arbitrary tie breakers. Worst case for AP might be if they are hard configed to the same channel and are very close to each other so they have about the same S/N and hosts can't decide which one to associate with, plus the interference with each other. In any case a press of the factory settings button should fix it. > ... > >> Curtis> there is only a risk if something that is an WiFi client is > >> Curtis> also a configured to be a router. > > Yes, but we want to assume that at least one of these will be configured > as a router as a default, which means we KNOW someone will turn on two > of them.... We want to assume that *all* AP are configured as routers except the legacy ones that want to be a dumb bridge with NAT to one port. > > On BSD and I suspect Linux as well, the default for: > > > > net.inet.ip.forwarding > > net.inet6.ip6.forwarding > > > > are both zero. > > Right, but that cannot be the default for a homenet box. You are mixing the discussion of what we want in routers with what we don't want enabled by default in every *legacy* PC, toaster and coffee maker. If the coffee maker is a competent IPv6 router with extensions to let it autoconfig, then let it be a router. I really don't want my dumb old kitchen appliances trying to NAT for each other. But that new IPv6 espresso maker that knows how to act as a router - that would be OK. :-) You lost the context. You snipped out the statement I was replying to. A little too much trimming on the response. It happens. > Joe Curtis From lorenzo@google.com Thu Oct 20 05:22:59 2011 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 AE17521F8B32 for ; Thu, 20 Oct 2011 05:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQvyx1rUwZ6B for ; Thu, 20 Oct 2011 05:22:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 234A721F8B1F for ; Thu, 20 Oct 2011 05:22:58 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p9KCMwBr017819 for ; Thu, 20 Oct 2011 05:22:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319113378; bh=JGB9HYbytg57KPSSiGKtk0aN4AA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WVVro0oMvSZnGcu6CzLiSWBIKmi+Wq4BAuG2Cd3SY1bldvOWyBFFGOK6uQ/uT188C /Uv/xPIyvbLNFbbEjnQ2A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=smf/HENgJKzqpY4BlsF+cgFgvoiw8iW91evK8dfJL6x0ogdsOmiDdI86dwi58J1QS zmZjMk+wCmC3SuqZVLWJA== Received: from ggnk4 (ggnk4.prod.google.com [10.218.97.68]) by wpaz9.hot.corp.google.com with ESMTP id p9KCMvxf016035 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 20 Oct 2011 05:22:57 -0700 Received: by ggnk4 with SMTP id k4so3998324ggn.7 for ; Thu, 20 Oct 2011 05:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KDFXyahHsjoiP1rbXYbpiroiF/0jirIjrf3yVZXyuUM=; b=fJcTyzPanbn+FkXeGDKMcUwk7BnoraznW2WcpqeOMk2OKOrI3jqvO1QpuS79jptaaB zGru4kBRm/zp3osGlxAw== Received: by 10.150.188.9 with SMTP id l9mr9886138ybf.15.1319113377241; Thu, 20 Oct 2011 05:22:57 -0700 (PDT) Received: by 10.150.188.9 with SMTP id l9mr9886124ybf.15.1319113377105; Thu, 20 Oct 2011 05:22:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Thu, 20 Oct 2011 05:22:37 -0700 (PDT) In-Reply-To: <4E9ED1E2.1040107@freedesktop.org> References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> <4E9ED1E2.1040107@freedesktop.org> From: Lorenzo Colitti Date: Thu, 20 Oct 2011 21:22:37 +0900 Message-ID: To: Jim Gettys Content-Type: multipart/alternative; boundary=000e0cd6ad3642c9cc04afba04d0 X-System-Of-Record: true Cc: Ole Troan , homenet@ietf.org, =?ISO-8859-1?Q?David_T=E4ht?= Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 20 Oct 2011 12:22:59 -0000 --000e0cd6ad3642c9cc04afba04d0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 19, 2011 at 22:34, Jim Gettys wrote: > On 10/19/2011 03:43 AM, Ole Troan wrote: > > you aren't helping things work better by doing 6to4. > > please disabled by default, if you absolutely want to support it at all, > hide it somewhere under the Wizard menus. > +1. Please read Geoff Huston's data that shows the 12-20% failure rate of 6to4, and then please disable it. :-) --000e0cd6ad3642c9cc04afba04d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
                    On Wed, Oct 19, 2011 at 22:34, Jim Gettys <jg@= freedesktop.org> wrote:
                    On 10/19/2011 03:43 AM, Ole Troan wrote:
                    > you aren't helping things work better by doing 6to4.
                    > please disabled by default, if you absolutely want to support it at al= l, hide it somewhere under the Wizard menus.

                    +1. Please read Geoff Huston's data that shows the 12-20% failu= re rate of 6to4, and then please disable it. :-)
                    --000e0cd6ad3642c9cc04afba04d0-- From gettysjim@gmail.com Thu Oct 20 05:48:31 2011 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 6523821F8A80 for ; Thu, 20 Oct 2011 05:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywzXp-F5OxTA for ; Thu, 20 Oct 2011 05:48:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D359421F8A70 for ; Thu, 20 Oct 2011 05:48:30 -0700 (PDT) Received: by vws5 with SMTP id 5so2373736vws.31 for ; Thu, 20 Oct 2011 05:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8PLS3ZoaaJp18EalSl4J3hRT0vSuHGoxDGTB5AWW27M=; b=LCCX/OIIgCpJmQ7esku0O/KEJiGziqV2l+LpWJZ3uUVaa9egLgw9DTYUTx8hvkDSwb ribU/BYKRSYovmGYKy9gvk+ivL/nmvZlkX5hRKVpyqbauU0aqZ7Pt39O9B/bZWLk2dR8 iBXA7KXnjzxc11p5rDDJkze8ovfKwo9kvv6wM= Received: by 10.52.95.164 with SMTP id dl4mr10479585vdb.72.1319114910231; Thu, 20 Oct 2011 05:48:30 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ey9sm8891540vdc.19.2011.10.20.05.48.28 (version=SSLv3 cipher=OTHER); Thu, 20 Oct 2011 05:48:29 -0700 (PDT) Sender: Jim Gettys Message-ID: <4EA0189B.2000403@freedesktop.org> Date: Thu, 20 Oct 2011 08:48:27 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> <4E9ED1E2.1040107@freedesktop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ole Troan , homenet@ietf.org, =?ISO-8859-1?Q?David_T=E4?= =?ISO-8859-1?Q?ht?= Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 20 Oct 2011 12:48:31 -0000 On 10/20/2011 08:22 AM, Lorenzo Colitti wrote: > On Wed, Oct 19, 2011 at 22:34, Jim Gettys > wrote: > > On 10/19/2011 03:43 AM, Ole Troan wrote: > > you aren't helping things work better by doing 6to4. > > please disabled by default, if you absolutely want to support it > at all, hide it somewhere under the Wizard menus. > > > +1. Please read Geoff Huston's data that shows the 12-20% failure rate > of 6to4, and then please disable it. :-) Yes, his data was taken just before/as Comcast put its relays into production; it's not what we see on that network. Before then, almost all traffic went through some poor server in Wisconsin, as I remember. It sucked. There is a self fulfilling prophesy here: if no one has decentr elays, then 6to4 is never usable, and then we should deprecate it. If it is deprecated, why should anyone put in 6to4 relays? Be that as it may, I suspect we should be more clever about whether it gets turned on automatically or not, maybe by whether the address is from an address range where we have some evidence of decent relays being available. - Jim From ot@cisco.com Thu Oct 20 05:59:32 2011 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 DBAEE21F8B05 for ; Thu, 20 Oct 2011 05:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQRaF5hKfZzP for ; Thu, 20 Oct 2011 05:59:32 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0E54021F8AF9 for ; Thu, 20 Oct 2011 05:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=1089; q=dns/txt; s=iport; t=1319115572; x=1320325172; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eDy/Y4XjQOJKWhKWz5aX7uxIZsaAR9s1rh740LZF0fk=; b=C0anvPOmGKesz02RyYbeBS3XNXeKchhCCLjOqlvjCEAFwBTMOADPCGzq pKixNEtsqZy6oXD0ZPcIQVlHmrhq/6sKye6i3bxiG44AWsGnJdfmRhAip VAGiub7qR6f4x7iCprOorwr64JN9JaKXGK9N7d9CIWdaHS5xPZeYIdj1p 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPIaoE6Q/khN/2dsb2JhbABDqRaBBYFuAQEBAwESASc/BQsLDjhXBjWHXpc1AZ49h0hhBJQAkVk X-IronPort-AV: E=Sophos;i="4.69,379,1315180800"; d="scan'208";a="1417615" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 20 Oct 2011 12:59:31 +0000 Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com [64.103.53.235]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9KCxVxU001864; Thu, 20 Oct 2011 12:59:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4EA0189B.2000403@freedesktop.org> Date: Thu, 20 Oct 2011 14:59:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> <4E9ED1E2.1040107@freedesktop.org> <4EA0189B.2000403@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, =?iso-8859-1?Q?David_T=E4ht?= , Lorenzo Colitti Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 20 Oct 2011 12:59:33 -0000 Jim, > Yes, his data was taken just before/as Comcast put its relays into > production; it's not what we see on that network. Before then, almost > all traffic went through some poor server in Wisconsin, as I remember.=20= > It sucked. >=20 > There is a self fulfilling prophesy here: if no one has decentr elays, > then 6to4 is never usable, and then we should deprecate it. If it is > deprecated, why should anyone put in 6to4 relays? >=20 > Be that as it may, I suspect we should be more clever about whether it > gets turned on automatically or not, maybe by whether the address is > from an address range where we have some evidence of decent relays = being > available. from a 6to4 router perspective you have no idea. the return relays are = not under your control. nor are they under your ISPs control. in the homenet context you also need border discovery for this function. = as you really do not want to enable it on all internal routers. (in the case of global v4 = addressing). but seriously, just remove it from the build. cheers, Ole= From lorenzo@google.com Thu Oct 20 06:00:28 2011 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 7D14C21F8AF9 for ; Thu, 20 Oct 2011 06:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.436 X-Spam-Level: X-Spam-Status: No, score=-105.436 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsYGJkAHcibt for ; Thu, 20 Oct 2011 06:00:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BB58721F8B24 for ; Thu, 20 Oct 2011 06:00:27 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p9KD0QRZ018761 for ; Thu, 20 Oct 2011 06:00:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319115626; bh=lqKy0nklophvEmyoqir3n1moG2s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hUMqKcIxbUcnvuYa5g3hOdzHcpgij6R/HNsyb0NnSZDZDDSHeKm7Az1rGT0xrrOoj JDSwF9LgSp64WtkcNBiJg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=btXiRKlG28XSBXDMzcsuf5B6hJ10hXtuH/29JK5EJ9RiaeMxN7GOl9CxbenbBEtAq 4cmcEk8fnUkpAkbFllsJg== Received: from ywf7 (ywf7.prod.google.com [10.192.6.7]) by wpaz9.hot.corp.google.com with ESMTP id p9KD0NG5027788 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 20 Oct 2011 06:00:25 -0700 Received: by ywf7 with SMTP id 7so615547ywf.1 for ; Thu, 20 Oct 2011 06:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=petDiws8bTMZ6iSQyOwFW8YAP1PF0WUQxLKDg0Oftuc=; b=ImRzcrW0O4e7fH55jlqjBrGUaTqFdiuMk3CEkCV2aaDQQPk+P4qNqvkl6U5QgBYdAP Vmxpl1QwMq/+bMD7EO2A== Received: by 10.150.188.9 with SMTP id l9mr10036530ybf.15.1319115623261; Thu, 20 Oct 2011 06:00:23 -0700 (PDT) Received: by 10.150.188.9 with SMTP id l9mr10036507ybf.15.1319115623111; Thu, 20 Oct 2011 06:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Thu, 20 Oct 2011 06:00:03 -0700 (PDT) In-Reply-To: References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> <4E9ED1E2.1040107@freedesktop.org> <4EA0189B.2000403@freedesktop.org> From: Lorenzo Colitti Date: Thu, 20 Oct 2011 22:00:03 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=000e0cd6ad36221cad04afba8a4b X-System-Of-Record: true Cc: homenet@ietf.org, Jim Gettys , =?ISO-8859-1?Q?David_T=E4ht?= Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 20 Oct 2011 13:00:28 -0000 --000e0cd6ad36221cad04afba8a4b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 21:59, Ole Troan wrote: > but seriously, just remove it from the build. > Yep. Overlay networks will never match native performance. Please don't do 6to4, please implement RFC 6204 instead. --000e0cd6ad36221cad04afba8a4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
                    On Thu, Oct 20, 2011 at 21:59, Ole Troan <ot@cisco.com> = wrote:
                    but seriously, just remove it from the build.

                    Yep. Overlay networks will never match native performance. Please do= n't do 6to4, please implement RFC 6204 instead.
                    --000e0cd6ad36221cad04afba8a4b-- From gettysjim@gmail.com Thu Oct 20 06:24:03 2011 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 C01D921F8B85 for ; Thu, 20 Oct 2011 06:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N50d9-jiq6jb for ; Thu, 20 Oct 2011 06:23:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 221E321F8B71 for ; Thu, 20 Oct 2011 06:23:57 -0700 (PDT) Received: by vws5 with SMTP id 5so2413258vws.31 for ; Thu, 20 Oct 2011 06:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LM+dgHo/pwG3hn2Ofh691eEiLP3YNEjB1u14BAKAcL0=; b=d1uHRVGB/uENeHWHQLk/ydOS8YRMNjISeG2qL/EyfT5NNjfbXax/JKy6XbHT7hOKvL ZqLEhDZdyOy8JsH6gD7HFzHnmcB1Jfpjm5nZe/vdIEjosyTIO1p3EPmhHFo0Hy3qifGP Lb48YZiF7JBV22n7B9L5lO3bXPHPikOVKXgKM= Received: by 10.52.37.10 with SMTP id u10mr10554804vdj.57.1319117016027; Thu, 20 Oct 2011 06:23:36 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id r5sm9015211vdw.2.2011.10.20.06.23.34 (version=SSLv3 cipher=OTHER); Thu, 20 Oct 2011 06:23:34 -0700 (PDT) Sender: Jim Gettys Message-ID: <4EA020D5.4010907@freedesktop.org> Date: Thu, 20 Oct 2011 09:23:33 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> <4E9ED1E2.1040107@freedesktop.org> <4EA0189B.2000403@freedesktop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ole Troan , homenet@ietf.org, =?ISO-8859-1?Q?David_T=E4?= =?ISO-8859-1?Q?ht?= Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 20 Oct 2011 13:24:03 -0000 On 10/20/2011 09:00 AM, Lorenzo Colitti wrote: > On Thu, Oct 20, 2011 at 21:59, Ole Troan > wrote: > > but seriously, just remove it from the build. > > > Yep. Overlay networks will never match native performance. Please > don't do 6to4, please implement RFC 6204 instead. Yes, please do. Contributions of all sorts to CeroWrt/OpenWrt gratefully accepted. Things happen way faster if you do them yourself. ;-) - Jim From gettysjim@gmail.com Thu Oct 20 06:26:28 2011 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 102E821F8A70 for ; Thu, 20 Oct 2011 06:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQbwPRRZNBlH for ; Thu, 20 Oct 2011 06:26:27 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75DCE21F8672 for ; Thu, 20 Oct 2011 06:26:27 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2933583vcb.31 for ; Thu, 20 Oct 2011 06:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/s4Ol9sxv8Wnp37bBTLY7vfzfYy+CCTeTfUoOVcNtVA=; b=bgYj/roJWvkAgn9VmCNHcOq/eIdN/5yVnLuFudHgz2tuLDKVsaGZndrhACT9vXLk5h qZVMxHZVsuLfAseBq0LbLccZ8ys1YtcP46JBS+IHiCWoA4qr2FoefwqDWKaerfvhbqrV 8WHXbUC6WXf2xHMScpf3xE1X9klc8347pPyw8= Received: by 10.52.240.131 with SMTP id wa3mr10474158vdc.95.1319117187021; Thu, 20 Oct 2011 06:26:27 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id gx2sm9020072vdb.5.2011.10.20.06.26.25 (version=SSLv3 cipher=OTHER); Thu, 20 Oct 2011 06:26:26 -0700 (PDT) Sender: Jim Gettys Message-ID: <4EA02180.1070203@freedesktop.org> Date: Thu, 20 Oct 2011 09:26:24 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Ole Troan References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> <4E9ED1E2.1040107@freedesktop.org> <4EA0189B.2000403@freedesktop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, =?ISO-8859-1?Q?David_T=E4ht?= , Lorenzo Colitti Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 20 Oct 2011 13:26:28 -0000 On 10/20/2011 08:59 AM, Ole Troan wrote: > Jim, > >> Yes, his data was taken just before/as Comcast put its relays into >> production; it's not what we see on that network. Before then, almost >> all traffic went through some poor server in Wisconsin, as I remember. >> It sucked. >> >> There is a self fulfilling prophesy here: if no one has decentr elays, >> then 6to4 is never usable, and then we should deprecate it. If it is >> deprecated, why should anyone put in 6to4 relays? >> >> Be that as it may, I suspect we should be more clever about whether it >> gets turned on automatically or not, maybe by whether the address is >> from an address range where we have some evidence of decent relays being >> available. > from a 6to4 router perspective you have no idea. the return relays are not under your control. > nor are they under your ISPs control. Ah, point made (as far as I'm concerned). Dave? > in the homenet context you also need border discovery for this function. as you really do not want to > enable it on all internal routers. (in the case of global v4 addressing). > > but seriously, just remove it from the build. > This I disagree with; 6to4 is seriously useful in certain environments (like mine). Having it present can be useful, having it on by default, is problematic. Unless/until we can fully automate something else I want it available. - Jim From ot@cisco.com Thu Oct 20 07:22:59 2011 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 DB3B821F8BEE for ; Thu, 20 Oct 2011 07:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.292 X-Spam-Level: X-Spam-Status: No, score=-8.292 tagged_above=-999 required=5 tests=[AWL=2.307, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZWeDYGNJqYw for ; Thu, 20 Oct 2011 07:22:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BF04F21F8BE9 for ; Thu, 20 Oct 2011 07:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=341; q=dns/txt; s=iport; t=1319120578; x=1320330178; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uy//iv3lLtvPFZQBDzeuAZ6nqqNT2cjlboxoDL9TqxQ=; b=eSDZUqnkHYQ+5j//fM3wMZ/q31AOm9yITHU8Ai2kn1ZeOymNGQvs00MH TzRz+pJCD/tzq9FumcNL7ekumI8+Nakx7M5xojyFmQ2VeAUA0v4HJlsFv zBJmFifg/gmX+Sn/WJfvpc9bH8Ok7qUISsPHnfSrJ5y9LVcIctT7RcRR5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAUuoE6Q/khL/2dsb2JhbABDqRaBBYFuAQEBAwESASc/EAsOOFcGNYdelz0BnjmHSGEElACRWQ X-IronPort-AV: E=Sophos;i="4.69,379,1315180800"; d="scan'208";a="58203379" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Oct 2011 14:22:56 +0000 Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com [64.103.53.235]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9KEMuvd013517; Thu, 20 Oct 2011 14:22:56 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4EA02180.1070203@freedesktop.org> Date: Thu, 20 Oct 2011 16:22:55 +0200 Content-Transfer-Encoding: 7bit Message-Id: <18D90E1A-7FEE-4827-B097-06B4C4AC0729@cisco.com> References: <201110160135.p9G1Z8S8023584@gateway.ipv6.occnc.com> <4E9A8C15.2030605@gmail.com> <4E9AB641.7050201@gmail.com> <4E9ED1E2.1040107@freedesktop.org> <4EA0189B.2000403@freedesktop.org> <4EA02180.1070203@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1084) Cc: homenet@ietf.org, =?iso-8859-1?Q?David_T=E4ht?= , Lorenzo Colitti Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) 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, 20 Oct 2011 14:22:59 -0000 >> but seriously, just remove it from the build. >> > This I disagree with; 6to4 is seriously useful in certain environments > (like mine). Having it present can be useful, having it on by default, > is problematic. Unless/until we can fully automate something else I want > it available. yes, I'm fine with that. cheers, Ole From touch@isi.edu Thu Oct 20 10:38:48 2011 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 92E5721F8BF3 for ; Thu, 20 Oct 2011 10:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.879 X-Spam-Level: X-Spam-Status: No, score=-102.879 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldNCcSM-4jHv for ; Thu, 20 Oct 2011 10:38:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29F21F8BB6 for ; Thu, 20 Oct 2011 10:38:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p9KHcAmu017245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2011 10:38:10 -0700 (PDT) Message-ID: <4EA05C82.8010005@isi.edu> Date: Thu, 20 Oct 2011 10:38:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110200350.p9K3oQLX058090@gateway.ipv6.occnc.com> In-Reply-To: <201110200350.p9K3oQLX058090@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: homenet@ietf.org, Ted Lemon , Michael Richardson Subject: Re: [homenet] security question for zeroconf stuff inside the 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: Thu, 20 Oct 2011 17:38:48 -0000 Hi, Curtis, On 10/19/2011 8:50 PM, Curtis Villamizar wrote: ... > We want to assume that *all* AP are configured as routers except the > legacy ones that want to be a dumb bridge with NAT to one port. AFAICT, you want to assume that: - all AP routers are configured as per homenet - all other APs are bridges only I.e., if IP routing is supported then homenet is supported. I would prefer if that were true, but I don't think it's a reasonable assumption to make in an home environment, because... >>> On BSD and I suspect Linux as well, the default for: >>> >>> net.inet.ip.forwarding >>> net.inet6.ip6.forwarding >>> >>> are both zero. >> >> Right, but that cannot be the default for a homenet box. > > You are mixing the discussion of what we want in routers with what we > don't want enabled by default in every *legacy* PC, toaster and coffee > maker. If the coffee maker is a competent IPv6 router with extensions > to let it autoconfig, then let it be a router. I would like to make the same assumption, but we all know that Linux doesn't listen to the IETF standards. For any Linux parameter, we ought to assume that it *will* change and we need to deal with it. Since Linux is used in even dumb APs, that means that "future legacy" (i.e., non-homenet) APs *will* end up routing at some point, and will not support homenet. We need to deal with that eventuality too. Joe From russw@riw.us Thu Oct 20 11:11:04 2011 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 DF1CA21F8A91 for ; Thu, 20 Oct 2011 11:11:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgWuqtxvh07H for ; Thu, 20 Oct 2011 11:11:04 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35721F8ACE for ; Thu, 20 Oct 2011 11:11:04 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:58259 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RGx54-0001Ss-EO; Thu, 20 Oct 2011 14:11:02 -0400 Message-ID: <4EA0642D.30307@riw.us> Date: Thu, 20 Oct 2011 14:10:53 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110200156.p9K1uGK5055361@gateway.ipv6.occnc.com> In-Reply-To: <201110200156.p9K1uGK5055361@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: homenet@ietf.org Subject: Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing 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, 20 Oct 2011 18:11:05 -0000 > Its easy to detect a walled garden if you are expecting a default > route from a full uplink. Unless every uplink gives you a default route... > Note that I had a perfectly fine workaround, which was to NAT for any > device that wouldn't give up on using an old address if that address > became stale. Then you might as well NAT all the addresses on the subnet. :-) >> In fact, OSPF already does this... What I hate is this entire idea of >> "redistribution." A single protocol that does both DV and LS in the >> right places would be ideal --but I also think the existing DV protocols >> can be modified to provide this sort of thing. > > I was trying to help come to a compromise on the "grand unified > routing protocol problem" by stating that we don't need a one size > fits all routing protocol. We can have one for wired, one for > AP style wireless, one for mesh wireless. I would prefer one... > On packet size: OSPF doesn't have a requirement to round every hello > packet up MTU which ISIS does. OSPF can send only the LSA that > changed. ISIS has to send the whole LSPDU fragment which contains the > change and then the receiver has to check every TLV in the packet that > didn't change and find the one that did change. How many destinations do you think there will be in a home network? My guess is that we'll end up with one or two LSPs anyway. As for "rounding up," is it really that big of a deal? It's just a different solution for the same problem. :-) Russ From curtis@occnc.com Thu Oct 20 20:52:59 2011 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 70D7F21F891D for ; Thu, 20 Oct 2011 20:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co4QoFCW2JL0 for ; Thu, 20 Oct 2011 20:52:58 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB121F8906 for ; Thu, 20 Oct 2011 20:52:58 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9L3qdZY091227; Thu, 20 Oct 2011 20:52:39 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9L3qdZY091227 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319169160; bh=VOlcRotuewXRpuG+zn3dVUjCg5ppUBVvXQTw9Xu3IQY=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=GZaMG+MSUOpM0cGaFhm/XyE07aQzDUdNiOep5x7HBQcwjMcyxr3nFLlcPHilziWEg phTSvAQyNSfJcs/XD9+PYw0a1R5PwpjBE7ik7utZqZVh+dXBvTo+cAIDyAAMwXlxo+ bcwIeEmbIFni3FMMQmbFVZ8q+4fhPe2Knuhb7reQ= Message-Id: <201110210352.p9L3qdZY091227@gateway.ipv6.occnc.com> To: Joe Touch From: Curtis Villamizar In-reply-to: Your message of "Thu, 20 Oct 2011 10:38:10 PDT." <4EA05C82.8010005@isi.edu> Date: Thu, 20 Oct 2011 20:52:39 -0700 Cc: homenet@ietf.org, Ted Lemon , Michael Richardson , curtis@occnc.com Subject: Re: [homenet] security question for zeroconf stuff inside the homenet... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 03:52:59 -0000 In message <4EA05C82.8010005@isi.edu> Joe Touch writes: > Hi, Curtis, > > On 10/19/2011 8:50 PM, Curtis Villamizar wrote: > ... > > We want to assume that *all* AP are configured as routers except the > > legacy ones that want to be a dumb bridge with NAT to one port. > > AFAICT, you want to assume that: > > - all AP routers are configured as per homenet > > - all other APs are bridges only > > I.e., if IP routing is supported then homenet is supported. > > I would prefer if that were true, but I don't think it's a reasonable > assumption to make in an home environment, because... Possible confusion here due to overload of the word "configured". All AP routers which are capable as per homenet are zero config routers out of the box. Hope that all legcacy stuff is bridges only, but recognized that some may insist on trying to NAT on one port. Note that some product is so stupid as to always announce default route to the "LAN side", even with nothing connected on the uplink port (and then blackhole the traffic) and won't let a default route be configured or accepted by a routing protocol on any port except the designated uplink. Being backward compatible with anything that stupid may not be possible. Grandma may have to toss that one in the recycle bin. > >>> On BSD and I suspect Linux as well, the default for: > >>> > >>> net.inet.ip.forwarding > >>> net.inet6.ip6.forwarding > >>> > >>> are both zero. > >> > >> Right, but that cannot be the default for a homenet box. > > > > You are mixing the discussion of what we want in routers with what we > > don't want enabled by default in every *legacy* PC, toaster and coffee > > maker. If the coffee maker is a competent IPv6 router with extensions > > to let it autoconfig, then let it be a router. > > I would like to make the same assumption, but we all know that Linux > doesn't listen to the IETF standards. For any Linux parameter, we ought > to assume that it *will* change and we need to deal with it. sysctl is meant for changing it. > Since Linux is used in even dumb APs, that means that "future legacy" > (i.e., non-homenet) APs *will* end up routing at some point, and will > not support homenet. Today's dumb(est) APs that run Linux NAT and bridge or just bridge. If the box says router it does NAT (and is useless IMHO) if its just an AP it bridges to it's (usually one) Ethernet. Some of these NAT boxes run RIP on the "LAN side" and call that routing and enable it by default. Fortunately we can detect this brain damage too. If it speaks RIP only, it's not homenet aware. > We need to deal with that eventuality too. > > Joe Maximizing backwards compatibility to all reasonable devices is clearly one of the biggest challenges. Some devices out there may be just plain too braindead to work with unless the vendor can offer a firmware upgrade and then I can't see Grandma loading a new flash image on her router. Curtis From curtis@occnc.com Thu Oct 20 21:06:43 2011 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 704E411E80A3 for ; Thu, 20 Oct 2011 21:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go4XVqr6pDCw for ; Thu, 20 Oct 2011 21:06:42 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id E91D211E8097 for ; Thu, 20 Oct 2011 21:06:35 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9L46WKk091596; Thu, 20 Oct 2011 21:06:33 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9L46WKk091596 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319169993; bh=XhkGtiPoTqjzJMLQSkaqWF/+a4g2kKJL6jni8KknKuQ=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=NRhUtjQn/uwIMf7QyU6Ja//3pN8WUtp0+iNYATxmvxF/MpSfoKBJP2U3uNPTHlK0S rpJWxFMfbVHFTzGXWSmSyFQarVPVZp08gI9eQiWAPmw3Mxnj289CEtPQQvEIR67gjU noBqnaLfgP+0viAluatT3/++QMMhvf7U4Xhm1Cig= Message-Id: <201110210406.p9L46WKk091596@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Thu, 20 Oct 2011 14:10:53 EDT." <4EA0642D.30307@riw.us> Date: Thu, 20 Oct 2011 21:06:32 -0700 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 04:06:43 -0000 In message <4EA0642D.30307@riw.us> Russ White writes: > > > Its easy to detect a walled garden if you are expecting a default > > route from a full uplink. > > Unless every uplink gives you a default route... In which case you pick the closest one. Its only where the walled garden claims to have a default route but blackholes or tries to do web only and replaces content that you have trouble. > > Note that I had a perfectly fine workaround, which was to NAT for any > > device that wouldn't give up on using an old address if that address > > became stale. > > Then you might as well NAT all the addresses on the subnet. :-) No. You NAT at the border only for the hosts on the subnet that are legacy and cannot replace a DHCP assigned address with a new one. In affect you NAT the old subnet becuase the homenet hosts and routers accepted a new address. You then have more than one subnet address (aliases in ifconfig speak). > >> In fact, OSPF already does this... What I hate is this entire idea of > >> "redistribution." A single protocol that does both DV and LS in the > >> right places would be ideal --but I also think the existing DV protocols > >> can be modified to provide this sort of thing. > > > > I was trying to help come to a compromise on the "grand unified > > routing protocol problem" by stating that we don't need a one size > > fits all routing protocol. We can have one for wired, one for > > AP style wireless, one for mesh wireless. > > I would prefer one... There is at least an assertion that some DV protocols may be better for mesh wireless. There need not be one "grand unified routing protocol". In the provider world, BGP allowed the IGP to be picked per AS and allowed OSPF and ISIS (and EIGRP) to exist in different providers. As it turns out only the LS protocols endured. > > On packet size: OSPF doesn't have a requirement to round every hello > > packet up MTU which ISIS does. OSPF can send only the LSA that > > changed. ISIS has to send the whole LSPDU fragment which contains the > > change and then the receiver has to check every TLV in the packet that > > didn't change and find the one that did change. > > How many destinations do you think there will be in a home network? My > guess is that we'll end up with one or two LSPs anyway. Depends on where this stuff is deployed. Think public library for example. Multiple consumer grade APs. Real wires connecting them. No wizards to help out (except maybe some volunteer with some knowledge of PCs and absolutely no clue about networking). > As for "rounding up," is it really that big of a deal? It's just a > different solution for the same problem. A full MTU sized hello might be a big deal on a wireless mesh. Jim's comments seem to imply that and he was rather emphatical about routing protocols keeping the noise level down. > :-) > > Russ Curtis From curtis@occnc.com Thu Oct 20 21:33:22 2011 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 D185021F84DF for ; Thu, 20 Oct 2011 21:33:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): cc: ...freedesktop.org>, David T\344ht ; Thu, 20 Oct 2011 21:33:22 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1098521F84DC for ; Thu, 20 Oct 2011 21:33:21 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9L4XDH9095283; Thu, 20 Oct 2011 21:33:13 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9L4XDH9095283 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319171594; bh=yNU4fCNkucLscUciy7AP5AmwfvP5L7T9hbw82F7n0nw=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=qcdsNMXkjWsVPEpTF1eKmbqB+L2yCliaoJoeNwWjVpq0CjvtTkRZjftcBb2mLBtOO FHcUgbnPoHiACV1dxSpUgcCUdq/JxrBbOaV0I/7x4kyo50Md0o3yzQOHeQWsVBy5mL 9DmZYQEWjKQejXO0NdB25PFbx0H9S9taW7h4yKcY= Message-Id: <201110210433.p9L4XDH9095283@gateway.ipv6.occnc.com> To: Lorenzo Colitti From: Curtis Villamizar In-reply-to: Your message of "Thu, 20 Oct 2011 22:00:03 +0900." Date: Thu, 20 Oct 2011 21:33:13 -0700 Cc: Ole Troan , homenet@ietf.org, Jim Gettys , David Täht Subject: Re: [homenet] Thoughts about ipv6 routing (babel & AHCP) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 04:33:23 -0000 In message Lorenzo Colitti writes: > On Thu, Oct 20, 2011 at 21:59, Ole Troan wrote: > > > but seriously, just remove it from the build. > > > > Yep. Overlay networks will never match native performance. Please > don't do 6to4, please implement RFC 6204 instead. For tunnels RFC4213 is preferred over 6to4, but I do think that both should be implemented. Comcast has done a good job with 6to4, and other providers might as well. RFC6204 does specify that the WAN side can be a tunnel, but doesn't recommend any type of tunnel (I don't think having not looked just now). Curtis From russw@riw.us Fri Oct 21 06:10:02 2011 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 56A4F21F8C73 for ; Fri, 21 Oct 2011 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q03qnkJshHGm for ; Fri, 21 Oct 2011 06:10:00 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id BE83921F8C74 for ; Fri, 21 Oct 2011 06:09:58 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:61104 helo=[192.168.100.55]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RHEr0-0004xJ-EU; Fri, 21 Oct 2011 09:09:42 -0400 Message-ID: <4EA16F0C.1070301@riw.us> Date: Fri, 21 Oct 2011 09:09:32 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201110210406.p9L46WKk091596@gateway.ipv6.occnc.com> In-Reply-To: <201110210406.p9L46WKk091596@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: homenet@ietf.org Subject: Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing 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, 21 Oct 2011 13:10:02 -0000 >> Unless every uplink gives you a default route... > > In which case you pick the closest one. So you would argue that if there is a walled garden, it should always advertise full routes? I don't know how realistic that is all the time. Network failures are one example of this being problematic. >> Then you might as well NAT all the addresses on the subnet. :-) > > No. You NAT at the border only for the hosts on the subnet that are > legacy and cannot replace a DHCP assigned address with a new one. In > affect you NAT the old subnet becuase the homenet hosts and routers > accepted a new address. You then have more than one subnet address > (aliases in ifconfig speak). If you're already doing NAT, then... >> I would prefer one... > > There is at least an assertion that some DV protocols may be better > for mesh wireless. But why should a single protocol not be link state and d-v? OSPF already is. > In the provider world, BGP allowed the IGP to be picked per AS and > allowed OSPF and ISIS (and EIGRP) to exist in different providers. As > it turns out only the LS protocols endured. I would say that EIGRP has endured, as well. Not in the provider market, but certainly in other markets. For all the bad press EIGRP gets, it's actually a very interesting and useful protocol. > Depends on where this stuff is deployed. Think public library for > example. Multiple consumer grade APs. Real wires connecting them. > No wizards to help out (except maybe some volunteer with some > knowledge of PCs and absolutely no clue about networking). So you'd argue for a much more complex protocol because it's cheaper on the wire? I don't think "wire costs" mean much any longer, honestly. What's needed is an open evaluation of all the available protocols, rather than assuming OSPF is "the answer," etc. And we shouldn't leave out the option of extending an existing protocol, either --and I don't want routing information in opaque LSAs. :-) > A full MTU sized hello might be a big deal on a wireless mesh. Jim's > comments seem to imply that and he was rather emphatical about routing > protocols keeping the noise level down. Chattiness and packet size are two different problems. If you want the least chatty protocol, go to EIGRP. :-) It's the least chatty for several reasons. In fact, distance vector can always be made to be less chatty than any link state protocol, if that's really your goal. But again, there's no reason a single protocol can't act both ways in different environments. OSPF already does. :-) Russ From curtis@occnc.com Fri Oct 21 07:04:36 2011 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 5E17B11E8088 for ; Fri, 21 Oct 2011 07:04:36 -0700 (PDT) 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=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viavH3D5cJJT for ; Fri, 21 Oct 2011 07:04:35 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C3ED411E8082 for ; Fri, 21 Oct 2011 07:04:34 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9LE4Ssc010322; Fri, 21 Oct 2011 07:04:28 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9LE4Ssc010322 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319205868; bh=KXQfBulvCkNz78+0etjVKqNMKSZ1xohTu2D/HYcFiOA=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=oEBYg4pNPbldayGU0Sa/i6IP4FpYcgyr4Z2gM31xC9zxR81ylx8kVL7b6hPqq3n2x EhaVfqUHSll09qw7R+z2MA64DSuNXiXeitOh6kSChewdai+165U4ELH2oBQmKLyLG/ AyP3TMx5sD/BKhNuuQwaQf+Y8de+ZBfULF5Kst44= Message-Id: <201110211404.p9LE4Ssc010322@gateway.ipv6.occnc.com> To: Russ White From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 09:09:32 EDT." <4EA16F0C.1070301@riw.us> Date: Fri, 21 Oct 2011 07:04:27 -0700 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:04:36 -0000 In message <4EA16F0C.1070301@riw.us> Russ White writes: > >> Unless every uplink gives you a default route... > > > > In which case you pick the closest one. > > So you would argue that if there is a walled garden, it should always > advertise full routes? I don't know how realistic that is all the time. > Network failures are one example of this being problematic. No. A walled garden should never advertise full routes. With all the email its easy to lose track of what is being suggested. Take address allocation from the source which is also providing the least specific route. If there is a tie for least specific, then pick the closest. If there is a walled gardenner, they can advertise a prefix that they have been assigned, but no more. If there is also a router with a default, pick that one for the address allocation. Use *routing* and forward to the more specific route to talk through the walled garden router to the walled garden. Use the default route to talk to anything else. > >> Then you might as well NAT all the addresses on the subnet. :-) > > > > No. You NAT at the border only for the hosts on the subnet that are > > legacy and cannot replace a DHCP assigned address with a new one. In > > affect you NAT the old subnet becuase the homenet hosts and routers > > accepted a new address. You then have more than one subnet address > > (aliases in ifconfig speak). > > If you're already doing NAT, then... Only for legacy devices. Never devices might want to have the ability to have connections from the outside which you can't have with a NAT. > >> I would prefer one... > > > > There is at least an assertion that some DV protocols may be better > > for mesh wireless. > > But why should a single protocol not be link state and d-v? OSPF already is. Please read: Message-Id: <201110171821.p9HILtKr048064@gateway.ipv6.occnc.com> I'll make it easy for you on the point above. #5 routing a. DV and LS routing can mixed within a domain. DV routes can be injected into LS routing (for example as OSPF ASE). LS prefixes can be injected into DV. Within a LS or DV region, a mechanism to prefer internal routes to the LS domain or DV domain is needed. (OSPF already prefers internal prefixes to ASE). The rest of the message is also worth reading and you wouldn't be asking quite so many questions if you read this. > > In the provider world, BGP allowed the IGP to be picked per AS and > > allowed OSPF and ISIS (and EIGRP) to exist in different providers. As > > it turns out only the LS protocols endured. > > I would say that EIGRP has endured, as well. Not in the provider market, > but certainly in other markets. For all the bad press EIGRP gets, it's > actually a very interesting and useful protocol. Not in the provider market. No major provider uses it. BTW- ANS used it in their regional routers (each region had a separate AS) for a while but replaced it when Cisco's OSPF became stable (which took a *very* long time to happen, but did happen mid-1990s). It was also the "Cisco-only-ness" that assured no one would use it. > > Depends on where this stuff is deployed. Think public library for > > example. Multiple consumer grade APs. Real wires connecting them. > > No wizards to help out (except maybe some volunteer with some > > knowledge of PCs and absolutely no clue about networking). > > So you'd argue for a much more complex protocol because it's cheaper on > the wire? I don't think "wire costs" mean much any longer, honestly. > > What's needed is an open evaluation of all the available protocols, > rather than assuming OSPF is "the answer," etc. And we shouldn't leave > out the option of extending an existing protocol, either --and I don't > want routing information in opaque LSAs. :-) LS is not much more complicated. It has properties that DV can't touch, like ability to carry very useful other information about the topology. We want protocols that will work not only in Grandma's house but her grandkids too. Opaque LSAs are no different from ISIS TLVs that are not defined in the base spec. They are a proven extension with backwards compatibility back to routers of the 1980s. In case Grandma is still still hasn't tossed out that old Proteon. > > A full MTU sized hello might be a big deal on a wireless mesh. Jim's > > comments seem to imply that and he was rather emphatical about routing > > protocols keeping the noise level down. > > Chattiness and packet size are two different problems. If you want the > least chatty protocol, go to EIGRP. :-) It's the least chatty for > several reasons. In fact, distance vector can always be made to be less > chatty than any link state protocol, if that's really your goal. > > But again, there's no reason a single protocol can't act both ways in > different environments. OSPF already does. > > :-) > > Russ See point #5a above. No grand unified routing protocol. We will waste too much time arguing over which is the one best protocol. Curtis From lee.howard@twcable.com Fri Oct 21 08:31:47 2011 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 3C7C511E80C3 for ; Fri, 21 Oct 2011 08:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agJeNrBRg0hb for ; Fri, 21 Oct 2011 08:31:46 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 32F6E11E80BF for ; Fri, 21 Oct 2011 08:31:46 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,386,1315195200"; d="scan'208";a="288114884" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Oct 2011 11:28:03 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 21 Oct 2011 11:31:44 -0400 From: "Howard, Lee" To: james woodyatt , "curtis@occnc.com" Date: Fri, 21 Oct 2011 11:31:41 -0400 Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AcyHwuxnRSNe7owmRjCZtlCgvz4eqQIQ5LNA Message-ID: References: <201110110245.p9B2jttR062934@gateway.ipv6.occnc.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" Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 21 Oct 2011 15:31:47 -0000 > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behal= f Of james > woodyatt > Sent: Monday, October 10, 2011 11:07 PM > To: curtis@occnc.com > Cc: homenet@ietf.org > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote: > > > > All of this is only true for IPv4 but not for IPv6. > > I wasn't talking about IPv4 at all. My comments are relevant in a world = entirely comprising > IPv6-only service providers. The IPv6 Internet will be saddled with all = of the problems of > the IPv4 Internet with respect to devices on homenets having to beg the g= ateways to allow > inbound packets from arbitrary remote destinations. It has nothing to do= with NAT, and > everything to do with firewalls and stateful filters. s/beg/authorize > > > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet 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 curtis@occnc.com Fri Oct 21 09:20:34 2011 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 265BD21F8B9C for ; Fri, 21 Oct 2011 09:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ2w9hzaatWc for ; Fri, 21 Oct 2011 09:20:33 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C853B21F8B9A for ; Fri, 21 Oct 2011 09:20:32 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9LGKOGK013385; Fri, 21 Oct 2011 09:20:25 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9LGKOGK013385 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319214025; bh=R129tDM7eCTy7VKE6O/hkWycI3y2w11zaB4//HxuHYM=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=fKzsKKIJx1NGLPCbUTq10EKw9EIOhb7td3YYy8ejZcvsimAKCoQxZQbJXOMkZ0AV5 9B78xm7piAOIFsX1pJ04lTvtyigg2ZAkotqcTcHzeBJ89/0ZK0wGvD+sjjG2AynVmo VEbKvGFkUtMp58Zj4OO2umvrArKNeCIdTdL0fwX4= Message-Id: <201110211620.p9LGKOGK013385@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 11:31:41 EDT." Date: Fri, 21 Oct 2011 09:20:24 -0700 Cc: "homenet@ietf.org" , james woodyatt , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:20:34 -0000 In message "Howard, Lee" writes: > > > -----Original Message----- > > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of james > > woodyatt > > Sent: Monday, October 10, 2011 11:07 PM > > To: curtis@occnc.com > > Cc: homenet@ietf.org > > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > > > On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote: > > > > > > All of this is only true for IPv4 but not for IPv6. > > > > I wasn't talking about IPv4 at all. My comments are relevant in a world entirely comprising > > IPv6-only service providers. The IPv6 Internet will be saddled with all of the problems of > > the IPv4 Internet with respect to devices on homenets having to beg the gateways to allow > > inbound packets from arbitrary remote destinations. It has nothing to do with NAT, and > > everything to do with firewalls and stateful filters. > > s/beg/authorize That response seems to be confirming the problem. The customer should not need the ISP to authorize inbound traffic. Otherwise the service should not be called an "Internet" service. It is a service providing only limited Internet connectivity. Curtis From lee.howard@twcable.com Fri Oct 21 10:11:47 2011 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 555291F0C86 for ; Fri, 21 Oct 2011 10:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sw0It33oPvy for ; Fri, 21 Oct 2011 10:11:46 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id AA2CB1F0C7F for ; Fri, 21 Oct 2011 10:11:46 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,386,1315195200"; d="scan'208";a="288179048" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Oct 2011 13:08:04 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 21 Oct 2011 13:11:45 -0400 From: "Howard, Lee" To: "curtis@occnc.com" Date: Fri, 21 Oct 2011 13:11:45 -0400 Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AcyQDVyORWxY8i+EQvqe72ozidE4/wABjJMw Message-ID: References: Your message of "Fri, 21 Oct 2011 11:31:41 EDT." <201110211620.p9LGKOGK013385@gateway.ipv6.occnc.com> In-Reply-To: <201110211620.p9LGKOGK013385@gateway.ipv6.occnc.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" , james woodyatt Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 21 Oct 2011 17:11:47 -0000 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Friday, October 21, 2011 12:20 PM > To: Howard, Lee > Cc: james woodyatt; curtis@occnc.com; homenet@ietf.org > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > > In message > e.com> > "Howard, Lee" writes: > > > > > > -----Original Message----- > > > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On B= ehalf Of > james > > > woodyatt > > > Sent: Monday, October 10, 2011 11:07 PM > > > To: curtis@occnc.com > > > Cc: homenet@ietf.org > > > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > > > > > On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote: > > > > > > > > All of this is only true for IPv4 but not for IPv6. > > > > > > I wasn't talking about IPv4 at all. My comments are relevant in a wo= rld entirely > comprising > > > IPv6-only service providers. The IPv6 Internet will be saddled with = all of the problems > of > > > the IPv4 Internet with respect to devices on homenets having to beg t= he gateways to > allow > > > inbound packets from arbitrary remote destinations. It has nothing t= o do with NAT, > and > > > everything to do with firewalls and stateful filters. > > > > s/beg/authorize > > > > That response seems to be confirming the problem. > > The customer should not need the ISP to authorize inbound traffic. > Otherwise the service should not be called an "Internet" service. It > is a service providing only limited Internet connectivity. Perhaps I misunderstood the scenario. I would have the sentence read: "Devices on homenets have to authorize gateways to allow inbound packets from arbitrary remote destinations." Hosts can set their own security policy. If it's "send me everything," it can signal a firewall (using e.g. PCP) to allow everything. If it's "do no= t call," it can signal a firewall (using e.g. PCP) to deny anything not explicitly allowed. I do not adhere to "default permit" as a security principle. Lee > Curtis 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 cb.list6@gmail.com Fri Oct 21 10:32:56 2011 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 BA19411E80BF for ; Fri, 21 Oct 2011 10:32:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfZeP5YlpsBN for ; Fri, 21 Oct 2011 10:32:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C465111E80AD for ; Fri, 21 Oct 2011 10:32:55 -0700 (PDT) Received: by gyh20 with SMTP id 20so4915277gyh.31 for ; Fri, 21 Oct 2011 10:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8g+OKmPaWZ6PfZ9AI+3Up7glopMuYM823AcT6fh+nKI=; b=DNDtePWQHLD/8G7dTQFoblhOMWBpvxGVHheLPyP6rimukqxXG+QiEhtdzxNbe+tNQ0 H7RTySwHX7CcP9N0Z0knptqmGUJvNCTDTN7fKY8EZh/l5kb971n8SeJ1OQ2x62phl08q YW6F/Ox/PVEeZ6mkTin80nuT4gpHjPMpTJ33I= MIME-Version: 1.0 Received: by 10.68.74.132 with SMTP id t4mr636832pbv.130.1319218374400; Fri, 21 Oct 2011 10:32:54 -0700 (PDT) Received: by 10.142.222.9 with HTTP; Fri, 21 Oct 2011 10:32:54 -0700 (PDT) Received: by 10.142.222.9 with HTTP; Fri, 21 Oct 2011 10:32:54 -0700 (PDT) In-Reply-To: References: <201110211620.p9LGKOGK013385@gateway.ipv6.occnc.com> Date: Fri, 21 Oct 2011 10:32:54 -0700 Message-ID: From: Cameron Byrne To: "Howard, Lee" Content-Type: multipart/alternative; boundary=f46d041b476e965a7604afd276a7 Cc: "homenet@ietf.org" , james woodyatt , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 21 Oct 2011 17:32:56 -0000 --f46d041b476e965a7604afd276a7 Content-Type: text/plain; charset=ISO-8859-1 On Oct 21, 2011 10:11 AM, "Howard, Lee" wrote: > > > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Friday, October 21, 2011 12:20 PM > > To: Howard, Lee > > Cc: james woodyatt; curtis@occnc.com; homenet@ietf.org > > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > > > > > In message > > > e.com> > > "Howard, Lee" writes: > > > > > > > > > -----Original Message----- > > > > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of > > james > > > > woodyatt > > > > Sent: Monday, October 10, 2011 11:07 PM > > > > To: curtis@occnc.com > > > > Cc: homenet@ietf.org > > > > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > > > > > > > On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote: > > > > > > > > > > All of this is only true for IPv4 but not for IPv6. > > > > > > > > I wasn't talking about IPv4 at all. My comments are relevant in a world entirely > > comprising > > > > IPv6-only service providers. The IPv6 Internet will be saddled with all of the problems > > of > > > > the IPv4 Internet with respect to devices on homenets having to beg the gateways to > > allow > > > > inbound packets from arbitrary remote destinations. It has nothing to do with NAT, > > and > > > > everything to do with firewalls and stateful filters. > > > > > > s/beg/authorize > > > > > > > > That response seems to be confirming the problem. > > > > The customer should not need the ISP to authorize inbound traffic. > > Otherwise the service should not be called an "Internet" service. It > > is a service providing only limited Internet connectivity. > > Perhaps I misunderstood the scenario. > I would have the sentence read: > "Devices on homenets have to authorize gateways to allow inbound packets > from arbitrary remote destinations." > > Hosts can set their own security policy. If it's "send me everything," it > can signal a firewall (using e.g. PCP) to allow everything. If it's "do not call," > it can signal a firewall (using e.g. PCP) to deny anything not explicitly > allowed. > > I do not adhere to "default permit" as a security principle. > Then you also do not care for supporting the e2e principle, and I thought I heard people mumble e2w was a good thing at the start of homenet. I am in the camp the host should be strong and smart and networks should be simple and fast. Cb > Lee > > > Curtis > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --f46d041b476e965a7604afd276a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


                    On Oct 21, 2011 10:11 AM, "Howard, Lee" <lee.howard@twcable.com> wrote:
                    >
                    >
                    >
                    > > -----Original Message-----
                    > > From: Curtis Villamizar [mailto:curtis@occnc.com]
                    > > Sent: Friday, October 21, 2011 12:20 PM
                    > > To: Howard, Lee
                    > > Cc: james woodyatt; curtis@oc= cnc.com; homenet@ietf.org
                    > > Subject: Re: [homenet] Homenet Architecture & Interim Meeting=
                    > >
                    > >
                    > > In message
                    > > <DCC302FAA9FE5F4BBA4DCAD46569377914513347E4@PRVPEXVS03.corp.tw= cabl
                    > > e.com>
                    > > "Howard, Lee" writes:
                    > >
                    > > >
                    > > > > -----Original Message-----
                    > > > > From: homen= et-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of
                    > > james
                    > > > > woodyatt
                    > > > > Sent: Monday, October 10, 2011 11:07 PM
                    > > > > To: curtis@occnc.co= m
                    > > > > Cc: homenet@ietf.or= g
                    > > > > Subject: Re: [homenet] Homenet Architecture & Inter= im Meeting
                    > > > >
                    > > > > On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote: > > > > >
                    > > > > > All of this is only true for IPv4 but not for IPv6= .
                    > > > >
                    > > > > I wasn't talking about IPv4 at all. =A0My comments = are relevant in a world entirely
                    > > comprising
                    > > > > IPv6-only service providers. =A0The IPv6 Internet will = be saddled with all of the problems
                    > > of
                    > > > > the IPv4 Internet with respect to devices on homenets h= aving to beg the gateways to
                    > > allow
                    > > > > inbound packets from arbitrary remote destinations. =A0= It has nothing to do with NAT,
                    > > and
                    > > > > everything to do with firewalls and stateful filters. > > >
                    > > > s/beg/authorize
                    > >
                    > >
                    > >
                    > > That response seems to be confirming the problem.
                    > >
                    > > The customer should not need the ISP to authorize inbound traffic= .
                    > > Otherwise the service should not be called an "Internet"= ; service. =A0It
                    > > is a service providing only limited Internet connectivity.
                    >
                    > Perhaps I misunderstood the scenario.
                    > I would have the sentence read:
                    > "Devices on homenets have to authorize gateways to allow inbound = packets
                    > from arbitrary remote destinations."
                    >
                    > Hosts can set their own security policy. =A0If it's "send me = everything," it
                    > can signal a firewall (using e.g. PCP) to allow everything. =A0If it&#= 39;s "do not call,"
                    > it can signal a firewall (using e.g. PCP) to deny anything not explici= tly
                    > allowed.
                    >
                    > I do not adhere to "default permit" as a security principle.=
                    >

                    Then you also do not care for supporting the e2e principle, and I though= t I heard people mumble e2w=A0 was a good thing at the start of homenet.

                    I am in the camp the host should be strong and smart and networks should= be simple and fast.

                    Cb

                    > Lee
                    >
                    > > Curtis
                    >
                    > This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely for = the use of the individual or entity to which it is addressed. If you are no= t the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the con= tents of and attachments to this E-mail is strictly prohibited and may be u= nlawful. If you have received this E-mail in error, please notify the sende= r immediately and permanently delete the original and any copy of this E-ma= il and any printout.
                    > _______________________________________________
                    > homenet mailing list
                    > homenet@ietf.org
                    > https://www.= ietf.org/mailman/listinfo/homenet

                    --f46d041b476e965a7604afd276a7-- From lee.howard@twcable.com Fri Oct 21 11:21:04 2011 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 900BB1F0C8A for ; Fri, 21 Oct 2011 11:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55JU6DhtXTQd for ; Fri, 21 Oct 2011 11:21:04 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D30091F0C62 for ; Fri, 21 Oct 2011 11:21:03 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,387,1315195200"; d="scan'208";a="273157555" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Oct 2011 14:17:24 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 21 Oct 2011 14:21:01 -0400 From: "Howard, Lee" To: Cameron Byrne Date: Fri, 21 Oct 2011 14:21:00 -0400 Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AcyQF3iE6J37xtxySSmQIF9MrZSwAQAAtYOg Message-ID: References: <201110211620.p9LGKOGK013385@gateway.ipv6.occnc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" , james woodyatt , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 21 Oct 2011 18:21:04 -0000 > > I do not adhere to "default permit" as a security principle. > > Then you also do not care for supporting the e2e principle, and I thought > I heard people mumble e2w was a good thing at the start of homenet. > I am in the camp the host should be strong and smart and networks should > be simple and fast. > > Cb Let's discuss the end-to-end principle and see how it applies here. rfc1958 quotes from [Saltzer]: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.") In this instance, the "function" could be considered either a) implementati= on of a forwarding policy, or b) the application sending/receiving packets. I= f (a), then is is being done "with the knowledge and help of the application,= " so the principle is intact. If (b), then the firewall is not attempting to implement that function, only to forward or not forward packets, and the principle is intact. All of the examples contemplated in rfc1958 and in the original paper are about adding processing to packet forwarding, such as error checking, encryption, or deduplication. In this case, the host (or application) is establishing a security policy, and asking for help enforcing that policy. A general security principle is to drop malicious traffic as close to the source as possible (rfc3013, rfc3871). "the end-to-end argument is not an absolute rule, but rather a guideline that helps in application and protoco= l design analysis" http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf People can argue that the end-to-end principle prohibits use of stateful fi= rewalls. I believe that properly implemented, where the host (application) sets the = policy and the gateway/firewall makes a forwarding decision, the principle is uphe= ld. 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 lee.howard@twcable.com Fri Oct 21 11:32:16 2011 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 22F6C21F8AFE for ; Fri, 21 Oct 2011 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18SOhtnBIFBV for ; Fri, 21 Oct 2011 11:32:14 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D475121F8AFC for ; Fri, 21 Oct 2011 11:32:13 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,387,1315195200"; d="scan'208,217";a="273163203" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Oct 2011 14:28:34 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 21 Oct 2011 14:32:11 -0400 From: "Howard, Lee" To: "homenet@ietf.org" Date: Fri, 21 Oct 2011 14:32:10 -0400 Thread-Topic: routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334AAFPRVPEXVS03cor_" MIME-Version: 1.0 Subject: [homenet] routing requirements 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, 21 Oct 2011 18:32:16 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334AAFPRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've caught up on some 300 messages about routing. Here are the requiremen= ts I've gleaned. Question marks are unclear to me, please help. 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solution= s against mutliple L2 types. 4. Border detection. a. Border may be upstream ISP, or may be a device that is a gateway t= o SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo = to home net. Or there may be no border, if no external connection has been= established. b. Must be able to find "up" (a path to the Internet), but must not be= dependent on "up" (Internet connectivity) existing for intra-home reachabi= lity. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device.= Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scena= rios. b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condi= tion? g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least,= not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be = able to use another in case on fails. 11. Prevent looping. 12. Prefix stability? 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. 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. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334AAFPRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                    I've caught up on some 300 messages about routing= .  Here are the requirements I've gleaned.  Question marks are un= clear to me, please help.

                     

                    1.      Homenet router requirements

                    2.      When evaluating a solution, discuss whether it prov= ides for:

                    3.      Reachability between all nodes in the home network.=

                    a.       Links may be Ethernet, WiFi, MoCA, or any other; te= st all solutions against mutliple L2 types.

                    4.      Border detection. 

                    a.       Border may be upstream ISP, or may be a device that= is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 80= 2.15.4 and foo to home net.  Or there may be no border, if no external con= nection has been established. 

                    b.      Must be able to find “up” (a path to th= e Internet), but must not be dependent on “up” (Internet connec= tivity) existing for intra-home reachability.

                    c.       May be discovered by routing protocol, or other mea= ns.

                    5.      Robust to routers being moved/added/removed/renumbe= red

                    a.       Convergence time a few minutes or less.<= /p>

                    6.      No configuration required.

                    a.       We might tolerate? a single password being entered = on each device.  Discuss.

                    7.      Best-path is a non-requirement.

                    8.      Support for multiple upstream networks is a require= ment.

                    a.       Including wireless offload, video-only, and split-t= unnel VPN scenarios. 

                    b.      With separate routers to each.  Not multihomed= off the same router.

                    c.       Prefix delegated from all ISPs (upstreams).

                    d.      ISP A is default.

                    e.       With only traffic destined to ISP B’s prefix = using that link.

                    f.       With a backup default to ISP B, if desired.  W= hat is default condition?

                    g.      Source address selection is out of scope.  And= should be solved by rfc3484, with longest prefix match (whether ULA or wal= led garden).  Choosing which address to use to look up the destination= address is out of scope.

                    9.      Cannot assume hierarchical prefix delegation in the= home (at least, not unless the WG develops such a solution).

                    10.  A host with mutliple upstream paths to the same des= tination should be able to use another in case on fails.

                    11.  Prevent looping.

                    12.  Prefix stability? 

                    13.  Lightweight (cheap) implementation.

                    Let me know if I’ve missed, or mistated, an= ything.

                     

                    Lee

                     


                    This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
                     --_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334AAFPRVPEXVS03cor_-- From curtis@occnc.com Fri Oct 21 11:38:24 2011 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 48D4F21F8B28 for ; Fri, 21 Oct 2011 11:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPyfRKQF+K3W for ; Fri, 21 Oct 2011 11:38:23 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6621F8B23 for ; Fri, 21 Oct 2011 11:38:23 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9LIcGpG030685; Fri, 21 Oct 2011 11:38:17 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9LIcGpG030685 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319222297; bh=0uwYeaL/HIAwv/Y8s6svBpV3bc2yTOJZnN1xQa+HGJs=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=Ny/mN7Wr1wAmc+p04rtPnGDBcIs6SuIgpL1c5BQSbMCQkZXPdwm5F3YDB1Qo5Go3E zbV5fpUfBD0nFFlG3meQHrk3JtB+bOjP2e108SI0fh4LIlBCBDrtlHin+WJAI4oncR QRrKlpbT31hv7H+EJBIXNA7QRaFeKrfwrwSAij0Y= Message-Id: <201110211838.p9LIcGpG030685@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 13:11:45 EDT." Date: Fri, 21 Oct 2011 11:38:16 -0700 Cc: "homenet@ietf.org" , james woodyatt , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:38:24 -0000 In message "Howard, Lee" writes: > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Friday, October 21, 2011 12:20 PM > > To: Howard, Lee > > Cc: james woodyatt; curtis@occnc.com; homenet@ietf.org > > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > > > > > In message > > > e.com> > > "Howard, Lee" writes: > > > > > > > > > -----Original Message----- > > > > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of > > james > > > > woodyatt > > > > Sent: Monday, October 10, 2011 11:07 PM > > > > To: curtis@occnc.com > > > > Cc: homenet@ietf.org > > > > Subject: Re: [homenet] Homenet Architecture & Interim Meeting > > > > > > > > On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote: > > > > > > > > > > All of this is only true for IPv4 but not for IPv6. > > > > > > > > I wasn't talking about IPv4 at all. My comments are relevant in a world entirely > > comprising > > > > IPv6-only service providers. The IPv6 Internet will be saddled with all of the problems > > of > > > > the IPv4 Internet with respect to devices on homenets having to beg the gateways to > > allow > > > > inbound packets from arbitrary remote destinations. It has nothing to do with NAT, > > and > > > > everything to do with firewalls and stateful filters. > > > > > > s/beg/authorize > > > > > > > > That response seems to be confirming the problem. > > > > The customer should not need the ISP to authorize inbound traffic. > > Otherwise the service should not be called an "Internet" service. It > > is a service providing only limited Internet connectivity. > > Perhaps I misunderstood the scenario. I would have the sentence read: > "Devices on homenets have to authorize gateways to allow inbound > packets from arbitrary remote destinations." > > Hosts can set their own security policy. If it's "send me > everything," it can signal a firewall (using e.g. PCP) to allow > everything. If it's "do not call," it can signal a firewall (using > e.g. PCP) to deny anything not explicitly allowed. > > I do not adhere to "default permit" as a security principle. > > Lee > > > Curtis Lee, Thanks for the prompt response. Seems it was a misunderstanding and we are in agreement. I'm not fond of PCP so if it were my home router, I'd configure the exceptions on the router. That should always be an option. Curtis From curtis@occnc.com Fri Oct 21 11:49:58 2011 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 24B6111E8081 for ; Fri, 21 Oct 2011 11:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqmxm7UABzpG for ; Fri, 21 Oct 2011 11:49:57 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3D21F0C94 for ; Fri, 21 Oct 2011 11:49:57 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9LInoFh030890; Fri, 21 Oct 2011 11:49:51 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9LInoFh030890 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319222991; bh=DRLx1b0QG1f4kiMW3ZWV/w/xhrDhrjGWJvnNWSdkY3k=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=AG6ZXOakUfEkzgMi2OxYxU2edYTP3ToBNgG9KR35EFw4mYYns35hI7fiyexAXM6Mf YtNwisGLc6s+0xJOzJKlWYMBuNQmJmjSbrSw3U9kQGWBcC4+WEKd8zUTGzaEHYOuuB 4DjRqNLABcwBwccCCgDAJtmq51dtxp4e/lR1ZSjg= Message-Id: <201110211849.p9LInoFh030890@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 14:21:00 EDT." Date: Fri, 21 Oct 2011 11:49:50 -0700 Cc: Cameron Byrne , "homenet@ietf.org" , james woodyatt , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:49:58 -0000 In message "Howard, Lee" writes: > > > I do not adhere to "default permit" as a security principle. > > > > Then you also do not care for supporting the e2e principle, and I thought > > I heard people mumble e2w was a good thing at the start of homenet. > > I am in the camp the host should be strong and smart and networks should > > be simple and fast. > > > > Cb > > Let's discuss the end-to-end principle and see how it applies here. > > rfc1958 quotes from [Saltzer]: > "The function in question can completely and > correctly be implemented only with the knowledge and help of the > application standing at the endpoints of the communication system. > Therefore, providing that questioned function as a feature of the > communication system itself is not possible. (Sometimes an incomplete > version of the function provided by the communication system may be > useful as a performance enhancement.") > > In this instance, the "function" could be considered either a) > implementation of a forwarding policy, or b) the application > sending/receiving packets. If (a), then is is being done "with the > knowledge and help of the application," so the principle is intact. > If (b), then the firewall is not attempting to implement that > function, only to forward or not forward packets, and the principle is > intact. > > All of the examples contemplated in rfc1958 and in the original paper > are about adding processing to packet forwarding, such as error > checking, encryption, or deduplication. In this case, the host (or > application) is establishing a security policy, and asking for help > enforcing that policy. > > A general security principle is to drop malicious traffic as close to > the source as possible (rfc3013, rfc3871). > > "the end-to-end argument is not an absolute rule, but rather a > guideline that helps in application and protocol design analysis" > http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > > > People can argue that the end-to-end principle prohibits use of > stateful firewalls. I believe that properly implemented, where the > host (application) sets the policy and the gateway/firewall makes a > forwarding decision, the principle is upheld. > > Lee Lee, What people are arguing is a violation of the end-to-end principle is having a provider put in place filters that can't be shut of by the consumer. It would be preferable if the consumer could shut them off completely with at most one support call and then take responsibility themselves or better yet have configuration control over the firewall. If a mechanism is provided to poke pinholes, that may be acceptable to some. PCP may not be acceptable to many, preferring a configuration (persistent) change to the firewall. I for one would rather you shut off any firewall that you provide and leave it to me (and I would find another provider if you couldn't do that). But that is not typical. Curtis From curtis@occnc.com Fri Oct 21 12:04:10 2011 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 353E321F8B35 for ; Fri, 21 Oct 2011 12:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaloDp3EWr0s for ; Fri, 21 Oct 2011 12:04:09 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 5C07821F8B12 for ; Fri, 21 Oct 2011 12:04:09 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9LJ43CK031266; Fri, 21 Oct 2011 12:04:03 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9LJ43CK031266 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319223844; bh=sCOcKvzX9ZUgWtxmRi8iNHN+6qw0c4cxs6vTQB7XYyU=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=R39BDDS8QDKEp8RleySPEEMl3NWXFfiLMyvRcY1iiYYXIzjXWBGRIjUVOG7eMi/JR +UjZNAQbkSL3f4lIQQ18UGWQhNhNYI+TtRJ03jNM7LhZl460gu4QUhlf/P/eA7dkgl z/bMFRah4/Pv0NYNlcNSK8XR0kkFcYVY3YJWuYXw= Message-Id: <201110211904.p9LJ43CK031266@gateway.ipv6.occnc.com> To: Cameron Byrne From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 10:32:54 PDT." Date: Fri, 21 Oct 2011 12:04:03 -0700 Cc: "Howard, Lee" , "homenet@ietf.org" , james woodyatt , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:04:10 -0000 In message Cameron Byrne writes: > I am in the camp the host should be strong and smart and networks > should be simple and fast. > > Cb Same here but we can't get rid of all the windows systems out there. So service providers are compelled to put firewalls in front of consumer customers (and even most small business) and have them enabled by default. To not do so would result in the service provider having a network of malicious bots (as opposed to a network containing a subset of sites running malware that the service provider couldn't prevent). Back in the early 1990s I argued that we should not let windows systems on the Internet. That was back when your network (college campuses, corporations, etc) could be shut down by a provider if attacks were coming out of it and you did nothing to completely eradicate it. An example of this was Mitnik breaking into a university in Houston and Sesquinet shutting off their Internet for four days due to a computer science department response that security was a hard problem and from a practical standpoint there was nothing they could do about it. Back then, if you couldn't make it secure, it didn't belong on the Internet. I do see your point and agree with you. From a technical perspective, firewalls are an inadequate bandaid over a set of OS and application security problems and the right thing to do is fix the root casue. Curtis From cb.list6@gmail.com Fri Oct 21 12:31:17 2011 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 A0AC021F8B6D for ; Fri, 21 Oct 2011 12:31:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCwvoWrQZ0LU for ; Fri, 21 Oct 2011 12:31:17 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E938621F8B6C for ; Fri, 21 Oct 2011 12:31:16 -0700 (PDT) Received: by qadc10 with SMTP id c10so1767226qad.31 for ; Fri, 21 Oct 2011 12:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Hqod0tihrGPeotkDKNIIzr+tJcvcHAupOGapf+hcsJ4=; b=k5yEhtcjQhaDc+dF1uYikF6SP5ShAlhZ0X1w1E46E0SWAAKkqSElWwmgYC8Zq9JfAe R3+gXgWoZFZx1d+15BG4SHbQ6KOY2DH4aiCi+nOrJWZU4qcaVh75ywVLJJ3NPNJdILRt EEj47f33KRUF+3nqZGtmtDUzBLspRxuuXIKcE= MIME-Version: 1.0 Received: by 10.68.74.132 with SMTP id t4mr1294594pbv.130.1319225475236; Fri, 21 Oct 2011 12:31:15 -0700 (PDT) Received: by 10.142.222.9 with HTTP; Fri, 21 Oct 2011 12:31:14 -0700 (PDT) In-Reply-To: <201110211904.p9LJ43CK031266@gateway.ipv6.occnc.com> References: <201110211904.p9LJ43CK031266@gateway.ipv6.occnc.com> Date: Fri, 21 Oct 2011 12:31:14 -0700 Message-ID: From: Cameron Byrne To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Howard, Lee" , "homenet@ietf.org" , james woodyatt Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 21 Oct 2011 19:31:17 -0000 On Fri, Oct 21, 2011 at 12:04 PM, Curtis Villamizar wrot= e: > > In message > Cameron Byrne writes: > >> I am in the camp the host should be strong and smart and networks >> should be simple and fast. >> >> Cb > > Same here but we can't get rid of all the windows systems out there. > Why? Even windows XP comes with a host based firewall since 2003 ... That's coming up on 10 years by the time homenet influences the market. . blah blah blah... we all must engineer for the least common denominator because somebody out there can be attacked by the Morris Worm still... And, most (cite?) actual attacks are not preventable with a $30 home router. Most (cite?) homenet security issues are relate to phishing and users downloading and installing malware with admin privilege, which PCP and stateful firewalls cannot solve. > So service providers are compelled to put firewalls in front of > consumer customers (and even most small business) and have them > enabled by default. > > To not do so would result in the service provider having a network of > malicious bots (as opposed to a network containing a subset of sites > running malware that the service provider couldn't prevent). > Is there proof that $30 home routers protect computers and "move the needle" on malware? Or is this left over mindset from the 1990s? > Back in the early 1990s I argued that we should not let windows > systems on the Internet. =A0That was back when your network (college > campuses, corporations, etc) could be shut down by a provider if > attacks were coming out of it and you did nothing to completely > eradicate it. =A0An example of this was Mitnik breaking into a > university in Houston and Sesquinet shutting off their Internet for > four days due to a computer science department response that security > was a hard problem and from a practical standpoint there was nothing > they could do about it. =A0Back then, if you couldn't make it secure, it > didn't belong on the Internet. > Would a firewall stopped this or was this social engineering? Also, this is not the 1990s... Things are indeed better now from a network programming perspective. Social engineering and so on are a different layer. > I do see your point and agree with you. =A0From a technical perspective, > firewalls are an inadequate bandaid over a set of OS and application > security problems and the right thing to do is fix the root casue. > ^^^^ Good stuff there. Lets focus on that instead of the dogma and FUD to create "homenet" of the future. Thanks, Cameron > Curtis > From d.sturek@att.net Fri Oct 21 13:44:50 2011 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 174CA21F8AF8 for ; Fri, 21 Oct 2011 13:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lADlrTHhMzRc for ; Fri, 21 Oct 2011 13:44:49 -0700 (PDT) Received: from nm35-vm6.bullet.mail.ne1.yahoo.com (nm35-vm6.bullet.mail.ne1.yahoo.com [98.138.229.102]) by ietfa.amsl.com (Postfix) with SMTP id 5A12021F8AF7 for ; Fri, 21 Oct 2011 13:44:49 -0700 (PDT) Received: from [98.138.90.56] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2011 20:44:45 -0000 Received: from [98.138.226.59] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2011 20:44:45 -0000 Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP; 21 Oct 2011 20:44:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1319229885; bh=kH3FdiTzK74CF3gkQJvNJY5ay7QS4n2f2Gw5DmRtv6I=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Date:Subject:Message-ID:From:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=z85Jp4Z5lyQPhH+Im878Q0I62lpUpXbSAd0IiQpI1Lm3HhqWDjJln2KBrKbUftqviFD5zdorhtC4uRtzAYt1f12fxwQm+ijj8G7c5lquTGoqzGeJEwTkzsiOvO7nitV7VutJ8HJLYEV6wi3fQqGpaUJkAW5BCBxoShfs/rAs3Sc= X-Yahoo-Newman-Id: 239129.36638.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: y2FuPwwVM1lEW4wplR5YzhUzhP43hyfF8Tk45VJn97zPIYQ 5Ap1qFz9XXx2NPHPzQcoyoYuoEAnETpiththENB9RKjmytMM6cbPiWfWhoNS h38TSTyrUsRxK89M_uvx3znh3ezko7kNxOMYVQSRj6o4PE1T_tIgtU96tU_v 6xdroKSTzjGbIOLqMNNgnebbFYVbE4BBHD0zppsOGwRnn50s28JoYATHin1j A7rlxoZif31IJC.mTs0z4TLfxd8USg8SikN.rTKwNNbJQ207zY19DCN3qLaB aeJBz82DZ762jl5CJ6jNWm2oe_t0ougf0_P2R6vZo0uFoDqWS.oEt.g_vc4i xZI.64_xDGsascR6Am2k.2lwifw7CVPKv103XQO4pCOmBIt9WDSn9ipcR012 bPA8_FZZrBlPLzk_dpsXl6Buz81.mIsWRNFR6LGBqzcBVowYM3WbMnns.gp5 rVKVA_U84 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from 26.205.77.234 (d.sturek@208.54.5.180 with plain) by smtp210.mail.ne1.yahoo.com with SMTP; 21 Oct 2011 13:44:27 -0700 PDT Date: Fri, 21 Oct 2011 11:53:20 -0700 Message-ID: From: Don Sturek To: "Howard, Lee" , "homenet@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [homenet] routing requirements 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, 21 Oct 2011 20:44:50 -0000 SGkgTGVlLAoKSSBsaWtlIHRoaXMgbGlzdCBvZiByZXF1aXJlbWVudHMhCgpPbmUgdGhpbmc6ICBp ZiB0aGUgcmVxdWlyZW1lbnRzIG9uIHJvdXRpbmcgdG8gdGhlIGludGVybmV0IHVzaW5nIHRoZSBh bHRlcm5hdGUgcHJlZml4IHByb3ZlcyB0b28gY29tcGxpY2F0ZWQgb24gYSBmaXJld2FsbGVkIGlu dGVyZmFjZSB3ZSBzaG91bGQgZGVmZXIgdGhhdCBmZWF0dXJlLgoKRG9uCgpTZW50IGZyb20gVC1N b2JpbGUgRzIgd2l0aCBHb29nbGUKCiJIb3dhcmQsIExlZSIgPGxlZS5ob3dhcmRAdHdjYWJsZS5j b20+IHdyb3RlOgoKPkkndmUgY2F1Z2h0IHVwIG9uIHNvbWUgMzAwIG1lc3NhZ2VzIGFib3V0IHJv dXRpbmcuICBIZXJlIGFyZSB0aGUgcmVxdWlyZW1lbnRzIEkndmUgZ2xlYW5lZC4gIFF1ZXN0aW9u IG1hcmtzIGFyZSB1bmNsZWFyIHRvIG1lLCBwbGVhc2UgaGVscC4KPgo+Cj4KPjEuICAgICAgSG9t ZW5ldCByb3V0ZXIgcmVxdWlyZW1lbnRzCj4KPjIuICAgICAgV2hlbiBldmFsdWF0aW5nIGEgc29s dXRpb24sIGRpc2N1c3Mgd2hldGhlciBpdCBwcm92aWRlcyBmb3I6Cj4KPjMuICAgICAgUmVhY2hh YmlsaXR5IGJldHdlZW4gYWxsIG5vZGVzIGluIHRoZSBob21lIG5ldHdvcmsuCj4KPmEuICAgICAg IExpbmtzIG1heSBiZSBFdGhlcm5ldCwgV2lGaSwgTW9DQSwgb3IgYW55IG90aGVyOyB0ZXN0IGFs bCBzb2x1dGlvbnMgYWdhaW5zdCBtdXRsaXBsZSBMMiB0eXBlcy4KPgo+NC4gICAgICBCb3JkZXIg ZGV0ZWN0aW9uLgo+Cj5hLiAgICAgICBCb3JkZXIgbWF5IGJlIHVwc3RyZWFtIElTUCwgb3IgbWF5 IGJlIGEgZGV2aWNlIHRoYXQgaXMgYSBnYXRld2F5IHRvIFNtYXJ0R3JpZCBkZXZpY2VzLCBlLmcu IGEgY29udHJvbGxlciB0aGF0IHNwZWFrcyBSUEwgdG8gODAyLjE1LjQgYW5kIGZvbyB0byBob21l IG5ldC4gIE9yIHRoZXJlIG1heSBiZSBubyBib3JkZXIsIGlmIG5vIGV4dGVybmFsIGNvbm5lY3Rp b24gaGFzIGJlZW4gZXN0YWJsaXNoZWQuCj4KPmIuICAgICAgTXVzdCBiZSBhYmxlIHRvIGZpbmQg InVwIiAoYSBwYXRoIHRvIHRoZSBJbnRlcm5ldCksIGJ1dCBtdXN0IG5vdCBiZSBkZXBlbmRlbnQg b24gInVwIiAoSW50ZXJuZXQgY29ubmVjdGl2aXR5KSBleGlzdGluZyBmb3IgaW50cmEtaG9tZSBy ZWFjaGFiaWxpdHkuCj4KPmMuICAgICAgIE1heSBiZSBkaXNjb3ZlcmVkIGJ5IHJvdXRpbmcgcHJv dG9jb2wsIG9yIG90aGVyIG1lYW5zLgo+Cj41LiAgICAgIFJvYnVzdCB0byByb3V0ZXJzIGJlaW5n IG1vdmVkL2FkZGVkL3JlbW92ZWQvcmVudW1iZXJlZAo+Cj5hLiAgICAgICBDb252ZXJnZW5jZSB0 aW1lIGEgZmV3IG1pbnV0ZXMgb3IgbGVzcy4KPgo+Ni4gICAgICBObyBjb25maWd1cmF0aW9uIHJl cXVpcmVkLgo+Cj5hLiAgICAgICBXZSBtaWdodCB0b2xlcmF0ZT8gYSBzaW5nbGUgcGFzc3dvcmQg YmVpbmcgZW50ZXJlZCBvbiBlYWNoIGRldmljZS4gIERpc2N1c3MuCj4KPjcuICAgICAgQmVzdC1w YXRoIGlzIGEgbm9uLXJlcXVpcmVtZW50Lgo+Cj44LiAgICAgIFN1cHBvcnQgZm9yIG11bHRpcGxl IHVwc3RyZWFtIG5ldHdvcmtzIGlzIGEgcmVxdWlyZW1lbnQuCj4KPmEuICAgICAgIEluY2x1ZGlu ZyB3aXJlbGVzcyBvZmZsb2FkLCB2aWRlby1vbmx5LCBhbmQgc3BsaXQtdHVubmVsIFZQTiBzY2Vu YXJpb3MuCj4KPmIuICAgICAgV2l0aCBzZXBhcmF0ZSByb3V0ZXJzIHRvIGVhY2guICBOb3QgbXVs dGlob21lZCBvZmYgdGhlIHNhbWUgcm91dGVyLgo+Cj5jLiAgICAgICBQcmVmaXggZGVsZWdhdGVk IGZyb20gYWxsIElTUHMgKHVwc3RyZWFtcykuCj4KPmQuICAgICAgSVNQIEEgaXMgZGVmYXVsdC4K Pgo+ZS4gICAgICAgV2l0aCBvbmx5IHRyYWZmaWMgZGVzdGluZWQgdG8gSVNQIEIncyBwcmVmaXgg dXNpbmcgdGhhdCBsaW5rLgo+Cj5mLiAgICAgICBXaXRoIGEgYmFja3VwIGRlZmF1bHQgdG8gSVNQ IEIsIGlmIGRlc2lyZWQuICBXaGF0IGlzIGRlZmF1bHQgY29uZGl0aW9uPwo+Cj5nLiAgICAgIFNv dXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBpcyBvdXQgb2Ygc2NvcGUuICBBbmQgc2hvdWxkIGJlIHNv bHZlZCBieSByZmMzNDg0LCB3aXRoIGxvbmdlc3QgcHJlZml4IG1hdGNoICh3aGV0aGVyIFVMQSBv ciB3YWxsZWQgZ2FyZGVuKS4gIENob29zaW5nIHdoaWNoIGFkZHJlc3MgdG8gdXNlIHRvIGxvb2sg dXAgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgb3V0IG9mIHNjb3BlLgo+Cj45LiAgICAgIENh bm5vdCBhc3N1bWUgaGllcmFyY2hpY2FsIHByZWZpeCBkZWxlZ2F0aW9uIGluIHRoZSBob21lIChh dCBsZWFzdCwgbm90IHVubGVzcyB0aGUgV0cgZGV2ZWxvcHMgc3VjaCBhIHNvbHV0aW9uKS4KPgo+ MTAuICBBIGhvc3Qgd2l0aCBtdXRsaXBsZSB1cHN0cmVhbSBwYXRocyB0byB0aGUgc2FtZSBkZXN0 aW5hdGlvbiBzaG91bGQgYmUgYWJsZSB0byB1c2UgYW5vdGhlciBpbiBjYXNlIG9uIGZhaWxzLgo+ Cj4xMS4gIFByZXZlbnQgbG9vcGluZy4KPgo+MTIuICBQcmVmaXggc3RhYmlsaXR5Pwo+Cj4xMy4g IExpZ2h0d2VpZ2h0IChjaGVhcCkgaW1wbGVtZW50YXRpb24uCj4KPkxldCBtZSBrbm93IGlmIEkn dmUgbWlzc2VkLCBvciBtaXN0YXRlZCwgYW55dGhpbmcuCj4KPgo+Cj5MZWUKPgo+Cj4KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZv cm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRv IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlz IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiBy ZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWls IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNv cHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4KPgo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPmhvbWVuZXQgbWFpbGluZyBsaXN0Cj5ob21l bmV0QGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVu ZXQK From gettysjim@gmail.com Fri Oct 21 13:50:11 2011 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 922411F0C3E for ; Fri, 21 Oct 2011 13:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1qhNU2VkPpA for ; Fri, 21 Oct 2011 13:50:11 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C8F611F0C35 for ; Fri, 21 Oct 2011 13:50:10 -0700 (PDT) Received: by qyk34 with SMTP id 34so912907qyk.10 for ; Fri, 21 Oct 2011 13:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lvMIwN5hb5lYwNevBiIOTioGsH0X6a0CSac3kSyPRrE=; b=wWr3I8ItRWVlnZ5fav8O/85tvf1sY+MKy3Pkd2zp7vZYzWHLfF8CcS8kNQBV/CXjNr ft5PE/NOPRlFPjae7GR939WOBaqfYAT4OANOWz8zsY+S8ERXCLr6qWVM6jK0epQM7q6m vhpwtbcYZSEJJuCAu+N/gfxDfYXM2xM9Le9t0= Received: by 10.229.216.6 with SMTP id hg6mr623290qcb.200.1319230210183; Fri, 21 Oct 2011 13:50:10 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id et6sm16394372qab.4.2011.10.21.13.50.08 (version=SSLv3 cipher=OTHER); Fri, 21 Oct 2011 13:50:09 -0700 (PDT) Sender: Jim Gettys Message-ID: <4EA1DAFF.6080500@freedesktop.org> Date: Fri, 21 Oct 2011 16:50:07 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Howard, Lee" , "homenet@ietf.org" Subject: Re: [homenet] routing requirements 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, 21 Oct 2011 20:50:11 -0000 On 10/21/2011 02:53 PM, Don Sturek wrote: > Hi Lee, > > I like this list of requirements! > > One thing: if the requirements on routing to the internet using the alternate prefix proves too complicated on a firewalled interface we should defer that feature. > > Don > > Sent from T-Mobile G2 with Google > > "Howard, Lee" wrote: > >> I've caught up on some 300 messages about routing. Here are the requirements I've gleaned. Question marks are unclear to me, please help. >> >> >> >> 1. Homenet router requirements >> >> 2. When evaluating a solution, discuss whether it provides for: >> >> 3. Reachability between all nodes in the home network. >> >> a. Links may be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple L2 types. >> >> 4. Border detection. >> >> a. Border may be upstream ISP, or may be a device that is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to home net. Or there may be no border, if no external connection has been established. >> >> b. Must be able to find "up" (a path to the Internet), but must not be dependent on "up" (Internet connectivity) existing for intra-home reachability. >> >> c. May be discovered by routing protocol, or other means. >> >> 5. Robust to routers being moved/added/removed/renumbered >> >> a. Convergence time a few minutes or less. >> >> 6. No configuration required. >> >> a. We might tolerate? a single password being entered on each device. Discuss. >> >> 7. Best-path is a non-requirement. >> >> 8. Support for multiple upstream networks is a requirement. >> >> a. Including wireless offload, video-only, and split-tunnel VPN scenarios. >> >> b. With separate routers to each. Not multihomed off the same router. >> >> c. Prefix delegated from all ISPs (upstreams). >> >> d. ISP A is default. >> >> e. With only traffic destined to ISP B's prefix using that link. >> >> f. With a backup default to ISP B, if desired. What is default condition? >> >> g. Source address selection is out of scope. And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden). Choosing which address to use to look up the destination address is out of scope. >> >> 9. Cannot assume hierarchical prefix delegation in the home (at least, not unless the WG develops such a solution). >> >> 10. A host with mutliple upstream paths to the same destination should be able to use another in case on fails. >> >> 11. Prevent looping. >> >> 12. Prefix stability? >> >> 13. Lightweight (cheap) implementation. >> >> Let me know if I've missed, or mistated, anything. A couple missed: reference the scars on my back I discussed earlier: Scalability analysis, both for the dense mesh case, and the non-dense case, Behaviour/scaling when run on wireless, and its ability to handle both wired and wireless links. Robustness in the face of unintentional joining of networks. - Jim From samita.chakrabarti@ericsson.com Fri Oct 21 14:08:00 2011 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 70C8121F8B23 for ; Fri, 21 Oct 2011 14:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9TBbCGmpA7A for ; Fri, 21 Oct 2011 14:07:57 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C017F21F8B12 for ; Fri, 21 Oct 2011 14:07:57 -0700 (PDT) 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 p9LL7uvG025496; Fri, 21 Oct 2011 16:07:57 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 21 Oct 2011 17:07:50 -0400 From: Samita Chakrabarti To: "Howard, Lee" , "homenet@ietf.org" Date: Fri, 21 Oct 2011 17:07:49 -0400 Thread-Topic: routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQ Message-ID: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_16D60F43CA0B724F8052D7E9323565D7243F7EB0BBEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [homenet] routing requirements 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, 21 Oct 2011 21:08:00 -0000 --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB0BBEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Howard, Thank you very much for the summary of messages. A comment on item 12: 12. Prefix stability? SC> I expect that 'Prefix Stability' is a requirement at home or small off= ices. Without prefix stability some of the applications will suddenly break= when the old prefix expires and the new prefix becomes effective. And question to the wg: 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. SC> Is the expectation from homenet wg that all hosts will implement RFC 3= 484 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think = so ] So the host implementation change should be required if a host has to= support multiple prefixes or I might be missing something? Thanks, -Samita ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requiremen= ts I've gleaned. Question marks are unclear to me, please help. 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solution= s against mutliple L2 types. 4. Border detection. a. Border may be upstream ISP, or may be a device that is a gateway t= o SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo = to home net. Or there may be no border, if no external connection has been= established. b. Must be able to find "up" (a path to the Internet), but must not be= dependent on "up" (Internet connectivity) existing for intra-home reachabi= lity. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device.= Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scena= rios. b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condi= tion? g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least,= not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be = able to use another in case on fails. 11. Prevent looping. 12. Prefix stability? 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. 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. --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB0BBEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
                    Hello Howard,
                     
                    Thank you very much for the summary of=20 messages.
                     
                    A comment on item 12:
                    12.  Prefix stability? 
                     
                    SC>  I expect that 'Prefix Stability' is= a=20 requirement at home or small offices. Without prefix stability some of the= =20 applications will suddenly break when the old prefix expires and the new pr= efix=20 becomes effective.
                     
                    And question to the wg:

                    =  

                    8.     =20 Support for multiple upstream networks is a=20 requirement.

                    = g.     =20 Source address selection is out of scope.  And should be= =20 solved by rfc3484, with longest prefix match (whether ULA or walled=20 garden).  Choosing which address to use to look up the destination add= ress=20 is out of scope.

                    =  

                    = SC&g= t;  Is=20 the expectation from homenet wg that all hosts will implement RFC 3484=20 ?

                    = Do t= he current=20 home IPv6 host products support  RFC 3484 ? [ I don't think so ] = So=20 the host implementation change should be required if a host has t= o=20 support multiple prefixes or I might be missing=20 something?

                    =  

                    =  

                    = Thanks,

                    = -Samita

                    =  

                    =  

                    From: homenet-bounces@ietf.org=20 [mailto:homenet-bounces@ietf.org] On Behalf Of Howard,=20 Lee
                    Sent: Friday, October 21, 2011 11:32 AM
                    To:=20 homenet@ietf.org
                    Subject: [homenet] routing=20 requirements

                    I've caught up on some 300 messages about routing.&= nbsp;=20 Here are the requirements I've gleaned.  Question marks are unclear to= me,=20 please help.

                     

                    1.     =20 Homenet router requirements

                    2.     =20 When evaluating a solution, discuss whether it prov= ides=20 for:

                    3.     =20 Reachability between all nodes in the home=20 network.

                    = a.      = =20 Links may be Ethernet, WiFi, MoCA, or any other; te= st=20 all solutions against mutliple L2 types.

                    4.     =20 Border detection. 

                    = a.      = =20 Border may be upstream ISP, or may be a device that= is a=20 gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4= and=20 foo to home net.  Or there may be no border, if no external=20 connection has been established. 

                    = b.     =20 Must be able to find “up” (a path to th= e Internet), but=20 must not be dependent on “up” (Internet connectivity) existing = for intra-home=20 reachability.

                    = c.      = =20 May be discovered by routing protocol, or other=20 means.

                    5.     =20 Robust to routers being=20 moved/added/removed/renumbered

                    = a.      = =20 Convergence time a few minutes or less.<= /P>

                    6.     =20 No configuration required.

                    = a.      = =20 We might tolerate? a single password being entered = on=20 each device.  Discuss.

                    7.     =20 Best-path is a non-requirement.

                    8.     =20 Support for multiple upstream networks is a=20 requirement.

                    = a.      = =20 Including wireless offload, video-only, and split-t= unnel=20 VPN scenarios. 

                    = b.     =20 With separate routers to each.  Not multihomed= off=20 the same router.

                    = c.      = =20 Prefix delegated from all ISPs=20 (upstreams).

                    = d.     =20 ISP A is default.

                    = e.      = =20 With only traffic destined to ISP B’s prefix = using that=20 link.

                    = f.      = =20 With a backup default to ISP B, if desired.  W= hat=20 is default condition?

                    = g.     =20 Source address selection is out of scope.  And= =20 should be solved by rfc3484, with longest prefix match (whether ULA or wall= ed=20 garden).  Choosing which address to use to look up the destination add= ress=20 is out of scope.

                    9.     =20 Cannot assume hierarchical prefix delegation in the= home=20 (at least, not unless the WG develops such a solution).

                    10.&= nbsp;=20 A host with mutliple upstream paths to the same=20 destination should be able to use another in case on fails.

                    11.&= nbsp;=20 Prevent looping.

                    12.&= nbsp;=20 Prefix stability? 

                    13.&= nbsp;=20 Lightweight (cheap) implementation.

                    Let me know if I’ve missed, or mistated,=20 anything.

                     

                    Lee

                     


                    This E-mail and any of its attachm= ents may=20 contain Time Warner Cable proprietary information, which is privileged,=20 confidential, or subject to copyright belonging to Time Warner Cable. This= =20 E-mail is intended solely for the use of the individual or entity to which = it is=20 addressed. If you are not the intended recipient of this E-mail, you are he= reby=20 notified that any dissemination, distribution, copying, or action taken in= =20 relation to the contents of and attachments to this E-mail is strictly=20 prohibited and may be unlawful. If you have received this E-mail in error,= =20 please notify the sender immediately and permanently delete the original an= d any=20 copy of this E-mail and any printout.
                     --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB0BBEUSAACMS0715e_-- From lee.howard@twcable.com Fri Oct 21 14:08:14 2011 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 D59B121F8B2E for ; Fri, 21 Oct 2011 14:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kQu+0LR6w0E for ; Fri, 21 Oct 2011 14:08:14 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5DECE21F8B12 for ; Fri, 21 Oct 2011 14:08:14 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,388,1315195200"; d="scan'208";a="273241814" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Oct 2011 17:04:36 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 21 Oct 2011 17:08:13 -0400 From: "Howard, Lee" To: Jim Gettys , Don Sturek Date: Fri, 21 Oct 2011 17:08:14 -0400 Thread-Topic: [homenet] routing requirements Thread-Index: AcyQMwaUF24/xc35SU2EyARQxidUEQAAmX+w Message-ID: References: <4EA1DAFF.6080500@freedesktop.org> In-Reply-To: <4EA1DAFF.6080500@freedesktop.org> 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" Subject: Re: [homenet] routing requirements 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, 21 Oct 2011 21:08:14 -0000 > -----Original Message----- > From: Jim Gettys [mailto:gettysjim@gmail.com] On Behalf Of Jim Gettys > >> > >> Let me know if I've missed, or mistated, anything. > > A couple missed: reference the scars on my back I discussed earlier: > > Scalability analysis, both for the dense mesh case, and the non-dense cas= e, > > Behaviour/scaling when run on wireless, and its ability to handle both > wired and wireless links. > > Robustness in the face of unintentional joining of networks. > - Jim > Yes, I missed those, and have added them to my list. 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 lee.howard@twcable.com Fri Oct 21 14:22:33 2011 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 DFAC011E8083 for ; Fri, 21 Oct 2011 14:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNsuI7XZsL9w for ; Fri, 21 Oct 2011 14:22:33 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5F11E8082 for ; Fri, 21 Oct 2011 14:22:33 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,388,1315195200"; d="scan'208";a="288304632" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Oct 2011 17:18:50 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 21 Oct 2011 17:22:32 -0400 From: "Howard, Lee" To: Cameron Byrne , "curtis@occnc.com" Date: Fri, 21 Oct 2011 17:22:32 -0400 Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AcyQKAD2HSrSPmxhT0KWNeR9SsbR0AADb4kw Message-ID: References: <201110211904.p9LJ43CK031266@gateway.ipv6.occnc.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" , james woodyatt Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 21 Oct 2011 21:22:34 -0000 I've had some of these arguments before, but I'll write them down now so there's a record. Maybe we should document the debated points in a discussion draft, so we could invite further comment. > And, most (cite?) actual attacks are not preventable with a $30 home > router. Most (cite?) homenet security issues are relate to phishing > and users downloading and installing malware with admin privilege, > which PCP and stateful firewalls cannot solve. Port scanning is largely blocked by stateful firewalls. Thus it's not the prevention of actual attacks, but the fact that attacks don't exist because they're useless given the existence of firewalls. > > So service providers are compelled to put firewalls in front of > > consumer customers (and even most small business) and have them > > enabled by default. btw, I realize we operated from different assumptions. My default view is that the customer manages the gateway/firewall, not the ISP (or maybe in addition to the ISP). So in my world view, it's clear that the user (or host, or application) sets the security policy, which is enforced by the firewall. So if one OS believes it is invulnerable, it can signal the fire= wall to allow all traffic to it. If another OS wants defense in depth, it can signal the firewall to allow only wanted traffic. You may s/OS/app. > Is there proof that $30 home routers protect computers and "move the > needle" on malware? Or is this left over mindset from the 1990s? I argue they hold the needle on malware, and there's no reason to make it easier to attack ignorant users. Somebody else once said: > There are no attacks in IPv6, what are we protecting against? We should design security in before there are attacks, not wait and see what gets attacked. To be constructive, I would like home routers (or at least home border gateways) have a "default deny" security policy, which can be overriden by user configuration or signaling from internal hosts that traffic is wanted. "Signaling" could be PCP, uPNP, SYN, etc. 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 lee.howard@twcable.com Fri Oct 21 14:26:26 2011 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 CBB0721F858D for ; Fri, 21 Oct 2011 14:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJMHe8SpwXiE for ; Fri, 21 Oct 2011 14:26:24 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A7C1121F858C for ; Fri, 21 Oct 2011 14:26:23 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,388,1315195200"; d="scan'208,217";a="288305922" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Oct 2011 17:22:31 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 21 Oct 2011 17:26:13 -0400 From: "Howard, Lee" To: Samita Chakrabarti , "homenet@ietf.org" Date: Fri, 21 Oct 2011 17:26:14 -0400 Thread-Topic: routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQAAEKcrA= Message-ID: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> In-Reply-To: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334D0DPRVPEXVS03cor_" MIME-Version: 1.0 Subject: Re: [homenet] routing requirements 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, 21 Oct 2011 21:26:27 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334D0DPRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you describe some scenarios which would cause a prefix to change, in wh= ich applications break in ways that are unacceptable? All of the ones I ca= n think of would be cases where I would expect a session to drop, but I'm s= ure that's a lack of creativity on my part. Lee From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements Hello Howard, Thank you very much for the summary of messages. A comment on item 12: 12. Prefix stability? SC> I expect that 'Prefix Stability' is a requirement at home or small off= ices. Without prefix stability some of the applications will suddenly break= when the old prefix expires and the new prefix becomes effective. And question to the wg: 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. SC> Is the expectation from homenet wg that all hosts will implement RFC 34= 84 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think s= o ] So the host implementation change should be required if a host has to = support multiple prefixes or I might be missing something? Thanks, -Samita ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requiremen= ts I've gleaned. Question marks are unclear to me, please help. 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solution= s against mutliple L2 types. 4. Border detection. a. Border may be upstream ISP, or may be a device that is a gateway t= o SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo = to home net. Or there may be no border, if no external connection has been= established. b. Must be able to find "up" (a path to the Internet), but must not be= dependent on "up" (Internet connectivity) existing for intra-home reachabi= lity. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device.= Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scena= rios. b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condi= tion? g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least,= not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be = able to use another in case on fails. 11. Prevent looping. 12. Prefix stability? 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. 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. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334D0DPRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                    Can you = describe some scenarios which would cause a prefix to change, in which appl= ications break in ways that are unacceptable?  All of the ones I can t= hink of would be cases where I would expect a session to drop, but I’= m sure that’s a lack of creativity on my part.

                    <= p class=3DMsoNormal> 

                    Lee

                     =

                    From: Samita Cha= krabarti [mailto:samita.chakrabarti@ericsson.com]
                    Sent: Friday, = October 21, 2011 5:08 PM
                    To: Howard, Lee; homenet@ietf.org
                    = Subject: RE: routing requirements

                     

                    Hello Howard,<= /span> 

                    Thank you very much for the summary of messages.

                     

                    A comment on item 12:

                    = 12.  Prefix stability? 

                     

                    SC>  I expect that 'Prefix Stability' is a requireme= nt at home or small offices. Without prefix stability some of the applicati= ons will suddenly break when the old prefix expires and the new prefix beco= mes effective.

                     

                    And question to the wg:

                     

                    8.      Support for multiple upstream networks is a requiremen= t.

                    g.     = Source address selection is out of scope= .  And should be solved by rfc3484, with longest prefix match (whether= ULA or walled garden).  Choosing which address to use to look up the = destination address is out of scope.

                     =

                    SC> Is the expectation from homenet wg that all h= osts will implement RFC 3484 ?

                    Do t= he current home IPv6 host products support RFC 3484 ? [ I don't think so ]&= nbsp; So the host implementation change should be required if a h= ost has to support multiple prefixes or I might be missing something?

                     

                     

                    -Samita=

                     

                     

                    From:<= /b> home= net-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of = Howard, Lee
                    Sent: Friday, October 21, 2011 11:32 AM
                    To:= homenet@ietf.org
                    Subject: [homenet] routing requirements                    <= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>=

                    I've caught up on some 300 message= s about routing.  Here are the requirements I've gleaned.  Questi= on marks are unclear to me, please help.

                     

                    1.   = ;   Homenet router requirements

                    2.      When evaluating = a solution, discuss whether it provides for:

                    3.      Reachability between= all nodes in the home network.

                    a.       Links may= be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple= L2 types.

                    4.   = ;   Border detection. 

                    a.       = Border may be upstream ISP, or may be a device that is a gateway to = SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo= to home net.  Or there may be no border, if no external connectio= n has been established. 

                    b.      Must be able to = find “up” (a path to the Internet), but must not be dependent o= n “up” (Internet connectivity) existing for intra-home reachabi= lity.

                    c.&nbs= p;      May be discovered by routing protoc= ol, or other means.

                    5. &n= bsp;    Robust to routers being moved/added/removed/r= enumbered

                    a.=        Convergence time a few minutes = or less.

                    6.   &= nbsp;  No configuration required.

                    a.       = We might tolerate? a single password being entered on each device.&n= bsp; Discuss.

                    7.  &n= bsp;   Best-path is a non-requirement.

                    8.      Support f= or multiple upstream networks is a requirement.

                    a.       = Including wireless offload, video-only, and split-tunnel VPN scenari= os. 

                    b.      With separate routers to each. = Not multihomed off the same router.

                    c.       Pref= ix delegated from all ISPs (upstreams).

                    d.      ISP A i= s default.

                    e.       With only traffic destined to = ISP B’s prefix using that link.

                    f.       Wit= h a backup default to ISP B, if desired.  What is default condition?

                    g.  = ;    Source address selection is out of scope.  = And should be solved by rfc3484, with longest prefix match (whether ULA or = walled garden).  Choosing which address to use to look up the destinat= ion address is out of scope.

                    9.      Cannot assume hierarchical prefix de= legation in the home (at least, not unless the WG develops such a solution)= .

                    10= .  A host with= mutliple upstream paths to the same destination should be able to use anot= her in case on fails.

                    11.&nbs= p; Prevent looping.

                    12.  Prefix stability? 

                    13.  Lightweight (cheap) implementation.

                    Let me know if I’ve missed, or mistated, an= ything.

                     

                    Lee

                     =

                     

                    This E-mail and any of its attachmen= ts may contain Time Warner Cable proprietary information, which is privileg= ed, confidential, or subject to copyright belonging to Time Warner Cable. T= his E-mail is intended solely for the use of the individual or entity to wh= ich it is addressed. If you are not the intended recipient of this E-mail, = you are hereby notified that any dissemination, distribution, copying, or a= ction taken in relation to the contents of and attachments to this E-mail i= s strictly prohibited and may be unlawful. If you have received this E-mail= in error, please notify the sender immediately and permanently delete the = original and any copy of this E-mail and any printout.=

                    = --_000_DCC302FAA9FE5F4BBA4DCAD4656937791451334D0DPRVPEXVS03cor_-- From shemant@cisco.com Fri Oct 21 17:18:30 2011 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 5AB2921F850B for ; Fri, 21 Oct 2011 17:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.674 X-Spam-Level: X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+M9fuH6uHQV for ; Fri, 21 Oct 2011 17:18:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 44AC721F8541 for ; Fri, 21 Oct 2011 17:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=35145; q=dns/txt; s=iport; t=1319242705; x=1320452305; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=u/EQ5fYgmot8nORDXhxApSmxogmjxKcesHBH10bWF+Q=; b=AWRYyCCZ72M9onhVGa6B84zqL6BygnaLZwWfy/X6V4Fck5oEmpUot7hO lJj0G+4mFLzjGp8y2CvWqgqNSP9uJo11JDEX4o6NrYPa6eB2V5VzOfjwO ePn6dMptROUd3KAhMUTlKsoSR3R+8CX9jeSAQwV+7ZPQLU/YAydpB48Nq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8AAEULok6tJXHB/2dsb2JhbABDgk2XE48/gQWBbgEBAQQSAQkRA0IXAgEIEQQBAQsGCAgBBgEGAUUJCAEBBAESCBMHnHQBnjCFMYIuYQSIA5EzjEM X-IronPort-AV: E=Sophos;i="4.69,389,1315180800"; d="scan'208,217";a="30207292" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 22 Oct 2011 00:18:24 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9M0IOBS024908; Sat, 22 Oct 2011 00:18:24 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 19:18:23 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9050.1C92EC86" Date: Fri, 21 Oct 2011 19:18:22 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQAAEKcrAABaGVoA== References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> From: "Hemant Singh (shemant)" To: "Howard, Lee" , "Samita Chakrabarti" , X-OriginalArrivalTime: 22 Oct 2011 00:18:23.0864 (UTC) FILETIME=[1C9B8780:01CC9050] Subject: Re: [homenet] routing requirements 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, 22 Oct 2011 00:18:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9050.1C92EC86 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note the IETF IPv6 CE router specifies use of the ULA in the home to keep the home network independent of the SP network. This way my computer at home can still print to the printer even when my SP IPv6 network is down. We have said this multiple time in v6ops during development of the IPv6 CE router RFC 6204. I don't have the time to read the copious emails of homenet, but seeing some emails here and there I see homenet regressing on issues that are closed in the v6ops IPv6 CE router document development. Examples of issues homenet is regressing on is ND Proxy and use of zospf for prefix delegation in the LAN. There was only one cell phone vendor who was asking us for ND Proxy with a single /64 PD delegated to the phone. We convinced the vendor at the Prague IETF to abandon that idea because such a /64 would need RA Proxy in the CE router and RA Proxy is not defined is any RFC. Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. That is why ND Proxy was removed from the cpe rtr bis document.=20 =20 Zospf was also closed in v6ops that it's not possible to use for prefix delegation in the LAN. Here is an email to v6ops on closure on ospf for prefix delegation. =20 =20 Hemant =20 ---- begin snip ------------ =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Wednesday, July 27, 2011 1:26 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router =20 =20 >Can such a default be extensible to exchange different types of information than just reachability? For example, can it propagate information such as "this is a guest network and this is an internal network" or "this is a prefix that I have tentatively >assigned but do not own yet"? If not, then perhaps something more flexible like IS-IS would be better. =20 Not possible because the proposal is not workable. Someone brought up using OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE router design team. See the questions I asked followed by the person's reply and my responses back to show no routing protocol can be used to delegate prefixes in the LAN. =20 =20 I asked, HS: How do you know OSPF has converged before responding to DHCPv6 PD requests? =20 Reply: The CE router SHOULD wait until two sequential link-state advertisements have no link state changes before delegating any prefixes. This allows time for OSPF to converge, and for the router to build a topology map. =20 Seeing the above reply, I made my comment: =20 HS: Still does not work. After OSPF converges, what happens if the user changes the network such as unplugging a router and moving the router? =20 Reply: The router has a link state table-when it changes, you go through discovery again and issue a Reconfigure where appropriate. =20 =20 HS: There is a network bridge between two routers and the bridge does not have any means to report link-up or down. Further, what if a network interface of a router is flapping all the time and thus basing any algorithm on OSPF convergence breaks down. The flapping interface problem becomes worse if one has a cyclic network. Your proposal still does not work. =20 =20 Hemant =20 =20 ------ end snip --------- =20 =20 =20 =20 =20 From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 5:26 PM To: Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements =20 Can you describe some scenarios which would cause a prefix to change, in which applications break in ways that are unacceptable? All of the ones I can think of would be cases where I would expect a session to drop, but I'm sure that's a lack of creativity on my part. =20 Lee =20 From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com]=20 Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements =20 Hello Howard, =20 Thank you very much for the summary of messages. =20 A comment on item 12: 12. Prefix stability?=20 =20 SC> I expect that 'Prefix Stability' is a requirement at home or small offices. Without prefix stability some of the applications will suddenly break when the old prefix expires and the new prefix becomes effective. =20 And question to the wg: =20 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden). Choosing which address to use to look up the destination address is out of scope. =20 SC> Is the expectation from homenet wg that all hosts will implement RFC 3484 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think so ] So the host implementation change should be required if a host has to support multiple prefixes or I might be missing something? =20 =20 Thanks, -Samita =20 =20 ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requirements I've gleaned. Question marks are unclear to me, please help. =20 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple L2 types. 4. Border detection. =20 a. Border may be upstream ISP, or may be a device that is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to home net. Or there may be no border, if no external connection has been established. =20 b. Must be able to find "up" (a path to the Internet), but must not be dependent on "up" (Internet connectivity) existing for intra-home reachability. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device. Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scenarios. =20 b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condition? g. Source address selection is out of scope. And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden). Choosing which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least, not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be able to use another in case on fails.=20 11. Prevent looping. 12. Prefix stability? =20 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. =20 Lee =20 =20 ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------_=_NextPart_001_01CC9050.1C92EC86 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                    Note the IETF IPv6 CE router specifies use of = the ULA in the home to keep the home network independent of the SP = network.  This way my computer at home can still print to the = printer even when my SP IPv6 network is down.  We have said this = multiple time in v6ops during development of the IPv6 CE router RFC = 6204.  I don’t have the time to read the copious emails of = homenet, but seeing some emails here and there I see homenet regressing = on issues that are closed in the v6ops IPv6 CE router document = development.  Examples of issues homenet is regressing on is ND = Proxy and use of zospf for prefix delegation in the LAN.  =  There was only one cell phone vendor who was asking us for ND = Proxy with a single /64 PD delegated to the phone.   We = convinced the vendor at the Prague IETF to abandon that idea because = such a /64 would need RA Proxy in the CE router and RA Proxy is not = defined is any RFC.  Thus the vendor agreed and decided to go with = DHCPv6 PD of RC 3633.  That is why ND Proxy was removed from the = cpe rtr bis document.

                     

                    Zospf was also closed in = v6ops that it’s not possible to use for prefix delegation in the = LAN.   Here is an email to v6ops on closure on ospf for prefix = delegation. 

                     

                    Hemant

                     

                    ---- begin snip = ------------

                     

                    From:= = Lorenzo Colitti [mailto:lorenzo@google.com]
                    Sent: Wednesday, July 27, 2011 1:26 PM
                    To: = Hemant Singh (shemant)
                    Cc: IPv6 Operations
                    Subject: = Re: [v6ops] default LAN routing protocol for IPv6 CE = router

                     

                     

                    >Can such a default be extensible to = exchange different types of information than just reachability? For = example, can it propagate information such as "this is a guest = network and this is an internal network" or "this is a prefix = that I have tentatively >assigned but do not own yet"? If = not, then perhaps something more flexible like IS-IS would be = better.

                     

                    Not possible because the = proposal is not workable.   Someone brought up using OSPFv3 = for use in prefix delegation in the home LAN to our IETF CPE router = design team.  See the questions I asked followed by the = person’s reply and my responses back to show no routing protocol = can be used to delegate prefixes in the LAN. =  

                     

                    I asked, HS: How do you = know OSPF has converged before responding to DHCPv6 PD = requests?

                     

                    Reply: The CE router = SHOULD wait until two sequential link-state advertisements have no link = state  changes before delegating any prefixes.  This allows = time for OSPF to converge, and for the  router to build a topology = map.

                     

                    Seeing the above reply, = I made my comment:

                     

                    HS: Still does not = work.  After OSPF converges, what happens if the user changes the = network such  as unplugging a router and moving the = router?

                     

                    Reply: The router has a = link state table—when it changes, you go through discovery again = and issue a  Reconfigure where appropriate.  =

                     

                    HS:  There is a = network bridge between two routers and the bridge does not have any = means to report link-up  or down.  Further, what if a network = interface of a router is flapping all the time and thus  basing any = algorithm on OSPF convergence breaks down.  The flapping interface = problem becomes  worse if one has a cyclic network.  Your = proposal still does not work. 

                     

                    Hemant

                     

                     

                    ------ end snip = ---------

                     

                     

                     

                     

                     

                    From:= = homenet-bounces@ietf.org = [mailto:homenet-bounces= @ietf.org] On Behalf Of Howard, Lee
                    Sent: Friday, = October 21, 2011 5:26 PM
                    To: Samita Chakrabarti; homenet@ietf.org
                    Subject: = Re: [homenet] routing requirements

                     

                    Can you describe some scenarios which would = cause a prefix to change, in which applications break in ways that are = unacceptable?  All of the ones I can think of would be cases where = I would expect a session to drop, but I’m sure that’s a lack = of creativity on my part.

                     

                    Lee

                     

                    From:= = Samita Chakrabarti [mailto:samita.c= hakrabarti@ericsson.com]
                    Sent: Friday, October 21, 2011 = 5:08 PM
                    To: Howard, Lee; homenet@ietf.org
                    Subject: = RE: routing requirements

                     

                    He= llo Howard,

                     

                    Th= ank you very much for the summary of messages.

                     

                    A = comment on item 12:

                    12.  Prefix stability? 

                     

                    SC= >  I expect that 'Prefix Stability' is a requirement at home or = small offices. Without prefix stability some of the applications will = suddenly break when the old prefix expires and the new prefix becomes = effective.

                     

                    An= d question to the wg:

                     

                    8.   &= nbsp;  Support for multiple = upstream networks is a requirement.

                    g.   &= nbsp;  Source address selection = is out of scope.  And should be solved by rfc3484, with longest = prefix match (whether ULA or walled garden).  Choosing which = address to use to look up the destination address is out of = scope.

                     

                    SC> Is the expectation from homenet wg that all hosts = will implement RFC 3484 ?

                    Do the current home IPv6 host products support RFC 3484 ? = [ I don't think so ]  So the host implementation change should = be required if a host has to support multiple prefixes or I might = be missing something?

                     

                     

                    Thanks,

                    -Samita

                     

                     

                    From:= = homenet-bounces@ietf.org = [mailto:homenet-bounces= @ietf.org] On Behalf Of Howard, Lee
                    Sent: Friday, = October 21, 2011 11:32 AM
                    To: homenet@ietf.org
                    Subject: = [homenet] routing requirements

                    I've = caught up on some 300 messages about routing.  Here are the = requirements I've gleaned.  Question marks are unclear to me, = please help.

                     

                    1.     = Homenet router requirements

                    2.     = When evaluating a solution, discuss whether it provides = for:

                    3.     = Reachability between all nodes in the home = network.

                    a.     =   Links may be Ethernet, WiFi, MoCA, or any other; test all = solutions against mutliple L2 types.

                    4.     = Border detection. 

                    a.     =   Border may be upstream ISP, or may be a device that is a = gateway to SmartGrid devices, e.g. a controller that speaks RPL to = 802.15.4 and foo to home net.  Or there may be no border, if = no external connection has been established. 

                    b.     = Must be able to find “up” (a path to the Internet), = but must not be dependent on “up” (Internet connectivity) = existing for intra-home reachability.

                    c.     =   May be discovered by routing protocol, or other = means.

                    5.     = Robust to routers being = moved/added/removed/renumbered

                    a.     =   Convergence time a few minutes or less.

                    6.     = No configuration required.

                    a.     =   We might tolerate? a single password being entered on each = device.  Discuss.

                    7.     = Best-path is a non-requirement.

                    8.     = Support for multiple upstream networks is a = requirement.

                    a.     =   Including wireless offload, video-only, and split-tunnel = VPN scenarios. 

                    b.     = With separate routers to each.  Not multihomed off the same = router.

                    c.     =   Prefix delegated from all ISPs = (upstreams).

                    d.     = ISP A is default.

                    e.     =   With only traffic destined to ISP B’s prefix using = that link.

                    f.     =   With a backup default to ISP B, if desired.  What is = default condition?

                    g.     = Source address selection is out of scope.  And should be = solved by rfc3484, with longest prefix match (whether ULA or walled = garden).  Choosing which address to use to look up the destination = address is out of scope.

                    9.     = Cannot assume hierarchical prefix delegation in the home (at = least, not unless the WG develops such a solution).

                    10.  A host with = mutliple upstream paths to the same destination should be able to use = another in case on fails.

                    11.  Prevent = looping.

                    12.  Prefix = stability? 

                    13.  Lightweight = (cheap) implementation.

                    Let me = know if I’ve missed, or mistated, anything.

                     

                    Lee

                     

                     

                    Thi= s E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use 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 dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any = printout.

                    ------_=_NextPart_001_01CC9050.1C92EC86-- From Hans_Liu@dlink.com.tw Fri Oct 21 18:03:38 2011 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 8726A21F85AE for ; Fri, 21 Oct 2011 18:03:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1BNXUJVHP97 for ; Fri, 21 Oct 2011 18:03:38 -0700 (PDT) Received: from smtp-tp2.dlink.com.tw (smtp-tp2.dlink.com.tw [60.248.210.36]) by ietfa.amsl.com (Postfix) with ESMTP id BC46D21F8586 for ; Fri, 21 Oct 2011 18:03:37 -0700 (PDT) Received: from HCB-HUB2.dlink.com.tw (localhost.localdomain [127.0.0.1]) by smtp-tp2.dlink.com.tw (Postfix) with ESMTP id 26E76873B4; Sat, 22 Oct 2011 09:03:22 +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; Sat, 22 Oct 2011 09:03:23 +0800 From: Hans Liu To: "Howard, Lee" Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AQHMkCf+FyT5tD4jWUG1KTMs0JW8yJWGyKoAgADD0O4= Date: Sat, 22 Oct 2011 01:03:22 +0000 Message-ID: <7FEE6A24-B0C5-4CDF-B008-57D67D1105F6@dlink.com.tw> References: <201110211904.p9LJ43CK031266@gateway.ipv6.occnc.com> , In-Reply-To: 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: Cameron Byrne , james woodyatt , "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 22 Oct 2011 01:03:38 -0000 +1 Agree with Lee.=20 Best regards, Hans Sent from Hans' iPad2 On Oct 22, 2011, at 5:22 AM, "Howard, Lee" wrote: > I've had some of these arguments before, but I'll write them down now > so there's a record. Maybe we should document the debated points in > a discussion draft, so we could invite further comment. >=20 >> And, most (cite?) actual attacks are not preventable with a $30 home >> router. Most (cite?) homenet security issues are relate to phishing >> and users downloading and installing malware with admin privilege, >> which PCP and stateful firewalls cannot solve. >=20 > Port scanning is largely blocked by stateful firewalls. Thus it's not th= e > prevention of actual attacks, but the fact that attacks don't exist becau= se > they're useless given the existence of firewalls. >=20 >>> So service providers are compelled to put firewalls in front of >>> consumer customers (and even most small business) and have them >>> enabled by default. >=20 > btw, I realize we operated from different assumptions. My default view > is that the customer manages the gateway/firewall, not the ISP (or maybe > in addition to the ISP). So in my world view, it's clear that the user (= or > host, or application) sets the security policy, which is enforced by the > firewall. So if one OS believes it is invulnerable, it can signal the fi= rewall > to allow all traffic to it. If another OS wants defense in depth, it can > signal the firewall to allow only wanted traffic. You may s/OS/app. >=20 >> Is there proof that $30 home routers protect computers and "move the >> needle" on malware? Or is this left over mindset from the 1990s? >=20 > I argue they hold the needle on malware, and there's no reason to make > it easier to attack ignorant users. >=20 > Somebody else once said: >> There are no attacks in IPv6, what are we protecting against? > We should design security in before there are attacks, not wait and see > what gets attacked. >=20 > To be constructive, I would like home routers (or at least home border > gateways) have a "default deny" security policy, which can be > overriden by user configuration or signaling from internal hosts that > traffic is wanted. "Signaling" could be PCP, uPNP, SYN, etc. >=20 > Lee >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From samita.chakrabarti@ericsson.com Fri Oct 21 18:48:32 2011 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 33C6E1F0C34 for ; Fri, 21 Oct 2011 18:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlU-8JmA1REY for ; Fri, 21 Oct 2011 18:48:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6C44D1F0C3D for ; Fri, 21 Oct 2011 18:48:26 -0700 (PDT) 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 p9M1mMMt016769; Fri, 21 Oct 2011 20:48:23 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 21 Oct 2011 21:48:16 -0400 From: Samita Chakrabarti To: "Hemant Singh (shemant)" , "Howard, Lee" , "homenet@ietf.org" Date: Fri, 21 Oct 2011 21:48:15 -0400 Thread-Topic: [homenet] routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQAAEKcrAABaGVoAACyGYA Message-ID: <16D60F43CA0B724F8052D7E9323565D7243F7EB191@EUSAACMS0715.eamcs.ericsson.se> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [homenet] routing requirements 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, 22 Oct 2011 01:48:32 -0000 --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Hemant for the information from V6ops discussion on zospf prefix del= egation. In my humble view: - Prefix assignment should be independent from a routing protocol - Binding prefix-assignment to a routing protocol creates the problem of sy= nchronization as you pointed out and also it limits the user to a single ro= uting protocol for the network. I think the users/operators should have fle= xibility to choose a routing protocol for the services they offer today and= in future. I'd really like to see IPv6 PD solution for the home network for network st= ability after a power outage or bringing up a new set of network. We have gone through similar debate in RPL development timeframe and finall= y as far as I know RPL made the prefix configuration optional. If someone thinks that a new version of ospfv3 will introduce prefix assign= ment as a optional feature for a particular application/environment where i= t might work perfectly - I am okay with that. It is difficult for me to thi= nk OSPFv3 being the default choice to configure ip-addresses in a home netw= ork. In future, home network will grow further - I expect that there will be tw= o kinds of users at home - 1) tech-challenged users who like plug-n-play 2= ) tech-savvy users running business or running multi-level networks at home= for convenience and pleasure or whatever reasons. So it'll be a combinatio= n of big and small ip-enabled devices and lots of them... Regards, -Samita ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Friday, October 21, 2011 5:18 PM To: Howard, Lee; Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements Note the IETF IPv6 CE router specifies use of the ULA in the home to keep t= he home network independent of the SP network. This way my computer at hom= e can still print to the printer even when my SP IPv6 network is down. We = have said this multiple time in v6ops during development of the IPv6 CE rou= ter RFC 6204. I don't have the time to read the copious emails of homenet,= but seeing some emails here and there I see homenet regressing on issues t= hat are closed in the v6ops IPv6 CE router document development. Examples = of issues homenet is regressing on is ND Proxy and use of zospf for prefix = delegation in the LAN. There was only one cell phone vendor who was askin= g us for ND Proxy with a single /64 PD delegated to the phone. We convinc= ed the vendor at the Prague IETF to abandon that idea because such a /64 wo= uld need RA Proxy in the CE router and RA Proxy is not defined is any RFC. = Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. That = is why ND Proxy was removed from the cpe rtr bis document. Zospf was also closed in v6ops that it's not possible to use for prefix del= egation in the LAN. Here is an email to v6ops on closure on ospf for pref= ix delegation. Hemant ---- begin snip ------------ From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Wednesday, July 27, 2011 1:26 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >Can such a default be extensible to exchange different types of informatio= n than just reachability? For example, can it propagate information such as= "this is a guest network and this is an internal network" or "this is a pr= efix that I have tentatively >assigned but do not own yet"? If not, then pe= rhaps something more flexible like IS-IS would be better. Not possible because the proposal is not workable. Someone brought up usi= ng OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE rout= er design team. See the questions I asked followed by the person's reply a= nd my responses back to show no routing protocol can be used to delegate pr= efixes in the LAN. I asked, HS: How do you know OSPF has converged before responding to DHCPv6= PD requests? Reply: The CE router SHOULD wait until two sequential link-state advertisem= ents have no link state changes before delegating any prefixes. This allo= ws time for OSPF to converge, and for the router to build a topology map. Seeing the above reply, I made my comment: HS: Still does not work. After OSPF converges, what happens if the user ch= anges the network such as unplugging a router and moving the router? Reply: The router has a link state table-when it changes, you go through di= scovery again and issue a Reconfigure where appropriate. HS: There is a network bridge between two routers and the bridge does not = have any means to report link-up or down. Further, what if a network inte= rface of a router is flapping all the time and thus basing any algorithm o= n OSPF convergence breaks down. The flapping interface problem becomes wo= rse if one has a cyclic network. Your proposal still does not work. Hemant ------ end snip --------- From: homenet-bounces@ietf.org [mailto:hom= enet-bounces@ietf.org] On Behalf = Of Howard, Lee Sent: Friday, October 21, 2011 5:26 PM To: Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements Can you describe some scenarios which would cause a prefix to change, in wh= ich applications break in ways that are unacceptable? All of the ones I ca= n think of would be cases where I would expect a session to drop, but I'm s= ure that's a lack of creativity on my part. Lee From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements Hello Howard, Thank you very much for the summary of messages. A comment on item 12: 12. Prefix stability? SC> I expect that 'Prefix Stability' is a requirement at home or small off= ices. Without prefix stability some of the applications will suddenly break= when the old prefix expires and the new prefix becomes effective. And question to the wg: 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. SC> Is the expectation from homenet wg that all hosts will implement RFC 34= 84 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think s= o ] So the host implementation change should be required if a host has to = support multiple prefixes or I might be missing something? Thanks, -Samita ________________________________ From: homenet-bounces@ietf.org [mailto:hom= enet-bounces@ietf.org] On Behalf = Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requiremen= ts I've gleaned. Question marks are unclear to me, please help. 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solution= s against mutliple L2 types. 4. Border detection. a. Border may be upstream ISP, or may be a device that is a gateway t= o SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo = to home net. Or there may be no border, if no external connection has been= established. b. Must be able to find "up" (a path to the Internet), but must not be= dependent on "up" (Internet connectivity) existing for intra-home reachabi= lity. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device.= Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scena= rios. b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condi= tion? g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least,= not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be = able to use another in case on fails. 11. Prevent looping. 12. Prefix stability? 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. 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. --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
                     
                    Thanks Hemant for the information from=20 V6ops discussion on zospf prefix delegation= .
                    = In my humble=20 view:
                    =  - Prefix assignment should= =20 be independent  from a routing=20 protocol
                    = - Binding prefix-assignment to a = routing=20 protocol creates the problem of synchronization as you pointed out and also= it=20 limits the user to a single routing protocol for the network. I think the=20 users/operators should have flexibility to choose a routing protocol for th= e=20 services they offer today and in future.
                     
                    I'd really like to see IPv6 PD solution for the = home=20 network for network stability after a power outage or bringing up a new set= of=20 network.
                    We have gone through similar debate in RPL devel= opment=20 timeframe and finally as far as I know RPL made the prefix configuration=20 optional.
                     
                    If someone thinks that a new version of ospfv3 w= ill=20 introduce prefix assignment as a optional feature for a particular=20 application/environment where it might work perfectly - I am okay with that= . It=20 is difficult for me to think OSPFv3 being the default choice to configure=20 ip-addresses in a home network.
                    In future, home network will grow further  = - I=20 expect that there will be two kinds of users at home - 1)  tech-challe= nged=20 users who like plug-n-play 2) tech-savvy users running business or running= =20 multi-level networks at home for convenience and pleasure or whatever reaso= ns.=20 So it'll be a combination of big and small ip-enabled devices and lots of=20 them...
                     
                    Regards,
                    -Samita

                    From: homenet-bounces@ietf.org=20 [mailto:homenet-bounces@ietf.org] On Behalf Of Hemant Singh=20 (shemant)
                    Sent: Friday, October 21, 2011 5:18 PM
                    To: Ho= ward,=20 Lee; Samita Chakrabarti; homenet@ietf.org
                    Subject: Re: [homenet]= =20 routing requirements

                    Note the IETF IPv6 CE r= outer=20 specifies use of the ULA in the home to keep the home network independent o= f the=20 SP network.  This way my computer at home can still print to the print= er=20 even when my SP IPv6 network is down.  We have said this multiple time= in=20 v6ops during development of the IPv6 CE router RFC 6204.  I don’= t have the=20 time to read the copious emails of homenet, but seeing some emails here and= =20 there I see homenet regressing on issues that are closed in the v6ops IPv6 = CE=20 router document development.  Examples of issues homenet is regressing= on=20 is ND Proxy and use of zospf for prefix delegation in the LAN.   = There=20 was only one cell phone vendor who was asking us for ND Proxy with a single= /64=20 PD delegated to the phone.   We convinced the vendor at the Pragu= e=20 IETF to abandon that idea because such a /64 would need RA Proxy in the CE= =20 router and RA Proxy is not defined is any RFC.  Thus the vendor agreed= and=20 decided to go with DHCPv6 PD of RC 3633.  That is why ND Proxy was rem= oved=20 from the cpe rtr bis document.

                     

                    Zospf was also closed i= n v6ops=20 that it’s not possible to use for prefix delegation in the LAN.  = ; Here=20 is an email to v6ops on closure on ospf for prefix delegation. =20

                     

                    Hemant

                     

                    ---- begin snip=20 ------------

                     

                    From:<= /B> Lorenzo Coli= tti [mailto:lorenzo@google.com]= =20
                    Sent: Wednesday, July 27, 2011 1:26 PM
                    To: Hemant Sing= h=20 (shemant)
                    Cc: IPv6 Operations
                    Subject: Re: [v6ops] defa= ult=20 LAN routing protocol for IPv6 CE router

                    &nbs= p;

                     

                    >Can such a d= efault be=20 extensible to exchange different types of information than just reachabilit= y?=20 For example, can it propagate information such as "this is a guest network = and=20 this is an internal network" or "this is a prefix that I have tentatively <= SPAN=20 style=3D"COLOR: #1f497d">>assigned but do not own yet"? If not, t= hen=20 perhaps something more flexible like IS-IS would be better.

                     

                    Not possible because th= e=20 proposal is not workable.   Someone brought up using OSPFv3 for u= se in=20 prefix delegation in the home LAN to our IETF CPE router design team. = See=20 the questions I asked followed by the person’s reply and my responses= back to=20 show no routing protocol can be used to delegate prefixes in the LAN.=20  

                     

                    I asked, HS: How do you= know=20 OSPF has converged before responding to DHCPv6 PD=20 requests?

                     

                    Reply: The CE router SH= OULD wait=20 until two sequential link-state advertisements have no link state  cha= nges=20 before delegating any prefixes.  This allows time for OSPF to converge= , and=20 for the  router to build a topology map.

                     

                    Seeing the above reply,= I made=20 my comment:

                     

                    HS: Still does not work= . =20 After OSPF converges, what happens if the user changes the network such &nb= sp;as=20 unplugging a router and moving the router?

                     

                    Reply: The router has a= link=20 state table—when it changes, you go through discovery again and issue= a=20  Reconfigure where appropriate. 

                     

                    HS:  There is a ne= twork=20 bridge between two routers and the bridge does not have any means to report= =20 link-up  or down.  Further, what if a network interface of a rout= er is=20 flapping all the time and thus  basing any algorithm on OSPF convergen= ce=20 breaks down.  The flapping interface problem becomes  worse if on= e has=20 a cyclic network.  Your proposal still does not work. =20

                     

                    Hemant

                     

                     

                    ------ end snip=20 ---------

                     

                     

                     

                     

                     

                    From:<= /B> homenet-bounces@ietf.org [mailto:homenet-bounces@i= etf.org]=20 On Behalf Of Howard, Lee
                    Sent: Friday, October 21, 2011 5:= 26=20 PM
                    To: Samita Chakrabarti; homenet@ietf.org
                    Subject: Re= :=20 [homenet] routing requirements

                     

                    Can=20 you describe some scenarios which would cause a prefix to change, in which= =20 applications break in ways that are unacceptable?  All of the ones I c= an=20 think of would be cases where I would expect a session to drop, but I’= ;m sure=20 that’s a lack of creativity on my part.

                     

                    Lee

                     

                    From:<= /B> Samita Chakr= abarti=20 [mailto:samita.cha= krabarti@ericsson.com]=20
                    Sent: Friday, October 21, 2011 5:08 PM
                    To: Howard, Lee= ; homenet@ietf.org
                    Subject: RE= :=20 routing requirements

                     

                    H= ello=20 Howard,

                     

                    T= hank=20 you very much for the summary of messages.

                     

                    A= =20 comment on item 12:

                    12. =20 Prefix=20 stability? 

                     

                    S= C> =20 I expect that 'Prefix Stability' is a requirement at home or small offices.= =20 Without prefix stability some of the applications will suddenly break when = the=20 old prefix expires and the new prefix becomes effective.

                     

                    A= nd=20 question to the wg:

                     

                    8.   =   =20 Support for multiple upstream networks i= s a=20 requirement.

                    g.   =   =20 Source address selection is out of scope= . =20 And should be solved by rfc3484, with longest prefix match (whether ULA or= =20 walled garden).  Choosing which address to use to look up the destinat= ion=20 address is out of scope.

                     

                    SC>=20 Is the expectation from homenet wg that all hosts will implement RFC 3484=20 ?

                    Do=20 the current home IPv6 host products support RFC 3484 ? [ I don't think so=20 ]  So the host implementation change should be required if a= host=20 has to support multiple prefixes or I might be missing=20 something?

                     

                     

                    Thanks,

                    -Samita

                     

                     

                    From:<= /B> homenet-bounces@ietf.org [mailto:homenet-bounces@i= etf.org]=20 On Behalf Of Howard, Lee
                    Sent: Friday, October 21, 2011 11= :32=20 AM
                    To: homenet@ietf.org
                    Subject: [h= omenet]=20 routing requirements

                    I've caught up on some 300 messages about routing.&= nbsp;=20 Here are the requirements I've gleaned.  Question marks are unclear to= me,=20 please help.

                     

                    1.     = =20 Homenet router requirements

                    2.     = =20 When evaluating a solution, discuss whether it provides=20 for:

                    3.     = =20 Reachability between all nodes in the home network.

                         &= nbsp;=20 Links may be Ethernet, WiFi, MoCA, or any other; test all solutions= =20 against mutliple L2 types.

                    4.     = =20 Border detection. 

                         &= nbsp;=20 Border may be upstream ISP, or may be a device that is a gateway to= =20 SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo= =20 to home net.  Or there may be no border, if no external connection has= been=20 established. 

                         = =20 Must be able to find “up” (a path to the Internet), but = must not be=20 dependent on “up” (Internet connectivity) existing for intra-ho= me=20 reachability.

                         &= nbsp;=20 May be discovered by routing protocol, or other means.

                    5.     = =20 Robust to routers being moved/added/removed/renumbered

                         &= nbsp;=20 Convergence time a few minutes or less.

                    6.     = =20 No configuration required.

                         &= nbsp;=20 We might tolerate? a single password being entered on each device.&n= bsp;=20 Discuss.

                    7.     = =20 Best-path is a non-requirement.

                    8.     = =20 Support for multiple upstream networks is a requirement.<= /P>

                         &= nbsp;=20 Including wireless offload, video-only, and split-tunnel VPN=20 scenarios. 

                         = =20 With separate routers to each.  Not multihomed off the same=20 router.

                         &= nbsp;=20 Prefix delegated from all ISPs (upstreams).

                         = =20 ISP A is default.

                         &= nbsp;=20 With only traffic destined to ISP B’s prefix using that=20 link.

                         &= nbsp;=20 With a backup default to ISP B, if desired.  What is default=20 condition?

                         = =20 Source address selection is out of scope.  And should be solved= by=20 rfc3484, with longest prefix match (whether ULA or walled garden). =20 Choosing which address to use to look up the destination address is out of= =20 scope.

                    9.     = =20 Cannot assume hierarchical prefix delegation in the home (at least, = not=20 unless the WG develops such a solution).

                    10.  A host with mutli= ple=20 upstream paths to the same destination should be able to use another in cas= e on=20 fails.

                    11.  Prevent=20 looping.

                    12.  Prefix stability?=  =20

                    13.  Lightweight (chea= p)=20 implementation.

                    Let me know if I’ve missed, or mistated,=20 anything.

                     

                    Lee

                     

                    &nbs= p;

                    = This=20 E-mail and any of its attachments may contain Time Warner Cable proprietary= =20 information, which is privileged, confidential, or subject to copyright=20 belonging to Time Warner Cable. This E-mail is intended solely for the use = of=20 the individual or entity to which it is addressed. If you are not the inten= ded=20 recipient of this E-mail, you are hereby notified that any dissemination,=20 distribution, copying, or action taken in relation to the contents of and=20 attachments to this E-mail is strictly prohibited and may be unlawful. If y= ou=20 have received this E-mail in error, please notify the sender immediately an= d=20 permanently delete the original and any copy of this E-mail and any=20 printout.

                    --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_-- From curtis@occnc.com Fri Oct 21 18:52:32 2011 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 4D08411E80A0 for ; Fri, 21 Oct 2011 18:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Kwqh+NfrZtP for ; Fri, 21 Oct 2011 18:52:31 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13311E8081 for ; Fri, 21 Oct 2011 18:52:31 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9M1qNfl041300; Fri, 21 Oct 2011 18:52:23 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9M1qNfl041300 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319248344; bh=DQI2aNfMNjs8Nx1CRDGQQE/9II/ypwJvAWNeXm/Qzx4=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=ReBtfKXdYjoJ9YyY8e0NcfXJzONKeufgADQDtYo3LWNtoijnYIHjPi8E5tkl/gwGA 5+jtTGmpl53hca7HpnHKOOkeBixPG9KeRhL8JmBt+IOyblnC0xTnSWSbg5VpCagtYY pTwkVF2fhfi+cq3okpQP20pJIaSNGkhp1wA5Oya4= Message-Id: <201110220152.p9M1qNfl041300@gateway.ipv6.occnc.com> To: Cameron Byrne From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 12:31:14 PDT." Date: Fri, 21 Oct 2011 18:52:23 -0700 Cc: "Howard, Lee" , "homenet@ietf.org" , james woodyatt , curtis@occnc.com Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 01:52:32 -0000 In message Cameron Byrne writes: > On Fri, Oct 21, 2011 at 12:04 PM, Curtis Villamizar wrote: > > > > In message > > Cameron Byrne writes: > > > >> I am in the camp the host should be strong and smart and networks > >> should be simple and fast. > >> > >> Cb > > > > Same here but we can't get rid of all the windows systems out there. > > > > Why? Even windows XP comes with a host based firewall since 2003 ... > That's coming up on 10 years by the time homenet influences the > market. > > > > . blah blah blah... we all must engineer for the least common > denominator because somebody out there can be attacked by the Morris > Worm still... > > > > > And, most (cite?) actual attacks are not preventable with a $30 home > router. Most (cite?) homenet security issues are relate to phishing > and users downloading and installing malware with admin privilege, > which PCP and stateful firewalls cannot solve. > > > > So service providers are compelled to put firewalls in front of > > consumer customers (and even most small business) and have them > > enabled by default. > > > > To not do so would result in the service provider having a network of > > malicious bots (as opposed to a network containing a subset of sites > > running malware that the service provider couldn't prevent). > > > > Is there proof that $30 home routers protect computers and "move the > needle" on malware? Or is this left over mindset from the 1990s? > > > > Back in the early 1990s I argued that we should not let windows > > systems on the Internet.  That was back when your network (college > > campuses, corporations, etc) could be shut down by a provider if > > attacks were coming out of it and you did nothing to completely > > eradicate it.  An example of this was Mitnik breaking into a > > university in Houston and Sesquinet shutting off their Internet for > > four days due to a computer science department response that security > > was a hard problem and from a practical standpoint there was nothing > > they could do about it.  Back then, if you couldn't make it secure, it > > didn't belong on the Internet. > > > > Would a firewall stopped this or was this social engineering? Also, > this is not the 1990s... Things are indeed better now from a network > programming perspective. Social engineering and so on are a different > layer. > > > I do see your point and agree with you.  From a technical perspective, > > firewalls are an inadequate bandaid over a set of OS and application > > security problems and the right thing to do is fix the root casue. > > > ^^^^ > Good stuff there. Lets focus on that instead of the dogma and FUD to > create "homenet" of the future. > > Thanks, > > Cameron > > > Curtis Cameron, I was arguing against firewalls as a security solution. You seemed to have missed the whole point of the email. Pleae reread it. At most you could say that I conceded that firewalls are a marginal improvement (and therefore won't go away). For the provider it may be whether 90% of their users end up running malware or 10% (cite?). When there is a new remote exploit discovered it limits the damage. Curtis From shemant@cisco.com Fri Oct 21 18:56:03 2011 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 318A71F0C3D for ; Fri, 21 Oct 2011 18:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.681 X-Spam-Level: X-Spam-Status: No, score=-5.681 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxab80ddqN3l for ; Fri, 21 Oct 2011 18:56:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F21F0C34 for ; Fri, 21 Oct 2011 18:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6917; q=dns/txt; s=iport; t=1319248562; x=1320458162; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=PdsuMyVyhmrwq97PegMwQ1HdHzYVquJG8FVh5OICHqU=; b=g5z0AU2u8NzfwCSW/rAJB6FY7wQijmJHD12mM8nFIf944EMCnJdFcM5D r3QIhH/H9SA5XMjXk8ywvOtlAg3Nb2w8VdG4qac3B1tndhvYRWUqPr+DA dFs6XZlPaDFvLtT1DxI4iruz+MchwA28OrJy7uRnPlkq3U+FgBI7qBE3+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8AAEQiok6tJXG+/2dsb2JhbABDgk2XE48/gQWBbgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGpxkAZ4sh19hBIgDkTOMQw X-IronPort-AV: E=Sophos;i="4.69,389,1315180800"; d="scan'208,217";a="30208182" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2011 01:56:01 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9M1u1ZA019398; Sat, 22 Oct 2011 01:56:01 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 20:56:01 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC905D.BFBAD598" Date: Fri, 21 Oct 2011 20:56:00 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD812@XMB-RCD-109.cisco.com> In-Reply-To: <16D60F43CA0B724F8052D7E9323565D7243F7EB191@EUSAACMS0715.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQAAEKcrAABaGVoAACyGYAAADoggA= References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <16D60F43CA0B724F8052D7E9323565D7243F7EB191@EUSAACMS0715.eamcs.ericsson.se> From: "Hemant Singh (shemant)" To: "Samita Chakrabarti" , "Howard, Lee" , X-OriginalArrivalTime: 22 Oct 2011 01:56:01.0292 (UTC) FILETIME=[BFE81CC0:01CC905D] Subject: Re: [homenet] routing requirements 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, 22 Oct 2011 01:56:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC905D.BFBAD598 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com]=20 Sent: Friday, October 21, 2011 9:48 PM To: Hemant Singh (shemant); Howard, Lee; homenet@ietf.org Subject: RE: [homenet] routing requirements =20 =20 >If someone thinks that a new version of ospfv3 will introduce prefix assignment as a optional feature for a particular application/environment where it might work perfectly - I am okay with that. It is difficult for me >to think OSPFv3 being the default choice to configure ip-addresses in a home network.=20 =20 A routing protocol is so not proper to use for prefix delegation in the home LAN - it's like mixing oil and water. That is why I sent that v6ops email. Before anyone embarks on any ospfv3 or any other routing protocol based prefix delegation, please address what I raised for concerns in my v6ops email.=20 =20 Regards, =20 Hemant =20 ------_=_NextPart_001_01CC905D.BFBAD598 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                     

                     

                    From:= = Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] =
                    Sent: Friday, October 21, 2011 9:48 PM
                    To: Hemant = Singh (shemant); Howard, Lee; homenet@ietf.org
                    Subject: RE: = [homenet] routing requirements

                     

                     

                    >If= someone thinks that a new version of ospfv3 will introduce prefix = assignment as a optional feature for a particular = application/environment where it might work perfectly - I am okay with = that. It is difficult for me >to= think OSPFv3 being the default choice to configure ip-addresses in a = home network.

                     

                    A routing protocol is so = not proper to use for prefix delegation in the home LAN – = it’s like mixing oil and water.  That is why I sent that = v6ops email.   Before anyone embarks on any ospfv3 or any = other routing protocol based prefix delegation, please address what I = raised for concerns in my v6ops email.

                     

                    Regards,

                     

                    Hemant

                     

                    ------_=_NextPart_001_01CC905D.BFBAD598-- From samita.chakrabarti@ericsson.com Fri Oct 21 19:03:31 2011 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 211CE11E80A0 for ; Fri, 21 Oct 2011 19:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKJ4YgZ2kViK for ; Fri, 21 Oct 2011 19:03:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7C11E8081 for ; Fri, 21 Oct 2011 19:03:27 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9M23PaC017206; Fri, 21 Oct 2011 21:03:26 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 21 Oct 2011 22:03:20 -0400 From: Samita Chakrabarti To: "Howard, Lee" , "homenet@ietf.org" Date: Fri, 21 Oct 2011 22:03:19 -0400 Thread-Topic: routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQAAEKcrAACUr0gA== Message-ID: <16D60F43CA0B724F8052D7E9323565D7243F7EB195@EUSAACMS0715.eamcs.ericsson.se> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_16D60F43CA0B724F8052D7E9323565D7243F7EB195EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [homenet] routing requirements 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, 22 Oct 2011 02:03:31 -0000 --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB195EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Can you describe some scenarios which would cause a prefix to change, i= n which applications break in ways that are unacceptable? 1) See Hemanth's mail for a situation when a routing protocol assigns ip-a= ddresses after power failure or so 2) If the prefix assignment mechansim does not make sure that a device will= be assigned the same address for a short power failure or short interrupti= on of connectivity when your session is still alive (due to TCP session lif= etime) , the interface might receive a new address/prefix and now depending= on the prefix lifetime of the previous prefix, the session source address = may become invalid and if that session is a VoIP/Streaming Video or critica= l healthcare related communication, one does not appreciate the drop of the= session due to prefix instability. Regards, -Samita From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements Hello Howard, Thank you very much for the summary of messages. A comment on item 12: 12. Prefix stability? SC> I expect that 'Prefix Stability' is a requirement at home or small off= ices. Without prefix stability some of the applications will suddenly break= when the old prefix expires and the new prefix becomes effective. And question to the wg: 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. SC> Is the expectation from homenet wg that all hosts will implement RFC 34= 84 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think s= o ] So the host implementation change should be required if a host has to = support multiple prefixes or I might be missing something? Thanks, -Samita ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requiremen= ts I've gleaned. Question marks are unclear to me, please help. 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solution= s against mutliple L2 types. 4. Border detection. a. Border may be upstream ISP, or may be a device that is a gateway t= o SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo = to home net. Or there may be no border, if no external connection has been= established. b. Must be able to find "up" (a path to the Internet), but must not be= dependent on "up" (Internet connectivity) existing for intra-home reachabi= lity. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device.= Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scena= rios. b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condi= tion? g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least,= not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be = able to use another in case on fails. 11. Prevent looping. 12. Prefix stability? 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. 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. --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB195EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
                     

                     

                    &nbs= p;>=20  Can you describe some scenarios which would cause a pre= fix=20 to change, in which applications break in ways that are=20 unacceptable?   

                     

                    1) S= ee Hemanth's=20 mail for a situation when a  routing protocol assigns ip-addresse= s=20 after power failure or so

                    2) If the prefix assignment mechansim does not make sure= that a=20 device will be assigned the same address for a short power failure or short= =20 interruption of connectivity when your session is still alive (due to= =20 TCP session lifetime) , the interface might receive a new address/pref= ix=20 and now depending on the prefix lifetime of the previous prefix, the=20 session source address may become invalid and if that session is=20 a VoIP/Streaming Video or critical healthcare related communicati= on,=20 one does not appreciate the drop of the session due to prefix=20 instability.

                     

                     Regards,

                    -Samita

                     

                    From:<= /B> Samita Chakr= abarti=20 [mailto:samita.chakrabarti@ericsson.com]
                    Sent: Friday, October 2= 1,=20 2011 5:08 PM
                    To: Howard, Lee; homenet@ietf.org
                    Subject:= RE:=20 routing requirements

                     

                    H= ello=20 Howard,

                     

                    T= hank=20 you very much for the summary of messages.

                     

                    A= =20 comment on item 12:

                    12. =20 Prefix=20 stability? 

                     

                    S= C> =20 I expect that 'Prefix Stability' is a requirement at home or small offices.= =20 Without prefix stability some of the applications will suddenly break when = the=20 old prefix expires and the new prefix becomes effective.

                     

                    A= nd=20 question to the wg:

                     

                    8.   =   =20 Support for multiple upstream networks i= s a=20 requirement.

                    g.   =   =20 Source address selection is out of scope= . =20 And should be solved by rfc3484, with longest prefix match (whether ULA or= =20 walled garden).  Choosing which address to use to look up the destinat= ion=20 address is out of scope.

                     

                    SC>=20 Is the expectation from homenet wg that all hosts will implement RFC 3484=20 ?

                    Do=20 the current home IPv6 host products support RFC 3484 ? [ I don't think so=20 ]  So the host implementation change should be required if a= host=20 has to support multiple prefixes or I might be missing=20 something?

                     

                     

                    Thanks,

                    -Samita

                     

                     

                    From:<= /B>=20 homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of= =20 Howard, Lee
                    Sent: Friday, October 21, 2011 11:32 AM
                    To:= =20 homenet@ietf.org
                    Subject: [homenet] routing requirements

                    I've caught up on some 300 messages about routing.&= nbsp;=20 Here are the requirements I've gleaned.  Question marks are unclear to= me,=20 please help.

                     

                    1.     = =20 Homenet router requirements

                    2.     = =20 When evaluating a solution, discuss whether it provides=20 for:

                    3.     = =20 Reachability between all nodes in the home network.

                         &= nbsp;=20 Links may be Ethernet, WiFi, MoCA, or any other; test all solutions= =20 against mutliple L2 types.

                    4.     = =20 Border detection. 

                         &= nbsp;=20 Border may be upstream ISP, or may be a device that is a gateway to= =20 SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo= =20 to home net.  Or there may be no border, if no external connection has= been=20 established. 

                         = =20 Must be able to find “up” (a path to the Internet), but = must not be=20 dependent on “up” (Internet connectivity) existing for intra-ho= me=20 reachability.

                         &= nbsp;=20 May be discovered by routing protocol, or other means.

                    5.     = =20 Robust to routers being moved/added/removed/renumbered

                         &= nbsp;=20 Convergence time a few minutes or less.

                    6.     = =20 No configuration required.

                         &= nbsp;=20 We might tolerate? a single password being entered on each device.&n= bsp;=20 Discuss.

                    7.     = =20 Best-path is a non-requirement.

                    8.     = =20 Support for multiple upstream networks is a requirement.<= /P>

                         &= nbsp;=20 Including wireless offload, video-only, and split-tunnel VPN=20 scenarios. 

                         = =20 With separate routers to each.  Not multihomed off the same=20 router.

                         &= nbsp;=20 Prefix delegated from all ISPs (upstreams).

                         = =20 ISP A is default.

                         &= nbsp;=20 With only traffic destined to ISP B’s prefix using that=20 link.

                         &= nbsp;=20 With a backup default to ISP B, if desired.  What is default=20 condition?

                         = =20 Source address selection is out of scope.  And should be solved= by=20 rfc3484, with longest prefix match (whether ULA or walled garden). =20 Choosing which address to use to look up the destination address is out of= =20 scope.

                    9.     = =20 Cannot assume hierarchical prefix delegation in the home (at least, = not=20 unless the WG develops such a solution).

                    10.  A host with mutli= ple=20 upstream paths to the same destination should be able to use another in cas= e on=20 fails.

                    11.  Prevent=20 looping.

                    12.  Prefix stability?=  =20

                    13.  Lightweight (chea= p)=20 implementation.

                    Let me know if I’ve missed, or mistated,=20 anything.

                     

                    Lee

                     

                    &nbs= p;

                    = This=20 E-mail and any of its attachments may contain Time Warner Cable proprietary= =20 information, which is privileged, confidential, or subject to copyright=20 belonging to Time Warner Cable. This E-mail is intended solely for the use = of=20 the individual or entity to which it is addressed. If you are not the inten= ded=20 recipient of this E-mail, you are hereby notified that any dissemination,=20 distribution, copying, or action taken in relation to the contents of and=20 attachments to this E-mail is strictly prohibited and may be unlawful. If y= ou=20 have received this E-mail in error, please notify the sender immediately an= d=20 permanently delete the original and any copy of this E-mail and any=20 printout.

                    --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB195EUSAACMS0715e_-- From shemant@cisco.com Fri Oct 21 19:05:47 2011 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 8845521F85AE for ; Fri, 21 Oct 2011 19:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwqqbnFZvAbV for ; Fri, 21 Oct 2011 19:05:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CF48C21F846D for ; Fri, 21 Oct 2011 19:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=27599; q=dns/txt; s=iport; t=1319249144; x=1320458744; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=IY9JrUIrh0cRaRbCrznYafB/dNeAVqBmytbQbIkSFTQ=; b=A2XyKXB/3P7jMWTsWAR4bQ0NqXeF1Ema3f8D94vSMLWyB9fFRdQGLwd5 YIiUQ5seSsZPyTHWz+0MBhnLnFBpZa0Bc+BUhdqohWcVECLlObmcfcEN1 15PB5aTjOCwbJkQGqFZEYO+GGAV7Udq+nj4Fts7tixdoC9wGtvzKUjZ1R U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAC0kok6tJV2d/2dsb2JhbABCgk2XE4d0AYdKgQWBbgEBAQQSAQkRA0IXAgEIEQQBAQsGCAgHAQYBRQkIAQEEARIIEweHZpR2AZ4thTGCLmEEiAORM4xD X-IronPort-AV: E=Sophos;i="4.69,389,1315180800"; d="scan'208,217";a="30202347" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2011 02:05:43 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9M25hwg006354; Sat, 22 Oct 2011 02:05:43 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 21:05:43 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC905F.1A6E3D1A" Date: Fri, 21 Oct 2011 21:05:41 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD816@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQAAEKcrAABaGVoAAD8rqg References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Howard, Lee" , "Samita Chakrabarti" , X-OriginalArrivalTime: 22 Oct 2011 02:05:43.0026 (UTC) FILETIME=[1AA5AD20:01CC905F] Subject: Re: [homenet] routing requirements 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, 22 Oct 2011 02:05:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC905F.1A6E3D1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 See how a network bridge/hub cause a problem in the home network. It's one thing that a Joe SixPack, or Grandma has a network bridge behind their CE router and the devices in the home are connected to the hub. I have personally seen a home with two broadband modems that were connected to a hub that looped DAD messages back to the SP that totally hosed the SP network interface for broadband IPv6 services. See the Introduction section of the following draft. The second example is the problem I speak of with the hub. =20 http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01 =20 Thus anything homenet designs, do assume a home user can have a hub anywhere in the network and protocols have to be designed for such a network. =20 =20 Hemant =20 From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 5:26 PM To: Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements =20 Can you describe some scenarios which would cause a prefix to change, in which applications break in ways that are unacceptable? All of the ones I can think of would be cases where I would expect a session to drop, but I'm sure that's a lack of creativity on my part. =20 Lee =20 From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com]=20 Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements =20 Hello Howard, =20 Thank you very much for the summary of messages. =20 A comment on item 12: 12. Prefix stability?=20 =20 SC> I expect that 'Prefix Stability' is a requirement at home or small offices. Without prefix stability some of the applications will suddenly break when the old prefix expires and the new prefix becomes effective. =20 And question to the wg: =20 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden). Choosing which address to use to look up the destination address is out of scope. =20 SC> Is the expectation from homenet wg that all hosts will implement RFC 3484 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think so ] So the host implementation change should be required if a host has to support multiple prefixes or I might be missing something? =20 =20 Thanks, -Samita =20 =20 ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requirements I've gleaned. Question marks are unclear to me, please help. =20 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple L2 types. 4. Border detection. =20 a. Border may be upstream ISP, or may be a device that is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to home net. Or there may be no border, if no external connection has been established. =20 b. Must be able to find "up" (a path to the Internet), but must not be dependent on "up" (Internet connectivity) existing for intra-home reachability. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device. Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scenarios. =20 b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condition? g. Source address selection is out of scope. And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden). Choosing which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least, not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be able to use another in case on fails.=20 11. Prevent looping. 12. Prefix stability? =20 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. =20 Lee =20 =20 ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------_=_NextPart_001_01CC905F.1A6E3D1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                     

                     

                    See how a network = bridge/hub cause a problem in the home network.   It’s = one thing that a Joe SixPack, or Grandma has a network bridge  = behind their CE router and the devices in the home are connected to the = hub.  I have personally seen a home with two broadband modems that = were connected to a hub that looped DAD messages back to the SP that = totally hosed the SP network interface for broadband IPv6 services. =   See the Introduction section of the following draft.  = The second example is the problem I speak of with the = hub.

                     

                    htt= p://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01<= /p>

                     

                    Thus anything homenet = designs, do assume a home user can have a hub anywhere in the network = and protocols have to be designed for such a network.  =

                     

                    Hemant

                     

                    From:= = homenet-bounces@ietf.org = [mailto:homenet-bounces= @ietf.org] On Behalf Of Howard, Lee
                    Sent: Friday, = October 21, 2011 5:26 PM
                    To: Samita Chakrabarti; homenet@ietf.org
                    Subject: = Re: [homenet] routing requirements

                     

                    Can you describe some scenarios which would = cause a prefix to change, in which applications break in ways that are = unacceptable?  All of the ones I can think of would be cases where = I would expect a session to drop, but I’m sure that’s a lack = of creativity on my part.

                     

                    Lee

                     

                    From:= = Samita Chakrabarti [mailto:samita.c= hakrabarti@ericsson.com]
                    Sent: Friday, October 21, 2011 = 5:08 PM
                    To: Howard, Lee; homenet@ietf.org
                    Subject: = RE: routing requirements

                     

                    He= llo Howard,

                     

                    Th= ank you very much for the summary of messages.

                     

                    A = comment on item 12:

                    12.  Prefix stability? 

                     

                    SC= >  I expect that 'Prefix Stability' is a requirement at home or = small offices. Without prefix stability some of the applications will = suddenly break when the old prefix expires and the new prefix becomes = effective.

                     

                    An= d question to the wg:

                     

                    8.   &= nbsp;  Support for multiple = upstream networks is a requirement.

                    g.   &= nbsp;  Source address selection = is out of scope.  And should be solved by rfc3484, with longest = prefix match (whether ULA or walled garden).  Choosing which = address to use to look up the destination address is out of = scope.

                     

                    SC> Is the expectation from homenet wg that all hosts = will implement RFC 3484 ?

                    Do the current home IPv6 host products support RFC 3484 ? = [ I don't think so ]  So the host implementation change should = be required if a host has to support multiple prefixes or I might = be missing something?

                     

                     

                    Thanks,

                    -Samita

                     

                     

                    From:= = homenet-bounces@ietf.org = [mailto:homenet-bounces= @ietf.org] On Behalf Of Howard, Lee
                    Sent: Friday, = October 21, 2011 11:32 AM
                    To: homenet@ietf.org
                    Subject: = [homenet] routing requirements

                    I've = caught up on some 300 messages about routing.  Here are the = requirements I've gleaned.  Question marks are unclear to me, = please help.

                     

                    1.     = Homenet router requirements

                    2.     = When evaluating a solution, discuss whether it provides = for:

                    3.     = Reachability between all nodes in the home = network.

                    a.     =   Links may be Ethernet, WiFi, MoCA, or any other; test all = solutions against mutliple L2 types.

                    4.     = Border detection. 

                    a.     =   Border may be upstream ISP, or may be a device that is a = gateway to SmartGrid devices, e.g. a controller that speaks RPL to = 802.15.4 and foo to home net.  Or there may be no border, if = no external connection has been established. 

                    b.     = Must be able to find “up” (a path to the Internet), = but must not be dependent on “up” (Internet connectivity) = existing for intra-home reachability.

                    c.     =   May be discovered by routing protocol, or other = means.

                    5.     = Robust to routers being = moved/added/removed/renumbered

                    a.     =   Convergence time a few minutes or less.

                    6.     = No configuration required.

                    a.     =   We might tolerate? a single password being entered on each = device.  Discuss.

                    7.     = Best-path is a non-requirement.

                    8.     = Support for multiple upstream networks is a = requirement.

                    a.     =   Including wireless offload, video-only, and split-tunnel = VPN scenarios. 

                    b.     = With separate routers to each.  Not multihomed off the same = router.

                    c.     =   Prefix delegated from all ISPs = (upstreams).

                    d.     = ISP A is default.

                    e.     =   With only traffic destined to ISP B’s prefix using = that link.

                    f.     =   With a backup default to ISP B, if desired.  What is = default condition?

                    g.     = Source address selection is out of scope.  And should be = solved by rfc3484, with longest prefix match (whether ULA or walled = garden).  Choosing which address to use to look up the destination = address is out of scope.

                    9.     = Cannot assume hierarchical prefix delegation in the home (at = least, not unless the WG develops such a solution).

                    10.  A host with = mutliple upstream paths to the same destination should be able to use = another in case on fails.

                    11.  Prevent = looping.

                    12.  Prefix = stability? 

                    13.  Lightweight = (cheap) implementation.

                    Let me = know if I’ve missed, or mistated, anything.

                     

                    Lee

                     

                     

                    Thi= s E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use 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 dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any = printout.

                    ------_=_NextPart_001_01CC905F.1A6E3D1A-- From curtis@occnc.com Fri Oct 21 19:37:13 2011 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 7AD5921F8ABE for ; Fri, 21 Oct 2011 19:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvy2g3jCXqOW for ; Fri, 21 Oct 2011 19:37:12 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10521F8AAC for ; Fri, 21 Oct 2011 19:37:11 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9M2b24A042328; Fri, 21 Oct 2011 19:37:03 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9M2b24A042328 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319251023; bh=sX3oLSisAAS8UAEg+U+OknBeGXCJUGftiltd17kDNqo=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=k7xaq7B4IB0D1cW0FHaS8yC2EQlJhT5/hSVxoBhMIXc2DvHVtaEtnEOxkHyg6q5MY gXqqvjUHRJva4roS681mC3wQ/pXss65E7KhOhrYzNEs2c1GT4x4a42TGfJHnVt5yDo uADFItmchqkp7M54wEu5TbDepSwS1Z2ZiHmkmdNw= Message-Id: <201110220237.p9M2b24A042328@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 17:22:32 EDT." Date: Fri, 21 Oct 2011 19:37:02 -0700 Cc: Cameron Byrne , james woodyatt , "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 02:37:13 -0000 In message "Howard, Lee" writes: > I've had some of these arguments before, but I'll write them down now > so there's a record. Maybe we should document the debated points in > a discussion draft, so we could invite further comment. > > > And, most (cite?) actual attacks are not preventable with a $30 home > > router. Most (cite?) homenet security issues are relate to phishing > > and users downloading and installing malware with admin privilege, > > which PCP and stateful firewalls cannot solve. > > Port scanning is largely blocked by stateful firewalls. Thus it's not > the prevention of actual attacks, but the fact that attacks don't > exist because they're useless given the existence of firewalls. Its absurd for companies to put firewalls in and then use that as an excuse to run tftp to load images or configuration. If you as a company get someone good to do a security audit, they will do port scans for you and tell you what, if anything, is a potential problem. For enterprise, using a firewall instead of doing this just means that as soon as one PC is running malware, that exposure is wide open. > > > So service providers are compelled to put firewalls in front of > > > consumer customers (and even most small business) and have them > > > enabled by default. > > btw, I realize we operated from different assumptions. My default > view is that the customer manages the gateway/firewall, not the ISP > (or maybe in addition to the ISP). So in my world view, it's clear > that the user (or host, or application) sets the security policy, > which is enforced by the firewall. So if one OS believes it is > invulnerable, it can signal the firewall to allow all traffic to it. > If another OS wants defense in depth, it can signal the firewall to > allow only wanted traffic. You may s/OS/app. Some MSOs install a router with firewall enabled. Most will cheerfully disable it completely on request. I got a MSO business service and it took a while before they disabled it *and* saved the config so it didn't come back, even though I kept telling them they needed to do that. It was a small battle to get them to turn off their NAT, their firewall, their DHCP, and then a bit of a larger battle to get them to do rDNS. > > Is there proof that $30 home routers protect computers and "move the > > needle" on malware? Or is this left over mindset from the 1990s? > > I argue they hold the needle on malware, and there's no reason to make > it easier to attack ignorant users. There are a lot of retired people where I live and many will tell you that they think its time to upgrade their windows 98 PC. They *need* someone to put up a firewall for them. > Somebody else once said: > > There are no attacks in IPv6, what are we protecting against? > > We should design security in before there are attacks, not wait and > see what gets attacked. > > To be constructive, I would like home routers (or at least home border > gateways) have a "default deny" security policy, which can be > overriden by user configuration or signaling from internal hosts that > traffic is wanted. "Signaling" could be PCP, uPNP, SYN, etc. > > Lee Agree. For consumer and small business, firewall enabled is a reasonable default. I would not like to see it recommended in an RFC unless it was explained why the sorry state of PC software has made it a necessary evil, at least for now. Curtis From cb.list6@gmail.com Fri Oct 21 19:37:37 2011 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 18C521F0C4A for ; Fri, 21 Oct 2011 19:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=-5.179, BAYES_00=-2.599, FB_NUMYO=10.357, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZHhlJAW8-ab for ; Fri, 21 Oct 2011 19:37:36 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4750F21F8AAC for ; Fri, 21 Oct 2011 19:37:36 -0700 (PDT) Received: by pzk34 with SMTP id 34so11364643pzk.9 for ; Fri, 21 Oct 2011 19:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5p6VA89ZWvR1WY6RjY9yXouOK+N5Ycz8Wum9nAONSqc=; b=g8baD8bI9beCNUVigd5JulEU/bB0yozslgbShCkEeK8W8ixK2hNZhJVp8zparD+YRl mrJ/H9+fOnqfYYvgHfLSWAl5lOegmTDQ9sFPP2jtv3FkDuOplatHLItnfSanB5s+nAi6 O7cFcQ/Sag4gItfAuks9Tb/TfG8tjzxNqL4iw= MIME-Version: 1.0 Received: by 10.68.39.170 with SMTP id q10mr32009795pbk.96.1319251055952; Fri, 21 Oct 2011 19:37:35 -0700 (PDT) Received: by 10.142.222.9 with HTTP; Fri, 21 Oct 2011 19:37:35 -0700 (PDT) Received: by 10.142.222.9 with HTTP; Fri, 21 Oct 2011 19:37:35 -0700 (PDT) In-Reply-To: <201110220152.p9M1qNfl041300@gateway.ipv6.occnc.com> References: <201110220152.p9M1qNfl041300@gateway.ipv6.occnc.com> Date: Fri, 21 Oct 2011 19:37:35 -0700 Message-ID: From: Cameron Byrne To: curtis@occnc.com Content-Type: multipart/alternative; boundary=bcaec520e5af8f440504afda12d9 Cc: "Howard, Lee" , "homenet@ietf.org" , james woodyatt Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 22 Oct 2011 02:37:37 -0000 --bcaec520e5af8f440504afda12d9 Content-Type: text/plain; charset=ISO-8859-1 On Oct 21, 2011 6:52 PM, "Curtis Villamizar" wrote: > > > In message > Cameron Byrne writes: > > > On Fri, Oct 21, 2011 at 12:04 PM, Curtis Villamizar wrote: > > > > > > In message > > > Cameron Byrne writes: > > > > > >> I am in the camp the host should be strong and smart and networks > > >> should be simple and fast. > > >> > > >> Cb > > > > > > Same here but we can't get rid of all the windows systems out there. > > > > > > > Why? Even windows XP comes with a host based firewall since 2003 ... > > That's coming up on 10 years by the time homenet influences the > > market. > > > > > > > > . blah blah blah... we all must engineer for the least common > > denominator because somebody out there can be attacked by the Morris > > Worm still... > > > > > > > > > > And, most (cite?) actual attacks are not preventable with a $30 home > > router. Most (cite?) homenet security issues are relate to phishing > > and users downloading and installing malware with admin privilege, > > which PCP and stateful firewalls cannot solve. > > > > > > > So service providers are compelled to put firewalls in front of > > > consumer customers (and even most small business) and have them > > > enabled by default. > > > > > > To not do so would result in the service provider having a network of > > > malicious bots (as opposed to a network containing a subset of sites > > > running malware that the service provider couldn't prevent). > > > > > > > Is there proof that $30 home routers protect computers and "move the > > needle" on malware? Or is this left over mindset from the 1990s? > > > > > > > Back in the early 1990s I argued that we should not let windows > > > systems on the Internet. That was back when your network (college > > > campuses, corporations, etc) could be shut down by a provider if > > > attacks were coming out of it and you did nothing to completely > > > eradicate it. An example of this was Mitnik breaking into a > > > university in Houston and Sesquinet shutting off their Internet for > > > four days due to a computer science department response that security > > > was a hard problem and from a practical standpoint there was nothing > > > they could do about it. Back then, if you couldn't make it secure, it > > > didn't belong on the Internet. > > > > > > > Would a firewall stopped this or was this social engineering? Also, > > this is not the 1990s... Things are indeed better now from a network > > programming perspective. Social engineering and so on are a different > > layer. > > > > > I do see your point and agree with you. From a technical perspective, > > > firewalls are an inadequate bandaid over a set of OS and application > > > security problems and the right thing to do is fix the root casue. > > > > > ^^^^ > > Good stuff there. Lets focus on that instead of the dogma and FUD to > > create "homenet" of the future. > > > > Thanks, > > > > Cameron > > > > > Curtis > > > Cameron, > > I was arguing against firewalls as a security solution. You seemed to > have missed the whole point of the email. Pleae reread it. > Got it, no firewalls, you are against them. > At most you could say that I conceded that firewalls are a marginal > improvement (and therefore won't go away). For the provider it may be > whether 90% of their users end up running malware or 10% (cite?). > When there is a new remote exploit discovered it limits the damage. Got it, you think firewalls are required because gradma is running BIND 8. But, my point is that sp3 windows xp has a default on firewalls. So, assume 10yo software, what exploits are we preventing? How often do they occur? I am just looking for specific data so we can make a data supported decision. Cb --bcaec520e5af8f440504afda12d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


                    On Oct 21, 2011 6:52 PM, "Curtis Villamizar" <curtis@occnc.com> wrote:
                    >
                    >
                    > In message <CAD6AjGQCbRkqE4tg3P=3D+PgcujyFZ-01BK6jr1byxvHCqUWavAg@mail.gmail.= com>
                    > Cameron Byrne writes:
                    >
                    > > On Fri, Oct 21, 2011 at 12:04 PM, Curtis Villamizar <curtis@occnc.com> wrote:
                    > > >
                    > > > In message <CAD6AjGRqy4yjHpWnY+qEiyuJ8egvNtH=3D5stj=3D4KnDYxbivTmWA@mail.gmail.com>
                    > > > Cameron Byrne writes:
                    > > >
                    > > >> I am in the camp the host should be strong and smart and= networks
                    > > >> should be simple and fast.
                    > > >>
                    > > >> Cb
                    > > >
                    > > > Same here but we can't get rid of all the windows system= s out there.
                    > > >
                    > >
                    > > Why? =A0Even windows XP comes with a host based firewall since 20= 03 ...
                    > > That's coming up on 10 years by the time homenet influences t= he
                    > > market.
                    > >
                    > > <sarcasm>
                    > >
                    > > . blah blah blah... we all must engineer for the least common
                    > > denominator because somebody out there can be attacked by the Mor= ris
                    > > Worm still...
                    > >
                    > > </sarcasm>
                    > >
                    > >
                    > > And, most (cite?) actual attacks are not preventable with a $30 h= ome
                    > > router. =A0Most (cite?) homenet security issues are relate to phi= shing
                    > > and users downloading and installing malware with admin privilege= ,
                    > > which PCP and stateful firewalls cannot solve.
                    > >
                    > >
                    > > > So service providers are compelled to put firewalls in front= of
                    > > > consumer customers (and even most small business) and have t= hem
                    > > > enabled by default.
                    > > >
                    > > > To not do so would result in the service provider having a n= etwork of
                    > > > malicious bots (as opposed to a network containing a subset = of sites
                    > > > running malware that the service provider couldn't preve= nt).
                    > > >
                    > >
                    > > Is there proof that $30 home routers protect computers and "= move the
                    > > needle" on malware? =A0Or is this left over mindset from =A0= the 1990s?
                    > >
                    > >
                    > > > Back in the early 1990s I argued that we should not let wind= ows
                    > > > systems on the Internet. =A0That was back when your network = (college
                    > > > campuses, corporations, etc) could be shut down by a provide= r if
                    > > > attacks were coming out of it and you did nothing to complet= ely
                    > > > eradicate it. =A0An example of this was Mitnik breaking into= a
                    > > > university in Houston and Sesquinet shutting off their Inter= net for
                    > > > four days due to a computer science department response that= security
                    > > > was a hard problem and from a practical standpoint there was= nothing
                    > > > they could do about it. =A0Back then, if you couldn't ma= ke it secure, it
                    > > > didn't belong on the Internet.
                    > > >
                    > >
                    > > Would a firewall stopped this or was this social engineering? =A0= Also,
                    > > this is not the 1990s... Things are indeed better now from a netw= ork
                    > > programming perspective. Social engineering and so on are a diffe= rent
                    > > layer.
                    > >
                    > > > I do see your point and agree with you. =A0From a technical = perspective,
                    > > > firewalls are an inadequate bandaid over a set of OS and app= lication
                    > > > security problems and the right thing to do is fix the root = casue.
                    > > >
                    > > ^^^^
                    > > Good stuff there. =A0Lets focus on that instead of the dogma and = FUD to
                    > > create "homenet" of the future.
                    > >
                    > > Thanks,
                    > >
                    > > Cameron
                    > >
                    > > > Curtis
                    >
                    >
                    > Cameron,
                    >
                    > I was arguing against firewalls as a security solution. =A0You seemed = to
                    > have missed the whole point of the email. =A0Pleae reread it.
                    >

                    Got it, no firewalls, you are against them.

                    > At most you could say that I conceded that firewalls are a marginal=
                    > improvement (and therefore won't go away). =A0For the provider it = may be
                    > whether 90% of their users end up running malware or 10% (cite?).
                    > When there is a new remote exploit discovered it limits the damage.

                    Got it, you think firewalls are required because gradma is running BIND = 8.

                    But, my point is that sp3 windows xp has a default on firewalls. So, ass= ume 10yo software, what exploits are we preventing? How often do they occur= ?

                    I am just looking for specific data so we can make a data supported deci= sion.

                    Cb

                    --bcaec520e5af8f440504afda12d9-- From curtis@occnc.com Fri Oct 21 19:56:46 2011 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 445D211E808C for ; Fri, 21 Oct 2011 19:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXsYyABObKjl for ; Fri, 21 Oct 2011 19:56:45 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0811E8081 for ; Fri, 21 Oct 2011 19:56:45 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9M2ufP5042759; Fri, 21 Oct 2011 19:56:41 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9M2ufP5042759 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319252201; bh=vwPWyiCoezH3Ff8O0+iu0TAsPtmaLNqs2OYSfedeZTo=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=FnrkOAXvjAeOwn9uw93kqehEGbtFnPPZYlaa+bbHiYKd8fxZ9XFeiOpmmNlNYHzl4 Lze+Yf7OY+H8mfm+gsqJFIqC7JgemrFxaj+NKKOHhfYyR7/14wczZXpWb5QxA5YPP7 nqDJR8CscXnh5PPzo2vKAbli38YEY//X4/5Lt4Aw= Message-Id: <201110220256.p9M2ufP5042759@gateway.ipv6.occnc.com> To: Samita Chakrabarti From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 17:07:49 EDT." <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> Date: Fri, 21 Oct 2011 19:56:41 -0700 Cc: "Howard, Lee" , "homenet@ietf.org" Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 02:56:46 -0000 In message <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> Samita Chakrabarti writes: > Hello Howard, > > Thank you very much for the summary of messages. > > A comment on item 12: > 12. Prefix stability? > > SC> I expect that 'Prefix Stability' is a requirement at home or small > SC> offices. Without prefix stability some of the applications will > SC> suddenly break when the old prefix expires and the new prefix > SC> becomes effective. > > And question to the wg: > > 8. Support for multiple upstream networks is a requirement. > > g. Source address selection is out of scope. And should be solved by > rfc3484, with longest prefix match (whether ULA or walled garden). > Choosing which address to use to look up the destination address is > out of scope. > > SC> Is the expectation from homenet wg that all hosts will implement > SC> RFC 3484 ? > > SC> Do the current home IPv6 host products support RFC 3484 ? [ I > SC> don't think so ] So the host implementation change should be > SC> required if a host has to support multiple prefixes or I might be > SC> missing something? > > Thanks, > > -Samita A host can only be assigned multiple prefixes and have one essentially "taken away" if it is know to be OK with it. An extension (to an address allocation such as DHCP{4,6}) can easily be crefted that allows the host to communicate the capability. Prefix stability is then only a requirement for the legacy hosts. Any more recent hosts can give up an address. AFAIK all OS today support IPv6. All recent hosts should support RFC 3484 (it is a 2003 RFC). You'll still find some very old software out there, so not all. Worse than no IPv6 would be old broken IPv6 code. I don't think this WG should focus on that small minority. Curtis From cb.list6@gmail.com Fri Oct 21 20:02:03 2011 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 D4F001F0C45 for ; Fri, 21 Oct 2011 20:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.443 X-Spam-Level: ** X-Spam-Status: No, score=2.443 tagged_above=-999 required=5 tests=[AWL=-4.316, BAYES_00=-2.599, FB_NUMYO=10.357, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5kIYh9uLWAh for ; Fri, 21 Oct 2011 20:02:02 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2027E1F0C34 for ; Fri, 21 Oct 2011 20:02:02 -0700 (PDT) Received: by pzk34 with SMTP id 34so11400174pzk.9 for ; Fri, 21 Oct 2011 20:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/jDrD13+i4cSWDPRNrqLZsTuZFRoHYQ6YgiZHJ6FjcU=; b=sIpwExksufjeGO5o0lAJkKNkydVUQL7KTGgK/6O0OGCxlFTwDVdQaOaVm75Ppe+zYw 6MIInqRjuc6Vf0ySu437NF2do3N/7E/dL9JFdNqePY/04jc7rQQoY3f5uZoeHdD9qe6R +JTsx7/uiLCnvfemwGXl4lDyWS8PpgYe5xAZk= MIME-Version: 1.0 Received: by 10.68.38.169 with SMTP id h9mr32140224pbk.113.1319252521836; Fri, 21 Oct 2011 20:02:01 -0700 (PDT) Received: by 10.142.222.9 with HTTP; Fri, 21 Oct 2011 20:02:01 -0700 (PDT) Received: by 10.142.222.9 with HTTP; Fri, 21 Oct 2011 20:02:01 -0700 (PDT) In-Reply-To: References: <201110220152.p9M1qNfl041300@gateway.ipv6.occnc.com> Date: Fri, 21 Oct 2011 20:02:01 -0700 Message-ID: From: Cameron Byrne To: curtis@occnc.com Content-Type: multipart/alternative; boundary=bcaec520f1bdeee11004afda6922 Cc: "Howard, Lee" , "homenet@ietf.org" , james woodyatt Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 22 Oct 2011 03:02:03 -0000 --bcaec520f1bdeee11004afda6922 Content-Type: text/plain; charset=ISO-8859-1 On Oct 21, 2011 7:37 PM, "Cameron Byrne" wrote: > > > On Oct 21, 2011 6:52 PM, "Curtis Villamizar" wrote: > > > > > > In message > > Cameron Byrne writes: > > > > > On Fri, Oct 21, 2011 at 12:04 PM, Curtis Villamizar wrote: > > > > > > > > In message > > > > Cameron Byrne writes: > > > > > > > >> I am in the camp the host should be strong and smart and networks > > > >> should be simple and fast. > > > >> > > > >> Cb > > > > > > > > Same here but we can't get rid of all the windows systems out there. > > > > > > > > > > Why? Even windows XP comes with a host based firewall since 2003 ... > > > That's coming up on 10 years by the time homenet influences the > > > market. > > > > > > > > > > > > . blah blah blah... we all must engineer for the least common > > > denominator because somebody out there can be attacked by the Morris > > > Worm still... > > > > > > > > > > > > > > > And, most (cite?) actual attacks are not preventable with a $30 home > > > router. Most (cite?) homenet security issues are relate to phishing > > > and users downloading and installing malware with admin privilege, > > > which PCP and stateful firewalls cannot solve. > > > > > > > > > > So service providers are compelled to put firewalls in front of > > > > consumer customers (and even most small business) and have them > > > > enabled by default. > > > > > > > > To not do so would result in the service provider having a network of > > > > malicious bots (as opposed to a network containing a subset of sites > > > > running malware that the service provider couldn't prevent). > > > > > > > > > > Is there proof that $30 home routers protect computers and "move the > > > needle" on malware? Or is this left over mindset from the 1990s? > > > > > > > > > > Back in the early 1990s I argued that we should not let windows > > > > systems on the Internet. That was back when your network (college > > > > campuses, corporations, etc) could be shut down by a provider if > > > > attacks were coming out of it and you did nothing to completely > > > > eradicate it. An example of this was Mitnik breaking into a > > > > university in Houston and Sesquinet shutting off their Internet for > > > > four days due to a computer science department response that security > > > > was a hard problem and from a practical standpoint there was nothing > > > > they could do about it. Back then, if you couldn't make it secure, it > > > > didn't belong on the Internet. > > > > > > > > > > Would a firewall stopped this or was this social engineering? Also, > > > this is not the 1990s... Things are indeed better now from a network > > > programming perspective. Social engineering and so on are a different > > > layer. > > > > > > > I do see your point and agree with you. From a technical perspective, > > > > firewalls are an inadequate bandaid over a set of OS and application > > > > security problems and the right thing to do is fix the root casue. > > > > > > > ^^^^ > > > Good stuff there. Lets focus on that instead of the dogma and FUD to > > > create "homenet" of the future. > > > > > > Thanks, > > > > > > Cameron > > > > > > > Curtis > > > > > > Cameron, > > > > I was arguing against firewalls as a security solution. You seemed to > > have missed the whole point of the email. Pleae reread it. > > > > Got it, no firewalls, you are against them. > > > At most you could say that I conceded that firewalls are a marginal > > improvement (and therefore won't go away). For the provider it may be > > whether 90% of their users end up running malware or 10% (cite?). > > When there is a new remote exploit discovered it limits the damage. > > Got it, you think firewalls are required because gradma is running BIND 8. > > But, my point is that sp3 windows xp has a default on firewalls. So, assume 10yo software, what exploits are we preventing? How often do they occur? > > I am just looking for specific data so we can make a data supported decision. > > Cb http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10 Accoding to this data, 0.16% are running win2k, which afaik does not have a standard OS based default firewall and is the last Windows OS to not have a standard host based firewall that prevents remote attacks. Are we really engineering and setting security policy for less than1%? Keep in mind this 1% is getting even smaller. Cb --bcaec520f1bdeee11004afda6922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


                    On Oct 21, 2011 7:37 PM, "Cameron Byrne" <                    cb.list6@gmail.com> wrote:
                    >
                    >
                    > On Oct 21, 2011 6:52 PM, "Curtis Villamizar" <curtis@occnc.com> wrote:
                    > >
                    > >
                    > > In message <CAD6AjGQCbRkqE4tg3P=3D+PgcujyFZ-01BK6jr1byxvHCqUWavAg@mail.g= mail.com>
                    > > Cameron Byrne writes:
                    > >
                    > > > On Fri, Oct 21, 2011 at 12:04 PM, Curtis Villamizar <curtis@occnc.com> wrote:
                    > > > >
                    > > > > In message <CAD6AjGRqy4yjHpWnY+qEiyuJ8egvNtH=3D5stj= =3D4KnDYxbivTmWA@mail.gmail= .com>
                    > > > > Cameron Byrne writes:
                    > > > >
                    > > > >> I am in the camp the host should be strong and smar= t and networks
                    > > > >> should be simple and fast.
                    > > > >>
                    > > > >> Cb
                    > > > >
                    > > > > Same here but we can't get rid of all the windows s= ystems out there.
                    > > > >
                    > > >
                    > > > Why? =A0Even windows XP comes with a host based firewall sin= ce 2003 ...
                    > > > That's coming up on 10 years by the time homenet influen= ces the
                    > > > market.
                    > > >
                    > > > <sarcasm>
                    > > >
                    > > > . blah blah blah... we all must engineer for the least commo= n
                    > > > denominator because somebody out there can be attacked by th= e Morris
                    > > > Worm still...
                    > > >
                    > > > </sarcasm>
                    > > >
                    > > >
                    > > > And, most (cite?) actual attacks are not preventable with a = $30 home
                    > > > router. =A0Most (cite?) homenet security issues are relate t= o phishing
                    > > > and users downloading and installing malware with admin priv= ilege,
                    > > > which PCP and stateful firewalls cannot solve.
                    > > >
                    > > >
                    > > > > So service providers are compelled to put firewalls in = front of
                    > > > > consumer customers (and even most small business) and h= ave them
                    > > > > enabled by default.
                    > > > >
                    > > > > To not do so would result in the service provider havin= g a network of
                    > > > > malicious bots (as opposed to a network containing a su= bset of sites
                    > > > > running malware that the service provider couldn't = prevent).
                    > > > >
                    > > >
                    > > > Is there proof that $30 home routers protect computers and &= quot;move the
                    > > > needle" on malware? =A0Or is this left over mindset fro= m =A0the 1990s?
                    > > >
                    > > >
                    > > > > Back in the early 1990s I argued that we should not let= windows
                    > > > > systems on the Internet. =A0That was back when your net= work (college
                    > > > > campuses, corporations, etc) could be shut down by a pr= ovider if
                    > > > > attacks were coming out of it and you did nothing to co= mpletely
                    > > > > eradicate it. =A0An example of this was Mitnik breaking= into a
                    > > > > university in Houston and Sesquinet shutting off their = Internet for
                    > > > > four days due to a computer science department response= that security
                    > > > > was a hard problem and from a practical standpoint ther= e was nothing
                    > > > > they could do about it. =A0Back then, if you couldn'= ;t make it secure, it
                    > > > > didn't belong on the Internet.
                    > > > >
                    > > >
                    > > > Would a firewall stopped this or was this social engineering= ? =A0Also,
                    > > > this is not the 1990s... Things are indeed better now from a= network
                    > > > programming perspective. Social engineering and so on are a = different
                    > > > layer.
                    > > >
                    > > > > I do see your point and agree with you. =A0From a techn= ical perspective,
                    > > > > firewalls are an inadequate bandaid over a set of OS an= d application
                    > > > > security problems and the right thing to do is fix the = root casue.
                    > > > >
                    > > > ^^^^
                    > > > Good stuff there. =A0Lets focus on that instead of the dogma= and FUD to
                    > > > create "homenet" of the future.
                    > > >
                    > > > Thanks,
                    > > >
                    > > > Cameron
                    > > >
                    > > > > Curtis
                    > >
                    > >
                    > > Cameron,
                    > >
                    > > I was arguing against firewalls as a security solution. =A0You se= emed to
                    > > have missed the whole point of the email. =A0Pleae reread it.
                    > >
                    >
                    > Got it, no firewalls, you are against them.
                    >
                    > > At most you could say that I conceded that firewalls are a margin= al
                    > > improvement (and therefore won't go away). =A0For the provide= r it may be
                    > > whether 90% of their users end up running malware or 10% (cite?).=
                    > > When there is a new remote exploit discovered it limits the damag= e.
                    >
                    > Got it, you think firewalls are required because gradma is running BIN= D 8.
                    >
                    > But, my point is that sp3 windows xp has a default on firewalls. So, a= ssume 10yo software, what exploits are we preventing? How often do they occ= ur?
                    >
                    > I am just looking for specific data so we can make a data supported de= cision.
                    >
                    > Cb

                    http://www.netmarketshare.com/operating-system-market-shar= e.aspx?qprid=3D10

                    Accoding to this data, 0.16% are running win2k, which afaik does not hav= e a standard OS based default firewall and is the last Windows OS to not ha= ve a standard host based firewall that prevents remote attacks.

                    Are we really engineering and setting security policy for less than1%?= =A0 Keep in mind this 1% is getting even smaller.

                    Cb

                    --bcaec520f1bdeee11004afda6922-- From curtis@occnc.com Fri Oct 21 20:13:45 2011 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 0F5751F0C45 for ; Fri, 21 Oct 2011 20:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqq2CWCrIzJJ for ; Fri, 21 Oct 2011 20:13:44 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCA61F0C3C for ; Fri, 21 Oct 2011 20:13:43 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9M3Dc4N043180; Fri, 21 Oct 2011 20:13:38 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9M3Dc4N043180 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319253219; bh=4S4Zf3fewXDAp6FHcw35CVMbrlJYMZUv2xKqM0rJm3Y=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=JlPYFlnot+FHy9Qz4nDLSBhDRwQPXv6h4H4yBio3dwbp5liaIdLE3DbNOB3rQVA4V gsBrEcNxt8gk6oJ8J8afRmvz94C6gVe7R8O70GqsI5gLDGmLs8m87A664NZnYKfZs8 OR/LDUyjLEDpGdLgiqRwtmw8ShFM2doTjcF8cAdU= Message-Id: <201110220313.p9M3Dc4N043180@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 17:26:14 EDT." Date: Fri, 21 Oct 2011 20:13:38 -0700 Cc: Samita Chakrabarti , "homenet@ietf.org" Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 03:13:45 -0000 In message "Howard, Lee" writes: > Can you describe some scenarios which would cause a prefix to change, > in which applications break in ways that are unacceptable? All of the > ones I can think of would be cases where I would expect a session to > drop, but I'm sure that's a lack of creativity on my part. > > Lee Most IPv4 hosts can't tolerate their IP address going away. For IPv6 its slightly easier because they can add a new address in a new prefix. Only think is the host need to ask for an address and today if its lease has not expired it won't ask. Some older DHCP code won't take a change in address or default route when the lease expires. One thing that would break is any open TCP connections. The open connections use the already selected address. This has been a problem for mobility for quite a while but those heavier solution can't be applied to this problem. Concievably a TCP extension could support alternate source addresses (such as SCTP does). Until then, a TCP connection can't change addresses. If you switch from one provider uplink to another, you should be able to keep talking to your content provider. Currently you can't. For web users, hit the stop and the reload. Curtis From curtis@occnc.com Fri Oct 21 20:39:15 2011 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 E694311E8091 for ; Fri, 21 Oct 2011 20:39:15 -0700 (PDT) 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.061, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3XQIEVZHtEj for ; Fri, 21 Oct 2011 20:39:15 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D091011E808C for ; Fri, 21 Oct 2011 20:39:14 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9M3dAhW046084; Fri, 21 Oct 2011 20:39:10 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9M3dAhW046084 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319254751; bh=wKIz0tR0fXFv0JzjSxare5njetcQplLHi/C2phhWcvI=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=qOgDVuuPRPAu6K6n1Lw48WzAdrDt1/Bt/J4wyUWrCP7HA1hlxmYbAthniZzOcPRU/ O1uJBnqKxgBcyuM4K3vK2ibOT/zKN4nhREBYWypi/wqnmhWty4In6/ldMx3b6eOf4W NicnqiGBmoi+kCmcZPpAaAuB6aMgIwahiA30da+E= Message-Id: <201110220339.p9M3dAhW046084@gateway.ipv6.occnc.com> To: Jim Gettys From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 16:50:07 EDT." <4EA1DAFF.6080500@freedesktop.org> Date: Fri, 21 Oct 2011 20:39:10 -0700 Cc: "Howard, Lee" , "homenet@ietf.org" , Don Sturek Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 03:39:16 -0000 This is a response to Lee's list with Jim's additions. > "Howard, Lee" wrote: > >> I've caught up on some 300 messages about routing. Here are the requirements I've gleaned. Question marks are unclear to me, please help. >> >> >> >> 1. Homenet router requirements >> >> 2. When evaluating a solution, discuss whether it provides for: >> >> 3. Reachability between all nodes in the home network. >> >> a. Links may be Ethernet, WiFi, MoCA, or any other; test all >> solutions against mutliple L2 types. >> >> 4. Border detection. >> >> a. Border may be upstream ISP, or may be a device that is a >> gateway to SmartGrid devices, e.g. a controller that speaks RPL to >> 802.15.4 and foo to home net. Or there may be no border, if no >> external connection has been established. >> >> b. Must be able to find "up" (a path to the Internet), but >> must not be dependent on "up" (Internet connectivity) existing for >> intra-home reachability. >> >> c. May be discovered by routing protocol, or other means. >> >> 5. Robust to routers being moved/added/removed/renumbered This almost covers one of Jim's points. Jim added unitentional join. >> a. Convergence time a few minutes or less. Seconds at least. Goal for providers is 60 msec, but subsecond would be a reasonable goal for wired. >> 6. No configuration required. >> >> a. We might tolerate? a single password being entered on each >> device. Discuss. Default requested for core is all access disabled unless overridden by physical access (ie: hold button and power cycle sort of thing, but need not be a power cycle or reboot.) The physical access can be used to open some interface to allow install of an initial key/password. >> 7. Best-path is a non-requirement. It should be a goal but not a hard requirement. >> 8. Support for multiple upstream networks is a requirement. >> >> a. Including wireless offload, video-only, and split-tunnel >> VPN scenarios. >> >> b. With separate routers to each. Not multihomed off the same >> router. >> >> c. Prefix delegated from all ISPs (upstreams). This will be hard and may require detection of hosts with new capabilities and a (less functional) fallback strategy for others. >> d. ISP A is default. >> >> e. With only traffic destined to ISP B's prefix using that link. >> >> f. With a backup default to ISP B, if desired. What is >> default condition? With no designated A or B, closest is the default, with hysteresis. A tie breaker rule would be less desireable. >> g. Source address selection is out of scope. And should be >> solved by rfc3484, with longest prefix match (whether ULA or walled >> garden). Choosing which address to use to look up the destination >> address is out of scope. >> >> 9. Cannot assume hierarchical prefix delegation in the home >> (at least, not unless the WG develops such a solution). Here I disagree. Must assume hierarchical prefix delegation. ULAs are not globally routeable. ND proxy will fail Jim's scalability test in an instant. >> 10. A host with mutliple upstream paths to the same destination >> should be able to use another in case on fails. The problem is really which address to use in this case. RFC 3484 does not solve this unless the prefix for the now down uplink is removed. Adding a rule to bias the selection toward the prefix from which the default route is learned would be an update to RFC 3484. >> 11. Prevent looping. Yes please! >> 12. Prefix stability? For legacy hosts. Detect hosts which don't need it. >> 13. Lightweight (cheap) implementation. >> >> Let me know if I've missed, or mistated, anything. > In message <4EA1DAFF.6080500@freedesktop.org> > Jim Gettys writes: > > A couple missed: reference the scars on my back I discussed earlier: > > Scalability analysis, both for the dense mesh case, and the non-dense > case, > > Behaviour/scaling when run on wireless, and its ability to handle both > wired and wireless links. > > Robustness in the face of unintentional joining of networks. > - Jim Nice list. Thanks. Curtis From curtis@occnc.com Fri Oct 21 21:14:11 2011 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 9E31321F8557 for ; Fri, 21 Oct 2011 21:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[AWL=-5.365, BAYES_00=-2.599, FB_GET_MEDS=2.75, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, MANGLED_CHEAP=2.3, MANGLED_HOME=2.3, MANGLED_MEDS=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIIaoEhY2T4E for ; Fri, 21 Oct 2011 21:14:08 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id EC34721F8551 for ; Fri, 21 Oct 2011 21:14:07 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9M4DwOh052270; Fri, 21 Oct 2011 21:13:59 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9M4DwOh052270 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319256841; bh=R2ENvK7/SE0yAycA3TjXNgUqhhJsxEmaYPPtwVX8JDY=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=Failfm8NnvSOLer73rVoJFdYG2jhA4TCcYdgqu6XoZtra3vj0YBv7sojQWssnuoHN zgdxYTzoY6jyxho0lypbeVFnaGQB7db/cBqHNmxxe/cRcHvmCjtzIUxbLHiyvRUe0f CATqziuvUueUeQ28OtVHpyETtC+0pYItY+DRFRDQ= Message-Id: <201110220413.p9M4DwOh052270@gateway.ipv6.occnc.com> To: Samita Chakrabarti From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 21:48:15 EDT." <16D60F43CA0B724F8052D7E9323565D7243F7EB191@EUSAACMS0715.eamcs.ericsson.se> Date: Fri, 21 Oct 2011 21:13:58 -0700 Cc: "Howard, Lee" , "homenet@ietf.org" , "Hemant Singh \(shemant\)" Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 04:14:11 -0000 Address assignment must be a separate protocol so that it is not tied to one specific routing protocol. OTOH it can (and IMO should) make use of hints from the routing protocols at to where the uplinks are and how close they are in selecting among available addresses. For IPv4 where DHCP likes to see one address only, supporting legacy hosts is a harder problem. Any extension mean that accomodation have to be made for legacy hosts. Curtis In message <16D60F43CA0B724F8052D7E9323565D7243F7EB191@EUSAACMS0715.eamcs.ericsson.se> Samita Chakrabarti writes: --===============2644728098816532559== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_" --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Hemant for the information from V6ops discussion on zospf prefix del= egation. In my humble view: - Prefix assignment should be independent from a routing protocol - Binding prefix-assignment to a routing protocol creates the problem of sy= nchronization as you pointed out and also it limits the user to a single ro= uting protocol for the network. I think the users/operators should have fle= xibility to choose a routing protocol for the services they offer today and= in future. I'd really like to see IPv6 PD solution for the home network for network st= ability after a power outage or bringing up a new set of network. We have gone through similar debate in RPL development timeframe and finall= y as far as I know RPL made the prefix configuration optional. If someone thinks that a new version of ospfv3 will introduce prefix assign= ment as a optional feature for a particular application/environment where i= t might work perfectly - I am okay with that. It is difficult for me to thi= nk OSPFv3 being the default choice to configure ip-addresses in a home netw= ork. In future, home network will grow further - I expect that there will be tw= o kinds of users at home - 1) tech-challenged users who like plug-n-play 2= ) tech-savvy users running business or running multi-level networks at home= for convenience and pleasure or whatever reasons. So it'll be a combinatio= n of big and small ip-enabled devices and lots of them... Regards, -Samita ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Friday, October 21, 2011 5:18 PM To: Howard, Lee; Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements Note the IETF IPv6 CE router specifies use of the ULA in the home to keep t= he home network independent of the SP network. This way my computer at hom= e can still print to the printer even when my SP IPv6 network is down. We = have said this multiple time in v6ops during development of the IPv6 CE rou= ter RFC 6204. I don't have the time to read the copious emails of homenet,= but seeing some emails here and there I see homenet regressing on issues t= hat are closed in the v6ops IPv6 CE router document development. Examples = of issues homenet is regressing on is ND Proxy and use of zospf for prefix = delegation in the LAN. There was only one cell phone vendor who was askin= g us for ND Proxy with a single /64 PD delegated to the phone. We convinc= ed the vendor at the Prague IETF to abandon that idea because such a /64 wo= uld need RA Proxy in the CE router and RA Proxy is not defined is any RFC. = Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. That = is why ND Proxy was removed from the cpe rtr bis document. Zospf was also closed in v6ops that it's not possible to use for prefix del= egation in the LAN. Here is an email to v6ops on closure on ospf for pref= ix delegation. Hemant ---- begin snip ------------ From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Wednesday, July 27, 2011 1:26 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >Can such a default be extensible to exchange different types of informatio= n than just reachability? For example, can it propagate information such as= "this is a guest network and this is an internal network" or "this is a pr= efix that I have tentatively >assigned but do not own yet"? If not, then pe= rhaps something more flexible like IS-IS would be better. Not possible because the proposal is not workable. Someone brought up usi= ng OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE rout= er design team. See the questions I asked followed by the person's reply a= nd my responses back to show no routing protocol can be used to delegate pr= efixes in the LAN. I asked, HS: How do you know OSPF has converged before responding to DHCPv6= PD requests? Reply: The CE router SHOULD wait until two sequential link-state advertisem= ents have no link state changes before delegating any prefixes. This allo= ws time for OSPF to converge, and for the router to build a topology map. Seeing the above reply, I made my comment: HS: Still does not work. After OSPF converges, what happens if the user ch= anges the network such as unplugging a router and moving the router? Reply: The router has a link state table-when it changes, you go through di= scovery again and issue a Reconfigure where appropriate. HS: There is a network bridge between two routers and the bridge does not = have any means to report link-up or down. Further, what if a network inte= rface of a router is flapping all the time and thus basing any algorithm o= n OSPF convergence breaks down. The flapping interface problem becomes wo= rse if one has a cyclic network. Your proposal still does not work. Hemant ------ end snip --------- From: homenet-bounces@ietf.org [mailto:hom= enet-bounces@ietf.org] On Behalf = Of Howard, Lee Sent: Friday, October 21, 2011 5:26 PM To: Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements Can you describe some scenarios which would cause a prefix to change, in wh= ich applications break in ways that are unacceptable? All of the ones I ca= n think of would be cases where I would expect a session to drop, but I'm s= ure that's a lack of creativity on my part. Lee From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements Hello Howard, Thank you very much for the summary of messages. A comment on item 12: 12. Prefix stability? SC> I expect that 'Prefix Stability' is a requirement at home or small off= ices. Without prefix stability some of the applications will suddenly break= when the old prefix expires and the new prefix becomes effective. And question to the wg: 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. SC> Is the expectation from homenet wg that all hosts will implement RFC 34= 84 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think s= o ] So the host implementation change should be required if a host has to = support multiple prefixes or I might be missing something? Thanks, -Samita ________________________________ From: homenet-bounces@ietf.org [mailto:hom= enet-bounces@ietf.org] On Behalf = Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requiremen= ts I've gleaned. Question marks are unclear to me, please help. 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solution= s against mutliple L2 types. 4. Border detection. a. Border may be upstream ISP, or may be a device that is a gateway t= o SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo = to home net. Or there may be no border, if no external connection has been= established. b. Must be able to find "up" (a path to the Internet), but must not be= dependent on "up" (Internet connectivity) existing for intra-home reachabi= lity. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device.= Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scena= rios. b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condi= tion? g. Source address selection is out of scope. And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden). Choosin= g which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least,= not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be = able to use another in case on fails. 11. Prevent looping. 12. Prefix stability? 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. 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. --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
                     
                    Thanks Hemant for the information from=20 V6ops discussion on zospf prefix delegation= .
                    = In my humble=20 view:
                    =  - Prefix assignment should= =20 be independent  from a routing=20 protocol
                    = - Binding prefix-assignment to a = routing=20 protocol creates the problem of synchronization as you pointed out and also= it=20 limits the user to a single routing protocol for the network. I think the=20 users/operators should have flexibility to choose a routing protocol for th= e=20 services they offer today and in future.
                     
                    I'd really like to see IPv6 PD solution for the = home=20 network for network stability after a power outage or bringing up a new set= of=20 network.
                    We have gone through similar debate in RPL devel= opment=20 timeframe and finally as far as I know RPL made the prefix configuration=20 optional.
                     
                    If someone thinks that a new version of ospfv3 w= ill=20 introduce prefix assignment as a optional feature for a particular=20 application/environment where it might work perfectly - I am okay with that= . It=20 is difficult for me to think OSPFv3 being the default choice to configure=20 ip-addresses in a home network.
                    In future, home network will grow further  = - I=20 expect that there will be two kinds of users at home - 1)  tech-challe= nged=20 users who like plug-n-play 2) tech-savvy users running business or running= =20 multi-level networks at home for convenience and pleasure or whatever reaso= ns.=20 So it'll be a combination of big and small ip-enabled devices and lots of=20 them...
                     
                    Regards,
                    -Samita

                    From: homenet-bounces@ietf.org=20 [mailto:homenet-bounces@ietf.org] On Behalf Of Hemant Singh=20 (shemant)
                    Sent: Friday, October 21, 2011 5:18 PM
                    To: Ho= ward,=20 Lee; Samita Chakrabarti; homenet@ietf.org
                    Subject: Re: [homenet]= =20 routing requirements

                    Note the IETF IPv6 CE r= outer=20 specifies use of the ULA in the home to keep the home network independent o= f the=20 SP network.  This way my computer at home can still print to the print= er=20 even when my SP IPv6 network is down.  We have said this multiple time= in=20 v6ops during development of the IPv6 CE router RFC 6204.  I don’= t have the=20 time to read the copious emails of homenet, but seeing some emails here and= =20 there I see homenet regressing on issues that are closed in the v6ops IPv6 = CE=20 router document development.  Examples of issues homenet is regressing= on=20 is ND Proxy and use of zospf for prefix delegation in the LAN.   = There=20 was only one cell phone vendor who was asking us for ND Proxy with a single= /64=20 PD delegated to the phone.   We convinced the vendor at the Pragu= e=20 IETF to abandon that idea because such a /64 would need RA Proxy in the CE= =20 router and RA Proxy is not defined is any RFC.  Thus the vendor agreed= and=20 decided to go with DHCPv6 PD of RC 3633.  That is why ND Proxy was rem= oved=20 from the cpe rtr bis document.

                     

                    Zospf was also closed i= n v6ops=20 that it’s not possible to use for prefix delegation in the LAN.  = ; Here=20 is an email to v6ops on closure on ospf for prefix delegation. =20

                     

                    Hemant

                     

                    ---- begin snip=20 ------------

                     

                    From:<= /B> Lorenzo Coli= tti [mailto:lorenzo@google.com]= =20
                    Sent: Wednesday, July 27, 2011 1:26 PM
                    To: Hemant Sing= h=20 (shemant)
                    Cc: IPv6 Operations
                    Subject: Re: [v6ops] defa= ult=20 LAN routing protocol for IPv6 CE router

                    &nbs= p;

                     

                    >Can such a d= efault be=20 extensible to exchange different types of information than just reachabilit= y?=20 For example, can it propagate information such as "this is a guest network = and=20 this is an internal network" or "this is a prefix that I have tentatively <= SPAN=20 style=3D"COLOR: #1f497d">>assigned but do not own yet"? If not, t= hen=20 perhaps something more flexible like IS-IS would be better.

                     

                    Not possible because th= e=20 proposal is not workable.   Someone brought up using OSPFv3 for u= se in=20 prefix delegation in the home LAN to our IETF CPE router design team. = See=20 the questions I asked followed by the person’s reply and my responses= back to=20 show no routing protocol can be used to delegate prefixes in the LAN.=20  

                     

                    I asked, HS: How do you= know=20 OSPF has converged before responding to DHCPv6 PD=20 requests?

                     

                    Reply: The CE router SH= OULD wait=20 until two sequential link-state advertisements have no link state  cha= nges=20 before delegating any prefixes.  This allows time for OSPF to converge= , and=20 for the  router to build a topology map.

                     

                    Seeing the above reply,= I made=20 my comment:

                     

                    HS: Still does not work= . =20 After OSPF converges, what happens if the user changes the network such &nb= sp;as=20 unplugging a router and moving the router?

                     

                    Reply: The router has a= link=20 state table—when it changes, you go through discovery again and issue= a=20  Reconfigure where appropriate. 

                     

                    HS:  There is a ne= twork=20 bridge between two routers and the bridge does not have any means to report= =20 link-up  or down.  Further, what if a network interface of a rout= er is=20 flapping all the time and thus  basing any algorithm on OSPF convergen= ce=20 breaks down.  The flapping interface problem becomes  worse if on= e has=20 a cyclic network.  Your proposal still does not work. =20

                     

                    Hemant

                     

                     

                    ------ end snip=20 ---------

                     

                     

                     

                     

                     

                    From:<= /B> homenet-bounces@ietf.org [mailto:homenet-bounces@i= etf.org]=20 On Behalf Of Howard, Lee
                    Sent: Friday, October 21, 2011 5:= 26=20 PM
                    To: Samita Chakrabarti; homenet@ietf.org
                    Subject: Re= :=20 [homenet] routing requirements

                     

                    Can=20 you describe some scenarios which would cause a prefix to change, in which= =20 applications break in ways that are unacceptable?  All of the ones I c= an=20 think of would be cases where I would expect a session to drop, but I’= ;m sure=20 that’s a lack of creativity on my part.

                     

                    Lee

                     

                    From:<= /B> Samita Chakr= abarti=20 [mailto:samita.cha= krabarti@ericsson.com]=20
                    Sent: Friday, October 21, 2011 5:08 PM
                    To: Howard, Lee= ; homenet@ietf.org
                    Subject: RE= :=20 routing requirements

                     

                    H= ello=20 Howard,

                     

                    T= hank=20 you very much for the summary of messages.

                     

                    A= =20 comment on item 12:

                    12. =20 Prefix=20 stability? 

                     

                    S= C> =20 I expect that 'Prefix Stability' is a requirement at home or small offices.= =20 Without prefix stability some of the applications will suddenly break when = the=20 old prefix expires and the new prefix becomes effective.

                     

                    A= nd=20 question to the wg:

                     

                    8.   =   =20 Support for multiple upstream networks i= s a=20 requirement.

                    g.   =   =20 Source address selection is out of scope= . =20 And should be solved by rfc3484, with longest prefix match (whether ULA or= =20 walled garden).  Choosing which address to use to look up the destinat= ion=20 address is out of scope.

                     

                    SC>=20 Is the expectation from homenet wg that all hosts will implement RFC 3484=20 ?

                    Do=20 the current home IPv6 host products support RFC 3484 ? [ I don't think so=20 ]  So the host implementation change should be required if a= host=20 has to support multiple prefixes or I might be missing=20 something?

                     

                     

                    Thanks,

                    -Samita

                     

                     

                    From:<= /B> homenet-bounces@ietf.org [mailto:homenet-bounces@i= etf.org]=20 On Behalf Of Howard, Lee
                    Sent: Friday, October 21, 2011 11= :32=20 AM
                    To: homenet@ietf.org
                    Subject: [h= omenet]=20 routing requirements

                    I've caught up on some 300 messages about routing.&= nbsp;=20 Here are the requirements I've gleaned.  Question marks are unclear to= me,=20 please help.

                     

                    1.     = =20 Homenet router requirements

                    2.     = =20 When evaluating a solution, discuss whether it provides=20 for:

                    3.     = =20 Reachability between all nodes in the home network.

                         &= nbsp;=20 Links may be Ethernet, WiFi, MoCA, or any other; test all solutions= =20 against mutliple L2 types.

                    4.     = =20 Border detection. 

                         &= nbsp;=20 Border may be upstream ISP, or may be a device that is a gateway to= =20 SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo= =20 to home net.  Or there may be no border, if no external connection has= been=20 established. 

                         = =20 Must be able to find “up” (a path to the Internet), but = must not be=20 dependent on “up” (Internet connectivity) existing for intra-ho= me=20 reachability.

                         &= nbsp;=20 May be discovered by routing protocol, or other means.

                    5.     = =20 Robust to routers being moved/added/removed/renumbered

                         &= nbsp;=20 Convergence time a few minutes or less.

                    6.     = =20 No configuration required.

                         &= nbsp;=20 We might tolerate? a single password being entered on each device.&n= bsp;=20 Discuss.

                    7.     = =20 Best-path is a non-requirement.

                    8.     = =20 Support for multiple upstream networks is a requirement.<= /P>

                         &= nbsp;=20 Including wireless offload, video-only, and split-tunnel VPN=20 scenarios. 

                         = =20 With separate routers to each.  Not multihomed off the same=20 router.

                         &= nbsp;=20 Prefix delegated from all ISPs (upstreams).

                         = =20 ISP A is default.

                         &= nbsp;=20 With only traffic destined to ISP B’s prefix using that=20 link.

                         &= nbsp;=20 With a backup default to ISP B, if desired.  What is default=20 condition?

                         = =20 Source address selection is out of scope.  And should be solved= by=20 rfc3484, with longest prefix match (whether ULA or walled garden). =20 Choosing which address to use to look up the destination address is out of= =20 scope.

                    9.     = =20 Cannot assume hierarchical prefix delegation in the home (at least, = not=20 unless the WG develops such a solution).

                    10.  A host with mutli= ple=20 upstream paths to the same destination should be able to use another in cas= e on=20 fails.

                    11.  Prevent=20 looping.

                    12.  Prefix stability?=  =20

                    13.  Lightweight (chea= p)=20 implementation.

                    Let me know if I’ve missed, or mistated,=20 anything.

                     

                    Lee

                     

                    &nbs= p;

                    = This=20 E-mail and any of its attachments may contain Time Warner Cable proprietary= =20 information, which is privileged, confidential, or subject to copyright=20 belonging to Time Warner Cable. This E-mail is intended solely for the use = of=20 the individual or entity to which it is addressed. If you are not the inten= ded=20 recipient of this E-mail, you are hereby notified that any dissemination,=20 distribution, copying, or action taken in relation to the contents of and=20 attachments to this E-mail is strictly prohibited and may be unlawful. If y= ou=20 have received this E-mail in error, please notify the sender immediately an= d=20 permanently delete the original and any copy of this E-mail and any=20 printout.

                    --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_-- --===============2644728098816532559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --===============2644728098816532559==-- From curtis@occnc.com Fri Oct 21 21:48:30 2011 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 0AF0321F889A for ; Fri, 21 Oct 2011 21:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.715 X-Spam-Level: ** X-Spam-Status: No, score=2.715 tagged_above=-999 required=5 tests=[AWL=-5.042, BAYES_00=-2.599, FB_NUMYO=10.357, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIcs87k31saY for ; Fri, 21 Oct 2011 21:48:29 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81621F854F for ; Fri, 21 Oct 2011 21:48:28 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9M4mJgO056000; Fri, 21 Oct 2011 21:48:19 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9M4mJgO056000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319258900; bh=S6HZvJNxsXcP2yUuQtvEZB4G4yA55IQKtwQNNnTifFg=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=QRNHjBEoUyb5Mv9+82w2E0+LnYlRHXyKQMeaHE0rnf3dVw23o3tYt0mT7369srDJP ucwXydR+DUxfrSV+Np+LDgnExgg9B5qB8Z5PU9Q2aTR9WqV6FYtPmUJu1BJUxzJoO0 osy9at3sBeyaiPeLMJ39K2fotNxkt9l51HoCyXXk= Message-Id: <201110220448.p9M4mJgO056000@gateway.ipv6.occnc.com> To: Cameron Byrne From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Oct 2011 19:37:35 PDT." Date: Fri, 21 Oct 2011 21:48:18 -0700 Cc: "Howard, Lee" , "homenet@ietf.org" , james woodyatt , curtis@occnc.com Subject: Re: [homenet] Homenet Architecture & Interim Meeting X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 04:48:30 -0000 In message Cameron Byrne writes: > > > > Cameron, > > > > I was arguing against firewalls as a security solution. You seemed to > > have missed the whole point of the email. Pleae reread it. > > > > Got it, no firewalls, you are against them. > > > At most you could say that I conceded that firewalls are a marginal > > improvement (and therefore won't go away). For the provider it may be > > whether 90% of their users end up running malware or 10% (cite?). > > When there is a new remote exploit discovered it limits the damage. > > Got it, you think firewalls are required because gradma is running > BIND 8. > > But, my point is that sp3 windows xp has a default on firewalls. So, > assume 10yo software, what exploits are we preventing? How often do > they occur? > > I am just looking for specific data so we can make a data supported > decision. > > Cb As far as I am concerned you may have come close to winning this argument with the statistic that 0.16% of hosts predate firewalls in the host OS. OTOH - I don't think the last windows remote exploit predates when XP was introduced. Search for "microsoft windows and remote exploit" at http://www.kb.cert.org/vuls/html/search to get plenty of data to support your decisions. Here is a 2008 example where a firewall would help: http://www.kb.cert.org/vuls/id/827267 . It took a few minutes to find an exploit like this in the very long list. Most attacks do involve getting the user to view a web page or open an email attachment or something like that. For example http://www.kb.cert.org/vuls/id/230057 (that's 2011). And in such a case a firewall usually doesn't help. There are tons of these. Curtis From Ray.Bellis@nominet.org.uk Mon Oct 24 01:16:07 2011 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 2594721F84C3 for ; Mon, 24 Oct 2011 01:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.875 X-Spam-Level: X-Spam-Status: No, score=-9.875 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+pmFW0h06Za for ; Mon, 24 Oct 2011 01:16:06 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id AB8F721F849B for ; Mon, 24 Oct 2011 01:16:01 -0700 (PDT) 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=1/RQ5mq+2Gm09K+TP8vahTn9Zpre9o7GO85U+BcgtEexhbVbBxxRJ4FW 8hXzT546zAFd1u2dE/BKAiZeLF7lDK60fdCbtGCZkWKKWnb+PJEF4BJiB ge/aq8vwxz/GhUX; 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=1319444165; x=1350980165; 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]=20Homenet=20Architecture=20& =20Interim=20Meeting|Date:=20Mon,=2024=20Oct=202011=2008: 15:45=20+0000|Message-ID:=20|To:=20""=20|CC:=20"homenet@ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quo ted-printable|Content-ID:=20<25c3509c-b083-471b-b5f9-bf78 73466ce4>|In-Reply-To:=20<201110211849.p9LInoFh030890@gat eway.ipv6.occnc.com>|References:=20<201110211849.p9LInoFh 030890@gateway.ipv6.occnc.com>; bh=yGc6PoX8cxXORJ8zcPuW/7GSzAj6CGr06uAMFvGtD0E=; b=C5y9/rSa4S62ve5+QSEjXGzg9CySblrSixaT+s1AW0uWG7+TsBtiF9CO tZ5DFksibWlUcwjXlO0VueUvIlEKC4SVyVot6x6CtkSNatHKdiTXOuoeV dK05QSF4KkvRHpm; X-IronPort-AV: E=Sophos;i="4.69,396,1315177200"; d="scan'208";a="29142683" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 24 Oct 2011 09:15:47 +0100 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%19]) with mapi; Mon, 24 Oct 2011 09:15:47 +0100 From: Ray Bellis To: "" Thread-Topic: [homenet] Homenet Architecture & Interim Meeting Thread-Index: AQHMkCI28DzF36CsTUySedb9CHb/TZWLGTmA Date: Mon, 24 Oct 2011 08:15:45 +0000 Message-ID: References: <201110211849.p9LInoFh030890@gateway.ipv6.occnc.com> In-Reply-To: <201110211849.p9LInoFh030890@gateway.ipv6.occnc.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: <25c3509c-b083-471b-b5f9-bf7873466ce4> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] Homenet Architecture & Interim Meeting 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, 24 Oct 2011 08:16:07 -0000 On 21 Oct 2011, at 19:49, Curtis Villamizar wrote: > What people are arguing is a violation of the end-to-end principle is > having a provider put in place filters that can't be shut of by the > consumer. Anything outside of the home network is outside of our scope. Ray From Ray.Bellis@nominet.org.uk Mon Oct 24 01:24:21 2011 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 7A63D21F8C78 for ; Mon, 24 Oct 2011 01:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.695 X-Spam-Level: X-Spam-Status: No, score=-7.695 tagged_above=-999 required=5 tests=[AWL=-1.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiErNnH09sZC for ; Mon, 24 Oct 2011 01:24:20 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE7A21F8C7E for ; Mon, 24 Oct 2011 01:24:19 -0700 (PDT) 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: MIME-Version; b=qSK4xjBfSaIzDFdfy60QHVQtxarPvnihM+30mvsjj/fcI6c45fYpw8GV lrvpNNZXIbOabK4UMTFVokud2diHGcine+L6QXkuP7ECZbg31jBThAB9x bw1LDz7q+fFMeix; 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=1319444660; x=1350980660; 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]=20routing=20requirements |Date:=20Mon,=2024=20Oct=202011=2008:24:16=20+0000 |Message-ID:=20<5E233369-AB87-4E4D-88E9-1CC8FB8FC691@nomi net.org.uk>|To:=20"Hemant=20Singh=20(shemant)"=20|CC:=20"homenet@ietf.org"=20 |MIME-Version:=201.0|In-Reply-To:=20<5B6B2B64C9FE2A489045 EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com>|References: =20<16D60F43CA0B724F8052D7E9323565D7243F7E B0BB@EUSAACMS0715.eamcs.ericsson.se>=0D=0A=20=0D=0A=20<5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB -RCD-109.cisco.com>; bh=Yqgx3JxZJWgWhAx3lmXkLsTjxzrN1P7JzF4FUkHFjO8=; b=MoBYXG6c1sp3APA/Tm5qbJF+8dMBiBrxQ79FV9QkJMdtcXeeno75OF62 R7/8gmQdeOcJtpSGsrLuLgsvNY2BHBu8qwdGfGQVCHZMSVuVJOa5GTIU/ kTnnkzjvjhUBjwJ; X-IronPort-AV: E=Sophos;i="4.69,396,1315177200"; d="scan'208,217";a="36117748" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 24 Oct 2011 09:24:18 +0100 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%19]) with mapi; Mon, 24 Oct 2011 09:24:18 +0100 From: Ray Bellis To: "Hemant Singh (shemant)" Thread-Topic: [homenet] routing requirements Thread-Index: AQHMkFApRPmtbMOJVUGdaImEsxSYMpWLGz8A Date: Mon, 24 Oct 2011 08:24:16 +0000 Message-ID: <5E233369-AB87-4E4D-88E9-1CC8FB8FC691@nominet.org.uk> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5E233369AB874E4D88E91CC8FB8FC691nominetorguk_" MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] routing requirements 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, 24 Oct 2011 08:24:21 -0000 --_000_5E233369AB874E4D88E91CC8FB8FC691nominetorguk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 22 Oct 2011, at 01:18, Hemant Singh (shemant) wrote: Note the IETF IPv6 CE router specifies use of the ULA in the home to keep t= he home network independent of the SP network. This way my computer at hom= e can still print to the printer even when my SP IPv6 network is down. We = have said this multiple time in v6ops during development of the IPv6 CE rou= ter RFC 6204. Thanks for the reminder. FWIW, I believe the consensus _is_ for ULAs withi= n the home network, although I do see a few vocal opponents. I don=92t have the time to read the copious emails of homenet, but seeing s= ome emails here and there I see homenet regressing on issues that are close= d in the v6ops IPv6 CE router document development. Examples of issues hom= enet is regressing on is ND Proxy and use of zospf for prefix delegation in= the LAN. There was only one cell phone vendor who was asking us for ND P= roxy with a single /64 PD delegated to the phone. We convinced the vendor= at the Prague IETF to abandon that idea because such a /64 would need RA P= roxy in the CE router and RA Proxy is not defined is any RFC. Thus the ven= dor agreed and decided to go with DHCPv6 PD of RC 3633. That is why ND Pro= xy was removed from the cpe rtr bis document. Will those arguing for ND Proxy please stand up and be counted? Zospf was also closed in v6ops that it=92s not possible to use for prefix d= elegation in the LAN. Here is an email to v6ops on closure on ospf for pr= efix delegation. Again, thanks, that's useful background. Ray --_000_5E233369AB874E4D88E91CC8FB8FC691nominetorguk_ Content-Type: text/html; charset="Windows-1252" Content-ID: <382371d0-02b1-446d-900a-1c5960163239> Content-Transfer-Encoding: quoted-printable
                    <= div>
                    On 22 Oct 2011, at 01:18, Hemant Singh (shemant) wrote:

                    =
                    No= te the IETF IPv6 CE router specifies use of the ULA in the home to keep the= home network independent of the SP network.  This way my computer at = home can still print to the printer even when my SP IPv6 network is down.&n= bsp; We have said this multiple time in v6ops during development of the IPv= 6 CE router RFC 6204.

                    =
                    Thanks for the reminder.  FWIW, I believe the consensus _is_ for= ULAs within the home network, although I do see a few vocal opponents.

                    I don=92t have the time t= o read the copious emails of homenet, but seeing some emails here and there= I see homenet regressing on issues that are closed in the v6ops IPv6 CE ro= uter document development.  Examples of issues homenet is regressing o= n is ND Proxy and use of zospf for prefix delegation in the LAN.  &nbs= p;There was only one cell phone vendor who was asking us for ND Proxy with = a single /64 PD delegated to the phone.   We convinced the vendor= at the Prague IETF to abandon that idea because such a /64 would need RA P= roxy in the CE router and RA Proxy is not defined is any RFC.  Thus th= e vendor agreed and decided to go with DHCPv6 PD of RC 3633.  That is = why ND Proxy was removed from the cpe rtr bis document.
                    <= /div>

                    Will those arguing for ND Prox= y please stand up and be counted?

                    Zospf was also closed in v6ops that it=92s not possible to= use for prefix delegation in the LAN.   Here is an email to v6op= s on closure on ospf for prefix delegation. 
                    <= /span>

                    Again, thanks, that's useful background.<= /div>

                    Ray


                    = --_000_5E233369AB874E4D88E91CC8FB8FC691nominetorguk_-- From Ray.Bellis@nominet.org.uk Mon Oct 24 01:28:05 2011 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 991B821F8C1A for ; Mon, 24 Oct 2011 01:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.753 X-Spam-Level: X-Spam-Status: No, score=-9.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4eL+DBPouJJ for ; Mon, 24 Oct 2011 01:28:05 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id BD8C621F8C19 for ; Mon, 24 Oct 2011 01:28:04 -0700 (PDT) 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: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=3D8HkEL2a0orYkzF71hyLfrRRsk26mNHg4jQRAxzL9U82+kvH3Lf5zsd SSaMgXQSUGVe/B9BenRDoWpr5S14PA+r1WnHSWMmk8P3YI4GE9gx46rTa sncocGqzOGndG7D; 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=1319444884; x=1350980884; 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]=20routing=20requirements |Date:=20Mon,=2024=20Oct=202011=2008:28:02=20+0000 |Message-ID:=20<1D5F43A5-57B7-40EC-92B3-214C7E4F0E3A@nomi net.org.uk>|To:=20"homenet@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<0dc08259-96c0-4c94-8b63-5eac6d56 1c93>|In-Reply-To:=20<201110220339.p9M3dAhW046084@gateway .ipv6.occnc.com>|References:=20<201110220339.p9M3dAhW0460 84@gateway.ipv6.occnc.com>; bh=Mhh+Xv+T8njR/4OeDaj9597J0VidDZCFre6aqep5BPI=; b=q0JG4k2mwKdqGEYqPVC0x0/S3EC4DwbjHay2BLFq5yN51wLZFMioDZyO ledPa4WAjwsYEWPLsI8xwIhtYIIacXZs17zm9Pk1kwoIQcqgXAAqhplz+ 12qlczImFjLbzC2; X-IronPort-AV: E=Sophos;i="4.69,396,1315177200"; d="scan'208";a="29142902" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 24 Oct 2011 09:28:03 +0100 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%19]) with mapi; Mon, 24 Oct 2011 09:28:03 +0100 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: [homenet] routing requirements Thread-Index: AQHMkGwoRPmtbMOJVUGdaImEsxSYMpWLHBQA Date: Mon, 24 Oct 2011 08:28:02 +0000 Message-ID: <1D5F43A5-57B7-40EC-92B3-214C7E4F0E3A@nominet.org.uk> References: <201110220339.p9M3dAhW046084@gateway.ipv6.occnc.com> In-Reply-To: <201110220339.p9M3dAhW046084@gateway.ipv6.occnc.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: <0dc08259-96c0-4c94-8b63-5eac6d561c93> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] routing requirements 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, 24 Oct 2011 08:28:05 -0000 On 22 Oct 2011, at 04:39, Curtis Villamizar wrote: > Nice list. +1 from me, too. This looks to me like a good basis for a detailed routing requirements draf= t... Ray From cb.list6@gmail.com Mon Oct 24 06:27:18 2011 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 EB41C21F8BEB for ; Mon, 24 Oct 2011 06:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGz-Fcl88YB8 for ; Mon, 24 Oct 2011 06:27:17 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE49B21F85F1 for ; Mon, 24 Oct 2011 06:27:16 -0700 (PDT) Received: by qyk34 with SMTP id 34so1867761qyk.10 for ; Mon, 24 Oct 2011 06:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gtQKU8+oOgWq2inuMJBpM3XPv5znKKAT6Xa/aiejcBg=; b=aCIDSPUvfQsJOHhCPD8hAjb02Wl7RxlLC9bffIZ9IjC5cJDoM3R63JNplgIiXn8mgK n4bSmhXYmjRPe+Eytt6Pr69xpSHDRBQiTZ4C5oQME5wlDwiZ5re/cv+U20JqsiKSL/ue hPPmAeygXkfAaEEEPJ40O41BwDP7241yoVuyU= MIME-Version: 1.0 Received: by 10.68.12.104 with SMTP id x8mr48347451pbb.79.1319462836226; Mon, 24 Oct 2011 06:27:16 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Mon, 24 Oct 2011 06:27:15 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Mon, 24 Oct 2011 06:27:15 -0700 (PDT) In-Reply-To: <5E233369-AB87-4E4D-88E9-1CC8FB8FC691@nominet.org.uk> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5E233369-AB87-4E4D-88E9-1CC8FB8FC691@nominet.org.uk> Date: Mon, 24 Oct 2011 06:27:15 -0700 Message-ID: From: Cameron Byrne To: Ray Bellis Content-Type: multipart/alternative; boundary=bcaec51f9061a5c95104b00b61ea Cc: "homenet@ietf.org" , "Hemant Singh \(shemant\)" Subject: Re: [homenet] routing requirements 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, 24 Oct 2011 13:27:18 -0000 --bcaec51f9061a5c95104b00b61ea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Oct 24, 2011 1:24 AM, "Ray Bellis" wrote: > > > On 22 Oct 2011, at 01:18, Hemant Singh (shemant) wrote: > >> Note the IETF IPv6 CE router specifies use of the ULA in the home to kee= p the home network independent of the SP network. This way my computer at home can still print to the printer even when my SP IPv6 network is down. We have said this multiple time in v6ops during development of the IPv6 CE router RFC 6204. > > > Thanks for the reminder. FWIW, I believe the consensus _is_ for ULAs within the home network, although I do see a few vocal opponents. > >> I don=92t have the time to read the copious emails of homenet, but seein= g some emails here and there I see homenet regressing on issues that are closed in the v6ops IPv6 CE router document development. Examples of issue= s homenet is regressing on is ND Proxy and use of zospf for prefix delegation in the LAN. There was only one cell phone vendor who was asking us for ND Proxy with a single /64 PD delegated to the phone. We convinced the vendo= r at the Prague IETF to abandon that idea because such a /64 would need RA Proxy in the CE router and RA Proxy is not defined is any RFC. Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. That is why ND Proxy was removed from the cpe rtr bis document. > > > Will those arguing for ND Proxy please stand up and be counted? > I am not arguing for ND proxy, just saying the mobile device may use it to extend their connectivity into the house. So I am not saying the home route= r will do nd proxy, unless you consider the mobile attached device to be the home router itself. There is no standcardized support for dhcp-pd in 3gpp yet, it is in the pipe, and deployment will vary. Nd proxy is not a bad solution here. In the case of 3gpp mobile device, nd proxy is only extending the users's attached /64 p2p link onto a LAN, it is not sharing with other customers or provider infrastructure. Cb >> Zospf was also closed in v6ops that it=92s not possible to use for prefi= x delegation in the LAN. Here is an email to v6ops on closure on ospf for prefix delegation. > > > Again, thanks, that's useful background. > > Ray > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --bcaec51f9061a5c95104b00b61ea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


                    On Oct 24, 2011 1:24 AM, "Ray Bellis" <Ray.Bellis@nominet.org.uk> wrote:
                    >
                    >
                    > On 22 Oct 2011, at 01:18, Hemant Singh (shemant) wrote:
                    >
                    >> Note the IETF IPv6 CE router specifies use of the ULA in the home = to keep the home network independent of the SP network.=A0 This way my comp= uter at home can still print to the printer even when my SP IPv6 network is= down.=A0 We have said this multiple time in v6ops during development of th= e IPv6 CE router RFC 6204.
                    >
                    >
                    > Thanks for the reminder. =A0FWIW, I believe the consensus _is_ for ULA= s within the home network, although I do see a few vocal opponents.
                    >
                    >> I don=92t have the time to read the copious emails of homenet, but= seeing some emails here and there I see homenet regressing on issues that = are closed in the v6ops IPv6 CE router document development.=A0 Examples of= issues homenet is regressing on is ND Proxy and use of zospf for prefix de= legation in the LAN.=A0 =A0There was only one cell phone vendor who was ask= ing us for ND Proxy with a single /64 PD delegated to the phone.=A0=A0 We c= onvinced the vendor at the Prague IETF to abandon that idea because such a = /64 would need RA Proxy in the CE router and RA Proxy is not defined is any= RFC.=A0 Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633= .=A0 That is why ND Proxy was removed from the cpe rtr bis document.
                    >
                    >
                    > Will those arguing for ND Proxy please stand up and be counted?
                    >

                    I am not arguing for ND proxy, just saying the mobile device may use it = to extend their connectivity into the house. So I am not saying the home ro= uter will do nd proxy, unless you consider the mobile attached device to be= the home router itself.

                    There is no standcardized support for dhcp-pd in 3gpp yet, it is in the = pipe, and deployment will vary. Nd proxy is not a bad solution here.

                    In the case of 3gpp mobile device, nd proxy is only extending the users&= #39;s attached /64 p2p link onto a LAN, it is not sharing with other custom= ers or provider infrastructure.

                    Cb
                    >> Zospf was also closed in v6ops that it=92s not possible to use for= prefix delegation in the LAN. =A0=A0Here is an email to v6ops on closure o= n ospf for prefix delegation.=A0
                    >
                    >
                    > Again, thanks, that's useful background.
                    >
                    > Ray
                    >
                    >
                    >
                    > _______________________________________________
                    > homenet mailing list
                    > homenet@ietf.org
                    > https://www.= ietf.org/mailman/listinfo/homenet
                    >

                    --bcaec51f9061a5c95104b00b61ea-- From lee.howard@twcable.com Mon Oct 24 06:28:32 2011 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 3C15021F8C22 for ; Mon, 24 Oct 2011 06:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqrYmP3BYPo0 for ; Mon, 24 Oct 2011 06:28:31 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1273621F8BEB for ; Mon, 24 Oct 2011 06:28:30 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,397,1315195200"; d="scan'208";a="288777413" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Oct 2011 09:24:27 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 24 Oct 2011 09:28:15 -0400 From: "Howard, Lee" To: "curtis@occnc.com" Date: Mon, 24 Oct 2011 09:28:15 -0400 Thread-Topic: [homenet] routing requirements Thread-Index: AcySUMil+qqx6mS7TFS8mgPG//cI6g== Message-ID: <1DD9DEAE-0F85-41A1-B4C9-C8C09BC84D45@twcable.com> References: <201110220339.p9M3dAhW046084@gateway.ipv6.occnc.com> In-Reply-To: <201110220339.p9M3dAhW046084@gateway.ipv6.occnc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" , Don Sturek , Jim Gettys Subject: Re: [homenet] routing requirements 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, 24 Oct 2011 13:28:32 -0000 On Oct 21, 2011, at 11:39 PM, Curtis Villamizar wrote: > > This is a response to Lee's list with Jim's additions. > >> "Howard, Lee" wrote: >> >>> I've caught up on some 300 messages about routing. Here are the requir= ements I've gleaned. Question marks are unclear to me, please help. >>> >>> >>> >>> 1. Homenet router requirements >>> >>> 2. When evaluating a solution, discuss whether it provides for: >>> >>> 3. Reachability between all nodes in the home network. >>> >>> a. Links may be Ethernet, WiFi, MoCA, or any other; test all >>> solutions against mutliple L2 types. >>> >>> 4. Border detection. >>> >>> a. Border may be upstream ISP, or may be a device that is a >>> gateway to SmartGrid devices, e.g. a controller that speaks RPL to >>> 802.15.4 and foo to home net. Or there may be no border, if no >>> external connection has been established. >>> >>> b. Must be able to find "up" (a path to the Internet), but >>> must not be dependent on "up" (Internet connectivity) existing for >>> intra-home reachability. >>> >>> c. May be discovered by routing protocol, or other means. >>> >>> 5. Robust to routers being moved/added/removed/renumbered > > This almost covers one of Jim's points. Jim added unitentional join. > >>> a. Convergence time a few minutes or less. > > Seconds at least. Goal for providers is 60 msec, but subsecond would > be a reasonable goal for wired. > Why would we need that level of repair? This is a home network, not a carrier network. >>> 6. No configuration required. >>> >>> a. We might tolerate? a single password being entered on each >>> device. Discuss. > > Default requested for core is all access disabled unless overridden by > physical access (ie: hold button and power cycle sort of thing, but > need not be a power cycle or reboot.) The physical access can be used > to open some interface to allow install of an initial key/password. > >>> 7. Best-path is a non-requirement. > > It should be a goal but not a hard requirement. Why? > >>> 8. Support for multiple upstream networks is a requirement. >>> >>> a. Including wireless offload, video-only, and split-tunnel >>> VPN scenarios. >>> >>> b. With separate routers to each. Not multihomed off the same >>> router. >>> >>> c. Prefix delegated from all ISPs (upstreams). > > This will be hard and may require detection of hosts with new > capabilities and a (less functional) fallback strategy for others. Yes. Maybe this should be an assumption, not a requirement, and the resolution of issues around it is dependent on how we do address assignment. The trouble here is that there's no way for two ISPs two coordinate prefix assignment, so they will both reply with IA_PD, and two routers will try to use those prefixes. > >>> d. ISP A is default. >>> >>> e. With only traffic destined to ISP B's prefix using that link. >>> >>> f. With a backup default to ISP B, if desired. What is >>> default condition? > > With no designated A or B, closest is the default, with hysteresis. A > tie breaker rule would be less desireable. What does "closest" mean? Longest match? > >>> g. Source address selection is out of scope. And should be >>> solved by rfc3484, with longest prefix match (whether ULA or walled >>> garden). Choosing which address to use to look up the destination >>> address is out of scope. >>> >>> 9. Cannot assume hierarchical prefix delegation in the home >>> (at least, not unless the WG develops such a solution). > > Here I disagree. Must assume hierarchical prefix delegation. > > ULAs are not globally routeable. ND proxy will fail Jim's scalability > test in an instant. I would prefer a hierarchical solution. I have not been able to finish writing up my proposed solution, but it's pretty much "wait to see if anyone else needs a prefix from you, then request all the prefixes you need." Here again, what assumptions we take for routing depend on what we do for address assignment. Until then, I think we should not assume hierarchical delegation. > >>> 10. A host with mutliple upstream paths to the same destination >>> should be able to use another in case on fails. > > The problem is really which address to use in this case. RFC 3484 > does not solve this unless the prefix for the now down uplink is > removed. Adding a rule to bias the selection toward the prefix from > which the default route is learned would be an update to RFC 3484. Deprecating the prefix would help, yes. For in-home destinations, any prefix should work. > >>> 12. Prefix stability? > > For legacy hosts. Detect hosts which don't need it. I don't understand this requirement, I just captured it from discussion. Why is it required? > >>> 13. Lightweight (cheap) implementation. >>> >>> Let me know if I've missed, or mistated, anything. > >> In message <4EA1DAFF.6080500@freedesktop.org> >> Jim Gettys writes: >> >> A couple missed: reference the scars on my back I discussed earlier: >> >> Scalability analysis, both for the dense mesh case, and the non-dense >> case, >> >> Behaviour/scaling when run on wireless, and its ability to handle both >> wired and wireless links. >> >> Robustness in the face of unintentional joining of networks. >> - Jim > > Nice list. Thanks. > > Curtis 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 lee.howard@twcable.com Mon Oct 24 06:59:02 2011 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 EBF5C21F8D8D for ; Mon, 24 Oct 2011 06:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1iaNAmpsqV0 for ; Mon, 24 Oct 2011 06:59:02 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FF21F8D84 for ; Mon, 24 Oct 2011 06:59:02 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,397,1315195200"; d="scan'208";a="273726931" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Oct 2011 09:55:05 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 24 Oct 2011 09:58:52 -0400 From: "Howard, Lee" To: "curtis@occnc.com" Date: Mon, 24 Oct 2011 09:58:41 -0400 Thread-Topic: [homenet] routing requirements Thread-Index: AcyQaJviOt0UCfmQReOvGnS3Ui4RygB7Bb+g Message-ID: References: Your message of "Fri, 21 Oct 2011 17:26:14 EDT." <201110220313.p9M3Dc4N043180@gateway.ipv6.occnc.com> In-Reply-To: <201110220313.p9M3Dc4N043180@gateway.ipv6.occnc.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: Samita Chakrabarti , "homenet@ietf.org" Subject: Re: [homenet] routing requirements 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, 24 Oct 2011 13:59:03 -0000 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Friday, October 21, 2011 11:14 PM > To: Howard, Lee > Cc: Samita Chakrabarti; homenet@ietf.org > Subject: Re: [homenet] routing requirements > > > In message > le.com> > "Howard, Lee" writes: > > > Can you describe some scenarios which would cause a prefix to change, > > in which applications break in ways that are unacceptable? All of the > > ones I can think of would be cases where I would expect a session to > > drop, but I'm sure that's a lack of creativity on my part. > > > > Lee > > > Most IPv4 hosts can't tolerate their IP address going away. For IPv6 > its slightly easier because they can add a new address in a new > prefix. Only think is the host need to ask for an address and today > if its lease has not expired it won't ask. Some older DHCP code won't > take a change in address or default route when the lease expires. The case we were talking about, I think, was a link or device failure. One expects an outage in those cases. > One thing that would break is any open TCP connections. The open > connections use the already selected address. This has been a problem > for mobility for quite a while but those heavier solution can't be > applied to this problem. TCP is not expected to be resilient to outages. We're not building a carrier network, we're building a home network. Bounce the connection. > > Concievably a TCP extension could support alternate source addresses > (such as SCTP does). Until then, a TCP connection can't change > addresses. > > If you switch from one provider uplink to another, you should be able > to keep talking to your content provider. Currently you can't. For > web users, hit the stop and the reload. Web, p2p, gaming, VPN. . . I'm okay with the session dropping in case of failure. 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 curtis@occnc.com Mon Oct 24 09:58:28 2011 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 9FE4011E808B for ; Mon, 24 Oct 2011 09:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH1Llr-bo0IU for ; Mon, 24 Oct 2011 09:58:25 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFA121F86EC for ; Mon, 24 Oct 2011 09:58:24 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9OGwDU9060420; Mon, 24 Oct 2011 09:58:13 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9OGwDU9060420 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319475494; bh=9tGMeAYLpBWpOcBBMz4EB1NE244wJz+ACDJI4aJH1+o=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=QEFvmVaPLgauTIw8gvVQDjMoHfJZVqhjgIJYZqtgKezwKNMYOKGpBf0b7dIAWAXb+ 07XDRKyMwgpS58l3JjhdjHbxBKNmEDZclLJIXPoPhkTMojkgoDPEckkztp0Se/VH24 wO2U/v6DV98HqfOGgaGKJOxE0CpGtrT12EN0ui1E= Message-Id: <201110241658.p9OGwDU9060420@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Oct 2011 09:28:15 EDT." <1DD9DEAE-0F85-41A1-B4C9-C8C09BC84D45@twcable.com> Date: Mon, 24 Oct 2011 09:58:13 -0700 Cc: "homenet@ietf.org" , Don Sturek , Jim Gettys , "curtis@occnc.com" Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:58:28 -0000 Trimmed, leaving only responses to the points Lee brought up. In message <1DD9DEAE-0F85-41A1-B4C9-C8C09BC84D45@twcable.com> "Howard, Lee" writes: > > > This almost covers one of Jim's points. Jim added unitentional join. > > > >>> a. Convergence time a few minutes or less. > > > > Seconds at least. Goal for providers is 60 msec, but subsecond would > > be a reasonable goal for wired. > > > > Why would we need that level of repair? This is a home network, not a > carrier network. On wired it is easy to get subsecond in a small topology. It would be nice if you streaming audio, movie, phone call to support, etc, stayed up when a minor change was made as long as connectivity still existed. > >>> 7. Best-path is a non-requirement. > > > > It should be a goal but not a hard requirement. > > Why? Having your HD video stream avoid the 10baseT hub that you have never bothered to through out would be a good thing. It could also be said that today the slowest thing out there is 10/100, but why not take a GbE path if one is available. Any why not take one 10/100 hop instead of two? Its a worthy goal since some application will eventually want the bandwidth, even if temporarily. With wireless, best path might be more important, but it seems to be a more ellusive goal. At least some people are arguing against it. > >>> 8. Support for multiple upstream networks is a requirement. > >>> > >>> a. Including wireless offload, video-only, and split-tunnel > >>> VPN scenarios. > >>> > >>> b. With separate routers to each. Not multihomed off the same > >>> router. > >>> > >>> c. Prefix delegated from all ISPs (upstreams). > > > > This will be hard and may require detection of hosts with new > > capabilities and a (less functional) fallback strategy for others. > > Yes. Maybe this should be an assumption, not a requirement, and > the resolution of issues around it is dependent on how we do > address assignment. The trouble here is that there's no way for > two ISPs two coordinate prefix assignment, so they will both reply > with IA_PD, and two routers will try to use those prefixes. We need to assume that sometimes there will be cluefull and cooperative service providers upstream, and sometimes there won't be. Today some configuration is required on almost any provider uplink. In the case where the provider installs and completely controls the CPE, and the demarc is the ethernet the other end may just act as a DHCPv4 server and won't do anything else. Then it is hard to identify this as an uplink as there are all sorts of consumer products today that do DHCPv4 and claim to have a default route even though there is nothing connected on the uplink side. If the provider does respond to an IA_PD with a glocally routable prefix of length /64 (or less specific), then it can be assumed to be an uplink. It may also be doing IPv4 NAT and hand out private address space typically in 192/24 or 10/8. > >>> d. ISP A is default. > >>> > >>> e. With only traffic destined to ISP B's prefix using that link. > >>> > >>> f. With a backup default to ISP B, if desired. What is > >>> default condition? > > > > With no designated A or B, closest is the default, with hysteresis. A > > tie breaker rule would be less desireable. > > What does "closest" mean? Longest match? Closest means what closest has always meant: least cost, ie: best path. Least cost is a function of how the routing protocol deals with metrics. This is intended as a deterministic and unambiguous tie breaker. > >>> 9. Cannot assume hierarchical prefix delegation in the home > >>> (at least, not unless the WG develops such a solution). > > > > Here I disagree. Must assume hierarchical prefix delegation. > > > > ULAs are not globally routeable. ND proxy will fail Jim's scalability > > test in an instant. > > I would prefer a hierarchical solution. I have not been able to finish > writing up my proposed solution, but it's pretty much "wait to see if > anyone else needs a prefix from you, then request all the prefixes you > need." > > Here again, what assumptions we take for routing depend on what we > do for address assignment. Until then, I think we should not assume > hierarchical delegation. Off topic a bit (your proposed solution). If everything powers up and waits for someone else to ask for addresses, then only the hosts ask. The routers then ask each other in random order and those that are not direct uplinks have no basis for a response. If everything asks first, then the uplinks will be the only ones to respond quickly. The responses will progress from the uplinks along the topology until all parts of the topology have one or more prefixes suballocated from the prefix that was provided to the uplink(s). In the absense of legacy devices, all but the closest age out if they were assigned before the closest. In the cast where there is no uplink, after a brief timeout ULAs start being assigned for the purpose of bringing internal routing up and having internal connectivity. Again if an uplink becomes available, then in the absence of legacy hosts or routers, the ULAs can age out. > >>> 10. A host with mutliple upstream paths to the same destination > >>> should be able to use another in case on fails. > > > > The problem is really which address to use in this case. RFC 3484 > > does not solve this unless the prefix for the now down uplink is > > removed. Adding a rule to bias the selection toward the prefix from > > which the default route is learned would be an update to RFC 3484. > > Deprecating the prefix would help, yes. For in-home destinations, > any prefix should work. Consider the case where two uplinks come up and each provides a different /64. Using an address provided by the closest uplink yields symetric routing with respect to the set of uplinks. If one of the uplinks goes down, then the prefix it provided may not be routable through the other uplink (another provider may route toward a less specific prefix if the more specific for your house is not globally announced. It is very unlikely that your /64 will be globally announced for the purpose of your home network multihoming. The uplink router needs to *try* to withdraw the prefix. For the benefit of the legacy devices that continue to use the no longer working prefix, the other uplink must NAT (IPv6 to IPv6). The newer hosts and routers will stop using the no longer working prefix and switch to the working prefix. Connections that were up using the old prefix will go down (equiv of network unreachable, except more authoritative). > >>> 12. Prefix stability? > > > > For legacy hosts. Detect hosts which don't need it. > > > I don't understand this requirement, I just captured it from discussion. > Why is it required? Legacy hosts need prefix stability. You have to know which hosts don't need to be assigned a stable address. If all of the hosts are capable of promptly giving up the address they were assigned, then there is no need to keep a prefix that is no longer routeable due to an uplink going down. > >>> 13. Lightweight (cheap) implementation. > >>> > >>> Let me know if I've missed, or mistated, anything. > > > >> In message <4EA1DAFF.6080500@freedesktop.org> > >> Jim Gettys writes: > >> > >> A couple missed: reference the scars on my back I discussed earlier: > >> > >> Scalability analysis, both for the dense mesh case, and the non-dense > >> case, > >> > >> Behaviour/scaling when run on wireless, and its ability to handle both > >> wired and wireless links. > >> > >> Robustness in the face of unintentional joining of networks. > >> - Jim > > > > Nice list. Thanks. > > > > Curtis > > > Lee Curtis From curtis@occnc.com Mon Oct 24 10:19:04 2011 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 D640711E8082 for ; Mon, 24 Oct 2011 10:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pay83GqGryhB for ; Mon, 24 Oct 2011 10:19:04 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2621F8D14 for ; Mon, 24 Oct 2011 10:19:03 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9OHIud5060865; Mon, 24 Oct 2011 10:18:57 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9OHIud5060865 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319476737; bh=v6fHJROFcFLkrY/CesbXDH2WwMHEh/XRRh82TwCPvDA=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=h5JFUQ+TKD2okSH2TEFhFHQds0xeq1wVr4WIQQzfeIWdTasdGIMUyCOQTq+WKiVDR glRFtVy2nMzCJNoM43m+L5/upUwMJwcxUi3oiP76A2DVVuPkUSpnbiZNdpMUiQqcXV EThzKbaQ5Y4uIIuNDSQl68LElnczhVS2+2CM4SiI= Message-Id: <201110241718.p9OHIud5060865@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Oct 2011 09:58:41 EDT." Date: Mon, 24 Oct 2011 10:18:56 -0700 Cc: Samita Chakrabarti , "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:19:05 -0000 In message "Howard, Lee" writes: > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Friday, October 21, 2011 11:14 PM > > To: Howard, Lee > > Cc: Samita Chakrabarti; homenet@ietf.org > > Subject: Re: [homenet] routing requirements > > > > > > In message > > > le.com> > > "Howard, Lee" writes: > > > > > Can you describe some scenarios which would cause a prefix to change, > > > in which applications break in ways that are unacceptable? All of the > > > ones I can think of would be cases where I would expect a session to > > > drop, but I'm sure that's a lack of creativity on my part. > > > > > > Lee > > > > > > Most IPv4 hosts can't tolerate their IP address going away. For IPv6 > > its slightly easier because they can add a new address in a new > > prefix. Only think is the host need to ask for an address and today > > if its lease has not expired it won't ask. Some older DHCP code won't > > take a change in address or default route when the lease expires. > > The case we were talking about, I think, was a link or device failure. > One expects an outage in those cases. If you have two uplinks, you shouldn't need to reboot everything your house to get connectivity back up because hosts and routers are using a prefix that is no longer globally routable. > > One thing that would break is any open TCP connections. The open > > connections use the already selected address. This has been a problem > > for mobility for quite a while but those heavier solution can't be > > applied to this problem. > > TCP is not expected to be resilient to outages. We're not building a > carrier network, we're building a home network. Bounce the > connection. No one is suggesting we try to avoid dropping an open TCP connection on a down transition from the uplink that provided the address the host is using. > > Concievably a TCP extension could support alternate source addresses > > (such as SCTP does). Until then, a TCP connection can't change > > addresses. > > > > If you switch from one provider uplink to another, you should be able > > to keep talking to your content provider. Currently you can't. For > > web users, hit the stop and the reload. > > Web, p2p, gaming, VPN. . . I'm okay with the session dropping in case > of failure. Yes. This is not a TCP ng WG so we don't try to fix TCP here. There are cases like two uplinks to the same provider (same /64 prefix) that would work without any effort. This would be rare in the home though not unthinkable in a home or small business and not uncommon in medium and large businesses. We should make it possible for multihoming scenarios such as this to work, preferably with no configuration, except at the provider. For example, an extension to IA_PD essentially saying "use X/65 which came from X/64 and has no firewall enabled yet" would allow the provider to do all the configuration needed to make this workable with zero config on the customer side. > Lee Curtis From curtis@occnc.com Mon Oct 24 10:38:22 2011 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 1234321F8672 for ; Mon, 24 Oct 2011 10:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDNwh34aVWCm for ; Mon, 24 Oct 2011 10:38:21 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 15AF421F86A4 for ; Mon, 24 Oct 2011 10:38:20 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9OHcFld061302; Mon, 24 Oct 2011 10:38:15 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9OHcFld061302 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319477895; bh=DToikhD1uI2we+S5YDq7ymYJSaZCsYL0EKHuycrUNBQ=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=MTAaqU4cDfKTZtN/xBuQOHUENMJ6LczLsYoIqw64W7Uc+Utp7vW2i2eKAcAhlS4NQ 6nNKaTLl/W2YsYfyZRBGDFT4WNi0JoPSo4N9IJyOckf18HAfZ4fVYaZj3ZyV9OVNqj Ttst2mbb4S6EFWTs5J+sZ9lrqVQ6jfDEwrKeZjuU= Message-Id: <201110241738.p9OHcFld061302@gateway.ipv6.occnc.com> To: Cameron Byrne From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Oct 2011 06:27:15 PDT." Date: Mon, 24 Oct 2011 10:38:15 -0700 Cc: Ray Bellis , "homenet@ietf.org" , "Hemant Singh \(shemant\)" Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:38:22 -0000 In message Cameron Byrne writes: > On Oct 24, 2011 1:24 AM, "Ray Bellis" wrote: > > > > > > On 22 Oct 2011, at 01:18, Hemant Singh (shemant) wrote: > > > >> Note the IETF IPv6 CE router specifies use of the ULA in the home > >> to keep the home network independent of the SP network. This way > >> my computer at home can still print to the printer even when my SP > >> IPv6 network is down. We have said this multiple time in v6ops > >> during development of the IPv6 CE router RFC 6204. > > > > > > Thanks for the reminder. FWIW, I believe the consensus _is_ for > > ULAs within the home network, although I do see a few vocal > > opponents. > > > >> I don=92t have the time to read the copious emails of homenet, but > >> seeing some emails here and there I see homenet regressing on > >> issues that are closed in the v6ops IPv6 CE router document > >> development. Examples of issues homenet is regressing on is ND > >> Proxy and use of zospf for prefix delegation in the LAN. There > >> was only one cell phone vendor who was asking us for ND Proxy with > >> a single /64 PD delegated to the phone. We convinced the vendor > >> at the Prague IETF to abandon that idea because such a /64 would need > >> RA Proxy in the CE router and RA Proxy is not defined is any RFC. > >> Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. > >> That is why ND Proxy was removed from the cpe rtr bis document. > > > > > > Will those arguing for ND Proxy please stand up and be counted? > > > I am not arguing for ND proxy, just saying the mobile device may use > it to extend their connectivity into the house. So I am not saying the > home route= r will do nd proxy, unless you consider the mobile > attached device to be the home router itself. > > There is no standcardized support for dhcp-pd in 3gpp yet, it is in > the pipe, and deployment will vary. Nd proxy is not a bad solution > here. > > In the case of 3gpp mobile device, nd proxy is only extending the > users's attached /64 p2p link onto a LAN, it is not sharing with other > customers or provider infrastructure. > > Cb The homenet work will have to interoperate with whatever 3GPP has defined, but does not have to recommend any further use of ND proxy. The work in homenet might (or might not) affect what 3GPP does in the future if there is compelling reason to do things differently. > >> Zospf was also closed in v6ops that it=92s not possible to use for > >> prefix delegation in the LAN. Here is an email to v6ops on > >> closure on ospf for prefix delegation. > > > > Again, thanks, that's useful background. > > > > Ray I don't think there have been any arguments in favor of using OSPF or ZOSPF as the address assignment protocol. There have been arguments (from me at least) to allow that the assignment protocol take hints from whatever routing protocol is in place as to which prefixes were originated from closer uplinks. This allows the use of a prefered uplink (ie: wired provider preferred over wireless provider) or a closest path out to equally preferred providers. There are also arguments for OSPF as a routing protocol, with extensions where needed, such as better automated router ID selection. There are also arguments for as useful a result as possible with zero configuration as a goal for whatever protocols or usage is defined in homenet, independent of whether OSPF is in any way involved. The death of zospf as an address assignment protocol in v6ops does not negate these points. Curtis From jhw@apple.com Mon Oct 24 11:33:54 2011 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 456041F0C4F for ; Mon, 24 Oct 2011 11:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z3bHHR1Gr83 for ; Mon, 24 Oct 2011 11:33:53 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id B88F91F0C3F for ; Mon, 24 Oct 2011 11:33:53 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bTg1mjGW2lau4TS521vRRw)" Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LTL00H6A26T8FN1@mail-out.apple.com> for homenet@ietf.org; Mon, 24 Oct 2011 11:33:21 -0700 (PDT) X-AuditID: 11807134-b7cc1ae0000078f0-07-4ea5af700f22 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 00.75.30960.07FA5AE4; Mon, 24 Oct 2011 11:33:20 -0700 (PDT) From: james woodyatt In-reply-to: <5E233369-AB87-4E4D-88E9-1CC8FB8FC691@nominet.org.uk> Date: Mon, 24 Oct 2011 11:33:26 -0700 Message-id: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5E233369-AB87-4E4D-88E9-1CC8FB8FC691@nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUieJDvpm7B+qV+Bl8nmFm8X3SIxeJT13NW ByaPJUt+MnmcmDuPKYApissmJTUnsyy1SN8ugSvj5q5LbAWrVCouP3/J3sD4RL6LkZNDQsBE 4vOdW6wQtpjEhXvr2boYuTiEBFYwSZy4+J4FJCEsoC3R838JG4jNK2AssebWO7A4s0CCRGff Q3YQm01AReLb5btMIDangJPE5hnrmUFsFgFViZYFu5gh6vUlevc8hJpjI/Fy0k52iGUPmCSW NW8HGyQioCWxdf8HZoiL5CVavt5hm8DINwvJ7llIdkPY2hLLFr5mhrANJJ52vmLFFNeXePNu DtMCRrZVjIJFqTmJlYYmeokFBTmpesn5uZsYQYHaUGiyg/HgT/5DjAIcjEo8vJeWLvETYk0s K67MPcQowcGsJMI7z3qpnxBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe1QaL/YQE0hNLUrNTUwtS i2CyTBycUg2MK44fETXlCvm9kuFXvV1wRf8hDc3DH3zSPm968OPb/rDSnh/9gm4675h+7/nZ Zy479edLjZCYE9P88zazFi+dxvi3YY7qsayEjiarUwdvfPqyXj9L9rbChhv3b6z3u3qXY0YI y2vGHzf5w5fKSUaaWX6vMdEKn8a5onSDV/P5xO4lXv4exgZnlViKMxINtZiLihMB9avmeFAC AAA= Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements 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, 24 Oct 2011 18:33:54 -0000 --Boundary_(ID_bTg1mjGW2lau4TS521vRRw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Oct 24, 2011, at 1:24 AM, Ray Bellis wrote: > > Will those arguing for ND Proxy please stand up and be counted? I have long complained that certain WPAN physical layers should be prepared to attach to home networks, either by application layer gateways on bastion hosts, or by dedicated ND/RD proxy devices, rather than by demanding that every residential network deploy a standard zero configuration prefix delegation and routing protocol to interface to these peculiar WPAN networks. I know I'm in the minority on this. I don't think I can point to anyone who agrees with me. Still, I should be counted. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_bTg1mjGW2lau4TS521vRRw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
                    Will = those arguing for ND Proxy please stand up and be = counted?

                    I have long complained = that certain WPAN physical layers should be prepared to attach to home = networks, either by application layer gateways on bastion hosts, or by = dedicated ND/RD proxy devices, rather than by demanding that every = residential network deploy a standard zero configuration prefix = delegation and routing protocol to interface to these peculiar WPAN = networks.

                    I know I'm in the minority on this.  I = don't think I can point to anyone who agrees with me.  Still, I = should be counted.


                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_bTg1mjGW2lau4TS521vRRw)-- From therbst@silverspringnet.com Mon Oct 24 11:46:06 2011 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 BD55911E80B7 for ; Mon, 24 Oct 2011 11:46:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhOh8UHDUgf0 for ; Mon, 24 Oct 2011 11:46:06 -0700 (PDT) Received: from it-ipdr-01.silverspringnet.com (it-ipdr-01.silverspringnet.com [74.121.22.27]) by ietfa.amsl.com (Postfix) with ESMTP id CD9C521F8AFA for ; Mon, 24 Oct 2011 11:46:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAB+xpU4KyAE+/2dsb2JhbABDqheBbgEGOj8SAQgNBAMBAh9CHQgBAQQBDQW7bIhABIgGkU6MMA X-IronPort-AV: E=Sophos;i="4.69,399,1315206000"; d="scan'208";a="1048307" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipdr-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 24 Oct 2011 11:46:02 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Mon, 24 Oct 2011 11:46:02 -0700 From: Thomas Herbst To: james woodyatt , Ray Bellis Date: Mon, 24 Oct 2011 11:45:59 -0700 Thread-Topic: [homenet] routing requirements Thread-Index: AcySfS2McVPjhoNhR4OrykiPCeg5OA== 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.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Thomas Herbst Subject: Re: [homenet] routing requirements 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, 24 Oct 2011 18:46:06 -0000 In my v6 ops presentation in Beijing, Dave Thaler agreed with you (James). I'm on the other side of the argument. tom From: james woodyatt Date: Mon, 24 Oct 2011 11:33:26 -0700 To: Ray Bellis Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements On Oct 24, 2011, at 1:24 AM, Ray Bellis wrote: Will those arguing for ND Proxy please stand up and be counted? I have long complained that certain WPAN physical layers should be prepared to attach to home networks, either by application layer gateways on bastion hosts, or by dedicated ND/RD proxy devices, rather than by demanding that every residential network deploy a standard zero configuration prefix delegation and routing protocol to interface to these peculiar WPAN networks. I know I'm in the minority on this. I don't think I can point to anyone who agrees with me. Still, I should be counted. -- james woodyatt member of technical staff, core os networking From curtis@occnc.com Mon Oct 24 12:38:57 2011 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 6592E11E80FE for ; Mon, 24 Oct 2011 12:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NA7g5ygG9AC for ; Mon, 24 Oct 2011 12:38:56 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 866BA11E80FD for ; Mon, 24 Oct 2011 12:38:56 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p9OJcpms064576; Mon, 24 Oct 2011 12:38:51 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p9OJcpms064576 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1319485132; bh=ye6Yf2JJgl9yL7fcSmbEC72pxq/2huXHUyF3jKzOrwA=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=o/iAeUpa749i4jthIreB4XDErDk65/6naBR30z3FkPniOi4TzuHuqTai/9FVvJNjY wDUvCXmnDqqJENYIoj4D2eQb9XiYNlN97slOpaMvgPbvpnzyMVbx6gzN9QfSZl9sWM 6ewkEllJSu7ow65yxkpRONIQ65mWeursqzzf+h/I= Message-Id: <201110241938.p9OJcpms064576@gateway.ipv6.occnc.com> To: james woodyatt From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Oct 2011 11:33:26 PDT." Date: Mon, 24 Oct 2011 12:38:51 -0700 Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 19:38:57 -0000 In message james woodyatt writes: > > On Oct 24, 2011, at 1:24 AM, Ray Bellis wrote: > > > > Will those arguing for ND Proxy please stand up and be counted? > > I have long complained that certain WPAN physical layers should be > prepared to attach to home networks, either by application layer > gateways on bastion hosts, or by dedicated ND/RD proxy devices, rather > than by demanding that every residential network deploy a standard > zero configuration prefix delegation and routing protocol to interface > to these peculiar WPAN networks. > > I know I'm in the minority on this. I don't think I can point to > anyone who agrees with me. Still, I should be counted. > > -- > james woodyatt > member of technical staff, core os networking I'm not sure what you are advocating. (Except having read ahead I know whatever it is Dave Thaler agrees with you). It seems to me like you are advocating treatment of WPAN as a special case stub with very limited capability appropriate only for a stub. Is it possible for a WPAN-only connected device to have more than one reachable device which could provide connectivity to a wired (or WiFi wireless) network and eventual connectivity to a controlling host? Is it also possible that a mesh of WPAN devices could exist? If so, then WPAN is no longer a special case stub, it is mearly a low power device with limited radio coverage and/or limited bandwidth. For example, a potential application of WPAN is home security. With routing each window or door or motion sensor need not be within reach of the control unit, just within reach of another window or door or sensor. This would be a mesh application in the home. The bluetooth limitation where the headset has to be near the phone or computer need not constrain what WPAN is used for in the future. The effective range can be extended as long as the device is near *something* that does WPAN and the something has other connectivity or is part of a mesh that has other connectivity. I did mention that devices need to be "bonded" to each other somehow. These WPAN applications are a case where this is important. The more the range of the WPAN is extended, the more you wouldn't want it to be too easy to spoof the home alarm system or have anything connect to a given phone or headset. Of course, limited range is no excuse for the situation with bluetooth headsets in airports where everything bonds with everything else because they all use a manufacturer's default. Curtis From lorenzo@google.com Mon Oct 24 21:26:28 2011 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 9B15511E80BC for ; Mon, 24 Oct 2011 21:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqHC5bdhMTez for ; Mon, 24 Oct 2011 21:26:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E6AC311E8097 for ; Mon, 24 Oct 2011 21:26:27 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p9P4QRmJ018181 for ; Mon, 24 Oct 2011 21:26:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319516787; bh=ot63vtjwb7B6c9VzwSutDDZAOsA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=YRkNdlOxj/sVR9Ze1DG3GC9A645ZgHvZgvXVY9PSUHP5DIF9tvLTLHyMEpa6XFxTs iGDcrl2ZiFNOC7DCA6yng== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=NwVjJivOGN9sSfUTlhiS4SxGIOjXakygvPfdKpbwTNk03YuIKBJ1jfkocHsxYWCL3 i/8ZTPUJRUJMv6E6ObHXw== Received: from vcbfk14 (vcbfk14.prod.google.com [10.220.204.14]) by wpaz9.hot.corp.google.com with ESMTP id p9P4PDah010030 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2011 21:26:26 -0700 Received: by vcbfk14 with SMTP id fk14so135144vcb.2 for ; Mon, 24 Oct 2011 21:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=PBiyUldqDwzAkFOQJ75Yi68qsgnvA8GCXJeDg8YysyE=; b=x5tOAw4dcGKw8Xs6s/UZnfz4USKT4hnBD439+mFCRZDRkGKvAj4tiGHD5E08jGQmtt uMMTQmGYCgK1tQ8AGXyg== Received: by 10.151.15.4 with SMTP id s4mr3618806ybi.30.1319516786322; Mon, 24 Oct 2011 21:26:26 -0700 (PDT) Received: by 10.151.15.4 with SMTP id s4mr3618799ybi.30.1319516786162; Mon, 24 Oct 2011 21:26:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 24 Oct 2011 21:26:06 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Mon, 24 Oct 2011 21:26:06 -0700 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=000e0cd6e82a507e2d04b017f166 X-System-Of-Record: true Cc: "Howard, Lee" , Samita Chakrabarti , homenet@ietf.org Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 04:26:28 -0000 --000e0cd6e82a507e2d04b017f166 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2011 at 17:18, Hemant Singh (shemant) wr= ote: > I don=92t have the time to read the copious emails of homenet, but seeing > some emails here and there I see homenet regressing on issues that are > closed in the v6ops IPv6 CE router document development. > If you haven't read the homenet email conversations, how do you know that these are regressions? Zospf was also closed in v6ops that it=92s not possible to use for prefix > delegation in the LAN. Here is an email to v6ops on closure on ospf for > prefix delegation. > That email says, basically, "it can't be done" without saying why. We had a lot of discussion during the interim meeting and we think it can be done using a routing protocol. Please at least go and read the strawman I posted to the list. Prefix delegation has problems with non-trivial topologies or with multihoming. --000e0cd6e82a507e2d04b017f166 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
                    On Fri, Oct 21, 2011 at 17:18, Hemant Singh (she= mant) <shemant@cisco.com> wrote:

                    I don=92t have the time to read the copio= us emails of homenet, but seeing some emails here and there I see homenet r= egressing on issues that are closed in the v6ops IPv6 CE router document de= velopment.=A0


                    If you haven't read the ho= menet email conversations, how do you know that these are regressions?

                    Zospf was also closed in v6ops t= hat it=92s not possible to use for prefix delegation in the LAN. =A0=A0Here= is an email to v6ops on closure on ospf for prefix delegation.=A0


                    That email says, basically, &q= uot;it can't be done" without saying why. We had a lot of discussi= on during the interim meeting and we think it can be done using a routing p= rotocol. Please at least go and read the strawman I posted to the list.

                    Prefix delegation has problems with non-trivial topolog= ies or with multihoming.
                    --000e0cd6e82a507e2d04b017f166-- From shemant@cisco.com Mon Oct 24 22:12:31 2011 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 C5B4921F8BFE for ; Mon, 24 Oct 2011 22:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ1MWijyelb6 for ; Mon, 24 Oct 2011 22:12:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AA97B21F8BF9 for ; Mon, 24 Oct 2011 22:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8300; q=dns/txt; s=iport; t=1319519544; x=1320729144; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=HDQ7tYUttVlSnQbHxeNAtMOLNozV/Qcwuc7xZRZ204s=; b=WqlLaHc7l+6m84yqOHWnSMU2KxGrJzEnkmppaECIelsxSXw7WSF7ic+t wM4rt1lHyBxsS7UiVAKeLXQhJjscshFGJuZkyZeSfXjXhOjwJtK+R3fVT 3iymdaH5y67pTodjUAEeI7+I1a+JDYQyTONOebgx3z78WQMBV0C3GVl5n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAM9Epk6tJXG9/2dsb2JhbABDgk2XCI9CgQWBbgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqdZgGeT4diYQSIBpE4jEY X-IronPort-AV: E=Sophos;i="4.69,402,1315180800"; d="scan'208,217";a="30723582" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2011 05:12:24 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9P5COtt016406; Tue, 25 Oct 2011 05:12:24 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 00:12:23 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC92D4.AE04277E" Date: Tue, 25 Oct 2011 00:12:22 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcySzkQePFKw++M5R96gfmdAucX9iwAAZ8QQ References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" X-OriginalArrivalTime: 25 Oct 2011 05:12:23.0906 (UTC) FILETIME=[AE219420:01CC92D4] Cc: "Howard, Lee" , Samita Chakrabarti , homenet@ietf.org Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 05:12:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92D4.AE04277E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Tuesday, October 25, 2011 12:26 AM To: Hemant Singh (shemant) Cc: Howard, Lee; Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements =20 =20 >If you haven't read the homenet email conversations, how do you know that these are regressions? =20 Some regressions are fairly clear from just glancing at the subject of emails in homenet. The example is ND Proxy and glancing at emails such as "cell phone operators may use a single /64" and hence the need for ND Proxy. This is precisely what we discussed in v6ops and closed in v6ops. =20 >That email says, basically, "it can't be done" without saying why. We had a lot of discussion during the interim meeting and we think it can be done using a routing protocol. Please at least go and >read the strawman I posted to the list. =20 Cmon, now. I included clear text showing why it can't be done to v6ops. My v6ops is open to anyone in v6ops and homenet to reply specifically as to how one will get around the problems I raised with using any ospf or routing protocol for prefix delegation. =20 =20 >Prefix delegation has problems with non-trivial topologies or with multihoming. =20 Preaching to the choir. That is why we punted prefix delegation out of the IPv6 CE router v6ops document. But using a routing protocol to figure out prefix delegation for the problems you describe above remains to be seen. =20 Thanks, =20 Hemant =20 =20 ------_=_NextPart_001_01CC92D4.AE04277E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                     

                     

                     

                    >If you = haven't read the homenet email conversations, how do you know that these = are regressions?

                     

                    Some regressions are fairly clear from just glancing at the subject = of emails in homenet.  The example is ND Proxy and glancing at = emails such as “cell phone operators may use a single /64” = and hence the need for ND Proxy.  This is precisely what we = discussed in v6ops and closed in = v6ops.

                     

                    >That email = says, basically, "it can't be done" without saying why. We had = a lot of discussion during the interim meeting and we think it can be = done using a routing protocol. Please at least go and >read the strawman I posted to the = list.

                     

                    Cmon, now.  I included clear text showing why it can’t be = done to v6ops.   My v6ops is open to anyone in v6ops and = homenet to reply specifically as to how one will get around the problems = I raised with using any ospf or routing protocol for prefix = delegation. 

                     

                    >Prefix delegation has problems with = non-trivial topologies or with multihoming.

                     

                    Preaching to the choir.  That is why we punted prefix delegation = out of the IPv6 CE router v6ops document.  But using a routing = protocol to figure out prefix delegation for the problems  you = describe above remains to be seen.

                     

                    Thanks,

                     

                    Hemant

                     

                     

                    ------_=_NextPart_001_01CC92D4.AE04277E-- From shemant@cisco.com Mon Oct 24 22:15:04 2011 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 9666321F8C08 for ; Mon, 24 Oct 2011 22:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrDKedhNlDq3 for ; Mon, 24 Oct 2011 22:15:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7B721F8C0A for ; Mon, 24 Oct 2011 22:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10380; q=dns/txt; s=iport; t=1319519701; x=1320729301; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=L0vv5lNuonIGYFBSL8ecoMGtt7ckGchiqC03i8bo4Jw=; b=m8pVKMfMXvZgTihu51U95ALFxqZAIPYcz8P/ZF9xqwFw2XK6iTZjnZg6 UAbCuUSqQgnnBHBsaVGB6YjOj7UOPiaNQmSoNhnMfy2fSAM0Z29LF1+VL DOvL3X/JxlYyFKb0JyPPtlIjx8fshQDZjozEsDQQHc28c8z/jopbz4uW9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAH9Fpk6tJV2a/2dsb2JhbABDgk2XCI9CgQWBbgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQBEgganWgBnk+HYmEEiAaROIxG X-IronPort-AV: E=Sophos;i="4.69,402,1315180800"; d="scan'208,217";a="30714527" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 25 Oct 2011 05:15:01 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9P5F0TK000392; Tue, 25 Oct 2011 05:15:01 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 00:15:00 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC92D5.0B6B9CD7" Date: Tue, 25 Oct 2011 00:14:59 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6E@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcySzkQePFKw++M5R96gfmdAucX9iwAAZ8QQAAE/fwA= References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Lorenzo Colitti" X-OriginalArrivalTime: 25 Oct 2011 05:15:00.0750 (UTC) FILETIME=[0B9E12E0:01CC92D5] Cc: "Howard, Lee" , Samita Chakrabarti , homenet@ietf.org Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 05:15:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92D5.0B6B9CD7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry typo. In my email below, please change =20 "My v6ops" to "My v6ops email" =20 Hemant =20 From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, October 25, 2011 1:12 AM To: Lorenzo Colitti Cc: Howard, Lee; Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements =20 =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Tuesday, October 25, 2011 12:26 AM To: Hemant Singh (shemant) Cc: Howard, Lee; Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements =20 =20 >If you haven't read the homenet email conversations, how do you know that these are regressions? =20 Some regressions are fairly clear from just glancing at the subject of emails in homenet. The example is ND Proxy and glancing at emails such as "cell phone operators may use a single /64" and hence the need for ND Proxy. This is precisely what we discussed in v6ops and closed in v6ops. =20 >That email says, basically, "it can't be done" without saying why. We had a lot of discussion during the interim meeting and we think it can be done using a routing protocol. Please at least go and >read the strawman I posted to the list. =20 Cmon, now. I included clear text showing why it can't be done to v6ops. My v6ops is open to anyone in v6ops and homenet to reply specifically as to how one will get around the problems I raised with using any ospf or routing protocol for prefix delegation. =20 =20 >Prefix delegation has problems with non-trivial topologies or with multihoming. =20 Preaching to the choir. That is why we punted prefix delegation out of the IPv6 CE router v6ops document. But using a routing protocol to figure out prefix delegation for the problems you describe above remains to be seen. =20 Thanks, =20 Hemant =20 =20 ------_=_NextPart_001_01CC92D5.0B6B9CD7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                    Sorry typo.  In my email below, please = change

                     

                    “My v6ops” to “My v6ops = email”

                     

                    Hemant

                     

                    From:= = homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant)
                    Sent: Tuesday, October 25, 2011 = 1:12 AM
                    To: Lorenzo Colitti
                    Cc: Howard, Lee; Samita = Chakrabarti; homenet@ietf.org
                    Subject: Re: [homenet] routing = requirements

                     

                     

                     

                     

                    >If you = haven't read the homenet email conversations, how do you know that these = are regressions?

                     

                    Some regressions are fairly clear from just glancing at the subject = of emails in homenet.  The example is ND Proxy and glancing at = emails such as “cell phone operators may use a single /64” = and hence the need for ND Proxy.  This is precisely what we = discussed in v6ops and closed in = v6ops.

                     

                    >That email = says, basically, "it can't be done" without saying why. We had = a lot of discussion during the interim meeting and we think it can be = done using a routing protocol. Please at least go and >read the strawman I posted to the = list.

                     

                    Cmon, now.  I included clear text showing why it can’t be = done to v6ops.   My v6ops is open to anyone in v6ops and = homenet to reply specifically as to how one will get around the problems = I raised with using any ospf or routing protocol for prefix = delegation. 

                     

                    >Prefix delegation has problems with = non-trivial topologies or with multihoming.

                     

                    Preaching to the choir.  That is why we punted prefix delegation = out of the IPv6 CE router v6ops document.  But using a routing = protocol to figure out prefix delegation for the problems  you = describe above remains to be seen.

                     

                    Thanks,

                     

                    Hemant

                     

                     

                    ------_=_NextPart_001_01CC92D5.0B6B9CD7-- From lorenzo@google.com Mon Oct 24 22:22:29 2011 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 ED5E021F8C56 for ; Mon, 24 Oct 2011 22:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsvH09RvAaBo for ; Mon, 24 Oct 2011 22:22:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E91D121F8C55 for ; Mon, 24 Oct 2011 22:22:28 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p9P5MQYb015412 for ; Mon, 24 Oct 2011 22:22:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319520146; bh=MJHxoSvd4W/XX5ToV/R+TT4tRBM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Jzcvgsf4f0XrC27yN2YqrAEqAvn8UgnaZxRId/FgSAhcCM3g80fssYOsBtSd3GyBW Jk5+NWsR0o5YeIzifuUBA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=s3rsRAXhIG3OADJqkp5aP4rb+bTJ9aKd/cH/6s5vFPwkeBs71Cg5n2C0WWhxYwILB sayAYe2ma+PiD9qFnpAsA== Received: from ggnk3 (ggnk3.prod.google.com [10.218.97.67]) by wpaz29.hot.corp.google.com with ESMTP id p9P5J36q010303 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2011 22:22:25 -0700 Received: by ggnk3 with SMTP id k3so166090ggn.9 for ; Mon, 24 Oct 2011 22:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=k8txp54X0EDgU+yez4oZFZJT+S3uX2uEV1EEe4/b4gQ=; b=dBk3wqVe7r8kl9kMcsg1LxCJTwFP5rMJODDfFqBlwDKmwaYb9fVJ1B/WXjIYBbFaAy Liw7suqESEOcLwu3bsxA== Received: by 10.150.160.12 with SMTP id i12mr2070272ybe.15.1319520145362; Mon, 24 Oct 2011 22:22:25 -0700 (PDT) Received: by 10.150.160.12 with SMTP id i12mr2070259ybe.15.1319520145183; Mon, 24 Oct 2011 22:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 24 Oct 2011 22:22:05 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Mon, 24 Oct 2011 22:22:05 -0700 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=000e0cd75c8c8714f004b018b981 X-System-Of-Record: true Cc: "Howard, Lee" , Samita Chakrabarti , homenet@ietf.org Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 05:22:30 -0000 --000e0cd75c8c8714f004b018b981 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Oct 24, 2011 at 22:12, Hemant Singh (shemant) wr= ote: > >If you haven't read the homenet email conversations, how do you know tha= t > these are regressions? > > ** > > ** ** > > Some regressions are fairly clear from just glancing at the subject of > emails in homenet. The example is ND Proxy and glancing at emails such a= s > =93cell phone operators may use a single /64=94 and hence the need for ND > Proxy. This is precisely what we discussed in v6ops and closed in v6ops. > If a cell phone operator gives you a single /64, what do you propose to do? >That email says, basically, "it can't be done" without saying why. We had = a > lot of discussion during the interim meeting and we think it can be done > using a routing protocol. Please at least go and >read the strawman I > posted to the list.**** > > ** ** > > Cmon, now. I included clear text showing why it can=92t be done to v6ops= . > My v6ops is open to anyone in v6ops and homenet to reply specifically as= to > how one will get around the problems I raised with using any ospf or rout= ing > protocol for prefix delegation. > Nope, you re-forwarder an email that you wrote saying why you thought it couldn't be done. You don't say why the strawman architecture I proposed can't work. **** > > >Prefix delegation has problems with non-trivial topologies or with > multihoming. > > ** ** > > Preaching to the choir. That is why we punted prefix delegation out of t= he > IPv6 CE router v6ops document. But using a routing protocol to figure ou= t > prefix delegation for the problems you describe above remains to be seen= . > Please read the slides I posted and comment. --000e0cd75c8c8714f004b018b981 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
                    On Mon, Oct 24, 2011 at 22:12, Hemant Singh (she= mant) <shemant@ci= sco.com> wrote:

                    >If you haven't= read the homenet email conversations, how do you know that these are regre= ssions?

                    =A0

                    Some regressions ar= e fairly clear from just glancing at the subject of emails in homenet.=A0 T= he example is ND Proxy and glancing at emails such as =93cell phone operato= rs may use a single /64=94 and hence the need for ND Proxy.=A0 This is prec= isely what we discussed in v6ops and closed in v6ops.


                    If a cell phone op= erator gives you a single /64, what do you propose to do?

                    >Th= at email says, basically, "it can't be done" without saying w= hy. We had a lot of discussion during the interim meeting and we think it c= an be done using a routing protocol. Please at least go and >read the strawman I posted to the list.=

                    =A0

                    Cmon, now.=A0 I included clear text showing why it can=92= t be done to v6ops.=A0 =A0My v6ops is open to anyone in v6ops and homenet t= o reply specifically as to how one will get around the problems I raised wi= th using any ospf or routing protocol for prefix delegation.=A0


                    Nope, you re-forwa= rder an email that you wrote saying why you thought it couldn't be done= . You don't say why the strawman architecture I proposed can't work= .

                    >Prefix delegation has problems with non-trivial topologies or with multiho= ming.

                    =A0

                    Preaching to the choir.=A0 That is why we punted prefix delegation out of = the IPv6 CE router v6ops document.=A0 But using a routing protocol to figur= e out prefix delegation for the problems =A0you describe above remains to b= e seen.


                    Please read the sl= ides I posted and comment.=A0
                    --000e0cd75c8c8714f004b018b981-- From d.sturek@att.net Mon Oct 24 23:47:57 2011 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 BA63621F8A80 for ; Mon, 24 Oct 2011 23:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdFAYRH4Ly71 for ; Mon, 24 Oct 2011 23:47:57 -0700 (PDT) Received: from nm20.access.bullet.mail.sp2.yahoo.com (nm20.access.bullet.mail.sp2.yahoo.com [98.139.44.147]) by ietfa.amsl.com (Postfix) with SMTP id BEC0721F8AD3 for ; Mon, 24 Oct 2011 23:47:51 -0700 (PDT) Received: from [98.139.44.97] by nm20.access.bullet.mail.sp2.yahoo.com with NNFMP; 25 Oct 2011 06:47:51 -0000 Received: from [98.139.44.88] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 25 Oct 2011 06:47:51 -0000 Received: from [127.0.0.1] by omp1025.access.mail.sp2.yahoo.com with NNFMP; 25 Oct 2011 06:47:51 -0000 X-Yahoo-Newman-Id: 715393.8784.bm@omp1025.access.mail.sp2.yahoo.com Received: (qmail 40514 invoked from network); 25 Oct 2011 06:47:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1319525271; bh=U3iBy+ZfH731tbT5MXYb3XoDF4d2rQ3JF455Hshec80=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=yUiHni2ehq5qnbBO9UI3GyNdCgZ0bCrC8OWpQ6NFNgx1CaNJKWMCNh0TQzeYYHZO5hzL2sv4ZVd8N6W4umN8IevdRVdXK5kQKOhNsWVgVBh6dMByy+2iD8BYQ2gCqbp7lpfCzh8O5HAZuFRLvR5z3jD13T49JX+WxlUJtO7fiAY= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MQqVtkAVM1mTmXk_TheF.7smjvMLMQV90ck0vT8MzCV0SL2 wPhnjUEVzGybPj.IpJCelDOuducHLSSpbx0aieKwkvVEKhaBBscZ3DXYqt.4 HKGIlmyWTACeeWc3xNM7UWkOVWhM8AdlEDZWkdeWcv3m52bK_zE1SGKVko_E g3ND8VxgRiKaEbbHf1fP.rWb4pQ2qIDeg5y9oxJZYZMTeRVdGbSRrcCaDgnd QYmHc779m0paL57eEtMFOIfHWOqLsVaurwJ5Mck2kdBaxImPyGNNnY.ALjtx 4k23vM_dHYkfeACZmlJq1Vo6CDLXTCrEcxxW_kHR84frUtqwCtVqaDVNu6R5 kCNa4vARW8fiiyOaqBc0P866nN_7dUP3A_YYdPd0OPi7Tr8O4wRTuRqG0oPK _pySK0XHkYbxc9lc9uQ9w5jNlpLTpO8L_lbyTgQ-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.1.227] (d.sturek@212.170.168.7 with login) by smtp101.sbc.mail.gq1.yahoo.com with SMTP; 24 Oct 2011 23:47:50 -0700 PDT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 24 Oct 2011 15:52:08 -0700 From: Don Sturek To: Thomas Herbst , james woodyatt , Ray Bellis Message-ID: Thread-Topic: [homenet] routing requirements 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] routing requirements 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, 25 Oct 2011 06:47:57 -0000 I agree with Tom that an application gateway and ND proxy is a non starter in a home network setting. Don Sturek On 10/24/11 11:45 AM, "Thomas Herbst" wrote: >In my v6 ops presentation in Beijing, Dave Thaler agreed with you (James). > >I'm on the other side of the argument. > >tom > >From: james woodyatt >Date: Mon, 24 Oct 2011 11:33:26 -0700 >To: Ray Bellis >Cc: "homenet@ietf.org Group" >Subject: Re: [homenet] routing requirements > > >On Oct 24, 2011, at 1:24 AM, Ray Bellis wrote: > > > >Will those arguing for ND Proxy please stand up and be counted? > > > > >I have long complained that certain WPAN physical layers should be >prepared to attach to home networks, either by application layer gateways >on bastion hosts, or by dedicated ND/RD proxy devices, rather than by >demanding that every residential network deploy a standard zero >configuration prefix delegation and routing protocol to interface to these >peculiar WPAN networks. > >I know I'm in the minority on this. I don't think I can point to anyone >who agrees with me. Still, I should be counted. > > >-- >james woodyatt >member of technical staff, core os networking > > > > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From pthubert@cisco.com Tue Oct 25 00:27:12 2011 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 C84D221F8AFE for ; Tue, 25 Oct 2011 00:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yt+KffdNv19 for ; Tue, 25 Oct 2011 00:27:07 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 791E121F8AFC for ; Tue, 25 Oct 2011 00:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=44406; q=dns/txt; s=iport; t=1319527625; x=1320737225; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=+mIlHSiMqYluAzeEHOrIDkMK+gOjtO8lPYfBEikOigc=; b=YbvjAo50UkNTfiWzPsgvzNyy0fge/91va6KAXLFfOxWBz83oWjK9NICC IK3jdbsfbsKz+1aXAtV4dhOewsTc4DPoniNgTLIIjQnaJxpwAJFXhRp1T pI2Pdnf5AYg0vAk7WkNy/cXZr2LnDHw63fuUhFbkx8ialOYpKaMAZYiH7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAAtkpk6Q/khL/2dsb2JhbABDgk2XCo9CgQWBbgEBAQEDEgEJEQNCFwIBCBEEAQELBggIAQYBBgFFCQgBAQQBEggTB51SAZ5YhTSCLmEEmT6MKg X-IronPort-AV: E=Sophos;i="4.69,403,1315180800"; d="scan'208,217";a="1688567" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 25 Oct 2011 07:27:03 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9P7R3rG005535; Tue, 25 Oct 2011 07:27:03 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 09:27:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC92E7.7D969825" Date: Tue, 25 Oct 2011 09:26:58 +0200 Message-ID: In-Reply-To: <16D60F43CA0B724F8052D7E9323565D7243F7EB191@EUSAACMS0715.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyQH74rwyl1glV0QOOG1H42ujp25wAE8UBQAAEKcrAABaGVoAACyGYAAKLrlSA= References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <16D60F43CA0B724F8052D7E9323565D7243F7EB191@EUSAACMS0715.eamcs.ericsson.se> From: "Pascal Thubert (pthubert)" To: "Samita Chakrabarti" , "Hemant Singh (shemant)" , "Howard, Lee" , X-OriginalArrivalTime: 25 Oct 2011 07:27:03.0214 (UTC) FILETIME=[7DC624E0:01CC92E7] Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 07:27:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92E7.7D969825 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd really like to see IPv6 PD solution for the home network for network stability after a power outage or bringing up a new set of network. We have gone through similar debate in RPL development timeframe and finally as far as I know RPL made the prefix configuration optional. =20 [Pascal Thubert ] Samita,=20 =20 I think you are confusing things here. RPL does not delegate prefixes; never did. If RPL routers that will own different prefixes need to obtain those prefixes, they will have to do so some other way. What RPL does is share through an optimized diffusion mechanism the subnet information between RPL routers that are part of a same subnet. More like a multilink subnet adaptation of classical RAs. =20 You'll note that if a router at home needs to establish a tunnel towards a given gateway to get its traffic routed there, then it can also get a prefix through DHCP PD from that gateway with RFC 6276. Tunneling can be useful to direct certain traffic towards certain gateway, and NEMO can make that simple and secure. In that case, for the purpose of traffic towards that gateway (eg a utility GW ) the home network is the visited network. =20 Cheers, =20 Pascal =20 ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Friday, October 21, 2011 5:18 PM To: Howard, Lee; Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements Note the IETF IPv6 CE router specifies use of the ULA in the home to keep the home network independent of the SP network. This way my computer at home can still print to the printer even when my SP IPv6 network is down. We have said this multiple time in v6ops during development of the IPv6 CE router RFC 6204. I don't have the time to read the copious emails of homenet, but seeing some emails here and there I see homenet regressing on issues that are closed in the v6ops IPv6 CE router document development. Examples of issues homenet is regressing on is ND Proxy and use of zospf for prefix delegation in the LAN. There was only one cell phone vendor who was asking us for ND Proxy with a single /64 PD delegated to the phone. We convinced the vendor at the Prague IETF to abandon that idea because such a /64 would need RA Proxy in the CE router and RA Proxy is not defined is any RFC. Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. That is why ND Proxy was removed from the cpe rtr bis document.=20 =20 Zospf was also closed in v6ops that it's not possible to use for prefix delegation in the LAN. Here is an email to v6ops on closure on ospf for prefix delegation. =20 =20 Hemant =20 ---- begin snip ------------ =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Wednesday, July 27, 2011 1:26 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router =20 =20 >Can such a default be extensible to exchange different types of information than just reachability? For example, can it propagate information such as "this is a guest network and this is an internal network" or "this is a prefix that I have tentatively >assigned but do not own yet"? If not, then perhaps something more flexible like IS-IS would be better. =20 Not possible because the proposal is not workable. Someone brought up using OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE router design team. See the questions I asked followed by the person's reply and my responses back to show no routing protocol can be used to delegate prefixes in the LAN. =20 =20 I asked, HS: How do you know OSPF has converged before responding to DHCPv6 PD requests? =20 Reply: The CE router SHOULD wait until two sequential link-state advertisements have no link state changes before delegating any prefixes. This allows time for OSPF to converge, and for the router to build a topology map. =20 Seeing the above reply, I made my comment: =20 HS: Still does not work. After OSPF converges, what happens if the user changes the network such as unplugging a router and moving the router? =20 Reply: The router has a link state table-when it changes, you go through discovery again and issue a Reconfigure where appropriate. =20 =20 HS: There is a network bridge between two routers and the bridge does not have any means to report link-up or down. Further, what if a network interface of a router is flapping all the time and thus basing any algorithm on OSPF convergence breaks down. The flapping interface problem becomes worse if one has a cyclic network. Your proposal still does not work. =20 =20 Hemant =20 =20 ------ end snip --------- =20 =20 =20 =20 =20 From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 5:26 PM To: Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements =20 Can you describe some scenarios which would cause a prefix to change, in which applications break in ways that are unacceptable? All of the ones I can think of would be cases where I would expect a session to drop, but I'm sure that's a lack of creativity on my part. =20 Lee =20 From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com]=20 Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements =20 Hello Howard, =20 Thank you very much for the summary of messages. =20 A comment on item 12: 12. Prefix stability?=20 =20 SC> I expect that 'Prefix Stability' is a requirement at home or small offices. Without prefix stability some of the applications will suddenly break when the old prefix expires and the new prefix becomes effective. =20 And question to the wg: =20 8. Support for multiple upstream networks is a requirement. g. Source address selection is out of scope. And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden). Choosing which address to use to look up the destination address is out of scope. =20 SC> Is the expectation from homenet wg that all hosts will implement RFC 3484 ? Do the current home IPv6 host products support RFC 3484 ? [ I don't think so ] So the host implementation change should be required if a host has to support multiple prefixes or I might be missing something? =20 =20 Thanks, -Samita =20 =20 ________________________________ From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org Subject: [homenet] routing requirements I've caught up on some 300 messages about routing. Here are the requirements I've gleaned. Question marks are unclear to me, please help. =20 1. Homenet router requirements 2. When evaluating a solution, discuss whether it provides for: 3. Reachability between all nodes in the home network. a. Links may be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple L2 types. 4. Border detection. =20 a. Border may be upstream ISP, or may be a device that is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to home net. Or there may be no border, if no external connection has been established. =20 b. Must be able to find "up" (a path to the Internet), but must not be dependent on "up" (Internet connectivity) existing for intra-home reachability. c. May be discovered by routing protocol, or other means. 5. Robust to routers being moved/added/removed/renumbered a. Convergence time a few minutes or less. 6. No configuration required. a. We might tolerate? a single password being entered on each device. Discuss. 7. Best-path is a non-requirement. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scenarios. =20 b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condition? g. Source address selection is out of scope. And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden). Choosing which address to use to look up the destination address is out of scope. 9. Cannot assume hierarchical prefix delegation in the home (at least, not unless the WG develops such a solution). 10. A host with mutliple upstream paths to the same destination should be able to use another in case on fails.=20 11. Prevent looping. 12. Prefix stability? =20 13. Lightweight (cheap) implementation. Let me know if I've missed, or mistated, anything. =20 Lee =20 =20 ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------_=_NextPart_001_01CC92E7.7D969825 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                    I'= d really like to see IPv6 PD solution for the home network for network = stability after a power outage or bringing up a new set of = network.

                    We= have gone through similar debate in RPL development timeframe and = finally as far as I know RPL made the prefix configuration = optional.

                     

                    [Pascal Thubert ] Samita, =

                     

                    I = think you are confusing things here. RPL does not delegate prefixes; = never did. If RPL routers that will own different prefixes need to = obtain those prefixes, they will have to do so some other way. What RPL = does is share through an optimized diffusion mechanism the subnet = information between RPL routers that are part of a same subnet. More = like a multilink subnet adaptation of classical = RAs.

                     

                    You’ll note that if a router at home needs = to establish a tunnel towards a given gateway to get its traffic routed = there, then it can also get a prefix through DHCP PD from that gateway = with RFC 6276. Tunneling can be useful to direct certain traffic towards = certain gateway, and NEMO can make that simple and secure. In that case, = for the purpose of traffic towards that gateway (eg a utility GW ) the = home network is the visited network.

                     

                    Cheers,

                     

                    Pascal

                     

                    From:= homenet-bounces@ietf.org [mailto:homenet-bounces= @ietf.org] On Behalf Of Hemant Singh = (shemant)
                    Sent: Friday, October 21, 2011 5:18 PM
                    To: = Howard, Lee; Samita Chakrabarti; homenet@ietf.org
                    Subject: = Re: [homenet] routing requirements

                    Note the IETF IPv6 CE router = specifies use of the ULA in the home to keep the home network = independent of the SP network.  This way my computer at home can = still print to the printer even when my SP IPv6 network is down.  = We have said this multiple time in v6ops during development of the IPv6 = CE router RFC 6204.  I don’t have the time to read the = copious emails of homenet, but seeing some emails here and there I see = homenet regressing on issues that are closed in the v6ops IPv6 CE router = document development.  Examples of issues homenet is regressing on = is ND Proxy and use of zospf for prefix delegation in the LAN.  =  There was only one cell phone vendor who was asking us for ND = Proxy with a single /64 PD delegated to the phone.   We = convinced the vendor at the Prague IETF to abandon that idea because = such a /64 would need RA Proxy in the CE router and RA Proxy is not = defined is any RFC.  Thus the vendor agreed and decided to go with = DHCPv6 PD of RC 3633.  That is why ND Proxy was removed from the = cpe rtr bis document.

                     

                    Zospf was = also closed in v6ops that it’s not possible to use for prefix = delegation in the LAN.   Here is an email to v6ops on closure = on ospf for prefix delegation. 

                     

                    Hemant

                     

                    ---- begin = snip ------------

                     

                    From:= Lorenzo = Colitti [mailto:lorenzo@google.com]
                    Sent: Wednesday, July 27, 2011 1:26 PM
                    To: = Hemant Singh (shemant)
                    Cc: IPv6 Operations
                    Subject: = Re: [v6ops] default LAN routing protocol for IPv6 CE = router

                     

                     

                    >Can = such a default be extensible to exchange different types of information = than just reachability? For example, can it propagate information such = as "this is a guest network and this is an internal network" = or "this is a prefix that I have tentatively >assigned but do not own yet"? If = not, then perhaps something more flexible like IS-IS would be = better.

                     

                    Not = possible because the proposal is not workable.   Someone = brought up using OSPFv3 for use in prefix delegation in the home LAN to = our IETF CPE router design team.  See the questions I asked = followed by the person’s reply and my responses back to show no = routing protocol can be used to delegate prefixes in the LAN. =  

                     

                    I asked, = HS: How do you know OSPF has converged before responding to DHCPv6 PD = requests?

                     

                    Reply: The = CE router SHOULD wait until two sequential link-state advertisements = have no link state  changes before delegating any prefixes.  = This allows time for OSPF to converge, and for the  router to build = a topology map.

                     

                    Seeing the = above reply, I made my comment:

                     

                    HS: Still = does not work.  After OSPF converges, what happens if the user = changes the network such  as unplugging a router and moving the = router?

                     

                    Reply: The = router has a link state table—when it changes, you go through = discovery again and issue a  Reconfigure where appropriate.  =

                     

                    HS: =  There is a network bridge between two routers and the bridge does = not have any means to report link-up  or down.  Further, what = if a network interface of a router is flapping all the time and thus =  basing any algorithm on OSPF convergence breaks down.  The = flapping interface problem becomes  worse if one has a cyclic = network.  Your proposal still does not work.  =

                     

                    Hemant

                     

                     

                    ------ end = snip ---------

                     

                     

                     

                     

                     

                    From:= homenet-bounces@ietf.org [mailto:homenet-bounces= @ietf.org] On Behalf Of Howard, Lee
                    Sent: Friday, = October 21, 2011 5:26 PM
                    To: Samita Chakrabarti; homenet@ietf.org
                    Subject: = Re: [homenet] routing requirements

                     

                    Can you describe some scenarios which would = cause a prefix to change, in which applications break in ways that are = unacceptable?  All of the ones I can think of would be cases where = I would expect a session to drop, but I’m sure that’s a lack = of creativity on my part.

                     

                    Lee

                     

                    From:= Samita = Chakrabarti [mailto:samita.c= hakrabarti@ericsson.com]
                    Sent: Friday, October 21, 2011 = 5:08 PM
                    To: Howard, Lee; homenet@ietf.org
                    Subject: = RE: routing requirements

                     

                    He= llo Howard,

                     

                    Th= ank you very much for the summary of messages.

                     

                    A = comment on item 12:

                    12.  Prefix stability? 

                     

                    SC= >  I expect that 'Prefix Stability' is a requirement at home or = small offices. Without prefix stability some of the applications will = suddenly break when the old prefix expires and the new prefix becomes = effective.

                     

                    An= d question to the wg:

                     

                    8.   &= nbsp;  Support for = multiple upstream networks is a requirement.

                    g.   &= nbsp;  Source = address selection is out of scope.  And should be solved by = rfc3484, with longest prefix match (whether ULA or walled garden).  = Choosing which address to use to look up the destination address is out = of scope.

                     

                    SC> Is the expectation from homenet wg that all hosts = will implement RFC 3484 ?

                    Do the current home IPv6 host products support RFC 3484 ? = [ I don't think so ]  So the host implementation change should = be required if a host has to support multiple prefixes or I might = be missing something?

                     

                     

                    Thanks,

                    -Samita

                     

                     

                    From:= homenet-bounces@ietf.org [mailto:homenet-bounces= @ietf.org] On Behalf Of Howard, Lee
                    Sent: Friday, = October 21, 2011 11:32 AM
                    To: homenet@ietf.org
                    Subject: = [homenet] routing requirements

                    I've caught up on some 300 messages about routing.  = Here are the requirements I've gleaned.  Question marks are unclear = to me, please help.

                     

                    1.     = Homenet router = requirements

                    2.     = When evaluating a solution, discuss whether = it provides for:

                    3.     = Reachability between all nodes in the home = network.

                    a.     =   Links may be Ethernet, WiFi, MoCA, or = any other; test all solutions against mutliple L2 = types.

                    4.     = Border detection.  =

                    a.     =   Border may be upstream ISP, or may be a = device that is a gateway to SmartGrid devices, e.g. a controller that = speaks RPL to 802.15.4 and foo to home net.  Or there may be = no border, if no external connection has been established.  =

                    b.     = Must be able to find “up” (a path = to the Internet), but must not be dependent on “up” = (Internet connectivity) existing for intra-home = reachability.

                    c.     =   May be discovered by routing protocol, = or other means.

                    5.     = Robust to routers being = moved/added/removed/renumbered

                    a.     =   Convergence time a few minutes or = less.

                    6.     = No configuration = required.

                    a.     =   We might tolerate? a single password = being entered on each device.  Discuss.

                    7.     = Best-path is a = non-requirement.

                    8.     = Support for multiple upstream networks is a = requirement.

                    a.     =   Including wireless offload, video-only, = and split-tunnel VPN scenarios. 

                    b.     = With separate routers to each.  Not = multihomed off the same router.

                    c.     =   Prefix delegated from all ISPs = (upstreams).

                    d.     = ISP A is default.

                    e.     =   With only traffic destined to ISP = B’s prefix using that link.

                    f.     =   With a backup default to ISP B, if = desired.  What is default condition?

                    g.     = Source address selection is out of = scope.  And should be solved by rfc3484, with longest prefix match = (whether ULA or walled garden).  Choosing which address to use to = look up the destination address is out of scope.

                    9.     = Cannot assume hierarchical prefix delegation = in the home (at least, not unless the WG develops such a = solution).

                    10.  = A host with mutliple upstream paths to the = same destination should be able to use another in case on fails. =

                    11.  = Prevent looping.

                    12.  Prefix stability? 

                    13.  Lightweight (cheap) implementation.

                    Let me know if I’ve = missed, or mistated, anything.

                     

                    Lee

                     

                     

                    Thi= s E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use 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 dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any = printout.

                    ------_=_NextPart_001_01CC92E7.7D969825-- From jari.arkko@piuha.net Tue Oct 25 07:03:51 2011 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 DA9DE21F8A71 for ; Tue, 25 Oct 2011 07:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4mrQX0smD7U for ; Tue, 25 Oct 2011 07:03:51 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3928521F8AEE for ; Tue, 25 Oct 2011 07:03:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8734F2CC3B; Tue, 25 Oct 2011 17:03:49 +0300 (EEST) 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 vVrNs+Ujp0ex; Tue, 25 Oct 2011 17:03:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C40C72CC34; Tue, 25 Oct 2011 17:03:48 +0300 (EEST) Message-ID: <4EA6C1C4.7050609@piuha.net> Date: Tue, 25 Oct 2011 16:03:48 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Acee Lindem Subject: [homenet] a few drafts... 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, 25 Oct 2011 14:03:52 -0000 Here's a couple of drafts inspired by discussions from the interim meeting: http://tools.ietf.org/html/draft-acee-ospf-ospfv3-autoconfig-00.txt OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-00.txt This memo describes a prefix assignment mechanism for home networks. It is expected that home gateway routers are assigned an IPv6 prefix through DHCPv6 Prefix Delegation (PD). This prefix needs to be divided among the multiple subnets in a home network. This memo describes a mechanism for such division via OSPFv3. This is an alternative design to using DHCPv6 PD also for the prefix assignment. The memo is input to the working group so that it can make a decision on which type of design to pursue. It is expected that a routing- protocol based assignment uses a minimal amount of prefixes. Comments appreciated! Jari From lee.howard@twcable.com Tue Oct 25 10:33:18 2011 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 D6E4D21F8BAE for ; Tue, 25 Oct 2011 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksQGAvoV73vU for ; Tue, 25 Oct 2011 10:33:18 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 09B1D21F8BEE for ; Tue, 25 Oct 2011 10:33:17 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,403,1315195200"; d="scan'208";a="289433897" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Oct 2011 13:29:26 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 25 Oct 2011 13:33:16 -0400 From: "Howard, Lee" To: "curtis@occnc.com" Date: Tue, 25 Oct 2011 13:33:14 -0400 Thread-Topic: [homenet] routing requirements Thread-Index: AcyScQhQx53yb/YwTSGme4JZeO+2uwAyd7KQ Message-ID: References: Your message of "Mon, 24 Oct 2011 09:58:41 EDT." <201110241718.p9OHIud5060865@gateway.ipv6.occnc.com> In-Reply-To: <201110241718.p9OHIud5060865@gateway.ipv6.occnc.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: Samita Chakrabarti , "homenet@ietf.org" Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 17:33:19 -0000 > > > Most IPv4 hosts can't tolerate their IP address going away. For IPv6 > > > its slightly easier because they can add a new address in a new > > > prefix. Only think is the host need to ask for an address and today > > > if its lease has not expired it won't ask. Some older DHCP code won'= t > > > take a change in address or default route when the lease expires. > > > > The case we were talking about, I think, was a link or device failure. > > One expects an outage in those cases. > > If you have two uplinks, you shouldn't need to reboot everything your > house to get connectivity back up because hosts and routers are using > a prefix that is no longer globally routable. Agree. That's different that renumbering or reconverging. > > > One thing that would break is any open TCP connections. The open > > > connections use the already selected address. This has been a proble= m > > > for mobility for quite a while but those heavier solution can't be > > > applied to this problem. > > > > TCP is not expected to be resilient to outages. We're not building a > > carrier network, we're building a home network. Bounce the > > connection. > > No one is suggesting we try to avoid dropping an open TCP connection > on a down transition from the uplink that provided the address the > host is using. Ah, I thought that's what you were suggesting. In a scenario where there's a triangle of routers in the home, A to the ISP= , B and C both connected to A, and Host D connected (shared medium) to both B and C. . . if B fails, how fast must C become available? I want self-repair within a couple of minutes, but not subsecond. Or more precisely, I want self-repair for an arbitrarily large and complex home network before the user finds the number for tech support. In another message you said: > > > Seconds at least. Goal for providers is 60 msec, but subsecond > > > would be a reasonable goal for wired. > > Why would we need that level of repair? This is a home network, not a > > carrier network. > On wired it is easy to get subsecond in a small topology. It would be ni= ce > if you streaming audio, movie, phone call to support, etc, stayed up when > a minor change was made as long as connectivity still existed. Easy doesn't mean required. How small a topology? What about network layers other than Ethernet? I agree it would be nice, but "nice to have" is different than "required." > > > Concievably a TCP extension could support alternate source addresses > > > (such as SCTP does). Until then, a TCP connection can't change > > > addresses. > > > > > > If you switch from one provider uplink to another, you should be able > > > to keep talking to your content provider. Currently you can't. For > > > web users, hit the stop and the reload. > > > > Web, p2p, gaming, VPN. . . I'm okay with the session dropping in case > > of failure. > > > Yes. This is not a TCP ng WG so we don't try to fix TCP here. > > There are cases like two uplinks to the same provider (same /64 > prefix) that would work without any effort. This would be rare in the > home though not unthinkable in a home or small business and not > uncommon in medium and large businesses. > > We should make it possible for multihoming scenarios such as this to > work, preferably with no configuration, except at the provider. For > example, an extension to IA_PD essentially saying "use X/65 which came > from X/64 and has no firewall enabled yet" would allow the provider to > do all the configuration needed to make this workable with zero config > on the customer side. I don't follow you, but it sounds like a good topic for a new thread. 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 jhw@apple.com Tue Oct 25 10:47:54 2011 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 031EE21F8B03 for ; Tue, 25 Oct 2011 10:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.418 X-Spam-Level: X-Spam-Status: No, score=-106.418 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrvfI18sCmos for ; Tue, 25 Oct 2011 10:47:53 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7E76521F8ACA for ; Tue, 25 Oct 2011 10:47:53 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YM2zP+abSReMoMdtvsJsTA)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LTM00KS1UMIVA30@mail-out.apple.com> for homenet@ietf.org; Tue, 25 Oct 2011 10:47:45 -0700 (PDT) X-AuditID: 11807136-b7c19ae0000072b0-36-4ea6f641f535 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 0F.A3.29360.146F6AE4; Tue, 25 Oct 2011 10:47:45 -0700 (PDT) From: james woodyatt Date: Tue, 25 Oct 2011 10:47:45 -0700 In-reply-to: To: "homenet@ietf.org Group" References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> Message-id: X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUieJDvpq7jt2V+Bk+eS1u8X3SIxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGcs+3WAu2CxX8XnJDtYGxmdSXYycHBICJhJTLhxihrDFJC7c W8/WxcjFISSwgkni6d0LTCAJNgEViW+X74LZvALGEmtuvWPpYuTgYBZIkHjRHAASFhbQluj5 v4QNxGYRUJV4OWs7K4jNKRAo0d/SBBYXEdCXeHrkF9T8r8wSnxbeYIeYaSPRcOQ1C8QR8hIt X++wTWDknYVk3SyEdSBhZqB1yxa+ZoawDSSedr5ixRTXl3jzbg7TAka2VYyCRak5iZWGpnqJ BQU5qXrJ+bmbGEGB11BotoNxx1+5Q4wCHIxKPLwFX5b5CbEmlhVX5h5ilOBgVhLhbT0BFOJN SaysSi3Kjy8qzUktPsQozcGiJM671mCxn5BAemJJanZqakFqEUyWiYNTqoHR+n6IuPaslVda yl6dylContz/xv1yTeelNUuMs9/Umd26O0fs1DHTTwUiwbMfrn6gHRD7l7HuJ7vA9bdBF87o 3ql27hN8nKV2eCKT6ryKX2KCuabKQQ43e9Irheew8SS/VjmdLnRNNd6DxzQ+/vKvXUv8Z7qp iPDkd0WZqGx12nd8n++LVzOUWIozEg21mIuKEwHRJCkWOAIAAA== Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 17:47:54 -0000 --Boundary_(ID_YM2zP+abSReMoMdtvsJsTA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Oct 24, 2011, at 10:22 PM, Lorenzo Colitti wrote: > > If a cell phone operator gives you a single /64, what do you propose to do? If a certain CableLabs MSO gives each of its several tens of millions of Internet users in North America only a single /64, what do we propose to do? -- james woodyatt member of technical staff, core os networking --Boundary_(ID_YM2zP+abSReMoMdtvsJsTA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
                    If a = cell phone operator gives you a single /64, what do you propose to = do?

                    If a certain CableLabs MSO = gives each of its several tens of millions of Internet users in North = America only a single /64, what do we propose to do?


                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_YM2zP+abSReMoMdtvsJsTA)-- From lorenzo@google.com Tue Oct 25 10:56:34 2011 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 1E4D821F8B88 for ; Tue, 25 Oct 2011 10:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.764 X-Spam-Level: X-Spam-Status: No, score=-105.764 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3L3ERv-PTor for ; Tue, 25 Oct 2011 10:56:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD0C21F8B83 for ; Tue, 25 Oct 2011 10:56:32 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p9PHuU27025509 for ; Tue, 25 Oct 2011 10:56:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319565390; bh=JbzNkyrKpTUEoecbGq8PhdD5Tg4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CX8IWsOYasgKqnxZo88dhwpzJJOQwaNTfVXwlKGIrWhsO8ZTi8pTjcaG7TxZrkg2i nF0W2phJqa4s/lHRQ4Ehg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=N9DYt4SmQQ21BFGk0m7MvnOdRGyX6ecnuMrtKHBVYvGMlMreCdeDHUg8EYroYmPxK dBLUoNrBKcQ1ljTpzIUcQ== Received: from ggnq4 (ggnq4.prod.google.com [10.218.98.132]) by wpaz5.hot.corp.google.com with ESMTP id p9PHrAWG004277 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 10:56:29 -0700 Received: by ggnq4 with SMTP id q4so1102335ggn.4 for ; Tue, 25 Oct 2011 10:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=F1Fs9mx88sKMHkNzIIW9qSAs8s9e39o52aMBu4Sn3Ek=; b=cN/QksriSOC2fgeMNnbkWxIrLfYa0iqmRB0CqnmaDb7aOYUAP+Ny651KGyxuGdO7JG ojuT2Qy7WNvXN56qWTPQ== Received: by 10.150.59.1 with SMTP id h1mr25863842yba.90.1319565388852; Tue, 25 Oct 2011 10:56:28 -0700 (PDT) Received: by 10.150.59.1 with SMTP id h1mr25863828yba.90.1319565388668; Tue, 25 Oct 2011 10:56:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 25 Oct 2011 10:56:07 -0700 (PDT) In-Reply-To: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Tue, 25 Oct 2011 10:56:07 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=000e0cd6ae683fe0d604b0234264 X-System-Of-Record: true Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 17:56:34 -0000 --000e0cd6ae683fe0d604b0234264 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 25, 2011 at 10:47, james woodyatt wrote: > On Oct 24, 2011, at 10:22 PM, Lorenzo Colitti wrote: > > > If a cell phone operator gives you a single /64, what do you propose to do? > > > If a certain CableLabs MSO gives each of its several tens of millions of > Internet users in North America only a single /64, what do we propose to do? > Admit defeat and either bridge everything or route longer-than-/64 prefixes. I hope it won't come to that. --000e0cd6ae683fe0d604b0234264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
                    On Tue, Oct 25, 2011 at 10:47, james woodyatt <jhw@= apple.com> wrote:
                    On Oct 24, 2011, at 10:2= 2 PM, Lorenzo Colitti wrote:

                    for homenet@ietf.org; Tue, 25 Oct 2011 11:00:48 -0700 (PDT) X-AuditID: 11807136-b7c19ae0000072b0-da-4ea6f950dc18 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id D4.A9.29360.059F6AE4; Tue, 25 Oct 2011 11:00:48 -0700 (PDT) From: james woodyatt Date: Tue, 25 Oct 2011 11:00:48 -0700 In-reply-to: To: "homenet@ietf.org Group" References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> Message-id: X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUieJDvpm7Az2V+Bm2dUhbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvMPkxkL1ipWPJ/v3cC4TraLkYNDQsBEYtEBly5GTiBTTOLC vfVsXYxcHEICK5gkfp3dzwSSYBNQkfh2+S6YzStgLLHm1jsWEJtZIEFixcV+dhBbWEBbouf/ EjYQm0VAVeJM41MmkPmcAoESnz6bgYRFBPQlnh75BVYiJPCaRWL74ziIkTYS/Q/2skHcIC/R 8vUO2wRG3llIts1Csg3C1pZYtvA1M4StJ/Gy6R0WcV2Ji+smMS5gZFvFKFiUmpNYaWiql1hQ kJOql5yfu4kRFHQNhWY7GHf8lTvEKMDBqMTDW/BlmZ8Qa2JZcWXuIUYJDmYlEd7WE0Ah3pTE yqrUovz4otKc1OJDjNIcLErivGsNFvsJCaQnlqRmp6YWpBbBZJk4OKUaGEsncmn/3qHgyMq+ vPTWrxY1g5rXXw+060Yv8Tvg4npsttKxqqmbQ/JLjstVi4k4KrHzM+Wz+J7mO3PtrcGpbDPJ 941N5/+J/iqZnRnh8mbWm0unbRfcOD3VUkzJ61e2k/Sux3fmckp5il+7tfewe5KS2otWw8jz LyJOTq9dev1k0k3WOe2NK5VYijMSDbWYi4oTAYhy6bc2AgAA Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 18:01:02 -0000 --Boundary_(ID_GFgNX1eyImsZMo5G+qsvwA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Oct 25, 2011, at 10:56 AM, Lorenzo Colitti wrote: > > Admit defeat and either bridge everything or route longer-than-/64 prefixes. I hope it won't come to that. I would prefer to deploy NAPT66 rather than route prefixes longer than /64. In fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever the service provider delegates anything longer than /48, so that we can route /48 prefixes uniformly across the entire home network. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_GFgNX1eyImsZMo5G+qsvwA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
                    Admit defeat = and either bridge everything or route longer-than-/64 prefixes. I hope = it won't come to that.

                    I would prefer = to deploy NAPT66 rather than route prefixes longer than /64.  In = fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever = the service provider delegates anything longer than /48, so that we can = route /48 prefixes uniformly across the entire home = network.


                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_GFgNX1eyImsZMo5G+qsvwA)-- From lorenzo@google.com Tue Oct 25 11:06:43 2011 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 1BEDB21F8B19 for ; Tue, 25 Oct 2011 11:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.913 X-Spam-Level: X-Spam-Status: No, score=-105.913 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGcwm24EP9Fy for ; Tue, 25 Oct 2011 11:06:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8818221F8B11 for ; Tue, 25 Oct 2011 11:06:42 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p9PI6fWY030103 for ; Tue, 25 Oct 2011 11:06:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319566002; bh=jVbsQaiLCcw/W4WMesJH/1zYNJo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=QxHuWCUSdIg+X9Th49jr6KcDfMlPgdra6PGJ38W9s40z8tT4gCQNp282bxaV/iTXL bSBo/j5EtkdDLz3RjddrQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ZJHSzDquOicIZHiK9gBNY5VJieZ9p9JrfPjsaac4WJ7LvN5UAdbd5LZwJvPMhNjiB VCNRM9fjnteRlHA696feA== Received: from vws15 (vws15.prod.google.com [10.241.21.143]) by hpaq1.eem.corp.google.com with ESMTP id p9PI1Fv5003117 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 11:04:11 -0700 Received: by vws15 with SMTP id 15so1106686vws.6 for ; Tue, 25 Oct 2011 11:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=UQp5vBECAkyY3zzoCteoqv2yMCetsPtVCKbiEFr7urM=; b=EuUS9J8X7iqSWUtaNP4Zhs4phCF19Um9lDUUWQDNo8VbuJProBAVEXvH6c/bBCkhni hyUHuw7rSFmo+cV28YkQ== Received: by 10.151.15.4 with SMTP id s4mr6219051ybi.30.1319565849279; Tue, 25 Oct 2011 11:04:09 -0700 (PDT) Received: by 10.151.15.4 with SMTP id s4mr6219035ybi.30.1319565849130; Tue, 25 Oct 2011 11:04:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 25 Oct 2011 11:03:49 -0700 (PDT) In-Reply-To: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Tue, 25 Oct 2011 11:03:49 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=000e0cd6e82ab1f5ac04b0235d56 X-System-Of-Record: true Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 18:06:43 -0000 --000e0cd6e82ab1f5ac04b0235d56 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 25, 2011 at 11:00, james woodyatt wrote: > Admit defeat and either bridge everything or route longer-than-/64 > prefixes. I hope it won't come to that. > > > I would prefer to deploy NAPT66 rather than route prefixes longer than /64. > In fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever > the service provider delegates anything longer than /48, so that we can > route /48 prefixes uniformly across the entire home network. > Sure, that optimizes routing, but it forces applications to be more complex. Do you really want all the STUN / TURN / ICE code that we have today to keep being necessary? --000e0cd6e82ab1f5ac04b0235d56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
                    On Tue, Oct 25, 2011 at 11:00, james woodyatt <jhw@apple.com><= /span> wrote:
                    Admit defeat and= either bridge everything or route longer-than-/64 prefixes. I hope it won&= #39;t come to that.

                    I would prefer to deploy NAPT66 rather than route pref= ixes longer than /64. =A0In fact, I'm tempted to to say we should prefe= r to deploy NAPT66 wherever the service provider delegates anything longer = than /48, so that we can route /48 prefixes uniformly across the entire hom= e network.

                    Sure, that optimizes routing, but it= forces applications to be more complex. =A0Do you really want all the STUN= / TURN / ICE code that we have today to keep being necessary?
                    --000e0cd6e82ab1f5ac04b0235d56-- From jhw@apple.com Tue Oct 25 11:08:04 2011 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 11FA421F8B19 for ; Tue, 25 Oct 2011 11:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhBFjNI02bLy for ; Tue, 25 Oct 2011 11:08:03 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 96B2921F8B11 for ; Tue, 25 Oct 2011 11:08:03 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YV8M8QPkM93EgJxx67tgeg)" Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LTM00CAUVMVU8U1@mail-out.apple.com> for homenet@ietf.org; Tue, 25 Oct 2011 11:07:27 -0700 (PDT) X-AuditID: 1180711d-b7b7dae000007623-9a-4ea6fadb4569 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 3F.50.30243.CDAF6AE4; Tue, 25 Oct 2011 11:07:25 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 25 Oct 2011 11:07:23 -0700 Message-id: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUieJDvpu7dX8v8DC6eNLN4v+gQi8X60+8Y HZg8Fmwq9Viy5CdTAFMUl01Kak5mWWqRvl0CV8byQ1wFBxUr1h28w9TAuFa2i5GTQ0LAROL9 jyVMELaYxIV769m6GLk4hARWMElMuTKJHSQhLKAt0fN/CRuIzStgLLHm1jsWEJtZIEFief9i MJtNQEXi2+W7YIM4BQIlJs5bzghiswioSlw528cOUa8v0bvnIdQcG4nWo1tZIJY9ZJWYtnQO 2CARAQ2JB+uOQ10kL9Hy9Q7bBEa+WUh2z0KyG8LWlli28DUzhK0n8bLpHTumuK7ExXWTGBcw sq1iFCxKzUmsNDTWSywoyEnVS87P3cQICtKGQtkdjPt/8h9iFOBgVOLhLfyyzE+INbGsuDL3 EKMEB7OSCG/rCaAQb0piZVVqUX58UWlOavEhRmkOFiVx3lUGi/2EBNITS1KzU1MLUotgskwc nFINjBwL/wp+jLpwJ718pwWTwfdD5tzecWyTGLw9o19HRXQ9EYmaXjgh3Nl13ZI9v41n6v1h YblTH3y49kZo9K2+1v9Gf+teM0bfExFeVKz119Lgnvez/aobdI0KOXVimdtthZg8I2db2f14 lsbM+DR7bwfPh5i9up3xDVu+buO8s+b91q92SQkJSizFGYmGWsxFxYkAvgmQ304CAAA= Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 18:08:04 -0000 --Boundary_(ID_YV8M8QPkM93EgJxx67tgeg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Oct 25, 2011, at 11:03 AM, Lorenzo Colitti wrote: > Sure, that optimizes routing, but it forces applications to be more complex. Do you really want all the STUN / TURN / ICE code that we have today to keep being necessary? That's all going to be necessary anyway because of the ubiquitous deployment of RFC 6092 in default-enabled configurations. Applications are already going to be forced to cope with that complexity, so why not simplify addressing an use NAPT66 on the ULA prefix? -- james woodyatt member of technical staff, core os networking --Boundary_(ID_YV8M8QPkM93EgJxx67tgeg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
                    Sure, that = optimizes routing, but it forces applications to be more complex. =  Do you really want all the STUN / TURN / ICE code that we have = today to keep being = necessary?

                    That's all going = to be necessary anyway because of the ubiquitous deployment of RFC 6092 = in default-enabled configurations.  Applications are already going = to be forced to cope with that complexity, so why not simplify = addressing an use NAPT66 on the ULA prefix?


                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_YV8M8QPkM93EgJxx67tgeg)-- From lorenzo@google.com Tue Oct 25 11:13:26 2011 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 6165E21F8BBB for ; Tue, 25 Oct 2011 11:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.918 X-Spam-Level: X-Spam-Status: No, score=-105.918 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXO7xAYiOa3q for ; Tue, 25 Oct 2011 11:13:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B16A521F8BB0 for ; Tue, 25 Oct 2011 11:13:25 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p9PIDPP8014303 for ; Tue, 25 Oct 2011 11:13:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319566405; bh=mXNIQscYEnD6WV9RHn7EmxxacGk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=G5I8XufB5DWuKf5AoItNPkw7MhBsgBt7jvf2EKmFp8cWcrrOBprkwrIiocgT4bfNc 35fU0fdXLUhiihxl1MzCw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=DN5uzlR/rPyGcMdKVBzJiRKUKPBhJ+E+xYI67naD+sO7/gIXl4lzYP2+91DoZaNrw Lae0DWSu9iVz93uwR3lQA== Received: from qyk2 (qyk2.prod.google.com [10.241.83.130]) by wpaz37.hot.corp.google.com with ESMTP id p9PI97pM006515 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 11:13:24 -0700 Received: by qyk2 with SMTP id 2so1134296qyk.8 for ; Tue, 25 Oct 2011 11:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=s4Zpo0WEslOk3iq0xsWLLin1o3da0MAtyREi7WuD/Rs=; b=LSmRyIQ7JNfLJ+Q4U7x3gZP+EyxHAovFniI5GuqZvaSrhodPVr3qwAAEULKBOYCq+Z NyyvhHo7vkhsPp4DYvDA== Received: by 10.150.206.6 with SMTP id d6mr26510546ybg.60.1319566404363; Tue, 25 Oct 2011 11:13:24 -0700 (PDT) Received: by 10.150.206.6 with SMTP id d6mr26510527ybg.60.1319566404121; Tue, 25 Oct 2011 11:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 25 Oct 2011 11:13:04 -0700 (PDT) In-Reply-To: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Tue, 25 Oct 2011 11:13:04 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=000e0cd404d0c6733404b0237e71 X-System-Of-Record: true Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 18:13:26 -0000 --000e0cd404d0c6733404b0237e71 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 25, 2011 at 11:07, james woodyatt wrote: > Sure, that optimizes routing, but it forces applications to be more > complex. Do you really want all the STUN / TURN / ICE code that we have > today to keep being necessary? > > > That's all going to be necessary anyway because of the ubiquitous > deployment of RFC 6092 in default-enabled configurations. Applications are > already going to be forced to cope with that complexity, so why not simplify > addressing an use NAPT66 on the ULA prefix? > Coping with firewalls is easier than coping with NATs, because at least you know your public IP address. --000e0cd404d0c6733404b0237e71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
                    On Tue, Oct 25, 2011 at 11:07, james woodyatt <jhw@apple.com><= /span> wrote:
                    Sure, that optim= izes routing, but it forces applications to be more complex. =A0Do you real= ly want all the STUN / TURN / ICE code that we have today to keep being nec= essary?

                    That's all going to be necessary anyway= because of the ubiquitous deployment of RFC 6092 in default-enabled config= urations. =A0Applications are already going to be forced to cope with that = complexity, so why not simplify addressing an use NAPT66 on the ULA prefix?=

                    Coping with firewalls is easier than= coping with NATs, because at least you know your public IP address.
                    <= /div> --000e0cd404d0c6733404b0237e71-- From shemant@cisco.com Tue Oct 25 11:29:41 2011 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 0B46221F8C33 for ; Tue, 25 Oct 2011 11:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNANL45F57qM for ; Tue, 25 Oct 2011 11:29:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DC5E221F8C32 for ; Tue, 25 Oct 2011 11:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10681; q=dns/txt; s=iport; t=1319567375; x=1320776975; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=tylozrC4jRLNMyfhfyX9uhpvHm3IFTabW2jea6wTrEo=; b=LSifDD/fhAdqoVnSqkEuf7aUZUc/tMTgCvi7uPCjeLfTA142/DgnXD+x m9tldialF+ICX7zRqLVq6sAPpEXNA+NJzPcD0TwXuVSIxvqYdU4wr/zZW CLaoGjB7an+dFZtPIdRXJUQlIh98dW8F+B6gTGepc9s0pMi1fNnqlppHk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAAJr/pk6tJXHA/2dsb2JhbABDgk2XCo9DgQWBbgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGp1bAZ53h3VhBIgGkTmMRw X-IronPort-AV: E=Sophos;i="4.69,405,1315180800"; d="scan'208,217";a="30919423" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 25 Oct 2011 18:29:34 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9PITXx8014318; Tue, 25 Oct 2011 18:29:33 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 13:29:32 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9344.0A426968" Date: Tue, 25 Oct 2011 13:29:31 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FE04B@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyTP0kLb4rQ6LLgQLWRbIm1m+m1owAA/qAg References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , X-OriginalArrivalTime: 25 Oct 2011 18:29:32.0896 (UTC) FILETIME=[0A6E4600:01CC9344] Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 18:29:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9344.0A426968 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CableLabs will not do so. Also as I have said in the past to this mailer that the reason ND Proxy was defeated because an RA Proxy would also be needed with a single /64. A Standards Track RFC does not exist for RA Proxy. Also, it's not for lack of trying - there are issues with ND Proxy or a RA Proxy that could not be solved till now. See emails Erik Nordmark sent to 6man on ND Proxy in the past year or two. =20 Also, why ask the question "what if a cellphone operator allocated a /64 to a phone". I already said, vendors have agreed to use the RFC 3633 PD. =20 =20 Cheers, =20 Hemant =20 From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, October 25, 2011 1:48 PM To: homenet@ietf.org Group Subject: Re: [homenet] routing requirements =20 On Oct 24, 2011, at 10:22 PM, Lorenzo Colitti wrote: =20 If a cell phone operator gives you a single /64, what do you propose to do? =20 If a certain CableLabs MSO gives each of its several tens of millions of Internet users in North America only a single /64, what do we propose to do? =20 -- james woodyatt member of technical staff, core os networking =20 ------_=_NextPart_001_01CC9344.0A426968 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                    CableLabs will not do so.   Also as I have said in the past = to this mailer that the reason ND Proxy was defeated because an RA Proxy = would also be needed with a single /64.   A Standards Track = RFC does not exist for RA Proxy.   Also, it’s not for = lack of trying – there are issues with ND Proxy or a RA Proxy that = could not be solved till now.  See emails Erik Nordmark sent to = 6man on ND Proxy in the past year or two.

                     

                    Also, why ask the question “what if a cellphone operator = allocated a /64 to a phone”.  I already said, vendors have = agreed to use the RFC 3633 PD.  

                     

                    Cheers,

                     

                    Hemant

                     

                    From:= = homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of james woodyatt
                    Sent: Tuesday, October 25, 2011 1:48 = PM
                    To: homenet@ietf.org Group
                    Subject: Re: [homenet] = routing requirements

                     

                    On = Oct 24, 2011, at 10:22 PM, Lorenzo Colitti = wrote:

                     

                    If a = cell phone operator gives you a single /64, what do you propose to = do?

                     

                    If a certain CableLabs MSO gives each of its several = tens of millions of Internet users in North America only a single /64, = what do we propose to do?

                     


                    --

                    james = woodyatt <jhw@apple.com><= /o:p>

                    member= of technical staff, core os networking<= /o:p>


                     

                    ------_=_NextPart_001_01CC9344.0A426968-- From jhw@apple.com Tue Oct 25 11:34:34 2011 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 A707221F8C30 for ; Tue, 25 Oct 2011 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8EBnhiSXznQ for ; Tue, 25 Oct 2011 11:34:34 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0672721F8500 for ; Tue, 25 Oct 2011 11:34:34 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_biAs3XUBsljdcFfR/GTWag)" Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LTM00C0RWXEU8X1@mail-out.apple.com> for homenet@ietf.org; Tue, 25 Oct 2011 11:34:33 -0700 (PDT) X-AuditID: 11807137-b7c56ae0000051ed-7b-4ea70138f1e8 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id A0.77.20973.83107AE4; Tue, 25 Oct 2011 11:34:32 -0700 (PDT) From: james woodyatt Date: Tue, 25 Oct 2011 11:34:33 -0700 In-reply-to: To: "homenet@ietf.org Group" References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> Message-id: <96700997-BCB4-49C6-B281-F55B89515CC3@apple.com> X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUieJDvpq4F43I/gw3LzC3eLzrE4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJvXnzAVPNKpePzqPUsD4xm1LkYODgkBE4m2VfFdjJxAppjE hXvr2UBsIYEVTBJPPquC2GwCKhLfLt9lArF5BYwl1tx6xwJiMwskSLz8+JodxBYW0Jbo+b8E rJdFQFVixfSXrCA2p0CgxKfZs8F6RQT0JZ4e+QVUwwU0/zqbxOaGZ2wQQ20kTp3vY4U4Ql6i 5esdtgmMvLOQ7JuFZB+ErS2xbOFrZgjbQOJp5ytWTHF9iTfv5jAtYGRbxShYlJqTWGloppdY UJCTqpecn7uJERR4DYXmOxi3/5U7xCjAwajEw1v4ZZmfEGtiWXFl7iFGCQ5mJRHe1hNAId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rxrDRb7CQmkJ5akZqemFqQWwWSZODilGhgnsc41tXXRfv+T 8dyf5usHj0VaLZu8e6nuh/6TYkdnn+yfJWoksOtu8AGX801PkmqYXP0Ttn593rzWyzVR5oRv R6LIStavggGl60zfnH4h2tZ+tnnGmuucUiUNH6qjeE1V2Kf/4+NckPZjQlGXou+sJ9syz1yp FgrkMxb3Sg3qc1KJjhHtXqHEUpyRaKjFXFScCACi6/ExOAIAAA== Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 18:34:34 -0000 --Boundary_(ID_biAs3XUBsljdcFfR/GTWag) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Oct 25, 2011, at 11:13 AM, Lorenzo Colitti wrote: >=20 > Coping with firewalls is easier than coping with NATs, because at = least you know your public IP address. Yeah, but you're still going to have to use PCP to acquire explicit maps = in the firewall state for your public addresses=97 because implicit maps = alone aren't good enough=97 and PCP will tell you your external = addresses if there is NAPT66 gateway in the loop. It was expressly = designed for support NAPT66, so why not use it for that? Besides, applications in the IPv4 world are already coping with NAPT44, = so adapting to NAPT66 will be a straightforward transition for them. = Wouldn't it be nice for application developers to not have to deal with = privacy addressing and multiple provider prefixes and lions and tigers = and bears, oh my? Yes, I realize that means that application content = providers with big global data centers won't be able to directly address = every little sensor device in every home network on the planet, but I'm = actually very mindful that some people consider that a desirable feature = of network address translation despite what RFC 4864 says on the = subject. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_biAs3XUBsljdcFfR/GTWag) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
                    Coping with = firewalls is easier than coping with NATs, because at least you know = your public IP = address.

                    Yeah, but you're = still going to have to use PCP to acquire explicit maps in the firewall = state for your public addresses=97 because implicit maps alone aren't = good enough=97 and PCP will tell you your external addresses if there is = NAPT66 gateway in the loop.  It was expressly designed for support = NAPT66, so why not use it for that?

                    Besides, = applications in the IPv4 world are already coping with NAPT44, so = adapting to NAPT66 will be a straightforward transition for them. =  Wouldn't it be nice for application developers to not have to deal = with privacy addressing and multiple provider prefixes and lions and = tigers and bears, oh my?  Yes, I realize that means that = application content providers with big global data centers won't be able = to directly address every little sensor device in every home network on = the planet, but I'm actually very mindful that some people consider that = a desirable feature of network address translation despite what RFC 4864 = says on the subject.


                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_biAs3XUBsljdcFfR/GTWag)-- From cb.list6@gmail.com Tue Oct 25 11:44:27 2011 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 53DD011E809C for ; Tue, 25 Oct 2011 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+cePWxIYEtf for ; Tue, 25 Oct 2011 11:44:26 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2A9911E809A for ; Tue, 25 Oct 2011 11:44:26 -0700 (PDT) Received: by vws5 with SMTP id 5so927578vws.31 for ; Tue, 25 Oct 2011 11:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wbDHCKfF7qLygdbnwmulmQL6qJLKuKcrBcqeTiAY500=; b=H1kaCabhv1FIy1sEF8Mh+I031vfHQFA1DhVY/aM/IA61JJ6subfhhTUeF9VoyXT22x 9HRLaHsylFgrL8QXOT2MPEOSN6suyDTTI4T+rBDEo2iTYaK7lU8uqYr9f9kPGRw5sDL2 uarJa2AbLXiBFsYSZFLCpzLzTpP+tw3dw3zO4= MIME-Version: 1.0 Received: by 10.68.44.168 with SMTP id f8mr54772588pbm.11.1319568265821; Tue, 25 Oct 2011 11:44:25 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Tue, 25 Oct 2011 11:44:25 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FE04B@XMB-RCD-109.cisco.com> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FE04B@XMB-RCD-109.cisco.com> Date: Tue, 25 Oct 2011 11:44:25 -0700 Message-ID: From: Cameron Byrne To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 18:44:27 -0000 On Tue, Oct 25, 2011 at 11:29 AM, Hemant Singh (shemant) wrote: > CableLabs will not do so. =A0=A0Also as I have said in the past to this m= ailer > that the reason ND Proxy was defeated because an RA Proxy would also be > needed with a single /64.=A0=A0 A Standards Track RFC does not exist for = RA > Proxy.=A0=A0 Also, it=92s not for lack of trying =96 there are issues wit= h ND Proxy > or a RA Proxy that could not be solved till now.=A0 See emails Erik Nordm= ark > sent to 6man on ND Proxy in the past year or two. > > > > Also, why ask the question =93what if a cellphone operator allocated a /6= 4 to > a phone=94.=A0 I already said, vendors have agreed to use the RFC 3633 PD= . > http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps-08#section-5.3 Expect to see ND Proxy from mobile networks. I am not saying it is good or bad for HomeNet, i am just saying the mobile phones will do this... it is homenet's decision how to use it as access to the mobile network and Internet Cameron > > > Cheers, > > > > Hemant > > > > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behal= f > Of james woodyatt > Sent: Tuesday, October 25, 2011 1:48 PM > To: homenet@ietf.org Group > > Subject: Re: [homenet] routing requirements > > > > On Oct 24, 2011, at 10:22 PM, Lorenzo Colitti wrote: > > > > If a cell phone operator gives you a single /64, what do you propose to d= o? > > > > If a certain CableLabs MSO gives each of its several tens of millions of > Internet users in North America only a single /64, what do we propose to = do? > > > > -- > > james woodyatt > > member of technical staff, core os networking > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > From lorenzo@google.com Tue Oct 25 12:05:32 2011 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 BCD8411E80A6 for ; Tue, 25 Oct 2011 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.779 X-Spam-Level: X-Spam-Status: No, score=-105.779 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byAy1JQClJpm for ; Tue, 25 Oct 2011 12:05:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 062D011E809A for ; Tue, 25 Oct 2011 12:05:31 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p9PJ5UDS028802 for ; Tue, 25 Oct 2011 12:05:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319569531; bh=gZhq+u9mq2moVHn67vXUv19jd5E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=yakOv9kQhnBxoH/HBg69u4ZbBvVe1IyWE1VIhLVZ0jYGgsoojwI9qMUNfPEyuT36p gG3bMnmIvIWKG5bGZSfMw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=jOfymhSbbQUrzlvIAEw7TmridS1R+ErORd77sJEqjrWJKf+SRUKklin8H1Oh9EVsm pBi0wne+EejdFqwvQyUZQ== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by wpaz17.hot.corp.google.com with ESMTP id p9PIuTAt025109 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 12:05:29 -0700 Received: by gyc15 with SMTP id 15so1102433gyc.5 for ; Tue, 25 Oct 2011 12:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=aAGsiiN9OS5ig2R4uqm9zWqrs+4+hEREelohcdApTHs=; b=Z3u6we6X70ST2fgNwWkUlY6DD3b8lpLRySxtVdtk0Xixd1EruXuplqtT1NFPioG5i9 3Cpq7msWNsvF7AJwJ1KQ== Received: by 10.150.218.11 with SMTP id q11mr26586004ybg.105.1319569529337; Tue, 25 Oct 2011 12:05:29 -0700 (PDT) Received: by 10.150.218.11 with SMTP id q11mr26585986ybg.105.1319569529157; Tue, 25 Oct 2011 12:05:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 25 Oct 2011 12:05:08 -0700 (PDT) In-Reply-To: <96700997-BCB4-49C6-B281-F55B89515CC3@apple.com> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <96700997-BCB4-49C6-B281-F55B89515CC3@apple.com> From: Lorenzo Colitti Date: Tue, 25 Oct 2011 12:05:08 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=000e0cd1f86e0aba3b04b02439e4 X-System-Of-Record: true Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 19:05:32 -0000 --000e0cd1f86e0aba3b04b02439e4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 25, 2011 at 11:34, james woodyatt wrote: > Yes, I realize that means that application content providers with big > global data centers won't be able to directly address every little sensor > device in every home network on the planet > Actually, that's not what it means. It means that you won't be able to address a device in your own home without paying someone with a datacenter. --000e0cd1f86e0aba3b04b02439e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
                    On Tue, Oct 25, 2011 at 11:34, james woodyatt <jhw@apple.com><= /span> wrote:
                    Yes, I real= ize that means that application content providers with big global data cent= ers won't be able to directly address every little sensor device in eve= ry home network on the planet

                    Actually, that's not= what it means. It means that you won't be able to address a device in = your own home without paying someone with a datacenter.
                    --000e0cd1f86e0aba3b04b02439e4-- From lee.howard@twcable.com Tue Oct 25 13:06:45 2011 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 A1A201F0C69 for ; Tue, 25 Oct 2011 13:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCrYCDWjaInh for ; Tue, 25 Oct 2011 13:06:43 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8E60A1F0C65 for ; Tue, 25 Oct 2011 13:06:43 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,404,1315195200"; d="scan'208,217";a="289537487" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Oct 2011 16:02:51 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 25 Oct 2011 16:06:40 -0400 From: "Howard, Lee" To: james woodyatt , "homenet@ietf.org Group" Date: Tue, 25 Oct 2011 16:06:40 -0400 Thread-Topic: [homenet] routing requirements Thread-Index: AcyTRMFZhwKM/5WeT4mtxuqfO1kGYwAC/uJg Message-ID: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <96700997-BCB4-49C6-B281-F55B89515CC3@apple.com> In-Reply-To: <96700997-BCB4-49C6-B281-F55B89515CC3@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD465693779145148840DPRVPEXVS03cor_" MIME-Version: 1.0 Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 20:06:45 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD465693779145148840DPRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of james woodyatt Sent: Tuesday, October 25, 2011 2:35 PM To: homenet@ietf.org Group Subject: Re: [homenet] routing requirements On Oct 25, 2011, at 11:13 AM, Lorenzo Colitti wrote: Coping with firewalls is easier than coping with NATs, because at least you= know your public IP address. Yeah, but you're still going to have to use PCP to acquire explicit maps in= the firewall state for your public addresses- because implicit maps alone = aren't good enough- and PCP will tell you your external addresses if there = is NAPT66 gateway in the loop. It was expressly designed for support NAPT6= 6, so why not use it for that? Because it's hard. Application developers then have to figure out how to u= se information provided by PCP. Besides, applications in the IPv4 world are already coping with NAPT44, so = adapting to NAPT66 will be a straightforward transition for them. Wouldn't= it be nice for application developers to not have to deal with privacy add= ressing and multiple provider prefixes and lions and tigers and bears, oh m= y? Yes, I realize that means that application content providers with big g= lobal data centers won't be able to directly address every little sensor de= vice in every home network on the planet, but I'm actually very mindful tha= t some people consider that a desirable feature of network address translat= ion despite what RFC 4864 says on the subject. What's hard about privacy addressing? Does the multiple prefix problem get easier with ULA plus GUA? Or are you = saying we should forget GUA altogether-since one ISP in one place threatens= to use /64 by default, nobody can use GUA? Are lions, tigers and bears significant threats in home networks? Lee -- james woodyatt > member of technical staff, core os networking ________________________________ 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. --_000_DCC302FAA9FE5F4BBA4DCAD465693779145148840DPRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                     =

                     =

                    From: homenet-= bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of james woodyatt
                    Sent: Tuesday, October 25, 2011 2:35 PM
                    To: homenet@ietf.org Group
                    Subject: Re: [homenet] routing requirements

                     

                    On Oct 25, 2011, at 11:13 AM, Lorenzo Colitti wrote:=

                     

                    Copi= ng with firewalls is easier than coping with NATs, because at least you kno= w your public IP address.

                     

                    Yeah, but you're still goi= ng to have to use PCP to acquire explicit maps in the firewall state for yo= ur public addresses— because implicit maps alone aren't good enough— and PCP will tell you your external addresses if there is NA= PT66 gateway in the loop.  It was expressly designed for support NAPT6= 6, so why not use it for that?

                     =

                    Because it’s hard.=   Application developers then have to figure out how to use informatio= n provided by PCP.

                     

                    Besides, applications in t= he IPv4 world are already coping with NAPT44, so adapting to NAPT66 will be= a straightforward transition for them.  Wouldn't it be nice for application developers to not have to deal with privacy addressing and= multiple provider prefixes and lions and tigers and bears, oh my?  Ye= s, I realize that means that application content providers with big global = data centers won't be able to directly address every little sensor device in every home network on the planet, bu= t I'm actually very mindful that some people consider that a desirable feat= ure of network address translation despite what RFC 4864 says on the subjec= t.

                     =

                    What’s hard about = privacy addressing? 

                    Does the multiple prefix= problem get easier with ULA plus GUA?  Or are you saying we should fo= rget GUA altogether—since one ISP in one place threatens to use /64 b= y default, nobody can use GUA?

                    Are lions, tigers and be= ars significant threats in home networks?

                     =

                    Lee


                    --

                    j= ames woodyatt <jhw@apple.com>

                    m= ember of technical staff, core os networking



                     


                    This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
                     --_000_DCC302FAA9FE5F4BBA4DCAD465693779145148840DPRVPEXVS03cor_-- From jhw@apple.com Tue Oct 25 14:06:33 2011 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 88B2D21F8AF0 for ; Tue, 25 Oct 2011 14:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3hEwmjh2saL for ; Tue, 25 Oct 2011 14:06:32 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id A69D821F85D1 for ; Tue, 25 Oct 2011 14:06:32 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_f1hAEl9XvOKAe5z0A05GeQ)" Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LTN00K593WHVA11@mail-out.apple.com> for homenet@ietf.org; Tue, 25 Oct 2011 14:06:32 -0700 (PDT) X-AuditID: 11807134-b7cc1ae0000078f0-68-4ea724d77dd6 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 5F.20.30960.7D427AE4; Tue, 25 Oct 2011 14:06:31 -0700 (PDT) From: james woodyatt Date: Tue, 25 Oct 2011 14:06:30 -0700 In-reply-to: To: "homenet@ietf.org Group" References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <96700997-BCB4-49C6-B281-F55B89515CC3@apple.com> Message-id: X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUieJDvpu51leV+Bke/6lq8X3SIxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGZ0X/zEW9NZXnPs1mbGBcXlOFyMnh4SAicStEy8YIWwxiQv3 1rN1MXJxCAmsYJK4+OciK0iCTUBF4tvlu0wgNq+AscSaW+9Yuhg5OJgFEiTmzHIFCQsLaEv0 /F/CBhJmEVCVmLfTBCTMKRAqcfoASJiTQ0RAX+LpkV9Q4y+yS6zb2w010kbiW9MKNogb5CVa vt5hm8DIOwvJtlkI20DCzEDbli18zQxhG0g87XzFiimuL/Hm3RymBYxsqxgFi1JzEisNTfQS CwpyUvWS83M3MYLCrqHQZAfjwZ/8hxgFOBiVeHhPflvmJ8SaWFZcmXuIUYKDWUmEt/UEUIg3 JbGyKrUoP76oNCe1+BCjNAeLkjjvaoPFfkIC6YklqdmpqQWpRTBZJg5OqQZG3+XH70sfXG3y 1sjS+1bDbqXw7u5PhsLq5763iFzfZH6tq0jHpnrut3XV63jYjs2svf5k+v3adAHtD2x7iyve myUvCJ5p+/y/3cw7k/rNtpc5J/JbMAf3qvxh/6G/rCbb48n0RP7mkDyn+wX/zXvNf5omaliy /jp64czB+X9Y7s28svFvppWVEktxRqKhFnNRcSIATNf4zjcCAAA= Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 21:06:33 -0000 --Boundary_(ID_f1hAEl9XvOKAe5z0A05GeQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Oct 25, 2011, at 1:06 PM, Howard, Lee wrote: > Because it=92s hard. Application developers then have to figure out = how to use information provided by PCP. They already have to do that for the purpose of maintaining continuity = of operations with IPv4 when NAT444 and DS-Lite networks start = overtaking the current deployment model of publicly numbered NAT44 = gateways. They're going to be required to do that for native IPv6 after = IPv4 continuity is no longer required, because [AGAIN, I don't = understand why nobody seems to get this] CPE gateways are going to be = deployed every with IPv6 simple security enabled by default and nobody = anywhere will ever reconfigure their gateway into transparent mode. > What=92s hard about privacy addressing? It means you typically have multiple interface addresses per *prefix*. = A persistent one, e.g. IA_NA, plus zero or one temporary/privacy = addresses, e.g. IA_TA, plus zero, one or more *deprecated* = temporary/privacy addresses, e.g. from SLAAC. > Does the multiple prefix problem get easier with ULA plus GUA? Harder, because now you have multiple global scope prefixes with varying = domains of routing. > Or are you saying we should forget GUA altogether=97since one ISP in = one place threatens to use /64 by default, nobody can use GUA? It's not just one ISP. We have the whole 3GPP ecosystem threatening not = to use DHCP6-PD to delegate prefixes shorter than /64 because, hey, 3GPP = has a built-in system for delegating 64-bit prefixes. What reasonable = subscriber really needs to ask for anything more than a single /64? > Are lions, tigers and bears significant threats in home networks? Metaphorically speaking? Look, my point here is simple, and it's the same point I was making all = those years ago before even the first draft of RFC 6092 was published: = all the lovely wonderful mechanisms that RFC 4864 describes for making = it so you don't have to use NAT with IPv6 are a huge pain in the neck = for application developers. Without a stateful firewall in the way, all = those things RFC 4864 talks about are well worth doing. However, *with* = a stateful firewall in place, they're mostly redundant: the only thing = they buy is network layer addressability at the application layer. = Useless in practice without reachability as well. Alas, RFC 4864 explicitly recommends inserting a firewall. Which is why = we now have RFC 6092 and we will soon have PCP. And why RFC 6204 = explicitly references RFC 6092, and its forthcoming update will cite the = PCP specification. And why various procurement documents will be citing = both of them as requirements. Indeed, that was the whole point behind = writing RFC 6092 as a template for a requirement specification. We knew = it would be cited like that. We WANTED that to happen. I happen to be in the IETF minority who thinks that if we're going to = make application developers jump through all the same hoops that NAPT = makes them jump through, plus make them put up with a lot of = *additional* crazy stuff, i.e. the lions, tigers and bears, which you = need because there isn't a NAT providing a unified private address = realm, then we shouldn't be surprised that application developers decide = that IPv6 is crazy, that we proponents don't know what we're doing, and = that they shouldn't want to have anything to do with IPv6 if it can be = helped at all. In my experience, most applications developers look at all those lions, = tigers and bears, and they say, "Why is all this stuff even necessary? = Can't we just have one address per interface and use a NAPT like we're = already used to doing?" I'm very sympathetic to them, and at this point, I'm out of convincing = reasons to disagree. Those ubiquitous non-managed default-enabled firewalls everywhere will = be enough to force us all to do STUN/TURN/ICE and PCP and all that. I'm = not *advocating*, I'm just saying it's how the emerging reality looks to = be taking form. We should just assume it's going to be there, and spec = accordingly. This is where I say, "I told you so," again. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_f1hAEl9XvOKAe5z0A05GeQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
                    Because it=92s = hard.  Application developers then have to figure out how to use = information provided by PCP.
                    What=92s hard about = privacy = addressing?

                    It means = you typically have multiple interface addresses per *prefix*.  A = persistent one, e.g. IA_NA, plus zero or one temporary/privacy = addresses, e.g. IA_TA, plus zero, one or more *deprecated* = temporary/privacy addresses, e.g. from SLAAC.

                    Or are you saying we = should forget GUA altogether=97since one ISP in one place threatens to = use /64 by default, nobody can use = GUA?

                    It's not just = one ISP.  We have the whole 3GPP ecosystem threatening not to use = DHCP6-PD to delegate prefixes shorter than /64 because, hey, 3GPP has a = built-in system for delegating 64-bit prefixes.  What reasonable = subscriber really needs to ask for anything more than a single = /64?


                    I'm very = sympathetic to them, and at this point, I'm out of convincing reasons to = disagree.

                    Those ubiquitous non-managed = default-enabled firewalls everywhere will be enough to force us all to = do STUN/TURN/ICE and PCP and all that. I'm not *advocating*, I'm just = saying it's how the emerging reality looks to be taking form.  We = should just assume it's going to be there, and spec = accordingly.

                    This is where I say, "I told you = so," again.


                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_f1hAEl9XvOKAe5z0A05GeQ)-- From shemant@cisco.com Tue Oct 25 14:14:59 2011 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 561321F0C5A for ; Tue, 25 Oct 2011 14:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOh+RpdfMezQ for ; Tue, 25 Oct 2011 14:14:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B6FB21F0C58 for ; Tue, 25 Oct 2011 14:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=867; q=dns/txt; s=iport; t=1319577298; x=1320786898; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=E7meGGRCtT3fYrYoSOxy4XgIqnYpzOK9uITYLj90yKM=; b=ft9Vddvn9YbrCwRnY7o6jeSKJgNw5+ILQjafSYZqa4IuhVmNtxWcEpIF NZvmEZpfLkLbmLr7o7blkb69bIzbeZ3XomhEnw//8VU647xQ1VILH2v2F c3GEZnbbj+gp3FGdLjlcy8dd06WN4QsC/rlBubd5Y8CfKXiWtu407/qDy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAMYlp06tJXG8/2dsb2JhbABCmWCPQ4EFgW4BAQEEEgEdCj8MBAIBCA4DBAEBCwYXAQYBICUJCAEBBBMIGodmlWwBnmaHdWEEiAaROYUAh0c X-IronPort-AV: E=Sophos;i="4.69,405,1315180800"; d="scan'208";a="30959184" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2011 21:14:58 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9PLEwms015418; Tue, 25 Oct 2011 21:14:58 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 16:14:58 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 16:14:57 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6611@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyTRh+EU6eXy9yPSTaOc7hxT5C5vAAFEXeA References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FE04B@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Cameron Byrne" X-OriginalArrivalTime: 25 Oct 2011 21:14:58.0074 (UTC) FILETIME=[264C3FA0:01CC935B] Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 21:14:59 -0000 Cameron, -----Original Message----- From: Cameron Byrne [mailto:cb.list6@gmail.com]=20 Sent: Tuesday, October 25, 2011 2:44 PM To: Hemant Singh (shemant) Cc: james woodyatt; homenet@ietf.org Subject: Re: [homenet] routing requirements >http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps-08#section-5.3 >Expect to see ND Proxy from mobile networks. Thanks much for the reference. But the reference is still an I-D and not RFC. RFC 4389 is on Experimental Track. One reason this document could be gated in the IESG or IETF Last Call is by folks saying "you have asked for ND Proxy" but there is no Standards Track RFC that specifies an ND Proxy. My personal belief is to never enforce any specific tech on anyone. Let folks use whatever they want to use. However, we have to see what is technically feasible or not. Regards, Hemant From cb.list6@gmail.com Tue Oct 25 14:24:32 2011 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 83AF721F87D6 for ; Tue, 25 Oct 2011 14:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=1.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7su0W5vMbXAP for ; Tue, 25 Oct 2011 14:24:31 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id A90FC21F86F6 for ; Tue, 25 Oct 2011 14:24:31 -0700 (PDT) Received: by pzk34 with SMTP id 34so2484401pzk.9 for ; Tue, 25 Oct 2011 14:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zTWzYBurI5YIg4GXgzsBuc/xbRaUu4zPJET00Z/w3vs=; b=nVrLAi45n+XdnrJX5tuT6S2SLf0DTYKgCbledyeD1n+IjEPudz2hPrgEOH/EMnuHZ/ 1E3/y8cW5YxVpZY+tbAcmeYqm56MaD8ukCKJeEaPPuaY4WL1SutfgSFKoCFgNz7aps6E Ep0tKkenhf39LwkyeP44aRLztQTmHlrBDu15g= MIME-Version: 1.0 Received: by 10.68.199.170 with SMTP id jl10mr60199155pbc.28.1319577871416; Tue, 25 Oct 2011 14:24:31 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Tue, 25 Oct 2011 14:24:31 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6611@XMB-RCD-109.cisco.com> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FE04B@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6611@XMB-RCD-109.cisco.com> Date: Tue, 25 Oct 2011 14:24:31 -0700 Message-ID: From: Cameron Byrne To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 21:24:32 -0000 On Tue, Oct 25, 2011 at 2:14 PM, Hemant Singh (shemant) wrote: > Cameron, > > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Tuesday, October 25, 2011 2:44 PM > To: Hemant Singh (shemant) > Cc: james woodyatt; homenet@ietf.org > Subject: Re: [homenet] routing requirements > >>http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps-08#section-5.3 > >>Expect to see ND Proxy from mobile networks. > > Thanks much for the reference. =A0But the reference is still an I-D and > not RFC. =A0RFC 4389 is on Experimental Track. =A0One reason this documen= t The status does not matter. This I-D adds nothing new, it just puts what's already ratified in the 3GPP and practiced by operators and implementors into IETF speak. The I-D is just for your convenience to understand what is going on in 3GPP and mobile. CB > could be gated in the IESG or IETF Last Call is by folks saying "you > have asked for ND Proxy" but there is no Standards Track RFC that > specifies an ND Proxy. =A0My personal belief is to never enforce any > specific tech on anyone. =A0Let folks use whatever they want to use. > However, we have to see what is technically feasible or not. > > Regards, > > Hemant > From victor.kuarsingh@gmail.com Tue Oct 25 14:40:30 2011 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 792DE11E8097 for ; Tue, 25 Oct 2011 14:40:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VDaUjpz9sIE for ; Tue, 25 Oct 2011 14:40:30 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E198E11E8096 for ; Tue, 25 Oct 2011 14:40:29 -0700 (PDT) Received: by ggnv1 with SMTP id v1so1084590ggn.31 for ; Tue, 25 Oct 2011 14:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=jzNN7qAnT/duKm83eMEmjuH/uR/1SDoH+suXZPf8Y1c=; b=ifZQKqsUvJEtsMojDz87ZwmD44xKt0HiJzxfJ2As/49SfgNfHMk057DkM02Tka4bcN 9049+AiIh/7ks6e5G1/qdyOKZGEMtSde8OclK/KDF+gNpYMts7TEI2xADqCoAmDjgrlH sDUG+E1REdcCT9176F1L6nZ+7u/1SrMuhE3mk= Received: by 10.236.155.74 with SMTP id i50mr43949634yhk.23.1319578829437; Tue, 25 Oct 2011 14:40:29 -0700 (PDT) Received: from [10.158.105.159] ([65.91.55.103]) by mx.google.com with ESMTPS id z28sm40289199yhl.4.2011.10.25.14.40.25 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 14:40:28 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Tue, 25 Oct 2011 14:40:20 -0700 From: Victor Kuarsingh To: Cameron Byrne , "Hemant Singh (shemant)" Message-ID: Thread-Topic: [homenet] routing requirements In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 25 Oct 2011 21:40:30 -0000 >> >> >> >>>http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps-08#section-5.3 >> >>>Expect to see ND Proxy from mobile networks. >> >> Thanks much for the reference. But the reference is still an I-D and >> not RFC. RFC 4389 is on Experimental Track. One reason this document > >The status does not matter. This I-D adds nothing new, it just puts >what's already ratified in the 3GPP and practiced by operators and >implementors into IETF speak. The I-D is just for your convenience to >understand what is going on in 3GPP and mobile. > >CB All, Cameron is noting a very important point. Draft-ietf-v6ops-3gpp-eps-08 is a reflection of existing standards work in the 3GPP. Expect to see real products using functions based on those standards. I think (personally) that it would behoove us to address this. Given the overall growth of Wireline (Cell) endpoints, it will represent a non-trivial number of endpoints to consider - IMHO. Regards, Victor K > >> could be gated in the IESG or IETF Last Call is by folks saying "you >> have asked for ND Proxy" but there is no Standards Track RFC that >> specifies an ND Proxy. My personal belief is to never enforce any >> specific tech on anyone. Let folks use whatever they want to use. >> However, we have to see what is technically feasible or not. >> >> Regards, >> >> Hemant >> >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From lee.howard@twcable.com Wed Oct 26 08:04:53 2011 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 2B01F21F8B5B for ; Wed, 26 Oct 2011 08:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bprTV7uaLuO9 for ; Wed, 26 Oct 2011 08:04:50 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7948021F8B5A for ; Wed, 26 Oct 2011 08:04:49 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,408,1315195200"; d="scan'208,217";a="274750711" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Oct 2011 10:59:10 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 26 Oct 2011 11:03:03 -0400 From: "Howard, Lee" To: james woodyatt , "homenet@ietf.org Group" Date: Wed, 26 Oct 2011 11:03:02 -0400 Thread-Topic: [homenet] routing requirements Thread-Index: AcyTWfzhMBx+PPU2QeqIKiD3zLZu0AAlkAng Message-ID: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <96700997-BCB4-49C6-B281-F55B89515CC3@apple.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: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD465693779145156E609PRVPEXVS03cor_" MIME-Version: 1.0 Subject: Re: [homenet] routing requirements 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, 26 Oct 2011 15:04:53 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD465693779145156E609PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for expanding your arguments. I had not heard them before, so I = could not understand them. I'll think about them some more. Lee From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of james woodyatt Sent: Tuesday, October 25, 2011 5:07 PM To: homenet@ietf.org Group Subject: Re: [homenet] routing requirements On Oct 25, 2011, at 1:06 PM, Howard, Lee wrote: Because it's hard. Application developers then have to figure out how to u= se information provided by PCP. They already have to do that for the purpose of maintaining continuity of o= perations with IPv4 when NAT444 and DS-Lite networks start overtaking the c= urrent deployment model of publicly numbered NAT44 gateways. They're goin= g to be required to do that for native IPv6 after IPv4 continuity is no lon= ger required, because [AGAIN, I don't understand why nobody seems to get th= is] CPE gateways are going to be deployed every with IPv6 simple security e= nabled by default and nobody anywhere will ever reconfigure their gateway i= nto transparent mode. What's hard about privacy addressing? It means you typically have multiple interface addresses per *prefix*. A p= ersistent one, e.g. IA_NA, plus zero or one temporary/privacy addresses, e.= g. IA_TA, plus zero, one or more *deprecated* temporary/privacy addresses, = e.g. from SLAAC. Does the multiple prefix problem get easier with ULA plus GUA? Harder, because now you have multiple global scope prefixes with varying do= mains of routing. Or are you saying we should forget GUA altogether-since one ISP in one plac= e threatens to use /64 by default, nobody can use GUA? It's not just one ISP. We have the whole 3GPP ecosystem threatening not to= use DHCP6-PD to delegate prefixes shorter than /64 because, hey, 3GPP has = a built-in system for delegating 64-bit prefixes. What reasonable subscrib= er really needs to ask for anything more than a single /64? Are lions, tigers and bears significant threats in home networks? Metaphorically speaking? Look, my point here is simple, and it's the same point I was making all tho= se years ago before even the first draft of RFC 6092 was published: all the= lovely wonderful mechanisms that RFC 4864 describes for making it so you d= on't have to use NAT with IPv6 are a huge pain in the neck for application = developers. Without a stateful firewall in the way, all those things RFC 4= 864 talks about are well worth doing. However, *with* a stateful firewall = in place, they're mostly redundant: the only thing they buy is network laye= r addressability at the application layer. Useless in practice without rea= chability as well. Alas, RFC 4864 explicitly recommends inserting a firewall. Which is why we= now have RFC 6092 and we will soon have PCP. And why RFC 6204 explicitly = references RFC 6092, and its forthcoming update will cite the PCP specifica= tion. And why various procurement documents will be citing both of them as = requirements. Indeed, that was the whole point behind writing RFC 6092 as = a template for a requirement specification. We knew it would be cited like= that. We WANTED that to happen. I happen to be in the IETF minority who thinks that if we're going to make = application developers jump through all the same hoops that NAPT makes them= jump through, plus make them put up with a lot of *additional* crazy stuff= , i.e. the lions, tigers and bears, which you need because there isn't a NA= T providing a unified private address realm, then we shouldn't be surprised= that application developers decide that IPv6 is crazy, that we proponents = don't know what we're doing, and that they shouldn't want to have anything = to do with IPv6 if it can be helped at all. In my experience, most applications developers look at all those lions, tig= ers and bears, and they say, "Why is all this stuff even necessary? Can't = we just have one address per interface and use a NAPT like we're already us= ed to doing?" I'm very sympathetic to them, and at this point, I'm out of convincing reas= ons to disagree. Those ubiquitous non-managed default-enabled firewalls everywhere will be e= nough to force us all to do STUN/TURN/ICE and PCP and all that. I'm not *ad= vocating*, I'm just saying it's how the emerging reality looks to be taking= form. We should just assume it's going to be there, and spec accordingly. This is where I say, "I told you so," again. -- james woodyatt > member of technical staff, core os networking ________________________________ 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. --_000_DCC302FAA9FE5F4BBA4DCAD465693779145156E609PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                    Thank you for expanding = your arguments.  I had not heard them before, so I could not understan= d them.

                     =

                    I’ll think about t= hem some more.

                     =

                    Lee

                     =

                    From: homenet-= bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of james woodyatt
                    Sent: Tuesday, October 25, 2011 5:07 PM
                    To: homenet@ietf.org Group
                    Subject: Re: [homenet] routing requirements

                     

                    On Oct 25, 2011, at 1:06 PM, Howard, Lee wrote:=



                    Because it’s hard.=   Application developers then have to figure out how to use informatio= n provided by PCP.

                     

                    They already have to do that for the purpose of main= taining continuity of operations with IPv4 when NAT444 and DS-Lite networks= start overtaking the current deployment model of  publicly numbe= red NAT44 gateways.  They're going to be required to do that for native IPv6 after IPv4 continuity is no longer required, be= cause [AGAIN, I don't understand why nobody seems to get this] CPE gateways= are going to be deployed every with IPv6 simple security enabled by defaul= t and nobody anywhere will ever reconfigure their gateway into transparent mode.



                    What’s hard about = privacy addressing?

                     

                    It means you typically have multiple interface addre= sses per *prefix*.  A persistent one, e.g. IA_NA, plus zero or one tem= porary/privacy addresses, e.g. IA_TA, plus zero, one or more *deprecated* t= emporary/privacy addresses, e.g. from SLAAC.



                    Does the multiple prefix= problem get easier with ULA plus GUA?

                     

                    Harder, because now you have multiple global scope p= refixes with varying domains of routing.



                    Or are you saying we sho= uld forget GUA altogether—since one ISP in one place threatens to use= /64 by default, nobody can use GUA?

                     

                    It's not just one ISP.  We have the whole 3GPP = ecosystem threatening not to use DHCP6-PD to delegate prefixes shorter than= /64 because, hey, 3GPP has a built-in system for delegating 64-bit prefixe= s.  What reasonable subscriber really needs to ask for anything more than a single /64?



                    Are lions, tigers and be= ars significant threats in home networks?

                     

                    Metaphorically speaking?

                     

                    Look, my point here is simple, and it's the same poi= nt I was making all those years ago before even the first draft of RFC 6092= was published: all the lovely wonderful mechanisms that RFC 4864 describes= for making it so you don't have to use NAT with IPv6 are a huge pain in the neck for application developers. =  Without a stateful firewall in the way, all those things RFC 4864 tal= ks about are well worth doing.  However, *with* a stateful firewall in= place, they're mostly redundant: the only thing they buy is network layer addressability at the application layer. &= nbsp;Useless in practice without reachability as well.

                     

                    Alas, RFC 4864 explicitly recommends inserting a fir= ewall.  Which is why we now have RFC 6092 and we will soon have PCP. &= nbsp;And why RFC 6204 explicitly references RFC 6092, and its forthcoming u= pdate will cite the PCP specification. And why various procurement documents will be citing both of them as requirements.=  Indeed, that was the whole point behind writing RFC 6092 as a templa= te for a requirement specification.  We knew it would be cited like th= at.  We WANTED that to happen.

                     

                    I happen to be in the IETF minority who thinks that = if we're going to make application developers jump through all the same hoo= ps that NAPT makes them jump through, plus make them put up with a lot of *= additional* crazy stuff, i.e. the lions, tigers and bears, which you need because there isn't a NAT providin= g a unified private address realm, then we shouldn't be surprised that appl= ication developers decide that IPv6 is crazy, that we proponents don't know= what we're doing, and that they shouldn't want to have anything to do with IPv6 if it can be helped at all= .

                     

                    In my experience, most applications developers look = at all those lions, tigers and bears, and they say, "Why is all this s= tuff even necessary?  Can't we just have one address per interface and= use a NAPT like we're already used to doing?"

                     

                    I'm very sympathetic to them, and at this point, I'm= out of convincing reasons to disagree.

                     

                    Those ubiquitous non-managed default-enabled firewal= ls everywhere will be enough to force us all to do STUN/TURN/ICE and PCP an= d all that. I'm not *advocating*, I'm just saying it's how the emerging rea= lity looks to be taking form.  We should just assume it's going to be there, and spec accordingly.

                     

                    This is where I say, "I told you so," agai= n.

                     


                    --

                    j= ames woodyatt <jhw@apple.com>

                    m= ember of technical staff, core os networking



                     


                    This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
                     --_000_DCC302FAA9FE5F4BBA4DCAD465693779145156E609PRVPEXVS03cor_-- From Laurent.Toutain@telecom-bretagne.eu Wed Oct 26 08:42:16 2011 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 61BD221F8726 for ; Wed, 26 Oct 2011 08:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5beLpX+S1aZ for ; Wed, 26 Oct 2011 08:42:15 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4F21F86FF for ; Wed, 26 Oct 2011 08:42:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id p9QFgCv1032444 for ; Wed, 26 Oct 2011 17:42:12 +0200 Received: from courrier.enst-bretagne.fr (smtps.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id p9QFg4Fg032374 for ; Wed, 26 Oct 2011 17:42:07 +0200 Received: from mail-ww0-f44.google.com (passerelle-interne.enst-bretagne.fr [192.108.117.210]) (user=toutain mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id p9QFfxkT013431 for ; Wed, 26 Oct 2011 17:41:59 +0200 Received: by wwe6 with SMTP id 6so1884207wwe.13 for ; Wed, 26 Oct 2011 08:41:59 -0700 (PDT) Received: by 10.216.200.82 with SMTP id y60mr746689wen.71.1319643719205; Wed, 26 Oct 2011 08:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.182.81 with HTTP; Wed, 26 Oct 2011 08:41:38 -0700 (PDT) In-Reply-To: <4EA6C1C4.7050609@piuha.net> References: <4EA6C1C4.7050609@piuha.net> From: Laurent Toutain Date: Wed, 26 Oct 2011 17:41:38 +0200 Message-ID: To: Jari Arkko Content-Type: multipart/alternative; boundary=0016e6dab59e1d022404b0357fdc X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (coliposte.enst-bretagne.fr [192.108.115.12]); Wed, 26 Oct 2011 17:42:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Guillaume Chelius , "homenet@ietf.org" , Acee Lindem , BINET David RD-CORE-CAE Subject: Re: [homenet] a few drafts... 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, 26 Oct 2011 15:42:16 -0000 --0016e6dab59e1d022404b0357fdc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jari, I'm very please to see that this idea is coming back, we proposed some similar ideas several years ago in the late zerouter WG. ftp://ftp.utl.pt/rfc/ftp.isi.edu/internet-drafts/draft-chelius-router-autoc= onf-00.txt. We also published some papers to study performances for SID allocation ( http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf). The good news is if you have a /60 and need to allocate 15 prefixes, it can be done in 3 rounds. Laurent On Tue, Oct 25, 2011 at 16:03, Jari Arkko wrote: > Here's a couple of drafts inspired by discussions from the interim meetin= g: > > http://tools.ietf.org/html/**draft-acee-ospf-ospfv3-**autoconfig-00.txt > > OSPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This document > describes the necessary mechanisms for OSPFv3 to be self-configuring. > > http://tools.ietf.org/html/**draft-arkko-homenet-prefix-** > assignment-00.txt > > This memo describes a prefix assignment mechanism for home networks. > It is expected that home gateway routers are assigned an IPv6 prefix > through DHCPv6 Prefix Delegation (PD). This prefix needs to be > divided among the multiple subnets in a home network. This memo > describes a mechanism for such division via OSPFv3. This is an > alternative design to using DHCPv6 PD also for the prefix assignment. > The memo is input to the working group so that it can make a decision > on which type of design to pursue. It is expected that a routing- > protocol based assignment uses a minimal amount of prefixes. > > Comments appreciated! > > Jari > > ______________________________**_________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/**listinfo/homenet > --=20 Laurent Toutain +--- VoIP (recommended) ---+----------- T=E9l=E9com Bretagne -----------+ | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit : | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http://class.touta.in | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | +--------------------------+----------------------------------------+ --0016e6dab59e1d022404b0357fdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jari,

                    I'm very please to see that this idea is co= ming back, we proposed some similar ideas several years ago in the late zer= outer WG.=A0
                    ftp://ftp.utl.pt/rfc/ftp.isi.= edu/internet-drafts/draft-chelius-router-autoconf-00.txt. We also publi= shed some papers to study performances for SID allocation (http://conferen= ces.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf). The good news is if = you have a /60 and need to allocate 15 prefixes, it can be done in 3 rounds= .=A0

                    Laurent

                    On Tue, Oct 2= 5, 2011 at 16:03, Jari Arkko <jari.arkko@piuha.net> wrote:
                    Here's a couple of drafts inspired by discussions from the interim meet= ing:

                    http://tools.ietf.org/html/draft-acee-ospf-os= pfv3-autoconfig-00.txt

                    =A0 OSPFv3 is a candidate for deployments in environments where auto-
                    =A0 configuration is a requirement. =A0One such environment is the IPv6 =A0 home network where users expect to simply plug in a router and have =A0 it automatically use OSPFv3 for intra-domain routing. =A0This document=
                    =A0 describes the necessary mechanisms for OSPFv3 to be self-configuring.<= br>
                    http://tools.ietf.org/html/draft-arkko-ho= menet-prefix-assignment-00.txt

                    =A0 This memo describes a prefix assignment mechanism for home networks. =A0 It is expected that home gateway routers are assigned an IPv6 prefix =A0 through DHCPv6 Prefix Delegation (PD). =A0This prefix needs to be
                    =A0 divided among the multiple subnets in a home network. =A0This memo
                    =A0 describes a mechanism for such division via OSPFv3. =A0This is an
                    =A0 alternative design to using DHCPv6 PD also for the prefix assignment.<= br> =A0 The memo is input to the working group so that it can make a decision<= br> =A0 on which type of design to pursue. =A0It is expected that a routing- =A0 protocol based assignment uses a minimal amount of prefixes.

                    Comments appreciated!

                    Jari

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



                    --
                    Laurent Tout= ain
                    +--- VoIP (recommend= ed) ---+----------- T=E9l=E9com Bretagne -----------+
                    | Tel: +33 2 22 06= 8156 =A0 =A0| Tel: + 33 2 99 12 7026 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Vis= it :
                    | Fax: +33 2 22 06 8445 =A0 =A0| Fax: +33 2 99 12 7030 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0htt= p://class.touta.in
                    | Laurent@Touta.in =A0 =A0 =A0 =A0 | Laurent.Tout= ain@Telecom-Bretagne.eu =A0 =A0|
                    +--------------------------+----------------------------------------+
                    --0016e6dab59e1d022404b0357fdc-- From wassim.haddad@ericsson.com Wed Oct 26 09:25:48 2011 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 4D6CC21F86C1 for ; Wed, 26 Oct 2011 09:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.202 X-Spam-Level: X-Spam-Status: No, score=-105.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFLoiY1bKgNC for ; Wed, 26 Oct 2011 09:25:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A5B6221F85D1 for ; Wed, 26 Oct 2011 09:25:47 -0700 (PDT) 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 p9QGPGJ6002299 for ; Wed, 26 Oct 2011 11:25:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 26 Oct 2011 12:25:35 -0400 From: Wassim Haddad To: "homenet@ietf.org" Date: Wed, 26 Oct 2011 12:25:41 -0400 Thread-Topic: I-D Action: draft-haddad-homenet-gateway-visibility-00.txt Thread-Index: AcyT++NJtSEkiDUpS6ukUe1stpdtaQ== Message-ID: References: <20111024201837.8598.92335.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-55B4989A-C336-4E64-9E60-A14CA7E08951"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: Joel Halpern , Wassim Haddad Subject: [homenet] Fwd: I-D Action: draft-haddad-homenet-gateway-visibility-00.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, 26 Oct 2011 16:25:48 -0000 --Apple-Mail-55B4989A-C336-4E64-9E60-A14CA7E08951 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-4437941F-6A84-444B-9186-A7B00F9B451E --Apple-Mail-4437941F-6A84-444B-9186-A7B00F9B451E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, A New Internet-Draft is available from the on-line Internet-Drafts directori= es. Title: Ensuring Home Network Visibility to Home Gateway This memo describes a mechanism designed to increase the home gateway visibi= lity on the home network that it is serving. This includes knowledge of all= IPv6 addresses configured using prefixes assigned by the home gateway and advertised by router(s) attached to it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-homenet-gateway-visibility-= 00.txt Your comments are appreciated! Regards, Wassim H. --Apple-Mail-4437941F-6A84-444B-9186-A7B00F9B451E Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+RGVhciBhbGws PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPjxzcGFu Pjwvc3Bhbj48YnI+PHNwYW4+VGl0bGU6IEVuc3VyaW5nIEhvbWUgTmV0d29yayBWaXNpYmlsaXR5 IHRvIEhvbWUgR2F0ZXdheTwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5UaGlzIG1l bW8gZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGRlc2lnbmVkIHRvIGluY3JlYXNlIHRoZSBob21lIGdh dGV3YXkmbmJzcDs8L3NwYW4+PHNwYW4+dmlzaWJpbGl0eSBvbiB0aGUgaG9tZSBuZXR3b3JrIHRo YXQgaXQgaXMgc2VydmluZy4gJm5ic3A7VGhpcyBpbmNsdWRlczwvc3Bhbj48c3Bhbj4mbmJzcDtr bm93bGVkZ2Ugb2YgYWxsIElQdjYgYWRkcmVzc2VzIGNvbmZpZ3VyZWQgdXNpbmcgcHJlZml4ZXMg YXNzaWduZWQgYnk8L3NwYW4+PGJyPjxzcGFuPnRoZSBob21lIGdhdGV3YXkgYW5kIGFkdmVydGlz ZWQgYnkgcm91dGVyKHMpIGF0dGFjaGVkIHRvIGl0Ljwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxi cj48c3Bhbj5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8L3NwYW4+PGJyPjxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhZGRhZC1ob21l bmV0LWdhdGV3YXktdmlzaWJpbGl0eS0wMC50eHQiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnM9InRy dWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSIxIj5odHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYWRkYWQtaG9tZW5ldC1nYXRld2F5LXZpc2liaWxpdHkt MDAudHh0PC9hPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91ciBj b21tZW50cyBhcmUgYXBwcmVjaWF0ZWQhPC9kaXY+PGRpdj48YnI+PGJyPjxkaXY+UmVnYXJkcyw8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pldhc3NpbSBILjwvZGl2PjwvZGl2PjxkaXY+PC9kaXY+ PC9ib2R5PjwvaHRtbD4= --Apple-Mail-4437941F-6A84-444B-9186-A7B00F9B451E-- --Apple-Mail-55B4989A-C336-4E64-9E60-A14CA7E08951 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIENDCCBDAw ggMYoAMCAQICEQDYVPUywOyjtwh/x6nlhfS/MA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMDkxMDI5MTU1 ODU3WhcNMTIxMDI5MTU1ODU0WjBoMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNV2Fzc2lt IEhhZGRhZDEQMA4GA1UEBRMHZXdhc2hhZDEpMCcGCSqGSIb3DQEJARYad2Fzc2ltLmhhZGRhZEBl cmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJnf3T/nroDokwgzv1ob54nr EQ2qce7b8P0j9dhnGFPhfROZzOb8Uuo1MPaSpDLVObZgSisoJ5JU0euu6pVcofmLQPZzdWzooCBa s3Y2tuRtkvFgcZoDKJoo7sorV6yyeRwA+QZpvyS1A7cpsqxjB7jevoXrIFhjs79safz+/Ou/AgMB AAGjggGGMIIBgjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVzdC50ZWxp YS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nzb24/Y2Vy dGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAlBgNVHREEHjAcgRp3YXNzaW0uaGFk ZGFkQGVyaWNzc29uLmNvbTBGBgNVHSAEPzA9MDsGBiqFcGsBATAxMC8GCCsGAQUFBwIBFiNodHRw Oi8vd3d3LmVyaWNzc29uLmNvbS9sZWdhbC5zaHRtbDAdBgNVHQ4EFgQUiY5imSIHErhSp2V+9kdO JARmWScwHwYDVR0jBBgwFoAUlifDuN6lX11EPjlS5UWxdl9jMJswDgYDVR0PAQH/BAQDAgWgMA0G CSqGSIb3DQEBBQUAA4IBAQBIXqbs40JZUFTT/PWl6A0c3S85eU48TVXuwP2wkVhrBUz+45qAo0Yo FV3gDreoDoFGRFlHS5UiID7OUUyY4JJ0BCoqTPU6DGFjruZVNWk6gaL0WiFgqp0ro4CtysRmV1r1 no3JAaVcvZ4Hf7kOx2SxvresNlGlcDqk7eEABucmHNeQdDLCr61Ssrv3/Z6nMlI1IVLydpvqwgB8 7a0tqeejE3+QpTF0mLZWp1YYKz8hYSMX7MyJug372fN3MgWl7KiV0TOPMSn+yJZemwGl3xVmoT7j N/1/J6ApI5bLJrLNUT2UYjnBAyw3RIrzYoMuHJZu9L0f1gBPC8tLC0FsDEjAMYICFTCCAhECAQEw TjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QTAxAhEA2FT1MsDso7cIf8ep5YX0vzAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMjYxNjI1NDNaMCMGCSqGSIb3DQEJBDEWBBTDZK4D MYSWZvlQvb4CrW+5/KNB0DBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQDYVPUywOyjtwh/x6nlhfS/MF8G CyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhEA2FT1MsDso7cIf8ep5YX0vzANBgkqhkiG9w0BAQEFAASBgIoi XKc0231e6PZ4+7jGuogLmu2imobIxqL6h0Byy3Q1AjQYuoYmOT4GbSVRsSam8a9uBspOjkeRivyS Zwd1BHJhynYFQaan250tAG9ZVOGk6cPFtCuDYBVa+rIpyXOH9AKgDFpt5ImQSPhSEg2cDaHAsVAZ JuJ0AnGnfa5BctB7AAAAAAAA --Apple-Mail-55B4989A-C336-4E64-9E60-A14CA7E08951-- From daveoran@orandom.net Wed Oct 26 09:42:13 2011 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 754BE21F8B09 for ; Wed, 26 Oct 2011 09:42:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUd7K4Mi3Uc4 for ; Wed, 26 Oct 2011 09:42:13 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B5321F8AD9 for ; Wed, 26 Oct 2011 09:42:13 -0700 (PDT) Received: from dhcp-161-44-173-115.cisco.com (dhcp-161-44-173-115.cisco.com [161.44.173.115]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9QGgSCq013972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Oct 2011 09:42:28 -0700 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: David R Oran In-Reply-To: Date: Wed, 26 Oct 2011 12:42:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90B01617-3743-4B6A-99D1-F0159BB56331@orandom.net> References: <20111024201837.8598.92335.idtracker@ietfa.amsl.com> To: Wassim Haddad X-Mailer: Apple Mail (2.1251.1) Cc: "homenet@ietf.org" , Joel Halpern Subject: Re: [homenet] Fwd: I-D Action: draft-haddad-homenet-gateway-visibility-00.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, 26 Oct 2011 16:42:13 -0000 On Oct 26, 2011, at 12:25 PM, Wassim Haddad wrote: > Dear all, >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title: Ensuring Home Network Visibility to Home Gateway >=20 > This memo describes a mechanism designed to increase the home gateway = visibility on the home network that it is serving. This includes = knowledge of all IPv6 addresses configured using prefixes assigned by > the home gateway and advertised by router(s) attached to it. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-haddad-homenet-gateway-visibilit= y-00.txt >=20 >=20 > Your comments are appreciated! >=20 The draft says "In such scenario, it can be useful for the HGW(s) to keep track of all IPv6 addresses configured by different types of end devices that get attached to the home network via router(s) connected to the HGW(s)." but give zero justification for WHY it might be useful. I can't think of = any reason at all, but I assume you can but just thought it too obvious = to write down. Could you educate me? Thanks,=20 DaveO. =20 >=20 > Regards, >=20 > Wassim H. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From jari.arkko@piuha.net Wed Oct 26 10:19:49 2011 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 6B3B11F0C38 for ; Wed, 26 Oct 2011 10:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehpZMoT-bvCo for ; Wed, 26 Oct 2011 10:19:48 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 511051F0C34 for ; Wed, 26 Oct 2011 10:19:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 686102CC57; Wed, 26 Oct 2011 20:19:46 +0300 (EEST) 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 vs5r2RsOJbjo; Wed, 26 Oct 2011 20:19:45 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D06562CC54; Wed, 26 Oct 2011 20:19:44 +0300 (EEST) Message-ID: <4EA84130.3070409@piuha.net> Date: Wed, 26 Oct 2011 20:19:44 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Laurent Toutain References: <4EA6C1C4.7050609@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Guillaume Chelius , "homenet@ietf.org" , Acee Lindem , BINET David RD-CORE-CAE Subject: Re: [homenet] a few drafts... 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, 26 Oct 2011 17:19:49 -0000 Thanks for these pointers. We need to take a look at your analysis. It is great to have already some understanding of how well these types of mechanisms work! Jari On 26.10.2011 18:41, Laurent Toutain wrote: > Hi Jari, > > I'm very please to see that this idea is coming back, we proposed some similar ideas several years ago in the late zerouter WG. > ftp://ftp.utl.pt/rfc/ftp.isi.edu/internet-drafts/draft-chelius-router-autoconf-00.txt. We also published some papers to study performances for SID allocation (http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf). The good news is if you have a /60 and need to allocate 15 prefixes, it can be done in 3 rounds. > > Laurent > > On Tue, Oct 25, 2011 at 16:03, Jari Arkko > wrote: > > Here's a couple of drafts inspired by discussions from the interim meeting: > > http://tools.ietf.org/html/draft-acee-ospf-ospfv3-autoconfig-00.txt > > OSPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This document > describes the necessary mechanisms for OSPFv3 to be self-configuring. > > http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-00.txt > > This memo describes a prefix assignment mechanism for home networks. > It is expected that home gateway routers are assigned an IPv6 prefix > through DHCPv6 Prefix Delegation (PD). This prefix needs to be > divided among the multiple subnets in a home network. This memo > describes a mechanism for such division via OSPFv3. This is an > alternative design to using DHCPv6 PD also for the prefix assignment. > The memo is input to the working group so that it can make a decision > on which type of design to pursue. It is expected that a routing- > protocol based assignment uses a minimal amount of prefixes. > > Comments appreciated! > > Jari > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > Laurent Toutain > +--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+ > | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit : > | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http://class.touta.in > | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | > +--------------------------+----------------------------------------+ From mellon@fugue.com Wed Oct 26 18:26:07 2011 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 6875521F841B for ; Wed, 26 Oct 2011 18:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNGkZgg7bQXp for ; Wed, 26 Oct 2011 18:26:07 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0E10921F8319 for ; Wed, 26 Oct 2011 18:26:07 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:64be:2d46:e87d:b53] (unknown [IPv6:2001:470:1f07:1486:64be:2d46:e87d:b53]) by toccata.fugue.com (Postfix) with ESMTPSA id 9F6162381790; Wed, 26 Oct 2011 21:26:03 -0400 (EDT) References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> From: Ted Lemon Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-F346DF37-C2DB-4244-A46A-B8C39E9352EA In-Reply-To: Message-Id: <51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com> Date: Tue, 25 Oct 2011 14:36:32 -0400 To: james woodyatt Mime-Version: 1.0 (1.0) X-Mailer: iPad Mail (9A334) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] routing requirements 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, 27 Oct 2011 01:26:07 -0000 --Apple-Mail-F346DF37-C2DB-4244-A46A-B8C39E9352EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 25, 2011, at 2:00 PM, james woodyatt wrote: > On Oct 25, 2011, at 10:56 AM, Lorenzo Colitti wrote: >>=20 >> Admit defeat and either bridge everything or route longer-than-/64 prefix= es. I hope it won't come to that. >=20 > I would prefer to deploy NAPT66 rather than route prefixes longer than /64= . In fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever= the service provider delegates anything longer than /48, so that we can rou= te /48 prefixes uniformly across the entire home network. I would rather have a bridged /64 than a routed, NATted homenet. In fact, I= think it would have to be a /128 before I'd reign myself to NAT.=20= --Apple-Mail-F346DF37-C2DB-4244-A46A-B8C39E9352EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
                    On Oct 25, 2011, at 2:00 P= M, james woodyatt <jhw@apple.com>= wrote:

                    On O= ct 25, 2011, at 10:56 AM, Lorenzo Colitti wrote:

                    Admit defeat and either bridge everything or route longer-than-/64 p= refixes. I hope it won't come to that.

                    I w= ould prefer to deploy NAPT66 rather than route prefixes longer than /64. &nb= sp;In fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever= the service provider delegates anything longer than /48, so that we can rou= te /48 prefixes uniformly across the entire home network.

                    I would rather have a bridged /64 than a routed, NATted homen= et.  In fact, I think it would have to be a /128 before I'd reign mysel= f to NAT. 
                    = --Apple-Mail-F346DF37-C2DB-4244-A46A-B8C39E9352EA-- From shemant@cisco.com Thu Oct 27 07:44:38 2011 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 B6D9421F8B3B for ; Thu, 27 Oct 2011 07:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFAlUX8QSWzE for ; Thu, 27 Oct 2011 07:44:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CAA0E21F8B45 for ; Thu, 27 Oct 2011 07:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10146; q=dns/txt; s=iport; t=1319726678; x=1320936278; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=I7XcF/bxnYQur+qN5Avb13PcG9yzWa1OWwFlCEJ9Ocs=; b=CHUa6xABSDEtpa8LvqG8am3eOnpOTiYGR2RvLg0Eyyh00L3JbKk/1Y7B LXb9UaRUHx1MY29/P4ehwVorhkU9g3CaDXDTZzrhU/p03C6MXEf0qYF36 CDi1Yp4mUAavjlUYmIW4venXAdTj2dRaauO/8L7w4y5jrqDFBheuIq2Nr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BAGRtqU6tJXG9/2dsb2JhbABCgk2CKpUVjk+BAoEFgXIBAQEEEgEJBwoDSRACAQgOAwQBAQsGFwECAgIBAUQJCAEBBAESCBqeJgGMSpITh2ozYQSIBpE9jEc X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208,217";a="31392599" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 27 Oct 2011 14:44:30 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9REiUas021742; Thu, 27 Oct 2011 14:44:30 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 09:44:29 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC94B6.EE97B4BF" Date: Thu, 27 Oct 2011 09:44:28 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com> In-Reply-To: <51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyUR2kgocM748trRj+3roMZdUTbYAAbvoMw References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com> From: "Hemant Singh (shemant)" To: "Ted Lemon" , "james woodyatt" X-OriginalArrivalTime: 27 Oct 2011 14:44:29.0711 (UTC) FILETIME=[EEBB41F0:01CC94B6] Cc: homenet@ietf.org Subject: Re: [homenet] routing requirements 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, 27 Oct 2011 14:44:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC94B6.EE97B4BF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IA0KDQogDQoNCkZyb206IGhvbWVuZXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmhvbWVuZXQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogVHVlc2RheSwg T2N0b2JlciAyNSwgMjAxMSAyOjM3IFBNDQpUbzogamFtZXMgd29vZHlhdHQNCkNjOiBob21lbmV0 QGlldGYub3JnIEdyb3VwDQpTdWJqZWN0OiBSZTogW2hvbWVuZXRdIHJvdXRpbmcgcmVxdWlyZW1l bnRzDQoNCiANCg0KPkkgd291bGQgcmF0aGVyIGhhdmUgYSBicmlkZ2VkIC82NCB0aGFuIGEgcm91 dGVkLCBOQVR0ZWQgaG9tZW5ldC4gIEluIGZhY3QsIEkgdGhpbmsgaXQgd291bGQgaGF2ZSB0byBi ZSBhIC8xMjggYmVmb3JlIEknZCByZWlnbiBteXNlbGYgdG8gTkFULiANCg0KIA0KDQpXaXRoIGEg YnJpZGdlIGFuZCBhIHRldGhlcmVkIGNlbGwgcGhvbmUsIG15IFBDIGluIHRoZSBob21lIGlzIHNl cnZlZCBmcm9tIHRoZSBXaS1GaSBmcm9tIHRoZSBjZWxsIHBob25lLiAgSSBhbSBkb2luZyB0YXhl cyBvbiB0aGUgbGFwdG9wIGFuZCB0aGUgdGF4IGRhdGEgZ2V0cyBicmlkZ2VkIG91dCB0aGUgY2Vs bHVsYXIgbmV0d29yayB0byB0aGUgU1AuICAgQWRkaXRpb25hbGx5LCBJIGhhdmUgYW4gQXBwbGVU ViBvciBzb21lIGRldmljZSBsaWtlIHRoYXQgd2l0aCBhIFdpLUZpIGxpbmsgdGhhdCBpcyBzZXJ2 ZWQgYnkgdGhlIGNlbGwgcGhvbmUgV2lGaS4gIFdpdGggYnJpZGdpbmcsIGFsbCB0aGUgdmlkZW8g ZGF0YSBvZiB0aGUgVFYgaW4gdGhlIGhvbWUgZ2V0cyBicmlkZ2VkIHRvIHRoZSBTUC4gIA0KDQog DQoNCkhlbWFudA0KDQo= ------_=_NextPart_001_01CC94B6.EE97B4BF Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBs ZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGlu az1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gaG9tZW5ldC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86aG9tZW5ldC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBM ZW1vbjxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAyNSwgMjAxMSAyOjM3IFBNPGJy PjxiPlRvOjwvYj4gamFtZXMgd29vZHlhdHQ8YnI+PGI+Q2M6PC9iPiBob21lbmV0QGlldGYub3Jn IEdyb3VwPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2hvbWVuZXRdIHJvdXRpbmcgcmVxdWlyZW1l bnRzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+Jmd0Ozwvc3Bhbj5JIHdvdWxkIHJhdGhlciBoYXZlIGEgYnJpZGdlZCAv NjQgdGhhbiBhIHJvdXRlZCwgTkFUdGVkIGhvbWVuZXQuICZuYnNwO0luIGZhY3QsIEkgdGhpbmsg aXQgd291bGQgaGF2ZSB0byBiZSBhIC8xMjggYmVmb3JlIEknZCByZWlnbiBteXNlbGYgdG8gTkFU LiZuYnNwOzxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldp dGggYSBicmlkZ2UgYW5kIGEgdGV0aGVyZWQgY2VsbCBwaG9uZSwgbXkgUEMgaW4gdGhlIGhvbWUg aXMgc2VydmVkIGZyb20gdGhlIFdpLUZpIGZyb20gdGhlIGNlbGwgcGhvbmUuIMKgSSBhbSBkb2lu ZyB0YXhlcyBvbiB0aGUgbGFwdG9wIGFuZCB0aGUgdGF4IGRhdGEgZ2V0cyBicmlkZ2VkIG91dCB0 aGUgY2VsbHVsYXIgbmV0d29yayB0byB0aGUgU1AuwqDCoCBBZGRpdGlvbmFsbHksIEkgaGF2ZSBh biBBcHBsZVRWIG9yIHNvbWUgZGV2aWNlIGxpa2UgdGhhdCB3aXRoIGEgV2ktRmkgbGluayB0aGF0 IGlzIHNlcnZlZCBieSB0aGUgY2VsbCBwaG9uZSBXaUZpLsKgIFdpdGggYnJpZGdpbmcsIGFsbCB0 aGUgdmlkZW8gZGF0YSBvZiB0aGUgVFYgaW4gdGhlIGhvbWUgZ2V0cyBicmlkZ2VkIHRvIHRoZSBT UC7CoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhlbWFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CC94B6.EE97B4BF-- From mellon@fugue.com Thu Oct 27 08:13:57 2011 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 6A8FB21F8B24 for ; Thu, 27 Oct 2011 08:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjx-ZWhbmsII for ; Thu, 27 Oct 2011 08:13:56 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3DD21F8B21 for ; Thu, 27 Oct 2011 08:13:56 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:5459:5364:41cb:c151] (unknown [IPv6:2001:470:1f07:1486:5459:5364:41cb:c151]) by toccata.fugue.com (Postfix) with ESMTPSA id D877A2380C8F; Thu, 27 Oct 2011 11:13:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A474101-6C8F-4E24-9808-04CFD13F679C" From: Ted Lemon In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com> Date: Thu, 27 Oct 2011 11:13:53 -0400 Message-Id: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1251.1) Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 27 Oct 2011 15:13:57 -0000 --Apple-Mail=_2A474101-6C8F-4E24-9808-04CFD13F679C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 27, 2011, at 10:44 AM, Hemant Singh (shemant) wrote: > With a bridge and a tethered cell phone, my PC in the home is served = from the Wi-Fi from the cell phone. I am doing taxes on the laptop and = the tax data gets bridged out the cellular network to the SP. = Additionally, I have an AppleTV or some device like that with a Wi-Fi = link that is served by the cell phone WiFi. With bridging, all the = video data of the TV in the home gets bridged to the SP.=20 You are assuming that the /64 is at the provider. In that case I agree = that it could not work, for the very reason you have given. In the = situation you are describing, the provider has not delegated you a /64; = they have merely connected you to their /64. This is a badly broken = configuration: why would anyone do this, particularly for cellular data? --Apple-Mail=_2A474101-6C8F-4E24-9808-04CFD13F679C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii With a bridge and a = tethered cell phone, my PC in the home is served from the Wi-Fi from the = cell phone.  I am doing taxes on the laptop and the tax data gets = bridged out the cellular network to the SP.   Additionally, I = have an AppleTV or some device like that with a Wi-Fi link that is = served by the cell phone WiFi.  With bridging, all the video data = of the TV in the home gets bridged to the = SP. 

                    You are assuming that = the /64 is at the provider.   In that case I agree that it could = not work, for the very reason you have given.   In the situation = you are describing, the provider has not delegated you a /64; they have = merely connected you to their /64.   This is a badly broken = configuration: why would anyone do this, particularly for cellular = data?

                    = --Apple-Mail=_2A474101-6C8F-4E24-9808-04CFD13F679C-- From cb.list6@gmail.com Thu Oct 27 08:32:42 2011 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 A317121F8B92 for ; Thu, 27 Oct 2011 08:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDxz6NJremuo for ; Thu, 27 Oct 2011 08:32:42 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3421F8B8D for ; Thu, 27 Oct 2011 08:32:41 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3247967ggn.31 for ; Thu, 27 Oct 2011 08:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zqjV0NMzbs7+GdhMnukhDDA8QIl5fjoIrxDbKbTeZM4=; b=uxCxZKDI8AfgXcR4xNOVEnpkUfBsGya2Ioc1egv/ZD+m6u9LpSM/W0/TJPJJabOY9k KZ47CpJX0Lop0Ldto62J93T7DCsg/Ru/+pO+UCxTAD5AwTlv/CjR07oaX9uJb5oDGn4d d4VIlSsqo5X0+tW0LIzOW4lwxn+fPnOzfZ8cA= MIME-Version: 1.0 Received: by 10.68.74.132 with SMTP id t4mr46481666pbv.130.1319729561148; Thu, 27 Oct 2011 08:32:41 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 27 Oct 2011 08:32:40 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 27 Oct 2011 08:32:40 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com> References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com> Date: Thu, 27 Oct 2011 08:32:40 -0700 Message-ID: From: Cameron Byrne To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=f46d041b476eb11dbf04b0497bbf Cc: homenet@ietf.org, Ted Lemon , james woodyatt Subject: Re: [homenet] routing requirements 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, 27 Oct 2011 15:32:42 -0000 --f46d041b476eb11dbf04b0497bbf Content-Type: text/plain; charset=ISO-8859-1 On Oct 27, 2011 7:44 AM, "Hemant Singh (shemant)" wrote: > > > > > > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Tuesday, October 25, 2011 2:37 PM > To: james woodyatt > Cc: homenet@ietf.org Group > > Subject: Re: [homenet] routing requirements > > > > >I would rather have a bridged /64 than a routed, NATted homenet. In fact, I think it would have to be a /128 before I'd reign myself to NAT. > > > > With a bridge and a tethered cell phone, my PC in the home is served from the Wi-Fi from the cell phone. I am doing taxes on the laptop and the tax data gets bridged out the cellular network to the SP. Additionally, I have an AppleTV or some device like that with a Wi-Fi link that is served by the cell phone WiFi. With bridging, all the video data of the TV in the home gets bridged to the SP. > > It sounds like you are implying that the link between your cell phone shares a broadcast domain with other users like a cable modem. This is not the case. The link between the user can the mobile gateway (similar to a cmts or dslam) is a p2p link that is not shared with any other subscriber. Bridging this link will not result in any security changes for you or the level noise on the link. In the case of ipv6, your handset has a /64 and your handset is the ONLY user on that subnet. Briding that p2p /64 will not result in any new exposure of your traffic to other subscribers. Cb > > Hemant > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --f46d041b476eb11dbf04b0497bbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


                    On Oct 27, 2011 7:44 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:
                    >
                    > =A0
                    >
                    > =A0
                    >
                    > From: homenet-bounces@ietf= .org [mailto:homenet-bounce= s@ietf.org] On Behalf Of Ted Lemon
                    > Sent: Tuesday, October 25, 2011 2:37 PM
                    > To: james woodyatt
                    > Cc: homenet@ietf.org Group
                    >
                    > Subject: Re: [homenet] routing requirements
                    >
                    > =A0
                    >
                    > >I would rather have a bridged /64 than a routed, NATted homenet. = =A0In fact, I think it would have to be a /128 before I'd reign myself = to NAT.=A0
                    >
                    > =A0
                    >
                    > With a bridge and a tethered cell phone, my PC in the home is served f= rom the Wi-Fi from the cell phone. =A0I am doing taxes on the laptop and th= e tax data gets bridged out the cellular network to the SP.=A0=A0 Additiona= lly, I have an AppleTV or some device like that with a Wi-Fi link that is s= erved by the cell phone WiFi.=A0 With bridging, all the video data of the T= V in the home gets bridged to the SP.=A0
                    >
                    > =A0

                    It sounds like you are implying that the link between your cell phone sh= ares a broadcast domain with other users like a cable modem.

                    This is not the case.

                    The link between the user can the mobile gateway (similar to a cmts or d= slam) is a p2p link that is not shared with any other subscriber.=A0 Bridgi= ng this link will not result in any security changes for you or the level n= oise on the link.

                    In the case of ipv6, your handset has a /64 and your handset is the ONLY= user on that subnet.=A0 Briding that p2p /64 will not result in any new ex= posure of your traffic to other subscribers.

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

                    --f46d041b476eb11dbf04b0497bbf-- From shemant@cisco.com Thu Oct 27 08:42:12 2011 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 077AB21F8B81 for ; Thu, 27 Oct 2011 08:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.763 X-Spam-Level: X-Spam-Status: No, score=-5.763 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCYJ0jqKxvfe for ; Thu, 27 Oct 2011 08:42:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 42D4A21F8B80 for ; Thu, 27 Oct 2011 08:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4750; q=dns/txt; s=iport; t=1319730131; x=1320939731; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=TVH/yfN26ufbi5bpr2LV3vSyyQGGjYG9NucFZ4VHoJQ=; b=gBr0fjHJdGOLgn1ZA3sKnuTVntnb3o5NG/98BxArGjEcDkj9Tpe1SaIH 36QqwVwCqP0uX+HcLRNkoTj7HNISUW4ZPvXLYue5wLKk55/r9qf6XLcQY m+k0aA3ftG+87l08zlis3Uugu/bZ41qRXcxGdTLnzOwCGfrGxPzvguZpT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4BAIt7qU6tJXG//2dsb2JhbABDgk2XQI9RgQWBcgEBAQQSAQkRA0kQAgEIDgMEAQELBhcBBgFFCQgBAQQTCBqeFAGeXogdYQSIBpE9jEc X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208,217";a="31439379" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 27 Oct 2011 15:42:10 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9RFgAdF029972; Thu, 27 Oct 2011 15:42:10 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 10:42:10 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC94BE.FD3DDB02" Date: Thu, 27 Oct 2011 10:42:09 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6D42@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyUuw4IIqAKWt4nSfam3JN1xts2dAAA5xHg References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Ted Lemon" X-OriginalArrivalTime: 27 Oct 2011 15:42:10.0067 (UTC) FILETIME=[FD43AE30:01CC94BE] Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 27 Oct 2011 15:42:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC94BE.FD3DDB02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: Ted Lemon [mailto:mellon@fugue.com]=20 Sent: Thursday, October 27, 2011 11:14 AM To: Hemant Singh (shemant) Cc: james woodyatt; homenet@ietf.org Subject: Re: [homenet] routing requirements =20 >You are assuming that the /64 is at the provider. =20 =20 Yes. A /64 is shared between the WAN and the LAN segment of the cell phone. Such a badly broken addressing was actually suggested to us authors of the v6ops CE router draft about 2.5 years back by one cellular phone vendor. =20 Hemant =20 ------_=_NextPart_001_01CC94BE.FD3DDB02 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                     

                     

                    From:= = Ted Lemon [mailto:mellon@fugue.com]
                    Sent: Thursday, October = 27, 2011 11:14 AM
                    To: Hemant Singh (shemant)
                    Cc: = james woodyatt; homenet@ietf.org
                    Subject: Re: [homenet] = routing requirements

                     

                    >You are assuming that the /64 is at = the provider.  

                     

                    Yes.   A /64 is shared between the WAN and the LAN segment = of the cell phone.  Such a badly broken addressing was actually = suggested to us authors of the v6ops CE router draft about 2.5 years = back by one cellular phone vendor.

                     

                    Hemant

                     

                    ------_=_NextPart_001_01CC94BE.FD3DDB02-- From mellon@fugue.com Thu Oct 27 08:44:12 2011 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 605E321F8BCB for ; Thu, 27 Oct 2011 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpK8n+gqxjNK for ; Thu, 27 Oct 2011 08:44:12 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA2E21F8BC5 for ; Thu, 27 Oct 2011 08:44:12 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:5459:5364:41cb:c151] (unknown [IPv6:2001:470:1f07:1486:5459:5364:41cb:c151]) by toccata.fugue.com (Postfix) with ESMTPSA id A8B812380C8F; Thu, 27 Oct 2011 11:44:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_F4F87C3F-AD08-4D5B-B4D7-EBBB94AB0D27" From: Ted Lemon In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6D42@XMB-RCD-109.cisco.com> Date: Thu, 27 Oct 2011 11:44:09 -0400 Message-Id: References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com> <51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6D42@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1251.1) Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 27 Oct 2011 15:44:12 -0000 --Apple-Mail=_F4F87C3F-AD08-4D5B-B4D7-EBBB94AB0D27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 27, 2011, at 11:42 AM, Hemant Singh (shemant) wrote: > Yes. A /64 is shared between the WAN and the LAN segment of the cell = phone. Such a badly broken addressing was actually suggested to us = authors of the v6ops CE router draft about 2.5 years back by one = cellular phone vendor. If such a broken configuration were actually deployed, I think it would = be fixed quickly, either by not doing it that way, or by installing a = really strict egress filter. It's not in the 3g provider's interests = to have this kind of brokenness in a handset. =20= --Apple-Mail=_F4F87C3F-AD08-4D5B-B4D7-EBBB94AB0D27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes.   A = /64 is shared between the WAN and the LAN segment of the cell = phone.  Such a badly broken addressing was actually suggested to us = authors of the v6ops CE router draft about 2.5 years back by one = cellular phone vendor.

                    If such = a broken configuration were actually deployed, I think it would be fixed = quickly, either by not doing it that way, or by installing a really = strict egress filter.   It's not in the 3g provider's interests to = have this kind of brokenness in a = handset.
                     
                    = --Apple-Mail=_F4F87C3F-AD08-4D5B-B4D7-EBBB94AB0D27-- From shemant@cisco.com Thu Oct 27 09:12:53 2011 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 6547521F8C16 for ; Thu, 27 Oct 2011 09:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1UxPToBbTbO for ; Thu, 27 Oct 2011 09:12:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 01E5E21F8C14 for ; Thu, 27 Oct 2011 09:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5184; q=dns/txt; s=iport; t=1319731972; x=1320941572; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=TvCHEJwpDJc6BeGEG1ieNDXapKhsXtKxRVEeYPaisJw=; b=V/Tymr/A97bcWakf9bKTjO9oocAgxmTb12RvTWs67Nv092jbljaDtiJm Z69oW9VsAs8f1R7ddjVZ2OOzGq4kfFUOWcQOYmOKO+lw4NbSvjGnLHolX DaNEwVcsdWv8VeoyBunWXtlmxd3G9AuT9nYsbjbhORaRdgzJceBdr8aGJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4BAH2CqU6tJV2Y/2dsb2JhbABDgk2XQI9RgQWBcgEBAQQSAQkRA0kQAgEIDgMEAQELBhcBBgFFCQgBAQQTCBqeIgGeXogdYQSIBpE9jEc X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208,217";a="31425055" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 27 Oct 2011 16:12:51 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9RGCpY7011394; Thu, 27 Oct 2011 16:12:51 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 11:12:51 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC94C3.4678F1E6" Date: Thu, 27 Oct 2011 11:12:50 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A6D6B@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] routing requirements Thread-Index: AcyUv0jWAWZVw79wQrSbxCyA5h7j5gAA5xNw References: <16D60F43CA0B724F8052D7E9323565D7243F7EB0BB@EUSAACMS0715.eamcs.ericsson.se><5B6B2B64C9FE2A489045EEEADDAFF2C3031FD7F8@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3031FDD6D@XMB-RCD-109.cisco.com><51A7F882-E2AB-48DB-B751-BA6412C93EF9@fugue.com><5B6B2B64C9FE2A489045EEEADDAFF2C3032A6CED@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3032A6D42@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Ted Lemon" X-OriginalArrivalTime: 27 Oct 2011 16:12:51.0445 (UTC) FILETIME=[46CFAA50:01CC94C3] Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] routing requirements 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, 27 Oct 2011 16:12:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC94C3.4678F1E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, October 27, 2011 11:44 AM To: Hemant Singh (shemant) Cc: homenet@ietf.org; james woodyatt Subject: Re: [homenet] routing requirements =20 >If such a broken configuration were actually deployed, I think it would be fixed quickly, either by not doing it that way, or by installing a really strict egress filter. It's not in the 3g provider's >interests to have this kind of brokenness in a handset. =20 As far as I know, no it's not been deployed. I, Wes Beebee, and Ole Troan talked to the cell phone vendor (after the Prague IETF) and said such a /64 deployment should not be deployed and instead DHCPv6 PD as per RFC 3633 should be used to allocate a shorter than /64 prefix to the CE device. =20 Hemant ------_=_NextPart_001_01CC94C3.4678F1E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

                     

                     

                    From:= = homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Ted Lemon
                    Sent: Thursday, October 27, 2011 11:44 = AM
                    To: Hemant Singh (shemant)
                    Cc: homenet@ietf.org; = james woodyatt
                    Subject: Re: [homenet] routing = requirements

                     

                    >If such a broken configuration were = actually deployed, I think it would be fixed quickly, either by not = doing it that way, or by installing a really strict egress filter. =   It's not in the 3g provider's >interests to have this kind of = brokenness in a handset.

                     

                    As far as I know, no it’s not been deployed.  I, Wes = Beebee, and Ole Troan talked to the cell phone vendor (after the Prague = IETF) and said such a /64 deployment should not be deployed and instead = DHCPv6 PD as per RFC 3633 should be used to allocate a shorter than /64 = prefix to the CE device.

                     

                    Hemant

                    ------_=_NextPart_001_01CC94C3.4678F1E6-- From mark@townsley.net Fri Oct 28 05:55:38 2011 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 6B32B21F8B87 for ; Fri, 28 Oct 2011 05:55:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-ozKAyb-Qs3 for ; Fri, 28 Oct 2011 05:55:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABDA621F8B84 for ; Fri, 28 Oct 2011 05:55:34 -0700 (PDT) Received: by eyg24 with SMTP id 24so3792720eyg.31 for ; Fri, 28 Oct 2011 05:55:33 -0700 (PDT) Received: by 10.216.213.72 with SMTP id z50mr875814weo.19.1319806517628; Fri, 28 Oct 2011 05:55:17 -0700 (PDT) Received: from [192.168.0.110] (dan75-4-82-239-58-63.fbx.proxad.net. [82.239.58.63]) by mx.google.com with ESMTPS id y38sm14850038wbm.2.2011.10.28.05.55.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Oct 2011 05:55:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <90B01617-3743-4B6A-99D1-F0159BB56331@orandom.net> Date: Fri, 28 Oct 2011 14:55:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69D5F8A3-7A6D-4307-8024-695512792D5B@townsley.net> References: <20111024201837.8598.92335.idtracker@ietfa.amsl.com> <90B01617-3743-4B6A-99D1-F0159BB56331@orandom.net> To: Wassim Haddad , Joel Halpern X-Mailer: Apple Mail (2.1084) Cc: "homenet@ietf.org Group" , David R Oran Subject: Re: [homenet] Fwd: I-D Action: draft-haddad-homenet-gateway-visibility-00.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: Fri, 28 Oct 2011 12:55:38 -0000 On Oct 26, 2011, at 6:42 PM, David R Oran wrote: >=20 > On Oct 26, 2011, at 12:25 PM, Wassim Haddad wrote: >=20 >> Dear all, >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >> Title: Ensuring Home Network Visibility to Home Gateway >>=20 >> This memo describes a mechanism designed to increase the home gateway = visibility on the home network that it is serving. This includes = knowledge of all IPv6 addresses configured using prefixes assigned by >> the home gateway and advertised by router(s) attached to it. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-haddad-homenet-gateway-visibilit= y-00.txt >>=20 >>=20 >> Your comments are appreciated! >>=20 > The draft says "In such scenario, it can be useful for the HGW(s) > to keep track of all IPv6 addresses configured by different types of > end devices that get attached to the home network via router(s) > connected to the HGW(s)." >=20 > but give zero justification for WHY it might be useful. I can't think = of any reason at all, but I assume you can but just thought it too = obvious to write down. >=20 > Could you educate me? Ray and I would like to know as well, in particular we're trying to see = where this fits into the homenet architecture (considering the 5 areas = we are chartered to target as well). If nothing else, we need to know = this in order to fit it into the Taipei homenet agenda assuming you want = some time to discuss it there. Thanks, - Ray & Mark >=20 > Thanks,=20 > DaveO. >=20 >>=20 >> Regards, >>=20 >> Wassim H. >> _______________________________________________ >> 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 v6ops@globis.net Fri Oct 28 13:12:35 2011 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 521AE11E8080 for ; Fri, 28 Oct 2011 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyd734KSyJ14 for ; Fri, 28 Oct 2011 13:12:34 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B122911E807F for ; Fri, 28 Oct 2011 13:12:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 850D6870089; Fri, 28 Oct 2011 22:12:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYBEwS0gWmfm; Fri, 28 Oct 2011 22:12:25 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 50698870087; Fri, 28 Oct 2011 22:12:25 +0200 (CEST) Message-ID: <4EAB0CA9.5010504@globis.net> Date: Fri, 28 Oct 2011 22:12:25 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Jari Arkko Content-Type: multipart/alternative; boundary="------------040407060902020301080503" Cc: homenet@ietf.org, Acee Lindem Subject: [homenet] a few drafts... 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, 28 Oct 2011 20:12:35 -0000 This is a multi-part message in MIME format. --------------040407060902020301080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is certainly an interesting approach to the distributed prefix assignment problem and worth discussing further IMHO. Since there are a lot of things to configure in Homenet I was advocating a specific topology discovery and configuration protocol. Once you have a routing protocol up and configured it would certainly make all other configuration in Homenet much easier e.g. distributing an anycast address for a name server or DHCPv6 server to be used by end nodes. I have a few dumb questions from a layman that are probably so obvious you won't think they're worth addressing in the draft. After reading the drafts I'm unsure of the exact relationship between the 2 new TLV values and the AC LSA wrapper. draft-arkko-homenet-prefix-assignment-00 defines that they are always related on the wire, and "the information from all TLV instances is retained" but once they are unpacked in the local memory is maintaining the relationship necessary? Do you need to remember from whom you learned a usable prefix TLV? I think you do, so you can age it out properly, but it isn't explicitly mentioned. Do all AC LSA packets defined in http://tools.ietf.org/html/draft-acee-ospf-ospfv3-autoconfig-00 from a single source have to contain a complete set of TLV's associated with a particular Type every time they are sent out? So if one new interface comes up on a router whilst other have been up for a while, does the AC LSA update have to include TLV's for all assigned prefixes for all interfaces on the local router, and not just the new assignments? I think that's true but it isn't explictly mentioned. Is it not a potential DOS attack to flood in many usable prefixes into the OSPF AC, even if the router does wait 10 minutes before writing flash and retain at least the 5 most recent assignments? Worth warning about in security or trivial? Is there a standard lifetime associated with the AC LSA? Is it the standard MaxAge (1 hour)? Is it the standard LSRefreshTime (30 mins) Is there any guidance or timing constraints regarding advertising the newly assigned link prefixes learned via autoconfig into other OSPF LSAs or into RA? I can imagine you might want to wait a short interval to wait for any assignment conflicts to resolve to avoid disrupting routing or fresh host communications. Is there any guidance about how prefixes learned via autoconfig could/should/should not interact with prefixes learned via other sources e.g. local hard configuration? regards, RayH > Subject: > [homenet] a few drafts... > From: > Jari Arkko > Date: > Tue, 25 Oct 2011 16:03:48 +0200 > > To: > "homenet@ietf.org" > CC: > Acee Lindem > > Content-Transfer-Encoding: > 7bit > Precedence: > list > MIME-Version: > 1.0 > Message-ID: > <4EA6C1C4.7050609@piuha.net> > Content-Type: > text/plain; charset=ISO-8859-1; format=flowed > Message: > 1 > > > Here's a couple of drafts inspired by discussions from the interim > meeting: > > http://tools.ietf.org/html/draft-acee-ospf-ospfv3-autoconfig-00.txt > > OSPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This document > describes the necessary mechanisms for OSPFv3 to be self-configuring. > > http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-00.txt > > This memo describes a prefix assignment mechanism for home networks. > It is expected that home gateway routers are assigned an IPv6 prefix > through DHCPv6 Prefix Delegation (PD). This prefix needs to be > divided among the multiple subnets in a home network. This memo > describes a mechanism for such division via OSPFv3. This is an > alternative design to using DHCPv6 PD also for the prefix assignment. > The memo is input to the working group so that it can make a decision > on which type of design to pursue. It is expected that a routing- > protocol based assignment uses a minimal amount of prefixes. > > Comments appreciated! > > Jari --------------040407060902020301080503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is certainly an interesting approach to the distributed prefix assignment problem and worth discussing further IMHO.

                    Since there are a lot of things to configure in Homenet I was advocating a specific topology discovery and configuration protocol.

                    Once you have a routing protocol up and configured it would certainly make all other configuration in Homenet much easier e.g. distributing an anycast address for a name server or DHCPv6 server to be used by end nodes.



                    I have a few dumb questions from a layman that are probably so obvious you won't think they're worth addressing in the draft.

                    After reading the drafts I'm unsure of the exact relationship between the 2 new TLV values and the AC LSA wrapper. draft-arkko-homenet-prefix-assignment-00 defines that they are always related on the wire, and "the information from all TLV instances is retained" but once they are unpacked in the local memory is maintaining the relationship necessary?

                    Do you need to remember from whom you learned a usable prefix TLV? I think you do, so you can age it out properly, but it isn't explicitly mentioned.

                    Do all AC LSA packets defined in http://tools.ietf.org/html/draft-acee-ospf-ospfv3-autoconfig-00 from a single source have to contain a complete set of TLV's associated with a particular Type every time they are sent out? So if one new interface comes up on a router whilst other have been up for a while, does the AC LSA update have to include TLV's for all assigned prefixes for all interfaces on the local router, and not just the  new assignments? I think that's true but it isn't explictly mentioned.

                    Is it not a potential DOS attack to flood in many usable prefixes into the OSPF AC, even if the router does wait 10 minutes before writing flash and retain at least the 5 most recent assignments? Worth warning about in security or trivial?

                    Is there a standard lifetime associated with the AC LSA?
                    Is it the standard MaxAge (1 hour)?
                    Is it the standard LSRefreshTime (30 mins)

                    Is there any guidance or timing constraints regarding advertising the newly assigned link prefixes learned via autoconfig into other OSPF LSAs or into RA? I can imagine you might want to wait a short interval to wait for any assignment conflicts to resolve to avoid disrupting routing or fresh host communications.

                    Is there any guidance about how prefixes learned via autoconfig could/should/should not interact with prefixes learned via other sources e.g. local hard configuration?

                    regards,
                    RayH
                    Subject:
                    [homenet] a few drafts...
                    From:
                    Jari Arkko <jari.arkko@piuha.net>
                    Date:
                    Tue, 25 Oct 2011 16:03:48 +0200
                    To:
                    "homenet@ietf.org" <homenet@ietf.org>
                    CC:
                    Acee Lindem <acee.lindem@ericsson.com>
                    Content-Transfer-Encoding:
                    7bit
                    Precedence:
                    list
                    MIME-Version:
                    1.0
                    Message-ID:
                    <4EA6C1C4.7050609@piuha.net>
                    Content-Type:
                    text/plain; charset=ISO-8859-1; format=flowed
                    Message:
                    1

                    Here's a couple of drafts inspired by discussions from the interim meeting:

                    http://tools.ietf.org/html/draft-acee-ospf-ospfv3-autoconfig-00.txt

                       OSPFv3 is a candidate for deployments in environments where auto-
                       configuration is a requirement.  One such environment is the IPv6
                       home network where users expect to simply plug in a router and have
                       it automatically use OSPFv3 for intra-domain routing.  This document
                       describes the necessary mechanisms for OSPFv3 to be self-configuring.

                    http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-00.txt

                       This memo describes a prefix assignment mechanism for home networks.
                       It is expected that home gateway routers are assigned an IPv6 prefix
                       through DHCPv6 Prefix Delegation (PD).  This prefix needs to be
                       divided among the multiple subnets in a home network.  This memo
                       describes a mechanism for such division via OSPFv3.  This is an
                       alternative design to using DHCPv6 PD also for the prefix assignment.
                       The memo is input to the working group so that it can make a decision
                       on which type of design to pursue.  It is expected that a routing-
                       protocol based assignment uses a minimal amount of prefixes.

                    Comments appreciated!

                    Jari
                    --------------040407060902020301080503-- From jari.arkko@piuha.net Fri Oct 28 13:21:56 2011 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 70B191F0C34 for ; Fri, 28 Oct 2011 13:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPqujeEa+JIO for ; Fri, 28 Oct 2011 13:21:56 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 680721F0C54 for ; Fri, 28 Oct 2011 13:21:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B9BF02CC44; Fri, 28 Oct 2011 23:21:54 +0300 (EEST) 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 Ur714bPA9RXI; Fri, 28 Oct 2011 23:21:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1BE492CC4A; Fri, 28 Oct 2011 23:21:54 +0300 (EEST) Message-ID: <4EAB0EE1.6030209@piuha.net> Date: Fri, 28 Oct 2011 23:21:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ray Hunter References: <4EAB0CA9.5010504@globis.net> In-Reply-To: <4EAB0CA9.5010504@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Acee Lindem Subject: Re: [homenet] a few drafts... 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, 28 Oct 2011 20:21:57 -0000 Ray, These are certainly all good questions. I'm sure we need to fill in answers to all these. I don't have an immediate answer, but we will take this into account when preparing the next revision. Jari From jhw@apple.com Fri Oct 28 16:02:57 2011 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 87FA011E808B for ; Fri, 28 Oct 2011 16:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTNdMN0Ilwye for ; Fri, 28 Oct 2011 16:02:57 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 07C8311E8089 for ; Fri, 28 Oct 2011 16:02:56 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qUKhnxNCMXUmagSu7xbUfg)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LTS00MZVTCJBF33@mail-out.apple.com> for homenet@ietf.org; Fri, 28 Oct 2011 16:02:56 -0700 (PDT) X-AuditID: 11807136-b7c19ae0000072b0-55-4eab34a0aa16 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B6.E4.29360.0A43BAE4; Fri, 28 Oct 2011 16:02:56 -0700 (PDT) From: james woodyatt Date: Fri, 28 Oct 2011 16:02:56 -0700 In-reply-to: <69D5F8A3-7A6D-4307-8024-695512792D5B@townsley.net> To: "homenet@ietf.org Group" References: <20111024201837.8598.92335.idtracker@ietfa.amsl.com> <90B01617-3743-4B6A-99D1-F0159BB56331@orandom.net> <69D5F8A3-7A6D-4307-8024-695512792D5B@townsley.net> Message-id: X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUieJDvpu4Ck9V+BtseClm8X3SIxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYt3nmYt6DeueHhqF0sDY7NOFyMnh4SAicSJKZtZIGwxiQv3 1rN1MXJxCAmsYJI419ABlmATUJH4dvkuE4jNK2AssebWO7A4s0CCxOdpt8HiwgKBEjufbwSL swioSpz4NJUdxOYUcJB4PXkBWFxEQF/i6ZFfUAtuM0q8/TibGWKojcT32WeYIa6Ql2j5eodt AiPvLCT7ZiHZB2FrSyxb+Jp5FiMHkK0jMXkhI6owhP3x/BGmBYxsqxgFi1JzEisNTfUSCwpy UvWS83M3MYJCr6HQbAfjjr9yhxgFOBiVeHgdnqzyE2JNLCuuzD3EKMHBrCTC++IxUIg3JbGy KrUoP76oNCe1+BCjNAeLkjivI/9qPyGB9MSS1OzU1ILUIpgsEwenVAPjRs7oV+ceHrr8/drv K/WmLywnX/s5qanSQblHyWjq1en7tqT/al/x+0HN5P3sTZeuWLPXNhx033z+eJ6Z6cZrp2z2 9MzY6BGVt3qNv8n3TSGX7mmzqjzfxKC2IWiSh9oftlWyfUHKMXvkn+/JY8yWe2rxxCRTYvqu 6R+Szuwp498Wd0hIL+lhvBJLcUaioRZzUXEiAFdYFCw5AgAA Subject: Re: [homenet] I-D Action: draft-haddad-homenet-gateway-visibility-00.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: Fri, 28 Oct 2011 23:02:57 -0000 --Boundary_(ID_qUKhnxNCMXUmagSu7xbUfg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Oct 28, 2011, at 5:55 AM, Mark Townsley wrote: > On Oct 26, 2011, at 6:42 PM, David R Oran wrote: >> On Oct 26, 2011, at 12:25 PM, Wassim Haddad wrote: >>> >>> This memo describes a mechanism designed to increase the home gateway visibility on the home network that it is serving. This includes knowledge of all IPv6 addresses configured using prefixes assigned by >>> the home gateway and advertised by router(s) attached to it. >> >> The draft says "In such scenario, it can be useful for the HGW(s) >> to keep track of all IPv6 addresses configured by different types of >> end devices that get attached to the home network via router(s) >> connected to the HGW(s)." >> >> but give zero justification for WHY it might be useful. I can't think of any reason at all, but I assume you can but just thought it too obvious to write down. >> >> Could you educate me? > > Ray and I would like to know as well, in particular we're trying to see where this fits into the homenet architecture (considering the 5 areas we are chartered to target as well). If nothing else, we need to know this in order to fit it into the Taipei homenet agenda assuming you want some time to discuss it there. Looks to me like somebody really wants the functionality of I-D.woodyatt-ald, only just for IP addresses and not for protocol and port numbers as well. If you gonna hoover up everything, why not go big? -- james woodyatt member of technical staff, core os networking --Boundary_(ID_qUKhnxNCMXUmagSu7xbUfg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
                    On Oct 26, 2011, at 6:42 PM, = David R Oran wrote:
                    On Oct 26, 2011, at = 12:25 PM, Wassim Haddad wrote:

                    This memo describes a mechanism = designed to increase the home gateway visibility on the home network = that it is serving.  This includes knowledge of all IPv6 addresses = configured using prefixes assigned = by
                    the home gateway and advertised by router(s) attached to = it.

                    The draft says "In such scenario, it can be useful for the = HGW(s)
                     to keep track of = all IPv6 addresses configured by different types = of
                     end devices that get = attached to the home network via router(s)
                     connected to the = HGW(s)."

                    but give zero = justification for WHY it might be useful. I can't think of any reason at = all, but I assume you can but just thought it too obvious to write = down.

                    Could you = educate me?

                    Ray and I would like to know as well, in = particular we're trying to see where this fits into the homenet = architecture (considering the 5 areas we are chartered to target as = well). If nothing else, we need to know this in order to fit it into the = Taipei homenet agenda assuming you want some time to discuss it = there.

                    Looks to me like somebody really = wants the functionality of I-D.woodyatt-ald, only just for IP addresses = and not for protocol and port numbers as well.  If you gonna hoover = up everything, why not go big?


                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_qUKhnxNCMXUmagSu7xbUfg)-- From nordmark@cisco.com Fri Oct 28 18:16:25 2011 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 38E0411E8088 for ; Fri, 28 Oct 2011 18:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa7ryQx8z3bm for ; Fri, 28 Oct 2011 18:16:24 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD711E8081 for ; Fri, 28 Oct 2011 18:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1129; q=dns/txt; s=iport; t=1319850979; x=1321060579; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=cvNdUvdnr2zVSQFkjm7BmDsQ89LpRauxTVic//3r5EI=; b=EMMILbgiGP71elq+ZygGRxXZvFE8ne32tGObYTnbk1Gw7WeO6dItzHS6 2oFbYiBuXk6OKxCSEjwdhuiirwHGxD0bmUzvG/bOtYR/EsEAOWaiWpU+k MleiDFRN+obNRzNWDg6yt5/f1jU8678Jzwl+7eqQ+3m0T7ZT3uUI/ohAq s=; X-IronPort-AV: E=Sophos;i="4.69,421,1315180800"; d="scan'208";a="11055989" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 29 Oct 2011 01:16:19 +0000 Received: from [10.0.1.13] (sjc-vpn6-1478.cisco.com [10.21.125.198]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9T1GIlI007103; Sat, 29 Oct 2011 01:16:18 GMT Message-ID: <4EAB53E3.5090004@cisco.com> Date: Fri, 28 Oct 2011 18:16:19 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.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] Prefix stability requirements in draft-arkko-homenet-prefix-assignment-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: Sat, 29 Oct 2011 01:16:25 -0000 The document has fairly week stability requirements: o The assignments must be stable across reboots, power cycling, router software updates, and preferably, should be stable across simple network changes such as adding a new device on the stub network segments. However, stability across more complex types of network reconfiguration events is not a requirement. I don't understand what a stub network segment is. Is this a segment which has only one router connected to it? If so I think the above requirement is far to weak. I think the goal (but not requirement, because it isn't obvious that it can be satisfied) should be to handle the same type of changes that bridges can handle without any unnecessary prefix changes on the segments. For example, if a segment is split in two separate segments, then it would be necessary to assign a new prefix since each segment needs a unique prefix. But apart from such necessary changes there shouldn't be a need to renumber because routers are added, removed, or connected in different ways. Regards, Erik From jari.arkko@piuha.net Sat Oct 29 11:56:14 2011 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 24FFE21F85B8 for ; Sat, 29 Oct 2011 11:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N76-pqtnHM1c for ; Sat, 29 Oct 2011 11:56:13 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 555DF21F85AE for ; Sat, 29 Oct 2011 11:56:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A99B02CC44; Sat, 29 Oct 2011 21:56:12 +0300 (EEST) 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 ZhkJmzUbzx5k; Sat, 29 Oct 2011 21:56:12 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DA0DA2CC34; Sat, 29 Oct 2011 21:56:11 +0300 (EEST) Message-ID: <4EAC4C4A.40606@piuha.net> Date: Sat, 29 Oct 2011 21:56:10 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Erik Nordmark References: <4EAB53E3.5090004@cisco.com> In-Reply-To: <4EAB53E3.5090004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Prefix stability requirements in draft-arkko-homenet-prefix-assignment-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: Sat, 29 Oct 2011 18:56:14 -0000 On 29.10.2011 04:16, Erik Nordmark wrote: > > The document has fairly week stability requirements: > > o The assignments must be stable across reboots, power cycling, > router software updates, and preferably, should be stable across > simple network changes such as adding a new device on the stub > network segments. However, stability across more complex types of > network reconfiguration events is not a requirement. > > I don't understand what a stub network segment is. > Is this a segment which has only one router connected to it? That got written pretty quickly, and can clearly be improved. By "stub network segment" I meant adding a new router on the edges of the network, not in the middle, between existing routers. But I can see that it was not a well-formed requirement. It seems easy to add a new router anywhere and not have it disrupt the rest of the network, as long as you do not force a network to split into two. For instance, if the old network was R1 - R2 and then you a new router R3 so that the network looks like this: R1 - R3 - R2 Then whatever subnet existed before R1 and R2 now needs to change. R1 or R2 or both need to get a new prefix, because the same prefix cannot be in two places. > If so I think the above requirement is far to weak. > > I think the goal (but not requirement, because it isn't obvious that it can be satisfied) should be to handle the same type of changes that bridges can handle without any unnecessary prefix changes on the segments. For example, if a segment is split in two separate segments, then it would be necessary to assign a new prefix since each segment needs a unique prefix. But apart from such necessary changes there shouldn't be a need to renumber because routers are added, removed, or connected in different ways. Right. I think -- without proving it -- that draft-arkko-homenet-prefix-assignment could actually fulfill your requirement. Assigned prefixes are sticky with routers and per Section 5.3 new routers employ a wait period before assigning themselves a prefix. Barring collisions in the generated suggested prefixes _and_ parts of the network being down, or network partitions this would seem to allow the right thing to happen. I have edited the requirement text for -01 to be as follows: o The assignments must be stable across reboots, power cycling, router software updates, and preferably, should be stable across simple network changes. Simple network changes are in this case defined as those that could be resolved through either deletion or addition of a prefix assignment. For instance, the addition of a new router without changing connections between existing routers requires just the assigment of new prefixes for the new networks that the router introduces. There are no stability requirements across more complex types of network reconfiguration events. For instance, if a network is separated into two networks connected by a newly inserted router, this may lead into renumbering all networks within the home. Does this work for you? Jari From nordmark@cisco.com Sat Oct 29 14:14:57 2011 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 15F1321F853B for ; Sat, 29 Oct 2011 14:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib+GcGxm6s46 for ; Sat, 29 Oct 2011 14:14:56 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4C90821F8531 for ; Sat, 29 Oct 2011 14:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=4500; q=dns/txt; s=iport; t=1319922896; x=1321132496; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=V0h6gXEijBVT/FGhjj9L8tEfHY7Ifc/a6dObbHnnmWs=; b=lSMJxZUpG/3iQLmG9AbDLwMeaz+gW0T+dTaDuTrRP9BVyuBRqtj52h1s JnsNIMqUqnNgBJT3kiy7Gb/d0FaKpII/7x0Xf9XVRD0gRXlO2iGuR8tbt X5/032aqDQaBRaTuhKU1cHUCoW7JT+Dz9FxO0WtaPzOFk5VQMBxqDXAKj I=; X-IronPort-AV: E=Sophos;i="4.69,424,1315180800"; d="scan'208";a="10046298" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 Oct 2011 21:14:56 +0000 Received: from [10.0.1.13] (sjc-vpn6-974.cisco.com [10.21.123.206]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9TLEtuF029084; Sat, 29 Oct 2011 21:14:55 GMT Message-ID: <4EAC6CD0.1090701@cisco.com> Date: Sat, 29 Oct 2011 14:14:56 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jari Arkko References: <4EAB53E3.5090004@cisco.com> <4EAC4C4A.40606@piuha.net> In-Reply-To: <4EAC4C4A.40606@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Prefix stability requirements in draft-arkko-homenet-prefix-assignment-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: Sat, 29 Oct 2011 21:14:57 -0000 On 10/29/11 11:56 AM, Jari Arkko wrote: > On 29.10.2011 04:16, Erik Nordmark wrote: >> >> The document has fairly week stability requirements: >> >> o The assignments must be stable across reboots, power cycling, >> router software updates, and preferably, should be stable across >> simple network changes such as adding a new device on the stub >> network segments. However, stability across more complex types of >> network reconfiguration events is not a requirement. >> >> I don't understand what a stub network segment is. >> Is this a segment which has only one router connected to it? > > That got written pretty quickly, and can clearly be improved. By "stub > network segment" I meant adding a new router on the edges of the > network, not in the middle, between existing routers. If one of the reasons one might want routers is for redundant connectivity inside the home, then even something which is conceptually a stub (not intended for transit) will have two routers attached to it. > But I can see that it was not a well-formed requirement. It seems easy > to add a new router anywhere and not have it disrupt the rest of the > network, as long as you do not force a network to split into two. For > instance, if the old network was > > R1 - R2 > > and then you a new router R3 so that the network looks like this: > > R1 - R3 - R2 > > Then whatever subnet existed before R1 and R2 now needs to change. R1 or > R2 or both need to get a new prefix, because the same prefix cannot be > in two places. In that case you are partitioning a link into two, and there one clearly needs to add an additional prefix. > I think -- without proving it -- that > draft-arkko-homenet-prefix-assignment could actually fulfill your > requirement. Assigned prefixes are sticky with routers and per Section > 5.3 new routers employ a wait period before assigning themselves a > prefix. Barring collisions in the generated suggested prefixes _and_ > parts of the network being down, or network partitions this would seem > to allow the right thing to happen. I looked briefly at the solution in the draft, but it seems to fundamentally associate the prefix(es) with router interfaces and not with links. An interesting case is a link like this rest of home network | | R1 R2 | | +------------+ | | H1 H2 If R1 is the first router, it assigns a prefix to its southbound interface. I take it the solution makes R2 pick up that prefix for its southbound interface. But what happens if R1 is decomissioned? Will R2 permanently assert that prefix for the link? > I have edited the requirement text for -01 to be as follows: > > o The assignments must be stable across reboots, power cycling, > router software updates, and preferably, should be stable across > simple network changes. Simple network changes are in this case > defined as those that could be resolved through either deletion or > addition of a prefix assignment. For instance, the addition of a > new router without changing connections between existing routers > requires just the assigment of new prefixes for the new networks > that the router introduces. There are no stability requirements > across more complex types of network reconfiguration events. For > instance, if a network is separated into two networks connected by > a newly inserted router, this may lead into renumbering all > networks within the home. > > Does this work for you? First of all, even if no new routers are introduced, there can be L2 changes which necessitate new prefixes, such as cutting the cable/bridge between R1/H1 and R2/H2 above. That isn't much different than introducing R3 between the two halves. I.e. either rest of home network | | R1 R2 | | | | | | H1 H2 or rest of home network | | R1 R2 | | +-----R3-----+ | | H1 H2 Why would we want to renumber all the networks within the home in such a case? I think a reasonable goal is that we at most cause changes locally H1 and/or H2 see new prefixes, with no effect on the rest of the home network. The best we can do is that only one of H1 or H2 ends up getting new prefixes. But that might be hard to accomplish reliably. Erik From jari.arkko@piuha.net Sun Oct 30 02:40:11 2011 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 8785B21F888A for ; Sun, 30 Oct 2011 02:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvYQtpd-OpwK for ; Sun, 30 Oct 2011 02:40:11 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id BAF0121F886A for ; Sun, 30 Oct 2011 02:40:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1530D2CC44; Sun, 30 Oct 2011 11:40:10 +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 IP2U-IAW-qlu; Sun, 30 Oct 2011 11:40:09 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 75CDB2CC39; Sun, 30 Oct 2011 11:40:09 +0200 (EET) Message-ID: <4EAD1B77.6010602@piuha.net> Date: Sun, 30 Oct 2011 11:40:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Erik Nordmark , "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Prefix stability requirements in draft-arkko-homenet-prefix-assignment-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: Sun, 30 Oct 2011 09:40:11 -0000 Erik, > I looked briefly at the solution in the draft, but it seems tofundamentally associate the prefix(es) with router interfaces and notwith links. The draft associates prefixes with interfaces because that is the only thing that it can do alone. But since it monitors prefix assignments by both neighboring routers and everyone else, routers are aware of the network topology _and_ network prefix assignments. A prefix assignment by your neighbor becomes your prefix assignment, too. You use the same prefix on the same network, not add another one. And next time if the two routers boot in a different order you will remember your neighbor's prefix for this network and use it. If the two routers are moved to different networks, there will be a collision, it is detected, and one of the routers selects a new prefix. > An interesting case is a link like this > > rest of home network > | | > R1 R2 > | | > +------------+ > | | > H1 H2 > > If R1 is the first router, it assigns a prefix to its southboundinterface. I take it the solution makes R2 pick up that prefix for itssouthbound interface. Yes. > But what happens if R1 is decomissioned? Will R2 permanently assert thatprefix for the link? Yes. See Section 4, first bullet item, and Section 5.3, item 5 and the second bullet. (And if R1 is just moved to a different part of the network then Section 5.3 item 5 second bullet will not apply, because the prefix has been announced elsewhere.) Jari From tjc@ecs.soton.ac.uk Sun Oct 30 17:26:19 2011 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 1A9D121F8B06 for ; Sun, 30 Oct 2011 17:26:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xji7-BacK+Ec for ; Sun, 30 Oct 2011 17:26:18 -0700 (PDT) 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 D9DF221F8AE6 for ; Sun, 30 Oct 2011 17:26:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p9V0QBFf027956 for ; Mon, 31 Oct 2011 00:26:11 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p9V0QBFf027956 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1320020771; bh=jgiEktEh4I5lBEzg2PnNgXQUOIY=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=P/TEOOmn1NhuXmGFP2kom12Z1VKmVWQH7w+Ct6P/XfDfiyMVU8y4/4XKbOYF6ZThx rcMJq+5w0gMhVxO9QWARPOEe+T8tlXGJtueVfB0BlurdWd7ROgy7s+tR4lyuicCYYr /l2Q7E3cHFY/BFGjEDM6lr4AxAOkddIqAKdG159I= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id n9U0QB0543722232El ret-id none; Mon, 31 Oct 2011 00:26:11 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p9V0Oq5p032716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 31 Oct 2011 00:24:53 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Tim Chown In-Reply-To: <20111031002027.18320.78505.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 00:24:52 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20111031002027.18320.78505.idtracker@ietfa.amsl.com> <8592B698-AF5F-44D2-8D6B-92B58E77B808@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1251.1) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n9U0QB054372223200; tid=n9U0QB0543722232El; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p9V0QBFf027956 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-chown-homenet-arch-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: Mon, 31 Oct 2011 00:26:19 -0000 Hi, A new version of the architecture text is now available. We've included = much feedback from the homenet list and interim WG meeting. There is still a little more editorial work likely by the authors before = Monday night's deadline that may result in a -02 version, in particular = in section 3.5, but comments on the -01 version are very welcome. Tim On 31 Oct 2011, at 00:20, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Home Networking Architecture for IPv6 > Author(s) : Jari Arkko > Tim Chown > Jason Weil > Ole Troan > Filename : draft-chown-homenet-arch-01.txt > Pages : 26 > Date : 2011-10-30 >=20 > This text describes evolving networking technology within small > "residential home" networks. The goal of this memo is to = define the > architecture for IPv6-based home networking and the associated > principles and considerations. The text highlights the impact of > IPv6 on home networking, illustrates topology scenarios, and shows > how standard IPv6 mechanisms and addressing can be employed in home > networking. The architecture describes the need for specific > protocol extensions for certain additional functionality. It is > assumed that the IPv6 home network runs as an IPv6-only or = dual-stack > network, but there are no recommendations in this memo for the IPv4 > part of the network. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chown-homenet-arch-01.txt From jari.arkko@piuha.net Mon Oct 31 08:21:22 2011 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 3ECD41F0C35 for ; Mon, 31 Oct 2011 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQaFCfSYZYNs for ; Mon, 31 Oct 2011 08:21:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 94ADF21F8DC9 for ; Mon, 31 Oct 2011 08:21:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E29F12CC5B for ; Mon, 31 Oct 2011 17:21:20 +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 cN9G-wiKTJRH for ; Mon, 31 Oct 2011 17:21:20 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5AD422CC30 for ; Mon, 31 Oct 2011 17:21:20 +0200 (EET) Message-ID: <4EAEBCF0.3090305@piuha.net> Date: Mon, 31 Oct 2011 17:21:20 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "homenet@ietf.org" References: <20111031151951.4438.52423.idtracker@ietfa.amsl.com> In-Reply-To: <20111031151951.4438.52423.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] FW: New Version Notification for draft-arkko-homenet-prefix-assignment-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: Mon, 31 Oct 2011 15:21:22 -0000 FYI. Contains small updates based on input received on the list. > A new version of I-D, draft-arkko-homenet-prefix-assignment-01.txt has been successfully submitted by Jari Arkko and posted to the IETF repository. > > Filename: draft-arkko-homenet-prefix-assignment > Revision: 01 > Title: Prefix Assignment in a Home Network > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 14 > > From wassim.haddad@ericsson.com Mon Oct 31 12:57:41 2011 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 97E0A11E81D3 for ; Mon, 31 Oct 2011 12:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANzkF9ii2K57 for ; Mon, 31 Oct 2011 12:57:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E60F111E81D0 for ; Mon, 31 Oct 2011 12:57:40 -0700 (PDT) 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 p9VJvY9Y001783; Mon, 31 Oct 2011 14:57:39 -0500 Received: from [155.53.121.159] (147.117.20.214) by eusaamw0706.eamcs.ericsson.se (147.117.20.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 31 Oct 2011 15:57:35 -0400 MIME-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_C6832CB0-2E07-4C01-BABD-ECE3529FA0B5"; protocol="application/pkcs7-signature"; micalg=sha1 From: Wassim Haddad In-Reply-To: <69D5F8A3-7A6D-4307-8024-695512792D5B@townsley.net> Date: Mon, 31 Oct 2011 12:57:51 -0700 Message-ID: <2850A807-6BA3-4817-B2F0-ADE1D78E0C54@ericsson.com> References: <20111024201837.8598.92335.idtracker@ietfa.amsl.com> <90B01617-3743-4B6A-99D1-F0159BB56331@orandom.net> <69D5F8A3-7A6D-4307-8024-695512792D5B@townsley.net> To: Mark Townsley , David R Oran X-Mailer: Apple Mail (2.1251.1) Cc: Joel Halpern , Wassim Haddad , "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-gateway-visibility-00.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: Mon, 31 Oct 2011 19:57:41 -0000 --Apple-Mail=_C6832CB0-2E07-4C01-BABD-ECE3529FA0B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Oct 28, 2011, at 5:55 AM, Mark Townsley wrote: > On Oct 26, 2011, at 6:42 PM, David R Oran wrote: >=20 >>=20 >> On Oct 26, 2011, at 12:25 PM, Wassim Haddad wrote: >>=20 >>> Dear all, >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>> Title: Ensuring Home Network Visibility to Home Gateway >>>=20 >>> This memo describes a mechanism designed to increase the home = gateway visibility on the home network that it is serving. This = includes knowledge of all IPv6 addresses configured using prefixes = assigned by >>> the home gateway and advertised by router(s) attached to it. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-haddad-homenet-gateway-visibilit= y-00.txt >>>=20 >>>=20 >>> Your comments are appreciated! >>>=20 >> The draft says "In such scenario, it can be useful for the HGW(s) >> to keep track of all IPv6 addresses configured by different types of >> end devices that get attached to the home network via router(s) >> connected to the HGW(s)." >>=20 >> but give zero justification for WHY it might be useful. I can't think = of any reason at all, but I assume you can but just thought it too = obvious to write down. >>=20 >> Could you educate me? >=20 > Ray and I would like to know as well, in particular we're trying to = see where this fits into the homenet architecture (considering the 5 = areas we are chartered to target as well). If nothing else, we need to = know this in order to fit it into the Taipei homenet agenda assuming you = want some time to discuss it there. =3D> The reason is that if we consider that in-home services are getting = increasingly complex then it makes sense to aggregate control as much as = possible in one device (i.e., the home GW) in order to make average = user's life simpler and easier. IMHO, having one router at home is = already a burden to the "average user" in terms of grappling with all = configurations so one could justifyably argue that the situation will = get much worse with multiple ones! Furthermore, the traditional assumption for service controllers like = UPnP, is that the network is bridged while homenet WG seems to be = leaning towards a routed internal network (note also that this gets = even more complicated if we add that a DLNA certified device does not = mean at all that all features are implemented).=20 Consequently, in order to keep the home network control simple, a single = point of service control is helpful to both the home user and the = network service provider. As an example, I have a medical device at home connected to a router = that is two hops away from the home GW. The medical device requires = special treatment for both downstream and upstream traffic. IMHO, it = would be very helpful if the service control point (i.e., home GW) can = discover the device and engage directly with in suitable exchanges to = determine what it needs to ensure it works in the most optimal way, then = make necessary configurations accordingly.=20 Regards, Wassim H.= --Apple-Mail=_C6832CB0-2E07-4C01-BABD-ECE3529FA0B5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIENDCCBDAw ggMYoAMCAQICEQDYVPUywOyjtwh/x6nlhfS/MA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMDkxMDI5MTU1 ODU3WhcNMTIxMDI5MTU1ODU0WjBoMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNV2Fzc2lt IEhhZGRhZDEQMA4GA1UEBRMHZXdhc2hhZDEpMCcGCSqGSIb3DQEJARYad2Fzc2ltLmhhZGRhZEBl cmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJnf3T/nroDokwgzv1ob54nr EQ2qce7b8P0j9dhnGFPhfROZzOb8Uuo1MPaSpDLVObZgSisoJ5JU0euu6pVcofmLQPZzdWzooCBa s3Y2tuRtkvFgcZoDKJoo7sorV6yyeRwA+QZpvyS1A7cpsqxjB7jevoXrIFhjs79safz+/Ou/AgMB AAGjggGGMIIBgjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVzdC50ZWxp YS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nzb24/Y2Vy dGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAlBgNVHREEHjAcgRp3YXNzaW0uaGFk ZGFkQGVyaWNzc29uLmNvbTBGBgNVHSAEPzA9MDsGBiqFcGsBATAxMC8GCCsGAQUFBwIBFiNodHRw Oi8vd3d3LmVyaWNzc29uLmNvbS9sZWdhbC5zaHRtbDAdBgNVHQ4EFgQUiY5imSIHErhSp2V+9kdO JARmWScwHwYDVR0jBBgwFoAUlifDuN6lX11EPjlS5UWxdl9jMJswDgYDVR0PAQH/BAQDAgWgMA0G CSqGSIb3DQEBBQUAA4IBAQBIXqbs40JZUFTT/PWl6A0c3S85eU48TVXuwP2wkVhrBUz+45qAo0Yo FV3gDreoDoFGRFlHS5UiID7OUUyY4JJ0BCoqTPU6DGFjruZVNWk6gaL0WiFgqp0ro4CtysRmV1r1 no3JAaVcvZ4Hf7kOx2SxvresNlGlcDqk7eEABucmHNeQdDLCr61Ssrv3/Z6nMlI1IVLydpvqwgB8 7a0tqeejE3+QpTF0mLZWp1YYKz8hYSMX7MyJug372fN3MgWl7KiV0TOPMSn+yJZemwGl3xVmoT7j N/1/J6ApI5bLJrLNUT2UYjnBAyw3RIrzYoMuHJZu9L0f1gBPC8tLC0FsDEjAMYICFTCCAhECAQEw TjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QTAxAhEA2FT1MsDso7cIf8ep5YX0vzAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMzExOTU3NTJaMCMGCSqGSIb3DQEJBDEWBBRqmtfy WCWk6xVRv4pLS3o3M5D4wDBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQDYVPUywOyjtwh/x6nlhfS/MF8G CyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhEA2FT1MsDso7cIf8ep5YX0vzANBgkqhkiG9w0BAQEFAASBgBHh yVI7Nb9ZZqcTcsZXzaSd4fTkcODCVxUT3Y+2kxCtDyVzR0icHkjunDvLMbyGAA05+PtdJJyyc8VB E039YzdsctIQF+mIeGPy5MDBSjBG5jicmrCBmzpOglJGISk5uSXCoJ+FR9C/FCIc3dZjauPRnpyR ei3pwJ7BgyflfUcLAAAAAAAA --Apple-Mail=_C6832CB0-2E07-4C01-BABD-ECE3529FA0B5-- From jhw@apple.com Mon Oct 31 13:48:59 2011 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 5FC6111E827A for ; Mon, 31 Oct 2011 13:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToVxiVVA7UDI for ; Mon, 31 Oct 2011 13:48:59 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 02A7D11E8279 for ; Mon, 31 Oct 2011 13:48:59 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hAKAL1JoiCzViEdpfdHPwA)" Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LTY00IRL75GIW33@mail-out.apple.com> for homenet@ietf.org; Mon, 31 Oct 2011 13:48:56 -0700 (PDT) X-AuditID: 11807137-b7c56ae0000051ed-4d-4eaf09b82833 Received: from ba0301a-dhcp89.apple.com (ba0301a-dhcp89.apple.com [17.193.14.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 18.DD.20973.8B90FAE4; Mon, 31 Oct 2011 13:48:56 -0700 (PDT) From: james woodyatt Date: Mon, 31 Oct 2011 13:48:56 -0700 In-reply-to: <2850A807-6BA3-4817-B2F0-ADE1D78E0C54@ericsson.com> To: "homenet@ietf.org Group" References: <20111024201837.8598.92335.idtracker@ietfa.amsl.com> <90B01617-3743-4B6A-99D1-F0159BB56331@orandom.net> <69D5F8A3-7A6D-4307-8024-695512792D5B@townsley.net> <2850A807-6BA3-4817-B2F0-ADE1D78E0C54@ericsson.com> Message-id: X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUieJDvpu4OzvV+Bl0TZSzeLzrE4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujB87/jIXvBGr2HX7AXsD4xKRLkZODgkBE4npU9pZIWwxiQv3 1rN1MXJxCAmsYJJYuKuBHSTBJqAi8e3yXSYQm1fAWGLNrXcsIDazQILEjD9HGUFsYYFAiZ3P N4LFWQRUJeZe3coGYnMKOEjMfvUCbIGIgL7E0yO/oBb0M0lMevENKMEBNNRGYssVJogj5CVa vt5hm8DIOwvJullI1kHY2hLLFr5mngXUzSygIzF5IZowhP3x/BGmBYxsqxgFi1JzEisNzfQS CwpyUvWS83M3MYICr6HQfAfj9r9yhxgFOBiVeHh/7lvnJ8SaWFZcmXuIUYKDWUmE138ZUIg3 JbGyKrUoP76oNCe1+BCjNAeLkjjvhLdAKYH0xJLU7NTUgtQimCwTB6dUA2PRtsN3O5aquEk5 LpxfbLFG8TuD1r4nDAmzjv+ay+WytOR5dFOy23HNolf9tja37nUp9fv+nWu31mGW3bHseIcG kUVdbzpq1e3KmD02MV28oTUnUuQK/65XkS3HA0vPu9z10n2SnLugbGpJl30xz9bkpb8ljW+H SlvfyZJhyjQ8e7QkvfV/jxJLcUaioRZzUXEiAANmbtk4AgAA Subject: Re: [homenet] I-D Action: draft-haddad-homenet-gateway-visibility-00.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: Mon, 31 Oct 2011 20:48:59 -0000 --Boundary_(ID_hAKAL1JoiCzViEdpfdHPwA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT everyone-- I am now thoroughly confused. I completely fail to understand how the proposal in section 4 follows from the motivation described in section 3. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_hAKAL1JoiCzViEdpfdHPwA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

                    --
                    james woodyatt <jhw@apple.com>
                    member of technical staff, core os = networking



                    = --Boundary_(ID_hAKAL1JoiCzViEdpfdHPwA)-- From nordmark@cisco.com Mon Oct 31 18:26:49 2011 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 0420511E809A for ; Mon, 31 Oct 2011 18:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3j4dlIFVixT for ; Mon, 31 Oct 2011 18:26:48 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DF46411E8097 for ; Mon, 31 Oct 2011 18:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nordmark@cisco.com; l=1335; q=dns/txt; s=iport; t=1320110805; x=1321320405; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Wf6fb/zK6xnG+8tlJfYmgkp68LOMxE81DFsEDyxcN0g=; b=VNIOcCfn2e1ClfYLKgd69zXwTm+UqzmVhGeDGiC2nAFhXH6OS5Jk3kxm 7y64kU/l1LXoA3XPJ18lChn84VZHutLQaBxB7jk63ggGgr8gr8NV/LVj9 Mez0VHGEcqgSgexWOHXjy9O71aRIVAzxse0zQiA8r28UgpB4ViItoC1WH U=; X-IronPort-AV: E=Sophos;i="4.69,435,1315180800"; d="scan'208";a="10299196" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 01 Nov 2011 01:26:44 +0000 Received: from [10.0.1.13] (sjc-vpn6-1874.cisco.com [10.21.127.82]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA11Qhx6006631; Tue, 1 Nov 2011 01:26:43 GMT Message-ID: <4EAF4AD5.50303@cisco.com> Date: Mon, 31 Oct 2011 18:26:45 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <20111029153139.31713.66593.idtracker@ietfa.amsl.com> In-Reply-To: <20111029153139.31713.66593.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111029153139.31713.66593.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] Fwd: New Version Notification for draft-chakrabarti-homenet-prefix-alloc-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, 01 Nov 2011 01:26:49 -0000 -------- Original Message -------- Subject: New Version Notification for draft-chakrabarti-homenet-prefix-alloc-01.txt Date: Sat, 29 Oct 2011 08:31:39 -0700 From: internet-drafts@ietf.org To: nordmark@cisco.com CC: samita.chakrabarti@ericsson.com, nordmark@cisco.com, wassim.haddad@ericsson.com, suresh.krishnan@ericsson.com A new version of I-D, draft-chakrabarti-homenet-prefix-alloc-01.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-chakrabarti-homenet-prefix-alloc Revision: 01 Title: Simple Approach to Prefix Distribution in Basic Home Networks Creation date: 2011-10-28 WG ID: Individual Submission Number of pages: 24 Abstract: Modern IPv4 home networks are often configured with multi-level of NATs and Residential gateways to separate islands of networks used for different purposes. With the introduction of IPv6 home networks we'd like to be able to maintain the same topological freedom as we have with IPv4 but without requiring any IPv6 NATs. This document specifies the topological restrictions for what we term Basic Home Networks and specifies how DHCPv6 Prefix Delegation can be used to autoconfigure IPv6 address prefixes in such networks. The IETF Secretariat