From mark@townsley.net Fri Jul 1 01:02:05 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95121F88A5; Fri, 1 Jul 2011 01:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wUoPGfsy0H5; Fri, 1 Jul 2011 01:02:04 -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 A138221F88A3; Fri, 1 Jul 2011 01:02:03 -0700 (PDT) Received: by wyj26 with SMTP id 26so2342021wyj.31 for ; Fri, 01 Jul 2011 01:02:02 -0700 (PDT) Received: by 10.216.229.220 with SMTP id h70mr874611weq.1.1309507322743; Fri, 01 Jul 2011 01:02:02 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fu18sm2164925wbb.10.2011.07.01.01.02.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 01:02:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-487637714 From: Mark Townsley In-Reply-To: <4E0D0281.3020608@raszuk.net> Date: Fri, 1 Jul 2011 10:01:59 +0200 Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <4E0D0281.3020608@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org, homegate@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:02:05 -0000 --Apple-Mail-1-487637714 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 1, 2011, at 1:10 AM, Robert Raszuk wrote: >=20 > I think this is a great WG proposal and I fully support it's creation. >=20 > However my ISP is telling me that it has sufficient pool of IPv4 = addresses for the min next 5-10 years so rolling v6 for residential = users is completely not that much appealing to him. My ISP has v6 to a half-million homes and doesn't know how to deal with = multiple v6 subnets (among other things) aside of manual configuration. = But let's stay out of "my ISP says" discussions. Clearly, we can come up = with anecdotes at every extreme. What's important is that, globally, = IPv6 deployment is finally on the rise and implementations are appearing = in commercial products targeted at the home.=20 You are probably running IPv6 in your home anyway if you have a Mac, = linux, or windows machine circa Vista or later. It may be disconnected = from the Internet (or is possibly connected via some automatic tunnel = that you may or may not be aware of), but even link-local IPv6 in the = home is something that should work correctly.=20 >=20 > IETF can build many specs recommending v6 deployments, protocol = extensions and network architectures. Unfortunately before the day when = there is first attractive real content available online _only_ via v6 or = when there is new killer app which works only over v6 I think the world = will become more and more fragmented into islands of v4, v4v6 and v6 = only. >=20 > The issue is not technical here and IETF will not I am afraid be able = to fix it. There are technical issues with deploying IPv6 in the home, and that is = what homenet is slated to work on.=20 > The issue is purely business driven and till all providers get clear = message from their users that they must have v6 as they can not google = anymore, pay their bills, use new fancy holographic movie downloader app = (just as examples) the migration towards v6 may take not 10 but 50 to = 100 years. Ah yes, the Killer App - it would all too easy if IPv6 had a visicalc or = wordstar equivalent to drive sales, wouldn't it?=20 http://en.wikipedia.org/wiki/Killer_application That discussion is not really within the scope of this WG though. - Mark >=20 > Cheers, > R. > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun --Apple-Mail-1-487637714 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I think this is a great WG proposal and I fully = support it's creation.

However my ISP is telling me that it has = sufficient pool of IPv4 addresses for the min next 5-10 years so rolling = v6 for residential users is completely not that much appealing to = him.

My ISP has v6 to a = half-million homes and doesn't know how to deal with multiple v6 subnets = (among other things) aside of manual configuration. But let's stay = out of "my ISP says" discussions. Clearly, we can come up with anecdotes = at every extreme. What's important is that, globally, IPv6 deployment is = finally on the rise and implementations are appearing in commercial = products targeted at the home. 

You are = probably running IPv6 in your home anyway if you have a Mac, linux, or = windows machine circa Vista or later. It may be disconnected from the = Internet (or is possibly connected via some automatic tunnel that you = may or may not be aware of), but even link-local IPv6 in the home is = something that should work correctly. 


IETF can build many specs recommending v6 = deployments, protocol extensions and network architectures. = Unfortunately before the day  when there is first attractive real = content available online _only_ via v6 or when there is new killer app = which works only over v6 I think the world will become more and more = fragmented into islands of v4, v4v6 and v6 only.

The issue is not = technical here and IETF will not I am afraid be able to fix = it.

There are technical issues = with deploying IPv6 in the home, and that is what homenet is slated to = work on. 

The issue is = purely business driven and till all providers get clear message from = their users that they must have v6 as they can not google anymore, pay = their bills, use new fancy holographic movie downloader app (just as = examples) the migration towards v6 may take not 10 but 50 to 100 = years.

Ah yes, the Killer App - it = would all too easy if IPv6 had a visicalc or wordstar equivalent to = drive sales, wouldn't it? 


That = discussion is not really within the scope of this WG = though.

- Mark


Cheers,
R.
__________________________________= _____________
fun mailing list
fun@ietf.org
https://www.ietf.org/mail= man/listinfo/fun

= --Apple-Mail-1-487637714-- From mark@townsley.net Fri Jul 1 01:06:57 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B9521F886C; Fri, 1 Jul 2011 01:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCiD27R0xQK9; Fri, 1 Jul 2011 01:06:52 -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 8E16D21F884E; Fri, 1 Jul 2011 01:06:51 -0700 (PDT) Received: by wwe5 with SMTP id 5so2013580wwe.13 for ; Fri, 01 Jul 2011 01:06:50 -0700 (PDT) Received: by 10.227.172.13 with SMTP id j13mr2665983wbz.45.1309507610489; Fri, 01 Jul 2011 01:06:50 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fu18sm2167622wbb.10.2011.07.01.01.06.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 01:06:49 -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: Fri, 1 Jul 2011 10:06:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org, homegate@ietf.org Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:06:57 -0000 On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote: > I also think that this deals with an important topic and the list of = items listed on the proposed charter are quite relevant. I'm just not = entirely clear on the "routing component": are you referring to: > * A requirement document for Routing in the home? At least a section within a home architecture document. > * A recommendation for a specific routing protocol ? > * A framework before the specification of a new routing protocol ? The charter says: "For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default." - Mark > I'm clearly not expressing an opinion, just a question. > Thanks. > JP. >=20 > JP Vasseur > Cisco Fellow >=20 > Sent from Blackberry >=20 > ----- Original Message ----- > From: Mark Townsley [mailto:mark@townsley.net] > Sent: Thursday, June 30, 2011 11:36 AM > To: Weil, Jason > Cc: fun@ietf.org ; homegate@ietf.org > Subject: Re: [fun] status of the homenet effort >=20 >=20 > Thank you for the feedback, keep it coming. >=20 > On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: >=20 >> Mark, Raplh, Jari, et all, >>=20 >> I really appreciate the change in charter and direction for this = proposed >> WG and the interest to keep it going. I believe it sets a path that = is >> scoped narrow enough to provide a workplace for achievable results. >>=20 >> As a provider working on writing, testing and implementing IPv6 CPE, = I can >> relate firsthand that getting basic IPv6 functionality working in the = home >> network is no simple feat and is still a work in progress. Don't get = me >> wrong, basic functionality is there just not baked. What seems very >> straightforward in theory typically fails in a multitude of corner = cases >> ie reality. And just to clarify I am referring to a single /64 subnet >> topology with no routing. >>=20 >> If we can stay focussed on solving just the basics for the five areas >> included, I believe it will be helpful. The other recommendation = would be >> to work as expeditiously as possible. Providers in the process of >> deploying IPv6 now are already deep into this analysis and = development >> with their vendors. If we wait too long then these topics will be = solved >> with interoperability a possible casualty. >>=20 >> FWIW, I would also add that the five topics in the charter are also = listed >> in order >> Of priority at least for me. >>=20 >>=20 >> Thanks, >>=20 >> Jason >>=20 >>=20 >> On 6/29/11 5:46 AM, "Mark Townsley" wrote: >>=20 >>>=20 >>> All, >>>=20 >>> Apologies for double-posting if there are folks that are subscribed = to >>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone = will >>> finally create homenet@ietf.org and consolidate the membership >>> accordingly. >>>=20 >>> In the charter proposal below, I think you will see a lot of = similarity >>> with the consensus we achieved on the homegate list last year. Jari = has >>> taken that, feedback from the IESG, IAB, members of the = IP-Directorate, >>> v6ops chairs, etc. and shaped it towards something more focused on = the >>> Internet (and Routing) area, as well as IPv6. I believe he and Ralph = both >>> have a great deal of confidence that this is something that is very >>> important to the industry, and that the IETF has a critical role to = play. >>>=20 >>> So, make no mistake, whether we end up as a WG or a BoF between now = and >>> Quebec, "we're back" - please send comments, and make your travel or >>> remote-attendance plans accordingly if you want to participate. >>>=20 >>> Jari has asked me to co-chair the session in Quebec. As such, I'd = like to >>> take requests for presentation time now. Jari and I will likely = begin the >>> session with a scoping overview, as well as a first cut at an >>> architecture framework, but there should be some time for a few = other >>> items. When submitting your request, please identify which of the 5 = areas >>> below you think your work applies to as well as the internet-draft, = of >>> course. >>>=20 >>> Thanks, and see you on the list and in Quebec. >>>=20 >>> - Mark >>>=20 >>>=20 >>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>>=20 >>>> I wanted to provide an update of the situation with this working = group >>>> proposal. >>>>=20 >>>> HOMENET is a new working group proposal, a variation of the >>>> HOMEGATE/HOMENET theme that we discussed last year, but this time >>>> looking at it from a different angle. The old effort was mostly = focused >>>> about what home gateways should do: forwarding, transport, and DNS >>>> proxying issues. The new effort is about home networks themselves, = in >>>> particular what kind of network architecture and configuration is >>>> necessary to support IPv6-based home networks. We view IPv4-based = home >>>> networks as "done" at this time (or perhaps as "cannot be changed >>>> anyway"). >>>>=20 >>>> I have been discussing this effort in the background for the last >>>> couple of month with Mark Townsley and others, and more publicly = since >>>> early June. The proposal has been brought to the IESG, IAB and some >>>> directorates for discussion, and we've been going back and forth = whether >>>> this is ready to become a working group or needs to be run as a BOF = in >>>> Quebec City. The current plan is that the working group proposal = goes to >>>> IETF-wide review this week, and if the feedback from the community, = IAB, >>>> and the IESG is positive, we will create the working group just in = time >>>> for the IETF. Otherwise, the slot reserved in the agenda for the = meeting >>>> will be used to run the proposal as a BOF. >>>>=20 >>>> In any case, I would like to solicit discussion on this topic, and >>>> perhaps some early drafts as well. Please comment on the charter at >>>> least. >>>>=20 >>>> Note that the new proposal was called FUN at the time that we = created >>>> the list. It has now been renamed back to HOMENET to be more >>>> descriptive. The list will be renamed soon as well (current = subscribers >>>> will stay). >>>>=20 >>>> This is the most recent version of the charter we should discuss: >>>>=20 >>>> Home Networks (homenet) >>>> ----------------------------------- >>>>=20 >>>> Current Status: Proposed >>>> Last Edit: Wednesday, June 29th, 2011 >>>>=20 >>>> Chairs: >>>> TBD >>>>=20 >>>> Internet Area Directors: >>>> Ralph Droms >>>> Jari Arkko >>>>=20 >>>> Internet Area Advisor: >>>> Jari Arkko >>>>=20 >>>> Routing Area Technical Advisor: >>>> TBD >>>>=20 >>>> Security Area Technical Advisor: >>>> TBD >>>>=20 >>>> Mailing Lists: >>>> General Discussion: fun@ietf.org >>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>>> Archive: http://www.ietf.org/mail-archive/web/fun >>>>=20 >>>> Description of Working Group: >>>>=20 >>>> This working group focuses on the evolving networking technology >>>> within and among relatively small =B3residential home=B2 networks. = For >>>> example, an obvious trend in home networking is the proliferation = of >>>> networking technology in an increasingly broad range and number of >>>> devices. This evolution in scale and diversity sets some = requirements >>>> on IETF protocols. Some of the relevant trends include: >>>>=20 >>>> o Multiple segments: While less complex L3-toplogies involving as = few >>>> subnets as possible are preferred in home networks for a variety of >>>> reasons including simpler management and service discovery, the >>>> introduction of more than one subnet into a home network is enough >>>> to add complexity that needs to be addressed, and multiple >>>> dedicated segments are necessary for some cases. For instance, a >>>> common feature in modern home routers in the ability to support >>>> both guest and private network segments. Also, link layer >>>> networking technology is poised to become more heterogeneous, as >>>> networks begin to employ both traditional Ethernet technology and >>>> link layers designed for low-powered sensor networks. Finally, >>>> similar needs for segmentation may occur in other cases, such as >>>> separating building control or corporate extensions from the >>>> Internet access network. Different segments may be associated with >>>> subnets that have different routing and security policies. >>>>=20 >>>> o Service providers are deploying IPv6, and support for IPv6 is >>>> increasingly available in home gateway devices. While IPv6 = resembles >>>> IPv4 in many ways, it changes address allocation principles and = allows >>>> direct IP addressability and routing to devices in the home from = the >>>> Internet. This is a promising area in IPv6 that has proved = challenging >>>> in IPv4 with the proliferation of NAT. >>>>=20 >>>> o End-to-end communication is both an opportunity and a concern as = it >>>> enables new applications but also exposes nodes in the internal >>>> networks to receipt of unwanted traffic from the Internet. = Firewalls >>>> that restrict incoming connections may be used to prevent exposure, >>>> however, this reduces the efficacy of end-to-end connectivity that >>>> IPv6 has the potential to restore. >>>>=20 >>>> Home networks need to provide the tools to handle these situations = in >>>> a manner accessible to all users of home networks. Manual >>>> configuration is rarely, if at all, possible. The purpose of this >>>> working group is to focus on this evolution, in particular as it >>>> addresses the introduction of IPv6, by developing an architecture >>>> addressing this full scope of requirements: >>>>=20 >>>> o prefix configuration for routers >>>> o managing routing >>>> o name resolution >>>> o service discovery >>>> o network security >>>>=20 >>>> The task of the group is to produce an architecture document that >>>> outlines how to construct home networks involving multiple routers = and >>>> subnets. This document is expected to apply the IPv6 addressing >>>> architecture, prefix delegation, global and ULA addresses, source >>>> address selection rules and other existing components of the IPv6 >>>> architecture. The architecture document should drive what protocols >>>> changes, if any, are necessary. Specific protocol work described = below >>>> is expected to be within the scope of the working group one the >>>> architecture work is complete. However, the group is required to >>>> review its charter and milestones with the IESG and IETF community >>>> before submitting documents that make protocol changes. It is = expected >>>> that the group has to discuss some of the below solutions, however, = in >>>> order to complete the architecture work. >>>>=20 >>>> The group will apply existing protocols to handle the five >>>> requirements above. For prefix configuration, existing protocols = are >>>> likely sufficient, and at worst may need some small enhancements, = such >>>> as new options. For automatic routing, it is expected that existing >>>> routing protocols can be used as is, however, a new mechanism may = be >>>> needed in order to turn a selected protocol on by default. For name >>>> resolution and service discovery, extensions to existing >>>> multicast-based name resolution protocols are needed to enable them = to >>>> work across subnets. >>>>=20 >>>> For network security, the group shall document the concept of >>>> "advanced security" as a further development of "simple security" = from >>>> RFC 6092. The main goal of this work is to enable a security policy >>>> that adapts to IPv6 threats as they emerge, taking into account not >>>> only traffic from the Internet at large, but within and leaving the >>>> home network itself. >>>>=20 >>>> It is expected that the working group will define a set of protocol >>>> specifications to accomplish the five requirements from >>>> above. However, it is not in the scope of the working group to = define >>>> entirely new routing protocols or address allocation protocols. As >>>> noted, additional options or other small extensions may be = necessary >>>> to use the existing protocols in these new configuration tasks. The >>>> working group shall also not make any changes to IPv6 protocols or >>>> addressing architecture. Prefix configuration, routing, and = security >>>> related work shall not cause any changes that are not backwards >>>> compatible to existing IPv6 hosts. There may be host visible = changes >>>> in the work on naming and discovery protocols, however. In its = design, >>>> the working group shall also consider security aspects and the = impact >>>> on manageability. The main focus of the working group is home >>>> networks, but the group's results may also find applications in = other >>>> small networks. >>>>=20 >>>> The working group will liaise with the relevant IETF working >>>> groups. In particular, the group should work closely with the V6OPS >>>> working group, review any use or extension of DHCP with the DHC >>>> working group, and work with additional DNS requirements with the >>>> DNSEXT and DNSOP working groups. If it turns out that additional >>>> options are needed for a routing protocol, they will be developed = in >>>> the appropriate Routing Area working group, with the HOMENET = working >>>> group providing the architecture and requirements for such >>>> enhancements. The working group will also liase with external >>>> standards bodies where it is expected that there are normative >>>> dependencies between the specifications of the two bodies. >>>> It is expected that in the architecture definition stage liaising >>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>>=20 >>>> Milestones: >>>>=20 >>>> Jul 2011 Formation of the working group >>>> Sep 2011 First WG draft on the architecture >>>> Dec 2011 Submission of the architecture draft to the IESG as >>>> Informational RFC >>>> Dec 2011 Charter re-evaluation based on the architecture work >>>> Dec 2011 First WG draft on prefix configuration >>>> Dec 2011 First WG draft on routing >>>> Jan 2012 First WG draft on name resolution >>>> Feb 2012 First WG draft on service discovery >>>> Feb 2012 First WG draft on perimeter security >>>> Feb 2012 Start of routing related work in the relevant routing area >>>> working group, if needed >>>> Mar 2012 Submission of the prefix configuration draft to the IESG = as >>>> Standards Track RFC >>>> Apr 2012 Submission of the routing draft to the IESG as = Informational >>>> RFC >>>> Sep 2012 Submission of the name resolution draft to the IESG as >>>> Standards Track RFC >>>> Nov 2012 Submission of the service discovery draft to the IESG as >>>> Standards Track RFC >>>> Dec 2012 Submission of the perimeter security draft to the IESG as >>>> Informational RFC >>>>=20 >>>> _______________________________________________ >>>> fun mailing list >>>> fun@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fun >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >>=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. >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From mark@townsley.net Fri Jul 1 01:53:44 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9F721F87AA; Fri, 1 Jul 2011 01:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM0+oPmkZUNK; Fri, 1 Jul 2011 01:53:43 -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 0965C21F86F4; Fri, 1 Jul 2011 01:53:42 -0700 (PDT) Received: by wyj26 with SMTP id 26so2373562wyj.31 for ; Fri, 01 Jul 2011 01:53:41 -0700 (PDT) Received: by 10.216.132.214 with SMTP id o64mr2564631wei.75.1309510421783; Fri, 01 Jul 2011 01:53:41 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id u38sm700625weq.37.2011.07.01.01.53.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 01:53:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Fri, 1 Jul 2011 10:53:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B6FEF9D-430B-4C56-BB21-40C5ED888B51@townsley.net> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion , homegate@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:53:44 -0000 On Jun 30, 2011, at 6:36 PM, Keith Moore wrote: > On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote: >>>>=20 >>>> I think the consensus we had in the past BoFs and discussion in and = around this topic can be summed up as stating that homenet deliverables = will: >>>>=20 >>>> - coexist with (existing) IPv4 protocols, devices, applications, = etc. >>>> - operate in a (future) IPv6-only home network in the absence of = IPv4 >>>> - be IP-agnostic whenever possible >>>=20 >>> I'd like for this group to relax the "wherever possible" bit, so as = to not preclude solutions where IPv6 can do a better job than IPv4. >>=20 >> Yes, and I think that IPv6 should naturally do a better job than IPv4 = in the cases where it can.=20 >>=20 >> My original mail had this restatement of the above, which I think = gets closer to what you want: >>=20 >>>> However, when we can define something that is needed for IPv6 in a = way that is also useful for IPv4 without making significant concessions, = we should go ahead and do so. >=20 > when the group can define something that is useful in IPv6, it = shouldn't matter whether it's also useful for IPv4. The idea is not to go out of our way for IPv4, but if the topic is IP = agnostic anyway, so be it. To be clear, there is no *requirement* to = support IPv4 here. However, there is no requirement to avoid IPv4 *if* = it doesn't cause significant concession in the IPv6 design either. This cuts both ways, if there is something that is working well in IPv4 = that we need to carry over to IPv6 with simple extensions, we'll do that = and capitalizing on that running-code should be considered a good thing. = We don't want to invent new v6 protocols from scratch that don't work = with IPv4 when there is no need. For example (and I think this is hinted = at in the charter), we might use naming and service discovery that = already exists for IPv4, adapted the the v6 homenet. This doesn't mean = we need to re-invent a v6-only naming system from scratch - i'd much = rather use one that is there, which very well may support v4 and v6.=20 >=20 > please don't constrain home networks to work only within the confines = of IPv4 brain damage. What I think I am saying here is that we will do our best to perform as = if our brains are not damaged, and equally try to avoid damaging our = brains in the process. - Mark >=20 > Keith >=20 > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From soohongp@gmail.com Fri Jul 1 02:00:25 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7D921F8892 for ; Fri, 1 Jul 2011 02:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OLrp6v6GkCu for ; Fri, 1 Jul 2011 02:00:24 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0F121F87B0 for ; Fri, 1 Jul 2011 02:00:24 -0700 (PDT) Received: by pzk5 with SMTP id 5so3534870pzk.31 for ; Fri, 01 Jul 2011 02:00:23 -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=9ChQY/7MPAUkO28tcwZICH3KzdpDz4lUGbipKuKXPt0=; b=gct2NdkYxBta8Eh5IJHiOoZSqjwv0WwuvJ2XCEBDChilIdc32X6YO6XomR81JClxkD G6cnYRUcCXQRj84ufERf/aZLJ1WZCqFXG/qg877lJT5zyR8TmeI2cBvmvBvY/fLLnyby aD0TCK6ihw/Poke9HiGjuYSpgJ9WCAt/UvFvw= Received: by 10.68.57.209 with SMTP id k17mr3155800pbq.357.1309510823573; Fri, 01 Jul 2011 02:00:23 -0700 (PDT) Received: from [14.33.139.145] ([14.33.139.145]) by mx.google.com with ESMTPS id q5sm1904809pbk.58.2011.07.01.02.00.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 02:00:22 -0700 (PDT) References: <4E0AE3CF.2070504@piuha.net> <4E0CB009.9070104@piuha.net> In-Reply-To: <4E0CB009.9070104@piuha.net> Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (8J3) From: Soohong Daniel Park Date: Fri, 1 Jul 2011 18:01:12 +0900 To: Jari Arkko Cc: "fun@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 09:00:25 -0000 Presumably, the architrcture includes an analysis work considering the curre= nt home networking solutions, particulary DLNA. Correct? In fact, DLNA did t= he IPv6 over DLNA work before through a IPv6 Task Force, and came up with th= e whitepaper several years back. IPv6 is not well and widely embedded into D= LNA yet though. Just curious how interop and harmonize between ietf work and= DLNA. The past DLAN deliverable/efforts might be referred, and used for thi= s Homenet work. Daniel, Soohong Daniel Park Samsung Electronics, DMC R&D www.soohongp.com, twitter:@natpt 2011. 7. 1. =EC=98=A4=EC=A0=84 2:19 Jari Arkko =EC=9E= =91=EC=84=B1: > This is just an update that the IESG approved the below charter for extern= al review in its meeting today. "For external review" means that IETF partic= ipants and other people are formally asked to comment on it. The review peri= od runs until July 14th. >=20 > Jari >=20 > Home Networks (homenet) > ----------------------------------- >=20 > Current Status: Proposed > Last Edit: Wednesday, June 30th, 2011 >=20 > Chairs: > TBD >=20 > Internet Area Directors: > Ralph Droms > Jari Arkko >=20 > Internet Area Advisor: > Jari Arkko >=20 > Routing Area Technical Advisor: > TBD >=20 > Security Area Technical Advisor: > TBD >=20 > Mailing Lists: > General Discussion: fun@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/fun > Archive: http://www.ietf.org/mail-archive/web/fun >=20 > Description of Working Group: >=20 > This working group focuses on the evolving networking technology > within and among relatively small =E2=80=9Cresidential home=E2=80=9D netwo= rks. For > example, an obvious trend in home networking is the proliferation of > networking technology in an increasingly broad range and number of > devices. This evolution in scale and diversity sets some requirements > on IETF protocols. Some of the relevant trends include: >=20 > o Multiple segments: While less complex L3-toplogies involving as few > subnets as possible are preferred in home networks for a variety of > reasons including simpler management and service discovery, the > introduction of more than one subnet into a home network is enough > to add complexity that needs to be addressed, and multiple > dedicated segments are necessary for some cases. For instance, a > common feature in modern home routers in the ability to support > both guest and private network segments. Also, link layer > networking technology is poised to become more heterogeneous, as > networks begin to employ both traditional Ethernet technology and > link layers designed for low-powered sensor networks. Finally, > similar needs for segmentation may occur in other cases, such as > separating building control or corporate extensions from the > Internet access network. Different segments may be associated with > subnets that have different routing and security policies. >=20 > o Service providers are deploying IPv6, and support for IPv6 is > increasingly available in home gateway devices. While IPv6 resembles > IPv4 in many ways, it changes address allocation principles and allows > direct IP addressability and routing to devices in the home from the > Internet. This is a promising area in IPv6 that has proved challenging > in IPv4 with the proliferation of NAT. >=20 > o End-to-end communication is both an opportunity and a concern as it > enables new applications but also exposes nodes in the internal > networks to receipt of unwanted traffic from the Internet. Firewalls > that restrict incoming connections may be used to prevent exposure, > however, this reduces the efficacy of end-to-end connectivity that > IPv6 has the potential to restore. >=20 > Home networks need to provide the tools to handle these situations in > a manner accessible to all users of home networks. Manual > configuration is rarely, if at all, possible, as the necessary skills > and in some cases even suitable management interfaces are missing. >=20 > The purpose of this working group is to focus on this evolution, in > particular as it addresses the introduction of IPv6, by developing an > architecture addressing this full scope of requirements: >=20 > o prefix configuration for routers > o managing routing > o name resolution > o service discovery > o network security >=20 > The task of the group is to produce an architecture document that > outlines how to construct home networks involving multiple routers and > subnets. This document is expected to apply the IPv6 addressing > architecture, prefix delegation, global and ULA addresses, source > address selection rules and other existing components of the IPv6 > architecture. The architecture document should drive what protocols > changes, if any, are necessary. Specific protocol work described below > is expected to be within the scope of the working group once the > architecture work is complete. However, the group is required to > review its charter and milestones with the IESG and IETF community > before submitting documents that make protocol changes. It is expected > that the group has to discuss some of the below solutions, however, in > order to complete the architecture work. >=20 > The group will apply existing protocols to handle the five > requirements above. For prefix configuration, existing protocols are > likely sufficient, and at worst may need some small enhancements, such > as new options. For automatic routing, it is expected that existing > routing protocols can be used as is, however, a new mechanism may be > needed in order to turn a selected protocol on by default. For name > resolution and service discovery, extensions to existing > multicast-based name resolution protocols are needed to enable them to > work across subnets. >=20 > For network security, the group shall document the concept of > "advanced security" as a further development of "simple security" from > RFC 6092. The main goal of this work is to enable a security policy > that adapts to IPv6 threats as they emerge, taking into account not > only traffic from the Internet at large, but within and leaving the > home network itself. >=20 > It is expected that the working group will define a set of protocol > specifications to accomplish the five requirements from > above. However, it is not in the scope of the working group to define > entirely new routing protocols or address allocation protocols. As > noted, additional options or other small extensions may be necessary > to use the existing protocols in these new configuration tasks. The > working group shall also not make any changes to IPv6 protocols or > addressing architecture. Prefix configuration, routing, and security > related work shall not cause any changes that are not backwards > compatible to existing IPv6 hosts. There may be host visible changes > in the work on naming and discovery protocols, however. In its design, > the working group shall also consider security aspects and the impact > on manageability. The main focus of the working group is home > networks, but the group's results may also find applications in other > small networks. >=20 > The working group will liaise with the relevant IETF working > groups. In particular, the group should work closely with the V6OPS > working group, review any use or extension of DHCP with the DHC > working group, and work with additional DNS requirements with the > DNSEXT and DNSOP working groups. If it turns out that additional > options are needed for a routing protocol, they will be developed in > the appropriate Routing Area working group, with the HOMENET working > group providing the architecture and requirements for such > enhancements. The working group will also liase with external > standards bodies where it is expected that there are normative > dependencies between the specifications of the two bodies. > It is expected that in the architecture definition stage liaising > with the Broadband Forum, DLNA, and UPnP Forum is necessary. >=20 > Milestones: >=20 > Jul 2011 Formation of the working group > Sep 2011 First WG draft on the architecture > Dec 2011 Submission of the architecture draft to the IESG as Informational= RFC > Dec 2011 Charter re-evaluation based on the architecture work > Dec 2011 First WG draft on prefix configuration > Dec 2011 First WG draft on routing > Jan 2012 First WG draft on name resolution > Feb 2012 First WG draft on service discovery > Feb 2012 First WG draft on perimeter security > Feb 2012 Start of routing related work in the relevant routing area workin= g group, if needed > Mar 2012 Submission of the prefix configuration draft to the IESG as Stand= ards Track RFC > Apr 2012 Submission of the routing draft to the IESG as Informational RFC > Sep 2012 Submission of the name resolution draft to the IESG as Standards T= rack RFC > Nov 2012 Submission of the service discovery draft to the IESG as Standard= s Track RFC > Dec 2012 Submission of the perimeter security draft to the IESG as Informa= tional RFC >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From martyf@gmail.com Thu Jun 30 18:34:45 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25A11E81D6; Thu, 30 Jun 2011 18:34:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBAxyWyqpwwC; Thu, 30 Jun 2011 18:34:44 -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 4FF1111E810B; Thu, 30 Jun 2011 18:34:44 -0700 (PDT) Received: by bwb17 with SMTP id 17so2687770bwb.31 for ; Thu, 30 Jun 2011 18:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Cw2sj0iBy1I9ZPefltxqW9BDDjpqHGlALkVYeVg8XRo=; b=LE0JtNL4Dc81th6rzAZhfC9dDIMGjX79khL+p8cT5lv40CjyD12/v7+AZ4Q0xglE9t dO+li4VJpm9iNUndVWlon+yukdXWK+FQB2vUUb12SC/GlCe0SjrcvksU3i3V6Ku/77ry NJrs5R/JTBUu6lq9aDE9JC85M7pCrcVGXNKiw= Received: by 10.204.7.194 with SMTP id e2mr2448875bke.134.1309484035817; Thu, 30 Jun 2011 18:33:55 -0700 (PDT) References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <4E0D0281.3020608@raszuk.net> From: Martin Focazio In-Reply-To: Mime-Version: 1.0 (iPad Mail 8G4) Date: Thu, 30 Jun 2011 21:34:10 -0400 Message-ID: <-4529087406481929693@unknownmsgid> To: james woodyatt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 01 Jul 2011 02:06:43 -0700 Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 01:34:45 -0000 On Jun 30, 2011, at 19:51, james woodyatt wrote: > > The key thing here is that by Alice choosing to use one service provider = over another, she can make Bob's application fail, and vice versa. The mob= ile service providers that don't have enough IPv4 addresses to serve all th= eir customers are in a bind and can't budge. The wireline service provider= s who have 5-10 years of IPv4 addresses in reserve are the ones whistling p= ast the graveyard. > You assume at Alice CAN select a service provider. In a large part of the USA your choices are nil. You have a single wireline provider or you don't have a connection. From jvasseur@cisco.com Thu Jun 30 22:27:28 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D027121F869B; Thu, 30 Jun 2011 22:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLuJtkiuTc66; Thu, 30 Jun 2011 22:27:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id F17EC21F8696; Thu, 30 Jun 2011 22:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=15713; q=dns/txt; s=iport; t=1309498044; x=1310707644; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=uaUm9vbvJnqfI0fKoFk0oPAkuW0/YEU+2x93kO1dSII=; b=YH8QhwaVL4cad8Q+ZYYHus3ulPyxw1HVCFzVmklHwqTuj7lk62szEnfv VLZglQJmepVMGlCDFtoCFKrIL37PRKBrXnLrFM6bWFoXL34ZiIMbhOrfc pZ//T4Eu375C3/1zWW2u3816rYT/ZokvLmlUoB9Zde8phApFBOM5j1bR3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAI9ZDU6tJXG//2dsb2JhbABEDpgrjzJ3iHmiJJ1xgx8TgwAEhz6PcYRHhwg X-IronPort-AV: E=Sophos;i="4.65,456,1304294400"; d="scan'208";a="351128749" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 05:27:22 +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 p615RM2Q016713; Fri, 1 Jul 2011 05:27:22 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 00:27:22 -0500 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: Fri, 1 Jul 2011 00:27:21 -0500 Message-ID: In-Reply-To: <7D900BF0-EA18-4ADA-A447-A9D3A717B61C@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fun] status of the homenet effort Thread-Index: Acw3RKfd7kxyV7l1RY669+qj09MH3gAauVbb From: "JP Vasseur (jvasseur)" To: , X-OriginalArrivalTime: 01 Jul 2011 05:27:22.0314 (UTC) FILETIME=[8DB4C2A0:01CC37AF] X-Mailman-Approved-At: Fri, 01 Jul 2011 02:06:43 -0700 Cc: fun@ietf.org, homegate@ietf.org Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 05:27:28 -0000 I also think that this deals with an important topic and the list of = items listed on the proposed charter are quite relevant. I'm just not = entirely clear on the "routing component": are you referring to: * A requirement document for Routing in the home? * A recommendation for a specific routing protocol ? * A framework before the specification of a new routing protocol ? I'm clearly not expressing an opinion, just a question. Thanks. JP. JP Vasseur Cisco Fellow Sent from Blackberry ----- Original Message ----- From: Mark Townsley [mailto:mark@townsley.net] Sent: Thursday, June 30, 2011 11:36 AM To: Weil, Jason Cc: fun@ietf.org ; homegate@ietf.org Subject: Re: [fun] status of the homenet effort Thank you for the feedback, keep it coming. On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: > Mark, Raplh, Jari, et all, >=20 > I really appreciate the change in charter and direction for this = proposed > WG and the interest to keep it going. I believe it sets a path that is > scoped narrow enough to provide a workplace for achievable results. >=20 > As a provider working on writing, testing and implementing IPv6 CPE, I = can > relate firsthand that getting basic IPv6 functionality working in the = home > network is no simple feat and is still a work in progress. Don't get = me > wrong, basic functionality is there just not baked. What seems very > straightforward in theory typically fails in a multitude of corner = cases > ie reality. And just to clarify I am referring to a single /64 subnet > topology with no routing. >=20 > If we can stay focussed on solving just the basics for the five areas > included, I believe it will be helpful. The other recommendation would = be > to work as expeditiously as possible. Providers in the process of > deploying IPv6 now are already deep into this analysis and development > with their vendors. If we wait too long then these topics will be = solved > with interoperability a possible casualty. >=20 > FWIW, I would also add that the five topics in the charter are also = listed > in order > Of priority at least for me. >=20 >=20 > Thanks, >=20 > Jason >=20 >=20 > On 6/29/11 5:46 AM, "Mark Townsley" wrote: >=20 >>=20 >> All, >>=20 >> Apologies for double-posting if there are folks that are subscribed = to >> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will >> finally create homenet@ietf.org and consolidate the membership >> accordingly. >>=20 >> In the charter proposal below, I think you will see a lot of = similarity >> with the consensus we achieved on the homegate list last year. Jari = has >> taken that, feedback from the IESG, IAB, members of the = IP-Directorate, >> v6ops chairs, etc. and shaped it towards something more focused on = the >> Internet (and Routing) area, as well as IPv6. I believe he and Ralph = both >> have a great deal of confidence that this is something that is very >> important to the industry, and that the IETF has a critical role to = play. >>=20 >> So, make no mistake, whether we end up as a WG or a BoF between now = and >> Quebec, "we're back" - please send comments, and make your travel or >> remote-attendance plans accordingly if you want to participate. >>=20 >> Jari has asked me to co-chair the session in Quebec. As such, I'd = like to >> take requests for presentation time now. Jari and I will likely begin = the >> session with a scoping overview, as well as a first cut at an >> architecture framework, but there should be some time for a few other >> items. When submitting your request, please identify which of the 5 = areas >> below you think your work applies to as well as the internet-draft, = of >> course. >>=20 >> Thanks, and see you on the list and in Quebec. >>=20 >> - Mark >>=20 >>=20 >> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>=20 >>> I wanted to provide an update of the situation with this working = group >>> proposal. >>>=20 >>> HOMENET is a new working group proposal, a variation of the >>> HOMEGATE/HOMENET theme that we discussed last year, but this time >>> looking at it from a different angle. The old effort was mostly = focused >>> about what home gateways should do: forwarding, transport, and DNS >>> proxying issues. The new effort is about home networks themselves, = in >>> particular what kind of network architecture and configuration is >>> necessary to support IPv6-based home networks. We view IPv4-based = home >>> networks as "done" at this time (or perhaps as "cannot be changed >>> anyway"). >>>=20 >>> I have been discussing this effort in the background for the last >>> couple of month with Mark Townsley and others, and more publicly = since >>> early June. The proposal has been brought to the IESG, IAB and some >>> directorates for discussion, and we've been going back and forth = whether >>> this is ready to become a working group or needs to be run as a BOF = in >>> Quebec City. The current plan is that the working group proposal = goes to >>> IETF-wide review this week, and if the feedback from the community, = IAB, >>> and the IESG is positive, we will create the working group just in = time >>> for the IETF. Otherwise, the slot reserved in the agenda for the = meeting >>> will be used to run the proposal as a BOF. >>>=20 >>> In any case, I would like to solicit discussion on this topic, and >>> perhaps some early drafts as well. Please comment on the charter at >>> least. >>>=20 >>> Note that the new proposal was called FUN at the time that we = created >>> the list. It has now been renamed back to HOMENET to be more >>> descriptive. The list will be renamed soon as well (current = subscribers >>> will stay). >>>=20 >>> This is the most recent version of the charter we should discuss: >>>=20 >>> Home Networks (homenet) >>> ----------------------------------- >>>=20 >>> Current Status: Proposed >>> Last Edit: Wednesday, June 29th, 2011 >>>=20 >>> Chairs: >>> TBD >>>=20 >>> Internet Area Directors: >>> Ralph Droms >>> Jari Arkko >>>=20 >>> Internet Area Advisor: >>> Jari Arkko >>>=20 >>> Routing Area Technical Advisor: >>> TBD >>>=20 >>> Security Area Technical Advisor: >>> TBD >>>=20 >>> Mailing Lists: >>> General Discussion: fun@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>> Archive: http://www.ietf.org/mail-archive/web/fun >>>=20 >>> Description of Working Group: >>>=20 >>> This working group focuses on the evolving networking technology >>> within and among relatively small =B3residential home=B2 networks. = For >>> example, an obvious trend in home networking is the proliferation of >>> networking technology in an increasingly broad range and number of >>> devices. This evolution in scale and diversity sets some = requirements >>> on IETF protocols. Some of the relevant trends include: >>>=20 >>> o Multiple segments: While less complex L3-toplogies involving as = few >>> subnets as possible are preferred in home networks for a variety of >>> reasons including simpler management and service discovery, the >>> introduction of more than one subnet into a home network is enough >>> to add complexity that needs to be addressed, and multiple >>> dedicated segments are necessary for some cases. For instance, a >>> common feature in modern home routers in the ability to support >>> both guest and private network segments. Also, link layer >>> networking technology is poised to become more heterogeneous, as >>> networks begin to employ both traditional Ethernet technology and >>> link layers designed for low-powered sensor networks. Finally, >>> similar needs for segmentation may occur in other cases, such as >>> separating building control or corporate extensions from the >>> Internet access network. Different segments may be associated with >>> subnets that have different routing and security policies. >>>=20 >>> o Service providers are deploying IPv6, and support for IPv6 is >>> increasingly available in home gateway devices. While IPv6 resembles >>> IPv4 in many ways, it changes address allocation principles and = allows >>> direct IP addressability and routing to devices in the home from the >>> Internet. This is a promising area in IPv6 that has proved = challenging >>> in IPv4 with the proliferation of NAT. >>>=20 >>> o End-to-end communication is both an opportunity and a concern as = it >>> enables new applications but also exposes nodes in the internal >>> networks to receipt of unwanted traffic from the Internet. Firewalls >>> that restrict incoming connections may be used to prevent exposure, >>> however, this reduces the efficacy of end-to-end connectivity that >>> IPv6 has the potential to restore. >>>=20 >>> Home networks need to provide the tools to handle these situations = in >>> a manner accessible to all users of home networks. Manual >>> configuration is rarely, if at all, possible. The purpose of this >>> working group is to focus on this evolution, in particular as it >>> addresses the introduction of IPv6, by developing an architecture >>> addressing this full scope of requirements: >>>=20 >>> o prefix configuration for routers >>> o managing routing >>> o name resolution >>> o service discovery >>> o network security >>>=20 >>> The task of the group is to produce an architecture document that >>> outlines how to construct home networks involving multiple routers = and >>> subnets. This document is expected to apply the IPv6 addressing >>> architecture, prefix delegation, global and ULA addresses, source >>> address selection rules and other existing components of the IPv6 >>> architecture. The architecture document should drive what protocols >>> changes, if any, are necessary. Specific protocol work described = below >>> is expected to be within the scope of the working group one the >>> architecture work is complete. However, the group is required to >>> review its charter and milestones with the IESG and IETF community >>> before submitting documents that make protocol changes. It is = expected >>> that the group has to discuss some of the below solutions, however, = in >>> order to complete the architecture work. >>>=20 >>> The group will apply existing protocols to handle the five >>> requirements above. For prefix configuration, existing protocols are >>> likely sufficient, and at worst may need some small enhancements, = such >>> as new options. For automatic routing, it is expected that existing >>> routing protocols can be used as is, however, a new mechanism may be >>> needed in order to turn a selected protocol on by default. For name >>> resolution and service discovery, extensions to existing >>> multicast-based name resolution protocols are needed to enable them = to >>> work across subnets. >>>=20 >>> For network security, the group shall document the concept of >>> "advanced security" as a further development of "simple security" = from >>> RFC 6092. The main goal of this work is to enable a security policy >>> that adapts to IPv6 threats as they emerge, taking into account not >>> only traffic from the Internet at large, but within and leaving the >>> home network itself. >>>=20 >>> It is expected that the working group will define a set of protocol >>> specifications to accomplish the five requirements from >>> above. However, it is not in the scope of the working group to = define >>> entirely new routing protocols or address allocation protocols. As >>> noted, additional options or other small extensions may be necessary >>> to use the existing protocols in these new configuration tasks. The >>> working group shall also not make any changes to IPv6 protocols or >>> addressing architecture. Prefix configuration, routing, and security >>> related work shall not cause any changes that are not backwards >>> compatible to existing IPv6 hosts. There may be host visible changes >>> in the work on naming and discovery protocols, however. In its = design, >>> the working group shall also consider security aspects and the = impact >>> on manageability. The main focus of the working group is home >>> networks, but the group's results may also find applications in = other >>> small networks. >>>=20 >>> The working group will liaise with the relevant IETF working >>> groups. In particular, the group should work closely with the V6OPS >>> working group, review any use or extension of DHCP with the DHC >>> working group, and work with additional DNS requirements with the >>> DNSEXT and DNSOP working groups. If it turns out that additional >>> options are needed for a routing protocol, they will be developed in >>> the appropriate Routing Area working group, with the HOMENET working >>> group providing the architecture and requirements for such >>> enhancements. The working group will also liase with external >>> standards bodies where it is expected that there are normative >>> dependencies between the specifications of the two bodies. >>> It is expected that in the architecture definition stage liaising >>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>=20 >>> Milestones: >>>=20 >>> Jul 2011 Formation of the working group >>> Sep 2011 First WG draft on the architecture >>> Dec 2011 Submission of the architecture draft to the IESG as >>> Informational RFC >>> Dec 2011 Charter re-evaluation based on the architecture work >>> Dec 2011 First WG draft on prefix configuration >>> Dec 2011 First WG draft on routing >>> Jan 2012 First WG draft on name resolution >>> Feb 2012 First WG draft on service discovery >>> Feb 2012 First WG draft on perimeter security >>> Feb 2012 Start of routing related work in the relevant routing area >>> working group, if needed >>> Mar 2012 Submission of the prefix configuration draft to the IESG as >>> Standards Track RFC >>> Apr 2012 Submission of the routing draft to the IESG as = Informational >>> RFC >>> Sep 2012 Submission of the name resolution draft to the IESG as >>> Standards Track RFC >>> Nov 2012 Submission of the service discovery draft to the IESG as >>> Standards Track RFC >>> Dec 2012 Submission of the perimeter security draft to the IESG as >>> Informational RFC >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >>=20 >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >=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. _______________________________________________ fun mailing list fun@ietf.org https://www.ietf.org/mailman/listinfo/fun From jvasseur@cisco.com Thu Jun 30 22:30:19 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4215B21F869B; Thu, 30 Jun 2011 22:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WunDwdCTiGS3; Thu, 30 Jun 2011 22:30:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 821B821F86BD; Thu, 30 Jun 2011 22:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1903; q=dns/txt; s=iport; t=1309498215; x=1310707815; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=+Ltjwy5EJJwOl/+/MsYUAqAvJQKr07MYx1z2X1K3YIs=; b=OPq3j1dfSq9dNWtgpMoC5wcSUFY/59NzjbQNhSDeZIi+gTpQQ0rS/60J An7wVsEBPX+i6HrL0/3qt97nIHTdob9ke93ZrIjBuOIZwZMmu1McK9j+I wgLqmnFcJDvVwXRHJXLKU1g8Dmd5mWtM5j+93W66w0X21vxY2DjtntBXF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAKRaDU6tJV2a/2dsb2JhbABSmCuPMneIeaIlnXKGMgSHPo9xi08 X-IronPort-AV: E=Sophos;i="4.65,456,1304294400"; d="scan'208";a="725212169" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 01 Jul 2011 05:30:14 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p615UEZJ019423; Fri, 1 Jul 2011 05:30:14 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 00:30:14 -0500 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: Fri, 1 Jul 2011 00:30:14 -0500 Message-ID: In-Reply-To: <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fun] [homegate] HOMENET working group proposal Thread-Index: Acw3RGDhWzyvVlXSTKCZLwtsLh7yEgAa5NF6 From: "JP Vasseur (jvasseur)" To: , X-OriginalArrivalTime: 01 Jul 2011 05:30:14.0580 (UTC) FILETIME=[F4627740:01CC37AF] X-Mailman-Approved-At: Fri, 01 Jul 2011 02:06:43 -0700 Cc: ietf@ietf.org, homegate@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 05:30:19 -0000 I'd like to second the relaxation of "wherever possible", which may lead = to a suboptimal solution for several components. JP Vasseur Cisco Fellow Sent from Blackberry ----- Original Message ----- From: Mark Townsley [mailto:mark@townsley.net] Sent: Thursday, June 30, 2011 11:33 AM To: Keith Moore Cc: IETF Discussion ; fun@ietf.org ; = homegate@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal On Jun 30, 2011, at 5:46 PM, Keith Moore wrote: >=20 > On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote: >=20 >>=20 >> I think the consensus we had in the past BoFs and discussion in and = around this topic can be summed up as stating that homenet deliverables = will: >>=20 >> - coexist with (existing) IPv4 protocols, devices, applications, etc. >> - operate in a (future) IPv6-only home network in the absence of IPv4 >> - be IP-agnostic whenever possible >=20 > I'd like for this group to relax the "wherever possible" bit, so as to = not preclude solutions where IPv6 can do a better job than IPv4. Yes, and I think that IPv6 should naturally do a better job than IPv4 in = the cases where it can.=20 My original mail had this restatement of the above, which I think gets = closer to what you want: >> However, when we can define something that is needed for IPv6 in a = way that is also useful for IPv4 without making significant concessions, = we should go ahead and do so. - Mark >=20 > IPv4 is a dinosaur gasping for its last breaths. >=20 > Keith >=20 >=20 > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate _______________________________________________ fun mailing list fun@ietf.org https://www.ietf.org/mailman/listinfo/fun From jari.arkko@piuha.net Fri Jul 1 02:15:26 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2281E11E80A8 for ; Fri, 1 Jul 2011 02:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAAANdmlMHDf for ; Fri, 1 Jul 2011 02:15:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 742A711E809A for ; Fri, 1 Jul 2011 02:15:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 74E242CC3B; Fri, 1 Jul 2011 12:15:23 +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 nQrD5RDSHsIB; Fri, 1 Jul 2011 12:15:23 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id EE4C02CC39; Fri, 1 Jul 2011 12:15:22 +0300 (EEST) Message-ID: <4E0D902A.4070807@piuha.net> Date: Fri, 01 Jul 2011 11:15:22 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Soohong Daniel Park References: <4E0AE3CF.2070504@piuha.net> <4E0CB009.9070104@piuha.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "fun@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 09:15:26 -0000 Daniel, > Presumably, the architrcture includes an analysis work considering the current home networking solutions, particulary DLNA. Correct? In fact, DLNA did the IPv6 over DLNA work before through a IPv6 Task Force, and came up with the whitepaper several years back. IPv6 is not well and widely embedded into DLNA yet though. Just curious how interop and harmonize between ietf work and DLNA. The past DLAN deliverable/efforts might be referred, and used for this Homenet work. > Yes. There needs to be an awareness and analysis of everything that already exists -- DHCP components, V6OPS documents on simple security, DLNA work, UPnP work, etc. Do you have a reference to the whitepaper and other associated information at DLNA? Jari From soohongp@gmail.com Fri Jul 1 02:31:11 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C094811E80E2 for ; Fri, 1 Jul 2011 02:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-K17lYysQTU for ; Fri, 1 Jul 2011 02:31:11 -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 0A44911E80D1 for ; Fri, 1 Jul 2011 02:31:10 -0700 (PDT) Received: by eye13 with SMTP id 13so1253316eye.31 for ; Fri, 01 Jul 2011 02:31:10 -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=LlC52J23nS/E7PlylsvFEEgW8NzAKVobCnVPZ70ec0c=; b=J7pMexc5oQoPMuAXbvO2+U/CgdA8jieXnbTeFTSJLYePe1d+ff/btSnM6y9OFH7BLN 4Jcm58kUWSDGtNI2zIcRjzX7/aCO6X+UxHPVJ97xTkfu0+FFMEm4zy/pVi9lhqs8tqz7 sobWsDSk2iGQiLpXDXLy1vY8s6gr+OJ+GF3ow= MIME-Version: 1.0 Received: by 10.14.35.163 with SMTP id u35mr868426eea.232.1309512669844; Fri, 01 Jul 2011 02:31:09 -0700 (PDT) Received: by 10.14.97.75 with HTTP; Fri, 1 Jul 2011 02:31:09 -0700 (PDT) Received: by 10.14.97.75 with HTTP; Fri, 1 Jul 2011 02:31:09 -0700 (PDT) In-Reply-To: <4E0D902A.4070807@piuha.net> References: <4E0AE3CF.2070504@piuha.net> <4E0CB009.9070104@piuha.net> <4E0D902A.4070807@piuha.net> Date: Fri, 1 Jul 2011 18:31:09 +0900 Message-ID: From: Daniel Park To: Jari Arkko Content-Type: multipart/alternative; boundary=0016e659fcec83d51604a6fead96 Cc: "fun@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 09:31:11 -0000 --0016e659fcec83d51604a6fead96 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Yes, since I was also a member of that TF within DLNA. But, I do not quite sure now whether we can share that whitepaper in ietf due to DLNA membership policy. Daniel Soohong Daniel Park from Galaxy S, twitter: @natpt 2011. 7. 1. =BF=C0=C8=C4 6:15=BF=A1 "Jari Arkko" =B4= =D4=C0=CC =C0=DB=BC=BA: > Daniel, >> Presumably, the architrcture includes an analysis work considering the current home networking solutions, particulary DLNA. Correct? In fact, DLNA did the IPv6 over DLNA work before through a IPv6 Task Force, and came up with the whitepaper several years back. IPv6 is not well and widely embedde= d into DLNA yet though. Just curious how interop and harmonize between ietf work and DLNA. The past DLAN deliverable/efforts might be referred, and use= d for this Homenet work. >> > > Yes. There needs to be an awareness and analysis of everything that > already exists -- DHCP components, V6OPS documents on simple security, > DLNA work, UPnP work, etc. > > Do you have a reference to the whitepaper and other associated > information at DLNA? > > Jari > --0016e659fcec83d51604a6fead96 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable

Yes, since I was also a member of that TF within DLNA. But, I do not qui= te sure now whether we can  share that whitepaper in ietf due to DLNA = membership policy.

Daniel

Soohong Daniel Park
from Galaxy S, twitter: @natpt

2011. 7. 1. =BF=C0=C8=C4 6:15=BF=A1 "Jari A= rkko" <jari.arkko@piuha.net= >=B4=D4=C0=CC =C0=DB=BC=BA:
> Daniel,
= >> Presumably, the architrcture includes an analysis work considering= the current home networking solutions, particulary DLNA. Correct? In fact,= DLNA did the IPv6 over DLNA work before through a IPv6 Task Force, and cam= e up with the whitepaper several years back. IPv6 is not well and widely em= bedded into DLNA yet though. Just curious how interop and harmonize between= ietf work and DLNA. The past DLAN deliverable/efforts might be referred, a= nd used for this Homenet work.
>>
>
> Yes. There needs to be an awareness and analys= is of everything that
> already exists -- DHCP components, V6OPS doc= uments on simple security,
> DLNA work, UPnP work, etc.
>
> Do you have a reference to the whitepaper and other associated
>= ; information at DLNA?
>
> Jari
>
--0016e659fcec83d51604a6fead96-- From swmike@swm.pp.se Fri Jul 1 03:20:02 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9121F86FD for ; Fri, 1 Jul 2011 03:20: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of-HRnEWRJzz for ; Fri, 1 Jul 2011 03:20:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD5521F86F6 for ; Fri, 1 Jul 2011 03:20:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4514E9E; Fri, 1 Jul 2011 12:19:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 41CA49A; Fri, 1 Jul 2011 12:19:59 +0200 (CEST) Date: Fri, 1 Jul 2011 12:19:59 +0200 (CEST) From: Mikael Abrahamsson To: Daniel Park In-Reply-To: Message-ID: References: <4E0AE3CF.2070504@piuha.net> <4E0CB009.9070104@piuha.net> <4E0D902A.4070807@piuha.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "fun@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 10:20:02 -0000 On Fri, 1 Jul 2011, Daniel Park wrote: > Yes, since I was also a member of that TF within DLNA. But, I do not > quite sure now whether we can share that whitepaper in ietf due to DLNA > membership policy. Reading up on www.dlna.org it seems the way this organisation operates and envisions future development is incompatible with how the IETF operates? "The DLNA Guidelines are available to DLNA Member companies for free and to purchase for non-DLNA Members." -- Mikael Abrahamsson email: swmike@swm.pp.se From mark@townsley.net Fri Jul 1 03:31:14 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3611E809A for ; Fri, 1 Jul 2011 03:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haDIT1sXxCpl for ; Fri, 1 Jul 2011 03:31:13 -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 DE3E011E80AC for ; Fri, 1 Jul 2011 03:31:04 -0700 (PDT) Received: by wwe5 with SMTP id 5so2087392wwe.13 for ; Fri, 01 Jul 2011 03:31:04 -0700 (PDT) Received: by 10.216.240.202 with SMTP id e52mr963250wer.84.1309516263886; Fri, 01 Jul 2011 03:31:03 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id u64sm1554256weq.28.2011.07.01.03.31.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 03:31:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Fri, 1 Jul 2011 12:31:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE3CF.2070504@piuha.net> <4E0CB009.9070104@piuha.net> <4E0D902A.4070807@piuha.net> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: "fun@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 10:31:14 -0000 On Jul 1, 2011, at 12:19 PM, Mikael Abrahamsson wrote: > On Fri, 1 Jul 2011, Daniel Park wrote: >=20 >> Yes, since I was also a member of that TF within DLNA. But, I do not = quite sure now whether we can share that whitepaper in ietf due to DLNA = membership policy. >=20 > Reading up on www.dlna.org it seems the way this organisation operates = and envisions future development is incompatible with how the IETF = operates? While it is certainly easier to work with organizations that have more = open policies, the IETF can and has managed to work with those that do = not. For example, the BBF has liaised Working Texts to the v6ops and = other WGs which are typically private to BBF members only, the IEEE has = setup arrangements where IETF WG chairs can give access to = password-protected document repositories to those that request it, etc. = Also, the practical need for these kinds of arrangements depends on the = overlap or lack thereof between IETF WG participants that do and do not = have access via membership anyway.=20 So, don't consider this a blocking function. We'll work it out, either = ourselves or via the IAB (who officially manages SDO liaison = relationships) if need be. - Mark >=20 > >=20 > "The DLNA Guidelines are available to DLNA Member companies for free = and to purchase for non-DLNA Members." >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From robert@raszuk.net Fri Jul 1 04:45:55 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406EC21F8647 for ; Fri, 1 Jul 2011 04:45:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3-aFSQyKUNA for ; Fri, 1 Jul 2011 04:45:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C959321F8637 for ; Fri, 1 Jul 2011 04:45:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMIAOSyDU6rRDoI/2dsb2JhbABSmG2Oc3erS54DhjIEkjKEdos9 X-IronPort-AV: E=Sophos;i="4.65,457,1304294400"; d="scan'208";a="351325769" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 11:45:54 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p61Bjrj6027245 for ; Fri, 1 Jul 2011 11:45:54 GMT Message-ID: <4E0DB36D.60303@raszuk.net> Date: Fri, 01 Jul 2011 13:45:49 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: fun@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 11:45:55 -0000 While rereading the proposed charter I have two questions .. 1. Is documentation or new tools specification development for home network troubleshooting either manual or automated in or outside of charter ? How about diagnostics in reachability to internal subnets or different hosts on the internet ? 2. How about multihoming with seamless switchover ? I think those will make home networking a bit easier ? --- Example for 1: What happens if I can ping/trace a destination, browse it's web site just fine, but my cgi script dies ? And I have a real case like this which honestly I am not sure how to troubleshoot. Server side reports no errors at all in the log. MTU is low as it can be. /* Well I found the solution but will not say it on this list as I am afraid Jari and Mark will unsubscribe me ;-) */ Cheers, R. From mark@townsley.net Fri Jul 1 05:43:53 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8711111E8A74 for ; Fri, 1 Jul 2011 05:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuDsyN3HJ-P1 for ; Fri, 1 Jul 2011 05:43:52 -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 2F67721E8BFA for ; Fri, 1 Jul 2011 05:19:17 -0700 (PDT) Received: by wyj26 with SMTP id 26so2500708wyj.31 for ; Fri, 01 Jul 2011 05:19:17 -0700 (PDT) Received: by 10.227.27.165 with SMTP id i37mr2923211wbc.39.1309522755724; Fri, 01 Jul 2011 05:19:15 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id en1sm2318529wbb.18.2011.07.01.05.19.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 05:19:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4E0DB36D.60303@raszuk.net> Date: Fri, 1 Jul 2011 14:19:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7EC07A1A-CCD2-4A4A-A92D-8475430F558E@townsley.net> References: <4E0DB36D.60303@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 12:43:53 -0000 On Jul 1, 2011, at 1:45 PM, Robert Raszuk wrote: > While rereading the proposed charter I have two questions .. >=20 > 1. Is documentation or new tools specification development for home = network troubleshooting either manual or automated in or outside of = charter ? How about diagnostics in reachability to internal subnets or = different hosts on the internet ? That's a pretty broad question. Let me try and answer.=20 There is a prevailing notion that the home network must work well in a = "not actively managed" manner. So if we met our goal perfectly, we'd = need no troubleshooting or diagnostics tools. The world isn't perfect = though, and where tools and such are necessary I'm sure they will spring = up. I don't see these specifically as major deliverables for homenet = though.=20 Note that protocols themselves, in particular auto-configuration and = such, are by their nature doing "automatic trouble-shooting" in one form = or another, and in terms of "reachability" IPv6 has NUD built right in = at least for within the home. So, in as much as this is part and parcel = for the protocol to work in an "automatic" and "not actively managed" = manner, sure, homenet has that. If you mean defining a "home network = management" application? No, I don't think we're going there. I could = imagine a homenet-ops or some such in the future, or as part of v6ops = now, that could develop these more though.=20 > 2. How about multihoming with seamless switchover ? This particular elephant has been in and out of various versions of the = charter. I'll plead the 5th on this one and ask Jari to describe where = we are on this, in particular in relation to mif, shim6, lisp, rrg, = v6ops, or any of the other areas that are touching on this.=20 Personally, I think it would be naive to not include the various = possibilities of multihomed connectivity, at the vary least in = describing the architecture for which we will work within. I don't think = homenet is the place to solve the general issue of "seamless = multihoming" at the protocol level, but perhaps we would point to what = works well in a home setting... we might even agree to one way to do it = if we are really, really, lucky.=20 > I think those will make home networking a bit easier ? >=20 > --- >=20 > Example for 1: What happens if I can ping/trace a destination, browse = it's web site just fine, but my cgi script dies ? And I have a real case = like this which honestly I am not sure how to troubleshoot. Server side = reports no errors at all in the log. MTU is low as it can be. >=20 > /* Well I found the solution but will not say it on this list as I am = afraid Jari and Mark will unsubscribe me ;-) */ I doubt that.=20 - Mark >=20 > Cheers, > R. > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From jason.weil@twcable.com Fri Jul 1 06:33:42 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF811E80FD; Fri, 1 Jul 2011 06:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.864 X-Spam-Level: X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iggWFojARrgh; Fri, 1 Jul 2011 06:33:40 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB911E8127; Fri, 1 Jul 2011 06:32:27 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,458,1304308800"; d="scan'208";a="244804822" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2011 09:31:04 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 1 Jul 2011 09:32:12 -0400 From: "Weil, Jason" To: Mark Townsley , "JP Vasseur (jvasseur)" Date: Fri, 1 Jul 2011 09:32:11 -0400 Thread-Topic: [fun] status of the homenet effort Thread-Index: Acw380h/wVPhDWgST5W2OIltGtCygA== 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.0.0.100825 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:33:42 -0000 DQoNCk9uIDcvMS8xMSA0OjA2IEFNLCAiTWFyayBUb3duc2xleSIgPG1hcmtAdG93bnNsZXkubmV0 PiB3cm90ZToNCg0KPg0KPk9uIEp1bCAxLCAyMDExLCBhdCA3OjI3IEFNLCBKUCBWYXNzZXVyIChq dmFzc2V1cikgd3JvdGU6DQo+DQo+PiBJIGFsc28gdGhpbmsgdGhhdCB0aGlzIGRlYWxzIHdpdGgg YW4gaW1wb3J0YW50IHRvcGljIGFuZCB0aGUgbGlzdCBvZg0KPj5pdGVtcyBsaXN0ZWQgb24gdGhl IHByb3Bvc2VkIGNoYXJ0ZXIgYXJlIHF1aXRlIHJlbGV2YW50LiBJJ20ganVzdCBub3QNCj4+ZW50 aXJlbHkgY2xlYXIgb24gdGhlICJyb3V0aW5nIGNvbXBvbmVudCI6IGFyZSB5b3UgcmVmZXJyaW5n IHRvOg0KPj4gKiBBIHJlcXVpcmVtZW50IGRvY3VtZW50IGZvciBSb3V0aW5nIGluIHRoZSBob21l Pw0KPg0KPkF0IGxlYXN0IGEgc2VjdGlvbiB3aXRoaW4gYSBob21lIGFyY2hpdGVjdHVyZSBkb2N1 bWVudC4NCj4NCj4+ICogQSByZWNvbW1lbmRhdGlvbiBmb3IgYSBzcGVjaWZpYyByb3V0aW5nIHBy b3RvY29sID8NCg0KW0pXXSBJIHNlZSBhIGd1aWRlbGluZXMvYW5hbHlzaXMgZm9yIGxpbmstc3Rh dGUgdnMuIGRpc3RhbmNlLXZlY3Rvcg0Kcm91dGluZyBwcm90b2NvbHMgaW4gYSBtdWx0aS1zZWdt ZW50IGhvbWUgbmV0d29yayBhcyBiZWluZyB1c2VmdWwuDQoNCj4NCj4+ICogQSBmcmFtZXdvcmsg YmVmb3JlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGEgbmV3IHJvdXRpbmcgcHJvdG9jb2wgPw0KDQpb SlddIEEgZnJhbWV3b3JrIG9yIGp1c3RpZmljYXRpb24gc3RhdGVtZW50IGZvciBhIG5ldyBsaWdo dHdlaWdodCByb3V0aW5nDQpwcm90b2NvbCB3b3VsZCBiZSB1c2VmdWwgYXMgd2VsbC4gQSBzb3Vy Y2UvZGVzdCBhd2FyZSBwcm90b2NvbCBoYXMgYmVlbg0KcHJvcG9zZWQgYXMgYSBwb3NzaWJsZSBz b2x1dGlvbiBmb3IgdGhlIG11bHRpLWhvbWVkIGhvbWUgbmV0d29yayBmb3INCmV4YW1wbGUuDQoN Cj4NCj5UaGUgY2hhcnRlciBzYXlzOg0KPg0KPiJGb3IgYXV0b21hdGljIHJvdXRpbmcsIGl0IGlz IGV4cGVjdGVkIHRoYXQgZXhpc3RpbmcNCj5yb3V0aW5nIHByb3RvY29scyBjYW4gYmUgdXNlZCBh cyBpcywgaG93ZXZlciwgYSBuZXcgbWVjaGFuaXNtIG1heSBiZQ0KPm5lZWRlZCBpbiBvcmRlciB0 byB0dXJuIGEgc2VsZWN0ZWQgcHJvdG9jb2wgb24gYnkgZGVmYXVsdC4iDQo+DQo+LSBNYXJrDQo+ DQo+DQo+PiBJJ20gY2xlYXJseSBub3QgZXhwcmVzc2luZyBhbiBvcGluaW9uLCBqdXN0IGEgcXVl c3Rpb24uDQo+PiBUaGFua3MuDQo+PiBKUC4NCj4+DQo+PiBKUCBWYXNzZXVyDQo+PiBDaXNjbyBG ZWxsb3cNCj4+DQo+PiBTZW50IGZyb20gQmxhY2tiZXJyeQ0KPj4NCj4+IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0NCj4+IEZyb206IE1hcmsgVG93bnNsZXkgW21haWx0bzptYXJrQHRvd25z bGV5Lm5ldF0NCj4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDMwLCAyMDExIDExOjM2IEFNDQo+PiBU bzogV2VpbCwgSmFzb24gPGphc29uLndlaWxAdHdjYWJsZS5jb20+DQo+PiBDYzogZnVuQGlldGYu b3JnIDxmdW5AaWV0Zi5vcmc+OyBob21lZ2F0ZUBpZXRmLm9yZyA8aG9tZWdhdGVAaWV0Zi5vcmc+ DQo+PiBTdWJqZWN0OiBSZTogW2Z1bl0gc3RhdHVzIG9mIHRoZSBob21lbmV0IGVmZm9ydA0KPj4N Cj4+DQo+PiBUaGFuayB5b3UgZm9yIHRoZSBmZWVkYmFjaywga2VlcCBpdCBjb21pbmcuDQo+Pg0K Pj4gT24gSnVuIDMwLCAyMDExLCBhdCA0OjE0IFBNLCBXZWlsLCBKYXNvbiB3cm90ZToNCj4+DQo+ Pj4gTWFyaywgUmFwbGgsIEphcmksIGV0IGFsbCwNCj4+Pg0KPj4+IEkgcmVhbGx5IGFwcHJlY2lh dGUgdGhlIGNoYW5nZSBpbiBjaGFydGVyIGFuZCBkaXJlY3Rpb24gZm9yIHRoaXMNCj4+PnByb3Bv c2VkDQo+Pj4gV0cgYW5kIHRoZSBpbnRlcmVzdCB0byBrZWVwIGl0IGdvaW5nLiBJIGJlbGlldmUg aXQgc2V0cyBhIHBhdGggdGhhdCBpcw0KPj4+IHNjb3BlZCBuYXJyb3cgZW5vdWdoIHRvIHByb3Zp ZGUgYSB3b3JrcGxhY2UgZm9yIGFjaGlldmFibGUgcmVzdWx0cy4NCj4+Pg0KPj4+IEFzIGEgcHJv dmlkZXIgd29ya2luZyBvbiB3cml0aW5nLCB0ZXN0aW5nIGFuZCBpbXBsZW1lbnRpbmcgSVB2NiBD UEUsIEkNCj4+PmNhbg0KPj4+IHJlbGF0ZSBmaXJzdGhhbmQgdGhhdCBnZXR0aW5nIGJhc2ljIElQ djYgZnVuY3Rpb25hbGl0eSB3b3JraW5nIGluIHRoZQ0KPj4+aG9tZQ0KPj4+IG5ldHdvcmsgaXMg bm8gc2ltcGxlIGZlYXQgYW5kIGlzIHN0aWxsIGEgd29yayBpbiBwcm9ncmVzcy4gRG9uJ3QgZ2V0 IG1lDQo+Pj4gd3JvbmcsIGJhc2ljIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUganVzdCBub3QgYmFr ZWQuIFdoYXQgc2VlbXMgdmVyeQ0KPj4+IHN0cmFpZ2h0Zm9yd2FyZCBpbiB0aGVvcnkgdHlwaWNh bGx5IGZhaWxzIGluIGEgbXVsdGl0dWRlIG9mIGNvcm5lcg0KPj4+Y2FzZXMNCj4+PiBpZSByZWFs aXR5LiBBbmQganVzdCB0byBjbGFyaWZ5IEkgYW0gcmVmZXJyaW5nIHRvIGEgc2luZ2xlIC82NCBz dWJuZXQNCj4+PiB0b3BvbG9neSB3aXRoIG5vIHJvdXRpbmcuDQo+Pj4NCj4+PiBJZiB3ZSBjYW4g c3RheSBmb2N1c3NlZCBvbiBzb2x2aW5nIGp1c3QgdGhlIGJhc2ljcyBmb3IgdGhlIGZpdmUgYXJl YXMNCj4+PiBpbmNsdWRlZCwgSSBiZWxpZXZlIGl0IHdpbGwgYmUgaGVscGZ1bC4gVGhlIG90aGVy IHJlY29tbWVuZGF0aW9uIHdvdWxkDQo+Pj5iZQ0KPj4+IHRvIHdvcmsgYXMgZXhwZWRpdGlvdXNs eSBhcyBwb3NzaWJsZS4gUHJvdmlkZXJzIGluIHRoZSBwcm9jZXNzIG9mDQo+Pj4gZGVwbG95aW5n IElQdjYgbm93IGFyZSBhbHJlYWR5IGRlZXAgaW50byB0aGlzIGFuYWx5c2lzIGFuZCBkZXZlbG9w bWVudA0KPj4+IHdpdGggdGhlaXIgdmVuZG9ycy4gSWYgd2Ugd2FpdCB0b28gbG9uZyB0aGVuIHRo ZXNlIHRvcGljcyB3aWxsIGJlDQo+Pj5zb2x2ZWQNCj4+PiB3aXRoIGludGVyb3BlcmFiaWxpdHkg YSBwb3NzaWJsZSBjYXN1YWx0eS4NCj4+Pg0KPj4+IEZXSVcsIEkgd291bGQgYWxzbyBhZGQgdGhh dCB0aGUgZml2ZSB0b3BpY3MgaW4gdGhlIGNoYXJ0ZXIgYXJlIGFsc28NCj4+Pmxpc3RlZA0KPj4+ IGluIG9yZGVyDQo+Pj4gT2YgcHJpb3JpdHkgYXQgbGVhc3QgZm9yIG1lLg0KPj4+DQo+Pj4NCj4+ PiBUaGFua3MsDQo+Pj4NCj4+PiBKYXNvbg0KPj4+DQo+Pj4NCj4+PiBPbiA2LzI5LzExIDU6NDYg QU0sICJNYXJrIFRvd25zbGV5IiA8bWFya0B0b3duc2xleS5uZXQ+IHdyb3RlOg0KPj4+DQo+Pj4+ DQo+Pj4+IEFsbCwNCj4+Pj4NCj4+Pj4gQXBvbG9naWVzIGZvciBkb3VibGUtcG9zdGluZyBpZiB0 aGVyZSBhcmUgZm9sa3MgdGhhdCBhcmUgc3Vic2NyaWJlZCB0bw0KPj4+PiBob21lZ2F0ZUBpZXRm Lm9yZyBhbmQgZnVuQGlldGYub3JnLiBJJ20gaG9waW5nIHNvb24gdGhhdCBzb21lb25lIHdpbGwN Cj4+Pj4gZmluYWxseSBjcmVhdGUgaG9tZW5ldEBpZXRmLm9yZyBhbmQgY29uc29saWRhdGUgdGhl IG1lbWJlcnNoaXANCj4+Pj4gYWNjb3JkaW5nbHkuDQo+Pj4+DQo+Pj4+IEluIHRoZSBjaGFydGVy IHByb3Bvc2FsIGJlbG93LCBJIHRoaW5rIHlvdSB3aWxsIHNlZSBhIGxvdCBvZg0KPj4+PnNpbWls YXJpdHkNCj4+Pj4gd2l0aCB0aGUgY29uc2Vuc3VzIHdlIGFjaGlldmVkIG9uIHRoZSBob21lZ2F0 ZSBsaXN0IGxhc3QgeWVhci4gSmFyaQ0KPj4+Pmhhcw0KPj4+PiB0YWtlbiB0aGF0LCBmZWVkYmFj ayBmcm9tIHRoZSBJRVNHLCBJQUIsIG1lbWJlcnMgb2YgdGhlDQo+Pj4+SVAtRGlyZWN0b3JhdGUs DQo+Pj4+IHY2b3BzIGNoYWlycywgZXRjLiBhbmQgc2hhcGVkIGl0IHRvd2FyZHMgc29tZXRoaW5n IG1vcmUgZm9jdXNlZCBvbiB0aGUNCj4+Pj4gSW50ZXJuZXQgKGFuZCBSb3V0aW5nKSBhcmVhLCBh cyB3ZWxsIGFzIElQdjYuIEkgYmVsaWV2ZSBoZSBhbmQgUmFscGgNCj4+Pj5ib3RoDQo+Pj4+IGhh dmUgYSBncmVhdCBkZWFsIG9mIGNvbmZpZGVuY2UgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0 IGlzIHZlcnkNCj4+Pj4gaW1wb3J0YW50IHRvIHRoZSBpbmR1c3RyeSwgYW5kIHRoYXQgdGhlIElF VEYgaGFzIGEgY3JpdGljYWwgcm9sZSB0bw0KPj4+PnBsYXkuDQo+Pj4+DQo+Pj4+IFNvLCBtYWtl IG5vIG1pc3Rha2UsIHdoZXRoZXIgd2UgZW5kIHVwIGFzIGEgV0cgb3IgYSBCb0YgYmV0d2VlbiBu b3cNCj4+Pj5hbmQNCj4+Pj4gUXVlYmVjLCAid2UncmUgYmFjayIgLSBwbGVhc2Ugc2VuZCBjb21t ZW50cywgYW5kIG1ha2UgeW91ciB0cmF2ZWwgb3INCj4+Pj4gcmVtb3RlLWF0dGVuZGFuY2UgcGxh bnMgYWNjb3JkaW5nbHkgaWYgeW91IHdhbnQgdG8gcGFydGljaXBhdGUuDQo+Pj4+DQo+Pj4+IEph cmkgaGFzIGFza2VkIG1lIHRvIGNvLWNoYWlyIHRoZSBzZXNzaW9uIGluIFF1ZWJlYy4gQXMgc3Vj aCwgSSdkDQo+Pj4+bGlrZSB0bw0KPj4+PiB0YWtlIHJlcXVlc3RzIGZvciBwcmVzZW50YXRpb24g dGltZSBub3cuIEphcmkgYW5kIEkgd2lsbCBsaWtlbHkgYmVnaW4NCj4+Pj50aGUNCj4+Pj4gc2Vz c2lvbiB3aXRoIGEgc2NvcGluZyBvdmVydmlldywgYXMgd2VsbCBhcyBhIGZpcnN0IGN1dCBhdCBh bg0KPj4+PiBhcmNoaXRlY3R1cmUgZnJhbWV3b3JrLCBidXQgdGhlcmUgc2hvdWxkIGJlIHNvbWUg dGltZSBmb3IgYSBmZXcgb3RoZXINCj4+Pj4gaXRlbXMuIFdoZW4gc3VibWl0dGluZyB5b3VyIHJl cXVlc3QsIHBsZWFzZSBpZGVudGlmeSB3aGljaCBvZiB0aGUgNQ0KPj4+PmFyZWFzDQo+Pj4+IGJl bG93IHlvdSB0aGluayB5b3VyIHdvcmsgYXBwbGllcyB0byBhcyB3ZWxsIGFzIHRoZSBpbnRlcm5l dC1kcmFmdCwgb2YNCj4+Pj4gY291cnNlLg0KPj4+Pg0KPj4+PiBUaGFua3MsIGFuZCBzZWUgeW91 IG9uIHRoZSBsaXN0IGFuZCBpbiBRdWViZWMuDQo+Pj4+DQo+Pj4+IC0gTWFyaw0KPj4+Pg0KPj4+ Pg0KPj4+PiBPbiBKdW4gMjksIDIwMTEsIGF0IDEwOjM1IEFNLCBKYXJpIEFya2tvIHdyb3RlOg0K Pj4+Pg0KPj4+Pj4gSSB3YW50ZWQgdG8gcHJvdmlkZSBhbiB1cGRhdGUgb2YgdGhlIHNpdHVhdGlv biB3aXRoIHRoaXMgd29ya2luZw0KPj4+Pj5ncm91cA0KPj4+Pj4gcHJvcG9zYWwuDQo+Pj4+Pg0K Pj4+Pj4gSE9NRU5FVCBpcyBhIG5ldyB3b3JraW5nIGdyb3VwIHByb3Bvc2FsLCBhIHZhcmlhdGlv biBvZiB0aGUNCj4+Pj4+IEhPTUVHQVRFL0hPTUVORVQgdGhlbWUgdGhhdCB3ZSBkaXNjdXNzZWQg bGFzdCB5ZWFyLCBidXQgdGhpcyB0aW1lDQo+Pj4+PiBsb29raW5nIGF0IGl0IGZyb20gYSBkaWZm ZXJlbnQgYW5nbGUuIFRoZSBvbGQgZWZmb3J0IHdhcyBtb3N0bHkNCj4+Pj4+Zm9jdXNlZA0KPj4+ Pj4gYWJvdXQgd2hhdCBob21lIGdhdGV3YXlzIHNob3VsZCBkbzogZm9yd2FyZGluZywgdHJhbnNw b3J0LCBhbmQgRE5TDQo+Pj4+PiBwcm94eWluZyBpc3N1ZXMuIFRoZSBuZXcgZWZmb3J0IGlzIGFi b3V0IGhvbWUgbmV0d29ya3MgdGhlbXNlbHZlcywgaW4NCj4+Pj4+IHBhcnRpY3VsYXIgd2hhdCBr aW5kIG9mIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGFuZCBjb25maWd1cmF0aW9uIGlzDQo+Pj4+PiBu ZWNlc3NhcnkgdG8gc3VwcG9ydCBJUHY2LWJhc2VkIGhvbWUgbmV0d29ya3MuIFdlIHZpZXcgSVB2 NC1iYXNlZA0KPj4+Pj5ob21lDQo+Pj4+PiBuZXR3b3JrcyBhcyAiZG9uZSIgYXQgdGhpcyB0aW1l IChvciBwZXJoYXBzIGFzICJjYW5ub3QgYmUgY2hhbmdlZA0KPj4+Pj4gYW55d2F5IikuDQo+Pj4+ Pg0KPj4+Pj4gSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlzIGVmZm9ydCBpbiB0aGUgYmFja2dy b3VuZCBmb3IgdGhlIGxhc3QNCj4+Pj4+IGNvdXBsZSBvZiBtb250aCB3aXRoIE1hcmsgVG93bnNs ZXkgYW5kIG90aGVycywgYW5kIG1vcmUgcHVibGljbHkNCj4+Pj4+c2luY2UNCj4+Pj4+IGVhcmx5 IEp1bmUuIFRoZSBwcm9wb3NhbCBoYXMgYmVlbiBicm91Z2h0IHRvIHRoZSBJRVNHLCBJQUIgYW5k IHNvbWUNCj4+Pj4+IGRpcmVjdG9yYXRlcyBmb3IgZGlzY3Vzc2lvbiwgYW5kIHdlJ3ZlIGJlZW4g Z29pbmcgYmFjayBhbmQgZm9ydGgNCj4+Pj4+d2hldGhlcg0KPj4+Pj4gdGhpcyBpcyByZWFkeSB0 byBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIG9yIG5lZWRzIHRvIGJlIHJ1biBhcyBhIEJPRg0KPj4+ Pj5pbg0KPj4+Pj4gUXVlYmVjIENpdHkuIFRoZSBjdXJyZW50IHBsYW4gaXMgdGhhdCB0aGUgd29y a2luZyBncm91cCBwcm9wb3NhbA0KPj4+Pj5nb2VzIHRvDQo+Pj4+PiBJRVRGLXdpZGUgcmV2aWV3 IHRoaXMgd2VlaywgYW5kIGlmIHRoZSBmZWVkYmFjayBmcm9tIHRoZSBjb21tdW5pdHksDQo+Pj4+ PklBQiwNCj4+Pj4+IGFuZCB0aGUgSUVTRyBpcyBwb3NpdGl2ZSwgd2Ugd2lsbCBjcmVhdGUgdGhl IHdvcmtpbmcgZ3JvdXAganVzdCBpbg0KPj4+Pj50aW1lDQo+Pj4+PiBmb3IgdGhlIElFVEYuIE90 aGVyd2lzZSwgdGhlIHNsb3QgcmVzZXJ2ZWQgaW4gdGhlIGFnZW5kYSBmb3IgdGhlDQo+Pj4+Pm1l ZXRpbmcNCj4+Pj4+IHdpbGwgYmUgdXNlZCB0byBydW4gdGhlIHByb3Bvc2FsIGFzIGEgQk9GLg0K Pj4+Pj4NCj4+Pj4+IEluIGFueSBjYXNlLCBJIHdvdWxkIGxpa2UgdG8gc29saWNpdCBkaXNjdXNz aW9uIG9uIHRoaXMgdG9waWMsIGFuZA0KPj4+Pj4gcGVyaGFwcyBzb21lIGVhcmx5IGRyYWZ0cyBh cyB3ZWxsLiBQbGVhc2UgY29tbWVudCBvbiB0aGUgY2hhcnRlciBhdA0KPj4+Pj4gbGVhc3QuDQo+ Pj4+Pg0KPj4+Pj4gTm90ZSB0aGF0IHRoZSBuZXcgcHJvcG9zYWwgd2FzIGNhbGxlZCBGVU4gYXQg dGhlIHRpbWUgdGhhdCB3ZSBjcmVhdGVkDQo+Pj4+PiB0aGUgbGlzdC4gSXQgaGFzIG5vdyBiZWVu IHJlbmFtZWQgYmFjayB0byBIT01FTkVUIHRvIGJlIG1vcmUNCj4+Pj4+IGRlc2NyaXB0aXZlLiBU aGUgbGlzdCB3aWxsIGJlIHJlbmFtZWQgc29vbiBhcyB3ZWxsIChjdXJyZW50DQo+Pj4+PnN1YnNj cmliZXJzDQo+Pj4+PiB3aWxsIHN0YXkpLg0KPj4+Pj4NCj4+Pj4+IFRoaXMgaXMgdGhlIG1vc3Qg cmVjZW50IHZlcnNpb24gb2YgdGhlIGNoYXJ0ZXIgd2Ugc2hvdWxkIGRpc2N1c3M6DQo+Pj4+Pg0K Pj4+Pj4gSG9tZSBOZXR3b3JrcyAoaG9tZW5ldCkNCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pg0KPj4+Pj4gQ3VycmVudCBTdGF0dXM6IFByb3Bvc2VkDQo+ Pj4+PiBMYXN0IEVkaXQ6IFdlZG5lc2RheSwgSnVuZSAyOXRoLCAyMDExDQo+Pj4+Pg0KPj4+Pj4g Q2hhaXJzOg0KPj4+Pj4gVEJEDQo+Pj4+Pg0KPj4+Pj4gSW50ZXJuZXQgQXJlYSBEaXJlY3RvcnM6 DQo+Pj4+PiBSYWxwaCBEcm9tcyA8cmRyb21zLmlldGZAZ21haWwuY29tPg0KPj4+Pj4gSmFyaSBB cmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQo+Pj4+Pg0KPj4+Pj4gSW50ZXJuZXQgQXJlYSBB ZHZpc29yOg0KPj4+Pj4gSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQo+Pj4+Pg0K Pj4+Pj4gUm91dGluZyBBcmVhIFRlY2huaWNhbCBBZHZpc29yOg0KPj4+Pj4gVEJEDQo+Pj4+Pg0K Pj4+Pj4gU2VjdXJpdHkgQXJlYSBUZWNobmljYWwgQWR2aXNvcjoNCj4+Pj4+IFRCRA0KPj4+Pj4N Cj4+Pj4+IE1haWxpbmcgTGlzdHM6DQo+Pj4+PiBHZW5lcmFsIERpc2N1c3Npb246IGZ1bkBpZXRm Lm9yZw0KPj4+Pj4gVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Z1bg0KPj4+Pj4gQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2Z1bg0KPj4+Pj4NCj4+Pj4+IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+ Pj4+Pg0KPj4+Pj4gVGhpcyB3b3JraW5nIGdyb3VwIGZvY3VzZXMgb24gdGhlIGV2b2x2aW5nIG5l dHdvcmtpbmcgdGVjaG5vbG9neQ0KPj4+Pj4gd2l0aGluIGFuZCBhbW9uZyByZWxhdGl2ZWx5IHNt YWxsIKn4cmVzaWRlbnRpYWwgaG9tZan3IG5ldHdvcmtzLiBGb3INCj4+Pj4+IGV4YW1wbGUsIGFu IG9idmlvdXMgdHJlbmQgaW4gaG9tZSBuZXR3b3JraW5nIGlzIHRoZSBwcm9saWZlcmF0aW9uIG9m DQo+Pj4+PiBuZXR3b3JraW5nIHRlY2hub2xvZ3kgaW4gYW4gaW5jcmVhc2luZ2x5IGJyb2FkIHJh bmdlIGFuZCBudW1iZXIgb2YNCj4+Pj4+IGRldmljZXMuIFRoaXMgZXZvbHV0aW9uIGluIHNjYWxl IGFuZCBkaXZlcnNpdHkgc2V0cyBzb21lIHJlcXVpcmVtZW50cw0KPj4+Pj4gb24gSUVURiBwcm90 b2NvbHMuIFNvbWUgb2YgdGhlIHJlbGV2YW50IHRyZW5kcyBpbmNsdWRlOg0KPj4+Pj4NCj4+Pj4+ IG8gTXVsdGlwbGUgc2VnbWVudHM6IFdoaWxlIGxlc3MgY29tcGxleCBMMy10b3Bsb2dpZXMgaW52 b2x2aW5nIGFzIGZldw0KPj4+Pj4gc3VibmV0cyBhcyBwb3NzaWJsZSBhcmUgcHJlZmVycmVkIGlu IGhvbWUgbmV0d29ya3MgZm9yIGEgdmFyaWV0eSBvZg0KPj4+Pj4gcmVhc29ucyBpbmNsdWRpbmcg c2ltcGxlciBtYW5hZ2VtZW50IGFuZCBzZXJ2aWNlIGRpc2NvdmVyeSwgdGhlDQo+Pj4+PiBpbnRy b2R1Y3Rpb24gb2YgbW9yZSB0aGFuIG9uZSBzdWJuZXQgaW50byBhIGhvbWUgbmV0d29yayBpcyBl bm91Z2gNCj4+Pj4+IHRvIGFkZCBjb21wbGV4aXR5IHRoYXQgbmVlZHMgdG8gYmUgYWRkcmVzc2Vk LCBhbmQgbXVsdGlwbGUNCj4+Pj4+IGRlZGljYXRlZCBzZWdtZW50cyBhcmUgbmVjZXNzYXJ5IGZv ciBzb21lIGNhc2VzLiBGb3IgaW5zdGFuY2UsIGENCj4+Pj4+IGNvbW1vbiBmZWF0dXJlIGluIG1v ZGVybiBob21lIHJvdXRlcnMgaW4gdGhlIGFiaWxpdHkgdG8gc3VwcG9ydA0KPj4+Pj4gYm90aCBn dWVzdCBhbmQgcHJpdmF0ZSBuZXR3b3JrIHNlZ21lbnRzLiBBbHNvLCBsaW5rIGxheWVyDQo+Pj4+ PiBuZXR3b3JraW5nIHRlY2hub2xvZ3kgaXMgcG9pc2VkIHRvIGJlY29tZSBtb3JlIGhldGVyb2dl bmVvdXMsIGFzDQo+Pj4+PiBuZXR3b3JrcyBiZWdpbiB0byBlbXBsb3kgYm90aCB0cmFkaXRpb25h bCBFdGhlcm5ldCB0ZWNobm9sb2d5IGFuZA0KPj4+Pj4gbGluayBsYXllcnMgZGVzaWduZWQgZm9y IGxvdy1wb3dlcmVkIHNlbnNvciBuZXR3b3Jrcy4gRmluYWxseSwNCj4+Pj4+IHNpbWlsYXIgbmVl ZHMgZm9yIHNlZ21lbnRhdGlvbiBtYXkgb2NjdXIgaW4gb3RoZXIgY2FzZXMsIHN1Y2ggYXMNCj4+ Pj4+IHNlcGFyYXRpbmcgYnVpbGRpbmcgY29udHJvbCBvciBjb3Jwb3JhdGUgZXh0ZW5zaW9ucyBm cm9tIHRoZQ0KPj4+Pj4gSW50ZXJuZXQgYWNjZXNzIG5ldHdvcmsuIERpZmZlcmVudCBzZWdtZW50 cyBtYXkgYmUgYXNzb2NpYXRlZCB3aXRoDQo+Pj4+PiBzdWJuZXRzIHRoYXQgaGF2ZSBkaWZmZXJl bnQgcm91dGluZyBhbmQgc2VjdXJpdHkgcG9saWNpZXMuDQo+Pj4+Pg0KPj4+Pj4gbyBTZXJ2aWNl IHByb3ZpZGVycyBhcmUgZGVwbG95aW5nIElQdjYsIGFuZCBzdXBwb3J0IGZvciBJUHY2IGlzDQo+ Pj4+PiBpbmNyZWFzaW5nbHkgYXZhaWxhYmxlIGluIGhvbWUgZ2F0ZXdheSBkZXZpY2VzLiBXaGls ZSBJUHY2IHJlc2VtYmxlcw0KPj4+Pj4gSVB2NCBpbiBtYW55IHdheXMsIGl0IGNoYW5nZXMgYWRk cmVzcyBhbGxvY2F0aW9uIHByaW5jaXBsZXMgYW5kDQo+Pj4+PmFsbG93cw0KPj4+Pj4gZGlyZWN0 IElQIGFkZHJlc3NhYmlsaXR5IGFuZCByb3V0aW5nIHRvIGRldmljZXMgaW4gdGhlIGhvbWUgZnJv bSB0aGUNCj4+Pj4+IEludGVybmV0LiBUaGlzIGlzIGEgcHJvbWlzaW5nIGFyZWEgaW4gSVB2NiB0 aGF0IGhhcyBwcm92ZWQNCj4+Pj4+Y2hhbGxlbmdpbmcNCj4+Pj4+IGluIElQdjQgd2l0aCB0aGUg cHJvbGlmZXJhdGlvbiBvZiBOQVQuDQo+Pj4+Pg0KPj4+Pj4gbyBFbmQtdG8tZW5kIGNvbW11bmlj YXRpb24gaXMgYm90aCBhbiBvcHBvcnR1bml0eSBhbmQgYSBjb25jZXJuIGFzIGl0DQo+Pj4+PiBl bmFibGVzIG5ldyBhcHBsaWNhdGlvbnMgYnV0IGFsc28gZXhwb3NlcyBub2RlcyBpbiB0aGUgaW50 ZXJuYWwNCj4+Pj4+IG5ldHdvcmtzIHRvIHJlY2VpcHQgb2YgdW53YW50ZWQgdHJhZmZpYyBmcm9t IHRoZSBJbnRlcm5ldC4gRmlyZXdhbGxzDQo+Pj4+PiB0aGF0IHJlc3RyaWN0IGluY29taW5nIGNv bm5lY3Rpb25zIG1heSBiZSB1c2VkIHRvIHByZXZlbnQgZXhwb3N1cmUsDQo+Pj4+PiBob3dldmVy LCB0aGlzIHJlZHVjZXMgdGhlIGVmZmljYWN5IG9mIGVuZC10by1lbmQgY29ubmVjdGl2aXR5IHRo YXQNCj4+Pj4+IElQdjYgaGFzIHRoZSBwb3RlbnRpYWwgdG8gcmVzdG9yZS4NCj4+Pj4+DQo+Pj4+ PiBIb21lIG5ldHdvcmtzIG5lZWQgdG8gcHJvdmlkZSB0aGUgdG9vbHMgdG8gaGFuZGxlIHRoZXNl IHNpdHVhdGlvbnMgaW4NCj4+Pj4+IGEgbWFubmVyIGFjY2Vzc2libGUgdG8gYWxsIHVzZXJzIG9m IGhvbWUgbmV0d29ya3MuIE1hbnVhbA0KPj4+Pj4gY29uZmlndXJhdGlvbiBpcyByYXJlbHksIGlm IGF0IGFsbCwgcG9zc2libGUuIFRoZSBwdXJwb3NlIG9mIHRoaXMNCj4+Pj4+IHdvcmtpbmcgZ3Jv dXAgaXMgdG8gZm9jdXMgb24gdGhpcyBldm9sdXRpb24sIGluIHBhcnRpY3VsYXIgYXMgaXQNCj4+ Pj4+IGFkZHJlc3NlcyB0aGUgaW50cm9kdWN0aW9uIG9mIElQdjYsIGJ5IGRldmVsb3BpbmcgYW4g YXJjaGl0ZWN0dXJlDQo+Pj4+PiBhZGRyZXNzaW5nIHRoaXMgZnVsbCBzY29wZSBvZiByZXF1aXJl bWVudHM6DQo+Pj4+Pg0KPj4+Pj4gbyBwcmVmaXggY29uZmlndXJhdGlvbiBmb3Igcm91dGVycw0K Pj4+Pj4gbyBtYW5hZ2luZyByb3V0aW5nDQo+Pj4+PiBvIG5hbWUgcmVzb2x1dGlvbg0KPj4+Pj4g byBzZXJ2aWNlIGRpc2NvdmVyeQ0KPj4+Pj4gbyBuZXR3b3JrIHNlY3VyaXR5DQo+Pj4+Pg0KPj4+ Pj4gVGhlIHRhc2sgb2YgdGhlIGdyb3VwIGlzIHRvIHByb2R1Y2UgYW4gYXJjaGl0ZWN0dXJlIGRv Y3VtZW50IHRoYXQNCj4+Pj4+IG91dGxpbmVzIGhvdyB0byBjb25zdHJ1Y3QgaG9tZSBuZXR3b3Jr cyBpbnZvbHZpbmcgbXVsdGlwbGUgcm91dGVycw0KPj4+Pj5hbmQNCj4+Pj4+IHN1Ym5ldHMuIFRo aXMgZG9jdW1lbnQgaXMgZXhwZWN0ZWQgdG8gYXBwbHkgdGhlIElQdjYgYWRkcmVzc2luZw0KPj4+ Pj4gYXJjaGl0ZWN0dXJlLCBwcmVmaXggZGVsZWdhdGlvbiwgZ2xvYmFsIGFuZCBVTEEgYWRkcmVz c2VzLCBzb3VyY2UNCj4+Pj4+IGFkZHJlc3Mgc2VsZWN0aW9uIHJ1bGVzIGFuZCBvdGhlciBleGlz dGluZyBjb21wb25lbnRzIG9mIHRoZSBJUHY2DQo+Pj4+PiBhcmNoaXRlY3R1cmUuIFRoZSBhcmNo aXRlY3R1cmUgZG9jdW1lbnQgc2hvdWxkIGRyaXZlIHdoYXQgcHJvdG9jb2xzDQo+Pj4+PiBjaGFu Z2VzLCBpZiBhbnksIGFyZSBuZWNlc3NhcnkuIFNwZWNpZmljIHByb3RvY29sIHdvcmsgZGVzY3Jp YmVkDQo+Pj4+PmJlbG93DQo+Pj4+PiBpcyBleHBlY3RlZCB0byBiZSB3aXRoaW4gdGhlIHNjb3Bl IG9mIHRoZSB3b3JraW5nIGdyb3VwIG9uZSB0aGUNCj4+Pj4+IGFyY2hpdGVjdHVyZSB3b3JrIGlz IGNvbXBsZXRlLiBIb3dldmVyLCB0aGUgZ3JvdXAgaXMgcmVxdWlyZWQgdG8NCj4+Pj4+IHJldmll dyBpdHMgY2hhcnRlciBhbmQgbWlsZXN0b25lcyB3aXRoIHRoZSBJRVNHIGFuZCBJRVRGIGNvbW11 bml0eQ0KPj4+Pj4gYmVmb3JlIHN1Ym1pdHRpbmcgZG9jdW1lbnRzIHRoYXQgbWFrZSBwcm90b2Nv bCBjaGFuZ2VzLiBJdCBpcw0KPj4+Pj5leHBlY3RlZA0KPj4+Pj4gdGhhdCB0aGUgZ3JvdXAgaGFz IHRvIGRpc2N1c3Mgc29tZSBvZiB0aGUgYmVsb3cgc29sdXRpb25zLCBob3dldmVyLA0KPj4+Pj5p bg0KPj4+Pj4gb3JkZXIgdG8gY29tcGxldGUgdGhlIGFyY2hpdGVjdHVyZSB3b3JrLg0KPj4+Pj4N Cj4+Pj4+IFRoZSBncm91cCB3aWxsIGFwcGx5IGV4aXN0aW5nIHByb3RvY29scyB0byBoYW5kbGUg dGhlIGZpdmUNCj4+Pj4+IHJlcXVpcmVtZW50cyBhYm92ZS4gRm9yIHByZWZpeCBjb25maWd1cmF0 aW9uLCBleGlzdGluZyBwcm90b2NvbHMgYXJlDQo+Pj4+PiBsaWtlbHkgc3VmZmljaWVudCwgYW5k IGF0IHdvcnN0IG1heSBuZWVkIHNvbWUgc21hbGwgZW5oYW5jZW1lbnRzLA0KPj4+Pj5zdWNoDQo+ Pj4+PiBhcyBuZXcgb3B0aW9ucy4gRm9yIGF1dG9tYXRpYyByb3V0aW5nLCBpdCBpcyBleHBlY3Rl ZCB0aGF0IGV4aXN0aW5nDQo+Pj4+PiByb3V0aW5nIHByb3RvY29scyBjYW4gYmUgdXNlZCBhcyBp cywgaG93ZXZlciwgYSBuZXcgbWVjaGFuaXNtIG1heSBiZQ0KPj4+Pj4gbmVlZGVkIGluIG9yZGVy IHRvIHR1cm4gYSBzZWxlY3RlZCBwcm90b2NvbCBvbiBieSBkZWZhdWx0LiBGb3IgbmFtZQ0KPj4+ Pj4gcmVzb2x1dGlvbiBhbmQgc2VydmljZSBkaXNjb3ZlcnksIGV4dGVuc2lvbnMgdG8gZXhpc3Rp bmcNCj4+Pj4+IG11bHRpY2FzdC1iYXNlZCBuYW1lIHJlc29sdXRpb24gcHJvdG9jb2xzIGFyZSBu ZWVkZWQgdG8gZW5hYmxlIHRoZW0NCj4+Pj4+dG8NCj4+Pj4+IHdvcmsgYWNyb3NzIHN1Ym5ldHMu DQo+Pj4+Pg0KPj4+Pj4gRm9yIG5ldHdvcmsgc2VjdXJpdHksIHRoZSBncm91cCBzaGFsbCBkb2N1 bWVudCB0aGUgY29uY2VwdCBvZg0KPj4+Pj4gImFkdmFuY2VkIHNlY3VyaXR5IiBhcyBhIGZ1cnRo ZXIgZGV2ZWxvcG1lbnQgb2YgInNpbXBsZSBzZWN1cml0eSINCj4+Pj4+ZnJvbQ0KPj4+Pj4gUkZD IDYwOTIuIFRoZSBtYWluIGdvYWwgb2YgdGhpcyB3b3JrIGlzIHRvIGVuYWJsZSBhIHNlY3VyaXR5 IHBvbGljeQ0KPj4+Pj4gdGhhdCBhZGFwdHMgdG8gSVB2NiB0aHJlYXRzIGFzIHRoZXkgZW1lcmdl LCB0YWtpbmcgaW50byBhY2NvdW50IG5vdA0KPj4+Pj4gb25seSB0cmFmZmljIGZyb20gdGhlIElu dGVybmV0IGF0IGxhcmdlLCBidXQgd2l0aGluIGFuZCBsZWF2aW5nIHRoZQ0KPj4+Pj4gaG9tZSBu ZXR3b3JrIGl0c2VsZi4NCj4+Pj4+DQo+Pj4+PiBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgZGVmaW5lIGEgc2V0IG9mIHByb3RvY29sDQo+Pj4+PiBzcGVjaWZpY2F0 aW9ucyB0byBhY2NvbXBsaXNoIHRoZSBmaXZlIHJlcXVpcmVtZW50cyBmcm9tDQo+Pj4+PiBhYm92 ZS4gSG93ZXZlciwgaXQgaXMgbm90IGluIHRoZSBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cCB0 byBkZWZpbmUNCj4+Pj4+IGVudGlyZWx5IG5ldyByb3V0aW5nIHByb3RvY29scyBvciBhZGRyZXNz IGFsbG9jYXRpb24gcHJvdG9jb2xzLiBBcw0KPj4+Pj4gbm90ZWQsIGFkZGl0aW9uYWwgb3B0aW9u cyBvciBvdGhlciBzbWFsbCBleHRlbnNpb25zIG1heSBiZSBuZWNlc3NhcnkNCj4+Pj4+IHRvIHVz ZSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGluIHRoZXNlIG5ldyBjb25maWd1cmF0aW9uIHRhc2tz LiBUaGUNCj4+Pj4+IHdvcmtpbmcgZ3JvdXAgc2hhbGwgYWxzbyBub3QgbWFrZSBhbnkgY2hhbmdl cyB0byBJUHY2IHByb3RvY29scyBvcg0KPj4+Pj4gYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUuIFBy ZWZpeCBjb25maWd1cmF0aW9uLCByb3V0aW5nLCBhbmQgc2VjdXJpdHkNCj4+Pj4+IHJlbGF0ZWQg d29yayBzaGFsbCBub3QgY2F1c2UgYW55IGNoYW5nZXMgdGhhdCBhcmUgbm90IGJhY2t3YXJkcw0K Pj4+Pj4gY29tcGF0aWJsZSB0byBleGlzdGluZyBJUHY2IGhvc3RzLiBUaGVyZSBtYXkgYmUgaG9z dCB2aXNpYmxlIGNoYW5nZXMNCj4+Pj4+IGluIHRoZSB3b3JrIG9uIG5hbWluZyBhbmQgZGlzY292 ZXJ5IHByb3RvY29scywgaG93ZXZlci4gSW4gaXRzDQo+Pj4+PmRlc2lnbiwNCj4+Pj4+IHRoZSB3 b3JraW5nIGdyb3VwIHNoYWxsIGFsc28gY29uc2lkZXIgc2VjdXJpdHkgYXNwZWN0cyBhbmQgdGhl IGltcGFjdA0KPj4+Pj4gb24gbWFuYWdlYWJpbGl0eS4gVGhlIG1haW4gZm9jdXMgb2YgdGhlIHdv cmtpbmcgZ3JvdXAgaXMgaG9tZQ0KPj4+Pj4gbmV0d29ya3MsIGJ1dCB0aGUgZ3JvdXAncyByZXN1 bHRzIG1heSBhbHNvIGZpbmQgYXBwbGljYXRpb25zIGluIG90aGVyDQo+Pj4+PiBzbWFsbCBuZXR3 b3Jrcy4NCj4+Pj4+DQo+Pj4+PiBUaGUgd29ya2luZyBncm91cCB3aWxsIGxpYWlzZSB3aXRoIHRo ZSByZWxldmFudCBJRVRGIHdvcmtpbmcNCj4+Pj4+IGdyb3Vwcy4gSW4gcGFydGljdWxhciwgdGhl IGdyb3VwIHNob3VsZCB3b3JrIGNsb3NlbHkgd2l0aCB0aGUgVjZPUFMNCj4+Pj4+IHdvcmtpbmcg Z3JvdXAsIHJldmlldyBhbnkgdXNlIG9yIGV4dGVuc2lvbiBvZiBESENQIHdpdGggdGhlIERIQw0K Pj4+Pj4gd29ya2luZyBncm91cCwgYW5kIHdvcmsgd2l0aCBhZGRpdGlvbmFsIEROUyByZXF1aXJl bWVudHMgd2l0aCB0aGUNCj4+Pj4+IEROU0VYVCBhbmQgRE5TT1Agd29ya2luZyBncm91cHMuIElm IGl0IHR1cm5zIG91dCB0aGF0IGFkZGl0aW9uYWwNCj4+Pj4+IG9wdGlvbnMgYXJlIG5lZWRlZCBm b3IgYSByb3V0aW5nIHByb3RvY29sLCB0aGV5IHdpbGwgYmUgZGV2ZWxvcGVkIGluDQo+Pj4+PiB0 aGUgYXBwcm9wcmlhdGUgUm91dGluZyBBcmVhIHdvcmtpbmcgZ3JvdXAsIHdpdGggdGhlIEhPTUVO RVQgd29ya2luZw0KPj4+Pj4gZ3JvdXAgcHJvdmlkaW5nIHRoZSBhcmNoaXRlY3R1cmUgYW5kIHJl cXVpcmVtZW50cyBmb3Igc3VjaA0KPj4+Pj4gZW5oYW5jZW1lbnRzLiBUaGUgd29ya2luZyBncm91 cCB3aWxsIGFsc28gbGlhc2Ugd2l0aCBleHRlcm5hbA0KPj4+Pj4gc3RhbmRhcmRzIGJvZGllcyB3 aGVyZSBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZXJlIGFyZSBub3JtYXRpdmUNCj4+Pj4+IGRlcGVu ZGVuY2llcyBiZXR3ZWVuIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiB0aGUgdHdvIGJvZGllcy4NCj4+ Pj4+IEl0IGlzIGV4cGVjdGVkIHRoYXQgaW4gdGhlIGFyY2hpdGVjdHVyZSBkZWZpbml0aW9uIHN0 YWdlIGxpYWlzaW5nDQo+Pj4+PiB3aXRoIHRoZSBCcm9hZGJhbmQgRm9ydW0sIERMTkEsIGFuZCBV UG5QIEZvcnVtIGlzIG5lY2Vzc2FyeS4NCj4+Pj4+DQo+Pj4+PiBNaWxlc3RvbmVzOg0KPj4+Pj4N Cj4+Pj4+IEp1bCAyMDExIEZvcm1hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cA0KPj4+Pj4gU2Vw IDIwMTEgRmlyc3QgV0cgZHJhZnQgb24gdGhlIGFyY2hpdGVjdHVyZQ0KPj4+Pj4gRGVjIDIwMTEg U3VibWlzc2lvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IHRvIHRoZSBJRVNHIGFzDQo+Pj4+ PiBJbmZvcm1hdGlvbmFsIFJGQw0KPj4+Pj4gRGVjIDIwMTEgQ2hhcnRlciByZS1ldmFsdWF0aW9u IGJhc2VkIG9uIHRoZSBhcmNoaXRlY3R1cmUgd29yaw0KPj4+Pj4gRGVjIDIwMTEgRmlyc3QgV0cg ZHJhZnQgb24gcHJlZml4IGNvbmZpZ3VyYXRpb24NCj4+Pj4+IERlYyAyMDExIEZpcnN0IFdHIGRy YWZ0IG9uIHJvdXRpbmcNCj4+Pj4+IEphbiAyMDEyIEZpcnN0IFdHIGRyYWZ0IG9uIG5hbWUgcmVz b2x1dGlvbg0KPj4+Pj4gRmViIDIwMTIgRmlyc3QgV0cgZHJhZnQgb24gc2VydmljZSBkaXNjb3Zl cnkNCj4+Pj4+IEZlYiAyMDEyIEZpcnN0IFdHIGRyYWZ0IG9uIHBlcmltZXRlciBzZWN1cml0eQ0K Pj4+Pj4gRmViIDIwMTIgU3RhcnQgb2Ygcm91dGluZyByZWxhdGVkIHdvcmsgaW4gdGhlIHJlbGV2 YW50IHJvdXRpbmcgYXJlYQ0KPj4+Pj4gd29ya2luZyBncm91cCwgaWYgbmVlZGVkDQo+Pj4+PiBN YXIgMjAxMiBTdWJtaXNzaW9uIG9mIHRoZSBwcmVmaXggY29uZmlndXJhdGlvbiBkcmFmdCB0byB0 aGUgSUVTRyBhcw0KPj4+Pj4gU3RhbmRhcmRzIFRyYWNrIFJGQw0KPj4+Pj4gQXByIDIwMTIgU3Vi bWlzc2lvbiBvZiB0aGUgcm91dGluZyBkcmFmdCB0byB0aGUgSUVTRyBhcyBJbmZvcm1hdGlvbmFs DQo+Pj4+PiBSRkMNCj4+Pj4+IFNlcCAyMDEyIFN1Ym1pc3Npb24gb2YgdGhlIG5hbWUgcmVzb2x1 dGlvbiBkcmFmdCB0byB0aGUgSUVTRyBhcw0KPj4+Pj4gU3RhbmRhcmRzIFRyYWNrIFJGQw0KPj4+ Pj4gTm92IDIwMTIgU3VibWlzc2lvbiBvZiB0aGUgc2VydmljZSBkaXNjb3ZlcnkgZHJhZnQgdG8g dGhlIElFU0cgYXMNCj4+Pj4+IFN0YW5kYXJkcyBUcmFjayBSRkMNCj4+Pj4+IERlYyAyMDEyIFN1 Ym1pc3Npb24gb2YgdGhlIHBlcmltZXRlciBzZWN1cml0eSBkcmFmdCB0byB0aGUgSUVTRyBhcw0K Pj4+Pj4gSW5mb3JtYXRpb25hbCBSRkMNCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gZnVuIG1haWxpbmcgbGlzdA0KPj4+ Pj4gZnVuQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Z1bg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiBmdW4gbWFpbGluZyBsaXN0DQo+Pj4+IGZ1bkBpZXRmLm9yZw0KPj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Z1bg0KPj4+DQo+Pj4NCj4+ PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l IFdhcm5lciBDYWJsZQ0KPj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdA0KPj4+dG8gY29weXJpZ2h0IGJlbG9uZ2lu ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+PnNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMN Cj4+PmFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0 aGlzIEUtbWFpbCwgeW91DQo+Pj5hcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3INCj4+PmFjdGlvbiB0YWtlbiBpbiByZWxh dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMNCj4+PkUtbWFp bCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZl IHJlY2VpdmVkDQo+Pj50aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4+cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBh bmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueQ0KPj4+cHJpbnRvdXQuDQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGZ1biBt YWlsaW5nIGxpc3QNCj4+IGZ1bkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9mdW4NCj4NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1h dGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNv cHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxh dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkg b2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From moore@network-heretics.com Fri Jul 1 06:36:35 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8485011E8148; Fri, 1 Jul 2011 06:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi6MpFJXu2Hr; Fri, 1 Jul 2011 06:36:34 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5406821F84D7; Fri, 1 Jul 2011 06:36:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5552B20905; Fri, 1 Jul 2011 09:36:12 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 01 Jul 2011 09:36:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=qpQfdnE3I93odyBFsVX+LbxFeGs=; b=lUGVFN02KT0lSochgz5ZpIhKBdjHgELi0QT1TSItpDuRMfgJ29blkR+YfktT/xUZuV86O+fdGjB/jlNanGfWhjtAxRlKxrMy5DwPp8Bff3WcTWtVnVlDhJDhQHNWBrkTMrg650AZdsyRCFY43LHJtukQ6BkGyE/CWHP+kLCKV3k= X-Sasl-enc: i0cKhgjK5+moYNIol8osIEUhU+TVYZyUBERv5RehBeVl 1309527371 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 3E91A40444B; Fri, 1 Jul 2011 09:36:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <0B6FEF9D-430B-4C56-BB21-40C5ED888B51@townsley.net> Date: Fri, 1 Jul 2011 09:35:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <0B6FEF9D-430B-4C56-BB21-40C5ED888B51@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion , homegate@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:36:35 -0000 On Jul 1, 2011, at 4:53 AM, Mark Townsley wrote: > The idea is not to go out of our way for IPv4, but if the topic is IP = agnostic anyway, so be it. To be clear, there is no *requirement* to = support IPv4 here. However, there is no requirement to avoid IPv4 *if* = it doesn't cause significant concession in the IPv6 design either. >=20 > This cuts both ways, if there is something that is working well in = IPv4 that we need to carry over to IPv6 with simple extensions, we'll do = that and capitalizing on that running-code should be considered a good = thing. We don't want to invent new v6 protocols from scratch that don't = work with IPv4 when there is no need. For example (and I think this is = hinted at in the charter), we might use naming and service discovery = that already exists for IPv4, adapted the the v6 homenet. This doesn't = mean we need to re-invent a v6-only naming system from scratch - i'd = much rather use one that is there, which very well may support v4 and = v6.=20 >=20 >>=20 >> please don't constrain home networks to work only within the confines = of IPv4 brain damage. >=20 > What I think I am saying here is that we will do our best to perform = as if our brains are not damaged, and equally try to avoid damaging our = brains in the process. +1 Keith From rdroms@cisco.com Fri Jul 1 07:37:46 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E5D11E8080; Fri, 1 Jul 2011 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.145 X-Spam-Level: X-Spam-Status: No, score=-9.145 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y9uvDp3rOnY; Fri, 1 Jul 2011 07:37:44 -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 EEE0A11E807F; Fri, 1 Jul 2011 07:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=19179; q=dns/txt; s=iport; t=1309531064; x=1310740664; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yeIFwzdCb/Ad9VLWln7qnbk/PEY1wTqRn1nP54jawlo=; b=RJJJybukgv5w8y9Cr4n7Rt4wvhOw0jq1m8N8bqfK+zKJ5LDymUH4cLnN 0v5PYgSTuSehumMu+tZipPHJwNxd5YE7T8bPQyKbXgGUo7KMt4F9Ieslr sTd/RoUB2ZqVCvkuUtdSEwh4nmgfOgykzgc1K+wg4fr3mkA2tF/dCqvdd 8=; X-IronPort-AV: E=Sophos;i="4.65,458,1304294400"; d="scan'208";a="99225645" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Jul 2011 14:37:43 +0000 Received: from [10.21.108.95] ([10.21.108.95]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p61Ebegn030917; Fri, 1 Jul 2011 14:37:41 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: Date: Fri, 1 Jul 2011 10:37:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F9A2F4E-54D4-47EB-B57D-041BB56F9523@cisco.com> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org, homegate@ietf.org, "JP Vasseur \(jvasseur\)" Subject: Re: [fun] [homegate] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 14:37:46 -0000 On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote: >=20 >=20 > On 7/1/11 4:06 AM, "Mark Townsley" wrote: >=20 >>=20 >> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote: >>=20 >>> I also think that this deals with an important topic and the list of >>> items listed on the proposed charter are quite relevant. I'm just = not >>> entirely clear on the "routing component": are you referring to: >>> * A requirement document for Routing in the home? >>=20 >> At least a section within a home architecture document. >>=20 >>> * A recommendation for a specific routing protocol ? >=20 > [JW] I see a guidelines/analysis for link-state vs. distance-vector > routing protocols in a multi-segment home network as being useful. In my opinion, operation without active admin intervention is more = important than the particular technology. =20 >>> * A framework before the specification of a new routing protocol ? >=20 > [JW] A framework or justification statement for a new lightweight = routing > protocol would be useful as well. A source/dest aware protocol has = been > proposed as a possible solution for the multi-homed home network for > example. >> The charter says: >>=20 >> "For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default." Source/dest aware protocol sounds more like a research project. = Developing requirements might be in scope for homenet. - Ralph >>=20 >> - Mark >>=20 >>=20 >>> I'm clearly not expressing an opinion, just a question. >>> Thanks. >>> JP. >>>=20 >>> JP Vasseur >>> Cisco Fellow >>>=20 >>> Sent from Blackberry >>>=20 >>> ----- Original Message ----- >>> From: Mark Townsley [mailto:mark@townsley.net] >>> Sent: Thursday, June 30, 2011 11:36 AM >>> To: Weil, Jason >>> Cc: fun@ietf.org ; homegate@ietf.org = >>> Subject: Re: [fun] status of the homenet effort >>>=20 >>>=20 >>> Thank you for the feedback, keep it coming. >>>=20 >>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: >>>=20 >>>> Mark, Raplh, Jari, et all, >>>>=20 >>>> I really appreciate the change in charter and direction for this >>>> proposed >>>> WG and the interest to keep it going. I believe it sets a path that = is >>>> scoped narrow enough to provide a workplace for achievable results. >>>>=20 >>>> As a provider working on writing, testing and implementing IPv6 = CPE, I >>>> can >>>> relate firsthand that getting basic IPv6 functionality working in = the >>>> home >>>> network is no simple feat and is still a work in progress. Don't = get me >>>> wrong, basic functionality is there just not baked. What seems very >>>> straightforward in theory typically fails in a multitude of corner >>>> cases >>>> ie reality. And just to clarify I am referring to a single /64 = subnet >>>> topology with no routing. >>>>=20 >>>> If we can stay focussed on solving just the basics for the five = areas >>>> included, I believe it will be helpful. The other recommendation = would >>>> be >>>> to work as expeditiously as possible. Providers in the process of >>>> deploying IPv6 now are already deep into this analysis and = development >>>> with their vendors. If we wait too long then these topics will be >>>> solved >>>> with interoperability a possible casualty. >>>>=20 >>>> FWIW, I would also add that the five topics in the charter are also >>>> listed >>>> in order >>>> Of priority at least for me. >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Jason >>>>=20 >>>>=20 >>>> On 6/29/11 5:46 AM, "Mark Townsley" wrote: >>>>=20 >>>>>=20 >>>>> All, >>>>>=20 >>>>> Apologies for double-posting if there are folks that are = subscribed to >>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone = will >>>>> finally create homenet@ietf.org and consolidate the membership >>>>> accordingly. >>>>>=20 >>>>> In the charter proposal below, I think you will see a lot of >>>>> similarity >>>>> with the consensus we achieved on the homegate list last year. = Jari >>>>> has >>>>> taken that, feedback from the IESG, IAB, members of the >>>>> IP-Directorate, >>>>> v6ops chairs, etc. and shaped it towards something more focused on = the >>>>> Internet (and Routing) area, as well as IPv6. I believe he and = Ralph >>>>> both >>>>> have a great deal of confidence that this is something that is = very >>>>> important to the industry, and that the IETF has a critical role = to >>>>> play. >>>>>=20 >>>>> So, make no mistake, whether we end up as a WG or a BoF between = now >>>>> and >>>>> Quebec, "we're back" - please send comments, and make your travel = or >>>>> remote-attendance plans accordingly if you want to participate. >>>>>=20 >>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd >>>>> like to >>>>> take requests for presentation time now. Jari and I will likely = begin >>>>> the >>>>> session with a scoping overview, as well as a first cut at an >>>>> architecture framework, but there should be some time for a few = other >>>>> items. When submitting your request, please identify which of the = 5 >>>>> areas >>>>> below you think your work applies to as well as the = internet-draft, of >>>>> course. >>>>>=20 >>>>> Thanks, and see you on the list and in Quebec. >>>>>=20 >>>>> - Mark >>>>>=20 >>>>>=20 >>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>>>>=20 >>>>>> I wanted to provide an update of the situation with this working >>>>>> group >>>>>> proposal. >>>>>>=20 >>>>>> HOMENET is a new working group proposal, a variation of the >>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time >>>>>> looking at it from a different angle. The old effort was mostly >>>>>> focused >>>>>> about what home gateways should do: forwarding, transport, and = DNS >>>>>> proxying issues. The new effort is about home networks = themselves, in >>>>>> particular what kind of network architecture and configuration is >>>>>> necessary to support IPv6-based home networks. We view IPv4-based >>>>>> home >>>>>> networks as "done" at this time (or perhaps as "cannot be changed >>>>>> anyway"). >>>>>>=20 >>>>>> I have been discussing this effort in the background for the last >>>>>> couple of month with Mark Townsley and others, and more publicly >>>>>> since >>>>>> early June. The proposal has been brought to the IESG, IAB and = some >>>>>> directorates for discussion, and we've been going back and forth >>>>>> whether >>>>>> this is ready to become a working group or needs to be run as a = BOF >>>>>> in >>>>>> Quebec City. The current plan is that the working group proposal >>>>>> goes to >>>>>> IETF-wide review this week, and if the feedback from the = community, >>>>>> IAB, >>>>>> and the IESG is positive, we will create the working group just = in >>>>>> time >>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the >>>>>> meeting >>>>>> will be used to run the proposal as a BOF. >>>>>>=20 >>>>>> In any case, I would like to solicit discussion on this topic, = and >>>>>> perhaps some early drafts as well. Please comment on the charter = at >>>>>> least. >>>>>>=20 >>>>>> Note that the new proposal was called FUN at the time that we = created >>>>>> the list. It has now been renamed back to HOMENET to be more >>>>>> descriptive. The list will be renamed soon as well (current >>>>>> subscribers >>>>>> will stay). >>>>>>=20 >>>>>> This is the most recent version of the charter we should discuss: >>>>>>=20 >>>>>> Home Networks (homenet) >>>>>> ----------------------------------- >>>>>>=20 >>>>>> Current Status: Proposed >>>>>> Last Edit: Wednesday, June 29th, 2011 >>>>>>=20 >>>>>> Chairs: >>>>>> TBD >>>>>>=20 >>>>>> Internet Area Directors: >>>>>> Ralph Droms >>>>>> Jari Arkko >>>>>>=20 >>>>>> Internet Area Advisor: >>>>>> Jari Arkko >>>>>>=20 >>>>>> Routing Area Technical Advisor: >>>>>> TBD >>>>>>=20 >>>>>> Security Area Technical Advisor: >>>>>> TBD >>>>>>=20 >>>>>> Mailing Lists: >>>>>> General Discussion: fun@ietf.org >>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>>>>> Archive: http://www.ietf.org/mail-archive/web/fun >>>>>>=20 >>>>>> Description of Working Group: >>>>>>=20 >>>>>> This working group focuses on the evolving networking technology >>>>>> within and among relatively small =B3residential home=B2 = networks. For >>>>>> example, an obvious trend in home networking is the proliferation = of >>>>>> networking technology in an increasingly broad range and number = of >>>>>> devices. This evolution in scale and diversity sets some = requirements >>>>>> on IETF protocols. Some of the relevant trends include: >>>>>>=20 >>>>>> o Multiple segments: While less complex L3-toplogies involving as = few >>>>>> subnets as possible are preferred in home networks for a variety = of >>>>>> reasons including simpler management and service discovery, the >>>>>> introduction of more than one subnet into a home network is = enough >>>>>> to add complexity that needs to be addressed, and multiple >>>>>> dedicated segments are necessary for some cases. For instance, a >>>>>> common feature in modern home routers in the ability to support >>>>>> both guest and private network segments. Also, link layer >>>>>> networking technology is poised to become more heterogeneous, as >>>>>> networks begin to employ both traditional Ethernet technology and >>>>>> link layers designed for low-powered sensor networks. Finally, >>>>>> similar needs for segmentation may occur in other cases, such as >>>>>> separating building control or corporate extensions from the >>>>>> Internet access network. Different segments may be associated = with >>>>>> subnets that have different routing and security policies. >>>>>>=20 >>>>>> o Service providers are deploying IPv6, and support for IPv6 is >>>>>> increasingly available in home gateway devices. While IPv6 = resembles >>>>>> IPv4 in many ways, it changes address allocation principles and >>>>>> allows >>>>>> direct IP addressability and routing to devices in the home from = the >>>>>> Internet. This is a promising area in IPv6 that has proved >>>>>> challenging >>>>>> in IPv4 with the proliferation of NAT. >>>>>>=20 >>>>>> o End-to-end communication is both an opportunity and a concern = as it >>>>>> enables new applications but also exposes nodes in the internal >>>>>> networks to receipt of unwanted traffic from the Internet. = Firewalls >>>>>> that restrict incoming connections may be used to prevent = exposure, >>>>>> however, this reduces the efficacy of end-to-end connectivity = that >>>>>> IPv6 has the potential to restore. >>>>>>=20 >>>>>> Home networks need to provide the tools to handle these = situations in >>>>>> a manner accessible to all users of home networks. Manual >>>>>> configuration is rarely, if at all, possible. The purpose of this >>>>>> working group is to focus on this evolution, in particular as it >>>>>> addresses the introduction of IPv6, by developing an architecture >>>>>> addressing this full scope of requirements: >>>>>>=20 >>>>>> o prefix configuration for routers >>>>>> o managing routing >>>>>> o name resolution >>>>>> o service discovery >>>>>> o network security >>>>>>=20 >>>>>> The task of the group is to produce an architecture document that >>>>>> outlines how to construct home networks involving multiple = routers >>>>>> and >>>>>> subnets. This document is expected to apply the IPv6 addressing >>>>>> architecture, prefix delegation, global and ULA addresses, source >>>>>> address selection rules and other existing components of the IPv6 >>>>>> architecture. The architecture document should drive what = protocols >>>>>> changes, if any, are necessary. Specific protocol work described >>>>>> below >>>>>> is expected to be within the scope of the working group one the >>>>>> architecture work is complete. However, the group is required to >>>>>> review its charter and milestones with the IESG and IETF = community >>>>>> before submitting documents that make protocol changes. It is >>>>>> expected >>>>>> that the group has to discuss some of the below solutions, = however, >>>>>> in >>>>>> order to complete the architecture work. >>>>>>=20 >>>>>> The group will apply existing protocols to handle the five >>>>>> requirements above. For prefix configuration, existing protocols = are >>>>>> likely sufficient, and at worst may need some small enhancements, >>>>>> such >>>>>> as new options. For automatic routing, it is expected that = existing >>>>>> routing protocols can be used as is, however, a new mechanism may = be >>>>>> needed in order to turn a selected protocol on by default. For = name >>>>>> resolution and service discovery, extensions to existing >>>>>> multicast-based name resolution protocols are needed to enable = them >>>>>> to >>>>>> work across subnets. >>>>>>=20 >>>>>> For network security, the group shall document the concept of >>>>>> "advanced security" as a further development of "simple security" >>>>>> from >>>>>> RFC 6092. The main goal of this work is to enable a security = policy >>>>>> that adapts to IPv6 threats as they emerge, taking into account = not >>>>>> only traffic from the Internet at large, but within and leaving = the >>>>>> home network itself. >>>>>>=20 >>>>>> It is expected that the working group will define a set of = protocol >>>>>> specifications to accomplish the five requirements from >>>>>> above. However, it is not in the scope of the working group to = define >>>>>> entirely new routing protocols or address allocation protocols. = As >>>>>> noted, additional options or other small extensions may be = necessary >>>>>> to use the existing protocols in these new configuration tasks. = The >>>>>> working group shall also not make any changes to IPv6 protocols = or >>>>>> addressing architecture. Prefix configuration, routing, and = security >>>>>> related work shall not cause any changes that are not backwards >>>>>> compatible to existing IPv6 hosts. There may be host visible = changes >>>>>> in the work on naming and discovery protocols, however. In its >>>>>> design, >>>>>> the working group shall also consider security aspects and the = impact >>>>>> on manageability. The main focus of the working group is home >>>>>> networks, but the group's results may also find applications in = other >>>>>> small networks. >>>>>>=20 >>>>>> The working group will liaise with the relevant IETF working >>>>>> groups. In particular, the group should work closely with the = V6OPS >>>>>> working group, review any use or extension of DHCP with the DHC >>>>>> working group, and work with additional DNS requirements with the >>>>>> DNSEXT and DNSOP working groups. If it turns out that additional >>>>>> options are needed for a routing protocol, they will be developed = in >>>>>> the appropriate Routing Area working group, with the HOMENET = working >>>>>> group providing the architecture and requirements for such >>>>>> enhancements. The working group will also liase with external >>>>>> standards bodies where it is expected that there are normative >>>>>> dependencies between the specifications of the two bodies. >>>>>> It is expected that in the architecture definition stage liaising >>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>>>>=20 >>>>>> Milestones: >>>>>>=20 >>>>>> Jul 2011 Formation of the working group >>>>>> Sep 2011 First WG draft on the architecture >>>>>> Dec 2011 Submission of the architecture draft to the IESG as >>>>>> Informational RFC >>>>>> Dec 2011 Charter re-evaluation based on the architecture work >>>>>> Dec 2011 First WG draft on prefix configuration >>>>>> Dec 2011 First WG draft on routing >>>>>> Jan 2012 First WG draft on name resolution >>>>>> Feb 2012 First WG draft on service discovery >>>>>> Feb 2012 First WG draft on perimeter security >>>>>> Feb 2012 Start of routing related work in the relevant routing = area >>>>>> working group, if needed >>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG = as >>>>>> Standards Track RFC >>>>>> Apr 2012 Submission of the routing draft to the IESG as = Informational >>>>>> RFC >>>>>> Sep 2012 Submission of the name resolution draft to the IESG as >>>>>> Standards Track RFC >>>>>> Nov 2012 Submission of the service discovery draft to the IESG as >>>>>> Standards Track RFC >>>>>> Dec 2012 Submission of the perimeter security draft to the IESG = as >>>>>> Informational RFC >>>>>>=20 >>>>>> _______________________________________________ >>>>>> fun mailing list >>>>>> fun@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fun >>>>>=20 >>>>> _______________________________________________ >>>>> fun mailing list >>>>> fun@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fun >>>>=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. >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >>=20 >=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. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From jvasseur@cisco.com Fri Jul 1 08:01:36 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F179E8018; Fri, 1 Jul 2011 08:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63yujp9OgNH1; Fri, 1 Jul 2011 08:01:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 649B99E8008; Fri, 1 Jul 2011 08:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=19588; q=dns/txt; s=iport; t=1309532494; x=1310742094; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=rxQkMYvWsW4+Ngf6YLfOKiEuBALtpp9ARQrUpKBo9tw=; b=WQghVXBoavftytTXdrT7cum/Lkn4Dy7nNr7VuMj/5QqFxpB6KBKWOjIA A88GYOewzc/C/ZjTfijPwQd1s+gpyDmEyucNiHk0/fp/tGew3fjiZvWxl 9Ta55HnUu6Jend647+uJnoUVJ1TrsGmTxWdN1d2c68mx2/c5OBzOoxOn/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBABjhDU6tJXG8/2dsb2JhbABEDpgujzV3iHmhdZ4Bgx8TgwAEhz6Pc4RHhwk X-IronPort-AV: E=Sophos;i="4.65,458,1304294400"; d="scan'208";a="390088336" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2011 15:01:31 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p61F1Van022975; Fri, 1 Jul 2011 15:01:31 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 10:01:31 -0500 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: Fri, 1 Jul 2011 10:01:30 -0500 Message-ID: In-Reply-To: <9F9A2F4E-54D4-47EB-B57D-041BB56F9523@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] [fun] status of the homenet effort Thread-Index: Acw3/HFBeThPmlw3Txed3gx0hkraNQAA1FLP From: "JP Vasseur (jvasseur)" To: "Ralph Droms (rdroms)" , X-OriginalArrivalTime: 01 Jul 2011 15:01:31.0096 (UTC) FILETIME=[C2C7BD80:01CC37FF] Cc: fun@ietf.org, homegate@ietf.org Subject: Re: [fun] [homegate] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:01:36 -0000 Agreeing with Ralph. JP Vasseur Cisco Fellow Sent from Blackberry ----- Original Message ----- From: Ralph Droms (rdroms) Sent: Friday, July 01, 2011 09:37 AM To: Weil, Jason Cc: Mark Townsley ; JP Vasseur (jvasseur); = fun@ietf.org ; homegate@ietf.org Subject: Re: [homegate] [fun] status of the homenet effort On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote: >=20 >=20 > On 7/1/11 4:06 AM, "Mark Townsley" wrote: >=20 >>=20 >> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote: >>=20 >>> I also think that this deals with an important topic and the list of >>> items listed on the proposed charter are quite relevant. I'm just = not >>> entirely clear on the "routing component": are you referring to: >>> * A requirement document for Routing in the home? >>=20 >> At least a section within a home architecture document. >>=20 >>> * A recommendation for a specific routing protocol ? >=20 > [JW] I see a guidelines/analysis for link-state vs. distance-vector > routing protocols in a multi-segment home network as being useful. In my opinion, operation without active admin intervention is more = important than the particular technology. =20 >>> * A framework before the specification of a new routing protocol ? >=20 > [JW] A framework or justification statement for a new lightweight = routing > protocol would be useful as well. A source/dest aware protocol has = been > proposed as a possible solution for the multi-homed home network for > example. >> The charter says: >>=20 >> "For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default." Source/dest aware protocol sounds more like a research project. = Developing requirements might be in scope for homenet. - Ralph >>=20 >> - Mark >>=20 >>=20 >>> I'm clearly not expressing an opinion, just a question. >>> Thanks. >>> JP. >>>=20 >>> JP Vasseur >>> Cisco Fellow >>>=20 >>> Sent from Blackberry >>>=20 >>> ----- Original Message ----- >>> From: Mark Townsley [mailto:mark@townsley.net] >>> Sent: Thursday, June 30, 2011 11:36 AM >>> To: Weil, Jason >>> Cc: fun@ietf.org ; homegate@ietf.org = >>> Subject: Re: [fun] status of the homenet effort >>>=20 >>>=20 >>> Thank you for the feedback, keep it coming. >>>=20 >>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: >>>=20 >>>> Mark, Raplh, Jari, et all, >>>>=20 >>>> I really appreciate the change in charter and direction for this >>>> proposed >>>> WG and the interest to keep it going. I believe it sets a path that = is >>>> scoped narrow enough to provide a workplace for achievable results. >>>>=20 >>>> As a provider working on writing, testing and implementing IPv6 = CPE, I >>>> can >>>> relate firsthand that getting basic IPv6 functionality working in = the >>>> home >>>> network is no simple feat and is still a work in progress. Don't = get me >>>> wrong, basic functionality is there just not baked. What seems very >>>> straightforward in theory typically fails in a multitude of corner >>>> cases >>>> ie reality. And just to clarify I am referring to a single /64 = subnet >>>> topology with no routing. >>>>=20 >>>> If we can stay focussed on solving just the basics for the five = areas >>>> included, I believe it will be helpful. The other recommendation = would >>>> be >>>> to work as expeditiously as possible. Providers in the process of >>>> deploying IPv6 now are already deep into this analysis and = development >>>> with their vendors. If we wait too long then these topics will be >>>> solved >>>> with interoperability a possible casualty. >>>>=20 >>>> FWIW, I would also add that the five topics in the charter are also >>>> listed >>>> in order >>>> Of priority at least for me. >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Jason >>>>=20 >>>>=20 >>>> On 6/29/11 5:46 AM, "Mark Townsley" wrote: >>>>=20 >>>>>=20 >>>>> All, >>>>>=20 >>>>> Apologies for double-posting if there are folks that are = subscribed to >>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone = will >>>>> finally create homenet@ietf.org and consolidate the membership >>>>> accordingly. >>>>>=20 >>>>> In the charter proposal below, I think you will see a lot of >>>>> similarity >>>>> with the consensus we achieved on the homegate list last year. = Jari >>>>> has >>>>> taken that, feedback from the IESG, IAB, members of the >>>>> IP-Directorate, >>>>> v6ops chairs, etc. and shaped it towards something more focused on = the >>>>> Internet (and Routing) area, as well as IPv6. I believe he and = Ralph >>>>> both >>>>> have a great deal of confidence that this is something that is = very >>>>> important to the industry, and that the IETF has a critical role = to >>>>> play. >>>>>=20 >>>>> So, make no mistake, whether we end up as a WG or a BoF between = now >>>>> and >>>>> Quebec, "we're back" - please send comments, and make your travel = or >>>>> remote-attendance plans accordingly if you want to participate. >>>>>=20 >>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd >>>>> like to >>>>> take requests for presentation time now. Jari and I will likely = begin >>>>> the >>>>> session with a scoping overview, as well as a first cut at an >>>>> architecture framework, but there should be some time for a few = other >>>>> items. When submitting your request, please identify which of the = 5 >>>>> areas >>>>> below you think your work applies to as well as the = internet-draft, of >>>>> course. >>>>>=20 >>>>> Thanks, and see you on the list and in Quebec. >>>>>=20 >>>>> - Mark >>>>>=20 >>>>>=20 >>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>>>>=20 >>>>>> I wanted to provide an update of the situation with this working >>>>>> group >>>>>> proposal. >>>>>>=20 >>>>>> HOMENET is a new working group proposal, a variation of the >>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time >>>>>> looking at it from a different angle. The old effort was mostly >>>>>> focused >>>>>> about what home gateways should do: forwarding, transport, and = DNS >>>>>> proxying issues. The new effort is about home networks = themselves, in >>>>>> particular what kind of network architecture and configuration is >>>>>> necessary to support IPv6-based home networks. We view IPv4-based >>>>>> home >>>>>> networks as "done" at this time (or perhaps as "cannot be changed >>>>>> anyway"). >>>>>>=20 >>>>>> I have been discussing this effort in the background for the last >>>>>> couple of month with Mark Townsley and others, and more publicly >>>>>> since >>>>>> early June. The proposal has been brought to the IESG, IAB and = some >>>>>> directorates for discussion, and we've been going back and forth >>>>>> whether >>>>>> this is ready to become a working group or needs to be run as a = BOF >>>>>> in >>>>>> Quebec City. The current plan is that the working group proposal >>>>>> goes to >>>>>> IETF-wide review this week, and if the feedback from the = community, >>>>>> IAB, >>>>>> and the IESG is positive, we will create the working group just = in >>>>>> time >>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the >>>>>> meeting >>>>>> will be used to run the proposal as a BOF. >>>>>>=20 >>>>>> In any case, I would like to solicit discussion on this topic, = and >>>>>> perhaps some early drafts as well. Please comment on the charter = at >>>>>> least. >>>>>>=20 >>>>>> Note that the new proposal was called FUN at the time that we = created >>>>>> the list. It has now been renamed back to HOMENET to be more >>>>>> descriptive. The list will be renamed soon as well (current >>>>>> subscribers >>>>>> will stay). >>>>>>=20 >>>>>> This is the most recent version of the charter we should discuss: >>>>>>=20 >>>>>> Home Networks (homenet) >>>>>> ----------------------------------- >>>>>>=20 >>>>>> Current Status: Proposed >>>>>> Last Edit: Wednesday, June 29th, 2011 >>>>>>=20 >>>>>> Chairs: >>>>>> TBD >>>>>>=20 >>>>>> Internet Area Directors: >>>>>> Ralph Droms >>>>>> Jari Arkko >>>>>>=20 >>>>>> Internet Area Advisor: >>>>>> Jari Arkko >>>>>>=20 >>>>>> Routing Area Technical Advisor: >>>>>> TBD >>>>>>=20 >>>>>> Security Area Technical Advisor: >>>>>> TBD >>>>>>=20 >>>>>> Mailing Lists: >>>>>> General Discussion: fun@ietf.org >>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>>>>> Archive: http://www.ietf.org/mail-archive/web/fun >>>>>>=20 >>>>>> Description of Working Group: >>>>>>=20 >>>>>> This working group focuses on the evolving networking technology >>>>>> within and among relatively small =B3residential home=B2 = networks. For >>>>>> example, an obvious trend in home networking is the proliferation = of >>>>>> networking technology in an increasingly broad range and number = of >>>>>> devices. This evolution in scale and diversity sets some = requirements >>>>>> on IETF protocols. Some of the relevant trends include: >>>>>>=20 >>>>>> o Multiple segments: While less complex L3-toplogies involving as = few >>>>>> subnets as possible are preferred in home networks for a variety = of >>>>>> reasons including simpler management and service discovery, the >>>>>> introduction of more than one subnet into a home network is = enough >>>>>> to add complexity that needs to be addressed, and multiple >>>>>> dedicated segments are necessary for some cases. For instance, a >>>>>> common feature in modern home routers in the ability to support >>>>>> both guest and private network segments. Also, link layer >>>>>> networking technology is poised to become more heterogeneous, as >>>>>> networks begin to employ both traditional Ethernet technology and >>>>>> link layers designed for low-powered sensor networks. Finally, >>>>>> similar needs for segmentation may occur in other cases, such as >>>>>> separating building control or corporate extensions from the >>>>>> Internet access network. Different segments may be associated = with >>>>>> subnets that have different routing and security policies. >>>>>>=20 >>>>>> o Service providers are deploying IPv6, and support for IPv6 is >>>>>> increasingly available in home gateway devices. While IPv6 = resembles >>>>>> IPv4 in many ways, it changes address allocation principles and >>>>>> allows >>>>>> direct IP addressability and routing to devices in the home from = the >>>>>> Internet. This is a promising area in IPv6 that has proved >>>>>> challenging >>>>>> in IPv4 with the proliferation of NAT. >>>>>>=20 >>>>>> o End-to-end communication is both an opportunity and a concern = as it >>>>>> enables new applications but also exposes nodes in the internal >>>>>> networks to receipt of unwanted traffic from the Internet. = Firewalls >>>>>> that restrict incoming connections may be used to prevent = exposure, >>>>>> however, this reduces the efficacy of end-to-end connectivity = that >>>>>> IPv6 has the potential to restore. >>>>>>=20 >>>>>> Home networks need to provide the tools to handle these = situations in >>>>>> a manner accessible to all users of home networks. Manual >>>>>> configuration is rarely, if at all, possible. The purpose of this >>>>>> working group is to focus on this evolution, in particular as it >>>>>> addresses the introduction of IPv6, by developing an architecture >>>>>> addressing this full scope of requirements: >>>>>>=20 >>>>>> o prefix configuration for routers >>>>>> o managing routing >>>>>> o name resolution >>>>>> o service discovery >>>>>> o network security >>>>>>=20 >>>>>> The task of the group is to produce an architecture document that >>>>>> outlines how to construct home networks involving multiple = routers >>>>>> and >>>>>> subnets. This document is expected to apply the IPv6 addressing >>>>>> architecture, prefix delegation, global and ULA addresses, source >>>>>> address selection rules and other existing components of the IPv6 >>>>>> architecture. The architecture document should drive what = protocols >>>>>> changes, if any, are necessary. Specific protocol work described >>>>>> below >>>>>> is expected to be within the scope of the working group one the >>>>>> architecture work is complete. However, the group is required to >>>>>> review its charter and milestones with the IESG and IETF = community >>>>>> before submitting documents that make protocol changes. It is >>>>>> expected >>>>>> that the group has to discuss some of the below solutions, = however, >>>>>> in >>>>>> order to complete the architecture work. >>>>>>=20 >>>>>> The group will apply existing protocols to handle the five >>>>>> requirements above. For prefix configuration, existing protocols = are >>>>>> likely sufficient, and at worst may need some small enhancements, >>>>>> such >>>>>> as new options. For automatic routing, it is expected that = existing >>>>>> routing protocols can be used as is, however, a new mechanism may = be >>>>>> needed in order to turn a selected protocol on by default. For = name >>>>>> resolution and service discovery, extensions to existing >>>>>> multicast-based name resolution protocols are needed to enable = them >>>>>> to >>>>>> work across subnets. >>>>>>=20 >>>>>> For network security, the group shall document the concept of >>>>>> "advanced security" as a further development of "simple security" >>>>>> from >>>>>> RFC 6092. The main goal of this work is to enable a security = policy >>>>>> that adapts to IPv6 threats as they emerge, taking into account = not >>>>>> only traffic from the Internet at large, but within and leaving = the >>>>>> home network itself. >>>>>>=20 >>>>>> It is expected that the working group will define a set of = protocol >>>>>> specifications to accomplish the five requirements from >>>>>> above. However, it is not in the scope of the working group to = define >>>>>> entirely new routing protocols or address allocation protocols. = As >>>>>> noted, additional options or other small extensions may be = necessary >>>>>> to use the existing protocols in these new configuration tasks. = The >>>>>> working group shall also not make any changes to IPv6 protocols = or >>>>>> addressing architecture. Prefix configuration, routing, and = security >>>>>> related work shall not cause any changes that are not backwards >>>>>> compatible to existing IPv6 hosts. There may be host visible = changes >>>>>> in the work on naming and discovery protocols, however. In its >>>>>> design, >>>>>> the working group shall also consider security aspects and the = impact >>>>>> on manageability. The main focus of the working group is home >>>>>> networks, but the group's results may also find applications in = other >>>>>> small networks. >>>>>>=20 >>>>>> The working group will liaise with the relevant IETF working >>>>>> groups. In particular, the group should work closely with the = V6OPS >>>>>> working group, review any use or extension of DHCP with the DHC >>>>>> working group, and work with additional DNS requirements with the >>>>>> DNSEXT and DNSOP working groups. If it turns out that additional >>>>>> options are needed for a routing protocol, they will be developed = in >>>>>> the appropriate Routing Area working group, with the HOMENET = working >>>>>> group providing the architecture and requirements for such >>>>>> enhancements. The working group will also liase with external >>>>>> standards bodies where it is expected that there are normative >>>>>> dependencies between the specifications of the two bodies. >>>>>> It is expected that in the architecture definition stage liaising >>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>>>>=20 >>>>>> Milestones: >>>>>>=20 >>>>>> Jul 2011 Formation of the working group >>>>>> Sep 2011 First WG draft on the architecture >>>>>> Dec 2011 Submission of the architecture draft to the IESG as >>>>>> Informational RFC >>>>>> Dec 2011 Charter re-evaluation based on the architecture work >>>>>> Dec 2011 First WG draft on prefix configuration >>>>>> Dec 2011 First WG draft on routing >>>>>> Jan 2012 First WG draft on name resolution >>>>>> Feb 2012 First WG draft on service discovery >>>>>> Feb 2012 First WG draft on perimeter security >>>>>> Feb 2012 Start of routing related work in the relevant routing = area >>>>>> working group, if needed >>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG = as >>>>>> Standards Track RFC >>>>>> Apr 2012 Submission of the routing draft to the IESG as = Informational >>>>>> RFC >>>>>> Sep 2012 Submission of the name resolution draft to the IESG as >>>>>> Standards Track RFC >>>>>> Nov 2012 Submission of the service discovery draft to the IESG as >>>>>> Standards Track RFC >>>>>> Dec 2012 Submission of the perimeter security draft to the IESG = as >>>>>> Informational RFC >>>>>>=20 >>>>>> _______________________________________________ >>>>>> fun mailing list >>>>>> fun@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fun >>>>>=20 >>>>> _______________________________________________ >>>>> fun mailing list >>>>> fun@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fun >>>>=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. >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >>=20 >=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. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From jason.weil@twcable.com Fri Jul 1 08:06:53 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0E9E8009; Fri, 1 Jul 2011 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxYdDXNZ3654; Fri, 1 Jul 2011 08:06:51 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8019E8005; Fri, 1 Jul 2011 08:06:51 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,458,1304308800"; d="scan'208";a="230905511" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2011 11:06:04 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 1 Jul 2011 11:06:50 -0400 From: "Weil, Jason" To: "JP Vasseur (jvasseur)" , "Ralph Droms (rdroms)" Date: Fri, 1 Jul 2011 11:06:49 -0400 Thread-Topic: [homegate] [fun] status of the homenet effort Thread-Index: Acw3/HFBeThPmlw3Txed3gx0hkraNQAA1FLPAAAGRSA= Message-ID: <34E4F50CAFA10349A41E0756550084FB0A909F58@PRVPEXVS04.corp.twcable.com> References: <9F9A2F4E-54D4-47EB-B57D-041BB56F9523@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [fun] [homegate] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:06:53 -0000 Agreed. My thought was Homenet builds consensus on what work is needed and = possibly sets the requirements. The development work should occur in whatev= er group is responsible for that technology. Jason -----Original Message----- From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] Sent: Friday, July 01, 2011 11:02 AM To: Ralph Droms (rdroms); Weil, Jason Cc: mark@townsley.net; fun@ietf.org; homegate@ietf.org Subject: Re: [homegate] [fun] status of the homenet effort Agreeing with Ralph. JP Vasseur Cisco Fellow Sent from Blackberry ----- Original Message ----- From: Ralph Droms (rdroms) Sent: Friday, July 01, 2011 09:37 AM To: Weil, Jason Cc: Mark Townsley ; JP Vasseur (jvasseur); fun@ietf.org = ; homegate@ietf.org Subject: Re: [homegate] [fun] status of the homenet effort On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote: > > > On 7/1/11 4:06 AM, "Mark Townsley" wrote: > >> >> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote: >> >>> I also think that this deals with an important topic and the list of >>> items listed on the proposed charter are quite relevant. I'm just not >>> entirely clear on the "routing component": are you referring to: >>> * A requirement document for Routing in the home? >> >> At least a section within a home architecture document. >> >>> * A recommendation for a specific routing protocol ? > > [JW] I see a guidelines/analysis for link-state vs. distance-vector > routing protocols in a multi-segment home network as being useful. In my opinion, operation without active admin intervention is more importan= t than the particular technology. >>> * A framework before the specification of a new routing protocol ? > > [JW] A framework or justification statement for a new lightweight routing > protocol would be useful as well. A source/dest aware protocol has been > proposed as a possible solution for the multi-homed home network for > example. >> The charter says: >> >> "For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default." Source/dest aware protocol sounds more like a research project. Developing= requirements might be in scope for homenet. - Ralph >> >> - Mark >> >> >>> I'm clearly not expressing an opinion, just a question. >>> Thanks. >>> JP. >>> >>> JP Vasseur >>> Cisco Fellow >>> >>> Sent from Blackberry >>> >>> ----- Original Message ----- >>> From: Mark Townsley [mailto:mark@townsley.net] >>> Sent: Thursday, June 30, 2011 11:36 AM >>> To: Weil, Jason >>> Cc: fun@ietf.org ; homegate@ietf.org >>> Subject: Re: [fun] status of the homenet effort >>> >>> >>> Thank you for the feedback, keep it coming. >>> >>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: >>> >>>> Mark, Raplh, Jari, et all, >>>> >>>> I really appreciate the change in charter and direction for this >>>> proposed >>>> WG and the interest to keep it going. I believe it sets a path that is >>>> scoped narrow enough to provide a workplace for achievable results. >>>> >>>> As a provider working on writing, testing and implementing IPv6 CPE, I >>>> can >>>> relate firsthand that getting basic IPv6 functionality working in the >>>> home >>>> network is no simple feat and is still a work in progress. Don't get m= e >>>> wrong, basic functionality is there just not baked. What seems very >>>> straightforward in theory typically fails in a multitude of corner >>>> cases >>>> ie reality. And just to clarify I am referring to a single /64 subnet >>>> topology with no routing. >>>> >>>> If we can stay focussed on solving just the basics for the five areas >>>> included, I believe it will be helpful. The other recommendation would >>>> be >>>> to work as expeditiously as possible. Providers in the process of >>>> deploying IPv6 now are already deep into this analysis and development >>>> with their vendors. If we wait too long then these topics will be >>>> solved >>>> with interoperability a possible casualty. >>>> >>>> FWIW, I would also add that the five topics in the charter are also >>>> listed >>>> in order >>>> Of priority at least for me. >>>> >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> >>>> On 6/29/11 5:46 AM, "Mark Townsley" wrote: >>>> >>>>> >>>>> All, >>>>> >>>>> Apologies for double-posting if there are folks that are subscribed t= o >>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will >>>>> finally create homenet@ietf.org and consolidate the membership >>>>> accordingly. >>>>> >>>>> In the charter proposal below, I think you will see a lot of >>>>> similarity >>>>> with the consensus we achieved on the homegate list last year. Jari >>>>> has >>>>> taken that, feedback from the IESG, IAB, members of the >>>>> IP-Directorate, >>>>> v6ops chairs, etc. and shaped it towards something more focused on th= e >>>>> Internet (and Routing) area, as well as IPv6. I believe he and Ralph >>>>> both >>>>> have a great deal of confidence that this is something that is very >>>>> important to the industry, and that the IETF has a critical role to >>>>> play. >>>>> >>>>> So, make no mistake, whether we end up as a WG or a BoF between now >>>>> and >>>>> Quebec, "we're back" - please send comments, and make your travel or >>>>> remote-attendance plans accordingly if you want to participate. >>>>> >>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd >>>>> like to >>>>> take requests for presentation time now. Jari and I will likely begin >>>>> the >>>>> session with a scoping overview, as well as a first cut at an >>>>> architecture framework, but there should be some time for a few other >>>>> items. When submitting your request, please identify which of the 5 >>>>> areas >>>>> below you think your work applies to as well as the internet-draft, o= f >>>>> course. >>>>> >>>>> Thanks, and see you on the list and in Quebec. >>>>> >>>>> - Mark >>>>> >>>>> >>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>>>> >>>>>> I wanted to provide an update of the situation with this working >>>>>> group >>>>>> proposal. >>>>>> >>>>>> HOMENET is a new working group proposal, a variation of the >>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time >>>>>> looking at it from a different angle. The old effort was mostly >>>>>> focused >>>>>> about what home gateways should do: forwarding, transport, and DNS >>>>>> proxying issues. The new effort is about home networks themselves, i= n >>>>>> particular what kind of network architecture and configuration is >>>>>> necessary to support IPv6-based home networks. We view IPv4-based >>>>>> home >>>>>> networks as "done" at this time (or perhaps as "cannot be changed >>>>>> anyway"). >>>>>> >>>>>> I have been discussing this effort in the background for the last >>>>>> couple of month with Mark Townsley and others, and more publicly >>>>>> since >>>>>> early June. The proposal has been brought to the IESG, IAB and some >>>>>> directorates for discussion, and we've been going back and forth >>>>>> whether >>>>>> this is ready to become a working group or needs to be run as a BOF >>>>>> in >>>>>> Quebec City. The current plan is that the working group proposal >>>>>> goes to >>>>>> IETF-wide review this week, and if the feedback from the community, >>>>>> IAB, >>>>>> and the IESG is positive, we will create the working group just in >>>>>> time >>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the >>>>>> meeting >>>>>> will be used to run the proposal as a BOF. >>>>>> >>>>>> In any case, I would like to solicit discussion on this topic, and >>>>>> perhaps some early drafts as well. Please comment on the charter at >>>>>> least. >>>>>> >>>>>> Note that the new proposal was called FUN at the time that we create= d >>>>>> the list. It has now been renamed back to HOMENET to be more >>>>>> descriptive. The list will be renamed soon as well (current >>>>>> subscribers >>>>>> will stay). >>>>>> >>>>>> This is the most recent version of the charter we should discuss: >>>>>> >>>>>> Home Networks (homenet) >>>>>> ----------------------------------- >>>>>> >>>>>> Current Status: Proposed >>>>>> Last Edit: Wednesday, June 29th, 2011 >>>>>> >>>>>> Chairs: >>>>>> TBD >>>>>> >>>>>> Internet Area Directors: >>>>>> Ralph Droms >>>>>> Jari Arkko >>>>>> >>>>>> Internet Area Advisor: >>>>>> Jari Arkko >>>>>> >>>>>> Routing Area Technical Advisor: >>>>>> TBD >>>>>> >>>>>> Security Area Technical Advisor: >>>>>> TBD >>>>>> >>>>>> Mailing Lists: >>>>>> General Discussion: fun@ietf.org >>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>>>>> Archive: http://www.ietf.org/mail-archive/web/fun >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> This working group focuses on the evolving networking technology >>>>>> within and among relatively small =B3residential home=B2 networks. F= or >>>>>> example, an obvious trend in home networking is the proliferation of >>>>>> networking technology in an increasingly broad range and number of >>>>>> devices. This evolution in scale and diversity sets some requirement= s >>>>>> on IETF protocols. Some of the relevant trends include: >>>>>> >>>>>> o Multiple segments: While less complex L3-toplogies involving as fe= w >>>>>> subnets as possible are preferred in home networks for a variety of >>>>>> reasons including simpler management and service discovery, the >>>>>> introduction of more than one subnet into a home network is enough >>>>>> to add complexity that needs to be addressed, and multiple >>>>>> dedicated segments are necessary for some cases. For instance, a >>>>>> common feature in modern home routers in the ability to support >>>>>> both guest and private network segments. Also, link layer >>>>>> networking technology is poised to become more heterogeneous, as >>>>>> networks begin to employ both traditional Ethernet technology and >>>>>> link layers designed for low-powered sensor networks. Finally, >>>>>> similar needs for segmentation may occur in other cases, such as >>>>>> separating building control or corporate extensions from the >>>>>> Internet access network. Different segments may be associated with >>>>>> subnets that have different routing and security policies. >>>>>> >>>>>> o Service providers are deploying IPv6, and support for IPv6 is >>>>>> increasingly available in home gateway devices. While IPv6 resembles >>>>>> IPv4 in many ways, it changes address allocation principles and >>>>>> allows >>>>>> direct IP addressability and routing to devices in the home from the >>>>>> Internet. This is a promising area in IPv6 that has proved >>>>>> challenging >>>>>> in IPv4 with the proliferation of NAT. >>>>>> >>>>>> o End-to-end communication is both an opportunity and a concern as i= t >>>>>> enables new applications but also exposes nodes in the internal >>>>>> networks to receipt of unwanted traffic from the Internet. Firewalls >>>>>> that restrict incoming connections may be used to prevent exposure, >>>>>> however, this reduces the efficacy of end-to-end connectivity that >>>>>> IPv6 has the potential to restore. >>>>>> >>>>>> Home networks need to provide the tools to handle these situations i= n >>>>>> a manner accessible to all users of home networks. Manual >>>>>> configuration is rarely, if at all, possible. The purpose of this >>>>>> working group is to focus on this evolution, in particular as it >>>>>> addresses the introduction of IPv6, by developing an architecture >>>>>> addressing this full scope of requirements: >>>>>> >>>>>> o prefix configuration for routers >>>>>> o managing routing >>>>>> o name resolution >>>>>> o service discovery >>>>>> o network security >>>>>> >>>>>> The task of the group is to produce an architecture document that >>>>>> outlines how to construct home networks involving multiple routers >>>>>> and >>>>>> subnets. This document is expected to apply the IPv6 addressing >>>>>> architecture, prefix delegation, global and ULA addresses, source >>>>>> address selection rules and other existing components of the IPv6 >>>>>> architecture. The architecture document should drive what protocols >>>>>> changes, if any, are necessary. Specific protocol work described >>>>>> below >>>>>> is expected to be within the scope of the working group one the >>>>>> architecture work is complete. However, the group is required to >>>>>> review its charter and milestones with the IESG and IETF community >>>>>> before submitting documents that make protocol changes. It is >>>>>> expected >>>>>> that the group has to discuss some of the below solutions, however, >>>>>> in >>>>>> order to complete the architecture work. >>>>>> >>>>>> The group will apply existing protocols to handle the five >>>>>> requirements above. For prefix configuration, existing protocols are >>>>>> likely sufficient, and at worst may need some small enhancements, >>>>>> such >>>>>> as new options. For automatic routing, it is expected that existing >>>>>> routing protocols can be used as is, however, a new mechanism may be >>>>>> needed in order to turn a selected protocol on by default. For name >>>>>> resolution and service discovery, extensions to existing >>>>>> multicast-based name resolution protocols are needed to enable them >>>>>> to >>>>>> work across subnets. >>>>>> >>>>>> For network security, the group shall document the concept of >>>>>> "advanced security" as a further development of "simple security" >>>>>> from >>>>>> RFC 6092. The main goal of this work is to enable a security policy >>>>>> that adapts to IPv6 threats as they emerge, taking into account not >>>>>> only traffic from the Internet at large, but within and leaving the >>>>>> home network itself. >>>>>> >>>>>> It is expected that the working group will define a set of protocol >>>>>> specifications to accomplish the five requirements from >>>>>> above. However, it is not in the scope of the working group to defin= e >>>>>> entirely new routing protocols or address allocation protocols. As >>>>>> noted, additional options or other small extensions may be necessary >>>>>> to use the existing protocols in these new configuration tasks. The >>>>>> working group shall also not make any changes to IPv6 protocols or >>>>>> addressing architecture. Prefix configuration, routing, and security >>>>>> related work shall not cause any changes that are not backwards >>>>>> compatible to existing IPv6 hosts. There may be host visible changes >>>>>> in the work on naming and discovery protocols, however. In its >>>>>> design, >>>>>> the working group shall also consider security aspects and the impac= t >>>>>> on manageability. The main focus of the working group is home >>>>>> networks, but the group's results may also find applications in othe= r >>>>>> small networks. >>>>>> >>>>>> The working group will liaise with the relevant IETF working >>>>>> groups. In particular, the group should work closely with the V6OPS >>>>>> working group, review any use or extension of DHCP with the DHC >>>>>> working group, and work with additional DNS requirements with the >>>>>> DNSEXT and DNSOP working groups. If it turns out that additional >>>>>> options are needed for a routing protocol, they will be developed in >>>>>> the appropriate Routing Area working group, with the HOMENET working >>>>>> group providing the architecture and requirements for such >>>>>> enhancements. The working group will also liase with external >>>>>> standards bodies where it is expected that there are normative >>>>>> dependencies between the specifications of the two bodies. >>>>>> It is expected that in the architecture definition stage liaising >>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>>>> >>>>>> Milestones: >>>>>> >>>>>> Jul 2011 Formation of the working group >>>>>> Sep 2011 First WG draft on the architecture >>>>>> Dec 2011 Submission of the architecture draft to the IESG as >>>>>> Informational RFC >>>>>> Dec 2011 Charter re-evaluation based on the architecture work >>>>>> Dec 2011 First WG draft on prefix configuration >>>>>> Dec 2011 First WG draft on routing >>>>>> Jan 2012 First WG draft on name resolution >>>>>> Feb 2012 First WG draft on service discovery >>>>>> Feb 2012 First WG draft on perimeter security >>>>>> Feb 2012 Start of routing related work in the relevant routing area >>>>>> working group, if needed >>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG as >>>>>> Standards Track RFC >>>>>> Apr 2012 Submission of the routing draft to the IESG as Informationa= l >>>>>> RFC >>>>>> Sep 2012 Submission of the name resolution draft to the IESG as >>>>>> Standards Track RFC >>>>>> Nov 2012 Submission of the service discovery draft to the IESG as >>>>>> Standards Track RFC >>>>>> Dec 2012 Submission of the perimeter security draft to the IESG as >>>>>> Informational RFC >>>>>> >>>>>> _______________________________________________ >>>>>> fun mailing list >>>>>> fun@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fun >>>>> >>>>> _______________________________________________ >>>>> fun mailing list >>>>> fun@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fun >>>> >>>> >>>> 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 receive= d >>>> 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. >>> >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >> > > > 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. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From mark@townsley.net Fri Jul 1 08:47:51 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D7611E80F5; Fri, 1 Jul 2011 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOuA+juzLNIw; Fri, 1 Jul 2011 08:47:49 -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 BAD7311E8121; Fri, 1 Jul 2011 08:47:44 -0700 (PDT) Received: by wyj26 with SMTP id 26so2645793wyj.31 for ; Fri, 01 Jul 2011 08:47:44 -0700 (PDT) Received: by 10.227.196.209 with SMTP id eh17mr3096185wbb.92.1309535263768; Fri, 01 Jul 2011 08:47:43 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fe4sm2438492wbb.45.2011.07.01.08.47.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:47:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0A909F58@PRVPEXVS04.corp.twcable.com> Date: Fri, 1 Jul 2011 17:47:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F9A2F4E-54D4-47EB-B57D-041BB56F9523@cisco.com> <34E4F50CAFA10349A41E0756550084FB0A909F58@PRVPEXVS04.corp.twcable.com> To: "Weil, Jason" X-Mailer: Apple Mail (2.1084) Cc: "fun@ietf.org" , "homegate@ietf.org" , "JP Vasseur \(jvasseur\)" Subject: Re: [fun] [homegate] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:47:51 -0000 On Jul 1, 2011, at 5:06 PM, Weil, Jason wrote: > Agreed. My thought was Homenet builds consensus on what work is needed = and possibly sets the requirements. The development work should occur in = whatever group is responsible for that technology. I think homenet could set defaults (not far removed from requirements, = and something that is imperative in a home network and less so in = others). Also, depending on the protocol involved, there may or may not = be a WG setup to do the work - for example, DHCP's modus operandi is = that simple DHCP options are defined not in the DHC WG itself, but in = the "parent technology" WG with review from DHC.=20 In any case, I think this is why Jari included a review stage of the = work to be done after we get through the architecture/framework... We'll = know better then what work can be knocked out under a homenet banner, = and what needs to be forked elsewhere.=20 - Mark >=20 > Jason >=20 > -----Original Message----- > From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] > Sent: Friday, July 01, 2011 11:02 AM > To: Ralph Droms (rdroms); Weil, Jason > Cc: mark@townsley.net; fun@ietf.org; homegate@ietf.org > Subject: Re: [homegate] [fun] status of the homenet effort >=20 > Agreeing with Ralph. >=20 > JP Vasseur > Cisco Fellow >=20 > Sent from Blackberry >=20 > ----- Original Message ----- > From: Ralph Droms (rdroms) > Sent: Friday, July 01, 2011 09:37 AM > To: Weil, Jason > Cc: Mark Townsley ; JP Vasseur (jvasseur); = fun@ietf.org ; homegate@ietf.org > Subject: Re: [homegate] [fun] status of the homenet effort >=20 >=20 > On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote: >=20 >>=20 >>=20 >> On 7/1/11 4:06 AM, "Mark Townsley" wrote: >>=20 >>>=20 >>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote: >>>=20 >>>> I also think that this deals with an important topic and the list = of >>>> items listed on the proposed charter are quite relevant. I'm just = not >>>> entirely clear on the "routing component": are you referring to: >>>> * A requirement document for Routing in the home? >>>=20 >>> At least a section within a home architecture document. >>>=20 >>>> * A recommendation for a specific routing protocol ? >>=20 >> [JW] I see a guidelines/analysis for link-state vs. distance-vector >> routing protocols in a multi-segment home network as being useful. >=20 > In my opinion, operation without active admin intervention is more = important than the particular technology. >=20 >>>> * A framework before the specification of a new routing protocol ? >>=20 >> [JW] A framework or justification statement for a new lightweight = routing >> protocol would be useful as well. A source/dest aware protocol has = been >> proposed as a possible solution for the multi-homed home network for >> example. >=20 >>> The charter says: >>>=20 >>> "For automatic routing, it is expected that existing >>> routing protocols can be used as is, however, a new mechanism may be >>> needed in order to turn a selected protocol on by default." >=20 > Source/dest aware protocol sounds more like a research project. = Developing requirements might be in scope for homenet. >=20 > - Ralph >=20 >>>=20 >>> - Mark >>>=20 >>>=20 >>>> I'm clearly not expressing an opinion, just a question. >>>> Thanks. >>>> JP. >>>>=20 >>>> JP Vasseur >>>> Cisco Fellow >>>>=20 >>>> Sent from Blackberry >>>>=20 >>>> ----- Original Message ----- >>>> From: Mark Townsley [mailto:mark@townsley.net] >>>> Sent: Thursday, June 30, 2011 11:36 AM >>>> To: Weil, Jason >>>> Cc: fun@ietf.org ; homegate@ietf.org = >>>> Subject: Re: [fun] status of the homenet effort >>>>=20 >>>>=20 >>>> Thank you for the feedback, keep it coming. >>>>=20 >>>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: >>>>=20 >>>>> Mark, Raplh, Jari, et all, >>>>>=20 >>>>> I really appreciate the change in charter and direction for this >>>>> proposed >>>>> WG and the interest to keep it going. I believe it sets a path = that is >>>>> scoped narrow enough to provide a workplace for achievable = results. >>>>>=20 >>>>> As a provider working on writing, testing and implementing IPv6 = CPE, I >>>>> can >>>>> relate firsthand that getting basic IPv6 functionality working in = the >>>>> home >>>>> network is no simple feat and is still a work in progress. Don't = get me >>>>> wrong, basic functionality is there just not baked. What seems = very >>>>> straightforward in theory typically fails in a multitude of corner >>>>> cases >>>>> ie reality. And just to clarify I am referring to a single /64 = subnet >>>>> topology with no routing. >>>>>=20 >>>>> If we can stay focussed on solving just the basics for the five = areas >>>>> included, I believe it will be helpful. The other recommendation = would >>>>> be >>>>> to work as expeditiously as possible. Providers in the process of >>>>> deploying IPv6 now are already deep into this analysis and = development >>>>> with their vendors. If we wait too long then these topics will be >>>>> solved >>>>> with interoperability a possible casualty. >>>>>=20 >>>>> FWIW, I would also add that the five topics in the charter are = also >>>>> listed >>>>> in order >>>>> Of priority at least for me. >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Jason >>>>>=20 >>>>>=20 >>>>> On 6/29/11 5:46 AM, "Mark Townsley" wrote: >>>>>=20 >>>>>>=20 >>>>>> All, >>>>>>=20 >>>>>> Apologies for double-posting if there are folks that are = subscribed to >>>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone = will >>>>>> finally create homenet@ietf.org and consolidate the membership >>>>>> accordingly. >>>>>>=20 >>>>>> In the charter proposal below, I think you will see a lot of >>>>>> similarity >>>>>> with the consensus we achieved on the homegate list last year. = Jari >>>>>> has >>>>>> taken that, feedback from the IESG, IAB, members of the >>>>>> IP-Directorate, >>>>>> v6ops chairs, etc. and shaped it towards something more focused = on the >>>>>> Internet (and Routing) area, as well as IPv6. I believe he and = Ralph >>>>>> both >>>>>> have a great deal of confidence that this is something that is = very >>>>>> important to the industry, and that the IETF has a critical role = to >>>>>> play. >>>>>>=20 >>>>>> So, make no mistake, whether we end up as a WG or a BoF between = now >>>>>> and >>>>>> Quebec, "we're back" - please send comments, and make your travel = or >>>>>> remote-attendance plans accordingly if you want to participate. >>>>>>=20 >>>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd >>>>>> like to >>>>>> take requests for presentation time now. Jari and I will likely = begin >>>>>> the >>>>>> session with a scoping overview, as well as a first cut at an >>>>>> architecture framework, but there should be some time for a few = other >>>>>> items. When submitting your request, please identify which of the = 5 >>>>>> areas >>>>>> below you think your work applies to as well as the = internet-draft, of >>>>>> course. >>>>>>=20 >>>>>> Thanks, and see you on the list and in Quebec. >>>>>>=20 >>>>>> - Mark >>>>>>=20 >>>>>>=20 >>>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>>>>>=20 >>>>>>> I wanted to provide an update of the situation with this working >>>>>>> group >>>>>>> proposal. >>>>>>>=20 >>>>>>> HOMENET is a new working group proposal, a variation of the >>>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this = time >>>>>>> looking at it from a different angle. The old effort was mostly >>>>>>> focused >>>>>>> about what home gateways should do: forwarding, transport, and = DNS >>>>>>> proxying issues. The new effort is about home networks = themselves, in >>>>>>> particular what kind of network architecture and configuration = is >>>>>>> necessary to support IPv6-based home networks. We view = IPv4-based >>>>>>> home >>>>>>> networks as "done" at this time (or perhaps as "cannot be = changed >>>>>>> anyway"). >>>>>>>=20 >>>>>>> I have been discussing this effort in the background for the = last >>>>>>> couple of month with Mark Townsley and others, and more publicly >>>>>>> since >>>>>>> early June. The proposal has been brought to the IESG, IAB and = some >>>>>>> directorates for discussion, and we've been going back and forth >>>>>>> whether >>>>>>> this is ready to become a working group or needs to be run as a = BOF >>>>>>> in >>>>>>> Quebec City. The current plan is that the working group proposal >>>>>>> goes to >>>>>>> IETF-wide review this week, and if the feedback from the = community, >>>>>>> IAB, >>>>>>> and the IESG is positive, we will create the working group just = in >>>>>>> time >>>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the >>>>>>> meeting >>>>>>> will be used to run the proposal as a BOF. >>>>>>>=20 >>>>>>> In any case, I would like to solicit discussion on this topic, = and >>>>>>> perhaps some early drafts as well. Please comment on the charter = at >>>>>>> least. >>>>>>>=20 >>>>>>> Note that the new proposal was called FUN at the time that we = created >>>>>>> the list. It has now been renamed back to HOMENET to be more >>>>>>> descriptive. The list will be renamed soon as well (current >>>>>>> subscribers >>>>>>> will stay). >>>>>>>=20 >>>>>>> This is the most recent version of the charter we should = discuss: >>>>>>>=20 >>>>>>> Home Networks (homenet) >>>>>>> ----------------------------------- >>>>>>>=20 >>>>>>> Current Status: Proposed >>>>>>> Last Edit: Wednesday, June 29th, 2011 >>>>>>>=20 >>>>>>> Chairs: >>>>>>> TBD >>>>>>>=20 >>>>>>> Internet Area Directors: >>>>>>> Ralph Droms >>>>>>> Jari Arkko >>>>>>>=20 >>>>>>> Internet Area Advisor: >>>>>>> Jari Arkko >>>>>>>=20 >>>>>>> Routing Area Technical Advisor: >>>>>>> TBD >>>>>>>=20 >>>>>>> Security Area Technical Advisor: >>>>>>> TBD >>>>>>>=20 >>>>>>> Mailing Lists: >>>>>>> General Discussion: fun@ietf.org >>>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>>>>>> Archive: http://www.ietf.org/mail-archive/web/fun >>>>>>>=20 >>>>>>> Description of Working Group: >>>>>>>=20 >>>>>>> This working group focuses on the evolving networking technology >>>>>>> within and among relatively small =B3residential home=B2 = networks. For >>>>>>> example, an obvious trend in home networking is the = proliferation of >>>>>>> networking technology in an increasingly broad range and number = of >>>>>>> devices. This evolution in scale and diversity sets some = requirements >>>>>>> on IETF protocols. Some of the relevant trends include: >>>>>>>=20 >>>>>>> o Multiple segments: While less complex L3-toplogies involving = as few >>>>>>> subnets as possible are preferred in home networks for a variety = of >>>>>>> reasons including simpler management and service discovery, the >>>>>>> introduction of more than one subnet into a home network is = enough >>>>>>> to add complexity that needs to be addressed, and multiple >>>>>>> dedicated segments are necessary for some cases. For instance, a >>>>>>> common feature in modern home routers in the ability to support >>>>>>> both guest and private network segments. Also, link layer >>>>>>> networking technology is poised to become more heterogeneous, as >>>>>>> networks begin to employ both traditional Ethernet technology = and >>>>>>> link layers designed for low-powered sensor networks. Finally, >>>>>>> similar needs for segmentation may occur in other cases, such as >>>>>>> separating building control or corporate extensions from the >>>>>>> Internet access network. Different segments may be associated = with >>>>>>> subnets that have different routing and security policies. >>>>>>>=20 >>>>>>> o Service providers are deploying IPv6, and support for IPv6 is >>>>>>> increasingly available in home gateway devices. While IPv6 = resembles >>>>>>> IPv4 in many ways, it changes address allocation principles and >>>>>>> allows >>>>>>> direct IP addressability and routing to devices in the home from = the >>>>>>> Internet. This is a promising area in IPv6 that has proved >>>>>>> challenging >>>>>>> in IPv4 with the proliferation of NAT. >>>>>>>=20 >>>>>>> o End-to-end communication is both an opportunity and a concern = as it >>>>>>> enables new applications but also exposes nodes in the internal >>>>>>> networks to receipt of unwanted traffic from the Internet. = Firewalls >>>>>>> that restrict incoming connections may be used to prevent = exposure, >>>>>>> however, this reduces the efficacy of end-to-end connectivity = that >>>>>>> IPv6 has the potential to restore. >>>>>>>=20 >>>>>>> Home networks need to provide the tools to handle these = situations in >>>>>>> a manner accessible to all users of home networks. Manual >>>>>>> configuration is rarely, if at all, possible. The purpose of = this >>>>>>> working group is to focus on this evolution, in particular as it >>>>>>> addresses the introduction of IPv6, by developing an = architecture >>>>>>> addressing this full scope of requirements: >>>>>>>=20 >>>>>>> o prefix configuration for routers >>>>>>> o managing routing >>>>>>> o name resolution >>>>>>> o service discovery >>>>>>> o network security >>>>>>>=20 >>>>>>> The task of the group is to produce an architecture document = that >>>>>>> outlines how to construct home networks involving multiple = routers >>>>>>> and >>>>>>> subnets. This document is expected to apply the IPv6 addressing >>>>>>> architecture, prefix delegation, global and ULA addresses, = source >>>>>>> address selection rules and other existing components of the = IPv6 >>>>>>> architecture. The architecture document should drive what = protocols >>>>>>> changes, if any, are necessary. Specific protocol work described >>>>>>> below >>>>>>> is expected to be within the scope of the working group one the >>>>>>> architecture work is complete. However, the group is required to >>>>>>> review its charter and milestones with the IESG and IETF = community >>>>>>> before submitting documents that make protocol changes. It is >>>>>>> expected >>>>>>> that the group has to discuss some of the below solutions, = however, >>>>>>> in >>>>>>> order to complete the architecture work. >>>>>>>=20 >>>>>>> The group will apply existing protocols to handle the five >>>>>>> requirements above. For prefix configuration, existing protocols = are >>>>>>> likely sufficient, and at worst may need some small = enhancements, >>>>>>> such >>>>>>> as new options. For automatic routing, it is expected that = existing >>>>>>> routing protocols can be used as is, however, a new mechanism = may be >>>>>>> needed in order to turn a selected protocol on by default. For = name >>>>>>> resolution and service discovery, extensions to existing >>>>>>> multicast-based name resolution protocols are needed to enable = them >>>>>>> to >>>>>>> work across subnets. >>>>>>>=20 >>>>>>> For network security, the group shall document the concept of >>>>>>> "advanced security" as a further development of "simple = security" >>>>>>> from >>>>>>> RFC 6092. The main goal of this work is to enable a security = policy >>>>>>> that adapts to IPv6 threats as they emerge, taking into account = not >>>>>>> only traffic from the Internet at large, but within and leaving = the >>>>>>> home network itself. >>>>>>>=20 >>>>>>> It is expected that the working group will define a set of = protocol >>>>>>> specifications to accomplish the five requirements from >>>>>>> above. However, it is not in the scope of the working group to = define >>>>>>> entirely new routing protocols or address allocation protocols. = As >>>>>>> noted, additional options or other small extensions may be = necessary >>>>>>> to use the existing protocols in these new configuration tasks. = The >>>>>>> working group shall also not make any changes to IPv6 protocols = or >>>>>>> addressing architecture. Prefix configuration, routing, and = security >>>>>>> related work shall not cause any changes that are not backwards >>>>>>> compatible to existing IPv6 hosts. There may be host visible = changes >>>>>>> in the work on naming and discovery protocols, however. In its >>>>>>> design, >>>>>>> the working group shall also consider security aspects and the = impact >>>>>>> on manageability. The main focus of the working group is home >>>>>>> networks, but the group's results may also find applications in = other >>>>>>> small networks. >>>>>>>=20 >>>>>>> The working group will liaise with the relevant IETF working >>>>>>> groups. In particular, the group should work closely with the = V6OPS >>>>>>> working group, review any use or extension of DHCP with the DHC >>>>>>> working group, and work with additional DNS requirements with = the >>>>>>> DNSEXT and DNSOP working groups. If it turns out that additional >>>>>>> options are needed for a routing protocol, they will be = developed in >>>>>>> the appropriate Routing Area working group, with the HOMENET = working >>>>>>> group providing the architecture and requirements for such >>>>>>> enhancements. The working group will also liase with external >>>>>>> standards bodies where it is expected that there are normative >>>>>>> dependencies between the specifications of the two bodies. >>>>>>> It is expected that in the architecture definition stage = liaising >>>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>>>>>=20 >>>>>>> Milestones: >>>>>>>=20 >>>>>>> Jul 2011 Formation of the working group >>>>>>> Sep 2011 First WG draft on the architecture >>>>>>> Dec 2011 Submission of the architecture draft to the IESG as >>>>>>> Informational RFC >>>>>>> Dec 2011 Charter re-evaluation based on the architecture work >>>>>>> Dec 2011 First WG draft on prefix configuration >>>>>>> Dec 2011 First WG draft on routing >>>>>>> Jan 2012 First WG draft on name resolution >>>>>>> Feb 2012 First WG draft on service discovery >>>>>>> Feb 2012 First WG draft on perimeter security >>>>>>> Feb 2012 Start of routing related work in the relevant routing = area >>>>>>> working group, if needed >>>>>>> Mar 2012 Submission of the prefix configuration draft to the = IESG as >>>>>>> Standards Track RFC >>>>>>> Apr 2012 Submission of the routing draft to the IESG as = Informational >>>>>>> RFC >>>>>>> Sep 2012 Submission of the name resolution draft to the IESG as >>>>>>> Standards Track RFC >>>>>>> Nov 2012 Submission of the service discovery draft to the IESG = as >>>>>>> Standards Track RFC >>>>>>> Dec 2012 Submission of the perimeter security draft to the IESG = as >>>>>>> Informational RFC >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> fun mailing list >>>>>>> fun@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/fun >>>>>>=20 >>>>>> _______________________________________________ >>>>>> fun mailing list >>>>>> fun@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fun >>>>>=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. >>>>=20 >>>> _______________________________________________ >>>> fun mailing list >>>> fun@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fun >>>=20 >>=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. >> _______________________________________________ >> homegate mailing list >> homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate >=20 From jhw@apple.com Fri Jul 1 09:39:19 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5994E1F0C82; Fri, 1 Jul 2011 09:39:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDMp0ULCXemp; Fri, 1 Jul 2011 09:39:18 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id E33371F0C60; Fri, 1 Jul 2011 09:39:18 -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 <0LNN00HLAY5LQE01@mail-out.apple.com>; Fri, 01 Jul 2011 09:37:46 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-02-4e0df7c0ab2c Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 5B.19.04993.0C7FD0E4; Fri, 01 Jul 2011 09:37:20 -0700 (PDT) Received: from [172.16.1.2] (adit.conjury.org [75.101.54.88]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNN00GIUY6YQK80@cardamom.apple.com>; Fri, 01 Jul 2011 09:37:46 -0700 (PDT) From: james woodyatt In-reply-to: <-4529087406481929693@unknownmsgid> Date: Fri, 01 Jul 2011 09:37:46 -0700 Message-id: <9F80E933-D8C4-4579-960F-81230B16DD57@apple.com> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <4E0D0281.3020608@raszuk.net> <-4529087406481929693@unknownmsgid> To: Martin Focazio X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiON1OVffAd14/g5lNGhaPD8xit9h2qZ/N gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ+xbsZSo4yF1xp6uXuYFxDWcXIyeHhICJxOdDk1kh bDGJC/fWs3UxcnEICbQySXw5u4IRJMErICjxY/I9li5GDg5mAXmJg+dlQcLMAloS3x+1skDU 9zFJHFnSwgSSEBawkZjU9QbMZhNQkfh2+S6YzSlgILF8/06wmSwCqhLPWpaxQAzykrj29hc7 xC4biYfT2sEOEhL4zSyxZosQiC0CVN+x/QwjxKHyEotbPjNOYBSYheS8WQjnzUJy3gJG5lWM gkWpOYmVhoZ6iQUFOal6yfm5mxhBIdhQaLCDce1P/kOMAhyMSjy8C57y+gmxJpYVV+YeYpTg YFYS4W29DhTiTUmsrEotyo8vKs1JLT7EKM3BoiTOG5vJ7SckkJ5YkpqdmlqQWgSTZeLglGpg dChjTmJXidr7eVpe/JszN50Ma9+WshZqXeLVPXnLSuLxsSl7td2VjmpZaTLo3+/Kjv3rVlZ6 Ys68KacvXNWcusLK+IE++0fO2FJP20l7r6d8fzuD68rfmNDDatISQZFaOxbf4XttcG7jg0OJ +1oWbkk8wMLy/eK1jm0WzDmrfyfWZUulvgt+rcRSnJFoqMVcVJwIAHW93589AgAA Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:39:19 -0000 On Jun 30, 2011, at 6:34 PM, Martin Focazio wrote: > On Jun 30, 2011, at 19:51, james woodyatt wrote: >> >> The key thing here is that by Alice choosing to use one service provider over another, she can make Bob's application fail, and vice versa. The mobile service providers that don't have enough IPv4 addresses to serve all their customers are in a bind and can't budge. The wireline service providers who have 5-10 years of IPv4 addresses in reserve are the ones whistling past the graveyard. > > You assume at Alice CAN select a service provider. In a large part of > the USA your choices are nil. You have a single wireline provider or > you don't have a connection. Telecommunications services are still ostensibly a regulated utility in the USA. If the people living in those areas neither want to move, nor demand their utility commissions to hold service providers accountable for the proper operation of the monopoly franchise they receive from the government, then those people are making their choice. Choosing an alternative is possible. It entails either individual action to relocate or collective action to reform the telecommunications services. Inaction, of course, is also an alternative. People choose one or the other. As I said, Alice can break Bob's applications by choosing her service provider. And vice versa. -- james woodyatt member of technical staff, core os networking From moore@network-heretics.com Fri Jul 1 11:31:57 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F8111E8126; Fri, 1 Jul 2011 11:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op0VQuAdkVHM; Fri, 1 Jul 2011 11:31:56 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 73BA911E8128; Fri, 1 Jul 2011 11:31:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 25FD320976; Fri, 1 Jul 2011 14:31:18 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 01 Jul 2011 14:31:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=vizbAscX1JZsrvh8qXkP9afekLc=; b=AXf7b7DTSkzF9Klow/mf2xAmj2I5OPLmd8z+nmkhZJCzDebsVWyEo6RA34ZPLaIg2UL8HzPNswbRdioH33jWY0VE2ycxk/6Cl/Gr+2NkWtcfCnLbbL05VeTsQk/+NW0+4qNLiTb2RIaABcxD7IQyxZST9VIOG6CK7pV7T/1WJIs= X-Sasl-enc: ZdXZ+RdhyiwIO3rTQFOYDi5/ezfTTrS2oc4IYoqkVnDW 1309545077 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id CDC94405EAA; Fri, 1 Jul 2011 14:31:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0CA192.1040801@broadcom.com> Date: Fri, 1 Jul 2011 14:30:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <75CB375A-C9AD-4FE9-9D37-08EBFCA9A0AB@network-heretics.com> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <4E0C9D58.30002@gont.com.ar> <4E0CA192.1040801@broadcom.com> To: Stephen [kiwin] PALM X-Mailer: Apple Mail (2.1084) Cc: "fun@ietf.org" , IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:31:57 -0000 Anytime we develop standards, the standards apply to future products. = There's no point in defining standards for applications and devices that = are already deployed. Sure, it's nice to have backward compatibility. But I don't think = anyone is likely to propose standards for HOMENET that will = significantly break compatibility with existing products. It's not as = if the set of applications and devices that one uses in a home network = is disjoint from the set of applications and devices used in other = networks. And it's reasonable to expect that users of existing = applications and devices might need to do some special-case = configuration to get those applications and devices to continue to work. = =20 Just to pick one example, if a legacy device is v4-only, and the only = access available is NATted v4 or native v6, there might be a need to = configure the device to be externally accessible using a v6 address. = The home network might support v4 internally but there might not be v4 = service available outside that enclave. Backward compatibility =3D good. Insisting that home networks always = use the same kludges that are used now =3D bad. Maybe the right answer is that the HOMENET group should consider what = means are needed to provide some measure of compatibility with legacy = devices and applications, that might continue to be used with networks = meeting the new standards. The working group seems like it's in a much = better position than the IETF list to propose reasonable compromises on = these issues. Keith On Jun 30, 2011, at 12:17 PM, Stephen [kiwin] PALM wrote: > It is not for "us" to decide when a user's network is not worth = expending > any more energy on. They have deployed their network... > and do not want to expend any more energy themselves. If their SP = deploys > IPv6 inelegantly, the user would have a lot of frustration/work. = Which > will generate many expensive tech support calls... and potentially = lost customers. >=20 > It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES = that users have. >=20 > regards, kiwin >=20 > On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote: >>=20 >> "Gone" isn't so important as "not worth expending any more energy = on.". So I'm with Keith and would like to find some words like "when it = doesn't take any more work." >>=20 >> - Ralph >>=20 >> On Jun 30, 2011, at 12:00 PM, "Fernando Gont" = wrote: >>=20 >>> On 06/30/2011 12:46 PM, Keith Moore wrote: >>>> I'd like for this group to relax the "wherever possible" bit, so as = to not preclude solutions where IPv6 can do a better job than IPv4. >>>>=20 >>>> IPv4 is a dinosaur gasping for its last breaths. >>>=20 >>> Just curious: when you expect IPv4 to be gone? (including "gone" = from >>> home and enterprise networks) >>>=20 >>> Thanks, >>> -- >>> Fernando Gont >>> e-mail: fernando@gont.com.ar || fgont@acm.org >>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >>=20 >=20 > --=20 > Stephen [kiwin] Palm Ph.D. E: = palm@kiwin.com > Senior Technical Director T: = +1-949-926-PALM > Broadcom Broadband Communications Group F: = +1-949-926-7256 > Irvine, California W: = http://www.kiwin.com > Secondary email accounts: stephenpalm@alumni.uci.edu = palm@broadcom.com > s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu = palm@ics.t.u-tokyo.ac.jp >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From listbounce-01@voort.ca Fri Jul 1 13:03:59 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2E411E80A9; Fri, 1 Jul 2011 13:03:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw7feMyG37OV; Fri, 1 Jul 2011 13:03:58 -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 B1BA59E805F; Fri, 1 Jul 2011 13:03:58 -0700 (PDT) Received: by gxk19 with SMTP id 19so1788673gxk.31 for ; Fri, 01 Jul 2011 13:03:58 -0700 (PDT) Received: by 10.91.212.15 with SMTP id o15mr3348168agq.189.1309550638086; Fri, 01 Jul 2011 13:03:58 -0700 (PDT) Received: from Kens-MacBook-Pro.local (76-10-173-233.dsl.teksavvy.com [76.10.173.233]) by mx.google.com with ESMTPS id 6sm1241265anu.31.2011.07.01.13.03.56 (version=SSLv3 cipher=OTHER); Fri, 01 Jul 2011 13:03:57 -0700 (PDT) Message-ID: <4E0E282B.1060400@voort.ca> Date: Fri, 01 Jul 2011 16:03:55 -0400 From: Kenneth Voort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ietf@ietf.org, fun@ietf.org References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> In-Reply-To: <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 20:03:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would also add that future IPv6 capable devices should allow end users to reach the IPv6 Internet from an IPv4-only provider through some means, perhaps tunneling, with no or minimal administrator intervention. I can see many providers remaining IPv4-only long into the future. On 11-06-30 5:57 AM, Mark Townsley wrote: > > I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: > > - coexist with (existing) IPv4 protocols, devices, applications, etc. > - operate in a (future) IPv6-only home network in the absence of IPv4 > - be IP-agnostic whenever possible > > In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. > > - Mark - -- Kenneth Voort - kenneth {at} voort {dot} ca FDF1 6265 EBAB C05C FD06 1AED 158E 14D6 37CD E87F | pgp encrypted email preferred -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk4OKCsACgkQFY4U1jfN6H8gawCgkTQmlcodjih+Pawf8YTLZYiI 7M4AoI2Bm7F+uBc2lmoo+IdHEpeklcf6 =Hv52 -----END PGP SIGNATURE----- From moore@network-heretics.com Fri Jul 1 14:14:45 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44711E80C2; Fri, 1 Jul 2011 14:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGXt1YxjqXKU; Fri, 1 Jul 2011 14:14:44 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4FE9E8030; Fri, 1 Jul 2011 14:14:44 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 47FFD20B66; Fri, 1 Jul 2011 17:14:44 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 01 Jul 2011 17:14:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=buOpRo1nF+/CDebHb6OPZQpBxs0=; b=d6Ae3iWnV9BAL6727cSHBpQbIFXAlYbtFzSWCgnryoJWDq6kb5t9S/3EJQWO4gNwh3e2btFmdXLJ1BdE70+P16RAYpYr0gwBqrzeBq5yjp9TNEAmlAf8UJKGQVaF+i5LG4tRl5uQJ8kOYHBROAOibrXB/JM7z7sz0dY8wOpUBaA= X-Sasl-enc: awSei0P5APbP1lCOvKQOKSBm3/7GfmiLwfP9DaNRZYcc 1309554883 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 859B140399D; Fri, 1 Jul 2011 17:14:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0E282B.1060400@voort.ca> Date: Fri, 1 Jul 2011 17:14:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> To: Kenneth Voort X-Mailer: Apple Mail (2.1084) Cc: ietf@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 21:14:45 -0000 On Jul 1, 2011, at 4:03 PM, Kenneth Voort wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I would also add that future IPv6 capable devices should allow end = users to reach the IPv6 Internet > from an IPv4-only provider through some means, perhaps tunneling, with = no or minimal administrator > intervention. I can see many providers remaining IPv4-only long into = the future. +1 From moore@network-heretics.com Fri Jul 1 14:18:17 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4411E81BA; Fri, 1 Jul 2011 14:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eE02o+NEcDe; Fri, 1 Jul 2011 14:18:17 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id DF40E11E81CA; Fri, 1 Jul 2011 14:18:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 95F3C20BB3; Fri, 1 Jul 2011 17:18:10 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 01 Jul 2011 17:18:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=CJQyH/9A9W3WHOTxT5h3GdnHf7Y=; b=cDISCaw+zPLrjDtXVmZMEtDW+mNTUY7lsO4tDq1JWWcRcU1jAKDFqjJecQLW7vQnxWDI9RiRExiPSdAnfvxAJyLogf7PrI3TMpFMfmZQCO/Gg/VKQMR6+msaQSSZrzxSX/7whkVnRbE4oJ62VszCWUynPlB35ZI1a0ntKyiX5YI= X-Sasl-enc: A6yFzRmGFRRs4XK8FCl+rRR8I80hy/ZVKMNDfJxw8U3a 1309555090 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B5B840A931; Fri, 1 Jul 2011 17:18:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0E2A75.6040207@dougbarton.us> Date: Fri, 1 Jul 2011 17:17:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> <4E0E2A75.6040207@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: ietf@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 21:18:17 -0000 On Jul 1, 2011, at 4:13 PM, Doug Barton wrote: > On 07/01/2011 13:03, Kenneth Voort wrote: >> I would also add that future IPv6 capable devices should allow end = users to reach the IPv6 Internet >> from an IPv4-only provider through some means, perhaps tunneling, = with no or minimal administrator >> intervention. I can see many providers remaining IPv4-only long into = the future. >=20 > This is an area that we very clearly do not need to get involved in = because it will solve itself due to market forces. Right now there is no = IPv6-only content that anyone cares about. When that changes, users will = start demanding that their provider give them access to it, or vote with = their feet. Whenever people talk about the Internet as if it were just about "access = to content", I have to wonder. The Internet has always been more = about conversation than content. =20 > To summarize my main point once again, there is nothing for the IETF = to do here, the problem will take care of itself. Quite the contrary. We still don't have a good transition mechanism = that HOMENET could specify. 6to4 has problems as we're now painfully = aware; configured tunnels and Teredo have different problems. There's = still room for work in this space if better solutions can be identified. = Though it doesn't seem appropriate to ask the HOMENET WG to develop = them. Keith From dougb@dougbarton.us Fri Jul 1 13:13:48 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB59911E8190 for ; Fri, 1 Jul 2011 13:13:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vghyCcgwa58i for ; Fri, 1 Jul 2011 13:13:48 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D57AE11E814E for ; Fri, 1 Jul 2011 13:13:47 -0700 (PDT) Received: (qmail 13216 invoked by uid 399); 1 Jul 2011 20:13:46 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 1 Jul 2011 20:13:46 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E0E2A75.6040207@dougbarton.us> Date: Fri, 01 Jul 2011 13:13:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Kenneth Voort References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> In-Reply-To: <4E0E282B.1060400@voort.ca> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 Jul 2011 14:28:53 -0700 Cc: ietf@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 20:13:49 -0000 On 07/01/2011 13:03, Kenneth Voort wrote: > I would also add that future IPv6 capable devices should allow end users to reach the IPv6 Internet > from an IPv4-only provider through some means, perhaps tunneling, with no or minimal administrator > intervention. I can see many providers remaining IPv4-only long into the future. This is an area that we very clearly do not need to get involved in because it will solve itself due to market forces. Right now there is no IPv6-only content that anyone cares about. When that changes, users will start demanding that their provider give them access to it, or vote with their feet. That said, I don't see IPv6-only content happening any time in the next 5 years, at least. Content providers do not want to cut themselves off from 99.9% of their potential user base. What's going to encourage IPv6 adoption on the content side are things like smart phones that use it natively (which is already happening). Content providers will see (and many are already seeing) that it is in their own best interest to get their content up on IPv6. The ISP side will be dragged kicking and screaming into the IPv6 world in the next couple of years as the IPv4 addresses really do dry up, and the cost of obtaining more on the gray market begins to exceed the cost of deploying IPv6. And of course, some just won't make the transition, and will ultimately fail. C'est la vie. To summarize my main point once again, there is nothing for the IETF to do here, the problem will take care of itself. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jnc@mercury.lcs.mit.edu Fri Jul 1 13:43:02 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADABB11E81B9; Fri, 1 Jul 2011 13:43:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vTni4UzN5Hd; Fri, 1 Jul 2011 13:43:02 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0B011E815B; Fri, 1 Jul 2011 13:43:02 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 069D218C14E; Fri, 1 Jul 2011 16:43:01 -0400 (EDT) To: fun@ietf.org, ietf@ietf.org Message-Id: <20110701204301.069D218C14E@mercury.lcs.mit.edu> Date: Fri, 1 Jul 2011 16:43:01 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Fri, 01 Jul 2011 14:28:53 -0700 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 20:43:02 -0000 > From: Kenneth Voort > future IPv6 capable devices should allow end users to reach the IPv6 > Internet from an IPv4-only provider through some means, perhaps > tunneling, with no or minimal administrator intervention. You mean, like with 6to4? (Sorry, couldn't resist! :-) Noel From jari.arkko@piuha.net Fri Jul 1 14:48:20 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA98111E81C3 for ; Fri, 1 Jul 2011 14:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIU3z5VeTUG9 for ; Fri, 1 Jul 2011 14:48:20 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44A11E80E7 for ; Fri, 1 Jul 2011 14:48:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 20CE82D366; Sat, 2 Jul 2011 00:48:17 +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 zRvN2OOPdkhh; Sat, 2 Jul 2011 00:48:13 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B85BD2CEFF; Sat, 2 Jul 2011 00:48:12 +0300 (EEST) Message-ID: <4E0E409C.3050106@piuha.net> Date: Fri, 01 Jul 2011 23:48:12 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: robert@raszuk.net References: <4E0DB36D.60303@raszuk.net> <7EC07A1A-CCD2-4A4A-A92D-8475430F558E@townsley.net> In-Reply-To: <7EC07A1A-CCD2-4A4A-A92D-8475430F558E@townsley.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: fun@ietf.org Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 21:48:21 -0000 Robert, Thank you for very interesting questions. As Mark noted, some aspects of diagnostics and troubleshooting are inherent in the notion of automatic configuration. Prefix delegation, routing, etc. has to figure out if there is connectivity and what to do if there isn't. But its mostly automatic, not built for human network managers to play with. Maybe the answers to your question are clearer once we have completed the architecture work. Maybe there are some additional diagnostics needs, but at this point I'll admit that I don't see them. Whereas... >> 2. How about multihoming with seamless switchover ? >> > > This particular elephant has been in and out of various versions of the charter. I'll plead the 5th on this one and ask Jari to describe where we are on this, in particular in relation to mif, shim6, lisp, rrg, v6ops, or any of the other areas that are touching on this. > > Personally, I think it would be naive to not include the various possibilities of multihomed connectivity, at the vary least in describing the architecture for which we will work within. I don't think homenet is the place to solve the general issue of "seamless multihoming" at the protocol level, but perhaps we would point to what works well in a home setting... we might even agree to one way to do it if we are really, really, lucky. > I think multihoming solutions should be out of scope. Not because they are uninteresting, they're not -- they are very important. And I know there are specific requirements for it in some home network cases. But it is a very complex and challenging topic by itself, and one where we have multiple IETF workings groups already. I agree with Mark though that we may point to some solutions and think about this during the architecture work, but even there I'd be a bit careful not to taken on too ambitious tasks. Jari From robert@raszuk.net Fri Jul 1 14:49:56 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7997F11E817C for ; Fri, 1 Jul 2011 14:49:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIEQXBTRAhlW for ; Fri, 1 Jul 2011 14:49:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 11D1B11E80E7 for ; Fri, 1 Jul 2011 14:49:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksIAPc/Dk6rRDoH/2dsb2JhbABSmQ6Oc3eIeaM3nVmGMgSSMoR2iz0 X-IronPort-AV: E=Sophos;i="4.65,460,1304294400"; d="scan'208";a="473733045" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2011 21:49:55 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p61Lnswd019483 for ; Fri, 1 Jul 2011 21:49:55 GMT Message-ID: <4E0E4105.6080208@raszuk.net> Date: Fri, 01 Jul 2011 23:49:57 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: fun@ietf.org References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> <4E0E2A75.6040207@dougbarton.us> In-Reply-To: <4E0E2A75.6040207@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 21:49:56 -0000 Doug, > This is an area that we very clearly do not need to get involved in > because it will solve itself due to market forces. Maybe it will, but why not make it easier for early adopters ? Especially for those who would like to start offering some v6 content over their v4 ISPs today. It seems that this is equally useful as AMT (Automatic IP Multicast Without Explicit Tunnels) as described in the below IETF WG doc: draft-ietf-mboned-auto-multicast-10 R. From robert@raszuk.net Fri Jul 1 15:15:10 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACE811E809B for ; Fri, 1 Jul 2011 15:15:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35OUKTslTmKY for ; Fri, 1 Jul 2011 15:15:09 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id B830D11E8085 for ; Fri, 1 Jul 2011 15:15:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANVGDk6rRDoH/2dsb2JhbABSqAF3iHmjZJ1bhjIEkjKEdos9 X-IronPort-AV: E=Sophos;i="4.65,460,1304294400"; d="scan'208";a="351718602" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 22:14:50 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p61MEmqm009556; Fri, 1 Jul 2011 22:14:49 GMT Message-ID: <4E0E46DC.90604@raszuk.net> Date: Sat, 02 Jul 2011 00:14:52 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jari Arkko References: <4E0DB36D.60303@raszuk.net> <7EC07A1A-CCD2-4A4A-A92D-8475430F558E@townsley.net> <4E0E409C.3050106@piuha.net> In-Reply-To: <4E0E409C.3050106@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fun@ietf.org Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 22:15:10 -0000 Hi Jari, > As Mark noted, some aspects of diagnostics and troubleshooting are > inherent in the notion of automatic configuration. Prefix delegation, > routing, etc. has to figure out if there is connectivity and what to do > if there isn't. But its mostly automatic, not built for human network > managers to play with. Well honestly while I agree that automation is great for vast majority of home networks, unfortunately for someone like me it is just scary - maybe too scary. If I buy or rent a car I always pick manual ... (maybe wrong comparison maybe not ... but it is just a matter of awareness of one's skills of control). > I think multihoming solutions should be out of scope. Maybe I was not sufficiently precise. I am not asking to roll-out new models of PIC or active/active load balancing for home networks. I am just trying to see a room for a spec which would define what should be the CPE behaviour when someone connects two DSL/Cable/Mixed lines to it. I hope we would not prohibit it ... and if not the behaviour needs to be either defined here or referenced as Mark mentioned earlier to other documents which solve this already. Many thx, R. From Christopher.Palmer@microsoft.com Fri Jul 1 15:53:00 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799EA11E8202 for ; Fri, 1 Jul 2011 15:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.932 X-Spam-Level: X-Spam-Status: No, score=-8.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y45ZjKcZ1GS for ; Fri, 1 Jul 2011 15:52:58 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id A7FF211E8203 for ; Fri, 1 Jul 2011 15:52:11 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Jul 2011 15:52:11 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 1 Jul 2011 15:52:10 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.59]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Fri, 1 Jul 2011 15:52:10 -0700 From: Christopher Palmer To: "fun@ietf.org" Thread-Topic: Feedback - HomeNet Charter Thread-Index: Acw4P6lZ494RAkYLScaJPz+8uNFAzwAAcqoQ Date: Fri, 1 Jul 2011 22:52:09 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DB@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: multipart/alternative; boundary="_000_0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DBTK5EX14MBXW601w_" MIME-Version: 1.0 Subject: [fun] Feedback - HomeNet Charter X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 22:53:00 -0000 --_000_0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DBTK5EX14MBXW601w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Folks, I've been trying to keep track of all the feedback concerning the HomeNet C= harter. Sorry for bringing up points that may have been discussed before, o= r are in general noobish. "End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore." We are absolutely aligned to this objective. IPv6 provides an opportunity t= o avoid the limiting topology of current IPv4 deployments and this should a= priority for everyone in the technology community. I have points of concern. "Managing routing" is a very broad category of th= ings and I'm not clear about what the vision is there. The focus on multiple subnet solutions doesn't seemed align to current oper= ational reality. While I understand the desire to be forward looking, this = seems "very" forward looking to a point. I'd be interested in data that ref= lects the contrary. Windows and Apple currently use different mechanisms for service discovery.= Is unification a goal? WSD is managed by OASIS, which isn't mentioned for = liasoning. Would we imagine the multicast DNS draft moving over to this WG?= I'm just confused on what is happening and what is intended to happen. Whi= le the charter says routing changes will be handled by the routing area wor= king group, the charter is not that specific on DNS changes. I feel like the vision and defining principles could be spelled out more. W= e want IPv6 home networks to be routable. OK. What else do we want? Why ar= e we doing this? "The purpose of this working group is to focus on this evolution...." To wh= at end? The requirements list reads "a solution will cover these technology areas" = - I'd be interested in some definition of what promises those technology ar= eas are meant to fulfill, the shape of the solution, not just its compositi= on. Best, Chris IPv6 @ Windows --_000_0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DBTK5EX14MBXW601w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Folks,

 

I’ve been trying to keep track of all the feed= back concerning the HomeNet Charter. Sorry for bringing up points that may = have been discussed before, or are in general noobish.

 

“End-to-end communication is both an opportuni= ty and a concern as it

enables new applications but also exposes nodes in t= he internal

networks to receipt of unwanted traffic from the Int= ernet. Firewalls

that restrict incoming connections may be used to pr= event exposure,

however, this reduces the efficacy of end-to-end con= nectivity that

IPv6 has the potential to restore.”=

 

We are absolutely aligned to this objective. IPv6 pr= ovides an opportunity to avoid the limiting topology of current IPv4 deploy= ments and this should a priority for everyone in the technology community.<= o:p>

 

I have points of concern. “Managing routing= 221; is a very broad category of things and I’m not clear about what = the vision is there.

 

The focus on multiple subnet solutions doesn’t= seemed align to current operational reality. While I understand the desire= to be forward looking, this seems “very” forward looking to a = point. I’d be interested in data that reflects the contrary.

 

Windows and Apple currently use different mechanisms= for service discovery. Is unification a goal? WSD is managed by OASIS, whi= ch isn’t mentioned for liasoning. Would we imagine the multicast DNS = draft moving over to this WG? I’m just confused on what is happening and what is intended to happen. While the charter say= s routing changes will be handled by the routing area working group, the ch= arter is not that specific on DNS changes.

 

I feel like the vision and defining principles could= be spelled out more. We want IPv6 home networks to be routable. OK.  = What else do we want? Why are we doing this?

 

“The purpose of this working group is to focus= on this evolution….” To what end?

 

The requirements list reads “a solution will c= over these technology areas” – I’d be interested in some = definition of what promises those technology areas are meant to fulfill, th= e shape of the solution, not just its composition.

 

Best,

Chris

IPv6 @ Windows

 

 

--_000_0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DBTK5EX14MBXW601w_-- From jhw@apple.com Fri Jul 1 16:17:33 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE511E81CB for ; Fri, 1 Jul 2011 16:17:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94L147OBJmS3 for ; Fri, 1 Jul 2011 16:17:33 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3380D11E811F for ; Fri, 1 Jul 2011 16:17:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay12.apple.com ([17.128.113.53]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNO009OCGOKH061@mail-out.apple.com> for fun@ietf.org; Fri, 01 Jul 2011 16:17:19 -0700 (PDT) X-AuditID: 11807135-b7b76ae000001169-da-4e0e55f2790e Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay12.apple.com (Apple SCV relay) with SMTP id 93.B4.04457.3F55E0E4; Fri, 01 Jul 2011 16:19:15 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNO00FNVGOVQB90@koseret.apple.com> for fun@ietf.org; Fri, 01 Jul 2011 16:17:19 -0700 (PDT) From: james woodyatt In-reply-to: <20110701204301.069D218C14E@mercury.lcs.mit.edu> Date: Fri, 01 Jul 2011 16:17:18 -0700 Message-id: References: <20110701204301.069D218C14E@mercury.lcs.mit.edu> To: fun@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUiON1OXfdzKJ+fwf/LHBaPD8xid2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRs/liIKt7BXPPzxlaWD8ydrFyMkhIWAicbjpDAuELSZx4d56 ti5GLg4hgU4miYtPr7ODJHgFBCV+TL4HVMTBwSwgL3HwvCxImFlAS+L7o1YWiPppTBIvb/0B GyQsYCPRuHsiG4jNJqAi8e3yXSYQm1PAVuL1123MIHNYBFQlelboQoy3kVg2fy0jiC0EZN86 +gusVURAQGLntDvsELfJSyxu+cw4gZF/FpKLZiFcNAvJRQsYmVcxChal5iRWGhrpJRYU5KTq JefnbmIEBVdDoekOxkcL1Q8xCnAwKvHwLnzK6yfEmlhWXJl7iFGCg1lJhPc/C5+fEG9KYmVV alF+fFFpTmrxIUZpDhYlcd4qRy4/IYH0xJLU7NTUgtQimCwTB6dUA6PAtzpv/k0CUtsUdaJC H85WFPHjbNDuuPlxVYvHpm/2t1ds3/j1uc+fVzUXMkNnTtdJ1royobBPXJh3Vpfr82O3hCoy EsSPcqUrptiuS/k96adr1LzwaNbYl/c/PnXVPsRb7XErXFBi6ZxZ97L++WjefvMpfY6uJUt3 Heui25ekHgg9ar46o0mJpTgj0VCLuag4EQBUUkTRKgIAAA== Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 23:17:33 -0000 [distribution narrowed to FUN list] On Jul 1, 2011, at 13:43 , Noel Chiappa wrote: > > > You mean, like with 6to4? > Actually, I suspect that operator hostility to 6to4 is high enough that devising some stealthier means of making their dumb IPv4-only networks serve our higher purposes will be necessary. I joke that we should use a stylized audio feedback that reminds the listener of an old acoustic modem when signaling the establishment of such a tunnel, because that's a pretty good metaphor for what we'd be doing. I suspect it wouldn't take much to adapt 6RD to these ends. Remember, 6RD tunnels do *not* need to be terminated by the provider network. They can be terminated by a third-party with minimal human interface burden. Perhaps I should find the time to write a draft on the topic. -- james woodyatt member of technical staff, core os networking From robert@raszuk.net Fri Jul 1 16:27:53 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641439E800A for ; Fri, 1 Jul 2011 16:27:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU+z02LIv2XM for ; Fri, 1 Jul 2011 16:27:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DE51A1F0C63 for ; Fri, 1 Jul 2011 16:26:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksIAH1XDk6rRDoG/2dsb2JhbABSmQ6Oc3eIeaNfnWSGMgSSMoR2iz0 X-IronPort-AV: E=Sophos;i="4.65,461,1304294400"; d="scan'208";a="390354968" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2011 23:26:45 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p61NQi5G030275 for ; Fri, 1 Jul 2011 23:26:45 GMT Message-ID: <4E0E57B8.8050007@raszuk.net> Date: Sat, 02 Jul 2011 01:26:48 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: fun@ietf.org References: <20110701204301.069D218C14E@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 23:27:53 -0000 Hi James, > I suspect it wouldn't take much to adapt 6RD to these ends. > Remember, 6RD tunnels do*not* need to be terminated by the provider > network. They can be terminated by a third-party with minimal human > interface burden. Perhaps I should find the time to write a draft on > the topic. Finding a time to write a draft is a great idea. However I think even better idea would be to find and wiki the list of actual providers anyone could terminate his 6RD to. R. From fluffy@cisco.com Fri Jul 1 17:24:21 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBD99E8004 for ; Fri, 1 Jul 2011 17:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQzxgE-hgrTw for ; Fri, 1 Jul 2011 17:24:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id AE18C9E802E for ; Fri, 1 Jul 2011 17:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=10763; q=dns/txt; s=iport; t=1309566260; x=1310775860; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=veqLr0ywEa5h4ScEZUoRpw1yNslEoaLn61NFJAvoTPE=; b=Lkl/yku6Bk19KSxyQavqrEqKrpla/WitsJd8Jja5THuHiwTEKgyvc0Su nj1G/x3IwXZzCC5Lk1PDX3Ney7VYFemxEMG/td6P4c+QNuuGCLHn+xQUk yHUEtFQx4Cu2Y0BRoBLwfYDwmsegR37Ih9wNEQx2/TJvtTV5pz6CVBwfb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFhkDk6rRDoI/2dsb2JhbABSqAF3iHmjd51cgzKDAASHPop0hHaEUIcK X-IronPort-AV: E=Sophos;i="4.65,461,1304294400"; d="scan'208";a="473784314" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2011 00:24:20 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p620OJs6017511 for ; Sat, 2 Jul 2011 00:24:19 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <4E0AE3CF.2070504@piuha.net> Date: Fri, 1 Jul 2011 18:24:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE3CF.2070504@piuha.net> To: fun@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 00:24:22 -0000 I'm sure this is a spectacularly clueless question but, .... could = someone say a bit more about why we need a routing protocol. I get that = there is a need for small number of subnets, but it seems like most the = requirements I have seen could be deal with using a single router that = could route between all the subnets. As I said, clueless questions but = can someone fill me in a bit on the use cases for a routing protocol? Or = why a new routing protocol might be needed. Thanks.=20 On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote: > I wanted to provide an update of the situation with this working group = proposal. >=20 > HOMENET is a new working group proposal, a variation of the = HOMEGATE/HOMENET theme that we discussed last year, but this time = looking at it from a different angle. The old effort was mostly focused = about what home gateways should do: forwarding, transport, and DNS = proxying issues. The new effort is about home networks themselves, in = particular what kind of network architecture and configuration is = necessary to support IPv6-based home networks. We view IPv4-based home = networks as "done" at this time (or perhaps as "cannot be changed = anyway"). >=20 > I have been discussing this effort in the background for the last = couple of month with Mark Townsley and others, and more publicly since = early June. The proposal has been brought to the IESG, IAB and some = directorates for discussion, and we've been going back and forth whether = this is ready to become a working group or needs to be run as a BOF in = Quebec City. The current plan is that the working group proposal goes to = IETF-wide review this week, and if the feedback from the community, IAB, = and the IESG is positive, we will create the working group just in time = for the IETF. Otherwise, the slot reserved in the agenda for the meeting = will be used to run the proposal as a BOF. >=20 > In any case, I would like to solicit discussion on this topic, and = perhaps some early drafts as well. Please comment on the charter at = least. >=20 > Note that the new proposal was called FUN at the time that we created = the list. It has now been renamed back to HOMENET to be more = descriptive. The list will be renamed soon as well (current subscribers = will stay). >=20 > This is the most recent version of the charter we should discuss: >=20 > Home Networks (homenet) > ----------------------------------- >=20 > Current Status: Proposed > Last Edit: Wednesday, June 29th, 2011 >=20 > Chairs: > TBD >=20 > Internet Area Directors: > Ralph Droms > Jari Arkko >=20 > Internet Area Advisor: > Jari Arkko >=20 > Routing Area Technical Advisor: > TBD >=20 > Security Area Technical Advisor: > TBD >=20 > Mailing Lists: > General Discussion: fun@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/fun > Archive: http://www.ietf.org/mail-archive/web/fun >=20 > Description of Working Group: >=20 > This working group focuses on the evolving networking technology > within and among relatively small =93residential home=94 networks. For > example, an obvious trend in home networking is the proliferation of > networking technology in an increasingly broad range and number of > devices. This evolution in scale and diversity sets some requirements > on IETF protocols. Some of the relevant trends include: >=20 > o Multiple segments: While less complex L3-toplogies involving as few > subnets as possible are preferred in home networks for a variety of > reasons including simpler management and service discovery, the > introduction of more than one subnet into a home network is enough > to add complexity that needs to be addressed, and multiple > dedicated segments are necessary for some cases. For instance, a > common feature in modern home routers in the ability to support > both guest and private network segments. Also, link layer > networking technology is poised to become more heterogeneous, as > networks begin to employ both traditional Ethernet technology and > link layers designed for low-powered sensor networks. Finally, > similar needs for segmentation may occur in other cases, such as > separating building control or corporate extensions from the > Internet access network. Different segments may be associated with > subnets that have different routing and security policies. >=20 > o Service providers are deploying IPv6, and support for IPv6 is > increasingly available in home gateway devices. While IPv6 resembles > IPv4 in many ways, it changes address allocation principles and allows > direct IP addressability and routing to devices in the home from the > Internet. This is a promising area in IPv6 that has proved challenging > in IPv4 with the proliferation of NAT. >=20 > o End-to-end communication is both an opportunity and a concern as it > enables new applications but also exposes nodes in the internal > networks to receipt of unwanted traffic from the Internet. Firewalls > that restrict incoming connections may be used to prevent exposure, > however, this reduces the efficacy of end-to-end connectivity that > IPv6 has the potential to restore. >=20 > Home networks need to provide the tools to handle these situations in > a manner accessible to all users of home networks. Manual > configuration is rarely, if at all, possible. The purpose of this > working group is to focus on this evolution, in particular as it > addresses the introduction of IPv6, by developing an architecture > addressing this full scope of requirements: >=20 > o prefix configuration for routers > o managing routing > o name resolution > o service discovery > o network security >=20 > The task of the group is to produce an architecture document that > outlines how to construct home networks involving multiple routers and > subnets. This document is expected to apply the IPv6 addressing > architecture, prefix delegation, global and ULA addresses, source > address selection rules and other existing components of the IPv6 > architecture. The architecture document should drive what protocols > changes, if any, are necessary. Specific protocol work described below > is expected to be within the scope of the working group one the > architecture work is complete. However, the group is required to > review its charter and milestones with the IESG and IETF community > before submitting documents that make protocol changes. It is expected > that the group has to discuss some of the below solutions, however, in > order to complete the architecture work. >=20 > The group will apply existing protocols to handle the five > requirements above. For prefix configuration, existing protocols are > likely sufficient, and at worst may need some small enhancements, such > as new options. For automatic routing, it is expected that existing > routing protocols can be used as is, however, a new mechanism may be > needed in order to turn a selected protocol on by default. For name > resolution and service discovery, extensions to existing > multicast-based name resolution protocols are needed to enable them to > work across subnets. >=20 > For network security, the group shall document the concept of > "advanced security" as a further development of "simple security" from > RFC 6092. The main goal of this work is to enable a security policy > that adapts to IPv6 threats as they emerge, taking into account not > only traffic from the Internet at large, but within and leaving the > home network itself. >=20 > It is expected that the working group will define a set of protocol > specifications to accomplish the five requirements from > above. However, it is not in the scope of the working group to define > entirely new routing protocols or address allocation protocols. As > noted, additional options or other small extensions may be necessary > to use the existing protocols in these new configuration tasks. The > working group shall also not make any changes to IPv6 protocols or > addressing architecture. Prefix configuration, routing, and security > related work shall not cause any changes that are not backwards > compatible to existing IPv6 hosts. There may be host visible changes > in the work on naming and discovery protocols, however. In its design, > the working group shall also consider security aspects and the impact > on manageability. The main focus of the working group is home > networks, but the group's results may also find applications in other > small networks. >=20 > The working group will liaise with the relevant IETF working > groups. In particular, the group should work closely with the V6OPS > working group, review any use or extension of DHCP with the DHC > working group, and work with additional DNS requirements with the > DNSEXT and DNSOP working groups. If it turns out that additional > options are needed for a routing protocol, they will be developed in > the appropriate Routing Area working group, with the HOMENET working > group providing the architecture and requirements for such > enhancements. The working group will also liase with external > standards bodies where it is expected that there are normative > dependencies between the specifications of the two bodies. > It is expected that in the architecture definition stage liaising > with the Broadband Forum, DLNA, and UPnP Forum is necessary. >=20 > Milestones: >=20 > Jul 2011 Formation of the working group > Sep 2011 First WG draft on the architecture > Dec 2011 Submission of the architecture draft to the IESG as = Informational RFC > Dec 2011 Charter re-evaluation based on the architecture work > Dec 2011 First WG draft on prefix configuration > Dec 2011 First WG draft on routing > Jan 2012 First WG draft on name resolution > Feb 2012 First WG draft on service discovery > Feb 2012 First WG draft on perimeter security > Feb 2012 Start of routing related work in the relevant routing area = working group, if needed > Mar 2012 Submission of the prefix configuration draft to the IESG as = Standards Track RFC > Apr 2012 Submission of the routing draft to the IESG as Informational = RFC > Sep 2012 Submission of the name resolution draft to the IESG as = Standards Track RFC > Nov 2012 Submission of the service discovery draft to the IESG as = Standards Track RFC > Dec 2012 Submission of the perimeter security draft to the IESG as = Informational RFC >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From fred@cisco.com Fri Jul 1 23:20:17 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366C511E80E3 for ; Fri, 1 Jul 2011 23:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-cfWz0PEH1k for ; Fri, 1 Jul 2011 23:20:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 934CF11E80B2 for ; Fri, 1 Jul 2011 23:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1316; q=dns/txt; s=iport; t=1309587615; x=1310797215; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=4CTLTKPtS0htDNUOdDU1BdD8VlFc5duTxJwe97DMnr0=; b=ep6m4xoBBJiaO8iV/ZZyB3rdY9dso3AwENOgZkkCuZLrZDs+XbeZVg+m Z4778eelOSOuc5/P3exG/AjwezHy/+8OsoQPx7w5LIFPoYqcMyxRpb2PP mBZ6SOEI/jVKenCwBBYMHQObzxONowTnlckicnYSOv45xSNZqROVTCkoL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0IAFW3Dk6rRDoH/2dsb2JhbABSmQ+Oc3eIeqVTnUSGNQSHP4p1hHiLXQ X-IronPort-AV: E=Sophos;i="4.65,462,1304294400"; d="scan'208";a="473850845" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2011 06:20:15 +0000 Received: from Freds-Computer.local (sjc-vpn2-1521.cisco.com [10.21.117.241]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p626KFgq024069 for ; Sat, 2 Jul 2011 06:20:15 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 01 Jul 2011 23:20:15 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 01 Jul 2011 23:20:15 -0700 From: Fred Baker Date: Fri, 1 Jul 2011 23:20:07 -0700 References: <20110702061725.26914.78761.idtracker@ietfa.amsl.com> To: fun@ietf.org Message-Id: 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: [fun] Fwd: New Version Notification for draft-baker-fun-routing-class-00.txt X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 06:20:17 -0000 FYI Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 1, 2011 11:17:25 PM PDT > To: fred@cisco.com > Cc: fred@cisco.com > Subject: New Version Notification for = draft-baker-fun-routing-class-00.txt >=20 > A new version of I-D, draft-baker-fun-routing-class-00.txt has been = successfully submitted by Fred Baker and posted to the IETF repository. >=20 > Filename: draft-baker-fun-routing-class > Revision: 00 > Title: Routing a Traffic Class > Creation date: 2011-07-01 > WG ID: Individual Submission > Number of pages: 14 >=20 > Abstract: > This note addresses the concept of routing a traffic class. This = has > many possible implementations, IGP and BGP, and link state as well = as > distance vector. The fundamental impetus is the question raised in > RFC 3704 and shim6 of exit routing, the question raised by Mike > O'Dell of source/destination routing, and the "fish" = problem, raised > in many networks, in which distinct traffic classes that could > conceivably use the same route predictably use different routes. > Instead of handling these as "destination routing with a = twist", the > paper looks at the matter systemically. >=20 > Requirements >=20 >=20 >=20 > The IETF Secretariat From fred@cisco.com Fri Jul 1 23:20:37 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7455811E80D3 for ; Fri, 1 Jul 2011 23:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-f4dJ2dHF1D for ; Fri, 1 Jul 2011 23:20:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id D34E911E80B2 for ; Fri, 1 Jul 2011 23:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=803; q=dns/txt; s=iport; t=1309587636; x=1310797236; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=PaPwU2SIeRWYfhmLVMua2oGH3bunSm4MxNNwcaSwOMI=; b=ibWvvNCVrDnfkr+3bYHHPrKTz8CwNmkhyobQB872TCgOD5D1i/XxCsOf kpfnNJpCPTIqIAW5BnRnKYOMlxK92wYRv6VMbXiVMleiePnHaX4Wt8Qc+ oc+qQMMiPnLp3P8qX8SyBJZHzTFULnjvwpgzbiuce2QCMYQaM9Alig8dp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0IAPG3Dk6rRDoH/2dsb2JhbABSmQ+Oc3eIeqVUnUSGNQSHP4p1hHiLXQ X-IronPort-AV: E=Sophos;i="4.65,462,1304294400"; d="scan'208";a="725771922" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2011 06:20:35 +0000 Received: from Freds-Computer.local (sjc-vpn2-1521.cisco.com [10.21.117.241]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p626KFgr024069 for ; Sat, 2 Jul 2011 06:20:35 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 01 Jul 2011 23:20:35 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 01 Jul 2011 23:20:35 -0700 From: Fred Baker Date: Fri, 1 Jul 2011 23:20:35 -0700 References: <20110702061930.27661.98226.idtracker@ietfa.amsl.com> To: fun@ietf.org Message-Id: 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: [fun] Fwd: New Version Notification for draft-baker-fun-multi-router-00.txt X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 06:20:37 -0000 FYI Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 1, 2011 11:19:30 PM PDT > To: fred@cisco.com > Cc: fred@cisco.com > Subject: New Version Notification for = draft-baker-fun-multi-router-00.txt >=20 > A new version of I-D, draft-baker-fun-multi-router-00.txt has been = successfully submitted by Fred Baker and posted to the IETF repository. >=20 > Filename: draft-baker-fun-multi-router > Revision: 00 > Title: Exploring the multi-router SOHO network > Creation date: 2011-07-01 > WG ID: Individual Submission > Number of pages: 12 >=20 > Abstract: > This note explores the ramifications of a multi-router or multihomed > small network, such as a residential or SOHO network. >=20 > Requirements >=20 >=20 >=20 > The IETF Secretariat From jari.arkko@piuha.net Sat Jul 2 01:01:48 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C543C1F0C42 for ; Sat, 2 Jul 2011 01:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW3si0LGxpzE for ; Sat, 2 Jul 2011 01:01:47 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6842A1F0C3B for ; Sat, 2 Jul 2011 01:01:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D9F172CEFF; Sat, 2 Jul 2011 11:01:43 +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 O+86Hstrk5pn; Sat, 2 Jul 2011 11:01:42 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DD6DC2CE66; Sat, 2 Jul 2011 11:01:41 +0300 (EEST) Message-ID: <4E0ED065.6060706@piuha.net> Date: Sat, 02 Jul 2011 10:01:41 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Cullen Jennings References: <4E0AE3CF.2070504@piuha.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: fun@ietf.org Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 08:01:48 -0000 Cullen, Good question. The charter does say that new routing protocols are NOT in scope, however. There may be a need to run a routing protocol, but if so, it would be an existing one. But back to your question. Do we need a routing protocol, or can a single router be at the center and deal with all? I think the single router model is a good one even when there are multiple subnets. That being said, when you plug in. say, the first sensor-network-to-WLAN router that can't do bridging you're in trouble. I personally think we should build for the case where there are multiple routers, while hoping that there is just one and that the number of subnets is either 1 or at least a very small number. Jari Cullen Jennings kirjoitti: > I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol. I get that there is a need for small number of subnets, but it seems like most the requirements I have seen could be deal with using a single router that could route between all the subnets. As I said, clueless questions but can someone fill me in a bit on the use cases for a routing protocol? Or why a new routing protocol might be needed. Thanks. > > > > On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote: > > >> I wanted to provide an update of the situation with this working group proposal. >> >> HOMENET is a new working group proposal, a variation of the HOMEGATE/HOMENET theme that we discussed last year, but this time looking at it from a different angle. The old effort was mostly focused about what home gateways should do: forwarding, transport, and DNS proxying issues. The new effort is about home networks themselves, in particular what kind of network architecture and configuration is necessary to support IPv6-based home networks. We view IPv4-based home networks as "done" at this time (or perhaps as "cannot be changed anyway"). >> >> I have been discussing this effort in the background for the last couple of month with Mark Townsley and others, and more publicly since early June. The proposal has been brought to the IESG, IAB and some directorates for discussion, and we've been going back and forth whether this is ready to become a working group or needs to be run as a BOF in Quebec City. The current plan is that the working group proposal goes to IETF-wide review this week, and if the feedback from the community, IAB, and the IESG is positive, we will create the working group just in time for the IETF. Otherwise, the slot reserved in the agenda for the meeting will be used to run the proposal as a BOF. >> >> In any case, I would like to solicit discussion on this topic, and perhaps some early drafts as well. Please comment on the charter at least. >> >> Note that the new proposal was called FUN at the time that we created the list. It has now been renamed back to HOMENET to be more descriptive. The list will be renamed soon as well (current subscribers will stay). >> >> This is the most recent version of the charter we should discuss: >> >> Home Networks (homenet) >> ----------------------------------- >> >> Current Status: Proposed >> Last Edit: Wednesday, June 29th, 2011 >> >> Chairs: >> TBD >> >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >> >> Internet Area Advisor: >> Jari Arkko >> >> Routing Area Technical Advisor: >> TBD >> >> Security Area Technical Advisor: >> TBD >> >> Mailing Lists: >> General Discussion: fun@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >> Archive: http://www.ietf.org/mail-archive/web/fun >> >> Description of Working Group: >> >> This working group focuses on the evolving networking technology >> within and among relatively small “residential home” networks. For >> example, an obvious trend in home networking is the proliferation of >> networking technology in an increasingly broad range and number of >> devices. This evolution in scale and diversity sets some requirements >> on IETF protocols. Some of the relevant trends include: >> >> o Multiple segments: While less complex L3-toplogies involving as few >> subnets as possible are preferred in home networks for a variety of >> reasons including simpler management and service discovery, the >> introduction of more than one subnet into a home network is enough >> to add complexity that needs to be addressed, and multiple >> dedicated segments are necessary for some cases. For instance, a >> common feature in modern home routers in the ability to support >> both guest and private network segments. Also, link layer >> networking technology is poised to become more heterogeneous, as >> networks begin to employ both traditional Ethernet technology and >> link layers designed for low-powered sensor networks. Finally, >> similar needs for segmentation may occur in other cases, such as >> separating building control or corporate extensions from the >> Internet access network. Different segments may be associated with >> subnets that have different routing and security policies. >> >> o Service providers are deploying IPv6, and support for IPv6 is >> increasingly available in home gateway devices. While IPv6 resembles >> IPv4 in many ways, it changes address allocation principles and allows >> direct IP addressability and routing to devices in the home from the >> Internet. This is a promising area in IPv6 that has proved challenging >> in IPv4 with the proliferation of NAT. >> >> o End-to-end communication is both an opportunity and a concern as it >> enables new applications but also exposes nodes in the internal >> networks to receipt of unwanted traffic from the Internet. Firewalls >> that restrict incoming connections may be used to prevent exposure, >> however, this reduces the efficacy of end-to-end connectivity that >> IPv6 has the potential to restore. >> >> Home networks need to provide the tools to handle these situations in >> a manner accessible to all users of home networks. Manual >> configuration is rarely, if at all, possible. The purpose of this >> working group is to focus on this evolution, in particular as it >> addresses the introduction of IPv6, by developing an architecture >> addressing this full scope of requirements: >> >> o prefix configuration for routers >> o managing routing >> o name resolution >> o service discovery >> o network security >> >> The task of the group is to produce an architecture document that >> outlines how to construct home networks involving multiple routers and >> subnets. This document is expected to apply the IPv6 addressing >> architecture, prefix delegation, global and ULA addresses, source >> address selection rules and other existing components of the IPv6 >> architecture. The architecture document should drive what protocols >> changes, if any, are necessary. Specific protocol work described below >> is expected to be within the scope of the working group one the >> architecture work is complete. However, the group is required to >> review its charter and milestones with the IESG and IETF community >> before submitting documents that make protocol changes. It is expected >> that the group has to discuss some of the below solutions, however, in >> order to complete the architecture work. >> >> The group will apply existing protocols to handle the five >> requirements above. For prefix configuration, existing protocols are >> likely sufficient, and at worst may need some small enhancements, such >> as new options. For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default. For name >> resolution and service discovery, extensions to existing >> multicast-based name resolution protocols are needed to enable them to >> work across subnets. >> >> For network security, the group shall document the concept of >> "advanced security" as a further development of "simple security" from >> RFC 6092. The main goal of this work is to enable a security policy >> that adapts to IPv6 threats as they emerge, taking into account not >> only traffic from the Internet at large, but within and leaving the >> home network itself. >> >> It is expected that the working group will define a set of protocol >> specifications to accomplish the five requirements from >> above. However, it is not in the scope of the working group to define >> entirely new routing protocols or address allocation protocols. As >> noted, additional options or other small extensions may be necessary >> to use the existing protocols in these new configuration tasks. The >> working group shall also not make any changes to IPv6 protocols or >> addressing architecture. Prefix configuration, routing, and security >> related work shall not cause any changes that are not backwards >> compatible to existing IPv6 hosts. There may be host visible changes >> in the work on naming and discovery protocols, however. In its design, >> the working group shall also consider security aspects and the impact >> on manageability. The main focus of the working group is home >> networks, but the group's results may also find applications in other >> small networks. >> >> The working group will liaise with the relevant IETF working >> groups. In particular, the group should work closely with the V6OPS >> working group, review any use or extension of DHCP with the DHC >> working group, and work with additional DNS requirements with the >> DNSEXT and DNSOP working groups. If it turns out that additional >> options are needed for a routing protocol, they will be developed in >> the appropriate Routing Area working group, with the HOMENET working >> group providing the architecture and requirements for such >> enhancements. The working group will also liase with external >> standards bodies where it is expected that there are normative >> dependencies between the specifications of the two bodies. >> It is expected that in the architecture definition stage liaising >> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >> >> Milestones: >> >> Jul 2011 Formation of the working group >> Sep 2011 First WG draft on the architecture >> Dec 2011 Submission of the architecture draft to the IESG as Informational RFC >> Dec 2011 Charter re-evaluation based on the architecture work >> Dec 2011 First WG draft on prefix configuration >> Dec 2011 First WG draft on routing >> Jan 2012 First WG draft on name resolution >> Feb 2012 First WG draft on service discovery >> Feb 2012 First WG draft on perimeter security >> Feb 2012 Start of routing related work in the relevant routing area working group, if needed >> Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC >> Apr 2012 Submission of the routing draft to the IESG as Informational RFC >> Sep 2012 Submission of the name resolution draft to the IESG as Standards Track RFC >> Nov 2012 Submission of the service discovery draft to the IESG as Standards Track RFC >> Dec 2012 Submission of the perimeter security draft to the IESG as Informational RFC >> >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >> > > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun > > From swmike@swm.pp.se Sat Jul 2 02:20:04 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175BF21F86DE for ; Sat, 2 Jul 2011 02:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMaMbE9gQqhr for ; Sat, 2 Jul 2011 02:20:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 268C921F86DD for ; Sat, 2 Jul 2011 02:20:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 00BCB9E; Sat, 2 Jul 2011 11:19:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F388C9A for ; Sat, 2 Jul 2011 11:19:58 +0200 (CEST) Date: Sat, 2 Jul 2011 11:19:58 +0200 (CEST) From: Mikael Abrahamsson To: fun@ietf.org In-Reply-To: <4E0ED065.6060706@piuha.net> Message-ID: References: <4E0AE3CF.2070504@piuha.net> <4E0ED065.6060706@piuha.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 09:20:04 -0000 On Sat, 2 Jul 2011, Jari Arkko wrote: > But back to your question. Do we need a routing protocol, or can a > single router be at the center and deal with all? I think the single > router model is a good one even when there are multiple subnets. That > being said, when you plug in. say, the first sensor-network-to-WLAN > router that can't do bridging you're in trouble. I personally think we > should build for the case where there are multiple routers, while hoping > that there is just one and that the number of subnets is either 1 or at > least a very small number. It's my opinion that while it may not happen the first 5-10 years, any home will consist of multiple routers. Any architecture we develop should in the long run handle multiple upstream providers (implying multiple provider CPEs) and multiple hierarchies of routers in the home. I also believe we need a routing protocol, plus a mechanism to do source based routing out to the correct ISP. Some of the needed mechanism might need to be developed in other WGs, but this WG can determine the need. This was discussed in quite a lot of detail on v6ops a few months back for the CPE router requirement draft, I'm sure there are discussions in other WGs touching on these topics as well. -- Mikael Abrahamsson email: swmike@swm.pp.se From jvasseur@cisco.com Sat Jul 2 04:18:15 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B7421F8A2B for ; Sat, 2 Jul 2011 04:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qalEnJeItS18 for ; Sat, 2 Jul 2011 04:18:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id C8BFB21F8A2A for ; Sat, 2 Jul 2011 04:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=16816; q=dns/txt; s=iport; t=1309605494; x=1310815094; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=QhQFuD90O3xPrYYSp7eEIcHkOKfNE327yAoYLZ7uGnw=; b=ZtPwxXUD7VMw1Qi5FlKDshWM1AeWtAKX04+MKChfOF+mdzFZe0XboUxp YkdnzTwqhxUh3DohFNNNZVrFmBFp/7CAOWyox195cAUyWSbaiqOtMVcIK F25/sNdNqZX3DxZGS9PlISsmMiyUpoBxN0D6ufqqlHmeypMqynkR9EOxR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAN39Dk6tJXG//2dsb2JhbABShEKUC44+dnetY40XkCGBK4IJgXaBDASHP494hEmHCg X-IronPort-AV: E=Sophos;i="4.65,463,1304294400"; d="scan'208";a="473905852" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2011 11:18:14 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p62BIDco006707; Sat, 2 Jul 2011 11:18:13 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Jul 2011 06:18:13 -0500 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: Sat, 2 Jul 2011 06:18:12 -0500 Message-ID: In-Reply-To: <4E0ED065.6060706@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fun] Routing ? Thread-Index: Acw4jk4Cb47IaeWfQFOrbJjomk/F7gAG20YB From: "JP Vasseur (jvasseur)" To: , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 02 Jul 2011 11:18:13.0466 (UTC) FILETIME=[BB9563A0:01CC38A9] Cc: fun@ietf.org Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 11:18:16 -0000 QWdyZWUgd2l0aCB5b3UgSmFyaS4gVHdvIG5vdGVzOg0KMSkgWW91IG1heSBoYXZlIHR3byByb3V0 ZXJzIGNvbm5lY3RlZCB0byB0aGUgV2FuIGFuZCBzdGlsbCBubyBuZWVkIHRvIHJ1biBhIHJvdXRv aW5nIHByb3RvY29sDQoyKSBUaGUgb25seSB1c2UgY2FzZSB0aGF0IEkgcmVhbGx5IGZvciBtb3N0 IGFwcHMgaXMgd2hlbiBub2RlcyBhcmUgbm90IGluIGRpcmVjdCByZWFjaA0KDQpKUCBWYXNzZXVy DQpDaXNjbyBGZWxsb3cNCg0KU2VudCBmcm9tIEJsYWNrYmVycnkNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KRnJvbTogSmFyaSBBcmtrbyBbbWFpbHRvOmphcmkuYXJra29AcGl1aGEu bmV0XQ0KU2VudDogU2F0dXJkYXksIEp1bHkgMDIsIDIwMTEgMDM6MDEgQU0NClRvOiBDdWxsZW4g SmVubmluZ3MgKGZsdWZmeSkNCkNjOiBmdW5AaWV0Zi5vcmcgPGZ1bkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbZnVuXSBSb3V0aW5nID8NCg0KQ3VsbGVuLA0KDQpHb29kIHF1ZXN0aW9uLg0KDQpU aGUgY2hhcnRlciBkb2VzIHNheSB0aGF0IG5ldyByb3V0aW5nIHByb3RvY29scyBhcmUgTk9UIGlu IHNjb3BlLCANCmhvd2V2ZXIuIFRoZXJlIG1heSBiZSBhIG5lZWQgdG8gcnVuIGEgcm91dGluZyBw cm90b2NvbCwgYnV0IGlmIHNvLCBpdCANCndvdWxkIGJlIGFuIGV4aXN0aW5nIG9uZS4NCg0KQnV0 IGJhY2sgdG8geW91ciBxdWVzdGlvbi4gRG8gd2UgbmVlZCBhIHJvdXRpbmcgcHJvdG9jb2wsIG9y IGNhbiBhIA0Kc2luZ2xlIHJvdXRlciBiZSBhdCB0aGUgY2VudGVyIGFuZCBkZWFsIHdpdGggYWxs PyBJIHRoaW5rIHRoZSBzaW5nbGUgDQpyb3V0ZXIgbW9kZWwgaXMgYSBnb29kIG9uZSBldmVuIHdo ZW4gdGhlcmUgYXJlIG11bHRpcGxlIHN1Ym5ldHMuIFRoYXQgDQpiZWluZyBzYWlkLCB3aGVuIHlv dSBwbHVnIGluLiBzYXksICB0aGUgZmlyc3Qgc2Vuc29yLW5ldHdvcmstdG8tV0xBTiANCnJvdXRl ciB0aGF0IGNhbid0IGRvIGJyaWRnaW5nIHlvdSdyZSBpbiB0cm91YmxlLiBJIHBlcnNvbmFsbHkg dGhpbmsgd2UgDQpzaG91bGQgYnVpbGQgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBtdWx0 aXBsZSByb3V0ZXJzLCB3aGlsZSBob3BpbmcgDQp0aGF0IHRoZXJlIGlzIGp1c3Qgb25lIGFuZCB0 aGF0IHRoZSBudW1iZXIgb2Ygc3VibmV0cyBpcyBlaXRoZXIgMSBvciBhdCANCmxlYXN0IGEgdmVy eSBzbWFsbCBudW1iZXIuDQoNCkphcmkNCg0KQ3VsbGVuIEplbm5pbmdzIGtpcmpvaXR0aToNCj4g SSdtIHN1cmUgdGhpcyBpcyBhIHNwZWN0YWN1bGFybHkgY2x1ZWxlc3MgcXVlc3Rpb24gYnV0LCAu Li4uIGNvdWxkIHNvbWVvbmUgc2F5IGEgYml0IG1vcmUgYWJvdXQgd2h5IHdlIG5lZWQgYSByb3V0 aW5nIHByb3RvY29sLiBJIGdldCB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3Igc21hbGwgbnVtYmVy IG9mIHN1Ym5ldHMsIGJ1dCBpdCBzZWVtcyBsaWtlIG1vc3QgdGhlIHJlcXVpcmVtZW50cyBJIGhh dmUgc2VlbiBjb3VsZCBiZSBkZWFsIHdpdGggdXNpbmcgYSBzaW5nbGUgcm91dGVyIHRoYXQgY291 bGQgcm91dGUgYmV0d2VlbiBhbGwgdGhlIHN1Ym5ldHMuIEFzIEkgc2FpZCwgY2x1ZWxlc3MgcXVl c3Rpb25zIGJ1dCBjYW4gc29tZW9uZSBmaWxsIG1lIGluIGEgYml0IG9uIHRoZSB1c2UgY2FzZXMg Zm9yIGEgcm91dGluZyBwcm90b2NvbD8gT3Igd2h5IGEgbmV3IHJvdXRpbmcgcHJvdG9jb2wgbWln aHQgYmUgbmVlZGVkLiBUaGFua3MuIA0KPg0KPg0KPg0KPiBPbiBKdW4gMjksIDIwMTEsIGF0IDI6 MzUgQU0sIEphcmkgQXJra28gd3JvdGU6DQo+DQo+ICAgDQo+PiBJIHdhbnRlZCB0byBwcm92aWRl IGFuIHVwZGF0ZSBvZiB0aGUgc2l0dWF0aW9uIHdpdGggdGhpcyB3b3JraW5nIGdyb3VwIHByb3Bv c2FsLg0KPj4NCj4+IEhPTUVORVQgaXMgYSBuZXcgd29ya2luZyBncm91cCBwcm9wb3NhbCwgYSB2 YXJpYXRpb24gb2YgdGhlIEhPTUVHQVRFL0hPTUVORVQgdGhlbWUgdGhhdCB3ZSBkaXNjdXNzZWQg bGFzdCB5ZWFyLCBidXQgdGhpcyB0aW1lIGxvb2tpbmcgYXQgaXQgZnJvbSBhIGRpZmZlcmVudCBh bmdsZS4gVGhlIG9sZCBlZmZvcnQgd2FzIG1vc3RseSBmb2N1c2VkIGFib3V0IHdoYXQgaG9tZSBn YXRld2F5cyBzaG91bGQgZG86IGZvcndhcmRpbmcsIHRyYW5zcG9ydCwgYW5kIEROUyBwcm94eWlu ZyBpc3N1ZXMuIFRoZSBuZXcgZWZmb3J0IGlzIGFib3V0IGhvbWUgbmV0d29ya3MgdGhlbXNlbHZl cywgaW4gcGFydGljdWxhciB3aGF0IGtpbmQgb2YgbmV0d29yayBhcmNoaXRlY3R1cmUgYW5kIGNv bmZpZ3VyYXRpb24gaXMgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgSVB2Ni1iYXNlZCBob21lIG5ldHdv cmtzLiBXZSB2aWV3IElQdjQtYmFzZWQgaG9tZSBuZXR3b3JrcyBhcyAiZG9uZSIgYXQgdGhpcyB0 aW1lIChvciBwZXJoYXBzIGFzICJjYW5ub3QgYmUgY2hhbmdlZCBhbnl3YXkiKS4NCj4+DQo+PiBJ IGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgZWZmb3J0IGluIHRoZSBiYWNrZ3JvdW5kIGZvciB0 aGUgbGFzdCBjb3VwbGUgb2YgbW9udGggd2l0aCBNYXJrIFRvd25zbGV5IGFuZCBvdGhlcnMsIGFu ZCBtb3JlIHB1YmxpY2x5IHNpbmNlIGVhcmx5IEp1bmUuIFRoZSBwcm9wb3NhbCBoYXMgYmVlbiBi cm91Z2h0IHRvIHRoZSBJRVNHLCBJQUIgYW5kIHNvbWUgZGlyZWN0b3JhdGVzIGZvciBkaXNjdXNz aW9uLCBhbmQgd2UndmUgYmVlbiBnb2luZyBiYWNrIGFuZCBmb3J0aCB3aGV0aGVyIHRoaXMgaXMg cmVhZHkgdG8gYmVjb21lIGEgd29ya2luZyBncm91cCBvciBuZWVkcyB0byBiZSBydW4gYXMgYSBC T0YgaW4gUXVlYmVjIENpdHkuIFRoZSBjdXJyZW50IHBsYW4gaXMgdGhhdCB0aGUgd29ya2luZyBn cm91cCBwcm9wb3NhbCBnb2VzIHRvIElFVEYtd2lkZSByZXZpZXcgdGhpcyB3ZWVrLCBhbmQgaWYg dGhlIGZlZWRiYWNrIGZyb20gdGhlIGNvbW11bml0eSwgSUFCLCBhbmQgdGhlIElFU0cgaXMgcG9z aXRpdmUsIHdlIHdpbGwgY3JlYXRlIHRoZSB3b3JraW5nIGdyb3VwIGp1c3QgaW4gdGltZSBmb3Ig dGhlIElFVEYuIE90aGVyd2lzZSwgdGhlIHNsb3QgcmVzZXJ2ZWQgaW4gdGhlIGFnZW5kYSBmb3Ig dGhlIG1lZXRpbmcgd2lsbCBiZSB1c2VkIHRvIHJ1biB0aGUgcHJvcG9zYWwgYXMgYSBCT0YuDQo+ Pg0KPj4gSW4gYW55IGNhc2UsIEkgd291bGQgbGlrZSB0byBzb2xpY2l0IGRpc2N1c3Npb24gb24g dGhpcyB0b3BpYywgYW5kIHBlcmhhcHMgc29tZSBlYXJseSBkcmFmdHMgYXMgd2VsbC4gUGxlYXNl IGNvbW1lbnQgb24gdGhlIGNoYXJ0ZXIgYXQgbGVhc3QuDQo+Pg0KPj4gTm90ZSB0aGF0IHRoZSBu ZXcgcHJvcG9zYWwgd2FzIGNhbGxlZCBGVU4gYXQgdGhlIHRpbWUgdGhhdCB3ZSBjcmVhdGVkIHRo ZSBsaXN0LiBJdCBoYXMgbm93IGJlZW4gcmVuYW1lZCBiYWNrIHRvIEhPTUVORVQgdG8gYmUgbW9y ZSBkZXNjcmlwdGl2ZS4gVGhlIGxpc3Qgd2lsbCBiZSByZW5hbWVkIHNvb24gYXMgd2VsbCAoY3Vy cmVudCBzdWJzY3JpYmVycyB3aWxsIHN0YXkpLg0KPj4NCj4+IFRoaXMgaXMgdGhlIG1vc3QgcmVj ZW50IHZlcnNpb24gb2YgdGhlIGNoYXJ0ZXIgd2Ugc2hvdWxkIGRpc2N1c3M6DQo+Pg0KPj4gSG9t ZSBOZXR3b3JrcyAoaG9tZW5ldCkNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+Pg0KPj4gQ3VycmVudCBTdGF0dXM6IFByb3Bvc2VkDQo+PiBMYXN0IEVkaXQ6IFdlZG5l c2RheSwgSnVuZSAyOXRoLCAyMDExDQo+Pg0KPj4gQ2hhaXJzOg0KPj4gVEJEDQo+Pg0KPj4gSW50 ZXJuZXQgQXJlYSBEaXJlY3RvcnM6DQo+PiBSYWxwaCBEcm9tcyA8cmRyb21zLmlldGZAZ21haWwu Y29tPg0KPj4gSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQo+Pg0KPj4gSW50ZXJu ZXQgQXJlYSBBZHZpc29yOg0KPj4gSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQo+ Pg0KPj4gUm91dGluZyBBcmVhIFRlY2huaWNhbCBBZHZpc29yOg0KPj4gVEJEDQo+Pg0KPj4gU2Vj dXJpdHkgQXJlYSBUZWNobmljYWwgQWR2aXNvcjoNCj4+IFRCRA0KPj4NCj4+IE1haWxpbmcgTGlz dHM6DQo+PiBHZW5lcmFsIERpc2N1c3Npb246IGZ1bkBpZXRmLm9yZw0KPj4gVG8gU3Vic2NyaWJl OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Z1bg0KPj4gQXJjaGl2ZTog aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Z1bg0KPj4NCj4+IERlc2NyaXB0 aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+Pg0KPj4gVGhpcyB3b3JraW5nIGdyb3VwIGZvY3VzZXMg b24gdGhlIGV2b2x2aW5nIG5ldHdvcmtpbmcgdGVjaG5vbG9neQ0KPj4gd2l0aGluIGFuZCBhbW9u ZyByZWxhdGl2ZWx5IHNtYWxsIOKAnHJlc2lkZW50aWFsIGhvbWXigJ0gbmV0d29ya3MuIEZvcg0K Pj4gZXhhbXBsZSwgYW4gb2J2aW91cyB0cmVuZCBpbiBob21lIG5ldHdvcmtpbmcgaXMgdGhlIHBy b2xpZmVyYXRpb24gb2YNCj4+IG5ldHdvcmtpbmcgdGVjaG5vbG9neSBpbiBhbiBpbmNyZWFzaW5n bHkgYnJvYWQgcmFuZ2UgYW5kIG51bWJlciBvZg0KPj4gZGV2aWNlcy4gVGhpcyBldm9sdXRpb24g aW4gc2NhbGUgYW5kIGRpdmVyc2l0eSBzZXRzIHNvbWUgcmVxdWlyZW1lbnRzDQo+PiBvbiBJRVRG IHByb3RvY29scy4gU29tZSBvZiB0aGUgcmVsZXZhbnQgdHJlbmRzIGluY2x1ZGU6DQo+Pg0KPj4g byBNdWx0aXBsZSBzZWdtZW50czogV2hpbGUgbGVzcyBjb21wbGV4IEwzLXRvcGxvZ2llcyBpbnZv bHZpbmcgYXMgZmV3DQo+PiBzdWJuZXRzIGFzIHBvc3NpYmxlIGFyZSBwcmVmZXJyZWQgaW4gaG9t ZSBuZXR3b3JrcyBmb3IgYSB2YXJpZXR5IG9mDQo+PiByZWFzb25zIGluY2x1ZGluZyBzaW1wbGVy IG1hbmFnZW1lbnQgYW5kIHNlcnZpY2UgZGlzY292ZXJ5LCB0aGUNCj4+IGludHJvZHVjdGlvbiBv ZiBtb3JlIHRoYW4gb25lIHN1Ym5ldCBpbnRvIGEgaG9tZSBuZXR3b3JrIGlzIGVub3VnaA0KPj4g dG8gYWRkIGNvbXBsZXhpdHkgdGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQsIGFuZCBtdWx0aXBs ZQ0KPj4gZGVkaWNhdGVkIHNlZ21lbnRzIGFyZSBuZWNlc3NhcnkgZm9yIHNvbWUgY2FzZXMuIEZv ciBpbnN0YW5jZSwgYQ0KPj4gY29tbW9uIGZlYXR1cmUgaW4gbW9kZXJuIGhvbWUgcm91dGVycyBp biB0aGUgYWJpbGl0eSB0byBzdXBwb3J0DQo+PiBib3RoIGd1ZXN0IGFuZCBwcml2YXRlIG5ldHdv cmsgc2VnbWVudHMuIEFsc28sIGxpbmsgbGF5ZXINCj4+IG5ldHdvcmtpbmcgdGVjaG5vbG9neSBp cyBwb2lzZWQgdG8gYmVjb21lIG1vcmUgaGV0ZXJvZ2VuZW91cywgYXMNCj4+IG5ldHdvcmtzIGJl Z2luIHRvIGVtcGxveSBib3RoIHRyYWRpdGlvbmFsIEV0aGVybmV0IHRlY2hub2xvZ3kgYW5kDQo+ PiBsaW5rIGxheWVycyBkZXNpZ25lZCBmb3IgbG93LXBvd2VyZWQgc2Vuc29yIG5ldHdvcmtzLiBG aW5hbGx5LA0KPj4gc2ltaWxhciBuZWVkcyBmb3Igc2VnbWVudGF0aW9uIG1heSBvY2N1ciBpbiBv dGhlciBjYXNlcywgc3VjaCBhcw0KPj4gc2VwYXJhdGluZyBidWlsZGluZyBjb250cm9sIG9yIGNv cnBvcmF0ZSBleHRlbnNpb25zIGZyb20gdGhlDQo+PiBJbnRlcm5ldCBhY2Nlc3MgbmV0d29yay4g RGlmZmVyZW50IHNlZ21lbnRzIG1heSBiZSBhc3NvY2lhdGVkIHdpdGgNCj4+IHN1Ym5ldHMgdGhh dCBoYXZlIGRpZmZlcmVudCByb3V0aW5nIGFuZCBzZWN1cml0eSBwb2xpY2llcy4NCj4+DQo+PiBv IFNlcnZpY2UgcHJvdmlkZXJzIGFyZSBkZXBsb3lpbmcgSVB2NiwgYW5kIHN1cHBvcnQgZm9yIElQ djYgaXMNCj4+IGluY3JlYXNpbmdseSBhdmFpbGFibGUgaW4gaG9tZSBnYXRld2F5IGRldmljZXMu IFdoaWxlIElQdjYgcmVzZW1ibGVzDQo+PiBJUHY0IGluIG1hbnkgd2F5cywgaXQgY2hhbmdlcyBh ZGRyZXNzIGFsbG9jYXRpb24gcHJpbmNpcGxlcyBhbmQgYWxsb3dzDQo+PiBkaXJlY3QgSVAgYWRk cmVzc2FiaWxpdHkgYW5kIHJvdXRpbmcgdG8gZGV2aWNlcyBpbiB0aGUgaG9tZSBmcm9tIHRoZQ0K Pj4gSW50ZXJuZXQuIFRoaXMgaXMgYSBwcm9taXNpbmcgYXJlYSBpbiBJUHY2IHRoYXQgaGFzIHBy b3ZlZCBjaGFsbGVuZ2luZw0KPj4gaW4gSVB2NCB3aXRoIHRoZSBwcm9saWZlcmF0aW9uIG9mIE5B VC4NCj4+DQo+PiBvIEVuZC10by1lbmQgY29tbXVuaWNhdGlvbiBpcyBib3RoIGFuIG9wcG9ydHVu aXR5IGFuZCBhIGNvbmNlcm4gYXMgaXQNCj4+IGVuYWJsZXMgbmV3IGFwcGxpY2F0aW9ucyBidXQg YWxzbyBleHBvc2VzIG5vZGVzIGluIHRoZSBpbnRlcm5hbA0KPj4gbmV0d29ya3MgdG8gcmVjZWlw dCBvZiB1bndhbnRlZCB0cmFmZmljIGZyb20gdGhlIEludGVybmV0LiBGaXJld2FsbHMNCj4+IHRo YXQgcmVzdHJpY3QgaW5jb21pbmcgY29ubmVjdGlvbnMgbWF5IGJlIHVzZWQgdG8gcHJldmVudCBl eHBvc3VyZSwNCj4+IGhvd2V2ZXIsIHRoaXMgcmVkdWNlcyB0aGUgZWZmaWNhY3kgb2YgZW5kLXRv LWVuZCBjb25uZWN0aXZpdHkgdGhhdA0KPj4gSVB2NiBoYXMgdGhlIHBvdGVudGlhbCB0byByZXN0 b3JlLg0KPj4NCj4+IEhvbWUgbmV0d29ya3MgbmVlZCB0byBwcm92aWRlIHRoZSB0b29scyB0byBo YW5kbGUgdGhlc2Ugc2l0dWF0aW9ucyBpbg0KPj4gYSBtYW5uZXIgYWNjZXNzaWJsZSB0byBhbGwg dXNlcnMgb2YgaG9tZSBuZXR3b3Jrcy4gTWFudWFsDQo+PiBjb25maWd1cmF0aW9uIGlzIHJhcmVs eSwgaWYgYXQgYWxsLCBwb3NzaWJsZS4gVGhlIHB1cnBvc2Ugb2YgdGhpcw0KPj4gd29ya2luZyBn cm91cCBpcyB0byBmb2N1cyBvbiB0aGlzIGV2b2x1dGlvbiwgaW4gcGFydGljdWxhciBhcyBpdA0K Pj4gYWRkcmVzc2VzIHRoZSBpbnRyb2R1Y3Rpb24gb2YgSVB2NiwgYnkgZGV2ZWxvcGluZyBhbiBh cmNoaXRlY3R1cmUNCj4+IGFkZHJlc3NpbmcgdGhpcyBmdWxsIHNjb3BlIG9mIHJlcXVpcmVtZW50 czoNCj4+DQo+PiBvIHByZWZpeCBjb25maWd1cmF0aW9uIGZvciByb3V0ZXJzDQo+PiBvIG1hbmFn aW5nIHJvdXRpbmcNCj4+IG8gbmFtZSByZXNvbHV0aW9uDQo+PiBvIHNlcnZpY2UgZGlzY292ZXJ5 DQo+PiBvIG5ldHdvcmsgc2VjdXJpdHkNCj4+DQo+PiBUaGUgdGFzayBvZiB0aGUgZ3JvdXAgaXMg dG8gcHJvZHVjZSBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgdGhhdA0KPj4gb3V0bGluZXMgaG93 IHRvIGNvbnN0cnVjdCBob21lIG5ldHdvcmtzIGludm9sdmluZyBtdWx0aXBsZSByb3V0ZXJzIGFu ZA0KPj4gc3VibmV0cy4gVGhpcyBkb2N1bWVudCBpcyBleHBlY3RlZCB0byBhcHBseSB0aGUgSVB2 NiBhZGRyZXNzaW5nDQo+PiBhcmNoaXRlY3R1cmUsIHByZWZpeCBkZWxlZ2F0aW9uLCBnbG9iYWwg YW5kIFVMQSBhZGRyZXNzZXMsIHNvdXJjZQ0KPj4gYWRkcmVzcyBzZWxlY3Rpb24gcnVsZXMgYW5k IG90aGVyIGV4aXN0aW5nIGNvbXBvbmVudHMgb2YgdGhlIElQdjYNCj4+IGFyY2hpdGVjdHVyZS4g VGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzaG91bGQgZHJpdmUgd2hhdCBwcm90b2NvbHMNCj4+ IGNoYW5nZXMsIGlmIGFueSwgYXJlIG5lY2Vzc2FyeS4gU3BlY2lmaWMgcHJvdG9jb2wgd29yayBk ZXNjcmliZWQgYmVsb3cNCj4+IGlzIGV4cGVjdGVkIHRvIGJlIHdpdGhpbiB0aGUgc2NvcGUgb2Yg dGhlIHdvcmtpbmcgZ3JvdXAgb25lIHRoZQ0KPj4gYXJjaGl0ZWN0dXJlIHdvcmsgaXMgY29tcGxl dGUuIEhvd2V2ZXIsIHRoZSBncm91cCBpcyByZXF1aXJlZCB0bw0KPj4gcmV2aWV3IGl0cyBjaGFy dGVyIGFuZCBtaWxlc3RvbmVzIHdpdGggdGhlIElFU0cgYW5kIElFVEYgY29tbXVuaXR5DQo+PiBi ZWZvcmUgc3VibWl0dGluZyBkb2N1bWVudHMgdGhhdCBtYWtlIHByb3RvY29sIGNoYW5nZXMuIEl0 IGlzIGV4cGVjdGVkDQo+PiB0aGF0IHRoZSBncm91cCBoYXMgdG8gZGlzY3VzcyBzb21lIG9mIHRo ZSBiZWxvdyBzb2x1dGlvbnMsIGhvd2V2ZXIsIGluDQo+PiBvcmRlciB0byBjb21wbGV0ZSB0aGUg YXJjaGl0ZWN0dXJlIHdvcmsuDQo+Pg0KPj4gVGhlIGdyb3VwIHdpbGwgYXBwbHkgZXhpc3Rpbmcg cHJvdG9jb2xzIHRvIGhhbmRsZSB0aGUgZml2ZQ0KPj4gcmVxdWlyZW1lbnRzIGFib3ZlLiBGb3Ig cHJlZml4IGNvbmZpZ3VyYXRpb24sIGV4aXN0aW5nIHByb3RvY29scyBhcmUNCj4+IGxpa2VseSBz dWZmaWNpZW50LCBhbmQgYXQgd29yc3QgbWF5IG5lZWQgc29tZSBzbWFsbCBlbmhhbmNlbWVudHMs IHN1Y2gNCj4+IGFzIG5ldyBvcHRpb25zLiBGb3IgYXV0b21hdGljIHJvdXRpbmcsIGl0IGlzIGV4 cGVjdGVkIHRoYXQgZXhpc3RpbmcNCj4+IHJvdXRpbmcgcHJvdG9jb2xzIGNhbiBiZSB1c2VkIGFz IGlzLCBob3dldmVyLCBhIG5ldyBtZWNoYW5pc20gbWF5IGJlDQo+PiBuZWVkZWQgaW4gb3JkZXIg dG8gdHVybiBhIHNlbGVjdGVkIHByb3RvY29sIG9uIGJ5IGRlZmF1bHQuIEZvciBuYW1lDQo+PiBy ZXNvbHV0aW9uIGFuZCBzZXJ2aWNlIGRpc2NvdmVyeSwgZXh0ZW5zaW9ucyB0byBleGlzdGluZw0K Pj4gbXVsdGljYXN0LWJhc2VkIG5hbWUgcmVzb2x1dGlvbiBwcm90b2NvbHMgYXJlIG5lZWRlZCB0 byBlbmFibGUgdGhlbSB0bw0KPj4gd29yayBhY3Jvc3Mgc3VibmV0cy4NCj4+DQo+PiBGb3IgbmV0 d29yayBzZWN1cml0eSwgdGhlIGdyb3VwIHNoYWxsIGRvY3VtZW50IHRoZSBjb25jZXB0IG9mDQo+ PiAiYWR2YW5jZWQgc2VjdXJpdHkiIGFzIGEgZnVydGhlciBkZXZlbG9wbWVudCBvZiAic2ltcGxl IHNlY3VyaXR5IiBmcm9tDQo+PiBSRkMgNjA5Mi4gVGhlIG1haW4gZ29hbCBvZiB0aGlzIHdvcmsg aXMgdG8gZW5hYmxlIGEgc2VjdXJpdHkgcG9saWN5DQo+PiB0aGF0IGFkYXB0cyB0byBJUHY2IHRo cmVhdHMgYXMgdGhleSBlbWVyZ2UsIHRha2luZyBpbnRvIGFjY291bnQgbm90DQo+PiBvbmx5IHRy YWZmaWMgZnJvbSB0aGUgSW50ZXJuZXQgYXQgbGFyZ2UsIGJ1dCB3aXRoaW4gYW5kIGxlYXZpbmcg dGhlDQo+PiBob21lIG5ldHdvcmsgaXRzZWxmLg0KPj4NCj4+IEl0IGlzIGV4cGVjdGVkIHRoYXQg dGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBzZXQgb2YgcHJvdG9jb2wNCj4+IHNwZWNp ZmljYXRpb25zIHRvIGFjY29tcGxpc2ggdGhlIGZpdmUgcmVxdWlyZW1lbnRzIGZyb20NCj4+IGFi b3ZlLiBIb3dldmVyLCBpdCBpcyBub3QgaW4gdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3Vw IHRvIGRlZmluZQ0KPj4gZW50aXJlbHkgbmV3IHJvdXRpbmcgcHJvdG9jb2xzIG9yIGFkZHJlc3Mg YWxsb2NhdGlvbiBwcm90b2NvbHMuIEFzDQo+PiBub3RlZCwgYWRkaXRpb25hbCBvcHRpb25zIG9y IG90aGVyIHNtYWxsIGV4dGVuc2lvbnMgbWF5IGJlIG5lY2Vzc2FyeQ0KPj4gdG8gdXNlIHRoZSBl eGlzdGluZyBwcm90b2NvbHMgaW4gdGhlc2UgbmV3IGNvbmZpZ3VyYXRpb24gdGFza3MuIFRoZQ0K Pj4gd29ya2luZyBncm91cCBzaGFsbCBhbHNvIG5vdCBtYWtlIGFueSBjaGFuZ2VzIHRvIElQdjYg cHJvdG9jb2xzIG9yDQo+PiBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZS4gUHJlZml4IGNvbmZpZ3Vy YXRpb24sIHJvdXRpbmcsIGFuZCBzZWN1cml0eQ0KPj4gcmVsYXRlZCB3b3JrIHNoYWxsIG5vdCBj YXVzZSBhbnkgY2hhbmdlcyB0aGF0IGFyZSBub3QgYmFja3dhcmRzDQo+PiBjb21wYXRpYmxlIHRv IGV4aXN0aW5nIElQdjYgaG9zdHMuIFRoZXJlIG1heSBiZSBob3N0IHZpc2libGUgY2hhbmdlcw0K Pj4gaW4gdGhlIHdvcmsgb24gbmFtaW5nIGFuZCBkaXNjb3ZlcnkgcHJvdG9jb2xzLCBob3dldmVy LiBJbiBpdHMgZGVzaWduLA0KPj4gdGhlIHdvcmtpbmcgZ3JvdXAgc2hhbGwgYWxzbyBjb25zaWRl ciBzZWN1cml0eSBhc3BlY3RzIGFuZCB0aGUgaW1wYWN0DQo+PiBvbiBtYW5hZ2VhYmlsaXR5LiBU aGUgbWFpbiBmb2N1cyBvZiB0aGUgd29ya2luZyBncm91cCBpcyBob21lDQo+PiBuZXR3b3Jrcywg YnV0IHRoZSBncm91cCdzIHJlc3VsdHMgbWF5IGFsc28gZmluZCBhcHBsaWNhdGlvbnMgaW4gb3Ro ZXINCj4+IHNtYWxsIG5ldHdvcmtzLg0KPj4NCj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgbGlh aXNlIHdpdGggdGhlIHJlbGV2YW50IElFVEYgd29ya2luZw0KPj4gZ3JvdXBzLiBJbiBwYXJ0aWN1 bGFyLCB0aGUgZ3JvdXAgc2hvdWxkIHdvcmsgY2xvc2VseSB3aXRoIHRoZSBWNk9QUw0KPj4gd29y a2luZyBncm91cCwgcmV2aWV3IGFueSB1c2Ugb3IgZXh0ZW5zaW9uIG9mIERIQ1Agd2l0aCB0aGUg REhDDQo+PiB3b3JraW5nIGdyb3VwLCBhbmQgd29yayB3aXRoIGFkZGl0aW9uYWwgRE5TIHJlcXVp cmVtZW50cyB3aXRoIHRoZQ0KPj4gRE5TRVhUIGFuZCBETlNPUCB3b3JraW5nIGdyb3Vwcy4gSWYg aXQgdHVybnMgb3V0IHRoYXQgYWRkaXRpb25hbA0KPj4gb3B0aW9ucyBhcmUgbmVlZGVkIGZvciBh IHJvdXRpbmcgcHJvdG9jb2wsIHRoZXkgd2lsbCBiZSBkZXZlbG9wZWQgaW4NCj4+IHRoZSBhcHBy b3ByaWF0ZSBSb3V0aW5nIEFyZWEgd29ya2luZyBncm91cCwgd2l0aCB0aGUgSE9NRU5FVCB3b3Jr aW5nDQo+PiBncm91cCBwcm92aWRpbmcgdGhlIGFyY2hpdGVjdHVyZSBhbmQgcmVxdWlyZW1lbnRz IGZvciBzdWNoDQo+PiBlbmhhbmNlbWVudHMuIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWxzbyBs aWFzZSB3aXRoIGV4dGVybmFsDQo+PiBzdGFuZGFyZHMgYm9kaWVzIHdoZXJlIGl0IGlzIGV4cGVj dGVkIHRoYXQgdGhlcmUgYXJlIG5vcm1hdGl2ZQ0KPj4gZGVwZW5kZW5jaWVzIGJldHdlZW4gdGhl IHNwZWNpZmljYXRpb25zIG9mIHRoZSB0d28gYm9kaWVzLg0KPj4gSXQgaXMgZXhwZWN0ZWQgdGhh dCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRlZmluaXRpb24gc3RhZ2UgbGlhaXNpbmcNCj4+IHdpdGgg dGhlIEJyb2FkYmFuZCBGb3J1bSwgRExOQSwgYW5kIFVQblAgRm9ydW0gaXMgbmVjZXNzYXJ5Lg0K Pj4NCj4+IE1pbGVzdG9uZXM6DQo+Pg0KPj4gSnVsIDIwMTEgRm9ybWF0aW9uIG9mIHRoZSB3b3Jr aW5nIGdyb3VwDQo+PiBTZXAgMjAxMSBGaXJzdCBXRyBkcmFmdCBvbiB0aGUgYXJjaGl0ZWN0dXJl DQo+PiBEZWMgMjAxMSBTdWJtaXNzaW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgdG8gdGhl IElFU0cgYXMgSW5mb3JtYXRpb25hbCBSRkMNCj4+IERlYyAyMDExIENoYXJ0ZXIgcmUtZXZhbHVh dGlvbiBiYXNlZCBvbiB0aGUgYXJjaGl0ZWN0dXJlIHdvcmsNCj4+IERlYyAyMDExIEZpcnN0IFdH IGRyYWZ0IG9uIHByZWZpeCBjb25maWd1cmF0aW9uDQo+PiBEZWMgMjAxMSBGaXJzdCBXRyBkcmFm dCBvbiByb3V0aW5nDQo+PiBKYW4gMjAxMiBGaXJzdCBXRyBkcmFmdCBvbiBuYW1lIHJlc29sdXRp b24NCj4+IEZlYiAyMDEyIEZpcnN0IFdHIGRyYWZ0IG9uIHNlcnZpY2UgZGlzY292ZXJ5DQo+PiBG ZWIgMjAxMiBGaXJzdCBXRyBkcmFmdCBvbiBwZXJpbWV0ZXIgc2VjdXJpdHkNCj4+IEZlYiAyMDEy IFN0YXJ0IG9mIHJvdXRpbmcgcmVsYXRlZCB3b3JrIGluIHRoZSByZWxldmFudCByb3V0aW5nIGFy ZWEgd29ya2luZyBncm91cCwgaWYgbmVlZGVkDQo+PiBNYXIgMjAxMiBTdWJtaXNzaW9uIG9mIHRo ZSBwcmVmaXggY29uZmlndXJhdGlvbiBkcmFmdCB0byB0aGUgSUVTRyBhcyBTdGFuZGFyZHMgVHJh Y2sgUkZDDQo+PiBBcHIgMjAxMiBTdWJtaXNzaW9uIG9mIHRoZSByb3V0aW5nIGRyYWZ0IHRvIHRo ZSBJRVNHIGFzIEluZm9ybWF0aW9uYWwgUkZDDQo+PiBTZXAgMjAxMiBTdWJtaXNzaW9uIG9mIHRo ZSBuYW1lIHJlc29sdXRpb24gZHJhZnQgdG8gdGhlIElFU0cgYXMgU3RhbmRhcmRzIFRyYWNrIFJG Qw0KPj4gTm92IDIwMTIgU3VibWlzc2lvbiBvZiB0aGUgc2VydmljZSBkaXNjb3ZlcnkgZHJhZnQg dG8gdGhlIElFU0cgYXMgU3RhbmRhcmRzIFRyYWNrIFJGQw0KPj4gRGVjIDIwMTIgU3VibWlzc2lv biBvZiB0aGUgcGVyaW1ldGVyIHNlY3VyaXR5IGRyYWZ0IHRvIHRoZSBJRVNHIGFzIEluZm9ybWF0 aW9uYWwgUkZDDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IGZ1biBtYWlsaW5nIGxpc3QNCj4+IGZ1bkBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mdW4NCj4+ICAgICANCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZnVuIG1haWxpbmcg bGlzdA0KPiBmdW5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9mdW4NCj4NCj4gICANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmZ1biBtYWlsaW5nIGxpc3QNCmZ1bkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mdW4NCg== From rdroms@cisco.com Sat Jul 2 04:29:51 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071CA21F8914 for ; Sat, 2 Jul 2011 04:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fD6vBZR+b7G for ; Sat, 2 Jul 2011 04:29:49 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 6C63921F8A16 for ; Sat, 2 Jul 2011 04:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=17370; q=dns/txt; s=iport; t=1309606186; x=1310815786; h=subject:references:from:in-reply-to:message-id:date:to: content-transfer-encoding:mime-version; bh=bTW0LFhdebCmqv7Y0x0K2vfZ2ckd6Eq+kfL097pIx4s=; b=hjsHhMVAPVOgBn1TgsOBnSFWO60m3xWx6J+KDPVl9pJPPeUcHQNyruso rsXKd1O6ZdyrWuyMciznwgzluj57/fCU7IN0DDerY4JBeDXNAYX4UHPWF GU66hKNAm98jtLoIlrBgbMgkb+xmdndFbHiFGNtQvyD/gkrXJB6Hmwy9M 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIGACoAD06tJV2Z/2dsb2JhbABShEKiSXQCd4h6pFqNF5AhgSuCCYF2gQwEkjaFAYRJgneEEQ X-IronPort-AV: E=Sophos;i="4.65,463,1304294400"; d="scan'208";a="390525508" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 02 Jul 2011 11:29:45 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p62BTjZu014475 for ; Sat, 2 Jul 2011 11:29:45 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Jul 2011 06:29:45 -0500 Received: from 144.254.231.94 ([144.254.231.94]) by XMB-RCD-202.cisco.com ([72.163.62.209]) with Microsoft Exchange Server HTTP-DAV ; Sat, 2 Jul 2011 11:29:45 +0000 References: <4E0AE3CF.2070504@piuha.net> <4E0ED065.6060706@piuha.net> From: "Ralph Droms (rdroms)" Content-Type: text/plain; charset="utf-8" In-Reply-To: <4E0ED065.6060706@piuha.net> thread-topic: [fun] Routing ? thread-index: Acw4q1eAZWSwlEYwSD2oGuWGys+A1A== Message-ID: Date: Sat, 2 Jul 2011 07:30:55 -0400 To: Content-Transfer-Encoding: base64 MIME-Version: 1.0 (iPad Mail 8J3) X-OriginalArrivalTime: 02 Jul 2011 11:29:45.0125 (UTC) FILETIME=[57D82D50:01CC38AB] Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 11:29:51 -0000 T24gSnVsIDIsIDIwMTEsIGF0IDQ6MDEgQU0sICJKYXJpIEFya2tvIiA8amFyaS5hcmtrb0BwaXVo YS5uZXQ+IHdyb3RlOg0KDQo+IEN1bGxlbiwNCj4gDQo+IEdvb2QgcXVlc3Rpb24uDQo+IA0KPiBU aGUgY2hhcnRlciBkb2VzIHNheSB0aGF0IG5ldyByb3V0aW5nIHByb3RvY29scyBhcmUgTk9UIGlu IHNjb3BlLCBob3dldmVyLiBUaGVyZSBtYXkgYmUgYSBuZWVkIHRvIHJ1biBhIHJvdXRpbmcgcHJv dG9jb2wsIGJ1dCBpZiBzbywgaXQgd291bGQgYmUgYW4gZXhpc3Rpbmcgb25lLg0KPiANCj4gQnV0 IGJhY2sgdG8geW91ciBxdWVzdGlvbi4gRG8gd2UgbmVlZCBhIHJvdXRpbmcgcHJvdG9jb2wsIG9y IGNhbiBhIHNpbmdsZSByb3V0ZXIgYmUgYXQgdGhlIGNlbnRlciBhbmQgZGVhbCB3aXRoIGFsbD8g SSB0aGluayB0aGUgc2luZ2xlIHJvdXRlciBtb2RlbCBpcyBhIGdvb2Qgb25lIGV2ZW4gd2hlbiB0 aGVyZSBhcmUgbXVsdGlwbGUgc3VibmV0cy4gVGhhdCBiZWluZyBzYWlkLCB3aGVuIHlvdSBwbHVn IGluLiBzYXksICB0aGUgZmlyc3Qgc2Vuc29yLW5ldHdvcmstdG8tV0xBTiByb3V0ZXIgdGhhdCBj YW4ndCBkbyBicmlkZ2luZyB5b3UncmUgaW4gdHJvdWJsZS4gSSBwZXJzb25hbGx5IHRoaW5rIHdl IHNob3VsZCBidWlsZCBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIHJvdXRl cnMsIHdoaWxlIGhvcGluZyB0aGF0IHRoZXJlIGlzIGp1c3Qgb25lIGFuZCB0aGF0IHRoZSBudW1i ZXIgb2Ygc3VibmV0cyBpcyBlaXRoZXIgMSBvciBhdCBsZWFzdCBhIHZlcnkgc21hbGwgbnVtYmVy Lg0KDQpaaWdCZWUgQWxsaWFuY2UgaXMgZGV2ZWxvcGluZyBpdCdzIHNwZWNpZmljYXRpb25zIHRv IGFjY29tbW9kYXRlIGV4YWN0bHkgdGhlIHVzZSBjYXNlIEphcmkgZGVzY3JpYmVzLiAgWkEgYW50 aWNpcGF0ZXMgYSBkZXBsb3ltZW50IHNjZW5hcmlvIGluIHdoaWNoIGEgSG9tZSBFbmVyZ3kgQ29u dHJvbGxlciAoSEVDKSBhY3RzIGFzIGEgcm91dGVyICh0aGUgdGVjaG5vbG9naWVzIGFyZSB1bmJy aWRnZWFibGUpIGJldHdlZW4gdGhlIGhvbWUgbmV0d29yayBhbmQgYW4gSUVFRSA4MDIuMTUuNCBz dWJuZXQuDQoNCk9uZSByb3V0ZXIgd291bGQgYmUgYmV0dGVyLCBidXQgd2UgaGF2ZSB0aGlzIHJl YWwgYW5kIGN1cnJlbnQgdXNlIGNhc2UgZm9yIG1vcmUgdGhhbiBvbmUsIHNvIHdlIG5lZWQgdG8g Y29uc2lkZXIgaXQuICBTcGVjaWZpYyBzb2x1dGlvbnMgaGF2ZSAob2YgY291cnNlKSBub3QgYmVl biBkaXNjdXNzZWQ7IHNvbWUgYXJjaGl0ZWN0dXJlcyBhbmQgdXNlIGNhc2VzIG1pZ2h0IG5vdCBu ZWVkIGEgInJvdXRpbmcgcHJvdG9jb2wiIGF0IGFsbCB0byBhbGxvdyBmb3IgbXVsdGlwbGUgcm91 dGVycy4NCg0KLSBSYWxwaA0KDQo+IA0KPiBKYXJpDQo+IA0KPiBDdWxsZW4gSmVubmluZ3Mga2ly am9pdHRpOg0KPj4gSSdtIHN1cmUgdGhpcyBpcyBhIHNwZWN0YWN1bGFybHkgY2x1ZWxlc3MgcXVl c3Rpb24gYnV0LCAuLi4uIGNvdWxkIHNvbWVvbmUgc2F5IGEgYml0IG1vcmUgYWJvdXQgd2h5IHdl IG5lZWQgYSByb3V0aW5nIHByb3RvY29sLiBJIGdldCB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3Ig c21hbGwgbnVtYmVyIG9mIHN1Ym5ldHMsIGJ1dCBpdCBzZWVtcyBsaWtlIG1vc3QgdGhlIHJlcXVp cmVtZW50cyBJIGhhdmUgc2VlbiBjb3VsZCBiZSBkZWFsIHdpdGggdXNpbmcgYSBzaW5nbGUgcm91 dGVyIHRoYXQgY291bGQgcm91dGUgYmV0d2VlbiBhbGwgdGhlIHN1Ym5ldHMuIEFzIEkgc2FpZCwg Y2x1ZWxlc3MgcXVlc3Rpb25zIGJ1dCBjYW4gc29tZW9uZSBmaWxsIG1lIGluIGEgYml0IG9uIHRo ZSB1c2UgY2FzZXMgZm9yIGEgcm91dGluZyBwcm90b2NvbD8gT3Igd2h5IGEgbmV3IHJvdXRpbmcg cHJvdG9jb2wgbWlnaHQgYmUgbmVlZGVkLiBUaGFua3MuIA0KPj4gDQo+PiANCj4+IE9uIEp1biAy OSwgMjAxMSwgYXQgMjozNSBBTSwgSmFyaSBBcmtrbyB3cm90ZToNCj4+IA0KPj4gIA0KPj4+IEkg d2FudGVkIHRvIHByb3ZpZGUgYW4gdXBkYXRlIG9mIHRoZSBzaXR1YXRpb24gd2l0aCB0aGlzIHdv cmtpbmcgZ3JvdXAgcHJvcG9zYWwuDQo+Pj4gDQo+Pj4gSE9NRU5FVCBpcyBhIG5ldyB3b3JraW5n IGdyb3VwIHByb3Bvc2FsLCBhIHZhcmlhdGlvbiBvZiB0aGUgSE9NRUdBVEUvSE9NRU5FVCB0aGVt ZSB0aGF0IHdlIGRpc2N1c3NlZCBsYXN0IHllYXIsIGJ1dCB0aGlzIHRpbWUgbG9va2luZyBhdCBp dCBmcm9tIGEgZGlmZmVyZW50IGFuZ2xlLiBUaGUgb2xkIGVmZm9ydCB3YXMgbW9zdGx5IGZvY3Vz ZWQgYWJvdXQgd2hhdCBob21lIGdhdGV3YXlzIHNob3VsZCBkbzogZm9yd2FyZGluZywgdHJhbnNw b3J0LCBhbmQgRE5TIHByb3h5aW5nIGlzc3Vlcy4gVGhlIG5ldyBlZmZvcnQgaXMgYWJvdXQgaG9t ZSBuZXR3b3JrcyB0aGVtc2VsdmVzLCBpbiBwYXJ0aWN1bGFyIHdoYXQga2luZCBvZiBuZXR3b3Jr IGFyY2hpdGVjdHVyZSBhbmQgY29uZmlndXJhdGlvbiBpcyBuZWNlc3NhcnkgdG8gc3VwcG9ydCBJ UHY2LWJhc2VkIGhvbWUgbmV0d29ya3MuIFdlIHZpZXcgSVB2NC1iYXNlZCBob21lIG5ldHdvcmtz IGFzICJkb25lIiBhdCB0aGlzIHRpbWUgKG9yIHBlcmhhcHMgYXMgImNhbm5vdCBiZSBjaGFuZ2Vk IGFueXdheSIpLg0KPj4+IA0KPj4+IEkgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhpcyBlZmZvcnQg aW4gdGhlIGJhY2tncm91bmQgZm9yIHRoZSBsYXN0IGNvdXBsZSBvZiBtb250aCB3aXRoIE1hcmsg VG93bnNsZXkgYW5kIG90aGVycywgYW5kIG1vcmUgcHVibGljbHkgc2luY2UgZWFybHkgSnVuZS4g VGhlIHByb3Bvc2FsIGhhcyBiZWVuIGJyb3VnaHQgdG8gdGhlIElFU0csIElBQiBhbmQgc29tZSBk aXJlY3RvcmF0ZXMgZm9yIGRpc2N1c3Npb24sIGFuZCB3ZSd2ZSBiZWVuIGdvaW5nIGJhY2sgYW5k IGZvcnRoIHdoZXRoZXIgdGhpcyBpcyByZWFkeSB0byBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIG9y IG5lZWRzIHRvIGJlIHJ1biBhcyBhIEJPRiBpbiBRdWViZWMgQ2l0eS4gVGhlIGN1cnJlbnQgcGxh biBpcyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIHByb3Bvc2FsIGdvZXMgdG8gSUVURi13aWRlIHJl dmlldyB0aGlzIHdlZWssIGFuZCBpZiB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgY29tbXVuaXR5LCBJ QUIsIGFuZCB0aGUgSUVTRyBpcyBwb3NpdGl2ZSwgd2Ugd2lsbCBjcmVhdGUgdGhlIHdvcmtpbmcg Z3JvdXAganVzdCBpbiB0aW1lIGZvciB0aGUgSUVURi4gT3RoZXJ3aXNlLCB0aGUgc2xvdCByZXNl cnZlZCBpbiB0aGUgYWdlbmRhIGZvciB0aGUgbWVldGluZyB3aWxsIGJlIHVzZWQgdG8gcnVuIHRo ZSBwcm9wb3NhbCBhcyBhIEJPRi4NCj4+PiANCj4+PiBJbiBhbnkgY2FzZSwgSSB3b3VsZCBsaWtl IHRvIHNvbGljaXQgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLCBhbmQgcGVyaGFwcyBzb21lIGVh cmx5IGRyYWZ0cyBhcyB3ZWxsLiBQbGVhc2UgY29tbWVudCBvbiB0aGUgY2hhcnRlciBhdCBsZWFz dC4NCj4+PiANCj4+PiBOb3RlIHRoYXQgdGhlIG5ldyBwcm9wb3NhbCB3YXMgY2FsbGVkIEZVTiBh dCB0aGUgdGltZSB0aGF0IHdlIGNyZWF0ZWQgdGhlIGxpc3QuIEl0IGhhcyBub3cgYmVlbiByZW5h bWVkIGJhY2sgdG8gSE9NRU5FVCB0byBiZSBtb3JlIGRlc2NyaXB0aXZlLiBUaGUgbGlzdCB3aWxs IGJlIHJlbmFtZWQgc29vbiBhcyB3ZWxsIChjdXJyZW50IHN1YnNjcmliZXJzIHdpbGwgc3RheSku DQo+Pj4gDQo+Pj4gVGhpcyBpcyB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiBvZiB0aGUgY2hhcnRl ciB3ZSBzaG91bGQgZGlzY3VzczoNCj4+PiANCj4+PiBIb21lIE5ldHdvcmtzIChob21lbmV0KQ0K Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gDQo+Pj4gQ3VycmVu dCBTdGF0dXM6IFByb3Bvc2VkDQo+Pj4gTGFzdCBFZGl0OiBXZWRuZXNkYXksIEp1bmUgMjl0aCwg MjAxMQ0KPj4+IA0KPj4+IENoYWlyczoNCj4+PiBUQkQNCj4+PiANCj4+PiBJbnRlcm5ldCBBcmVh IERpcmVjdG9yczoNCj4+PiBSYWxwaCBEcm9tcyA8cmRyb21zLmlldGZAZ21haWwuY29tPg0KPj4+ IEphcmkgQXJra28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KPj4+IA0KPj4+IEludGVybmV0IEFy ZWEgQWR2aXNvcjoNCj4+PiBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCj4+PiAN Cj4+PiBSb3V0aW5nIEFyZWEgVGVjaG5pY2FsIEFkdmlzb3I6DQo+Pj4gVEJEDQo+Pj4gDQo+Pj4g U2VjdXJpdHkgQXJlYSBUZWNobmljYWwgQWR2aXNvcjoNCj4+PiBUQkQNCj4+PiANCj4+PiBNYWls aW5nIExpc3RzOg0KPj4+IEdlbmVyYWwgRGlzY3Vzc2lvbjogZnVuQGlldGYub3JnDQo+Pj4gVG8g U3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Z1bg0KPj4+ IEFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9mdW4NCj4+PiAN Cj4+PiBEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOg0KPj4+IA0KPj4+IFRoaXMgd29ya2lu ZyBncm91cCBmb2N1c2VzIG9uIHRoZSBldm9sdmluZyBuZXR3b3JraW5nIHRlY2hub2xvZ3kNCj4+ PiB3aXRoaW4gYW5kIGFtb25nIHJlbGF0aXZlbHkgc21hbGwg4oCccmVzaWRlbnRpYWwgaG9tZeKA nSBuZXR3b3Jrcy4gRm9yDQo+Pj4gZXhhbXBsZSwgYW4gb2J2aW91cyB0cmVuZCBpbiBob21lIG5l dHdvcmtpbmcgaXMgdGhlIHByb2xpZmVyYXRpb24gb2YNCj4+PiBuZXR3b3JraW5nIHRlY2hub2xv Z3kgaW4gYW4gaW5jcmVhc2luZ2x5IGJyb2FkIHJhbmdlIGFuZCBudW1iZXIgb2YNCj4+PiBkZXZp Y2VzLiBUaGlzIGV2b2x1dGlvbiBpbiBzY2FsZSBhbmQgZGl2ZXJzaXR5IHNldHMgc29tZSByZXF1 aXJlbWVudHMNCj4+PiBvbiBJRVRGIHByb3RvY29scy4gU29tZSBvZiB0aGUgcmVsZXZhbnQgdHJl bmRzIGluY2x1ZGU6DQo+Pj4gDQo+Pj4gbyBNdWx0aXBsZSBzZWdtZW50czogV2hpbGUgbGVzcyBj b21wbGV4IEwzLXRvcGxvZ2llcyBpbnZvbHZpbmcgYXMgZmV3DQo+Pj4gc3VibmV0cyBhcyBwb3Nz aWJsZSBhcmUgcHJlZmVycmVkIGluIGhvbWUgbmV0d29ya3MgZm9yIGEgdmFyaWV0eSBvZg0KPj4+ IHJlYXNvbnMgaW5jbHVkaW5nIHNpbXBsZXIgbWFuYWdlbWVudCBhbmQgc2VydmljZSBkaXNjb3Zl cnksIHRoZQ0KPj4+IGludHJvZHVjdGlvbiBvZiBtb3JlIHRoYW4gb25lIHN1Ym5ldCBpbnRvIGEg aG9tZSBuZXR3b3JrIGlzIGVub3VnaA0KPj4+IHRvIGFkZCBjb21wbGV4aXR5IHRoYXQgbmVlZHMg dG8gYmUgYWRkcmVzc2VkLCBhbmQgbXVsdGlwbGUNCj4+PiBkZWRpY2F0ZWQgc2VnbWVudHMgYXJl IG5lY2Vzc2FyeSBmb3Igc29tZSBjYXNlcy4gRm9yIGluc3RhbmNlLCBhDQo+Pj4gY29tbW9uIGZl YXR1cmUgaW4gbW9kZXJuIGhvbWUgcm91dGVycyBpbiB0aGUgYWJpbGl0eSB0byBzdXBwb3J0DQo+ Pj4gYm90aCBndWVzdCBhbmQgcHJpdmF0ZSBuZXR3b3JrIHNlZ21lbnRzLiBBbHNvLCBsaW5rIGxh eWVyDQo+Pj4gbmV0d29ya2luZyB0ZWNobm9sb2d5IGlzIHBvaXNlZCB0byBiZWNvbWUgbW9yZSBo ZXRlcm9nZW5lb3VzLCBhcw0KPj4+IG5ldHdvcmtzIGJlZ2luIHRvIGVtcGxveSBib3RoIHRyYWRp dGlvbmFsIEV0aGVybmV0IHRlY2hub2xvZ3kgYW5kDQo+Pj4gbGluayBsYXllcnMgZGVzaWduZWQg Zm9yIGxvdy1wb3dlcmVkIHNlbnNvciBuZXR3b3Jrcy4gRmluYWxseSwNCj4+PiBzaW1pbGFyIG5l ZWRzIGZvciBzZWdtZW50YXRpb24gbWF5IG9jY3VyIGluIG90aGVyIGNhc2VzLCBzdWNoIGFzDQo+ Pj4gc2VwYXJhdGluZyBidWlsZGluZyBjb250cm9sIG9yIGNvcnBvcmF0ZSBleHRlbnNpb25zIGZy b20gdGhlDQo+Pj4gSW50ZXJuZXQgYWNjZXNzIG5ldHdvcmsuIERpZmZlcmVudCBzZWdtZW50cyBt YXkgYmUgYXNzb2NpYXRlZCB3aXRoDQo+Pj4gc3VibmV0cyB0aGF0IGhhdmUgZGlmZmVyZW50IHJv dXRpbmcgYW5kIHNlY3VyaXR5IHBvbGljaWVzLg0KPj4+IA0KPj4+IG8gU2VydmljZSBwcm92aWRl cnMgYXJlIGRlcGxveWluZyBJUHY2LCBhbmQgc3VwcG9ydCBmb3IgSVB2NiBpcw0KPj4+IGluY3Jl YXNpbmdseSBhdmFpbGFibGUgaW4gaG9tZSBnYXRld2F5IGRldmljZXMuIFdoaWxlIElQdjYgcmVz ZW1ibGVzDQo+Pj4gSVB2NCBpbiBtYW55IHdheXMsIGl0IGNoYW5nZXMgYWRkcmVzcyBhbGxvY2F0 aW9uIHByaW5jaXBsZXMgYW5kIGFsbG93cw0KPj4+IGRpcmVjdCBJUCBhZGRyZXNzYWJpbGl0eSBh bmQgcm91dGluZyB0byBkZXZpY2VzIGluIHRoZSBob21lIGZyb20gdGhlDQo+Pj4gSW50ZXJuZXQu IFRoaXMgaXMgYSBwcm9taXNpbmcgYXJlYSBpbiBJUHY2IHRoYXQgaGFzIHByb3ZlZCBjaGFsbGVu Z2luZw0KPj4+IGluIElQdjQgd2l0aCB0aGUgcHJvbGlmZXJhdGlvbiBvZiBOQVQuDQo+Pj4gDQo+ Pj4gbyBFbmQtdG8tZW5kIGNvbW11bmljYXRpb24gaXMgYm90aCBhbiBvcHBvcnR1bml0eSBhbmQg YSBjb25jZXJuIGFzIGl0DQo+Pj4gZW5hYmxlcyBuZXcgYXBwbGljYXRpb25zIGJ1dCBhbHNvIGV4 cG9zZXMgbm9kZXMgaW4gdGhlIGludGVybmFsDQo+Pj4gbmV0d29ya3MgdG8gcmVjZWlwdCBvZiB1 bndhbnRlZCB0cmFmZmljIGZyb20gdGhlIEludGVybmV0LiBGaXJld2FsbHMNCj4+PiB0aGF0IHJl c3RyaWN0IGluY29taW5nIGNvbm5lY3Rpb25zIG1heSBiZSB1c2VkIHRvIHByZXZlbnQgZXhwb3N1 cmUsDQo+Pj4gaG93ZXZlciwgdGhpcyByZWR1Y2VzIHRoZSBlZmZpY2FjeSBvZiBlbmQtdG8tZW5k IGNvbm5lY3Rpdml0eSB0aGF0DQo+Pj4gSVB2NiBoYXMgdGhlIHBvdGVudGlhbCB0byByZXN0b3Jl Lg0KPj4+IA0KPj4+IEhvbWUgbmV0d29ya3MgbmVlZCB0byBwcm92aWRlIHRoZSB0b29scyB0byBo YW5kbGUgdGhlc2Ugc2l0dWF0aW9ucyBpbg0KPj4+IGEgbWFubmVyIGFjY2Vzc2libGUgdG8gYWxs IHVzZXJzIG9mIGhvbWUgbmV0d29ya3MuIE1hbnVhbA0KPj4+IGNvbmZpZ3VyYXRpb24gaXMgcmFy ZWx5LCBpZiBhdCBhbGwsIHBvc3NpYmxlLiBUaGUgcHVycG9zZSBvZiB0aGlzDQo+Pj4gd29ya2lu ZyBncm91cCBpcyB0byBmb2N1cyBvbiB0aGlzIGV2b2x1dGlvbiwgaW4gcGFydGljdWxhciBhcyBp dA0KPj4+IGFkZHJlc3NlcyB0aGUgaW50cm9kdWN0aW9uIG9mIElQdjYsIGJ5IGRldmVsb3Bpbmcg YW4gYXJjaGl0ZWN0dXJlDQo+Pj4gYWRkcmVzc2luZyB0aGlzIGZ1bGwgc2NvcGUgb2YgcmVxdWly ZW1lbnRzOg0KPj4+IA0KPj4+IG8gcHJlZml4IGNvbmZpZ3VyYXRpb24gZm9yIHJvdXRlcnMNCj4+ PiBvIG1hbmFnaW5nIHJvdXRpbmcNCj4+PiBvIG5hbWUgcmVzb2x1dGlvbg0KPj4+IG8gc2Vydmlj ZSBkaXNjb3ZlcnkNCj4+PiBvIG5ldHdvcmsgc2VjdXJpdHkNCj4+PiANCj4+PiBUaGUgdGFzayBv ZiB0aGUgZ3JvdXAgaXMgdG8gcHJvZHVjZSBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgdGhhdA0K Pj4+IG91dGxpbmVzIGhvdyB0byBjb25zdHJ1Y3QgaG9tZSBuZXR3b3JrcyBpbnZvbHZpbmcgbXVs dGlwbGUgcm91dGVycyBhbmQNCj4+PiBzdWJuZXRzLiBUaGlzIGRvY3VtZW50IGlzIGV4cGVjdGVk IHRvIGFwcGx5IHRoZSBJUHY2IGFkZHJlc3NpbmcNCj4+PiBhcmNoaXRlY3R1cmUsIHByZWZpeCBk ZWxlZ2F0aW9uLCBnbG9iYWwgYW5kIFVMQSBhZGRyZXNzZXMsIHNvdXJjZQ0KPj4+IGFkZHJlc3Mg c2VsZWN0aW9uIHJ1bGVzIGFuZCBvdGhlciBleGlzdGluZyBjb21wb25lbnRzIG9mIHRoZSBJUHY2 DQo+Pj4gYXJjaGl0ZWN0dXJlLiBUaGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHNob3VsZCBkcml2 ZSB3aGF0IHByb3RvY29scw0KPj4+IGNoYW5nZXMsIGlmIGFueSwgYXJlIG5lY2Vzc2FyeS4gU3Bl Y2lmaWMgcHJvdG9jb2wgd29yayBkZXNjcmliZWQgYmVsb3cNCj4+PiBpcyBleHBlY3RlZCB0byBi ZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwIG9uZSB0aGUNCj4+PiBhcmNo aXRlY3R1cmUgd29yayBpcyBjb21wbGV0ZS4gSG93ZXZlciwgdGhlIGdyb3VwIGlzIHJlcXVpcmVk IHRvDQo+Pj4gcmV2aWV3IGl0cyBjaGFydGVyIGFuZCBtaWxlc3RvbmVzIHdpdGggdGhlIElFU0cg YW5kIElFVEYgY29tbXVuaXR5DQo+Pj4gYmVmb3JlIHN1Ym1pdHRpbmcgZG9jdW1lbnRzIHRoYXQg bWFrZSBwcm90b2NvbCBjaGFuZ2VzLiBJdCBpcyBleHBlY3RlZA0KPj4+IHRoYXQgdGhlIGdyb3Vw IGhhcyB0byBkaXNjdXNzIHNvbWUgb2YgdGhlIGJlbG93IHNvbHV0aW9ucywgaG93ZXZlciwgaW4N Cj4+PiBvcmRlciB0byBjb21wbGV0ZSB0aGUgYXJjaGl0ZWN0dXJlIHdvcmsuDQo+Pj4gDQo+Pj4g VGhlIGdyb3VwIHdpbGwgYXBwbHkgZXhpc3RpbmcgcHJvdG9jb2xzIHRvIGhhbmRsZSB0aGUgZml2 ZQ0KPj4+IHJlcXVpcmVtZW50cyBhYm92ZS4gRm9yIHByZWZpeCBjb25maWd1cmF0aW9uLCBleGlz dGluZyBwcm90b2NvbHMgYXJlDQo+Pj4gbGlrZWx5IHN1ZmZpY2llbnQsIGFuZCBhdCB3b3JzdCBt YXkgbmVlZCBzb21lIHNtYWxsIGVuaGFuY2VtZW50cywgc3VjaA0KPj4+IGFzIG5ldyBvcHRpb25z LiBGb3IgYXV0b21hdGljIHJvdXRpbmcsIGl0IGlzIGV4cGVjdGVkIHRoYXQgZXhpc3RpbmcNCj4+ PiByb3V0aW5nIHByb3RvY29scyBjYW4gYmUgdXNlZCBhcyBpcywgaG93ZXZlciwgYSBuZXcgbWVj aGFuaXNtIG1heSBiZQ0KPj4+IG5lZWRlZCBpbiBvcmRlciB0byB0dXJuIGEgc2VsZWN0ZWQgcHJv dG9jb2wgb24gYnkgZGVmYXVsdC4gRm9yIG5hbWUNCj4+PiByZXNvbHV0aW9uIGFuZCBzZXJ2aWNl IGRpc2NvdmVyeSwgZXh0ZW5zaW9ucyB0byBleGlzdGluZw0KPj4+IG11bHRpY2FzdC1iYXNlZCBu YW1lIHJlc29sdXRpb24gcHJvdG9jb2xzIGFyZSBuZWVkZWQgdG8gZW5hYmxlIHRoZW0gdG8NCj4+ PiB3b3JrIGFjcm9zcyBzdWJuZXRzLg0KPj4+IA0KPj4+IEZvciBuZXR3b3JrIHNlY3VyaXR5LCB0 aGUgZ3JvdXAgc2hhbGwgZG9jdW1lbnQgdGhlIGNvbmNlcHQgb2YNCj4+PiAiYWR2YW5jZWQgc2Vj dXJpdHkiIGFzIGEgZnVydGhlciBkZXZlbG9wbWVudCBvZiAic2ltcGxlIHNlY3VyaXR5IiBmcm9t DQo+Pj4gUkZDIDYwOTIuIFRoZSBtYWluIGdvYWwgb2YgdGhpcyB3b3JrIGlzIHRvIGVuYWJsZSBh IHNlY3VyaXR5IHBvbGljeQ0KPj4+IHRoYXQgYWRhcHRzIHRvIElQdjYgdGhyZWF0cyBhcyB0aGV5 IGVtZXJnZSwgdGFraW5nIGludG8gYWNjb3VudCBub3QNCj4+PiBvbmx5IHRyYWZmaWMgZnJvbSB0 aGUgSW50ZXJuZXQgYXQgbGFyZ2UsIGJ1dCB3aXRoaW4gYW5kIGxlYXZpbmcgdGhlDQo+Pj4gaG9t ZSBuZXR3b3JrIGl0c2VsZi4NCj4+PiANCj4+PiBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgZGVmaW5lIGEgc2V0IG9mIHByb3RvY29sDQo+Pj4gc3BlY2lmaWNhdGlv bnMgdG8gYWNjb21wbGlzaCB0aGUgZml2ZSByZXF1aXJlbWVudHMgZnJvbQ0KPj4+IGFib3ZlLiBI b3dldmVyLCBpdCBpcyBub3QgaW4gdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwIHRvIGRl ZmluZQ0KPj4+IGVudGlyZWx5IG5ldyByb3V0aW5nIHByb3RvY29scyBvciBhZGRyZXNzIGFsbG9j YXRpb24gcHJvdG9jb2xzLiBBcw0KPj4+IG5vdGVkLCBhZGRpdGlvbmFsIG9wdGlvbnMgb3Igb3Ro ZXIgc21hbGwgZXh0ZW5zaW9ucyBtYXkgYmUgbmVjZXNzYXJ5DQo+Pj4gdG8gdXNlIHRoZSBleGlz dGluZyBwcm90b2NvbHMgaW4gdGhlc2UgbmV3IGNvbmZpZ3VyYXRpb24gdGFza3MuIFRoZQ0KPj4+ IHdvcmtpbmcgZ3JvdXAgc2hhbGwgYWxzbyBub3QgbWFrZSBhbnkgY2hhbmdlcyB0byBJUHY2IHBy b3RvY29scyBvcg0KPj4+IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlLiBQcmVmaXggY29uZmlndXJh dGlvbiwgcm91dGluZywgYW5kIHNlY3VyaXR5DQo+Pj4gcmVsYXRlZCB3b3JrIHNoYWxsIG5vdCBj YXVzZSBhbnkgY2hhbmdlcyB0aGF0IGFyZSBub3QgYmFja3dhcmRzDQo+Pj4gY29tcGF0aWJsZSB0 byBleGlzdGluZyBJUHY2IGhvc3RzLiBUaGVyZSBtYXkgYmUgaG9zdCB2aXNpYmxlIGNoYW5nZXMN Cj4+PiBpbiB0aGUgd29yayBvbiBuYW1pbmcgYW5kIGRpc2NvdmVyeSBwcm90b2NvbHMsIGhvd2V2 ZXIuIEluIGl0cyBkZXNpZ24sDQo+Pj4gdGhlIHdvcmtpbmcgZ3JvdXAgc2hhbGwgYWxzbyBjb25z aWRlciBzZWN1cml0eSBhc3BlY3RzIGFuZCB0aGUgaW1wYWN0DQo+Pj4gb24gbWFuYWdlYWJpbGl0 eS4gVGhlIG1haW4gZm9jdXMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgaG9tZQ0KPj4+IG5ldHdv cmtzLCBidXQgdGhlIGdyb3VwJ3MgcmVzdWx0cyBtYXkgYWxzbyBmaW5kIGFwcGxpY2F0aW9ucyBp biBvdGhlcg0KPj4+IHNtYWxsIG5ldHdvcmtzLg0KPj4+IA0KPj4+IFRoZSB3b3JraW5nIGdyb3Vw IHdpbGwgbGlhaXNlIHdpdGggdGhlIHJlbGV2YW50IElFVEYgd29ya2luZw0KPj4+IGdyb3Vwcy4g SW4gcGFydGljdWxhciwgdGhlIGdyb3VwIHNob3VsZCB3b3JrIGNsb3NlbHkgd2l0aCB0aGUgVjZP UFMNCj4+PiB3b3JraW5nIGdyb3VwLCByZXZpZXcgYW55IHVzZSBvciBleHRlbnNpb24gb2YgREhD UCB3aXRoIHRoZSBESEMNCj4+PiB3b3JraW5nIGdyb3VwLCBhbmQgd29yayB3aXRoIGFkZGl0aW9u YWwgRE5TIHJlcXVpcmVtZW50cyB3aXRoIHRoZQ0KPj4+IEROU0VYVCBhbmQgRE5TT1Agd29ya2lu ZyBncm91cHMuIElmIGl0IHR1cm5zIG91dCB0aGF0IGFkZGl0aW9uYWwNCj4+PiBvcHRpb25zIGFy ZSBuZWVkZWQgZm9yIGEgcm91dGluZyBwcm90b2NvbCwgdGhleSB3aWxsIGJlIGRldmVsb3BlZCBp bg0KPj4+IHRoZSBhcHByb3ByaWF0ZSBSb3V0aW5nIEFyZWEgd29ya2luZyBncm91cCwgd2l0aCB0 aGUgSE9NRU5FVCB3b3JraW5nDQo+Pj4gZ3JvdXAgcHJvdmlkaW5nIHRoZSBhcmNoaXRlY3R1cmUg YW5kIHJlcXVpcmVtZW50cyBmb3Igc3VjaA0KPj4+IGVuaGFuY2VtZW50cy4gVGhlIHdvcmtpbmcg Z3JvdXAgd2lsbCBhbHNvIGxpYXNlIHdpdGggZXh0ZXJuYWwNCj4+PiBzdGFuZGFyZHMgYm9kaWVz IHdoZXJlIGl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlcmUgYXJlIG5vcm1hdGl2ZQ0KPj4+IGRlcGVu ZGVuY2llcyBiZXR3ZWVuIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiB0aGUgdHdvIGJvZGllcy4NCj4+ PiBJdCBpcyBleHBlY3RlZCB0aGF0IGluIHRoZSBhcmNoaXRlY3R1cmUgZGVmaW5pdGlvbiBzdGFn ZSBsaWFpc2luZw0KPj4+IHdpdGggdGhlIEJyb2FkYmFuZCBGb3J1bSwgRExOQSwgYW5kIFVQblAg Rm9ydW0gaXMgbmVjZXNzYXJ5Lg0KPj4+IA0KPj4+IE1pbGVzdG9uZXM6DQo+Pj4gDQo+Pj4gSnVs IDIwMTEgRm9ybWF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwDQo+Pj4gU2VwIDIwMTEgRmlyc3Qg V0cgZHJhZnQgb24gdGhlIGFyY2hpdGVjdHVyZQ0KPj4+IERlYyAyMDExIFN1Ym1pc3Npb24gb2Yg dGhlIGFyY2hpdGVjdHVyZSBkcmFmdCB0byB0aGUgSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQw0K Pj4+IERlYyAyMDExIENoYXJ0ZXIgcmUtZXZhbHVhdGlvbiBiYXNlZCBvbiB0aGUgYXJjaGl0ZWN0 dXJlIHdvcmsNCj4+PiBEZWMgMjAxMSBGaXJzdCBXRyBkcmFmdCBvbiBwcmVmaXggY29uZmlndXJh dGlvbg0KPj4+IERlYyAyMDExIEZpcnN0IFdHIGRyYWZ0IG9uIHJvdXRpbmcNCj4+PiBKYW4gMjAx MiBGaXJzdCBXRyBkcmFmdCBvbiBuYW1lIHJlc29sdXRpb24NCj4+PiBGZWIgMjAxMiBGaXJzdCBX RyBkcmFmdCBvbiBzZXJ2aWNlIGRpc2NvdmVyeQ0KPj4+IEZlYiAyMDEyIEZpcnN0IFdHIGRyYWZ0 IG9uIHBlcmltZXRlciBzZWN1cml0eQ0KPj4+IEZlYiAyMDEyIFN0YXJ0IG9mIHJvdXRpbmcgcmVs YXRlZCB3b3JrIGluIHRoZSByZWxldmFudCByb3V0aW5nIGFyZWEgd29ya2luZyBncm91cCwgaWYg bmVlZGVkDQo+Pj4gTWFyIDIwMTIgU3VibWlzc2lvbiBvZiB0aGUgcHJlZml4IGNvbmZpZ3VyYXRp b24gZHJhZnQgdG8gdGhlIElFU0cgYXMgU3RhbmRhcmRzIFRyYWNrIFJGQw0KPj4+IEFwciAyMDEy IFN1Ym1pc3Npb24gb2YgdGhlIHJvdXRpbmcgZHJhZnQgdG8gdGhlIElFU0cgYXMgSW5mb3JtYXRp b25hbCBSRkMNCj4+PiBTZXAgMjAxMiBTdWJtaXNzaW9uIG9mIHRoZSBuYW1lIHJlc29sdXRpb24g ZHJhZnQgdG8gdGhlIElFU0cgYXMgU3RhbmRhcmRzIFRyYWNrIFJGQw0KPj4+IE5vdiAyMDEyIFN1 Ym1pc3Npb24gb2YgdGhlIHNlcnZpY2UgZGlzY292ZXJ5IGRyYWZ0IHRvIHRoZSBJRVNHIGFzIFN0 YW5kYXJkcyBUcmFjayBSRkMNCj4+PiBEZWMgMjAxMiBTdWJtaXNzaW9uIG9mIHRoZSBwZXJpbWV0 ZXIgc2VjdXJpdHkgZHJhZnQgdG8gdGhlIElFU0cgYXMgSW5mb3JtYXRpb25hbCBSRkMNCj4+PiAN Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IGZ1biBtYWlsaW5nIGxpc3QNCj4+PiBmdW5AaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Z1bg0KPj4+ICAgIA0KPj4gDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gZnVuIG1haWxpbmcgbGlzdA0K Pj4gZnVuQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Z1bg0KPj4gDQo+PiAgDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBmdW4gbWFpbGluZyBsaXN0DQo+IGZ1bkBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Z1bg0K From fluffy@cisco.com Sat Jul 2 05:31:54 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8292611E8326 for ; Sat, 2 Jul 2011 05:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c2WRr1avERM for ; Sat, 2 Jul 2011 05:31:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 504FF11E82F4 for ; Sat, 2 Jul 2011 05:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=12259; q=dns/txt; s=iport; t=1309609913; x=1310819513; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=J+7oyC3TbwY0QxaxQMQnl720+L6Fci8GVorZ6YmF2g0=; b=Za4Ow/GjmPm2v30sU/PHWf99G/Eq7OGYXfAoY60XcQAaVeXPbunHoVBF ihZWuOvz37dX2KyXboOZ9Xn+JOfTRW4RLa9GwrdmyfFfoTFZdCaOM9c/O +Ks6hkPQZfxzSZhr1+KIKdX2zlPw9fh3tXveY3AOKsOyZVXnSNpAwJ/we o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADgPD06rRDoI/2dsb2JhbABSqAF3iHqkB506gzSDAgSHP4p3hHiEUocL X-IronPort-AV: E=Sophos;i="4.65,463,1304294400"; d="scan'208";a="351968453" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2011 12:31:52 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p62CVpve023747; Sat, 2 Jul 2011 12:31:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <4E0ED065.6060706@piuha.net> Date: Sat, 2 Jul 2011 06:31:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9350DA1B-A74D-42D6-803E-2E5E3BAA6D76@cisco.com> References: <4E0AE3CF.2070504@piuha.net> <4E0ED065.6060706@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 12:31:54 -0000 Thanks - that makes sense.=20 On Jul 2, 2011, at 2:01 AM, Jari Arkko wrote: > Cullen, >=20 > Good question. >=20 > The charter does say that new routing protocols are NOT in scope, = however. There may be a need to run a routing protocol, but if so, it = would be an existing one. >=20 > But back to your question. Do we need a routing protocol, or can a = single router be at the center and deal with all? I think the single = router model is a good one even when there are multiple subnets. That = being said, when you plug in. say, the first sensor-network-to-WLAN = router that can't do bridging you're in trouble. I personally think we = should build for the case where there are multiple routers, while hoping = that there is just one and that the number of subnets is either 1 or at = least a very small number. >=20 > Jari >=20 > Cullen Jennings kirjoitti: >> I'm sure this is a spectacularly clueless question but, .... could = someone say a bit more about why we need a routing protocol. I get that = there is a need for small number of subnets, but it seems like most the = requirements I have seen could be deal with using a single router that = could route between all the subnets. As I said, clueless questions but = can someone fill me in a bit on the use cases for a routing protocol? Or = why a new routing protocol might be needed. Thanks.=20 >>=20 >>=20 >> On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote: >>=20 >> =20 >>> I wanted to provide an update of the situation with this working = group proposal. >>>=20 >>> HOMENET is a new working group proposal, a variation of the = HOMEGATE/HOMENET theme that we discussed last year, but this time = looking at it from a different angle. The old effort was mostly focused = about what home gateways should do: forwarding, transport, and DNS = proxying issues. The new effort is about home networks themselves, in = particular what kind of network architecture and configuration is = necessary to support IPv6-based home networks. We view IPv4-based home = networks as "done" at this time (or perhaps as "cannot be changed = anyway"). >>>=20 >>> I have been discussing this effort in the background for the last = couple of month with Mark Townsley and others, and more publicly since = early June. The proposal has been brought to the IESG, IAB and some = directorates for discussion, and we've been going back and forth whether = this is ready to become a working group or needs to be run as a BOF in = Quebec City. The current plan is that the working group proposal goes to = IETF-wide review this week, and if the feedback from the community, IAB, = and the IESG is positive, we will create the working group just in time = for the IETF. Otherwise, the slot reserved in the agenda for the meeting = will be used to run the proposal as a BOF. >>>=20 >>> In any case, I would like to solicit discussion on this topic, and = perhaps some early drafts as well. Please comment on the charter at = least. >>>=20 >>> Note that the new proposal was called FUN at the time that we = created the list. It has now been renamed back to HOMENET to be more = descriptive. The list will be renamed soon as well (current subscribers = will stay). >>>=20 >>> This is the most recent version of the charter we should discuss: >>>=20 >>> Home Networks (homenet) >>> ----------------------------------- >>>=20 >>> Current Status: Proposed >>> Last Edit: Wednesday, June 29th, 2011 >>>=20 >>> Chairs: >>> TBD >>>=20 >>> Internet Area Directors: >>> Ralph Droms >>> Jari Arkko >>>=20 >>> Internet Area Advisor: >>> Jari Arkko >>>=20 >>> Routing Area Technical Advisor: >>> TBD >>>=20 >>> Security Area Technical Advisor: >>> TBD >>>=20 >>> Mailing Lists: >>> General Discussion: fun@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>> Archive: http://www.ietf.org/mail-archive/web/fun >>>=20 >>> Description of Working Group: >>>=20 >>> This working group focuses on the evolving networking technology >>> within and among relatively small =93residential home=94 networks. = For >>> example, an obvious trend in home networking is the proliferation of >>> networking technology in an increasingly broad range and number of >>> devices. This evolution in scale and diversity sets some = requirements >>> on IETF protocols. Some of the relevant trends include: >>>=20 >>> o Multiple segments: While less complex L3-toplogies involving as = few >>> subnets as possible are preferred in home networks for a variety of >>> reasons including simpler management and service discovery, the >>> introduction of more than one subnet into a home network is enough >>> to add complexity that needs to be addressed, and multiple >>> dedicated segments are necessary for some cases. For instance, a >>> common feature in modern home routers in the ability to support >>> both guest and private network segments. Also, link layer >>> networking technology is poised to become more heterogeneous, as >>> networks begin to employ both traditional Ethernet technology and >>> link layers designed for low-powered sensor networks. Finally, >>> similar needs for segmentation may occur in other cases, such as >>> separating building control or corporate extensions from the >>> Internet access network. Different segments may be associated with >>> subnets that have different routing and security policies. >>>=20 >>> o Service providers are deploying IPv6, and support for IPv6 is >>> increasingly available in home gateway devices. While IPv6 resembles >>> IPv4 in many ways, it changes address allocation principles and = allows >>> direct IP addressability and routing to devices in the home from the >>> Internet. This is a promising area in IPv6 that has proved = challenging >>> in IPv4 with the proliferation of NAT. >>>=20 >>> o End-to-end communication is both an opportunity and a concern as = it >>> enables new applications but also exposes nodes in the internal >>> networks to receipt of unwanted traffic from the Internet. Firewalls >>> that restrict incoming connections may be used to prevent exposure, >>> however, this reduces the efficacy of end-to-end connectivity that >>> IPv6 has the potential to restore. >>>=20 >>> Home networks need to provide the tools to handle these situations = in >>> a manner accessible to all users of home networks. Manual >>> configuration is rarely, if at all, possible. The purpose of this >>> working group is to focus on this evolution, in particular as it >>> addresses the introduction of IPv6, by developing an architecture >>> addressing this full scope of requirements: >>>=20 >>> o prefix configuration for routers >>> o managing routing >>> o name resolution >>> o service discovery >>> o network security >>>=20 >>> The task of the group is to produce an architecture document that >>> outlines how to construct home networks involving multiple routers = and >>> subnets. This document is expected to apply the IPv6 addressing >>> architecture, prefix delegation, global and ULA addresses, source >>> address selection rules and other existing components of the IPv6 >>> architecture. The architecture document should drive what protocols >>> changes, if any, are necessary. Specific protocol work described = below >>> is expected to be within the scope of the working group one the >>> architecture work is complete. However, the group is required to >>> review its charter and milestones with the IESG and IETF community >>> before submitting documents that make protocol changes. It is = expected >>> that the group has to discuss some of the below solutions, however, = in >>> order to complete the architecture work. >>>=20 >>> The group will apply existing protocols to handle the five >>> requirements above. For prefix configuration, existing protocols are >>> likely sufficient, and at worst may need some small enhancements, = such >>> as new options. For automatic routing, it is expected that existing >>> routing protocols can be used as is, however, a new mechanism may be >>> needed in order to turn a selected protocol on by default. For name >>> resolution and service discovery, extensions to existing >>> multicast-based name resolution protocols are needed to enable them = to >>> work across subnets. >>>=20 >>> For network security, the group shall document the concept of >>> "advanced security" as a further development of "simple security" = from >>> RFC 6092. The main goal of this work is to enable a security policy >>> that adapts to IPv6 threats as they emerge, taking into account not >>> only traffic from the Internet at large, but within and leaving the >>> home network itself. >>>=20 >>> It is expected that the working group will define a set of protocol >>> specifications to accomplish the five requirements from >>> above. However, it is not in the scope of the working group to = define >>> entirely new routing protocols or address allocation protocols. As >>> noted, additional options or other small extensions may be necessary >>> to use the existing protocols in these new configuration tasks. The >>> working group shall also not make any changes to IPv6 protocols or >>> addressing architecture. Prefix configuration, routing, and security >>> related work shall not cause any changes that are not backwards >>> compatible to existing IPv6 hosts. There may be host visible changes >>> in the work on naming and discovery protocols, however. In its = design, >>> the working group shall also consider security aspects and the = impact >>> on manageability. The main focus of the working group is home >>> networks, but the group's results may also find applications in = other >>> small networks. >>>=20 >>> The working group will liaise with the relevant IETF working >>> groups. In particular, the group should work closely with the V6OPS >>> working group, review any use or extension of DHCP with the DHC >>> working group, and work with additional DNS requirements with the >>> DNSEXT and DNSOP working groups. If it turns out that additional >>> options are needed for a routing protocol, they will be developed in >>> the appropriate Routing Area working group, with the HOMENET working >>> group providing the architecture and requirements for such >>> enhancements. The working group will also liase with external >>> standards bodies where it is expected that there are normative >>> dependencies between the specifications of the two bodies. >>> It is expected that in the architecture definition stage liaising >>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>=20 >>> Milestones: >>>=20 >>> Jul 2011 Formation of the working group >>> Sep 2011 First WG draft on the architecture >>> Dec 2011 Submission of the architecture draft to the IESG as = Informational RFC >>> Dec 2011 Charter re-evaluation based on the architecture work >>> Dec 2011 First WG draft on prefix configuration >>> Dec 2011 First WG draft on routing >>> Jan 2012 First WG draft on name resolution >>> Feb 2012 First WG draft on service discovery >>> Feb 2012 First WG draft on perimeter security >>> Feb 2012 Start of routing related work in the relevant routing area = working group, if needed >>> Mar 2012 Submission of the prefix configuration draft to the IESG as = Standards Track RFC >>> Apr 2012 Submission of the routing draft to the IESG as = Informational RFC >>> Sep 2012 Submission of the name resolution draft to the IESG as = Standards Track RFC >>> Nov 2012 Submission of the service discovery draft to the IESG as = Standards Track RFC >>> Dec 2012 Submission of the perimeter security draft to the IESG as = Informational RFC >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >>> =20 >>=20 >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >>=20 >> =20 >=20 From joelja@bogus.com Sat Jul 2 11:54:00 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE291F0C36 for ; Sat, 2 Jul 2011 11:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG3JnVzDKI0Y for ; Sat, 2 Jul 2011 11:53:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 497A71F0C51 for ; Sat, 2 Jul 2011 11:53:59 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p62Iruce015063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 2 Jul 2011 18:53:57 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Joel Jaeggli In-Reply-To: Date: Sat, 2 Jul 2011 11:53:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8942CB4B-B542-4331-8F9D-B6F823A1D72E@bogus.com> References: <4E0AE3CF.2070504@piuha.net> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 02 Jul 2011 18:53:57 +0000 (UTC) Cc: fun@ietf.org Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 18:54:00 -0000 I would be really unconvinced that a new routing protocol would be = required, for that to be the case there would need to be something = greatly wrong wtih the existing options. That said... A rational for the existence of a routing protocol, involves the = interconnection of existing addressing domains, and/or the cascading of = devices... strictly hierarchical assignment can deal with the later, but = to what extent does that always happen. if you presuppose the existence of a god box to which everything else is = connected the need for a routing protocol is greatly diminished or = eliminated, that said, that presumption also applies to enterprise lans. joel On Jul 1, 2011, at 5:24 PM, Cullen Jennings wrote: >=20 > I'm sure this is a spectacularly clueless question but, .... could = someone say a bit more about why we need a routing protocol. I get that = there is a need for small number of subnets, but it seems like most the = requirements I have seen could be deal with using a single router that = could route between all the subnets. As I said, clueless questions but = can someone fill me in a bit on the use cases for a routing protocol? Or = why a new routing protocol might be needed. Thanks.=20 >=20 >=20 >=20 > On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote: >=20 >> I wanted to provide an update of the situation with this working = group proposal. >>=20 >> HOMENET is a new working group proposal, a variation of the = HOMEGATE/HOMENET theme that we discussed last year, but this time = looking at it from a different angle. The old effort was mostly focused = about what home gateways should do: forwarding, transport, and DNS = proxying issues. The new effort is about home networks themselves, in = particular what kind of network architecture and configuration is = necessary to support IPv6-based home networks. We view IPv4-based home = networks as "done" at this time (or perhaps as "cannot be changed = anyway"). >>=20 >> I have been discussing this effort in the background for the last = couple of month with Mark Townsley and others, and more publicly since = early June. The proposal has been brought to the IESG, IAB and some = directorates for discussion, and we've been going back and forth whether = this is ready to become a working group or needs to be run as a BOF in = Quebec City. The current plan is that the working group proposal goes to = IETF-wide review this week, and if the feedback from the community, IAB, = and the IESG is positive, we will create the working group just in time = for the IETF. Otherwise, the slot reserved in the agenda for the meeting = will be used to run the proposal as a BOF. >>=20 >> In any case, I would like to solicit discussion on this topic, and = perhaps some early drafts as well. Please comment on the charter at = least. >>=20 >> Note that the new proposal was called FUN at the time that we created = the list. It has now been renamed back to HOMENET to be more = descriptive. The list will be renamed soon as well (current subscribers = will stay). >>=20 >> This is the most recent version of the charter we should discuss: >>=20 >> Home Networks (homenet) >> ----------------------------------- >>=20 >> Current Status: Proposed >> Last Edit: Wednesday, June 29th, 2011 >>=20 >> Chairs: >> TBD >>=20 >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >>=20 >> Internet Area Advisor: >> Jari Arkko >>=20 >> Routing Area Technical Advisor: >> TBD >>=20 >> Security Area Technical Advisor: >> TBD >>=20 >> Mailing Lists: >> General Discussion: fun@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >> Archive: http://www.ietf.org/mail-archive/web/fun >>=20 >> Description of Working Group: >>=20 >> This working group focuses on the evolving networking technology >> within and among relatively small =93residential home=94 networks. = For >> example, an obvious trend in home networking is the proliferation of >> networking technology in an increasingly broad range and number of >> devices. This evolution in scale and diversity sets some requirements >> on IETF protocols. Some of the relevant trends include: >>=20 >> o Multiple segments: While less complex L3-toplogies involving as few >> subnets as possible are preferred in home networks for a variety of >> reasons including simpler management and service discovery, the >> introduction of more than one subnet into a home network is enough >> to add complexity that needs to be addressed, and multiple >> dedicated segments are necessary for some cases. For instance, a >> common feature in modern home routers in the ability to support >> both guest and private network segments. Also, link layer >> networking technology is poised to become more heterogeneous, as >> networks begin to employ both traditional Ethernet technology and >> link layers designed for low-powered sensor networks. Finally, >> similar needs for segmentation may occur in other cases, such as >> separating building control or corporate extensions from the >> Internet access network. Different segments may be associated with >> subnets that have different routing and security policies. >>=20 >> o Service providers are deploying IPv6, and support for IPv6 is >> increasingly available in home gateway devices. While IPv6 resembles >> IPv4 in many ways, it changes address allocation principles and = allows >> direct IP addressability and routing to devices in the home from the >> Internet. This is a promising area in IPv6 that has proved = challenging >> in IPv4 with the proliferation of NAT. >>=20 >> o End-to-end communication is both an opportunity and a concern as it >> enables new applications but also exposes nodes in the internal >> networks to receipt of unwanted traffic from the Internet. Firewalls >> that restrict incoming connections may be used to prevent exposure, >> however, this reduces the efficacy of end-to-end connectivity that >> IPv6 has the potential to restore. >>=20 >> Home networks need to provide the tools to handle these situations in >> a manner accessible to all users of home networks. Manual >> configuration is rarely, if at all, possible. The purpose of this >> working group is to focus on this evolution, in particular as it >> addresses the introduction of IPv6, by developing an architecture >> addressing this full scope of requirements: >>=20 >> o prefix configuration for routers >> o managing routing >> o name resolution >> o service discovery >> o network security >>=20 >> The task of the group is to produce an architecture document that >> outlines how to construct home networks involving multiple routers = and >> subnets. This document is expected to apply the IPv6 addressing >> architecture, prefix delegation, global and ULA addresses, source >> address selection rules and other existing components of the IPv6 >> architecture. The architecture document should drive what protocols >> changes, if any, are necessary. Specific protocol work described = below >> is expected to be within the scope of the working group one the >> architecture work is complete. However, the group is required to >> review its charter and milestones with the IESG and IETF community >> before submitting documents that make protocol changes. It is = expected >> that the group has to discuss some of the below solutions, however, = in >> order to complete the architecture work. >>=20 >> The group will apply existing protocols to handle the five >> requirements above. For prefix configuration, existing protocols are >> likely sufficient, and at worst may need some small enhancements, = such >> as new options. For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default. For name >> resolution and service discovery, extensions to existing >> multicast-based name resolution protocols are needed to enable them = to >> work across subnets. >>=20 >> For network security, the group shall document the concept of >> "advanced security" as a further development of "simple security" = from >> RFC 6092. The main goal of this work is to enable a security policy >> that adapts to IPv6 threats as they emerge, taking into account not >> only traffic from the Internet at large, but within and leaving the >> home network itself. >>=20 >> It is expected that the working group will define a set of protocol >> specifications to accomplish the five requirements from >> above. However, it is not in the scope of the working group to define >> entirely new routing protocols or address allocation protocols. As >> noted, additional options or other small extensions may be necessary >> to use the existing protocols in these new configuration tasks. The >> working group shall also not make any changes to IPv6 protocols or >> addressing architecture. Prefix configuration, routing, and security >> related work shall not cause any changes that are not backwards >> compatible to existing IPv6 hosts. There may be host visible changes >> in the work on naming and discovery protocols, however. In its = design, >> the working group shall also consider security aspects and the impact >> on manageability. The main focus of the working group is home >> networks, but the group's results may also find applications in other >> small networks. >>=20 >> The working group will liaise with the relevant IETF working >> groups. In particular, the group should work closely with the V6OPS >> working group, review any use or extension of DHCP with the DHC >> working group, and work with additional DNS requirements with the >> DNSEXT and DNSOP working groups. If it turns out that additional >> options are needed for a routing protocol, they will be developed in >> the appropriate Routing Area working group, with the HOMENET working >> group providing the architecture and requirements for such >> enhancements. The working group will also liase with external >> standards bodies where it is expected that there are normative >> dependencies between the specifications of the two bodies. >> It is expected that in the architecture definition stage liaising >> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>=20 >> Milestones: >>=20 >> Jul 2011 Formation of the working group >> Sep 2011 First WG draft on the architecture >> Dec 2011 Submission of the architecture draft to the IESG as = Informational RFC >> Dec 2011 Charter re-evaluation based on the architecture work >> Dec 2011 First WG draft on prefix configuration >> Dec 2011 First WG draft on routing >> Jan 2012 First WG draft on name resolution >> Feb 2012 First WG draft on service discovery >> Feb 2012 First WG draft on perimeter security >> Feb 2012 Start of routing related work in the relevant routing area = working group, if needed >> Mar 2012 Submission of the prefix configuration draft to the IESG as = Standards Track RFC >> Apr 2012 Submission of the routing draft to the IESG as Informational = RFC >> Sep 2012 Submission of the name resolution draft to the IESG as = Standards Track RFC >> Nov 2012 Submission of the service discovery draft to the IESG as = Standards Track RFC >> Dec 2012 Submission of the perimeter security draft to the IESG as = Informational RFC >>=20 >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun >=20 From dougb@dougbarton.us Sat Jul 2 18:31:51 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E29721F864E for ; Sat, 2 Jul 2011 18:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0WPw4A2Lvmh for ; Sat, 2 Jul 2011 18:31:50 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 785A921F85E3 for ; Sat, 2 Jul 2011 18:31:50 -0700 (PDT) Received: (qmail 3655 invoked by uid 399); 3 Jul 2011 01:31:49 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 3 Jul 2011 01:31:49 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E0FC683.6020900@dougbarton.us> Date: Sat, 02 Jul 2011 18:31:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Keith Moore References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> <4E0E2A75.6040207@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:31:51 -0000 On 07/01/2011 14:17, Keith Moore wrote: > On Jul 1, 2011, at 4:13 PM, Doug Barton wrote: > >> On 07/01/2011 13:03, Kenneth Voort wrote: >>> I would also add that future IPv6 capable devices should allow >>> end users to reach the IPv6 Internet from an IPv4-only provider >>> through some means, perhaps tunneling, with no or minimal >>> administrator intervention. I can see many providers remaining >>> IPv4-only long into the future. >> >> This is an area that we very clearly do not need to get involved in >> because it will solve itself due to market forces. Right now there >> is no IPv6-only content that anyone cares about. When that changes, >> users will start demanding that their provider give them access to >> it, or vote with their feet. > > Whenever people talk about the Internet as if it were just about > "access to content", I have to wonder. The Internet has always > been more about conversation than content. The overwhelming majority of Internet users are consumers of content. Some of that content is stuff like Skype, instant messaging, etc. The overwhelming majority of businesses that make the Internet work are the content providers, and the ISPs that enable the consumers of that content to reach it. Failure to recognize these 2 critical facts leads to producing standards documents that have no relevance in the real world. >> To summarize my main point once again, there is nothing for the >> IETF to do here, the problem will take care of itself. > > Quite the contrary. We still don't have a good transition mechanism > that HOMENET could specify. And as I pointed out in the bits of my message that you snipped, we don't need one. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From fred@cisco.com Sat Jul 2 20:29:56 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382B511E811C for ; Sat, 2 Jul 2011 20:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeODj+mDIp3Q for ; Sat, 2 Jul 2011 20:29:55 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id A0EC711E80BC for ; Sat, 2 Jul 2011 20:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=893; q=dns/txt; s=iport; t=1309663795; x=1310873395; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=HnMa3r4tMWhMbylrWqPhgc3fJfvyhNK6MOiX80WlJ1g=; b=GKlLFjdYn/MF+PrBfUdlefQMs7g3idPeJ1mrTMnwJFmM2JkqjnuYPXhx EDElcBte9iQVOUV9BVrtrZdo0ph3huSinoj7ju29CCBB8KDFwvlAB1+em rbDURAA4+rtMVFSKrJ+9Rq1X2njpSb9kXpmWv5FKE8Z309eatw72NPX+s s=; X-IronPort-AV: E=Sophos;i="4.65,466,1304294400"; d="scan'208";a="288856754" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 03 Jul 2011 03:29:55 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p633TsKX025270; Sun, 3 Jul 2011 03:29:55 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 02 Jul 2011 20:29:55 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 02 Jul 2011 20:29:55 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 2 Jul 2011 20:29:45 -0700 Message-Id: <77E4CC08-18E7-4FD7-9034-1E5D0CC58373@cisco.com> References: <4E0AE3CF.2070504@piuha.net> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: fun@ietf.org Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:29:56 -0000 On Jul 1, 2011, at 5:24 PM, Cullen Jennings wrote: > I'm sure this is a spectacularly clueless question but, .... could = someone say a bit more about why we need a routing protocol. Well, if you draw a circle around the network so small that it consists = of exactly one router (figure 2 of draft-baker-fun-multi-router), I = guess we don't. However, I'll note that (discussion on v6ops a few = months back) existing IPv4 residential gateways for the most part = support a routing protocol - usually RIPv2. If present residential = gateways have that requirement for market reasons, it does seem = reasonable to expect future ones to. I guess the question I would ask is not "why", but "given that there is = evidently a present market requirement, why not". Can you explain to me = why every residential gateway manufacturer save one - including Linksys = - is wrong?= From moore@network-heretics.com Sat Jul 2 20:44:08 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDE721F8628; Sat, 2 Jul 2011 20:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvfvOnUQ-ywP; Sat, 2 Jul 2011 20:44:08 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 483FA21F8624; Sat, 2 Jul 2011 20:44:08 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id DD24720681; Sat, 2 Jul 2011 23:44:07 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 02 Jul 2011 23:44:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=KFtKT1wOQMMFYg95XvMIWdKAuGw=; b=eBeArItriehufQIUPNWTU3BkfbjTVH4Ha3HaPvUrLoaWB5EKbOqD2gl27QFecbtvN5RBSy3eg466QZriKlJVCZ/m57F7dO11CDBWav9jjYAuUPiLZubRKFrCiwvdlfdUxQqtmelyDXSslr9DTXvsjVEdKO2E2mVo2+iveG0Ty80= X-Sasl-enc: xXxK+SvQdMzqITS6vXVxEnfQPkViZSxv+0d9IT3KLdcz 1309664647 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id CCEDA403F96; Sat, 2 Jul 2011 23:44:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0FC683.6020900@dougbarton.us> Date: Sat, 2 Jul 2011 23:43:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> <4E0E2A75.6040207@dougbarton.us> <4E0FC683.6020900@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: ietf@ietf.org, fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:44:08 -0000 On Jul 2, 2011, at 9:31 PM, Doug Barton wrote: > On 07/01/2011 14:17, Keith Moore wrote: >>=20 >>=20 >> Whenever people talk about the Internet as if it were just about >> "access to content", I have to wonder. The Internet has always >> been more about conversation than content. >=20 > The overwhelming majority of Internet users are consumers of content. = Some of that content is stuff like Skype, instant messaging, etc. The point is that the Internet is not primarily about producers in the = center doling out content to users at the edge. Granted, netflix uses a = lot of bandwidth. But a lot of what has driven use of the Internet, and = continues to drive it, is users engaging in conversation of one form or = another. This was true when email and Usenet were the apps consuming = the most bandwidth, and it's true today for Skype, Facebook, Youtube, = IM, blogs, etc. Meanwhile, traditional producer-to-consumer media channels of all types = are steadily dying. They tend to blame it on copyright violation, or = "free" access to content on the Internet. The real problem is that most = of what they produce is crap. They're stuck in an old model that says = that a few people should decide what's good for everybody else, but now = people are in a position to decide what's good for themselves and/or = create their own content. > The overwhelming majority of businesses that make the Internet work = are the content providers, and the ISPs that enable the consumers of = that content to reach it. >=20 > Failure to recognize these 2 critical facts leads to producing = standards documents that have no relevance in the real world. Insistence on sticking to anachronistic models of "the real world" will = do the same thing. =20 Keith From fluffy@cisco.com Sat Jul 2 22:54:10 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ED321F874F for ; Sat, 2 Jul 2011 22:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.213 X-Spam-Level: X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnJonaC635Mi for ; Sat, 2 Jul 2011 22:54:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7A521F874D for ; Sat, 2 Jul 2011 22:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3110; q=dns/txt; s=iport; t=1309672449; x=1310882049; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=m8UvVv3jjV2hKjw87kvJ5YBZ3gOZjw7UuMPjoAUNPPA=; b=gkZfS8qeC+tfTQyaFs/phgRGNYBFvzXP1dhI7wxNgDl6cw8YW+ShSW0O +S8FCTgxwVpzxeVmHF+Sddte0RAMltRpV7X4kmx4RK29iVOPwVUBhwzsP 62trVfT6xjRMaSYA/lptq7uwQl7HJtSJTHYd10ItDvkpAnAKA0sZL1cUQ 4=; X-IronPort-AV: E=Sophos;i="4.65,466,1304294400"; d="scan'208";a="288886162" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-4.cisco.com with ESMTP; 03 Jul 2011 05:54:09 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p635s8ig015607; Sun, 3 Jul 2011 05:54:08 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <77E4CC08-18E7-4FD7-9034-1E5D0CC58373@cisco.com> Date: Sat, 2 Jul 2011 23:54:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE3CF.2070504@piuha.net> <77E4CC08-18E7-4FD7-9034-1E5D0CC58373@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org Subject: Re: [fun] Routing ? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 05:54:10 -0000 On Jul 2, 2011, at 9:29 PM, Fred Baker wrote: >=20 > On Jul 1, 2011, at 5:24 PM, Cullen Jennings wrote: >=20 >> I'm sure this is a spectacularly clueless question but, .... could = someone say a bit more about why we need a routing protocol. >=20 Jari's answer more or less convinced me on why the IETF was going to = consider routing a good thing here. After I sent my questions, I saw = your draft come out which provided even more info on use cases where = routing would be needed. =20 > Well, if you draw a circle around the network so small that it = consists of exactly one router (figure 2 of = draft-baker-fun-multi-router), I guess we don't. However, I'll note that = (discussion on v6ops a few months back) existing IPv4 residential = gateways for the most part support a routing protocol - usually RIPv2. = If present residential gateways have that requirement for market = reasons, it does seem reasonable to expect future ones to. >=20 > I guess the question I would ask is not "why", but "given that there = is evidently a present market requirement, why not". Can you explain to = me why every residential gateway manufacturer save one - including = Linksys - is wrong? In the mid 90s it may have been a useful feature and some devices = shipped it. I'd be willing to bet that one of the reasons that vendors = ship it in new things today is because the other vendors have it on = their data sheets. I will note that on the NATs I have used, it is not = enabled by default. I'll doubt that RIPv2 is the best routing protocol = for just about anything yet I don't hear people kicking down the doors = at linksys asking for other routing protocols. There may be some set of = people that use it - I don't know who they are - it's clearly not widely = used. I don't think the fact RIPv2 is widely shipped convinces me one = way or the other that routing is needed. I find the types of arguments = in your draft more convincing to where it will be needed and where it = will not.=20 I tend to think that FUN should focus on home networks that have zero = manual configuration with the exception of setting the wireless key (and = I'd even like to see that simplified). Sure more complex things will be = useful too but the small percentage of homes that need the use the = complex thing will figure it out - its the ones that need the simple = thing that are the problem.=20 I'll note that more and more home stuff seems to be support VLANs for = guest type access and other segregation. I also wonder if we will see = more equipment that will detect if it is on the edge of the home network = or in the middle. If it is on the edge, it might act more like a NAT or = FW while if it is in the middle, it might act more like a bridge. In the = v4 space, NATs that do this have significantly improved how well things = that do broadcast based discovery work - like UPnP. I forget the stats = but I think Elliot was telling me a substantial fraction of recent UDP = port allocations were for broadcast based discovery protocols.=20 From listbounce-01@voort.ca Sun Jul 3 13:29:36 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E4F22801C for ; Sun, 3 Jul 2011 13:29:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpQBZt0AiblA for ; Sun, 3 Jul 2011 13:29:35 -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 720AA22801B for ; Sun, 3 Jul 2011 13:29:34 -0700 (PDT) Received: by iye7 with SMTP id 7so4972478iye.31 for ; Sun, 03 Jul 2011 13:29:34 -0700 (PDT) Received: by 10.42.161.70 with SMTP id s6mr6190625icx.374.1309724974248; Sun, 03 Jul 2011 13:29:34 -0700 (PDT) Received: from Kens-MacBook-Pro.local (76-10-173-233.dsl.teksavvy.com [76.10.173.233]) by mx.google.com with ESMTPS id my4sm3158259ibb.3.2011.07.03.13.29.30 (version=SSLv3 cipher=OTHER); Sun, 03 Jul 2011 13:29:32 -0700 (PDT) Message-ID: <4E10D11D.3090501@voort.ca> Date: Sun, 03 Jul 2011 16:29:17 -0400 From: Kenneth Voort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: fun@ietf.org References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> <4E0E2A75.6040207@dougbarton.us> <4E0FC683.6020900@dougbarton.us> In-Reply-To: <4E0FC683.6020900@dougbarton.us> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Barton , Keith Moore Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 20:29:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-07-02 9:31 PM, Doug Barton wrote: > On 07/01/2011 14:17, Keith Moore wrote: >> On Jul 1, 2011, at 4:13 PM, Doug Barton wrote: >> >>> This is an area that we very clearly do not need to get involved in >>> because it will solve itself due to market forces. Right now there >>> is no IPv6-only content that anyone cares about. When that changes, >>> users will start demanding that their provider give them access to >>> it, or vote with their feet. When that happens, the end-to-end (or perhaps site-to-site) model of the Internet will be broken. I would argue that the Internet is more about "reachability" than "content" or "conversation". When the day comes when it is no longer technically possible to reach any Internet-connected host who wants me to reach it, from anywhere, the Internet will be broken. While IPv6 has the promise to fix a great many things, it also carries with it the threat of breaking that fundamental assumption upon which the Internet is built. >> Whenever people talk about the Internet as if it were just about >> "access to content", I have to wonder. The Internet has always >> been more about conversation than content. > > The overwhelming majority of Internet users are consumers of content. Some of that content is stuff > like Skype, instant messaging, etc. > > The overwhelming majority of businesses that make the Internet work are the content providers, and > the ISPs that enable the consumers of that content to reach it. > > Failure to recognize these 2 critical facts leads to producing standards documents that have no > relevance in the real world. I agree with you to a point. Where I see a problem is in *new* content producers coming online. It's not possible anymore for there to be another service provider such as YouTube or Netflix, or for that matter another ISP like Comcast or BT, with the IPv4 space there is left. Until and unless we see massive IPv6 deployment we're stuck with the players we've got. Nobody's going to build another Netflix and just wait for the ISP's to get the users to them. The transition should be engineered, not simply left to existing market forces to evolve. > >>> To summarize my main point once again, there is nothing for the >>> IETF to do here, the problem will take care of itself. >> >> Quite the contrary. We still don't have a good transition mechanism >> that HOMENET could specify. > > And as I pointed out in the bits of my message that you snipped, we don't need one. > > > Doug Perhaps, perhaps not. But I do think the behavior of an IPv6 network/host/CPE in the absence of IPv6 connectivity, or where not all of [more than one] providers is IPv6, should be defined, at the least. We will otherwise see some surely unpredictable and incompatible behavior. Should it be assumed that the only IPv6 provider must therefore be the default IPv6 route? What if that provider is the power company? Or should a default IPv6 route *always* be established via the same interface as the default IPv4 route? Should home networks establish IPv6 connectivity where none exists? I would also argue that some method of reaching the IPv6 Internet without provider-supplied IPv6 should be considered and/or recommended. Is it within HOMENET's scope to /encourage/ IPv6 deployment, or merely /facilitate/ it? We agree that there will be a day when not every host on the Internet will be reachable from every other host. I think what we disagree on is the scope and severity of the problem, and when it will happen. It is my hope that most people never hear the term "IPv6". - -- Kenneth Voort - kenneth {at} voort {dot} ca FDF1 6265 EBAB C05C FD06 1AED 158E 14D6 37CD E87F | pgp encrypted email preferred -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk4Q0R0ACgkQFY4U1jfN6H/6pwCfePQLx1r9j7bQsCw8iK2aTGM7 sEsAni5VvOMZIPyJHqMWUr/Gba4vHzOq =fq54 -----END PGP SIGNATURE----- From joelja@bogus.com Sun Jul 3 16:22:31 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4842121F85F8 for ; Sun, 3 Jul 2011 16:22:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spiFlO86lv4q for ; Sun, 3 Jul 2011 16:22:30 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 534CC21F85EA for ; Sun, 3 Jul 2011 16:22:30 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p63NMRbE045158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Jul 2011 23:22:28 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4E0E46DC.90604@raszuk.net> Date: Sun, 3 Jul 2011 16:22:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6938EFAB-DCEA-44DF-B743-05894CA09902@bogus.com> References: <4E0DB36D.60303@raszuk.net> <7EC07A1A-CCD2-4A4A-A92D-8475430F558E@townsley.net> <4E0E409C.3050106@piuha.net> <4E0E46DC.90604@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Jul 2011 23:22:29 +0000 (UTC) Cc: fun@ietf.org Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 23:22:31 -0000 On Jul 1, 2011, at 3:14 PM, Robert Raszuk wrote: > Hi Jari, >=20 >> As Mark noted, some aspects of diagnostics and troubleshooting are >> inherent in the notion of automatic configuration. Prefix delegation, >> routing, etc. has to figure out if there is connectivity and what to = do >> if there isn't. But its mostly automatic, not built for human network >> managers to play with. >=20 > Well honestly while I agree that automation is great for vast majority = of home networks, unfortunately for someone like me it is just scary - = maybe too scary. If I buy or rent a car I always pick manual ... (maybe = wrong comparison maybe not ... but it is just a matter of awareness of = one's skills of control). If it doesn't work without intervention by the user, then the solution = adopted by the vendor will definitely not be compliant with the = specification. The condition of not requiring intervention is = essentially cooked in the the commercial acceptance of products in the = space. From ek@google.com Sun Jul 3 22:13:26 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302EE21F861C for ; Sun, 3 Jul 2011 22:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQoN6CXei2ir for ; Sun, 3 Jul 2011 22:13:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9B221F855F for ; Sun, 3 Jul 2011 22:13:24 -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 p645DN0k020339 for ; Sun, 3 Jul 2011 22:13:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309756404; bh=tVi6bkWcFpsfPLYdSlDxfZrEbtg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ozFKE4EJJcOBGKA0Wz/K42A1ciG7smn0EK3zxkbdNnGfYR1r3lSb66eny2MNxQNET rCAHn94F5zNeKYB+jcizg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=owz+t8lUSwWK/AS8dtY4resz3ZB7EXMYYR9JbxIe8h8r3r2Zvv9sTRwR7ogT1n7dF brAK9mVSMGTTUe+rjHVxw== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by hpaq14.eem.corp.google.com with ESMTP id p645DLbO009955 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 3 Jul 2011 22:13:22 -0700 Received: by pzk27 with SMTP id 27so3118000pzk.27 for ; Sun, 03 Jul 2011 22:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PKH3St7XblsmakY49siZSGU5CH0WhmJt2iJ5Rnae4EI=; b=aMBLk/7ZYbriRf/kvLnBFF+vh99SOTCnnS3vdBSlXAA6Eu6CZVjJMjcD7atkqZAGt4 +E0pDAtyDAUrHj3Xywgg== MIME-Version: 1.0 Received: by 10.142.242.6 with SMTP id p6mr2683963wfh.96.1309756400933; Sun, 03 Jul 2011 22:13:20 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Sun, 3 Jul 2011 22:13:20 -0700 (PDT) In-Reply-To: References: <20110701204301.069D218C14E@mercury.lcs.mit.edu> Date: Mon, 4 Jul 2011 14:13:20 +0900 Message-ID: From: Erik Kline To: james woodyatt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 05:13:26 -0000 > I suspect it wouldn't take much to adapt 6RD to these ends. =C2=A0Remembe= r, 6RD tunnels do *not* need to be terminated by the provider network. =C2= =A0They can be terminated by a third-party with minimal human interface bur= den. =C2=A0Perhaps I should find the time to write a draft on the topic. +1 This plus the idea of being able to map a public v6 address to an internal IPv4 address (the home gateway does the address family translation) and folks could have all manner of broader access that just what portmapping allows. If the mechanism could resync and adjust accordingly when the public IPv4 address changes (probably involving dyndns.org-like updates), then why not have multiple named webservers running at home (all on v6, port 80)? Things get more complicated if there's a CGN in the picture, but that could be addressed by separate efforts. From moore@network-heretics.com Mon Jul 4 05:33:22 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0296E1F0C34 for ; Mon, 4 Jul 2011 05:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pS9o5mqJg3x for ; Mon, 4 Jul 2011 05:33:21 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id CFEEC21F861E for ; Mon, 4 Jul 2011 05:33:20 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id E485E20C03; Mon, 4 Jul 2011 08:33:19 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 04 Jul 2011 08:33:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=NUISaELYzOPYsxhIuoW28+Dya+U=; b=ph5tpl/vWsTx3+loyS5XV9czfMTzB55D4dttfu70FRWS0O2DGy/Mnle3076O5mrh0aAJYRLg/zsSvK/6bYJuxFw6pNrW0bKZnCtGtWW0MML1Tx1iZONA8HWlY29MzirT14ehmb+PB525oRygSOpis6f8bCvuvpsPuBhMchbnHdQ= X-Sasl-enc: UY99yhlq4UbYn+usAr3aqWDLtoF0sOfAUenXPtNc1jgb 1309782799 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id DF7D3401281; Mon, 4 Jul 2011 08:33:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E10D11D.3090501@voort.ca> Date: Mon, 4 Jul 2011 08:33:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0E282B.1060400@voort.ca> <4E0E2A75.6040207@dougbarton.us> <4E0FC683.6020900@dougbarton.us> <4E10D11D.3090501@voort.ca> To: Kenneth Voort X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org, Doug Barton Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 12:33:22 -0000 On Jul 3, 2011, at 4:29 PM, Kenneth Voort wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11-07-02 9:31 PM, Doug Barton wrote: >> On 07/01/2011 14:17, Keith Moore wrote: >>> On Jul 1, 2011, at 4:13 PM, Doug Barton wrote: >>>=20 >>>> This is an area that we very clearly do not need to get involved in >>>> because it will solve itself due to market forces. Right now there >>>> is no IPv6-only content that anyone cares about. When that changes, >>>> users will start demanding that their provider give them access to >>>> it, or vote with their feet. > When that happens, the end-to-end (or perhaps site-to-site) model of = the Internet will be broken. I > would argue that the Internet is more about "reachability" than = "content" or "conversation". When > the day comes when it is no longer technically possible to reach any = Internet-connected host who > wants me to reach it, from anywhere, the Internet will be broken. = While IPv6 has the promise to fix > a great many things, it also carries with it the threat of breaking = that fundamental assumption upon > which the Internet is built. Maybe I'm missing something. How does IPv6 threaten that model? =20 If what you're worried about is that IPv4 and IPv6 can't talk to each = other: My take is that there will be considerable economic pressure to = reduce support costs associated with IPv4 once IPv6 support is = widespread. And I don't actually believe there will be any significant = amount of "content" that will be accessible only via IPv6 until 99% of = Internet users have IPv6. =20 (There may well be applications that only work with IPv6 long before = that. But unless there's some easy, general way to run IPv6 over IPv4 = that works pretty much everywhere, those applications will be limited to = niche markets.) People didn't stop sending email just because BITNET fell into disuse. = They just switched to using Internet email addresses. Keith From wwwrun@ietfa.amsl.com Tue Jul 5 09:35:28 2011 Return-Path: X-Original-To: fun@ietf.org Delivered-To: fun@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 66BAF22801D; Tue, 5 Jul 2011 09:35:28 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110705163528.66BAF22801D@ietfa.amsl.com> Date: Tue, 5 Jul 2011 09:35:28 -0700 (PDT) Cc: fun@ietf.org Subject: [fun] WG Review: Home Networks (homenet) X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 16:35:28 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 12, 2011. Home Networks (homenet) ----------------------------------- Current Status: Proposed Working Group Last Edit: Thursday, June 30th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small Òresidential homeÓ networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liase with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, and UPnP Forum is necessary. Milestones: Jul 2011 Formation of the working group Sep 2011 First WG draft on the architecture Dec 2011 Submission of the architecture draft to the IESG as Informational RFC Dec 2011 Charter re-evaluation based on the architecture work Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2012 First WG draft on name resolution Feb 2012 First WG draft on service discovery Feb 2012 First WG draft on perimeter security Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Sep 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Nov 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Dec 2012 Submission of the perimeter security draft to the IESG as Informational RFC From moore@network-heretics.com Tue Jul 5 10:18:43 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68E522802A; Tue, 5 Jul 2011 10:18:43 -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.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqcN0eJGi7xM; Tue, 5 Jul 2011 10:18:41 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 188CC228022; Tue, 5 Jul 2011 10:18:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 94532207B5; Tue, 5 Jul 2011 13:18:40 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 05 Jul 2011 13:18:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=TmQAxrZNHZF55bsuEX0bp5ISRRc=; b=qAZlFNbCc+qKwyzPHWgSIGWiPp+UTWHHJH64bJ1aCXTsslLaj2NmHR0pGs4h/N1z0J/NOm9LtQVRaid+XnW1Q5my61ZzKa2STFk6exziHe//7+bNRUnr5HXRiAxpgYEu8AJZmrQtzoMotn3zCvdAYjDt6+ww2cFXsL+UfPW2LWg= X-Sasl-enc: xD1L8Zb2hqFdVQWIsjTDkoeCXILtl3Vz+uLQhCl6203q 1309886319 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A3161443CD0; Tue, 5 Jul 2011 13:18:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110705163528.66BAF22801D@ietfa.amsl.com> Date: Tue, 5 Jul 2011 13:18:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <376F5BEA-61A0-46B4-A367-D69A74C28C96@network-heretics.com> References: <20110705163528.66BAF22801D@ietfa.amsl.com> To: iesg@ietf.org X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org Subject: Re: [fun] WG Review: Home Networks (homenet) X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 17:18:43 -0000 >=20 > The purpose of this working group is to focus on this evolution, in > particular as it addresses the introduction of IPv6, by developing an > architecture addressing this full scope of requirements: >=20 > o prefix configuration for routers > o managing routing > o name resolution > o service discovery > o network security it seems like host/device security, as distinguished from network = security, should also be in this list. ease of configuration would appear to be paramount, and this touches on = the interface between hosts/devices and the home network, particularly = any perimeter based security mechanisms. I'm thinking that when someone = gets a new device, they might need to "pair" it with their network = (similar to Bluetooth devices) so that the perimeter security devices = know to allow traffic for it (and what kinds of traffic to allow). = similarly, hosts which have permission to access such devices from = outside of the home network might also need to be "paired".=20 one of the questions that I have is: to what extent is it reasonable to = expect that network-accessible devices made for use in homes (and hosts = that talk to them) are different than network-accessible devices used in = other environments (and the hosts that talk to them)? offhand I'm = thinking that you want to be able to support ordinary hosts, devices, = and applications on home networks, but it might take a bit more work to = get their traffic through perimeter security. similarly, you want to be = able to enable ordinary hosts to talk to things on the home network, but = doing so might be more cumbersome than for hosts with the appropriate = support built-in. there are multiple approaches for external access = that could be considered: proxies, IPsec, tunnels, etc. one thing that = should be clear up front, is that using ip addresses for authentication = tokens is a bad idea, no matter how widespread the practice is. I guess I think that there's a real need to develop a standard means to = arrange for secure external access to internal devices that are granted = permission for such access. > The task of the group is to produce an architecture document that > outlines how to construct home networks involving multiple routers and > subnets. This document is expected to apply the IPv6 addressing > architecture, prefix delegation, global and ULA addresses, source > address selection rules and other existing components of the IPv6 > architecture. I don't think it should be presumed that ULA's are applicable. Perhaps, = but not certainly. ULAs should be limited to devices for which there is = never any need to be accessed from outside the network, or to access = external hosts, and offhand I can't think of a situation that makes it = reasonable to impose this limitation on every device on a network = segment.. If ULAs can be doled out to only those devices that do not = have permission for external access, independent of network segment, = that might be fine.=20 Keith