From teco@inf-net.nl Mon Oct 1 00:19:57 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F8D21F84CF for ; Mon, 1 Oct 2012 00:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+co5x5InLyv for ; Mon, 1 Oct 2012 00:19:55 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2476221F84A7 for ; Mon, 1 Oct 2012 00:19:54 -0700 (PDT) Received: by eekd4 with SMTP id d4so2331259eek.31 for ; Mon, 01 Oct 2012 00:19:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=m8tX7cZytK1Q8q0rtt4r7kOBGmCKO9Eb78ejjrAW/LU=; b=HjmkCn2tcVSM4ppZbvQ0zfhkWof0F7P4AIR4Po1HxORvsx5CjrQvzynWasKDa3XJbp 0u9DUwa+ZyWzEk24KXb4hDvP+hYjl4j2o+vN66gFUiibApsuaSDcAD27ih99yEOnhJee Jq0Ct1Z7eDoYgYxnlWLgbb+UbWj4MmidFVBglMnv/e1JOCujhE2ArqSuU7FEf1kfCyPp MT1wu9I3esVZH4Ff/gUcgHzmQ528qLokLMCDvi9C1ckhwWsxCFG9bPuYVrwokmt68EDR RwiYWh7sWq8vHX0QTUIHrPwOWiOGd8pUbP8ioJIYCoe1BZKHLhCcnYg3oTKNpS6KARo5 z2Cg== Received: by 10.14.205.9 with SMTP id i9mr17083895eeo.21.1349075993578; Mon, 01 Oct 2012 00:19:53 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id c6sm7296419eep.17.2012.10.01.00.19.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 00:19:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <201209302302.q8UN2o0T027602@gateway1.orleans.occnc.com> Date: Mon, 1 Oct 2012 09:19:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <681E5F7C-D17A-40C2-8C34-6AB8B5F541CB@inf-net.nl> References: <201209302302.q8UN2o0T027602@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkl9PQifH1nPczAl4LtOnIR3biw9tU6voNipgRxSeISK45YBd0iqXuKTP493jboclYNb4L/ Cc: robert.cragie@gridmerge.com, homenet@ietf.org, Don Sturek Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 07:19:57 -0000 Op 1 okt. 2012, om 01:02 heeft Curtis Villamizar het volgende = geschreven: >=20 > In message <0ABFEE76-7737-41B7-96E1-8D90A0EFFC35@inf-net.nl> > Teco Boot writes: >=20 >>=20 >> Op 25 sep. 2012, om 21:55 heeft Don Sturek het volgende geschreven: >>=20 >>> Hi Teco, >>>=20 >>> The main requirement I see is that a home network with multiple ISP >>> connections, multiple CERs and a shared subnet must support the = ability to >>> discover services within the entire site (home) despite having = devices >>> with differing ULA prefixes and GUA prefixes. >>>=20 >>> How would you see discovery working in such a home network? >>=20 >> It might be the right moment to come up with my earlier work on = border=20 >> router discovery. I have to update to incorporate the homenet-arch, = and >> remove details for MANET/Autoconf. Intro & highlights: >> http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt >>=20 >> If there is interest, I'll resubmit for Homenet.=20 >>=20 >> Teco >=20 >=20 > Just looked at that draft. Thanks. > It solves one of the problems, having more > than one GUA prefix. It does not solve another closely related > problem, having more than one subnet behind the CER or border routers > (BR101 and BR201 in your diagram) where there is no prior > configuration. It does solve that problem, if I understand you correctly. Each of those subnets (out of a prefix) is managed on it's own:=20 the CER (BR) assigns an address & subnet out of these prefixes on the=20 interface(s) in the Homenet, and sends out a Border Router Information=20= Option (BRIO) for each of it. The downstream routers gets a subnet for=20= each prefix, if there is no subnet discovered for it already. This function is great for renumbering events. /^^^^^^^^^^^^^^^^^^^^^^\ / \ { The Internet } \ / \______________________/ / =20 /(2001:8DB:100::/40) +=3D=3D=3D=3D=3D=3D=3D+ =20 [ ISP_1 ] =20 +=3D=3D=3D=3D=3D=3D=3D+ =20 |(2001:8DB:101::/48)=20 |(2001:8DB:102::/48) =20 +--------+ =20 | BR_101 | =20 +--------+ =20 | FE80::101/64 =20 | 2001:8DB:101:1::101/64 | 2001:8DB:102:1::101/64 | =20 -+---------------------+---+- | 2001:8DB:101:1::1/64 |=20 2001:8DB:102:1::1/64 | FE80::1/64 | +-------+ | R_1 | +-------+ | 2001:8DB:101:1::1234/64 |=20 2001:8DB:102:1::1234/64 | FE80::1234/64 | +-----------+ | Host_1234 | +-----------+ >=20 > In your "Figure 2: Scenario 2" all routers have the same set of > addresses on each of their interfaces. This is not generally how > subnets are laid out. You mean the interface addresses can have different InterfaceID's?=20 Yes, this is true, I'll adjust. I used "node-id" as InterfaceID, this is somewhat misleading.=20 I draw only a GUA on router interface pointing to the ISP. Other GUA's are allowed but less useful. > Each interface on a router gets a different > link local address. The /48 is usually split into a set of /64, one > per subnet. =20 Sure, this is what I propose. > In a managed network (enterprise, clueful soho, etc) the > split of a /48 into 16 or less /64s today is done by configuration > (configuration of prefixes on the routers or DHCP server and relays). So we should do in Homenets, but now fully automatic. Managed networks can follow the Homenet autoconfiguraton, if we do our=20= work correctly. Teco >=20 > Curtis >=20 >=20 >>> Don >>>=20 >>>=20 >>>=20 >>>=20 >>> On 9/25/12 12:34 PM, "Teco Boot" wrote: >>>=20 >>>> Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven: >>>>=20 >>>> Sorry to jump in. >>>>=20 >>>>> Hi Robert, >>>>>=20 >>>>> One more point touched on in your note below: >>>>> 1) Ideally, it would be great if a single authorizatative device >>>>> existed >>>>> in the home providing DHCPv6 server services (if supported) and = prefix >>>>> delegation. >>>> I don't agree. When adding another gateway, to another ISP, I would = like >>>> such to be independent form the existing gear. >>>> (3.2.2.2. B: Two ISPs, Two CERs, Shared subnet) >>>>=20 >>>>=20 >>>>> One challenge in the description below is having multiple routers = on >>>>> multiple subnets, each possibly acting as a DHCPv6 server within = their >>>>> own >>>>> subnet and also providing their own ULA prefix. >>>> When hosts get their addresses for each RA prefix, by using SLAAC = and/or >>>> DHCPv6, what is the challenge? (protocol-wise, not current host = behavior) >>>>=20 >>>> When hosts get only one GUA, they will use only one link to one ISP = (no >>>> translation). For multi-path, this needs an update. >>>>=20 >>>>>=20 >>>>> We certainly don't want to further confuse address assignment in a >>>>> setting >>>>> where IT support does not exist. >>>> Agreed, we need to improve address assignment. And routing based on >>>> destination & source addresses. >>>>=20 >>>> Teco >>>>=20 >>>>>=20 >>>>> Don >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 9/25/12 1:57 AM, "Robert Cragie" = wrote: >>>>>=20 >>>>>> So let's tweak Curtis' sequence slightly: >>>>>>=20 >>>>>> What every host does is: >>>>>>=20 >>>>>> if it has no MAC: >>>>>> pick a random link local address >>>>>> else >>>>>> use the MAC to create a link local address >>>>>> run DAD to make sure no one else has same address >>>>>>=20 >>>>>> send a RS >>>>>>=20 >>>>>> if it gets RA >>>>>> use the RA prefix for SLAAC >>>>>> else >>>>>> time out and don't bother with SLAAC; can only use link local = address >>>>>>=20 >>>>>> then hopefully the host also does the following: >>>>>>=20 >>>>>> send DHCPv6 client request >>>>>>=20 >>>>>> if response >>>>>> it has yet another address to pick from if it got one using SLAAC >>>>>> else >>>>>> time out and get nothing from DHCPv6 >>>>>>=20 >>>>>> This should work fine for legacy APs where everything is bridged >>>>>> underneath it. Where it gets interesting is in the case of = cascaded >>>>>> subnets behind a router connected to an ISP, where one or more of = those >>>>>> subnets may be a mesh network comprised of mesh routers and = hosts. I am >>>>>> not quite sure how ULAs and DHCPv6 would work in this case as = there are >>>>>> limitations as far as I can see (although I accept I probably = have a >>>>>> bit >>>>>> more reading to do on the subject). >>>>>>=20 >>>>>> Robert >>>>>>=20 >>>>>> On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >>>>>>> In message >>>>>>> Don Sturek writes: >>>>>>>=20 >>>>>>>> Hi Curtis, >>>>>>>>=20 >>>>>>>> I think the difficulty is each device cannot "use the MAC to = create a >>>>>>>> ULA >>>>>>>> address". Some authoritative device in the network (eg, the = AP) must >>>>>>>> create the ULA prefix. If a ULA prefix is not present because = the AP >>>>>>>> is a >>>>>>>> legacy device not capable of providing a ULA prefix, the STA = devices >>>>>>>> must >>>>>>>> use link locals only. >>>>>>>>=20 >>>>>>>> Don >>>>>>>=20 >>>>>>> Don, >>>>>>>=20 >>>>>>> You are right about there being nothing to generate the ULA = prefix in >>>>>>> your example. My mistake. >>>>>>>=20 >>>>>>> But it doesn't change anything. If the AP is a dumb bridge and = there >>>>>>> is no router of any kind, then link local addresses are = perfectly >>>>>>> fine. There is only one subnet in that example, and ULA is not >>>>>>> needed. That was the example you gave. >>>>>>>=20 >>>>>>> Your example had no router just an old AP that acted as a = bridge, >>>>>>> therefore nothing to generate any sort of RA. If there is a = router >>>>>>> and no GUA prefix (which is not your example, but a useful = example), >>>>>>> then ULA can be used. The only RA that is seen is the RA = providing a >>>>>>> ULA prefix which the router can generate. >>>>>>>=20 >>>>>>> I did say that the possibility of having to subdivide a /64 only >>>>>>> exists for GUA. If a router exists which gets a GUA from a = provider, >>>>>>> and there are more subnets than the prefix length can support = the two >>>>>>> options are the ones listed below. (Search for --or--). >>>>>>>=20 >>>>>>> Curtis >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 9/24/12 6:52 PM, "Curtis Villamizar" = wrote: >>>>>>>>=20 >>>>>>>>> In message >>>>>>>>> Don Sturek writes: >>>>>>>>>=20 >>>>>>>>>> Hi Curtis, >>>>>>>>>>=20 >>>>>>>>>> I would expect most Wi-Fi AP manufacturers to support the = same >>>>>>>>>> address >>>>>>>>>> assignment they do today (ie, manual assignment and DHCP). I = would >>>>>>>>>> also expect as more IPv6 deployments happen that SLAAC will = also be >>>>>>>>>> supported (and, yes, even for GUA). >>>>>>>>>>=20 >>>>>>>>>> For the types of devices which will be added to Wi-Fi = networks in >>>>>>>>>> the >>>>>>>>>> future (eg, headless devices like appliances, thermostats, = etc.) >>>>>>>>>> that >>>>>>>>>> the preferred address assignment will be SLAAC and DHCPv6 = (and, >>>>>>>>>> yes, >>>>>>>>>> I >>>>>>>>>> purposely did not remove SLAAC.....) >>>>>>>>>>=20 >>>>>>>>>> Don >>>>>>>>>=20 >>>>>>>>> Don, >>>>>>>>>=20 >>>>>>>>> We seem to be talking past each other so let me again try to = be >>>>>>>>> clear. >>>>>>>>>=20 >>>>>>>>> What every host does is: >>>>>>>>>=20 >>>>>>>>> if it has no MAC: >>>>>>>>> pick a random link local (not ULA) address >>>>>>>>> else >>>>>>>>> use the MAC to create a ULA address >>>>>>>>> run DAD to make sure no one else has same address >>>>>>>>>=20 >>>>>>>>> send a RS >>>>>>>>>=20 >>>>>>>>> if it gets RA >>>>>>>>> use the RA prefix for SLAAC >>>>>>>>> else >>>>>>>>> time out and don't bother with SLAAC >>>>>>>>>=20 >>>>>>>>> then hopefully the host also does the following: >>>>>>>>>=20 >>>>>>>>> send DHCPv6 client request >>>>>>>>>=20 >>>>>>>>> if response >>>>>>>>> it has yet another address to pick from if it got one using = SLAAC >>>>>>>>> else >>>>>>>>> time out and get nothing from DHCPv6 >>>>>>>>>=20 >>>>>>>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 = server >>>>>>>>> the address that it already has (from SLAAC). >>>>>>>>>=20 >>>>>>>>> If as in the case of your Wi-Fi with a bridging AP example, = there is >>>>>>>>> no router to give it an DHCPv6 the link local or ULA addresses = are >>>>>>>>> still there and still usable. There is also no router to give = it an >>>>>>>>> RA response so it has no SLAAC assigned address and no DHCPv6 >>>>>>>>> assigned >>>>>>>>> address. >>>>>>>>>=20 >>>>>>>>> That is the end of your example. >>>>>>>>>=20 >>>>>>>>> If there is a router then there is something that can hand out = a RA >>>>>>>>> or >>>>>>>>> DHCPv6 response. >>>>>>>>>=20 >>>>>>>>> In the case were there exists multiple subnets and the CER has = been >>>>>>>>> granted a /64 (or too few /64s to handle the number of = subnets), >>>>>>>>> then: >>>>>>>>>=20 >>>>>>>>> it can use RA with /64 on some subnets and give them GUA = addresses >>>>>>>>> and some subnets have no access outside the homenet >>>>>>>>>=20 >>>>>>>>> --or-- >>>>>>>>>=20 >>>>>>>>> it can not use RA (and therefore prevent SLAAC from being = used) and >>>>>>>>> hand out DHCPv6 addresses and make use of prefixes longer than = /64. >>>>>>>>> This prevents the use of CGA but get connectivity to the = entire >>>>>>>>> homenet. >>>>>>>>>=20 >>>>>>>>> If every consumer oriented provider is willing to allocate = prefixes >>>>>>>>> shorter than /64 on request to home users, then the above = situation >>>>>>>>> never occurs. If it does, my argument is that the second = option >>>>>>>>> above >>>>>>>>> is better than the first. >>>>>>>>>=20 >>>>>>>>> Curtis >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" = wrote: >>>>>>>>>>=20 >>>>>>>>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>>>>>>>> Jim Gettys writes: >>>>>>>>>>>=20 >>>>>>>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Here is the use case: >>>>>>>>>>>>> 1) Customer has a legacy AP in their house >>>>>>>>>>>>> 2) Customer brings home new devices supporting IPv6 = (which are >>>>>>>>>>>> designed >>>>>>>>>>>>> to communicate only with other IPv6 based devices in the = home) >>>>>>>>>>>>> 3) The only way these new devices can communicate is = through >>>>>>>>>> address >>>>>>>>>>>>> assignment using SLAAC and then some discovery method the = two >>>>>>>>>>>>> new >>>>>>>>>>>> devices >>>>>>>>>>>>> support (without support from the AP). Here these devices = are >>>>>>>>>>>> assuming >>>>>>>>>>>>> bridging through the AP...... >>>>>>>>>>>>=20 >>>>>>>>>>>> And since current legacy AP's all bridge, we win (even = though we >>>>>>>>>> need to >>>>>>>>>>>> route in the future). >>>>>>>>>>> Jim, >>>>>>>>>>>=20 >>>>>>>>>>> The point was how do you get local IPv6 within the home with = the >>>>>>>>>>> legacy AP that does only IPv4 and just does bridging of = IPv6. >>>>>>>>>>> First >>>>>>>>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>>>>>>>>=20 >>>>>>>>>>> In this case you use link local or if everything has a MAC = you can >>>>>>>>>>> use >>>>>>>>>>> ULA based on the MAC addressses. >>>>>>>>>>>=20 >>>>>>>>>>>>> Placing a requirement that every customer who buys a new = IPv6 >>>>>>>>>> device, >>>>>>>>>>>>> intended to communicate only with other IPv6 devices in = the >>>>>>>>>>>>> home, >>>>>>>>>> will >>>>>>>>>>>>> require a forklift upgrade of a deployed network in order = to >>>>>>>>>>>>> work >>>>>>>>>>>> will not >>>>>>>>>>>>> be popular. >>>>>>>>>>>>=20 >>>>>>>>>>>> Good point. >>>>>>>>>>> But invalid. The use case Don gave would still work fine. = Only >>>>>>>>>>> GUA >>>>>>>>>>> addresses are affected. >>>>>>>>>>>=20 >>>>>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, >>>>>>>>>>>> anyway* >>>>>>>>>>>> in >>>>>>>>>>>> the home environment. >>>>>>>>>>>>=20 >>>>>>>>>>>> The loathing comes from the exquisite pain of suffering = with a >>>>>>>>>>>> flaky >>>>>>>>>>>> home network for several months, before realising I had a = rogue >>>>>>>>>>>> DHCP >>>>>>>>>>>> server somewhere on my network (from wireshark). I then = had to >>>>>>>>>>>> take >>>>>>>>>> the >>>>>>>>>>>> mac address, figure out who may have manufactured some = device >>>>>>>>>>>> from >>>>>>>>>> that >>>>>>>>>>>> information, and finally figured out the little VOIP ATA = adaptor >>>>>>>>>>>> I >>>>>>>>>> had >>>>>>>>>>>> been given liked to do DHCP. >>>>>>>>>>> It did DHCP on the *WAN side*? You didn't put the rest of = your >>>>>>>>>>> network behind the VOIP box on the LAN side I hope. >>>>>>>>>>>=20 >>>>>>>>>>>> This was by far the hardest debugging I've had to do in my = home >>>>>>>>>> network >>>>>>>>>>>> in normal operation. >>>>>>>>>>>>=20 >>>>>>>>>>>> This is well beyond normal home debugging capability of >>>>>>>>>>>> consumers. >>>>>>>>>>>> - Jim >>>>>>>>>>> We all have plenty of crappy IPv4 product horror stories. = My VOIP >>>>>>>>>>> phone locked up now and then and I figured out that if the = call >>>>>>>>>>> lasted >>>>>>>>>>> longer than the DHCPv4 lease, then it lost the least because = it >>>>>>>>>>> didn't >>>>>>>>>>> try to renew it. Not only did the call drop, but the device >>>>>>>>>>> locked >>>>>>>>>>> up. The first solution was to reboot it now and then. The = answer >>>>>>>>>>> was >>>>>>>>>>> to configure a fixed address. I was lucky to figure it out = before >>>>>>>>>>> my >>>>>>>>>>> wife threw the phone through a window. For all I know a = later >>>>>>>>>>> firmware upgrade might have fixed it. VOIP might be more = popular >>>>>>>>>>> if >>>>>>>>>>> VOIP phones under $600 worked reasonably well. >>>>>>>>>>>=20 >>>>>>>>>>> Both nice stories, but both are DHCPv4 related and have = nothing at >>>>>>>>>>> all >>>>>>>>>>> to do with SLAAC. >>>>>>>>>>>=20 >>>>>>>>>>> Curtis >>>>>>>>>>>=20 >>>>>>>>>>>>> Don >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" = >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> In message >>>>>>>>>>>>>> Don Sturek writes: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Don >>>>>>>>>>>>>> Don, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>>>>>> concerned. >>>>>>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. = Joel >>>>>>>>>> brought >>>>>>>>>>>>>> up ILNP in private email, but I beleive ILNP can also = work as >>>>>>>>>>>>>> the >>>>>>>>>>>>>> constraints in ILNP are in the ILNP identifier which is = not the >>>>>>>>>> same >>>>>>>>>>>>>> as the interface address in ILNP for which there is no >>>>>>>>>>>>>> constraint. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have subnets running fine using a few /112 allocated = from >>>>>>>>>> within a >>>>>>>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops = and >>>>>>>>>> DHCPv6 >>>>>>>>>>>>>> for dynamic allocations for laptops. It works fine. = Link >>>>>>>>>>>>>> local >>>>>>>>>>>>>> addresses are all that is needed to get DHCPv6 to work. = No >>>>>>>>>>>>>> host >>>>>>>>>> ever >>>>>>>>>>>>>> receives a RA since my routers won't give them one, so no = host >>>>>>>>>> ever >>>>>>>>>>>>>> tries to generate an address using SLAAC. The only = constraint >>>>>>>>>>>>>> is >>>>>>>>>>>> that >>>>>>>>>>>>>> any host connecting to my Ethernet or wireless must run a = DHCP >>>>>>>>>> client >>>>>>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. = DHCPv4 >>>>>>>>>>>>>> and >>>>>>>>>>>>>> DHCPv6 servers are available in every subnet except one = GbE >>>>>>>>>> subnet in >>>>>>>>>>>>>> the rack and to a few hosts in my home office. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> So as far as I am concerned we have an assertion that no = SLAAC >>>>>>>>>>>>>> is >>>>>>>>>> a >>>>>>>>>>>>>> problem and existance proof that it is not. Beside CGA = and >>>>>>>>>> requiring >>>>>>>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can = I not >>>>>>>>>>>> support >>>>>>>>>>>>>> on these /112 subnets? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Curtis >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" = >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The argument on /64 as the longest prefix is not that = it is >>>>>>>>>>>> magically >>>>>>>>>>>>>>>>> unnatural. >>>>>>>>>>>>>>>>> Rather, it is that there are a number of current and >>>>>>>>>>>>>>>>> evolving >>>>>>>>>>>>>>> protocols >>>>>>>>>>>>>>>>> that depend upon that /64. The obvious example is = that >>>>>>>>>>>>>>>>> SLAAC >>>>>>>>>> does >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The rules in this regard are written into approved = RFCs. If >>>>>>>>>>>> homenet >>>>>>>>>>>>>>>>> wants to change that, it really needs to go to 6man = with a >>>>>>>>>> strong >>>>>>>>>>>>>>> case. >>>>>>>>>>>>>>>>> (for point-to-point inter-router links this was = recently >>>>>>>>>>>> relaxed. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> At the same time, andy operator who insists on giving = homes >>>>>>>>>>>>>>>>> a >>>>>>>>>> /64 >>>>>>>>>>>> is >>>>>>>>>>>>>>>>> being inappropriately restrictive. Homenet should say = that, >>>>>>>>>>>> rather >>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>> Joel, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>>>>>>>> responding. >>>>>>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but = DHCPv6 will >>>>>>>>>>>>>>>> so >>>>>>>>>>>> IMHO >>>>>>>>>>>>>>>> no loss. CGA also won't work but then again I've also = never >>>>>>>>>> been a >>>>>>>>>>>>>>>> fan of security half measures. Yes anti-spoofing = without >>>>>>>>>>>>>>>> prior >>>>>>>>>>>>>>>> exchange of a key is nice, but no reasonable = authorization >>>>>>>>>> could be >>>>>>>>>>>>>>>> based on CGA without also exchanging some sort of key = or cert >>>>>>>>>> and >>>>>>>>>>>> at >>>>>>>>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> If SLAAC and CGA are the only things that break *and* >>>>>>>>>>>>>>>> providers >>>>>>>>>> do >>>>>>>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes = will >>>>>>>>>> have >>>>>>>>>>>> to >>>>>>>>>>>>>>>> be subdivided. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> So a question for you is what else if anything will = break? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I also understand that you are suggesting that this be = taken >>>>>>>>>>>>>>>> to >>>>>>>>>>>> 6man. >>>>>>>>>>>>>>>> That is a good suggestion. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Curtis >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>> using >>>>>>>>>>>>>>>>>> subnets longer than /64 is OK as long as they = are >>>>>>>>>>>>>>>>>> not >>>>>>>>>>>> leaked >>>>>>>>>>>>>>>>>> into global routing. Please read the text and >>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>>>> exploding on this topic. It may be necessary to >>>>>>>>>> subnet a >>>>>>>>>>>>>>> /64 >>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>> that is all a provider will give you and you = need >>>>>>>>>> subnets. >>>>>>>>>>>>>>> It >>>>>>>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>>>>>> subnetting a >>>>>>>>>>>>>>> class-A >>>>>>>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 = and >>>>>>>>>> not >>>>>>>>>>>>>>> using >>>>>>>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC = implementations >>>>>>>>>> would >>>>>>>>>>>>>>>>>> likely try to use the whole bottom 64). From damien.saucez@gmail.com Mon Oct 1 00:32:17 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BB321F859B for ; Mon, 1 Oct 2012 00:32:16 -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 hb6w18ErV2Tf for ; Mon, 1 Oct 2012 00:32:16 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A28E521F8588 for ; Mon, 1 Oct 2012 00:32:15 -0700 (PDT) Received: by eekd4 with SMTP id d4so2337712eek.31 for ; Mon, 01 Oct 2012 00:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WWXUmenvwZ9gKLhjKThG3EVIu3ND4VD9yHWxZw6tmks=; b=UuukK+XYIHsA7gt6E6b+YCJdPQOJ6SmPL9kIlJ5Kwl11XQlVQF3Z7oB2VOeR7fq3ga 6GhwYIYKrMIbxQnWRWEZ5flHDBLu3UyxJVs8llJzR37xC1h8bL4mjuf3KYzl8hfy4nnh 5RKe9rF6YWJ4MxIXDmse7JYS8WvjmRjWIdDq5GnDWn0zNJ/qpaPGPpHiI083OhM79/P1 +mffWAGSc92PphA7hgVOSSP1gVj+OncPiLKXne9DDMay5gK7rBxkbtEYX2BJ/P2o2qrv qssrPJzBVIU1Gt/t8lXRosBSX4EFbmUpobtAHetePmv2mK1DYj46AbCfJfDcg3Lv2m6d AWfQ== Received: by 10.14.202.131 with SMTP id d3mr17135025eeo.32.1349076734654; Mon, 01 Oct 2012 00:32:14 -0700 (PDT) Received: from [192.168.1.4] (19.64-247-81.adsl-dyn.isp.belgacom.be. [81.247.64.19]) by mx.google.com with ESMTPS id i1sm12164597eeo.8.2012.10.01.00.32.13 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 00:32:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Damien Saucez In-Reply-To: <201210010121.q911Lsbp031067@gateway1.orleans.occnc.com> Date: Mon, 1 Oct 2012 09:32:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C25872F-9E9D-49B4-BEDA-C82E0EBC485F@gmail.com> References: <201210010121.q911Lsbp031067@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1498) Cc: "homenet@ietf.org Group" , Wassim Haddad Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 07:32:17 -0000 Curtis, Thank you for the comments. Our target in this document is to raise the question of multihoming in personal and/or small/medium enterprise networks, so for now we were not looking at the mobile device such as smartphones connected to both 4g and wifi (for this, the multihoming solution must be implemented directly on the device). We believe that SOHO would be interested being multihomed but can't afford the cost of operating multihoming themselves. This is why we suggest the MSP which is a way to outsource multihoming complexity. Now, let's go to the technical part. We didn't want to provide solution so far but we had in mind the following: 1. traffic is tunnelled between the network and the MSP. 2. addresses assigned to devices in the network belong to the MSP (or at least are advertised by the MSP in BGP) and then they never change. 3. the MSP box has one "wire" (possibly vie wifi or 3/4G) per ISP to which the network is connected and each NIC connected to this "wire" receives addresses dynamically. Putting these three points together, it means that the gw are invisible to the devices in the network, that addresses of devices never change during communications and that traffic always go through the MSP (even though it is possible to avoid this). I agree that there is no such thing as the MSP so far, but there is a bunch of very big service providers that exist today, that are peering with virtually every significant network and that would certainly be happy to be the "first hop" for all the communications. Thank you, Damien Saucez On 01 Oct 2012, at 03:21, Curtis Villamizar wrote: >=20 > In message <08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> > Wassim Haddad writes: >=20 >> Dear all, >>=20 >> We have submitted a problem statement for multihoming in homenet. >> Comments appreciated! >>=20 >> Regards, >>=20 >> Wassim H. >=20 >=20 > Wassim, >=20 > You are proposing a solution, not submitting a problem statement. >=20 > A problem with your solution is that the most common multihoming is > the mobile device having IP access through both WiFi (via DSL or cable > or hotspot) and 4G mobile. In this case the "MSP middlebox" you > propose would have to be inside the mobile device, which is already > both one of the gateways and the end host. >=20 > Another problem is the current non-existance of a Multihoming Service > Provider (MSP)" somewhere out "in the cloud" to replace the source > address of packets. >=20 > No where in your document does the principle issue with multihoming > get addressed. The source address used by the host must be chosen > somehow by the host or replaced somewhere. The function of the "MSP > middlebox" as described is only to redirect outgoing packets. If the > source address reflect going through ISP2, and that link goes away, > then the packets can now go out through ISP1 but the problem of using > the wrong source address remains. >=20 > If the source address is somehow provided by the MSP, then the traffic > has to be tunnelled from MSP middlebox to MSP as might be implied by > the last paragraph in section 4 where it says "In addition, if Gw1 and > Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the > MSPMB will be configured automatically as well". The word "address" > barely appears in the draft except for the prior statement and one in > the intro saying why Shim6 or MPTCP should not be used. The word > "tunnel" doesn't appear at all. The word "source" (as in "source > address") doesn't appear at all. >=20 > So you don't seem to be proposing a viable solution or perhaps you had > something to do with tunnelling in mind that you didn't describe at > all clearly. >=20 > Curtis >=20 >=20 >> Begin forwarded message: >>=20 >>> From: "internet-drafts@ietf.org" >>> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt >>> Date: September 25, 2012 10:55:38 AM PDT >>> To: "i-d-announce@ietf.org" >>> Reply-To: "internet-drafts@ietf.org" >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : Multihoming in Homenet >>> Author(s) : Wassim Haddad >>> Damien Saucez >>> Joel Halpern >>> Filename : draft-haddad-homenet-multihomed-00.txt >>> Pages : 7 >>> Date : 2012-09-25 >>>=20 >>> Abstract: >>> So far, multihoming in Homenet must be supported by the hosts as >>> there is no mean to use simultaneously the different Internet = Service >>> Providers of the "Homenet" without risking flow disruption. In = this >>> memo, we describe the problem statement for multihoming in Homenet. >>> We also propose a high level solution that answers this particular >>> problem. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Mon Oct 1 05:33:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883C11F0C82 for ; Mon, 1 Oct 2012 05:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbCovxPUzy3s for ; Mon, 1 Oct 2012 05:33:09 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE7931F0C91 for ; Mon, 1 Oct 2012 05:33:08 -0700 (PDT) Received: by iec9 with SMTP id 9so13794816iec.31 for ; Mon, 01 Oct 2012 05:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VE08LrN+AWq+5z1RQ03OaBNrHqdRCddJ2/X3q3zIUJ0=; b=Cxlp7j9QENev9xkPI8U2I2e0+Tu2/LVpMw72A7DR0emzsakNVgFNUjvPRyYzDBZ4/B jA+NB+67QCJvt8L1UDQaULAURflwb9gjY6CXQfL6vTUYZ3MvuKcReOSaw0u+EBqhlqma BdsloR4iC2roTTWggn+vJqGUhlqiv7kR7i/405p58GSjCe9iYIp2SgLaa+yuTzoTIcEH 9DmD/O/Ppvt+tAB3cLAIXLk9XnaVDc9a7odaqASV+gAeAXoA4EG2BZHWF4LPNObYZ0rZ 0yShlARjlOQbxsBjw12QQ6zkIt+xpKVlz6IBJ5SpQcMSGQg1fsL+UserIZ5yW2GPuTrI evyQ== Received: by 10.42.49.9 with SMTP id u9mr4538789icf.12.1349094785188; Mon, 01 Oct 2012 05:33:05 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id gz10sm6881143igc.9.2012.10.01.05.33.03 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 05:33:04 -0700 (PDT) Message-ID: <50698D7F.5000003@gmail.com> Date: Mon, 01 Oct 2012 13:33:03 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Damien Saucez References: <201210010121.q911Lsbp031067@gateway1.orleans.occnc.com> <2C25872F-9E9D-49B4-BEDA-C82E0EBC485F@gmail.com> In-Reply-To: <2C25872F-9E9D-49B4-BEDA-C82E0EBC485F@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Wassim Haddad , curtis@occnc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:33:09 -0000 On 01/10/2012 08:32, Damien Saucez wrote: > Curtis, > > Thank you for the comments. > > Our target in this document is to raise the question of multihoming > in personal and/or small/medium enterprise networks, so for now > we were not looking at the mobile device such as smartphones > connected to both 4g and wifi (for this, the multihoming solution > must be implemented directly on the device). We believe that > SOHO would be interested being multihomed but can't afford the > cost of operating multihoming themselves. That's a good description of why the IETF designed SHIM6, which requires no cooperation from any router or ISP and scales well, should cost little or nothing, and will work for mobile devices too, on two conditions 1. It becomes widely deployed 2. Firewalls allow the SHIM6 extension header. I don't believe that this is really a topic for homenet, however. Brian From rja.lists@gmail.com Mon Oct 1 05:59:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6D11E8155 for ; Mon, 1 Oct 2012 05:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 Yrh6x6KTyZXB for ; Mon, 1 Oct 2012 05:59:22 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20311E8135 for ; Mon, 1 Oct 2012 05:59:21 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so905457qao.10 for ; Mon, 01 Oct 2012 05:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=izjFFtmE9FybAv3sheURZ1nAzXHPh84EMhEwRURJxeI=; b=B7ljtE9wk8mCo0EJIhILhbowPKtJcaPDiKS5h9ygLa6kZMjMTckhmHKgFH81iMYGT+ saZGtX0Sg0OAHStNKs+0amLpElFoqYGuWTcmfZ1+YN5rMcOk8T7239/uIbzGLGkKCJkf 8yBQ3UlS+PC9w6i7m5PV/cMFsXrvfS+XBvptQgJzyMXNF0sIZNrQ0fuJHpXVm5ZFgjJn q7gi/IwgYox/i7YsYd7fDhcTDS21xE9du9XVBE/2v3h+TDKaHukliH6EDR0YeP1oBvYd 3WJvOaXpq4D99I9Bva/0mvk+fBpxTgveHtxEfH3Ux5MR1M6W8J8kq83jr6F2hBLfC3TT 2zDQ== Received: by 10.229.137.133 with SMTP id w5mr10241365qct.21.1349096361269; Mon, 01 Oct 2012 05:59:21 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id dz9sm6922416qab.6.2012.10.01.05.59.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 05:59:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <201209302333.q8UNXOR7029594@gateway1.orleans.occnc.com> Date: Mon, 1 Oct 2012 08:59:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201209302333.q8UNXOR7029594@gateway1.orleans.occnc.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:59:23 -0000 On 30 Sep 2012, at 19:33 , Curtis Villamizar wrote: Claim (A): > Breaking SLAAC is bad. Breaking SLAAC breaks interoperability, and will keep various networked devices disconnected, which is a *fundamental* problem. Fundamentally, DHCPv6 is not widely enough supported=20 (today / soon) for it to be a sufficient answer=20 to getting network-capable devices onto the network. =20 There might be a time in future where the situation=20 with DHCPv6 support changes, but we aren't there today,=20 and we won't be there soon. Claim (B): > Consumer oriented providers handing out /64s > to home nets is also bad. Agreed (s/consumer-oriented/any/).=20 HomeNet WG ought to be VERY clear about this. HomeNet WG ALSO ought NOT "enable" or "encourage"=20 such behaviour by encouraging ANY scenarios=20 where SLAAC can't work properly. Claim (C): > But if a homenet does get nothing more than a /64, > and multiple subnets are needed, then SLAAC gets broken. I don't think that last bit above is broadly agreed, at least as of now. It does not obviously follow that "keeping devices=20 disconnected" is better than "not being able to subnet=20 as much as desired". Separately, it is not obvious that those are the *only*=20 two possible approaches to the issue you seem concerned=20 with (i.e. /64 from a provider && desire subnets). SUMMARY: =46rom my perspective, there is a logic fault in the combination of the quoted statements. The quoted=20 text is equivalent to logic of this form: If (A && B) THEN C. However, from where I sit, the combination of (A && B)=20 does not necessarily imply C. It could mean that one decides to waive the requirement (B) to keep every device connected, or that one devices a new alternative (D),=20 or something else entirely. If there are some additional data that would make the above true, then it would help to get those onto the table, and figure out how they would factor into the logic. Cheers, Ran From d.sturek@att.net Mon Oct 1 06:01:50 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731341F0CD6 for ; Mon, 1 Oct 2012 06:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owrF0eWnBm15 for ; Mon, 1 Oct 2012 06:01:48 -0700 (PDT) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by ietfa.amsl.com (Postfix) with SMTP id 768181F0CD8 for ; Mon, 1 Oct 2012 06:01:48 -0700 (PDT) Received: from [98.139.91.69] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 01 Oct 2012 13:01:48 -0000 Received: from [98.139.44.69] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 01 Oct 2012 13:01:48 -0000 Received: from [127.0.0.1] by omp1006.access.mail.sp2.yahoo.com with NNFMP; 01 Oct 2012 13:01:48 -0000 X-Yahoo-Newman-Id: 343562.9220.bm@omp1006.access.mail.sp2.yahoo.com Received: (qmail 13647 invoked from network); 1 Oct 2012 13:01:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1349096507; bh=+S3zGs7LKn6lpqFTNIDofaMjhdG+0hHstgwwKKwg6TQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=IYEJx2VM6X2cTVpzC128lUl3qUTK7zpg5Vcz72H1hDK8F91oS80bgxiSy3zjhQlTTOxp8P2qoBAge9+gxbB0vhn3PE7HhxsvO6ZZCiVOSWjKAr9ZzAvTg7vWGEVmKL0SxhTaVWlxrIqkhynLP3aVAvJQFdP8fO2NNN8ftzFQNGE= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xn7fqsUVM1lgKmOt3fR_N1QZMHCGmLu0EMEJcgh16Pgql9E CKQPoTACb9jAEaYn6AJYkTSLfoJcTx.r7bfkSjI4Nq.785AQ.cLzF0wbLkbK U2Zj73otHO6qyEknW20G7iOgVIsdxx4Lge_Iz7xt4giXk2bUCkQtx8hdfqBe kAIBv5BQ_oN68E618JgqgVwGDaJjUeuVBJU3ceJPyrdg9UnyAmG5_vNjRFlK ENymJdzkL3gmt4w1a6wAzAdpMymEdDPBO9n2jvItxv8RTGYAWkcwwHfaNYh0 I5LcWfq2WWxCuilgOxHRH06gPTwNAqIsaHf0dMcqFqiDN1elzseu1icqlDDe G_WXEffbST4Imqc540eDzhQH5..L68HRtvTK.mFzZuxpsb676Rr9RhE9RA_f isYVYDbTVQAaPZE.z4jpCRP0vJzLrX5Hgpa0g9Oy_q740PwLcTQPSVzgzMt_ fXo1d4EmS0707mDFlVHn6Z7zMtiL9Bkr.coOnHJ5DlTfAumoP3mE4MomLGuG Nzdw5vArZ0Ic- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@67.124.203.28 with login) by smtp115.sbc.mail.ne1.yahoo.com with SMTP; 01 Oct 2012 06:01:45 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 01 Oct 2012 06:01:43 -0700 From: Don Sturek To: Message-ID: Thread-Topic: [homenet] draft-ietf-homenet-arch-04 In-Reply-To: <201209302236.q8UMalVW027432@gateway1.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: robert.cragie@gridmerge.com, homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 13:01:50 -0000 Hi Curtis, On the topic of "link local on each subnet and a routing protocol works for any topology....." In using 6LoWPAN with ROLL (route over), you end up with a mesh network where the scope of link local address is only between a single device in the mesh and its one-hop neighbors (not among all devices in the mesh). In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communications between all devices in a single mesh subnet. Don On 9/30/12 3:36 PM, "Curtis Villamizar" wrote: > >In message >Don Sturek writes: > >> Hi Robert, >> >> One more point touched on in your note below: >> 1) Ideally, it would be great if a single authorizatative device >>existed >> in the home providing DHCPv6 server services (if supported) and prefix >> delegation. >> >> One challenge in the description below is having multiple routers on >> multiple subnets, each possibly acting as a DHCPv6 server within their >>own >> subnet and also providing their own ULA prefix. >> >> We certainly don't want to further confuse address assignment in a >>setting >> where IT support does not exist. >> >> Don > > >We want things to "just work" witb no config. Link local on each >subnet and a routing protocol works for any topology. ULA just allows >summarization of subnets in the routing protocol, such that host >routes are not needed (though not a big deal if host routes are used >in a homenet). > >This would "just work" when using link local or ULA. How to subdivide >a GUA prefix among the subnets is another issue. > >In principle, though I know of no proposals to do this yet, the set of >GUA that are available from one of more routers with a provider link >could be coordinated via the routing protocol (for example, using a >new OSPF Opaque LSA). > >Curtis > > >> On 9/25/12 1:57 AM, "Robert Cragie" wrote: >> >> >So let's tweak Curtis' sequence slightly: >> > >> >What every host does is: >> > >> > if it has no MAC: >> > pick a random link local address >> > else >> > use the MAC to create a link local address >> > run DAD to make sure no one else has same address >> > >> > send a RS >> > >> > if it gets RA >> > use the RA prefix for SLAAC >> > else >> > time out and don't bother with SLAAC; can only use link local >>address >> > >> >then hopefully the host also does the following: >> > >> > send DHCPv6 client request >> > >> > if response >> > it has yet another address to pick from if it got one using SLAAC >> > else >> > time out and get nothing from DHCPv6 >> > >> >This should work fine for legacy APs where everything is bridged >> >underneath it. Where it gets interesting is in the case of cascaded >> >subnets behind a router connected to an ISP, where one or more of those >> >subnets may be a mesh network comprised of mesh routers and hosts. I am >> >not quite sure how ULAs and DHCPv6 would work in this case as there are >> >limitations as far as I can see (although I accept I probably have a >>bit >> >more reading to do on the subject). >> > >> >Robert >> > >> >On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >> >> In message >> >> Don Sturek writes: >> >> >> >>> Hi Curtis, >> >>> >> >>> I think the difficulty is each device cannot "use the MAC to create >>a >> >>>ULA >> >>> address". Some authoritative device in the network (eg, the AP) >>must >> >>> create the ULA prefix. If a ULA prefix is not present because the >>AP >> >>>is a >> >>> legacy device not capable of providing a ULA prefix, the STA devices >> >>>must >> >>> use link locals only. >> >>> >> >>> Don >> >> >> >> Don, >> >> >> >> You are right about there being nothing to generate the ULA prefix in >> >> your example. My mistake. >> >> >> >> But it doesn't change anything. If the AP is a dumb bridge and there >> >> is no router of any kind, then link local addresses are perfectly >> >> fine. There is only one subnet in that example, and ULA is not >> >> needed. That was the example you gave. >> >> >> >> Your example had no router just an old AP that acted as a bridge, >> >> therefore nothing to generate any sort of RA. If there is a router >> >> and no GUA prefix (which is not your example, but a useful example), >> >> then ULA can be used. The only RA that is seen is the RA providing a >> >> ULA prefix which the router can generate. >> >> >> >> I did say that the possibility of having to subdivide a /64 only >> >> exists for GUA. If a router exists which gets a GUA from a provider, >> >> and there are more subnets than the prefix length can support the two >> >> options are the ones listed below. (Search for --or--). >> >> >> >> Curtis >> >> >> >> >> >>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: >> >>> >> >>>> In message >> >>>> Don Sturek writes: >> >>>> >> >>>>> Hi Curtis, >> >>>>> >> >>>>> I would expect most Wi-Fi AP manufacturers to support the same >> >>>>>address >> >>>>> assignment they do today (ie, manual assignment and DHCP). I >>would >> >>>>> also expect as more IPv6 deployments happen that SLAAC will also >>be >> >>>>> supported (and, yes, even for GUA). >> >>>>> >> >>>>> For the types of devices which will be added to Wi-Fi networks in >>the >> >>>>> future (eg, headless devices like appliances, thermostats, etc.) >>that >> >>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, >>yes, >> >>>>>I >> >>>>> purposely did not remove SLAAC.....) >> >>>>> >> >>>>> Don >> >>>> >> >>>> Don, >> >>>> >> >>>> We seem to be talking past each other so let me again try to be >>clear. >> >>>> >> >>>> What every host does is: >> >>>> >> >>>> if it has no MAC: >> >>>> pick a random link local (not ULA) address >> >>>> else >> >>>> use the MAC to create a ULA address >> >>>> run DAD to make sure no one else has same address >> >>>> >> >>>> send a RS >> >>>> >> >>>> if it gets RA >> >>>> use the RA prefix for SLAAC >> >>>> else >> >>>> time out and don't bother with SLAAC >> >>>> >> >>>> then hopefully the host also does the following: >> >>>> >> >>>> send DHCPv6 client request >> >>>> >> >>>> if response >> >>>> it has yet another address to pick from if it got one using >>SLAAC >> >>>> else >> >>>> time out and get nothing from DHCPv6 >> >>>> >> >>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server >> >>>> the address that it already has (from SLAAC). >> >>>> >> >>>> If as in the case of your Wi-Fi with a bridging AP example, there >>is >> >>>> no router to give it an DHCPv6 the link local or ULA addresses are >> >>>> still there and still usable. There is also no router to give it >>an >> >>>> RA response so it has no SLAAC assigned address and no DHCPv6 >>assigned >> >>>> address. >> >>>> >> >>>> That is the end of your example. >> >>>> >> >>>> If there is a router then there is something that can hand out a >>RA or >> >>>> DHCPv6 response. >> >>>> >> >>>> In the case were there exists multiple subnets and the CER has been >> >>>> granted a /64 (or too few /64s to handle the number of subnets), >>then: >> >>>> >> >>>> it can use RA with /64 on some subnets and give them GUA >>addresses >> >>>> and some subnets have no access outside the homenet >> >>>> >> >>>> --or-- >> >>>> >> >>>> it can not use RA (and therefore prevent SLAAC from being used) >>and >> >>>> hand out DHCPv6 addresses and make use of prefixes longer than >>/64. >> >>>> This prevents the use of CGA but get connectivity to the entire >> >>>> homenet. >> >>>> >> >>>> If every consumer oriented provider is willing to allocate prefixes >> >>>> shorter than /64 on request to home users, then the above situation >> >>>> never occurs. If it does, my argument is that the second option >>above >> >>>> is better than the first. >> >>>> >> >>>> Curtis >> >>>> >> >>>> >> >>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: >> >>>>> >> >>>>>> In message <5060BDC7.6020403@freedesktop.org> >> >>>>>> Jim Gettys writes: >> >>>>>> >> >>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >> >>>>>>>> Hi Curtis, >> >>>>>>>> >> >>>>>>>> Here is the use case: >> >>>>>>>> 1) Customer has a legacy AP in their house >> >>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are >> >>>>>>> designed >> >>>>>>>> to communicate only with other IPv6 based devices in the home) >> >>>>>>>> 3) The only way these new devices can communicate is through >> >>>>> address >> >>>>>>>> assignment using SLAAC and then some discovery method the two >>new >> >>>>>>> devices >> >>>>>>>> support (without support from the AP). Here these devices are >> >>>>>>> assuming >> >>>>>>>> bridging through the AP...... >> >>>>>>> >> >>>>>>> And since current legacy AP's all bridge, we win (even though we >> >>>>> need to >> >>>>>>> route in the future). >> >>>>>> Jim, >> >>>>>> >> >>>>>> The point was how do you get local IPv6 within the home with the >> >>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. >>First >> >>>>>> of all you have no subnets. There is no CER to do DHCPv6. >> >>>>>> >> >>>>>> In this case you use link local or if everything has a MAC you >>can >> >>>>>>use >> >>>>>> ULA based on the MAC addressses. >> >>>>>> >> >>>>>>>> Placing a requirement that every customer who buys a new IPv6 >> >>>>> device, >> >>>>>>>> intended to communicate only with other IPv6 devices in the >>home, >> >>>>> will >> >>>>>>>> require a forklift upgrade of a deployed network in order to >>work >> >>>>>>> will not >> >>>>>>>> be popular. >> >>>>>>> >> >>>>>>> Good point. >> >>>>>> But invalid. The use case Don gave would still work fine. Only >>GUA >> >>>>>> addresses are affected. >> >>>>>> >> >>>>>>> I loathe DHCP (of any sort) *for basic address assignment, >>anyway* >> >>>>>>>in >> >>>>>>> the home environment. >> >>>>>>> >> >>>>>>> The loathing comes from the exquisite pain of suffering with a >> >>>>>>>flaky >> >>>>>>> home network for several months, before realising I had a rogue >> >>>>>>>DHCP >> >>>>>>> server somewhere on my network (from wireshark). I then had to >> >>>>>>>take >> >>>>> the >> >>>>>>> mac address, figure out who may have manufactured some device >>from >> >>>>> that >> >>>>>>> information, and finally figured out the little VOIP ATA >>adaptor I >> >>>>> had >> >>>>>>> been given liked to do DHCP. >> >>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your >> >>>>>> network behind the VOIP box on the LAN side I hope. >> >>>>>> >> >>>>>>> This was by far the hardest debugging I've had to do in my home >> >>>>> network >> >>>>>>> in normal operation. >> >>>>>>> >> >>>>>>> This is well beyond normal home debugging capability of >>consumers. >> >>>>>>> - Jim >> >>>>>> We all have plenty of crappy IPv4 product horror stories. My >>VOIP >> >>>>>> phone locked up now and then and I figured out that if the call >> >>>>>>lasted >> >>>>>> longer than the DHCPv4 lease, then it lost the least because it >> >>>>>>didn't >> >>>>>> try to renew it. Not only did the call drop, but the device >>locked >> >>>>>> up. The first solution was to reboot it now and then. The >>answer >> >>>>>>was >> >>>>>> to configure a fixed address. I was lucky to figure it out >>before >> >>>>>>my >> >>>>>> wife threw the phone through a window. For all I know a later >> >>>>>> firmware upgrade might have fixed it. VOIP might be more >>popular if >> >>>>>> VOIP phones under $600 worked reasonably well. >> >>>>>> >> >>>>>> Both nice stories, but both are DHCPv4 related and have nothing >>at >> >>>>>>all >> >>>>>> to do with SLAAC. >> >>>>>> >> >>>>>> Curtis >> >>>>>> >> >>>>>>>> Don >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" >>wrote: >> >>>>>>>> >> >>>>>>>>> In message >> >>>>>>>>> Don Sturek writes: >> >>>>>>>>> >> >>>>>>>>>> Hi Curtis, >> >>>>>>>>>> >> >>>>>>>>>> SLAAC not working is a major problem. >> >>>>>>>>>> >> >>>>>>>>>> Don >> >>>>>>>>> Don, >> >>>>>>>>> >> >>>>>>>>> Why? This is an assertion without basis as far as I am >> >>>>>>>>>concerned. >> >>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel >> >>>>> brought >> >>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as >>the >> >>>>>>>>> constraints in ILNP are in the ILNP identifier which is not >>the >> >>>>> same >> >>>>>>>>> as the interface address in ILNP for which there is no >> >>>>>>>>>constraint. >> >>>>>>>>> >> >>>>>>>>> I have subnets running fine using a few /112 allocated from >> >>>>> within a >> >>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and >> >>>>> DHCPv6 >> >>>>>>>>> for dynamic allocations for laptops. It works fine. Link >>local >> >>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No >>host >> >>>>> ever >> >>>>>>>>> receives a RA since my routers won't give them one, so no host >> >>>>> ever >> >>>>>>>>> tries to generate an address using SLAAC. The only >>constraint is >> >>>>>>> that >> >>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP >> >>>>> client >> >>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 >> >>>>>>>>>and >> >>>>>>>>> DHCPv6 servers are available in every subnet except one GbE >> >>>>> subnet in >> >>>>>>>>> the rack and to a few hosts in my home office. >> >>>>>>>>> >> >>>>>>>>> So as far as I am concerned we have an assertion that no >>SLAAC is >> >>>>> a >> >>>>>>>>> problem and existance proof that it is not. Beside CGA and >> >>>>> requiring >> >>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >> >>>>>>> support >> >>>>>>>>> on these /112 subnets? >> >>>>>>>>> >> >>>>>>>>> Curtis >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" >> >>>>>>>>>>wrote: >> >>>>>>>>>> >> >>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >> >>>>>>>>>>> "Joel M. Halpern" writes: >> >>>>>>>>>>> >> >>>>>>>>>>>> Since you invited flames... >> >>>>>>>>>>>> >> >>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is >> >>>>>>> magically >> >>>>>>>>>>>> unnatural. >> >>>>>>>>>>>> Rather, it is that there are a number of current and >>evolving >> >>>>>>>>>> protocols >> >>>>>>>>>>>> that depend upon that /64. The obvious example is that >>SLAAC >> >>>>> does >> >>>>>>>>>> not >> >>>>>>>>>>>> work if subnets are longer than /64. >> >>>>>>>>>>>> >> >>>>>>>>>>>> The rules in this regard are written into approved RFCs. >>If >> >>>>>>> homenet >> >>>>>>>>>>>> wants to change that, it really needs to go to 6man with a >> >>>>> strong >> >>>>>>>>>> case. >> >>>>>>>>>>>> (for point-to-point inter-router links this was recently >> >>>>>>> relaxed. >> >>>>>>>>>>>> >> >>>>>>>>>>>> At the same time, andy operator who insists on giving >>homes a >> >>>>> /64 >> >>>>>>> is >> >>>>>>>>>>>> being inappropriately restrictive. Homenet should say >>that, >> >>>>>>> rather >> >>>>>>>>>>>> than >> >>>>>>>>>>>> trying to change the IPv6 architecture. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Yours, >> >>>>>>>>>>>> Joel >> >>>>>>>>>>> Joel, >> >>>>>>>>>>> >> >>>>>>>>>>> I don't consider your email a flame at all. Thanks for >> >>>>> responding. >> >>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 >>will >> >>>>>>>>>>>so >> >>>>>>> IMHO >> >>>>>>>>>>> no loss. CGA also won't work but then again I've also never >> >>>>> been a >> >>>>>>>>>>> fan of security half measures. Yes anti-spoofing without >>prior >> >>>>>>>>>>> exchange of a key is nice, but no reasonable authorization >> >>>>> could be >> >>>>>>>>>>> based on CGA without also exchanging some sort of key or >>cert >> >>>>> and >> >>>>>>> at >> >>>>>>>>>>> that point the CGA as a public key is redundant. >> >>>>>>>>>>> >> >>>>>>>>>>> If SLAAC and CGA are the only things that break *and* >>providers >> >>>>> do >> >>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will >> >>>>> have >> >>>>>>> to >> >>>>>>>>>>> be subdivided. >> >>>>>>>>>>> >> >>>>>>>>>>> So a question for you is what else if anything will break? >> >>>>>>>>>>> >> >>>>>>>>>>> I also understand that you are suggesting that this be >>taken to >> >>>>>>> 6man. >> >>>>>>>>>>> That is a good suggestion. >> >>>>>>>>>>> >> >>>>>>>>>>> Curtis >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >> >>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out >>that >> >>>>>>> using >> >>>>>>>>>>>>> subnets longer than /64 is OK as long as they are >>not >> >>>>>>> leaked >> >>>>>>>>>>>>> into global routing. Please read the text and >> >>>>>>>>>>>>>changes >> >>>>>>>>>> before >> >>>>>>>>>>>>> exploding on this topic. It may be necessary to >> >>>>> subnet a >> >>>>>>>>>> /64 >> >>>>>>>>>>>> if >> >>>>>>>>>>>>> that is all a provider will give you and you need >> >>>>> subnets. >> >>>>>>>>>> It >> >>>>>>>>>>>>> does work and it is no more unnatural than >> >>>>>>>>>>>>>subnetting a >> >>>>>>>>>> class-A >> >>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 >>and >> >>>>> not >> >>>>>>>>>> using >> >>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC >>implementations >> >>>>> would >> >>>>>>>>>>>>> likely try to use the whole bottom 64). >> >>>>>> _______________________________________________ >> >>>>>> homenet mailing list >> >>>>>> homenet@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/homenet >> >> _______________________________________________ >> >> homenet mailing list >> >> homenet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/homenet >> >> >> > >> > >> >_______________________________________________ >> >homenet mailing list >> >homenet@ietf.org >> >https://www.ietf.org/mailman/listinfo/homenet >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Mon Oct 1 11:02:12 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FBE21F8736 for ; Mon, 1 Oct 2012 11:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-ossMLsWIrg for ; Mon, 1 Oct 2012 11:02:11 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 8A17321F8732 for ; Mon, 1 Oct 2012 11:02:11 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q91I1tfW056624; Mon, 1 Oct 2012 14:01:55 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Mon, 01 Oct 2012 13:33:03 BST." <50698D7F.5000003@gmail.com> Date: Mon, 01 Oct 2012 14:01:55 -0400 Cc: Damien Saucez , "homenet@ietf.org Group" , Wassim Haddad , curtis@occnc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:02:12 -0000 In message <50698D7F.5000003@gmail.com> Brian E Carpenter writes: > On 01/10/2012 08:32, Damien Saucez wrote: > > Curtis, > > > > Thank you for the comments. > > > > Our target in this document is to raise the question of multihoming > > in personal and/or small/medium enterprise networks, so for now > > we were not looking at the mobile device such as smartphones > > connected to both 4g and wifi (for this, the multihoming solution > > must be implemented directly on the device). We believe that > > SOHO would be interested being multihomed but can't afford the > > cost of operating multihoming themselves. > > That's a good description of why the IETF designed SHIM6, which requires > no cooperation from any router or ISP and scales well, should cost little > or nothing, and will work for mobile devices too, on two conditions > > 1. It becomes widely deployed > 2. Firewalls allow the SHIM6 extension header. > > I don't believe that this is really a topic for homenet, however. > > Brian Brian, Your item #2 might be worth recording somewhere as a requirement if it is not already in rfc6204bis. (I didn't look). If shim6 is the recommendation on the part of homenet as to how to deal with multihoming in the home, then this is significant and should be in the framework. Curtis From curtis@occnc.com Mon Oct 1 11:11:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C226721F890B for ; Mon, 1 Oct 2012 11:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY9QecKklgpx for ; Mon, 1 Oct 2012 11:11:23 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id DA73C21F890C for ; Mon, 1 Oct 2012 11:11:22 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q91IB8vl056686; Mon, 1 Oct 2012 14:11:09 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210011811.q91IB8vl056686@gateway1.orleans.occnc.com> To: Don Sturek From: Curtis Villamizar In-reply-to: Your message of "Mon, 01 Oct 2012 06:01:43 PDT." Date: Mon, 01 Oct 2012 14:11:08 -0400 Cc: robert.cragie@gridmerge.com, homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:11:25 -0000 In message Don Sturek writes: > Hi Curtis, > > On the topic of "link local on each subnet and a routing protocol works > for any topology....." > > In using 6LoWPAN with ROLL (route over), you end up with a mesh network > where the scope of link local address is only between a single device in > the mesh and its one-hop neighbors (not among all devices in the mesh). > > In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communications > between all devices in a single mesh subnet. > > Don Don, The "subnet" is meant in IETF terms, not ITU subnetwork. The subnet is therefore anything link local by definition. A 6LoWPAN node can get a GUA and use the GUA (or link local address) of a router as a default route. If the 6LoWPAN device needs only site connectivity then it can use the link local address for everything. If a routing protocol is in use and is using link local based host routes, then a router must fake the DAD collision if a duplicate is found anywhere within the site. If a multiple ULA are used, one per subnet, then DAD is only relevant to the subnet. A router should pick a ULA prefix that is not already in use elsewhere in the site. An extremely low probability race condition exists, but it is a race condition among routers with multiple routers picking and advertising the exact same ULA prefix in the routing protocol very nearly simultaneously (within LAN flooding interval). A wait and backoff can solve this even though it is a miniscule probability. A mesh in IETF terminology is by definition multiple subnets. A subnet is by definition link local. Curtis > On 9/30/12 3:36 PM, "Curtis Villamizar" wrote: > > > > >In message > >Don Sturek writes: > > > >> Hi Robert, > >> > >> One more point touched on in your note below: > >> 1) Ideally, it would be great if a single authorizatative device > >>existed > >> in the home providing DHCPv6 server services (if supported) and prefix > >> delegation. > >> > >> One challenge in the description below is having multiple routers on > >> multiple subnets, each possibly acting as a DHCPv6 server within their > >>own > >> subnet and also providing their own ULA prefix. > >> > >> We certainly don't want to further confuse address assignment in a > >>setting > >> where IT support does not exist. > >> > >> Don > > > > > >We want things to "just work" witb no config. Link local on each > >subnet and a routing protocol works for any topology. ULA just allows > >summarization of subnets in the routing protocol, such that host > >routes are not needed (though not a big deal if host routes are used > >in a homenet). > > > >This would "just work" when using link local or ULA. How to subdivide > >a GUA prefix among the subnets is another issue. > > > >In principle, though I know of no proposals to do this yet, the set of > >GUA that are available from one of more routers with a provider link > >could be coordinated via the routing protocol (for example, using a > >new OSPF Opaque LSA). > > > >Curtis > > > > > >> On 9/25/12 1:57 AM, "Robert Cragie" wrote: > >> > >> >So let's tweak Curtis' sequence slightly: > >> > > >> >What every host does is: > >> > > >> > if it has no MAC: > >> > pick a random link local address > >> > else > >> > use the MAC to create a link local address > >> > run DAD to make sure no one else has same address > >> > > >> > send a RS > >> > > >> > if it gets RA > >> > use the RA prefix for SLAAC > >> > else > >> > time out and don't bother with SLAAC; can only use link local > >>address > >> > > >> >then hopefully the host also does the following: > >> > > >> > send DHCPv6 client request > >> > > >> > if response > >> > it has yet another address to pick from if it got one using SLAAC > >> > else > >> > time out and get nothing from DHCPv6 > >> > > >> >This should work fine for legacy APs where everything is bridged > >> >underneath it. Where it gets interesting is in the case of cascaded > >> >subnets behind a router connected to an ISP, where one or more of those > >> >subnets may be a mesh network comprised of mesh routers and hosts. I am > >> >not quite sure how ULAs and DHCPv6 would work in this case as there are > >> >limitations as far as I can see (although I accept I probably have a > >>bit > >> >more reading to do on the subject). > >> > > >> >Robert > >> > > >> >On 25/09/2012 5:45 AM, Curtis Villamizar wrote: > >> >> In message > >> >> Don Sturek writes: > >> >> > >> >>> Hi Curtis, > >> >>> > >> >>> I think the difficulty is each device cannot "use the MAC to create > >>a > >> >>>ULA > >> >>> address". Some authoritative device in the network (eg, the AP) > >>must > >> >>> create the ULA prefix. If a ULA prefix is not present because the > >>AP > >> >>>is a > >> >>> legacy device not capable of providing a ULA prefix, the STA devices > >> >>>must > >> >>> use link locals only. > >> >>> > >> >>> Don > >> >> > >> >> Don, > >> >> > >> >> You are right about there being nothing to generate the ULA prefix in > >> >> your example. My mistake. > >> >> > >> >> But it doesn't change anything. If the AP is a dumb bridge and there > >> >> is no router of any kind, then link local addresses are perfectly > >> >> fine. There is only one subnet in that example, and ULA is not > >> >> needed. That was the example you gave. > >> >> > >> >> Your example had no router just an old AP that acted as a bridge, > >> >> therefore nothing to generate any sort of RA. If there is a router > >> >> and no GUA prefix (which is not your example, but a useful example), > >> >> then ULA can be used. The only RA that is seen is the RA providing a > >> >> ULA prefix which the router can generate. > >> >> > >> >> I did say that the possibility of having to subdivide a /64 only > >> >> exists for GUA. If a router exists which gets a GUA from a provider, > >> >> and there are more subnets than the prefix length can support the two > >> >> options are the ones listed below. (Search for --or--). > >> >> > >> >> Curtis > >> >> > >> >> > >> >>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: > >> >>> > >> >>>> In message > >> >>>> Don Sturek writes: > >> >>>> > >> >>>>> Hi Curtis, > >> >>>>> > >> >>>>> I would expect most Wi-Fi AP manufacturers to support the same > >> >>>>>address > >> >>>>> assignment they do today (ie, manual assignment and DHCP). I > >>would > >> >>>>> also expect as more IPv6 deployments happen that SLAAC will also > >>be > >> >>>>> supported (and, yes, even for GUA). > >> >>>>> > >> >>>>> For the types of devices which will be added to Wi-Fi networks in > >>the > >> >>>>> future (eg, headless devices like appliances, thermostats, etc.) > >>that > >> >>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, > >>yes, > >> >>>>>I > >> >>>>> purposely did not remove SLAAC.....) > >> >>>>> > >> >>>>> Don > >> >>>> > >> >>>> Don, > >> >>>> > >> >>>> We seem to be talking past each other so let me again try to be > >>clear. > >> >>>> > >> >>>> What every host does is: > >> >>>> > >> >>>> if it has no MAC: > >> >>>> pick a random link local (not ULA) address > >> >>>> else > >> >>>> use the MAC to create a ULA address > >> >>>> run DAD to make sure no one else has same address > >> >>>> > >> >>>> send a RS > >> >>>> > >> >>>> if it gets RA > >> >>>> use the RA prefix for SLAAC > >> >>>> else > >> >>>> time out and don't bother with SLAAC > >> >>>> > >> >>>> then hopefully the host also does the following: > >> >>>> > >> >>>> send DHCPv6 client request > >> >>>> > >> >>>> if response > >> >>>> it has yet another address to pick from if it got one using > >>SLAAC > >> >>>> else > >> >>>> time out and get nothing from DHCPv6 > >> >>>> > >> >>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server > >> >>>> the address that it already has (from SLAAC). > >> >>>> > >> >>>> If as in the case of your Wi-Fi with a bridging AP example, there > >>is > >> >>>> no router to give it an DHCPv6 the link local or ULA addresses are > >> >>>> still there and still usable. There is also no router to give it > >>an > >> >>>> RA response so it has no SLAAC assigned address and no DHCPv6 > >>assigned > >> >>>> address. > >> >>>> > >> >>>> That is the end of your example. > >> >>>> > >> >>>> If there is a router then there is something that can hand out a > >>RA or > >> >>>> DHCPv6 response. > >> >>>> > >> >>>> In the case were there exists multiple subnets and the CER has been > >> >>>> granted a /64 (or too few /64s to handle the number of subnets), > >>then: > >> >>>> > >> >>>> it can use RA with /64 on some subnets and give them GUA > >>addresses > >> >>>> and some subnets have no access outside the homenet > >> >>>> > >> >>>> --or-- > >> >>>> > >> >>>> it can not use RA (and therefore prevent SLAAC from being used) > >>and > >> >>>> hand out DHCPv6 addresses and make use of prefixes longer than > >>/64. > >> >>>> This prevents the use of CGA but get connectivity to the entire > >> >>>> homenet. > >> >>>> > >> >>>> If every consumer oriented provider is willing to allocate prefixes > >> >>>> shorter than /64 on request to home users, then the above situation > >> >>>> never occurs. If it does, my argument is that the second option > >>above > >> >>>> is better than the first. > >> >>>> > >> >>>> Curtis > >> >>>> > >> >>>> > >> >>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > >> >>>>> > >> >>>>>> In message <5060BDC7.6020403@freedesktop.org> > >> >>>>>> Jim Gettys writes: > >> >>>>>> > >> >>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: > >> >>>>>>>> Hi Curtis, > >> >>>>>>>> > >> >>>>>>>> Here is the use case: > >> >>>>>>>> 1) Customer has a legacy AP in their house > >> >>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are > >> >>>>>>> designed > >> >>>>>>>> to communicate only with other IPv6 based devices in the home) > >> >>>>>>>> 3) The only way these new devices can communicate is through > >> >>>>> address > >> >>>>>>>> assignment using SLAAC and then some discovery method the two > >>new > >> >>>>>>> devices > >> >>>>>>>> support (without support from the AP). Here these devices are > >> >>>>>>> assuming > >> >>>>>>>> bridging through the AP...... > >> >>>>>>> > >> >>>>>>> And since current legacy AP's all bridge, we win (even though we > >> >>>>> need to > >> >>>>>>> route in the future). > >> >>>>>> Jim, > >> >>>>>> > >> >>>>>> The point was how do you get local IPv6 within the home with the > >> >>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. > >>First > >> >>>>>> of all you have no subnets. There is no CER to do DHCPv6. > >> >>>>>> > >> >>>>>> In this case you use link local or if everything has a MAC you > >>can > >> >>>>>>use > >> >>>>>> ULA based on the MAC addressses. > >> >>>>>> > >> >>>>>>>> Placing a requirement that every customer who buys a new IPv6 > >> >>>>> device, > >> >>>>>>>> intended to communicate only with other IPv6 devices in the > >>home, > >> >>>>> will > >> >>>>>>>> require a forklift upgrade of a deployed network in order to > >>work > >> >>>>>>> will not > >> >>>>>>>> be popular. > >> >>>>>>> > >> >>>>>>> Good point. > >> >>>>>> But invalid. The use case Don gave would still work fine. Only > >>GUA > >> >>>>>> addresses are affected. > >> >>>>>> > >> >>>>>>> I loathe DHCP (of any sort) *for basic address assignment, > >>anyway* > >> >>>>>>>in > >> >>>>>>> the home environment. > >> >>>>>>> > >> >>>>>>> The loathing comes from the exquisite pain of suffering with a > >> >>>>>>>flaky > >> >>>>>>> home network for several months, before realising I had a rogue > >> >>>>>>>DHCP > >> >>>>>>> server somewhere on my network (from wireshark). I then had to > >> >>>>>>>take > >> >>>>> the > >> >>>>>>> mac address, figure out who may have manufactured some device > >>from > >> >>>>> that > >> >>>>>>> information, and finally figured out the little VOIP ATA > >>adaptor I > >> >>>>> had > >> >>>>>>> been given liked to do DHCP. > >> >>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your > >> >>>>>> network behind the VOIP box on the LAN side I hope. > >> >>>>>> > >> >>>>>>> This was by far the hardest debugging I've had to do in my home > >> >>>>> network > >> >>>>>>> in normal operation. > >> >>>>>>> > >> >>>>>>> This is well beyond normal home debugging capability of > >>consumers. > >> >>>>>>> - Jim > >> >>>>>> We all have plenty of crappy IPv4 product horror stories. My > >>VOIP > >> >>>>>> phone locked up now and then and I figured out that if the call > >> >>>>>>lasted > >> >>>>>> longer than the DHCPv4 lease, then it lost the least because it > >> >>>>>>didn't > >> >>>>>> try to renew it. Not only did the call drop, but the device > >>locked > >> >>>>>> up. The first solution was to reboot it now and then. The > >>answer > >> >>>>>>was > >> >>>>>> to configure a fixed address. I was lucky to figure it out > >>before > >> >>>>>>my > >> >>>>>> wife threw the phone through a window. For all I know a later > >> >>>>>> firmware upgrade might have fixed it. VOIP might be more > >>popular if > >> >>>>>> VOIP phones under $600 worked reasonably well. > >> >>>>>> > >> >>>>>> Both nice stories, but both are DHCPv4 related and have nothing > >>at > >> >>>>>>all > >> >>>>>> to do with SLAAC. > >> >>>>>> > >> >>>>>> Curtis > >> >>>>>> > >> >>>>>>>> Don > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" > >>wrote: > >> >>>>>>>> > >> >>>>>>>>> In message > >> >>>>>>>>> Don Sturek writes: > >> >>>>>>>>> > >> >>>>>>>>>> Hi Curtis, > >> >>>>>>>>>> > >> >>>>>>>>>> SLAAC not working is a major problem. > >> >>>>>>>>>> > >> >>>>>>>>>> Don > >> >>>>>>>>> Don, > >> >>>>>>>>> > >> >>>>>>>>> Why? This is an assertion without basis as far as I am > >> >>>>>>>>>concerned. > >> >>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel > >> >>>>> brought > >> >>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as > >>the > >> >>>>>>>>> constraints in ILNP are in the ILNP identifier which is not > >>the > >> >>>>> same > >> >>>>>>>>> as the interface address in ILNP for which there is no > >> >>>>>>>>>constraint. > >> >>>>>>>>> > >> >>>>>>>>> I have subnets running fine using a few /112 allocated from > >> >>>>> within a > >> >>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and > >> >>>>> DHCPv6 > >> >>>>>>>>> for dynamic allocations for laptops. It works fine. Link > >>local > >> >>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No > >>host > >> >>>>> ever > >> >>>>>>>>> receives a RA since my routers won't give them one, so no host > >> >>>>> ever > >> >>>>>>>>> tries to generate an address using SLAAC. The only > >>constraint is > >> >>>>>>> that > >> >>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP > >> >>>>> client > >> >>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 > >> >>>>>>>>>and > >> >>>>>>>>> DHCPv6 servers are available in every subnet except one GbE > >> >>>>> subnet in > >> >>>>>>>>> the rack and to a few hosts in my home office. > >> >>>>>>>>> > >> >>>>>>>>> So as far as I am concerned we have an assertion that no > >>SLAAC is > >> >>>>> a > >> >>>>>>>>> problem and existance proof that it is not. Beside CGA and > >> >>>>> requiring > >> >>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not > >> >>>>>>> support > >> >>>>>>>>> on these /112 subnets? > >> >>>>>>>>> > >> >>>>>>>>> Curtis > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" > >> >>>>>>>>>>wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> > >> >>>>>>>>>>> "Joel M. Halpern" writes: > >> >>>>>>>>>>> > >> >>>>>>>>>>>> Since you invited flames... > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is > >> >>>>>>> magically > >> >>>>>>>>>>>> unnatural. > >> >>>>>>>>>>>> Rather, it is that there are a number of current and > >>evolving > >> >>>>>>>>>> protocols > >> >>>>>>>>>>>> that depend upon that /64. The obvious example is that > >>SLAAC > >> >>>>> does > >> >>>>>>>>>> not > >> >>>>>>>>>>>> work if subnets are longer than /64. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The rules in this regard are written into approved RFCs. > >>If > >> >>>>>>> homenet > >> >>>>>>>>>>>> wants to change that, it really needs to go to 6man with a > >> >>>>> strong > >> >>>>>>>>>> case. > >> >>>>>>>>>>>> (for point-to-point inter-router links this was recently > >> >>>>>>> relaxed. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> At the same time, andy operator who insists on giving > >>homes a > >> >>>>> /64 > >> >>>>>>> is > >> >>>>>>>>>>>> being inappropriately restrictive. Homenet should say > >>that, > >> >>>>>>> rather > >> >>>>>>>>>>>> than > >> >>>>>>>>>>>> trying to change the IPv6 architecture. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Yours, > >> >>>>>>>>>>>> Joel > >> >>>>>>>>>>> Joel, > >> >>>>>>>>>>> > >> >>>>>>>>>>> I don't consider your email a flame at all. Thanks for > >> >>>>> responding. > >> >>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 > >>will > >> >>>>>>>>>>>so > >> >>>>>>> IMHO > >> >>>>>>>>>>> no loss. CGA also won't work but then again I've also never > >> >>>>> been a > >> >>>>>>>>>>> fan of security half measures. Yes anti-spoofing without > >>prior > >> >>>>>>>>>>> exchange of a key is nice, but no reasonable authorization > >> >>>>> could be > >> >>>>>>>>>>> based on CGA without also exchanging some sort of key or > >>cert > >> >>>>> and > >> >>>>>>> at > >> >>>>>>>>>>> that point the CGA as a public key is redundant. > >> >>>>>>>>>>> > >> >>>>>>>>>>> If SLAAC and CGA are the only things that break *and* > >>providers > >> >>>>> do > >> >>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will > >> >>>>> have > >> >>>>>>> to > >> >>>>>>>>>>> be subdivided. > >> >>>>>>>>>>> > >> >>>>>>>>>>> So a question for you is what else if anything will break? > >> >>>>>>>>>>> > >> >>>>>>>>>>> I also understand that you are suggesting that this be > >>taken to > >> >>>>>>> 6man. > >> >>>>>>>>>>> That is a good suggestion. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Curtis > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >> >>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out > >>that > >> >>>>>>> using > >> >>>>>>>>>>>>> subnets longer than /64 is OK as long as they are > >>not > >> >>>>>>> leaked > >> >>>>>>>>>>>>> into global routing. Please read the text and > >> >>>>>>>>>>>>>changes > >> >>>>>>>>>> before > >> >>>>>>>>>>>>> exploding on this topic. It may be necessary to > >> >>>>> subnet a > >> >>>>>>>>>> /64 > >> >>>>>>>>>>>> if > >> >>>>>>>>>>>>> that is all a provider will give you and you need > >> >>>>> subnets. > >> >>>>>>>>>> It > >> >>>>>>>>>>>>> does work and it is no more unnatural than > >> >>>>>>>>>>>>>subnetting a > >> >>>>>>>>>> class-A > >> >>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 > >>and > >> >>>>> not > >> >>>>>>>>>> using > >> >>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC > >>implementations > >> >>>>> would > >> >>>>>>>>>>>>> likely try to use the whole bottom 64). > >> >>>>>> _______________________________________________ > >> >>>>>> homenet mailing list > >> >>>>>> homenet@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Mon Oct 1 12:01:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8022821F8A6F for ; Mon, 1 Oct 2012 12:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQzKoyMgdahG for ; Mon, 1 Oct 2012 12:01:52 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id B5C1D21F8A6D for ; Mon, 1 Oct 2012 12:01:51 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q91J1FKW056959; Mon, 1 Oct 2012 15:01:16 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210011901.q91J1FKW056959@gateway1.orleans.occnc.com> To: RJ Atkinson From: Curtis Villamizar In-reply-to: Your message of "Mon, 01 Oct 2012 08:59:18 EDT." Date: Mon, 01 Oct 2012 15:01:14 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 19:01:52 -0000 In message RJ Atkinson writes: > > On 30 Sep 2012, at 19:33 , Curtis Villamizar wrote: > Claim (A): > > Breaking SLAAC is bad. > > Breaking SLAAC breaks interoperability, and will keep > various networked devices disconnected, which is a > *fundamental* problem. > > Fundamentally, DHCPv6 is not widely enough supported > (today / soon) for it to be a sufficient answer > to getting network-capable devices onto the network. > > There might be a time in future where the situation > with DHCPv6 support changes, but we aren't there today, > and we won't be there soon. > > Claim (B): > > Consumer oriented providers handing out /64s > > to home nets is also bad. > > Agreed (s/consumer-oriented/any/). > > HomeNet WG ought to be VERY clear about this. > > HomeNet WG ALSO ought NOT "enable" or "encourage" > such behaviour by encouraging ANY scenarios > where SLAAC can't work properly. > > Claim (C): > > But if a homenet does get nothing more than a /64, > > and multiple subnets are needed, then SLAAC gets broken. > > > I don't think that last bit above is broadly agreed, > at least as of now. > > It does not obviously follow that "keeping devices > disconnected" is better than "not being able to subnet > as much as desired". > > Separately, it is not obvious that those are the *only* > two possible approaches to the issue you seem concerned > with (i.e. /64 from a provider && desire subnets). > > > SUMMARY: > > >From my perspective, there is a logic fault in the > combination of the quoted statements. The quoted > text is equivalent to logic of this form: > > If (A && B) THEN C. > > However, from where I sit, the combination of (A && B) > does not necessarily imply C. It could mean that one > decides to waive the requirement (B) to keep every device > connected, or that one devices a new alternative (D), > or something else entirely. > > If there are some additional data that would make the > above true, then it would help to get those onto the > table, and figure out how they would factor into the logic. > > Cheers, > > Ran Ran, You are suggesting if A then !B. I prefer if A and B, then C. Your proposed if A then !B implies: 1. A guest subnet cannot be supported. 2. A separate legacy device subnet with IPv4 NAT can't be supported. 3. A subnet for delay sensitive local audio and/or video devices can't be supported. 4. Delay and jitter sensitive devices such as SIP phone can't be put on a separate subnet. 5. All WiFi and LOWPAN and GbE segments must be bridged together ragardless of preformance penalties. 6. Performance pigs can't be isolated. I think these were all objectives we would like to support. If supporting this means splitting up a /64 if A, then I'm for it. If some device can't live without SLAAC, then the consumer has two choices. Either 1) bridge everything together, or 2) complain until you get a firmware upgrade or get rid of that device. I'd pick 2 above, but I'm not the average consumer and neither is anyone on this list. I suspect many of us (but not most) already have subnets in our homes, and do so for good reasons. Curtis From rja.lists@gmail.com Mon Oct 1 12:18:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF521F8808 for ; Mon, 1 Oct 2012 12:18:38 -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 aY4Eu+FiNBMf for ; Mon, 1 Oct 2012 12:18:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF54121F8804 for ; Mon, 1 Oct 2012 12:18:31 -0700 (PDT) Received: by qcac10 with SMTP id c10so3219616qca.31 for ; Mon, 01 Oct 2012 12:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZdUdRmL/XzLF2KSpdXSXjgWLNjMgiUSkVyMuv67YEj8=; b=o59BPaHLFF9KcJ8wwdjZBXSIZ30eKySGFG+nrox5uhz7OT8MKbtmrkFQxESLeWZmLb 4+hC2E3lvigaTu7A2bVwfDHFje1i7tQ0t5fORHVXG29YHFdsBHiOqMOSA+VpQ6rvp04J RmGsbHSzt2ICseSWisrxIH3zfXHz7Ybhjeq0Ao7CdcQv5AAm0mPnS4jk45P/hZ8PMoUH az+A9PDRKkFZhiKlYICETEPdkhDDBEmsYRCJiPxNGB72xVWrz92RXLbLeViu23rzOwld NlGltsyWTSBKvJM1fe37lD/n2gRFM1YTDnt6NKegcjxtVThcfSdmfBUuQdZtOyGq/ZJt 5ygQ== Received: by 10.224.206.131 with SMTP id fu3mr39158044qab.27.1349119111308; Mon, 01 Oct 2012 12:18:31 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id bx11sm617454qab.0.2012.10.01.12.18.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 12:18:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <201210011901.q91J1FKW056959@gateway1.orleans.occnc.com> Date: Mon, 1 Oct 2012 15:18:29 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2DA2A3E2-F4E7-4D34-826A-DEFCEB2F4C5A@gmail.com> References: <201210011901.q91J1FKW056959@gateway1.orleans.occnc.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 19:18:38 -0000 On 01 Oct 2012, at 15:01 , Curtis Villamizar wrote: > You are suggesting if A then !B. No, my apologies for being unclear. I am NOT, repeat NOT, suggesting that. (A & !B) is a possible deployment option, of course, but it is not the ONLY option either. > I prefer if A and B, then C. I understand you have a personal preference. A set of people on this list have indicated that particular preference is strongly undesirable. However, disallowing SLAAC is NOT the ONLY conceivable approach. One ought to try to think of other options (each of which probably has different tradeoffs). Yours, Ran From damien.saucez@gmail.com Mon Oct 1 13:09:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8648D11E814B for ; Mon, 1 Oct 2012 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 3jT8ZaK5IFGl for ; Mon, 1 Oct 2012 13:09:18 -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 C329711E80D5 for ; Mon, 1 Oct 2012 13:09:17 -0700 (PDT) Received: by eaak13 with SMTP id k13so2075487eaa.31 for ; Mon, 01 Oct 2012 13:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DoYeW2Gor8SblC4pRXarSabOb+cSWhJW27XkIO701/c=; b=a8O0PsCAwbePyfKjD6xLOqNgmsUZymKwO29sC10qZT91B9E/jxFi/4DSKMI9dQA6BA W76UbxvUDjyuCZ6ofe5fOqcBbgn9MDX87hwUw+G67oST9Bhnl23tCiUbsCQYteitjVyA yYHJ7EmS2JHg6yv8be6jTHTZCjjmDrksfrXffvJnbaaV66z74oE9so5tyjq/W/bov7ZK 7PDvuSaThGr6KtWIloAf6wHPsa8/iI3P7r+GjHLsLcv3XwR6+IpgPG4I1ltcZKcSrZBw +tsVC3cI0F4kmvfhfag5v7MgiD0QPSd4m2G6YMZRz9uz0cJEx3xhJe4N9gwngKDWQHnk ZT3A== Received: by 10.14.221.69 with SMTP id q45mr6591767eep.36.1349122155322; Mon, 01 Oct 2012 13:09:15 -0700 (PDT) Received: from sop076s.vpn.inria.fr (sop076s.vpn.inria.fr. [138.96.228.76]) by mx.google.com with ESMTPS id 9sm50669202eei.12.2012.10.01.13.09.13 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 13:09:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Damien Saucez In-Reply-To: <50698D7F.5000003@gmail.com> Date: Mon, 1 Oct 2012 22:09:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210010121.q911Lsbp031067@gateway1.orleans.occnc.com> <2C25872F-9E9D-49B4-BEDA-C82E0EBC485F@gmail.com> <50698D7F.5000003@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1498) Cc: "homenet@ietf.org Group" , Wassim Haddad , curtis@occnc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 20:09:18 -0000 On 01 Oct 2012, at 14:33, Brian E Carpenter = wrote: > On 01/10/2012 08:32, Damien Saucez wrote: >> Curtis, >>=20 >> Thank you for the comments. >>=20 >> Our target in this document is to raise the question of multihoming >> in personal and/or small/medium enterprise networks, so for now >> we were not looking at the mobile device such as smartphones >> connected to both 4g and wifi (for this, the multihoming solution >> must be implemented directly on the device). We believe that >> SOHO would be interested being multihomed but can't afford the >> cost of operating multihoming themselves.=20 >=20 > That's a good description of why the IETF designed SHIM6, which = requires > no cooperation from any router or ISP and scales well, should cost = little > or nothing, and will work for mobile devices too, on two conditions >=20 > 1. It becomes widely deployed > 2. Firewalls allow the SHIM6 extension header. >=20 > I don't believe that this is really a topic for homenet, however. >=20 Well, I don't really like shim6 in this situation because it requires every host to implement shim6 (is shim6 in a sensor or in an access controller reasonable?). Also it is not straightforward with shim6 how to allow one to manage the devices in its network. In other words, how to outsource traffic control if shim6 is used? If I remember well the discussion a few years ago in shim6, the lack of easy management was sometime pinpointed. Damien Saucez > Brian From brian.e.carpenter@gmail.com Mon Oct 1 14:15:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714AA1F0CD6 for ; Mon, 1 Oct 2012 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ekycAyhgevk for ; Mon, 1 Oct 2012 14:15:03 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C64B51F040A for ; Mon, 1 Oct 2012 14:15:03 -0700 (PDT) Received: by iec9 with SMTP id 9so15291144iec.31 for ; Mon, 01 Oct 2012 14:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=atEIV4BdgUUKM1tOdUWbJWrHBNFXnPSnSy6RsoaU3lU=; b=ScI1YxvY1mjr2h/2hiTjeCCy2nW2qTCKkJUAUU1M4AwfFPoRNY1y83LBbn23UvE98W MLWlg8j+yWEAyosVeokEAFgc4XmiONh+YhzYjGQRk4TKo9Y68gOh42X//KwjZQsQa1pN Z2eAFCJe29TjrUuBJUKDeu1G3WTyeQIYXACxunAXLpVioHC7mqw7tdrxNbSt1u9m/aks LqV7JEE7kTfqZv4ZWVyCJe1Cnk2HfXPiyepNr/dNF5qzVkE8KCBCDrhubWK/o4eoKz1T aZDu5MLyFpWOrI993CPnS2IYM7rBTEo2D/Q5nrlgVID4OztGlf0vWYfIgtfkAs1ejWUG IfNQ== Received: by 10.50.16.143 with SMTP id g15mr7124395igd.9.1349126103366; Mon, 01 Oct 2012 14:15:03 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id ff4sm7888509igc.5.2012.10.01.14.15.01 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 14:15:02 -0700 (PDT) Message-ID: <506A07D1.8050605@gmail.com> Date: Mon, 01 Oct 2012 22:14:57 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com, Damien Saucez References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> In-Reply-To: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Wassim Haddad Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:15:04 -0000 Curtis & Damien, On 01/10/2012 19:01, Curtis Villamizar wrote: > In message <50698D7F.5000003@gmail.com> > Brian E Carpenter writes: > >> On 01/10/2012 08:32, Damien Saucez wrote: >>> Curtis, >>> >>> Thank you for the comments. >>> >>> Our target in this document is to raise the question of multihoming >>> in personal and/or small/medium enterprise networks, so for now >>> we were not looking at the mobile device such as smartphones >>> connected to both 4g and wifi (for this, the multihoming solution >>> must be implemented directly on the device). We believe that >>> SOHO would be interested being multihomed but can't afford the >>> cost of operating multihoming themselves. >> >> That's a good description of why the IETF designed SHIM6, which requires >> no cooperation from any router or ISP and scales well, should cost little >> or nothing, and will work for mobile devices too, on two conditions >> >> 1. It becomes widely deployed >> 2. Firewalls allow the SHIM6 extension header. >> >> I don't believe that this is really a topic for homenet, however. >> >> Brian > > > Brian, > > Your item #2 might be worth recording somewhere as a requirement if it > is not already in rfc6204bis. (I didn't look). No. See https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/ which it might be useful to discuss in Atlanta. > > If shim6 is the recommendation on the part of homenet as to how to > deal with multihoming in the home, then this is significant and should > be in the framework. It isn't a recommendation as far as I know, but shim6 was designed for use by small sites unlikely to operate a PI prefix and/or a routing-based approach to multihoming. On 01/10/2012 21:09, Damien Saucez wrote: > Well, I don't really like shim6 in this situation because it requires > every host to implement shim6 (is shim6 in a sensor or in an access > controller reasonable?). Probably not, but aren't such devices very likely to be gatewayed by some sort of building services server anyway, which is where the multihoming comes in? (There was some early work done on proxy shim6, for such cases.) > Also it is not straightforward with shim6 how > to allow one to manage the devices in its network. In other words, > how to outsource traffic control if shim6 is used? If I remember well > the discussion a few years ago in shim6, the lack of easy > management was sometime pinpointed. Yes, by ISPs who want to use BGP-style traffic engineering for larger customers. I don't think that applies to homenets. There is also a problem of exit selection, and although not explicitly aimed at shim6, that issue also comes up in draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. As far as I can tell, multihoming is not mentioned in the homenet charter, but it is discussed in draft-ietf-homenet-arch, without a clear conclusion. There is an argument for a specific analysis document on this topic, before we discuss our favourite solutions. Brian From curtis@occnc.com Mon Oct 1 14:33:10 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0DA1F0D68 for ; Mon, 1 Oct 2012 14:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk8T4CKUV+Bu for ; Mon, 1 Oct 2012 14:33:10 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 404811F0D66 for ; Mon, 1 Oct 2012 14:33:10 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q91LX7Zw057822; Mon, 1 Oct 2012 17:33:07 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210012133.q91LX7Zw057822@gateway1.orleans.occnc.com> To: RJ Atkinson From: Curtis Villamizar In-reply-to: Your message of "Mon, 01 Oct 2012 15:18:29 EDT." <2DA2A3E2-F4E7-4D34-826A-DEFCEB2F4C5A@gmail.com> Date: Mon, 01 Oct 2012 17:33:07 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:33:11 -0000 In message <2DA2A3E2-F4E7-4D34-826A-DEFCEB2F4C5A@gmail.com> RJ Atkinson writes: > > On 01 Oct 2012, at 15:01 , Curtis Villamizar wrote: > > You are suggesting if A then !B. > > No, my apologies for being unclear. > I am NOT, repeat NOT, suggesting that. > > (A & !B) is a possible deployment option, of course, > but it is not the ONLY option either. > > > I prefer if A and B, then C. > > I understand you have a personal preference. > > A set of people on this list have indicated that > particular preference is strongly undesirable. I agree that it is *very* undesirable. It does work. I've tried it. > However, disallowing SLAAC is NOT the ONLY conceivable > approach. One ought to try to think of other options > (each of which probably has different tradeoffs). AFAIK SLAAC requires a /64 prefix. Is that not true? Or are you suggesting changing it? > Yours, > > Ran If A and B, then C is a possibility. Only if C does SLAAC have to get disabled. It's not a good option and not every toy is going to play nice but if it is forced, for some it may be the best option. Another option is to use a tunnel rather than the ISP native IPv6 if the ISP won't allocate prefixes other than /64. I've had a lengthy off-list discussion with Joel. There is mixed response from one MSO, with /128 in a lame limited city trial today, /64 RSN (for some unspecified value of RSN), and shorter prefix still later. Its this sort of preference for a one size fits all least common denominator at a provider that has me concerned that some consumers may be stuck with a /64. It would be helpful if we had a consumer-ISP requirements from some WG, but homenet might not be the place. It may be the homenet can say that in order for things to work in the home certain things are required of the ISP or highly desireable (DHCPv6 prefix allocation, DNS and rDNS delegation and secondary, at least /60 on request and preferably without additional charge, etc). Would that be out-of-scope for homenet, and if so, in what WG would it be in-scope? If none, then can it become in-scope (charter update)? Curtis btw- if DHCP is not used, then dynamic DNS has to get popluated directly from the host and each host needs the key needed to make its DDNS update (and not someone else's DDNS update) and it also needs to know where the DDNS server is. This seems a lot more problematic than putting DHCPv6 client on the host. Lack of either means DDNS doesn't get updated. Also if DHCPv6 is not used, the domain name, DNS search list, nameserver list, ntpservers, .. etc, still have to be populated. From dave.taht@gmail.com Mon Oct 1 14:41:30 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9893D1F0D3F for ; Mon, 1 Oct 2012 14:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ILQF73b2glC for ; Mon, 1 Oct 2012 14:41:29 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB21F0D1D for ; Mon, 1 Oct 2012 14:41:28 -0700 (PDT) Received: by wibhr7 with SMTP id hr7so38647wib.13 for ; Mon, 01 Oct 2012 14:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8ps+UM1WkzF4EUG+W1ulI+qEAJEsp5jUp/mQlqCrzyQ=; b=Bi1Tw1FPZ2GjuYed72kFBxr6n+zL+gFp98V0kxYccM7GPAYIQfzFkerFsZqtmB15kL x4V1MccTTC4FrPtaRlNyt9FeAYAkDnZuo6MMf0JLAikX1jxoXItf0Lg6ji1XZgPZ3fdt mJIZgJN2C/izs+BCnshF0mdw3pj4c4ze3W5Uxe0SW1A5gj7xN2CivFhzCYvf5hGJDFT7 kiVz6n4kx+PEfE/EyUpm7hnUKygTvIOlCxsKFqiQcnLQLowxpezulOkb15lLeE6RNJiV WRh+xKTojctBhWulrp2gZJeYLHPZ6Yc2uIvK3wHab7dQ8pPX8G5qwQanxW/Z50e1RqDX 3lVw== MIME-Version: 1.0 Received: by 10.216.131.161 with SMTP id m33mr3980907wei.13.1349127687358; Mon, 01 Oct 2012 14:41:27 -0700 (PDT) Received: by 10.227.28.161 with HTTP; Mon, 1 Oct 2012 14:41:27 -0700 (PDT) In-Reply-To: <201210012133.q91LX7Zw057822@gateway1.orleans.occnc.com> References: <2DA2A3E2-F4E7-4D34-826A-DEFCEB2F4C5A@gmail.com> <201210012133.q91LX7Zw057822@gateway1.orleans.occnc.com> Date: Mon, 1 Oct 2012 14:41:27 -0700 Message-ID: From: Dave Taht To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:41:30 -0000 I have been tracking this conversation for a while, excuse the top post. 0) The state of cable modems is rather dismal as yet, with none that I'm aware of able to distribute anything bigger than /64. 6to4 is still the best option on that technology in the US. 1) At least some markets outside the USA (NZ, for sure) are managing to distribute /56 addresses via DSL/fiber 2) SLAAC is needed, too many dumb devices only implement that. I note that dnsmasq now contains a clever hack to utilize dhcpv4 information to correctly assign names to SLAAC based addresses. 3) I gave up on the whole /64 and slaac vs dhcpv6 debate years ago and went to ahcp, not that I'm ever going to get any traction on it, regardless of how well it solves 0, above. On Mon, Oct 1, 2012 at 2:33 PM, Curtis Villamizar wrote: > > In message <2DA2A3E2-F4E7-4D34-826A-DEFCEB2F4C5A@gmail.com> > RJ Atkinson writes: > >> >> On 01 Oct 2012, at 15:01 , Curtis Villamizar wrote: >> > You are suggesting if A then !B. >> >> No, my apologies for being unclear. >> I am NOT, repeat NOT, suggesting that. >> >> (A & !B) is a possible deployment option, of course, >> but it is not the ONLY option either. >> >> > I prefer if A and B, then C. >> >> I understand you have a personal preference. >> >> A set of people on this list have indicated that >> particular preference is strongly undesirable. > > I agree that it is *very* undesirable. It does work. I've tried it. > >> However, disallowing SLAAC is NOT the ONLY conceivable >> approach. One ought to try to think of other options >> (each of which probably has different tradeoffs). > > AFAIK SLAAC requires a /64 prefix. Is that not true? Or are you > suggesting changing it? > >> Yours, >> >> Ran > > If A and B, then C is a possibility. > > Only if C does SLAAC have to get disabled. It's not a good option and > not every toy is going to play nice but if it is forced, for some it > may be the best option. Another option is to use a tunnel rather than > the ISP native IPv6 if the ISP won't allocate prefixes other than /64. > > I've had a lengthy off-list discussion with Joel. There is mixed > response from one MSO, with /128 in a lame limited city trial today, > /64 RSN (for some unspecified value of RSN), and shorter prefix still > later. Its this sort of preference for a one size fits all least > common denominator at a provider that has me concerned that some > consumers may be stuck with a /64. > > It would be helpful if we had a consumer-ISP requirements from some > WG, but homenet might not be the place. > > It may be the homenet can say that in order for things to work in the > home certain things are required of the ISP or highly desireable > (DHCPv6 prefix allocation, DNS and rDNS delegation and secondary, at > least /60 on request and preferably without additional charge, etc). > Would that be out-of-scope for homenet, and if so, in what WG would it > be in-scope? If none, then can it become in-scope (charter update)? > > Curtis > > > btw- if DHCP is not used, then dynamic DNS has to get popluated > directly from the host and each host needs the key needed to make its > DDNS update (and not someone else's DDNS update) and it also needs to > know where the DDNS server is. This seems a lot more problematic than > putting DHCPv6 client on the host. Lack of either means DDNS doesn't > get updated. Also if DHCPv6 is not used, the domain name, DNS search > list, nameserver list, ntpservers, .. etc, still have to be populated. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From andrewmcgr@gmail.com Mon Oct 1 15:50:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984911F0D3F for ; Mon, 1 Oct 2012 15:50:15 -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 3xgU3uc+lj2v for ; Mon, 1 Oct 2012 15:50:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B01A51F0D1D for ; Mon, 1 Oct 2012 15:50:14 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so8272918pbb.31 for ; Mon, 01 Oct 2012 15:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=B5RMGihIPGj0Q2Nzf0dxAFs+w0IVygVLjgL6xmLripo=; b=WvIhBZZTbrx2qWuhzq1W429GMW/S0gTLI99RXI4l1zf9CLOFvMqF0tmygXTRQyQ2dU XCORC4rRp8JUaFrsKZKSM3y8a6u6GfUTcwG+adBGQmNjkHHcebgi3GC77nxOmuaCeLn3 q0T2nNtLS0P7Q3VEI7H8JjlNEQ2slhHDhN0XPLEeiqQwIlxw/H5gGo9gUV6gr0O5NOPn qBE6cZ5Wf4F3GX6ZJlf5yYUxCqKeXN8zBcwUwQpmntjXcWs1jzVEEQMwwxkLQ9Sh9Dsg IlMC4QMKbvMfFseaNy1GTn8MtXRd/UvMBKts3CBnSePGY8yDysmaKzDCl4BBGg9MtiIF 1paw== Received: by 10.68.197.104 with SMTP id it8mr45062596pbc.167.1349131814259; Mon, 01 Oct 2012 15:50:14 -0700 (PDT) Received: from andrewm-lo.ws.atlnz.lc (gate1.alliedtelesyn.co.nz. [202.49.72.36]) by mx.google.com with ESMTPS id d9sm11027169paw.35.2012.10.01.15.50.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 15:50:13 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Andrew McGregor In-Reply-To: Date: Tue, 2 Oct 2012 11:50:07 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DA2A3E2-F4E7-4D34-826A-DEFCEB2F4C5A@gmail.com> <201210012133.q91LX7Zw057822@gateway1.orleans.occnc.com> To: Dave Taht X-Mailer: Apple Mail (2.1498) Cc: homenet@ietf.org, RJ Atkinson , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 22:50:15 -0000 In fact, my connection in NZ gives me a /48 via DHCPv6 PD, although some = providers I gather are doing /56. Andrew On 2/10/2012, at 10:41 AM, Dave Taht wrote: > I have been tracking this conversation for a while, excuse the top = post. >=20 > 0) The state of cable modems is rather dismal as yet, with none that > I'm aware of able to distribute anything bigger than /64. 6to4 is > still the best option on that technology in the US. > 1) At least some markets outside the USA (NZ, for sure) are managing > to distribute /56 addresses via DSL/fiber > 2) SLAAC is needed, too many dumb devices only implement that. >=20 > I note that dnsmasq now contains a clever hack to utilize dhcpv4 > information to correctly assign names to SLAAC based addresses. >=20 > 3) I gave up on the whole /64 and slaac vs dhcpv6 debate years ago and > went to ahcp, not that I'm ever going to get any traction on it, > regardless of how well it solves 0, above. >=20 > On Mon, Oct 1, 2012 at 2:33 PM, Curtis Villamizar = wrote: >>=20 >> In message <2DA2A3E2-F4E7-4D34-826A-DEFCEB2F4C5A@gmail.com> >> RJ Atkinson writes: >>=20 >>>=20 >>> On 01 Oct 2012, at 15:01 , Curtis Villamizar wrote: >>>> You are suggesting if A then !B. >>>=20 >>> No, my apologies for being unclear. >>> I am NOT, repeat NOT, suggesting that. >>>=20 >>> (A & !B) is a possible deployment option, of course, >>> but it is not the ONLY option either. >>>=20 >>>> I prefer if A and B, then C. >>>=20 >>> I understand you have a personal preference. >>>=20 >>> A set of people on this list have indicated that >>> particular preference is strongly undesirable. >>=20 >> I agree that it is *very* undesirable. It does work. I've tried it. >>=20 >>> However, disallowing SLAAC is NOT the ONLY conceivable >>> approach. One ought to try to think of other options >>> (each of which probably has different tradeoffs). >>=20 >> AFAIK SLAAC requires a /64 prefix. Is that not true? Or are you >> suggesting changing it? >>=20 >>> Yours, >>>=20 >>> Ran >>=20 >> If A and B, then C is a possibility. >>=20 >> Only if C does SLAAC have to get disabled. It's not a good option = and >> not every toy is going to play nice but if it is forced, for some it >> may be the best option. Another option is to use a tunnel rather = than >> the ISP native IPv6 if the ISP won't allocate prefixes other than = /64. >>=20 >> I've had a lengthy off-list discussion with Joel. There is mixed >> response from one MSO, with /128 in a lame limited city trial today, >> /64 RSN (for some unspecified value of RSN), and shorter prefix still >> later. Its this sort of preference for a one size fits all least >> common denominator at a provider that has me concerned that some >> consumers may be stuck with a /64. >>=20 >> It would be helpful if we had a consumer-ISP requirements from some >> WG, but homenet might not be the place. >>=20 >> It may be the homenet can say that in order for things to work in the >> home certain things are required of the ISP or highly desireable >> (DHCPv6 prefix allocation, DNS and rDNS delegation and secondary, at >> least /60 on request and preferably without additional charge, etc). >> Would that be out-of-scope for homenet, and if so, in what WG would = it >> be in-scope? If none, then can it become in-scope (charter update)? >>=20 >> Curtis >>=20 >>=20 >> btw- if DHCP is not used, then dynamic DNS has to get popluated >> directly from the host and each host needs the key needed to make its >> DDNS update (and not someone else's DDNS update) and it also needs to >> know where the DDNS server is. This seems a lot more problematic = than >> putting DHCPv6 client on the host. Lack of either means DDNS doesn't >> get updated. Also if DHCPv6 is not used, the domain name, DNS search >> list, nameserver list, ntpservers, .. etc, still have to be = populated. >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From rja.lists@gmail.com Tue Oct 2 03:45:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EF921F8A4B for ; Tue, 2 Oct 2012 03:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 APFA+jDMdswq for ; Tue, 2 Oct 2012 03:45:53 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3921F8A67 for ; Tue, 2 Oct 2012 03:45:52 -0700 (PDT) Received: by qabj40 with SMTP id j40so453172qab.10 for ; Tue, 02 Oct 2012 03:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=uzYzkosg5XVGMhN+erIe48UNT12gho9rrUNB6c1l74A=; b=bTVLVAbpg/nqNdG6ve9P3UEv6J6bJySxHPMNcbUACZHwU8CeKbZR8JudlKrJSDkZcK dQjIyJ4g2zWQIcpBlmei6MDndL3Yd+erZ3/qG+rzzWu4fgNQKc06jsuDXptuVwsHhCbz yE+NwQHt6ssXr/eNBp4GWmLOY+dGF3N9i3mZqe7HvawWoIdCNTqzkrP+YXDhY8iLPGpW KNc+MF+xPVFIEf7y2S5BjLPRYx78QN7Gaj1MNlQIq+gONfwTGnu0lrMJs6cYPSdZSP/g 7q6/rXocCquszDsfz2NFojszJ2qPIPM/+aJIrf5gxS+hDAEVOQZhPqrRVmt/8jsXjGzf WTbg== Received: by 10.224.53.18 with SMTP id k18mr1675872qag.1.1349174752189; Tue, 02 Oct 2012 03:45:52 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id fy1sm1118117qab.10.2012.10.02.03.45.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 03:45:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <201210012133.q91LX7Zw057822@gateway1.orleans.occnc.com> Date: Tue, 2 Oct 2012 06:45:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6553243C-6506-4BB2-B290-E93A857CD4DD@gmail.com> References: <201210012133.q91LX7Zw057822@gateway1.orleans.occnc.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:45:54 -0000 On 01 Oct 2012, at 17:33 , Curtis Villamizar wrote: >>> I prefer if A and B, then C. >> >> I understand you have a personal preference. >> >> A set of people on this list have indicated that >> particular preference is strongly undesirable. > > I agree that it is *very* undesirable. It does work. I've tried it. It does not *generally* work. If it works for you, that says more about what kind of equipment you are connecting -- and the capabilities of that equipment (e.g. DHCPv6) than anything else. Particularly, DHCPv6 does not work with some widely deployed consumer electronics gear -- gear that only supports SLAAC. >> However, disallowing SLAAC is NOT the ONLY conceivable >> approach. One ought to try to think of other options >> (each of which probably has different tradeoffs). > > AFAIK SLAAC requires a /64 prefix. Yes. > Or are you suggesting changing it? No. > If A and B, then C is a possibility. One of several different possibilities. That one is particularly ugly because it means that some devices won't be able to connect to the network *at all*. Most consumers expect ALL of their devices to be able to connect with and use their home network. Anything less generally is viewed as not satisfactory. > Another option is to use a tunnel rather than > the ISP native IPv6 if the ISP won't allocate > prefixes other than /64. Yes. Other options also exist. > It may be the homenet can say that in order for things to work > in the home certain things are required of the ISP or highly > desirable (DHCPv6 prefix allocation, DNS and rDNS delegation > and secondary, at least /60 on request and preferably without > additional charge, etc). That sounds sensible to me -- and HIGHLY preferable to having HomeNet encourage ISPs to delegate /64s (or even longer prefixes) by standardising kludges that work only for special cases -- or only for equipment with features not universally available now/soon. > btw- if DHCP is not used, then dynamic DNS > has to get populated directly from the host This likely is true EVEN IF one has DHCPv6 in use. Running DHCPv6 does NOT automatically mean that the DNS gets populated correctly. Some DHCPv6 servers might have this capability, but other DHCPv6 servers definitely do not do this. (new topic) You seem to have a very particular brand/make/model of equipment in mind when you write about deployments. IMHO, HomeNet needs to work *in the general case*, without limiting its workability to Brand X, Model Y equipment running software version Z. Yours, Ran From robert.cragie@gridmerge.com Tue Oct 2 08:49:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F4621F8518 for ; Tue, 2 Oct 2012 08:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 G48D6nTjFT5H for ; Tue, 2 Oct 2012 08:49:38 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6328D21F8523 for ; Tue, 2 Oct 2012 08:49:37 -0700 (PDT) Received: from client-82-26-94-106.pete-bam-1.adsl.virginmedia.com ([82.26.94.106] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TJ4j0-00086z-Ic for homenet@ietf.org; Tue, 02 Oct 2012 16:49:35 +0100 Message-ID: <506B0D3E.80400@gridmerge.com> Date: Tue, 02 Oct 2012 16:50:22 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201210011811.q91IB8vl056686@gateway1.orleans.occnc.com> In-Reply-To: <201210011811.q91IB8vl056686@gateway1.orleans.occnc.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040008020704080408030300" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:49:40 -0000 This is a cryptographically signed message in MIME format. --------------ms040008020704080408030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Curtis, Comments inline, bracketed by Robert On 01/10/2012 7:11 PM, Curtis Villamizar wrote: > In message > Don Sturek writes: > =20 >> Hi Curtis, >> =20 >> On the topic of "link local on each subnet and a routing protocol work= s >> for any topology....." >> =20 >> In using 6LoWPAN with ROLL (route over), you end up with a mesh networ= k >> where the scope of link local address is only between a single device = in >> the mesh and its one-hop neighbors (not among all devices in the mesh)= =2E >> =20 >> In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communicat= ions >> between all devices in a single mesh subnet. >> =20 >> Don > > Don, > > The "subnet" is meant in IETF terms, not ITU subnetwork. The subnet > is therefore anything link local by definition. Not in the case of RPL or MANETs. This is a multi-link subnet where = routers within the subnet are L3 forwarders (aka "route over"). > A 6LoWPAN node can > get a GUA and use the GUA (or link local address) of a router as a > default route. If the 6LoWPAN device needs only site connectivity > then it can use the link local address for everything. Again, not true in RPL or MANETs. As Don points out, in a RPL/MANET = network, link local means your one-hop neighbors only. > > If a routing protocol is in use and is using link local based host > routes, then a router must fake the DAD collision if a duplicate is > found anywhere within the site. If a multiple ULA are used, one per > subnet, then DAD is only relevant to the subnet. A router should pick > a ULA prefix that is not already in use elsewhere in the site. In the multi-link subnet, typically a single ULA or GUA would be=20 used for the whole subnet including the routers. Multihoming may be=20 necessary depending on external connectivity. > > An extremely low probability race condition exists, but it is a race > condition among routers with multiple routers picking and advertising > the exact same ULA prefix in the routing protocol very nearly > simultaneously (within LAN flooding interval). A wait and backoff can > solve this even though it is a miniscule probability. > > A mesh in IETF terminology is by definition multiple subnets. A > subnet is by definition link local. Again, not according to RPL and MANET protocols. There does seem to = have been some discussion on this which probably needs to be resurrected = (see RFC 4903). > > Curtis > > >> On 9/30/12 3:36 PM, "Curtis Villamizar" wrote: >> =20 >>> In message >>> Don Sturek writes: >>> >>>> Hi Robert, >>>> =20 >>>> One more point touched on in your note below: >>>> 1) Ideally, it would be great if a single authorizatative device >>>> existed >>>> in the home providing DHCPv6 server services (if supported) and pref= ix >>>> delegation. >>>> =20 >>>> One challenge in the description below is having multiple routers on= >>>> multiple subnets, each possibly acting as a DHCPv6 server within the= ir >>>> own >>>> subnet and also providing their own ULA prefix. >>>> =20 >>>> We certainly don't want to further confuse address assignment in a >>>> setting >>>> where IT support does not exist. >>>> =20 >>>> Don >>> >>> We want things to "just work" witb no config. Link local on each >>> subnet and a routing protocol works for any topology. ULA just allow= s >>> summarization of subnets in the routing protocol, such that host >>> routes are not needed (though not a big deal if host routes are used >>> in a homenet). >>> >>> This would "just work" when using link local or ULA. How to subdivid= e >>> a GUA prefix among the subnets is another issue. >>> >>> In principle, though I know of no proposals to do this yet, the set o= f >>> GUA that are available from one of more routers with a provider link >>> could be coordinated via the routing protocol (for example, using a >>> new OSPF Opaque LSA). >>> >>> Curtis >>> >>> >>>> On 9/25/12 1:57 AM, "Robert Cragie" wr= ote: >>>> =20 >>>>> So let's tweak Curtis' sequence slightly: >>>>> >>>>> What every host does is: >>>>> >>>>> if it has no MAC: >>>>> pick a random link local address >>>>> else >>>>> use the MAC to create a link local address >>>>> run DAD to make sure no one else has same address >>>>> >>>>> send a RS >>>>> >>>>> if it gets RA >>>>> use the RA prefix for SLAAC >>>>> else >>>>> time out and don't bother with SLAAC; can only use link local >>>> address >>>>> then hopefully the host also does the following: >>>>> >>>>> send DHCPv6 client request >>>>> >>>>> if response >>>>> it has yet another address to pick from if it got one using SLA= AC >>>>> else >>>>> time out and get nothing from DHCPv6 >>>>> >>>>> This should work fine for legacy APs where everything is bridged >>>>> underneath it. Where it gets interesting is in the case of cascaded= >>>>> subnets behind a router connected to an ISP, where one or more of t= hose >>>>> subnets may be a mesh network comprised of mesh routers and hosts. = I am >>>>> not quite sure how ULAs and DHCPv6 would work in this case as there= are >>>>> limitations as far as I can see (although I accept I probably have = a >>>> bit >>>>> more reading to do on the subject). >>>>> >>>>> Robert >>>>> >>>>> On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >>>>>> In message >>>>>> Don Sturek writes: >>>>>> =20 >>>>>>> Hi Curtis, >>>>>>> =20 >>>>>>> I think the difficulty is each device cannot "use the MAC to crea= te >>>> a >>>>>>> ULA >>>>>>> address". Some authoritative device in the network (eg, the AP) >>>> must >>>>>>> create the ULA prefix. If a ULA prefix is not present because th= e >>>> AP >>>>>>> is a >>>>>>> legacy device not capable of providing a ULA prefix, the STA devi= ces >>>>>>> must >>>>>>> use link locals only. >>>>>>> =20 >>>>>>> Don >>>>>> Don, >>>>>> >>>>>> You are right about there being nothing to generate the ULA prefix= in >>>>>> your example. My mistake. >>>>>> >>>>>> But it doesn't change anything. If the AP is a dumb bridge and th= ere >>>>>> is no router of any kind, then link local addresses are perfectly >>>>>> fine. There is only one subnet in that example, and ULA is not >>>>>> needed. That was the example you gave. >>>>>> >>>>>> Your example had no router just an old AP that acted as a bridge, >>>>>> therefore nothing to generate any sort of RA. If there is a route= r >>>>>> and no GUA prefix (which is not your example, but a useful example= ), >>>>>> then ULA can be used. The only RA that is seen is the RA providin= g a >>>>>> ULA prefix which the router can generate. >>>>>> >>>>>> I did say that the possibility of having to subdivide a /64 only >>>>>> exists for GUA. If a router exists which gets a GUA from a provid= er, >>>>>> and there are more subnets than the prefix length can support the = two >>>>>> options are the ones listed below. (Search for --or--). >>>>>> >>>>>> Curtis >>>>>> >>>>>> >>>>>>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote:= >>>>>>> =20 >>>>>>>> In message >>>>>>>> Don Sturek writes: >>>>>>>> >>>>>>>>> Hi Curtis, >>>>>>>>> =20 >>>>>>>>> I would expect most Wi-Fi AP manufacturers to support the same >>>>>>>>> address >>>>>>>>> assignment they do today (ie, manual assignment and DHCP). I >>>> would >>>>>>>>> also expect as more IPv6 deployments happen that SLAAC will als= o >>>> be >>>>>>>>> supported (and, yes, even for GUA). >>>>>>>>> =20 >>>>>>>>> For the types of devices which will be added to Wi-Fi networks = in >>>> the >>>>>>>>> future (eg, headless devices like appliances, thermostats, etc.= ) >>>> that >>>>>>>>> the preferred address assignment will be SLAAC and DHCPv6 (and,= >>>> yes, >>>>>>>>> I >>>>>>>>> purposely did not remove SLAAC.....) >>>>>>>>> =20 >>>>>>>>> Don >>>>>>>> Don, >>>>>>>> >>>>>>>> We seem to be talking past each other so let me again try to be >>>> clear. >>>>>>>> What every host does is: >>>>>>>> >>>>>>>> if it has no MAC: >>>>>>>> pick a random link local (not ULA) address >>>>>>>> else >>>>>>>> use the MAC to create a ULA address >>>>>>>> run DAD to make sure no one else has same address >>>>>>>> >>>>>>>> send a RS >>>>>>>> >>>>>>>> if it gets RA >>>>>>>> use the RA prefix for SLAAC >>>>>>>> else >>>>>>>> time out and don't bother with SLAAC >>>>>>>> >>>>>>>> then hopefully the host also does the following: >>>>>>>> >>>>>>>> send DHCPv6 client request >>>>>>>> >>>>>>>> if response >>>>>>>> it has yet another address to pick from if it got one using= >>>> SLAAC >>>>>>>> else >>>>>>>> time out and get nothing from DHCPv6 >>>>>>>> >>>>>>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 ser= ver >>>>>>>> the address that it already has (from SLAAC). >>>>>>>> >>>>>>>> If as in the case of your Wi-Fi with a bridging AP example, ther= e >>>> is >>>>>>>> no router to give it an DHCPv6 the link local or ULA addresses a= re >>>>>>>> still there and still usable. There is also no router to give i= t >>>> an >>>>>>>> RA response so it has no SLAAC assigned address and no DHCPv6 >>>> assigned >>>>>>>> address. >>>>>>>> >>>>>>>> That is the end of your example. >>>>>>>> >>>>>>>> If there is a router then there is something that can hand out a= >>>> RA or >>>>>>>> DHCPv6 response. >>>>>>>> >>>>>>>> In the case were there exists multiple subnets and the CER has b= een >>>>>>>> granted a /64 (or too few /64s to handle the number of subnets),= >>>> then: >>>>>>>> it can use RA with /64 on some subnets and give them GUA >>>> addresses >>>>>>>> and some subnets have no access outside the homenet >>>>>>>> >>>>>>>> --or-- >>>>>>>> >>>>>>>> it can not use RA (and therefore prevent SLAAC from being use= d) >>>> and >>>>>>>> hand out DHCPv6 addresses and make use of prefixes longer tha= n >>>> /64. >>>>>>>> This prevents the use of CGA but get connectivity to the enti= re >>>>>>>> homenet. >>>>>>>> >>>>>>>> If every consumer oriented provider is willing to allocate prefi= xes >>>>>>>> shorter than /64 on request to home users, then the above situat= ion >>>>>>>> never occurs. If it does, my argument is that the second option= >>>> above >>>>>>>> is better than the first. >>>>>>>> >>>>>>>> Curtis >>>>>>>> >>>>>>>> >>>>>>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrot= e: >>>>>>>>> =20 >>>>>>>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>>>>>>> Jim Gettys writes: >>>>>>>>>> >>>>>>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>> >>>>>>>>>>>> Here is the use case: >>>>>>>>>>>> 1) Customer has a legacy AP in their house >>>>>>>>>>>> 2) Customer brings home new devices supporting IPv6 (which = are >>>>>>>>>>> designed >>>>>>>>>>>> to communicate only with other IPv6 based devices in the hom= e) >>>>>>>>>>>> 3) The only way these new devices can communicate is throug= h >>>>>>>>> address >>>>>>>>>>>> assignment using SLAAC and then some discovery method the tw= o >>>> new >>>>>>>>>>> devices >>>>>>>>>>>> support (without support from the AP). Here these devices a= re >>>>>>>>>>> assuming >>>>>>>>>>>> bridging through the AP...... >>>>>>>>>>> =20 >>>>>>>>>>> And since current legacy AP's all bridge, we win (even though= we >>>>>>>>> need to >>>>>>>>>>> route in the future). >>>>>>>>>> Jim, >>>>>>>>>> >>>>>>>>>> The point was how do you get local IPv6 within the home with t= he >>>>>>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. >>>> First >>>>>>>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>>>>>>> >>>>>>>>>> In this case you use link local or if everything has a MAC you= >>>> can >>>>>>>>>> use >>>>>>>>>> ULA based on the MAC addressses. >>>>>>>>>> >>>>>>>>>>>> Placing a requirement that every customer who buys a new IPv= 6 >>>>>>>>> device, >>>>>>>>>>>> intended to communicate only with other IPv6 devices in the >>>> home, >>>>>>>>> will >>>>>>>>>>>> require a forklift upgrade of a deployed network in order to= >>>> work >>>>>>>>>>> will not >>>>>>>>>>>> be popular. >>>>>>>>>>> =20 >>>>>>>>>>> Good point. >>>>>>>>>> But invalid. The use case Don gave would still work fine. On= ly >>>> GUA >>>>>>>>>> addresses are affected. >>>>>>>>>> >>>>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, >>>> anyway* >>>>>>>>>>> in >>>>>>>>>>> the home environment. >>>>>>>>>>> =20 >>>>>>>>>>> The loathing comes from the exquisite pain of suffering with = a >>>>>>>>>>> flaky >>>>>>>>>>> home network for several months, before realising I had a ro= gue >>>>>>>>>>> DHCP >>>>>>>>>>> server somewhere on my network (from wireshark). I then had = to >>>>>>>>>>> take >>>>>>>>> the >>>>>>>>>>> mac address, figure out who may have manufactured some device= >>>> from >>>>>>>>> that >>>>>>>>>>> information, and finally figured out the little VOIP ATA >>>> adaptor I >>>>>>>>> had >>>>>>>>>>> been given liked to do DHCP. >>>>>>>>>> It did DHCP on the *WAN side*? You didn't put the rest of you= r >>>>>>>>>> network behind the VOIP box on the LAN side I hope. >>>>>>>>>> >>>>>>>>>>> This was by far the hardest debugging I've had to do in my ho= me >>>>>>>>> network >>>>>>>>>>> in normal operation. >>>>>>>>>>> =20 >>>>>>>>>>> This is well beyond normal home debugging capability of >>>> consumers. >>>>>>>>>>> - Jim >>>>>>>>>> We all have plenty of crappy IPv4 product horror stories. My >>>> VOIP >>>>>>>>>> phone locked up now and then and I figured out that if the cal= l >>>>>>>>>> lasted >>>>>>>>>> longer than the DHCPv4 lease, then it lost the least because i= t >>>>>>>>>> didn't >>>>>>>>>> try to renew it. Not only did the call drop, but the device >>>> locked >>>>>>>>>> up. The first solution was to reboot it now and then. The >>>> answer >>>>>>>>>> was >>>>>>>>>> to configure a fixed address. I was lucky to figure it out >>>> before >>>>>>>>>> my >>>>>>>>>> wife threw the phone through a window. For all I know a later= >>>>>>>>>> firmware upgrade might have fixed it. VOIP might be more >>>> popular if >>>>>>>>>> VOIP phones under $600 worked reasonably well. >>>>>>>>>> >>>>>>>>>> Both nice stories, but both are DHCPv4 related and have nothin= g >>>> at >>>>>>>>>> all >>>>>>>>>> to do with SLAAC. >>>>>>>>>> >>>>>>>>>> Curtis >>>>>>>>>> >>>>>>>>>>>> Don >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" >>>> wrote: >>>>>>>>>>>>> In message >>>>>>>>>>>>> Don Sturek writes: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Don >>>>>>>>>>>>> Don, >>>>>>>>>>>>> >>>>>>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>>>>> concerned. >>>>>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joe= l >>>>>>>>> brought >>>>>>>>>>>>> up ILNP in private email, but I beleive ILNP can also work = as >>>> the >>>>>>>>>>>>> constraints in ILNP are in the ILNP identifier which is not= >>>> the >>>>>>>>> same >>>>>>>>>>>>> as the interface address in ILNP for which there is no >>>>>>>>>>>>> constraint. >>>>>>>>>>>>> >>>>>>>>>>>>> I have subnets running fine using a few /112 allocated from= >>>>>>>>> within a >>>>>>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops a= nd >>>>>>>>> DHCPv6 >>>>>>>>>>>>> for dynamic allocations for laptops. It works fine. Link >>>> local >>>>>>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No= >>>> host >>>>>>>>> ever >>>>>>>>>>>>> receives a RA since my routers won't give them one, so no h= ost >>>>>>>>> ever >>>>>>>>>>>>> tries to generate an address using SLAAC. The only >>>> constraint is >>>>>>>>>>> that >>>>>>>>>>>>> any host connecting to my Ethernet or wireless must run a D= HCP >>>>>>>>> client >>>>>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHC= Pv4 >>>>>>>>>>>>> and >>>>>>>>>>>>> DHCPv6 servers are available in every subnet except one GbE= >>>>>>>>> subnet in >>>>>>>>>>>>> the rack and to a few hosts in my home office. >>>>>>>>>>>>> >>>>>>>>>>>>> So as far as I am concerned we have an assertion that no >>>> SLAAC is >>>>>>>>> a >>>>>>>>>>>>> problem and existance proof that it is not. Beside CGA and= >>>>>>>>> requiring >>>>>>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I = not >>>>>>>>>>> support >>>>>>>>>>>>> on these /112 subnets? >>>>>>>>>>>>> >>>>>>>>>>>>> Curtis >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> The argument on /64 as the longest prefix is not that it= is >>>>>>>>>>> magically >>>>>>>>>>>>>>>> unnatural. >>>>>>>>>>>>>>>> Rather, it is that there are a number of current and >>>> evolving >>>>>>>>>>>>>> protocols >>>>>>>>>>>>>>>> that depend upon that /64. The obvious example is that >>>> SLAAC >>>>>>>>> does >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> The rules in this regard are written into approved RFCs.= >>>> If >>>>>>>>>>> homenet >>>>>>>>>>>>>>>> wants to change that, it really needs to go to 6man with= a >>>>>>>>> strong >>>>>>>>>>>>>> case. >>>>>>>>>>>>>>>> (for point-to-point inter-router links this was rece= ntly >>>>>>>>>>> relaxed. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> At the same time, andy operator who insists on giving >>>> homes a >>>>>>>>> /64 >>>>>>>>>>> is >>>>>>>>>>>>>>>> being inappropriately restrictive. Homenet should say >>>> that, >>>>>>>>>>> rather >>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>> Joel, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>>>>>>> responding. >>>>>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 >>>> will >>>>>>>>>>>>>>> so >>>>>>>>>>> IMHO >>>>>>>>>>>>>>> no loss. CGA also won't work but then again I've also ne= ver >>>>>>>>> been a >>>>>>>>>>>>>>> fan of security half measures. Yes anti-spoofing without= >>>> prior >>>>>>>>>>>>>>> exchange of a key is nice, but no reasonable authorizatio= n >>>>>>>>> could be >>>>>>>>>>>>>>> based on CGA without also exchanging some sort of key or >>>> cert >>>>>>>>> and >>>>>>>>>>> at >>>>>>>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If SLAAC and CGA are the only things that break *and* >>>> providers >>>>>>>>> do >>>>>>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes w= ill >>>>>>>>> have >>>>>>>>>>> to >>>>>>>>>>>>>>> be subdivided. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So a question for you is what else if anything will break= ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also understand that you are suggesting that this be >>>> taken to >>>>>>>>>>> 6man. >>>>>>>>>>>>>>> That is a good suggestion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Curtis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>>>>>>> 12. This is sure to be controversial. I pointed o= ut >>>> that >>>>>>>>>>> using >>>>>>>>>>>>>>>>> subnets longer than /64 is OK as long as they = are >>>> not >>>>>>>>>>> leaked >>>>>>>>>>>>>>>>> into global routing. Please read the text and= >>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>> before >>>>>>>>>>>>>>>>> exploding on this topic. It may be necessary = to >>>>>>>>> subnet a >>>>>>>>>>>>>> /64 >>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>> that is all a provider will give you and you n= eed >>>>>>>>> subnets. >>>>>>>>>>>>>> It >>>>>>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>>>>> subnetting a >>>>>>>>>>>>>> class-A >>>>>>>>>>>>>>>>> network would be in 1990. It means using DHCP= v6 >>>> and >>>>>>>>> not >>>>>>>>>>>>>> using >>>>>>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC >>>> implementations >>>>>>>>> would >>>>>>>>>>>>>>>>> likely try to use the whole bottom 64). >>>>>>>>>> _______________________________________________ >>>>>>>>>> homenet mailing list >>>>>>>>>> homenet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms040008020704080408030300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDIxNTUwMjJaMCMGCSqGSIb3DQEJBDEWBBTXDhjAjOqRdK7K6rFevOFoasW/OzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAJgidojEfjQIWnjPN+qBbiOv+Hvo4sA4jFpfObhu5rG7MIRx bUksm/add2wGx8OfURZMtLc4KDvmHUXNLSsdTNHPcQinCBtgvA94Ysx0dGE/ZLyhra+UAR5u gAvikXZka3P5YNqyh3S1Xus3GeMoxQYcuczlD++HR1+0ADVSRGkNx5GigLoEiJXbkneT3cab CgcoqsllEL2dmP49ZzHExQh4Ipadfd1+jvu78sBuHyOHsvKyuFkSiWb998b8W9wBTFQO8vfC l1yfia07abQLcY2723wT/7h6boHkXs5Cupar3j+O7p9QDs8zgIxR9FlI8C1jikwnsVLrecnS wcjderAAAAAAAAA= --------------ms040008020704080408030300-- From curtis@occnc.com Tue Oct 2 13:44:07 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794921F85BB for ; Tue, 2 Oct 2012 13:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=-2.194, BAYES_00=-2.599, MANGLED_HOME=2.3, MANGLED_YOUR=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPq9gn+uOkDC for ; Tue, 2 Oct 2012 13:44:04 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6A621F8594 for ; Tue, 2 Oct 2012 13:44:04 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q92Khvr9068903; Tue, 2 Oct 2012 16:43:57 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210022043.q92Khvr9068903@gateway1.orleans.occnc.com> To: robert.cragie@gridmerge.com From: Curtis Villamizar In-reply-to: Your message of "Tue, 02 Oct 2012 16:50:22 BST." <506B0D3E.80400@gridmerge.com> Date: Tue, 02 Oct 2012 16:43:57 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 20:44:07 -0000 IPv4 Proxy-ARP never scaled well and was highly problematic. RFC4903 is informational and merely records some history. It also recommends that link types mcast, ptp, nbma, be used and specifically states "A multi-link subnet model should be avoided." I don't think MANET and RPL violate the generally accepted definition of subnet. For example, Ethernet bridges do not violate the notion of IP subnet if they run STP or other protocol to learn MAC addresses within the subnet. To IP this is one logical mcast link. MANET is largely experimental (ie: RFC5449, RFC5614, RFC5820, others are experimental). RPL (RFC6550) is more closely analogous to a bridging protocol that operates over a spacific type of subnet. Possibly same with MANET. Both RPL and MANET have requirements that do not apply to the homenet that is running Ethernet and WiFi. If a LOWPAN island running RPL wants to be a single subnet, reachable from the Ethernet and WiFi subnets, that is fine. Some issues may exist if one of the LOWPAN devices is moved out of range or powered off and an RPL island is split into two RPL islands. The use of a single subnet as used in RPL/MANET is specifically discouraged in RFC4903. Curtis In message <506B0D3E.80400@gridmerge.com> Robert Cragie writes: This is a cryptographically signed message in MIME format. --===============5925802905536615095== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040008020704080408030300" This is a cryptographically signed message in MIME format. --------------ms040008020704080408030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Curtis, Comments inline, bracketed by Robert On 01/10/2012 7:11 PM, Curtis Villamizar wrote: > In message > Don Sturek writes: > =20 >> Hi Curtis, >> =20 >> On the topic of "link local on each subnet and a routing protocol work= s >> for any topology....." >> =20 >> In using 6LoWPAN with ROLL (route over), you end up with a mesh networ= k >> where the scope of link local address is only between a single device = in >> the mesh and its one-hop neighbors (not among all devices in the mesh)= =2E >> =20 >> In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communicat= ions >> between all devices in a single mesh subnet. >> =20 >> Don > > Don, > > The "subnet" is meant in IETF terms, not ITU subnetwork. The subnet > is therefore anything link local by definition. Not in the case of RPL or MANETs. This is a multi-link subnet where = routers within the subnet are L3 forwarders (aka "route over"). > A 6LoWPAN node can > get a GUA and use the GUA (or link local address) of a router as a > default route. If the 6LoWPAN device needs only site connectivity > then it can use the link local address for everything. Again, not true in RPL or MANETs. As Don points out, in a RPL/MANET = network, link local means your one-hop neighbors only. > > If a routing protocol is in use and is using link local based host > routes, then a router must fake the DAD collision if a duplicate is > found anywhere within the site. If a multiple ULA are used, one per > subnet, then DAD is only relevant to the subnet. A router should pick > a ULA prefix that is not already in use elsewhere in the site. In the multi-link subnet, typically a single ULA or GUA would be=20 used for the whole subnet including the routers. Multihoming may be=20 necessary depending on external connectivity. > > An extremely low probability race condition exists, but it is a race > condition among routers with multiple routers picking and advertising > the exact same ULA prefix in the routing protocol very nearly > simultaneously (within LAN flooding interval). A wait and backoff can > solve this even though it is a miniscule probability. > > A mesh in IETF terminology is by definition multiple subnets. A > subnet is by definition link local. Again, not according to RPL and MANET protocols. There does seem to = have been some discussion on this which probably needs to be resurrected = (see RFC 4903). > > Curtis > > >> On 9/30/12 3:36 PM, "Curtis Villamizar" wrote: >> =20 >>> In message >>> Don Sturek writes: >>> >>>> Hi Robert, >>>> =20 >>>> One more point touched on in your note below: >>>> 1) Ideally, it would be great if a single authorizatative device >>>> existed >>>> in the home providing DHCPv6 server services (if supported) and pref= ix >>>> delegation. >>>> =20 >>>> One challenge in the description below is having multiple routers on= >>>> multiple subnets, each possibly acting as a DHCPv6 server within the= ir >>>> own >>>> subnet and also providing their own ULA prefix. >>>> =20 >>>> We certainly don't want to further confuse address assignment in a >>>> setting >>>> where IT support does not exist. >>>> =20 >>>> Don >>> >>> We want things to "just work" witb no config. Link local on each >>> subnet and a routing protocol works for any topology. ULA just allow= s >>> summarization of subnets in the routing protocol, such that host >>> routes are not needed (though not a big deal if host routes are used >>> in a homenet). >>> >>> This would "just work" when using link local or ULA. How to subdivid= e >>> a GUA prefix among the subnets is another issue. >>> >>> In principle, though I know of no proposals to do this yet, the set o= f >>> GUA that are available from one of more routers with a provider link >>> could be coordinated via the routing protocol (for example, using a >>> new OSPF Opaque LSA). >>> >>> Curtis >>> >>> >>>> On 9/25/12 1:57 AM, "Robert Cragie" wr= ote: >>>> =20 >>>>> So let's tweak Curtis' sequence slightly: >>>>> >>>>> What every host does is: >>>>> >>>>> if it has no MAC: >>>>> pick a random link local address >>>>> else >>>>> use the MAC to create a link local address >>>>> run DAD to make sure no one else has same address >>>>> >>>>> send a RS >>>>> >>>>> if it gets RA >>>>> use the RA prefix for SLAAC >>>>> else >>>>> time out and don't bother with SLAAC; can only use link local >>>> address >>>>> then hopefully the host also does the following: >>>>> >>>>> send DHCPv6 client request >>>>> >>>>> if response >>>>> it has yet another address to pick from if it got one using SLA= AC >>>>> else >>>>> time out and get nothing from DHCPv6 >>>>> >>>>> This should work fine for legacy APs where everything is bridged >>>>> underneath it. Where it gets interesting is in the case of cascaded= >>>>> subnets behind a router connected to an ISP, where one or more of t= hose >>>>> subnets may be a mesh network comprised of mesh routers and hosts. = I am >>>>> not quite sure how ULAs and DHCPv6 would work in this case as there= are >>>>> limitations as far as I can see (although I accept I probably have = a >>>> bit >>>>> more reading to do on the subject). >>>>> >>>>> Robert >>>>> >>>>> On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >>>>>> In message >>>>>> Don Sturek writes: >>>>>> =20 >>>>>>> Hi Curtis, >>>>>>> =20 >>>>>>> I think the difficulty is each device cannot "use the MAC to crea= te >>>> a >>>>>>> ULA >>>>>>> address". Some authoritative device in the network (eg, the AP) >>>> must >>>>>>> create the ULA prefix. If a ULA prefix is not present because th= e >>>> AP >>>>>>> is a >>>>>>> legacy device not capable of providing a ULA prefix, the STA devi= ces >>>>>>> must >>>>>>> use link locals only. >>>>>>> =20 >>>>>>> Don >>>>>> Don, >>>>>> >>>>>> You are right about there being nothing to generate the ULA prefix= in >>>>>> your example. My mistake. >>>>>> >>>>>> But it doesn't change anything. If the AP is a dumb bridge and th= ere >>>>>> is no router of any kind, then link local addresses are perfectly >>>>>> fine. There is only one subnet in that example, and ULA is not >>>>>> needed. That was the example you gave. >>>>>> >>>>>> Your example had no router just an old AP that acted as a bridge, >>>>>> therefore nothing to generate any sort of RA. If there is a route= r >>>>>> and no GUA prefix (which is not your example, but a useful example= ), >>>>>> then ULA can be used. The only RA that is seen is the RA providin= g a >>>>>> ULA prefix which the router can generate. >>>>>> >>>>>> I did say that the possibility of having to subdivide a /64 only >>>>>> exists for GUA. If a router exists which gets a GUA from a provid= er, >>>>>> and there are more subnets than the prefix length can support the = two >>>>>> options are the ones listed below. (Search for --or--). >>>>>> >>>>>> Curtis >>>>>> >>>>>> >>>>>>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote:= >>>>>>> =20 >>>>>>>> In message >>>>>>>> Don Sturek writes: >>>>>>>> >>>>>>>>> Hi Curtis, >>>>>>>>> =20 >>>>>>>>> I would expect most Wi-Fi AP manufacturers to support the same >>>>>>>>> address >>>>>>>>> assignment they do today (ie, manual assignment and DHCP). I >>>> would >>>>>>>>> also expect as more IPv6 deployments happen that SLAAC will als= o >>>> be >>>>>>>>> supported (and, yes, even for GUA). >>>>>>>>> =20 >>>>>>>>> For the types of devices which will be added to Wi-Fi networks = in >>>> the >>>>>>>>> future (eg, headless devices like appliances, thermostats, etc.= ) >>>> that >>>>>>>>> the preferred address assignment will be SLAAC and DHCPv6 (and,= >>>> yes, >>>>>>>>> I >>>>>>>>> purposely did not remove SLAAC.....) >>>>>>>>> =20 >>>>>>>>> Don >>>>>>>> Don, >>>>>>>> >>>>>>>> We seem to be talking past each other so let me again try to be >>>> clear. >>>>>>>> What every host does is: >>>>>>>> >>>>>>>> if it has no MAC: >>>>>>>> pick a random link local (not ULA) address >>>>>>>> else >>>>>>>> use the MAC to create a ULA address >>>>>>>> run DAD to make sure no one else has same address >>>>>>>> >>>>>>>> send a RS >>>>>>>> >>>>>>>> if it gets RA >>>>>>>> use the RA prefix for SLAAC >>>>>>>> else >>>>>>>> time out and don't bother with SLAAC >>>>>>>> >>>>>>>> then hopefully the host also does the following: >>>>>>>> >>>>>>>> send DHCPv6 client request >>>>>>>> >>>>>>>> if response >>>>>>>> it has yet another address to pick from if it got one using= >>>> SLAAC >>>>>>>> else >>>>>>>> time out and get nothing from DHCPv6 >>>>>>>> >>>>>>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 ser= ver >>>>>>>> the address that it already has (from SLAAC). >>>>>>>> >>>>>>>> If as in the case of your Wi-Fi with a bridging AP example, ther= e >>>> is >>>>>>>> no router to give it an DHCPv6 the link local or ULA addresses a= re >>>>>>>> still there and still usable. There is also no router to give i= t >>>> an >>>>>>>> RA response so it has no SLAAC assigned address and no DHCPv6 >>>> assigned >>>>>>>> address. >>>>>>>> >>>>>>>> That is the end of your example. >>>>>>>> >>>>>>>> If there is a router then there is something that can hand out a= >>>> RA or >>>>>>>> DHCPv6 response. >>>>>>>> >>>>>>>> In the case were there exists multiple subnets and the CER has b= een >>>>>>>> granted a /64 (or too few /64s to handle the number of subnets),= >>>> then: >>>>>>>> it can use RA with /64 on some subnets and give them GUA >>>> addresses >>>>>>>> and some subnets have no access outside the homenet >>>>>>>> >>>>>>>> --or-- >>>>>>>> >>>>>>>> it can not use RA (and therefore prevent SLAAC from being use= d) >>>> and >>>>>>>> hand out DHCPv6 addresses and make use of prefixes longer tha= n >>>> /64. >>>>>>>> This prevents the use of CGA but get connectivity to the enti= re >>>>>>>> homenet. >>>>>>>> >>>>>>>> If every consumer oriented provider is willing to allocate prefi= xes >>>>>>>> shorter than /64 on request to home users, then the above situat= ion >>>>>>>> never occurs. If it does, my argument is that the second option= >>>> above >>>>>>>> is better than the first. >>>>>>>> >>>>>>>> Curtis >>>>>>>> >>>>>>>> >>>>>>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrot= e: >>>>>>>>> =20 >>>>>>>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>>>>>>> Jim Gettys writes: >>>>>>>>>> >>>>>>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>> >>>>>>>>>>>> Here is the use case: >>>>>>>>>>>> 1) Customer has a legacy AP in their house >>>>>>>>>>>> 2) Customer brings home new devices supporting IPv6 (which = are >>>>>>>>>>> designed >>>>>>>>>>>> to communicate only with other IPv6 based devices in the hom= e) >>>>>>>>>>>> 3) The only way these new devices can communicate is throug= h >>>>>>>>> address >>>>>>>>>>>> assignment using SLAAC and then some discovery method the tw= o >>>> new >>>>>>>>>>> devices >>>>>>>>>>>> support (without support from the AP). Here these devices a= re >>>>>>>>>>> assuming >>>>>>>>>>>> bridging through the AP...... >>>>>>>>>>> =20 >>>>>>>>>>> And since current legacy AP's all bridge, we win (even though= we >>>>>>>>> need to >>>>>>>>>>> route in the future). >>>>>>>>>> Jim, >>>>>>>>>> >>>>>>>>>> The point was how do you get local IPv6 within the home with t= he >>>>>>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. >>>> First >>>>>>>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>>>>>>> >>>>>>>>>> In this case you use link local or if everything has a MAC you= >>>> can >>>>>>>>>> use >>>>>>>>>> ULA based on the MAC addressses. >>>>>>>>>> >>>>>>>>>>>> Placing a requirement that every customer who buys a new IPv= 6 >>>>>>>>> device, >>>>>>>>>>>> intended to communicate only with other IPv6 devices in the >>>> home, >>>>>>>>> will >>>>>>>>>>>> require a forklift upgrade of a deployed network in order to= >>>> work >>>>>>>>>>> will not >>>>>>>>>>>> be popular. >>>>>>>>>>> =20 >>>>>>>>>>> Good point. >>>>>>>>>> But invalid. The use case Don gave would still work fine. On= ly >>>> GUA >>>>>>>>>> addresses are affected. >>>>>>>>>> >>>>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, >>>> anyway* >>>>>>>>>>> in >>>>>>>>>>> the home environment. >>>>>>>>>>> =20 >>>>>>>>>>> The loathing comes from the exquisite pain of suffering with = a >>>>>>>>>>> flaky >>>>>>>>>>> home network for several months, before realising I had a ro= gue >>>>>>>>>>> DHCP >>>>>>>>>>> server somewhere on my network (from wireshark). I then had = to >>>>>>>>>>> take >>>>>>>>> the >>>>>>>>>>> mac address, figure out who may have manufactured some device= >>>> from >>>>>>>>> that >>>>>>>>>>> information, and finally figured out the little VOIP ATA >>>> adaptor I >>>>>>>>> had >>>>>>>>>>> been given liked to do DHCP. >>>>>>>>>> It did DHCP on the *WAN side*? You didn't put the rest of you= r >>>>>>>>>> network behind the VOIP box on the LAN side I hope. >>>>>>>>>> >>>>>>>>>>> This was by far the hardest debugging I've had to do in my ho= me >>>>>>>>> network >>>>>>>>>>> in normal operation. >>>>>>>>>>> =20 >>>>>>>>>>> This is well beyond normal home debugging capability of >>>> consumers. >>>>>>>>>>> - Jim >>>>>>>>>> We all have plenty of crappy IPv4 product horror stories. My >>>> VOIP >>>>>>>>>> phone locked up now and then and I figured out that if the cal= l >>>>>>>>>> lasted >>>>>>>>>> longer than the DHCPv4 lease, then it lost the least because i= t >>>>>>>>>> didn't >>>>>>>>>> try to renew it. Not only did the call drop, but the device >>>> locked >>>>>>>>>> up. The first solution was to reboot it now and then. The >>>> answer >>>>>>>>>> was >>>>>>>>>> to configure a fixed address. I was lucky to figure it out >>>> before >>>>>>>>>> my >>>>>>>>>> wife threw the phone through a window. For all I know a later= >>>>>>>>>> firmware upgrade might have fixed it. VOIP might be more >>>> popular if >>>>>>>>>> VOIP phones under $600 worked reasonably well. >>>>>>>>>> >>>>>>>>>> Both nice stories, but both are DHCPv4 related and have nothin= g >>>> at >>>>>>>>>> all >>>>>>>>>> to do with SLAAC. >>>>>>>>>> >>>>>>>>>> Curtis >>>>>>>>>> >>>>>>>>>>>> Don >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" >>>> wrote: >>>>>>>>>>>>> In message >>>>>>>>>>>>> Don Sturek writes: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Don >>>>>>>>>>>>> Don, >>>>>>>>>>>>> >>>>>>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>>>>> concerned. >>>>>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joe= l >>>>>>>>> brought >>>>>>>>>>>>> up ILNP in private email, but I beleive ILNP can also work = as >>>> the >>>>>>>>>>>>> constraints in ILNP are in the ILNP identifier which is not= >>>> the >>>>>>>>> same >>>>>>>>>>>>> as the interface address in ILNP for which there is no >>>>>>>>>>>>> constraint. >>>>>>>>>>>>> >>>>>>>>>>>>> I have subnets running fine using a few /112 allocated from= >>>>>>>>> within a >>>>>>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops a= nd >>>>>>>>> DHCPv6 >>>>>>>>>>>>> for dynamic allocations for laptops. It works fine. Link >>>> local >>>>>>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No= >>>> host >>>>>>>>> ever >>>>>>>>>>>>> receives a RA since my routers won't give them one, so no h= ost >>>>>>>>> ever >>>>>>>>>>>>> tries to generate an address using SLAAC. The only >>>> constraint is >>>>>>>>>>> that >>>>>>>>>>>>> any host connecting to my Ethernet or wireless must run a D= HCP >>>>>>>>> client >>>>>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHC= Pv4 >>>>>>>>>>>>> and >>>>>>>>>>>>> DHCPv6 servers are available in every subnet except one GbE= >>>>>>>>> subnet in >>>>>>>>>>>>> the rack and to a few hosts in my home office. >>>>>>>>>>>>> >>>>>>>>>>>>> So as far as I am concerned we have an assertion that no >>>> SLAAC is >>>>>>>>> a >>>>>>>>>>>>> problem and existance proof that it is not. Beside CGA and= >>>>>>>>> requiring >>>>>>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I = not >>>>>>>>>>> support >>>>>>>>>>>>> on these /112 subnets? >>>>>>>>>>>>> >>>>>>>>>>>>> Curtis >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> The argument on /64 as the longest prefix is not that it= is >>>>>>>>>>> magically >>>>>>>>>>>>>>>> unnatural. >>>>>>>>>>>>>>>> Rather, it is that there are a number of current and >>>> evolving >>>>>>>>>>>>>> protocols >>>>>>>>>>>>>>>> that depend upon that /64. The obvious example is that >>>> SLAAC >>>>>>>>> does >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> The rules in this regard are written into approved RFCs.= >>>> If >>>>>>>>>>> homenet >>>>>>>>>>>>>>>> wants to change that, it really needs to go to 6man with= a >>>>>>>>> strong >>>>>>>>>>>>>> case. >>>>>>>>>>>>>>>> (for point-to-point inter-router links this was rece= ntly >>>>>>>>>>> relaxed. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> At the same time, andy operator who insists on giving >>>> homes a >>>>>>>>> /64 >>>>>>>>>>> is >>>>>>>>>>>>>>>> being inappropriately restrictive. Homenet should say >>>> that, >>>>>>>>>>> rather >>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>> Joel, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>>>>>>> responding. >>>>>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 >>>> will >>>>>>>>>>>>>>> so >>>>>>>>>>> IMHO >>>>>>>>>>>>>>> no loss. CGA also won't work but then again I've also ne= ver >>>>>>>>> been a >>>>>>>>>>>>>>> fan of security half measures. Yes anti-spoofing without= >>>> prior >>>>>>>>>>>>>>> exchange of a key is nice, but no reasonable authorizatio= n >>>>>>>>> could be >>>>>>>>>>>>>>> based on CGA without also exchanging some sort of key or >>>> cert >>>>>>>>> and >>>>>>>>>>> at >>>>>>>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If SLAAC and CGA are the only things that break *and* >>>> providers >>>>>>>>> do >>>>>>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes w= ill >>>>>>>>> have >>>>>>>>>>> to >>>>>>>>>>>>>>> be subdivided. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So a question for you is what else if anything will break= ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also understand that you are suggesting that this be >>>> taken to >>>>>>>>>>> 6man. >>>>>>>>>>>>>>> That is a good suggestion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Curtis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>>>>>>> 12. This is sure to be controversial. I pointed o= ut >>>> that >>>>>>>>>>> using >>>>>>>>>>>>>>>>> subnets longer than /64 is OK as long as they = are >>>> not >>>>>>>>>>> leaked >>>>>>>>>>>>>>>>> into global routing. Please read the text and= >>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>> before >>>>>>>>>>>>>>>>> exploding on this topic. It may be necessary = to >>>>>>>>> subnet a >>>>>>>>>>>>>> /64 >>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>> that is all a provider will give you and you n= eed >>>>>>>>> subnets. >>>>>>>>>>>>>> It >>>>>>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>>>>> subnetting a >>>>>>>>>>>>>> class-A >>>>>>>>>>>>>>>>> network would be in 1990. It means using DHCP= v6 >>>> and >>>>>>>>> not >>>>>>>>>>>>>> using >>>>>>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC >>>> implementations >>>>>>>>> would >>>>>>>>>>>>>>>>> likely try to use the whole bottom 64). >>>>>>>>>> _______________________________________________ >>>>>>>>>> homenet mailing list >>>>>>>>>> homenet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms040008020704080408030300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDIxNTUwMjJaMCMGCSqGSIb3DQEJBDEWBBTXDhjAjOqRdK7K6rFevOFoasW/OzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAJgidojEfjQIWnjPN+qBbiOv+Hvo4sA4jFpfObhu5rG7MIRx bUksm/add2wGx8OfURZMtLc4KDvmHUXNLSsdTNHPcQinCBtgvA94Ysx0dGE/ZLyhra+UAR5u gAvikXZka3P5YNqyh3S1Xus3GeMoxQYcuczlD++HR1+0ADVSRGkNx5GigLoEiJXbkneT3cab CgcoqsllEL2dmP49ZzHExQh4Ipadfd1+jvu78sBuHyOHsvKyuFkSiWb998b8W9wBTFQO8vfC l1yfia07abQLcY2723wT/7h6boHkXs5Cupar3j+O7p9QDs8zgIxR9FlI8C1jikwnsVLrecnS wcjderAAAAAAAAA= --------------ms040008020704080408030300-- --===============5925802905536615095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --===============5925802905536615095==-- From curtis@occnc.com Tue Oct 2 14:54:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F4F21F8615 for ; Tue, 2 Oct 2012 14:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=-1.423, BAYES_50=0.001, J_CHICKENPOX_31=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32nUJEFbrS1L for ; Tue, 2 Oct 2012 14:54:23 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id EBD6421F8528 for ; Tue, 2 Oct 2012 14:54:22 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q92LsG1P069291; Tue, 2 Oct 2012 17:54:17 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210022154.q92LsG1P069291@gateway1.orleans.occnc.com> To: homenet@ietf.org From: Curtis Villamizar Date: Tue, 02 Oct 2012 17:54:16 -0400 Cc: curtis@occnc.com Subject: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 21:54:26 -0000 Now that we beat summary item #12 to death, can we please turn our attention to the remaining 18 summary items listed below and the diffs to the draft? btw- I think the concensus on summary item #12 is that maybe we can add the following points to the framework. Subnets longer than /64 are bad. Some devices don't support DHCPv6, therefore SLAAC is essential. Consumer oriented service providers of must allow customers to easily request and get prefixes shorter than /64 and preferably at no additional cost if we are to avoid having to subdivide /64s. Curtis ------- Forwarded Message Message-Id: <201209230330.q8N3Uix6047290@gateway1.orleans.occnc.com> To: homenet@ietf.org cc: curtis@occnc.com Reply-To: curtis@occnc.com Subject: draft-ietf-homenet-arch-04 From: Curtis Villamizar Date: Sat, 22 Sep 2012 23:30:44 -0400 Tim, Jari, Anders, Ole, Jason, I hope this is an OK time for comments on this draft. I just spent some time going through draft-ietf-homenet-arch-04 and I also took the time to look through all the RFCs and drafts that it references, even most of the expired ones. I edited in some diffs to the xml2rfc source. Most of the diffs should be self explanitory, though I'm sure some will not be without controversy on the WG list. I left in some XML comments where either I wanted to explain a change, or I would like to see some discussion on list. The xml file is at http://www.ietf.org/id/draft-ietf-homenet-arch-04.xml The diffs are below. Hopefully we can all read unified diffs of an xml file. I'll also summarize some major points here. 1. Must be capable of self configuring but should allow manual config. 2. A few citations could stand to be removed. Some drafts are expired and don't look like they were entirely completed. Some of the expired drafts look good but just managed to expire. 3. I am proposing that we drop the "well known name" as a means to discover the border(s). This seems to me like a real bad idea. 4. In "Global addressability and elimination of NAT" (false-)security concerns about losing NAT are cited but no advantage to global addressability is cited. I think that is an oversight but didn't add text here. (yet) 5. In a few places I've pointed out that firewalls (and NAT and anti-virus) provide very ineffective security and we should be very up front about saying so, though we can acknowledge that in the absense of reasonably secure home products, we can't get rid of them just yet. 6. Proposals for IPv6-only MUST provide some accommodations for legacy IPv4 only hosts or plain vanilla DS hosts. I called this IPv4 fallback on an otherwise IPv6 only network. I split the bullet on NAT64/DNS64 into two. a. As I had pointed out on the list, doing DNS64 at the CE (or a router) will break any IPv4 only host. The DNS64 translation should be done at the host. The NAT64 can be done at the CE (or any willing router). b. The DS-Lite B4 can be done on the host as long as DHCPv6 tells the host that an AFTR is availalbe. If the CE gets the FQDN of an AFTR as a DHCPv6 client on the WAN side it can pass that along to hosts as a server on the DHCPv6 homenet side. The DS-Lite B4 capable host can tunnel to the AFTR and not make a DHCPv4 request (operate v6only). The plain DS and IPv4-only hosts can make DHCPv4 requests. If V4 packets arrive at the CE, the CE can act as a B4 if the provider gave a AFTR FQDN in the WAN side DHCPv6. 7. If some topology can casue things to be broken, then what the homenet WG specified is broken. Added some text on pathelogical cases. The only true pathological case is a loop in a set of repeaters if a routing protocol is used and switches either detect cycles or use IEEE spanning tree or link state protocols. 8. Cascading NATs are common. Added text as to why. 9. Questioned why we mention VLANs. An unsophisticated home user is not likely to be playing with VLANs. 10. Should we get rid of physical standard references? I think so. 11. Modified "bridge whenever possible" text. Also "Largest possible subnets" section title changed to "Largest practical subnets" for reasons given in comments. 12. This is sure to be controversial. I pointed out that using subnets longer than /64 is OK as long as they are not leaked into global routing. Please read the text and changes before exploding on this topic. It may be necessary to subnet a /64 if that is all a provider will give you and you need subnets. It does work and it is no more unnatural than subnetting a class-A network would be in 1990. It means using DHCPv6 and not using RA prefixes for GUA (otherwise SLAAC implementations would likely try to use the whole bottom 64). 13. There are a few minor wording changes, minor clarifications, etc. 14. There may be more fuss about confining interior routing within a border than needed. I added a paragraph that might help (or might not). 15. In the security section I added a subsection named "Marginal Effectiveness of NAT and Firewalls". (btw- Firewall horror story at bar BOF on request.) 16. Added "It has been suggested that Dynamic DNS could be made to operate in a zero-configuration mode using a locally significant root domain and with minimal configuration or using a DHCPv6 based (details to-be-defined) means of automated delegation populate a global DNS zone." Maybe a draft is needed on this but for now please discuss on list. 17. Suggest that any mechanism that is subnet-only has to be extended to site *or abandoned by the WG* rather than proxied. Old text said extended but not proxied (sic). 18. Updated references (one draft is now RFC, one individual draft is now WG draft, noted those that are expired). 19. Question on "ISPs renumber due to privacy laws". What's that all about? Curtis BTW- The file still compiles and I made some updates to the references section which means the entity defines up front are edited. I'm quite sure you'll want to pick and choose diffs or hand edit the changes you want back in. Hopefully you'll want something. :) - --- draft-ietf-homenet-arch-04.xml.orig 2012-07-16 10:00:38.000000000 -0400 +++ draft-ietf-homenet-arch-04.xml 2012-09-22 22:06:24.000000000 -0400 @@ -4,13 +4,17 @@ + + + + @@ -52,8 +56,8 @@ - - + @@ -202,8 +206,9 @@ which case such networks may use increasing numbers of subnets, and require methods for IPv6 prefixes to be delegated to those subnets. The assumption of this document is that the - -homenet is as far as possible self-organising and self-configuring, - -and is thus not pro-actively managed by the residential user. +homenet is as far as possible +capable of self-organising and self-configuring, +and is thus need not be pro-actively managed by the residential user. The @@ -258,6 +263,9 @@ "Advanced Security". Describes advanced security functions for a CER, as defined in , where the default inbound connection policy is generally "default allow". + CER: Customer Edge Router. A border router at the edge of the homenet. LLN: Low-power and lossy network. NAT: Network Address Translation. Typically referring to IPv4 @@ -283,10 +291,9 @@
- -Service providers are deploying IPv6, content is becoming available on - -IPv6 (accelerated recently by the World IPv6 Launch event) - -and support for IPv6 is increasingly available in devices and - -software used in the home. While + +While IPv6 resembles IPv4 in many ways, it changes address allocation principles, making multi-addressing the norm, and allowing direct IP addressability of home networking @@ -323,9 +330,14 @@ Documents that provide some more specific background and depth on this topic include: - -, - -, and - -. +, +, and +. + + The addition of routing between subnets raises the issue of how to extend mechanisms such as service discovery which currently rely @@ -340,6 +352,10 @@ Here, there are a number of choices. These include an appropriate service discovery protocol, or the use of a well-known name, resolved by some local name service. + Both might have to deal with handling more than one router responding in multihomed environments. @@ -357,6 +373,9 @@ allowing every device on every link to be assigned a globally unique IPv6 address. + The end-to-end communication that is potentially enabled with IPv6 is on the one hand an incredible @@ -373,6 +392,12 @@ would only be used on private networks or the device itself doesn't have the computing power to apply the necessary security methods. + IPv6 networks may or may not have filters applied at their borders, i.e. at the homenet CER. @@ -498,11 +523,33 @@ should be considered in IPv6-only environments: - -Ensuring there is a way to access content in the IPv4 Internet. This can +Ensuring there is a way to access content in the IPv4 Internet. + + +This can be arranged through incorporating NAT64 and DNS64 functionality in the home gateway router, for instance. Such features - -are outside the scope of this document however, being CER functions. +are outside the scope of this document however, being CER functions. +Legacy IPv4-only hosts could not function in a network for which the +DNS server implements DNS64. Therefore a DNS64 NS may need to disable +DNS64 translation for DNS queries arriving via IPv4 transport. +This can also be arranged through use of +DS-Lite, with the DS-Lite +B4 implemented in the host and the DS-Lite AFTR implemented in the +CPE, or the AFTR FQDN passed from the CPE to the host if AFTR is +offerred by the service provider. + + + + DNS discovery mechanisms are enabled for IPv6. Both stateless DHCPv6 +It is desirable for mechanisms which enable IPv6-only host +operation, to also support IPv4 as a fallback for legacy devices and +support DHCPv4 for legacy IPv4 only hosts and for IPv6 DS devices +which fail to operate without IPv4 and DHCPv4. + @@ -551,7 +604,8 @@ expect the resulting network to operate. Significant manual configuration is rarely, if at all, possible, given the knowledge level of typical home users. Thus the network should, - -as far as possible, be self-configuring. +as far as possible, be self-configuring. For the benefit of the +atypical more advanced user, manual configuration should be supported. The equipment also needs @@ -623,6 +677,17 @@ infrastructure to allow the rest to operate. In such cases, the user should ideally have some useful indication of the failure mode encountered. +There are no topology secenarios which could cause loss of +connectivity, except when the user +creates a physical island within the topology. Some potentially +pathological cases that can be created include bridging ports of a +router together, however this case can be detected and dealt with by +the router. Routing cycles within a topology are in a sense good in +that they offer redundancy. Bridging cyslces can be dangerous but are +also detectable when a switch learns the MAC of one of its interfaces +on another or runs a spanning tree or link state protocol. It is only +cycles using simple repeaters that are truly pathological. +
@@ -636,6 +701,14 @@ and private networks. +Cascading NATs are somewhat common in IPv4 home networks. Many +devices such as SIP devices and some streaming video devices have a +WAN side and LAN side Ethernet port and in their installation +instructions either recommend or insist on being the device closest to +the WAN for QoS reasons. A user may comply and string these together +resulting in two or three or potentially more cascaded IPv4 NAT. + + In general, the models described in and its successor RFC 6204-bis @@ -656,6 +729,9 @@ subnets, with no direct connectivity between them within the homenet. Isolation may be physical, or implemented via IEEE 802.1q VLANs. + Demarcation of the CER. The CER(s) may or may not be managed by the ISP. If the demarcation point is such that the customer can provide or manage the CER, its configuration must be simple. Both @@ -688,6 +764,23 @@ A separate discussion of physical infrastructures for homenets is included in and . + + In the following sections we give some examples of the types of @@ -707,7 +800,8 @@ topology itself may also be complex, and it may not be possible to assume a pure tree form, for instance (home users may plug routers together to form arbitrary topologies - -including loops). +including cycles. +
@@ -863,7 +957,9 @@ A general recommendation is to follow the same topology for IPv6 as is used for IPv4, but not to use NAT. Thus there should be routed IPv6 where an IPv4 NAT is used, and where there is no NAT - -there should be bridging if the link layer allows this. +routing or bridging may be used. Routing may have advantages over +bridging together high speed and lower speed shared media and bridging +may not be suitable for some media, such as ad-hoc mobile networks. In some cases IPv4 NAT @@ -925,12 +1021,14 @@ typically include . Applications may of course do different things, and this should not be precluded. + For the single CER Network Model C, multihoming may be offered by source routing at the CER. With multiple exit routers, the complexity rises. Given a packet with a source address on the network, the - -packet must be routed to the proper egress to avoid BCP 38 +packet must be routed to the proper egress to avoid BCP 38 +() filtering at an ISP that did not delegate the prefix the address is chosen from. While the packet might not take an optimal path to the correct exit CER, the @@ -939,11 +1037,12 @@ that the packet is routed in the most efficient manner to the correct exit. + There are various potential approaches to this problem, one example being described in - -. +. Another is discussed in , which explores support for source routing throughout the homenet. This approach would however likely require relatively significant @@ -951,6 +1050,8 @@ given the source address. Such changes should preferably be minimised. + There are some other multihoming considerations for homenet scenarios. First, it may be the case that @@ -967,6 +1068,7 @@ While we should not specifically target walled garden multihoming as a principal goal, it should not be precluded. + Host-based methods such @@ -1049,7 +1151,7 @@
- -
+
Today's IPv4 home networks generally have a single subnet, and early dual-stack deployments have a single congruent IPv6 subnet, @@ -1063,9 +1165,11 @@ routers and thus need multiple subnets, for the reasons described earlier. As part of the self-organisation of the network, the homenet should subdivide - -itself to the largest possible subnets that can be constructed within +itself to the largest practical subnets that can be constructed within the constraints of link layer mechanisms, bridging, physical - -connectivity, and policy. +connectivity, policy, and where applicable performance or other +criteria. For example, bridging a busy GbE subnet and a wireless +subnet together may impact wireless performance. While it may be desirable to maximise the chance of link-local @@ -1073,6 +1177,15 @@ multi-subnet home networks are inevitable, so their support must be included. +
@@ -1109,6 +1222,31 @@ homenet will need to adapt to the prefixes made available to it through the prefix delegation method used by its upstream ISP. + +It is important to note that for the purpose of a homenet, a /64 +prefix is subdividable. specifically states +"Subnet numbers must be assumed to come from the network part. This +is not to preclude routing protocols such as IS-IS level 1 +(intra-area) routing, which routes individual host addresses, but says +that it may not be depended upon in the world outside that zone." +Prefixes longer than /64 are not globally routable but may be used by +protocols such as IS-IS or OSPF to subdivide a /64. Subdividing a /64 +effectively requires a managed address space, disallowing allocation +within that /64 though SLAAC and disallowing +any technique which requires the use of the full lower 64 bits such as +CGA . + + + +If faced with allocation of a /64 prefix, or a prefix that is too +short to support a /64 for each subnet it may be necessary to +subdivide one or more /64. This need may arise if some providers +refuse to allocate anything but a /64 to home users, small office +users, or very small businesses. The need to get the network running +may have to be weighed against other needs such as CGA. + +
@@ -1123,7 +1261,8 @@ and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be - -severely constrained, or even unable to function. +severely constrained, or even unable to function if the /64 cannot be +subdivided due to conflicting requirements (such as CGA). The internal operation of the home network should also not depend on @@ -1142,6 +1281,12 @@ their prefix pool) changing. It is not expected that ISPs will support Provider Independent (PI) addressing for general residential homenets. + When an ISP needs to restructure and in doing so renumber its customer homenets, "flash" renumbering is likely to be imposed. This implies a need @@ -1154,6 +1299,8 @@ is an extended version of an initial numbering process, the difference between flash renumbering and an initial "cold start" is the need to provide service continuity. +The depricated addresses would remain usable within the homenet as +described in . There may be cases where local law means some ISPs are required to change @@ -1177,6 +1324,11 @@ The introduction of any new homenet protocols should not make any form of renumbering any more complex than it already is. +
@@ -1213,6 +1365,30 @@ scope through filtering at the border(s) of the homenet, as described in RFC 6092. + +If a routing protocol (or static routing) is not used, then ULA or GUA +connectivity across subnets cannot occur. ULA connectivity requires +that host routes (IPv6 /128 routes) be used. In a very large network +this would pose a scaling issue. Homenets should be sufficiently +small that scalability is not at all an issue, even is the absence of +the route aggregation afforded by GUA subnet routes. An interior +routing protocol adjacency (IS-IS or OSPF) should not be attempted by +default on a provider interface, and will generally require a shared +secret with the provider, implying a need for configuration. If such +an adjacency is configured, route summarization of GUA routes is +required and no ULA routes should be advertised to the provider. Any +sensible provider will provide route filters on their end. More +likely no routing protocol adjacency will exist between the homenet CE +and the provider. For medium sized businesses (not a homenet) a BGP +adjacency might be used, but still no OSPF or IS-IS adjacency. +Similarly the provider would pay no attention to distance vector +routing protocol information erroneously sent from the homenet. The +homenet interior routing information would therefore always be +confined to the homenet. + +
@@ -1230,7 +1406,8 @@ . Then each subnet in the homenet should receive a prefix from within the ISP-provided prefix(es). The ISP should only see the aggregate from - -the homenet, and not single /64 prefixes allocated within the homenet. +the homenet, and not single /64 (or longer) prefixes allocated within +the homenet. Delegation should be autonomous, and not assume a flat or @@ -1281,14 +1458,18 @@ Several proposals have been made for prefix delegation within a homenet. One group of proposals is based on DHCPv6 PD, as described in - -, - -, +, +, and . The other uses OSPFv3, as described in . More detailed analysis of these approaches needs to be made against the requirements/principles described above. +
@@ -1385,6 +1566,8 @@ evaluations of common routing protocols made against the type of requirements described above. +
@@ -1406,10 +1589,41 @@ to be able to operate securely, end-to-end where required, but also be robust against malicious traffic direct towards them. We simply note at - -this point that software on home devices will have an increase in +this point that software on home devices may have an increase in security if it allows its software to be updated regularly. +
+ +Security by way of obscurity (address translation) or through +firewalls (filtering) is at best marginally effective. The very poor +security track record of home computer, home networking and business +PC computers and networking is testomony to its ineffectiveness. A +compromise behind the firewall of any device exposes all others, +making an entire network that relies on obscurity or a firewall as +vulnerable as the most insecure device on the private side of the +network. + + +However, given home network products with very poor security, putting +a firewall in place does provide some protection, even if only +marginally effective. IPv6 global reachability may increase the need +to solve the underlying problem of certain insecure home and business +computer and network products. The use of firewalls today, whether a +good practice or not, is common practice and whatever protection +afforded, even if marginally effective, must not be lost. + + +
+
An IPv6-based home network architecture should embrace @@ -1465,6 +1679,8 @@ to be configured on a CER. Such methods should be able to be automatically updating. +
@@ -1577,7 +1793,11 @@ There are naming protocols that are designed to be configured and operate Internet-wide, like unicast-based DNS, but also protocols that are designed for zero-configuration local environments, like - -mDNS. Consideration should be made for how these interact with each +mDNS. It has been suggested that Dynamic DNS could be made to operate +in a zero-configuration mode using a locally significant root domain +and with minimal configuration or using a DHCPv6 based (details +to-be-defined) means of automated delegation populate a global DNS +zone. Consideration should be made for how these interact with each other in a homenet scenario. @@ -1634,6 +1854,8 @@ to multicast service discovery requests. Those same parts of the network may have less capacity for multicast traffic that may be flooded from other parts of the network. + In general, message utilisation should be efficient considering the network technologies the service may need to operate over. @@ -1650,7 +1872,7 @@ Current service discovery protocols are generally aimed at single - -subnets. If service discovery is to operate across the an entire +subnets. If service discovery is to operate across an entire homenet, by adopting an approach like that proposed as Extended mDNS (xmDNS) , then support may be required for IPv6 multicast across the scope of the @@ -1682,12 +1904,14 @@ The homenet architecture proposes that any existing protocols that are designed to only work within a subnet should be extended - -to work across subnets, rather than defining proxy capabilities +to work across subnets or not used by homenet, +rather than defining proxy capabilities for each of those functions. However, while it is desirable to extend protocols to site scope operation rather than providing proxy functions on subnet boundaries, the reality is that until all hosts can use site-scope discovery protocols, - -existing link-local protocols would need to be proxied anyway. +existing link-local protocols would need to be proxied anyway or other +solutions found which are not link local in scope. Some protocols already have proxy functions defined and in use, e.g. DHCPv6 relays, in which case those protocols would be expected to @@ -1812,10 +2036,14 @@ &rfc1918; + &rfc2462; &rfc2475; &rfc2775; + &rfc2827; &rfc3022; + &rfc3177; &rfc3646; + &rfc3972; &rfc4192; &rfc5533; &rfc5969; @@ -1826,22 +2054,26 @@ &rfc6296; &rfc6333; &rfc6555; - - &I-D.baker-fun-multi-router; - - &I-D.lynn-homenet-site-mdns; - - &I-D.townsley-troan-ipv6-ce-transitioning; - - &I-D.baker-fun-routing-class; - - &I-D.howard-homenet-routing-comparison; - - &I-D.herbst-v6ops-cpeenhancements; - - &I-D.vyncke-advanced-ipv6-security; - - &I-D.ietf-6man-rfc3484bis; - - &I-D.v6ops-multihoming-without-ipv6nat; - - &I-D.baker-homenet-prefix-assignment; + &I-D.baker-fun-multi-router; + &I-D.lynn-homenet-site-mdns; + &I-D.townsley-troan-ipv6-ce-transitioning; + &I-D.baker-fun-routing-class; + &I-D.howard-homenet-routing-comparison; + &I-D.herbst-v6ops-cpeenhancements; + &I-D.vyncke-advanced-ipv6-security; + &I-D.ietf-6man-rfc3484bis; + &I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat; + &I-D.baker-homenet-prefix-assignment; &I-D.arkko-homenet-prefix-assignment; &I-D.acee-ospf-ospfv3-autoconfig; - - &I-D.ietf-pcp-base; - - &I-D.hain-ipv6-ulac; - - &I-D.chakrabarti-homenet-prefix-alloc; - - &I-D.arkko-homenet-physical-standard; + &I-D.ietf-pcp-base; + &I-D.hain-ipv6-ulac; + &I-D.chakrabarti-homenet-prefix-alloc; + &I-D.arkko-homenet-physical-standard; + + @@ -1953,7 +2185,7 @@ Clarified simple and advanced security some more, and RFC 4864 and 6092. Stated that there should be just one secret key, if any are used at all. For multihoming, support multiple CERs but note that routing to the correct CER to avoid ISP filtering may not be optimal within the homenet. - -Added some ISPs renumber due to privacy laws. +Added some ISPs renumber due to privacy laws. Removed extra repeated references to Simple Security. Removed some solution creep on RIOs/RAs. Load-balancing scenario added as to be supported. ------- End of Forwarded Message From v6ops@globis.net Wed Oct 3 00:18:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44A21F86B5 for ; Wed, 3 Oct 2012 00:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.731 X-Spam-Level: X-Spam-Status: No, score=0.731 tagged_above=-999 required=5 tests=[AWL=-3.084, BAYES_40=-0.185, J_BACKHAIR_35=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_74=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 Vvtj-K3tmrr5 for ; Wed, 3 Oct 2012 00:18:52 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C956421F84E6 for ; Wed, 3 Oct 2012 00:18:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AB22287011E; Wed, 3 Oct 2012 09:18:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIldPtR36L41; Wed, 3 Oct 2012 09:18:12 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 679BC8700ED; Wed, 3 Oct 2012 09:18:12 +0200 (CEST) Message-ID: <506BE6AE.5070708@globis.net> Date: Wed, 03 Oct 2012 09:18:06 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: curtis@occnc.com References: <201210022154.q92LsG1P069291@gateway1.orleans.occnc.com> In-Reply-To: <201210022154.q92LsG1P069291@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 07:18:55 -0000 Why not just add RFC 6177 BCP 157 http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in draft-ietf-homenet-arch? That's a lot shorter than re-hashing the whole discussion within Homenet. Curtis Villamizar wrote: > Now that we beat summary item #12 to death, can we please turn our > attention to the remaining 18 summary items listed below and the diffs > to the draft? > > btw- I think the concensus on summary item #12 is that maybe we can > add the following points to the framework. Subnets longer than /64 > are bad. Some devices don't support DHCPv6, therefore SLAAC is > essential. Consumer oriented service providers of must allow > customers to easily request and get prefixes shorter than /64 and > preferably at no additional cost if we are to avoid having to > subdivide /64s. > > Curtis > > ------- Forwarded Message > > Message-Id:<201209230330.q8N3Uix6047290@gateway1.orleans.occnc.com> > To: homenet@ietf.org > cc: curtis@occnc.com > Reply-To: curtis@occnc.com > Subject: draft-ietf-homenet-arch-04 > From: Curtis Villamizar > Date: Sat, 22 Sep 2012 23:30:44 -0400 > > > Tim, Jari, Anders, Ole, Jason, > > I hope this is an OK time for comments on this draft. > > I just spent some time going through draft-ietf-homenet-arch-04 and I > also took the time to look through all the RFCs and drafts that it > references, even most of the expired ones. > > I edited in some diffs to the xml2rfc source. Most of the diffs > should be self explanitory, though I'm sure some will not be without > controversy on the WG list. I left in some XML comments where either > I wanted to explain a change, or I would like to see some discussion > on list. > > The xml file is at > http://www.ietf.org/id/draft-ietf-homenet-arch-04.xml > > The diffs are below. Hopefully we can all read unified diffs of an > xml file. I'll also summarize some major points here. > > 1. Must be capable of self configuring but should allow manual > config. > > 2. A few citations could stand to be removed. Some drafts are > expired and don't look like they were entirely completed. Some > of the expired drafts look good but just managed to expire. > > 3. I am proposing that we drop the "well known name" as a means to > discover the border(s). This seems to me like a real bad idea. > > 4. In "Global addressability and elimination of NAT" > (false-)security concerns about losing NAT are cited but no > advantage to global addressability is cited. I think that is an > oversight but didn't add text here. (yet) > > 5. In a few places I've pointed out that firewalls (and NAT and > anti-virus) provide very ineffective security and we should be > very up front about saying so, though we can acknowledge that in > the absense of reasonably secure home products, we can't get rid > of them just yet. > > 6. Proposals for IPv6-only MUST provide some accommodations for > legacy IPv4 only hosts or plain vanilla DS hosts. I called this > IPv4 fallback on an otherwise IPv6 only network. I split the > bullet on NAT64/DNS64 into two. > > a. As I had pointed out on the list, doing DNS64 at the CE (or > a router) will break any IPv4 only host. The DNS64 > translation should be done at the host. The NAT64 can be > done at the CE (or any willing router). > > b. The DS-Lite B4 can be done on the host as long as DHCPv6 > tells the host that an AFTR is availalbe. If the CE gets > the FQDN of an AFTR as a DHCPv6 client on the WAN side it > can pass that along to hosts as a server on the DHCPv6 > homenet side. The DS-Lite B4 capable host can tunnel to the > AFTR and not make a DHCPv4 request (operate v6only). The > plain DS and IPv4-only hosts can make DHCPv4 requests. If > V4 packets arrive at the CE, the CE can act as a B4 if the > provider gave a AFTR FQDN in the WAN side DHCPv6. > > 7. If some topology can casue things to be broken, then what the > homenet WG specified is broken. Added some text on pathelogical > cases. The only true pathological case is a loop in a set of > repeaters if a routing protocol is used and switches either > detect cycles or use IEEE spanning tree or link state protocols. > > 8. Cascading NATs are common. Added text as to why. > > 9. Questioned why we mention VLANs. An unsophisticated home user > is not likely to be playing with VLANs. > > 10. Should we get rid of physical standard references? I think so. > > 11. Modified "bridge whenever possible" text. Also "Largest > possible subnets" section title changed to "Largest practical > subnets" for reasons given in comments. > > 12. This is sure to be controversial. I pointed out that using > subnets longer than /64 is OK as long as they are not leaked > into global routing. Please read the text and changes before > exploding on this topic. It may be necessary to subnet a /64 if > that is all a provider will give you and you need subnets. It > does work and it is no more unnatural than subnetting a class-A > network would be in 1990. It means using DHCPv6 and not using > RA prefixes for GUA (otherwise SLAAC implementations would > likely try to use the whole bottom 64). > > 13. There are a few minor wording changes, minor clarifications, > etc. > > 14. There may be more fuss about confining interior routing within > a border than needed. I added a paragraph that might help (or > might not). > > 15. In the security section I added a subsection named "Marginal > Effectiveness of NAT and Firewalls". (btw- Firewall horror > story at bar BOF on request.) > > 16. Added "It has been suggested that Dynamic DNS could be made to > operate in a zero-configuration mode using a locally significant > root domain and with minimal configuration or using a DHCPv6 > based (details to-be-defined) means of automated delegation > populate a global DNS zone." Maybe a draft is needed on this > but for now please discuss on list. > > 17. Suggest that any mechanism that is subnet-only has to be > extended to site *or abandoned by the WG* rather than proxied. > Old text said extended but not proxied (sic). > > 18. Updated references (one draft is now RFC, one individual draft > is now WG draft, noted those that are expired). > > 19. Question on "ISPs renumber due to privacy laws". What's that > all about? > > Curtis > > > BTW- The file still compiles and I made some updates to the references > section which means the entity defines up front are edited. I'm quite > sure you'll want to pick and choose diffs or hand edit the changes you > want back in. Hopefully you'll want something. :) > > > > - --- draft-ietf-homenet-arch-04.xml.orig 2012-07-16 10:00:38.000000000 -0400 > +++ draft-ietf-homenet-arch-04.xml 2012-09-22 22:06:24.000000000 -0400 > @@ -4,13 +4,17 @@ > > > > + > > + > > + > > > > > > + > > > > @@ -52,8 +56,8 @@ > PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc3484bis.xml'> > > - - - - PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.v6ops-multihoming-without-ipv6nat.xml'> > + + PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat.xml'> > > PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-homenet-prefix-assignment.xml'> > @@ -202,8 +206,9 @@ > which case such networks may use increasing numbers of subnets, and > require methods for IPv6 prefixes to be delegated to those subnets. > The assumption of this document is that the > - -homenet is as far as possible self-organising and self-configuring, > - -and is thus not pro-actively managed by the residential user. > +homenet is as far as possible > +capable of self-organising and self-configuring, > +and is thus need not be pro-actively managed by the residential user. > > > The > @@ -258,6 +263,9 @@ > "Advanced Security". Describes advanced security functions for a CER, as > defined in, > where the default inbound connection policy is generally "default allow". > + > CER: Customer Edge Router. A border router at the edge of the homenet. > LLN: Low-power and lossy network. > NAT: Network Address Translation. Typically referring to IPv4 > @@ -283,10 +291,9 @@ >
> > > - -Service providers are deploying IPv6, content is becoming available on > - -IPv6 (accelerated recently by the World IPv6 Launch event) > - -and support for IPv6 is increasingly available in devices and > - -software used in the home. While > + > +While > IPv6 resembles IPv4 in many ways, it changes address allocation principles, > making multi-addressing the norm, and allowing direct IP addressability > of home networking > @@ -323,9 +330,14 @@ > > Documents that provide some more specific background and depth on this > topic include: > - -, > - -, and > - -. > +, > +, and > +. > + > + > > The addition of routing between subnets raises the issue of > how to extend mechanisms such as service discovery which currently rely > @@ -340,6 +352,10 @@ > Here, there are a number of choices. These include > an appropriate service discovery protocol, or the use of a > well-known name, resolved by some local name service. > + > Both might have to deal with handling more than one router responding > in multihomed environments. > > @@ -357,6 +373,9 @@ > allowing every device on every link to be assigned a globally unique > IPv6 address. > > + > > The end-to-end communication that is potentially enabled with IPv6 is > on the one hand an incredible > @@ -373,6 +392,12 @@ > would only be used on private networks or the device itself doesn't > have the computing power to apply the necessary security methods. > > + > > IPv6 networks may or may not have filters applied at their borders, i.e. > at the homenet CER. > @@ -498,11 +523,33 @@ > should be considered in IPv6-only environments: > > > - -Ensuring there is a way to access content in the IPv4 Internet. This can > +Ensuring there is a way to access content in the IPv4 Internet. > + > + > +This can > be arranged through incorporatingNAT64 > andDNS64 > functionality in the home gateway router, for instance. Such features > - -are outside the scope of this document however, being CER functions. > +are outside the scope of this document however, being CER functions. > +Legacy IPv4-only hosts could not function in a network for which the > +DNS server implements DNS64. Therefore a DNS64 NS may need to disable > +DNS64 translation for DNS queries arriving via IPv4 transport. > +This can also be arranged through use of > +DS-Lite, with the DS-Lite > +B4 implemented in the host and the DS-Lite AFTR implemented in the > +CPE, or the AFTR FQDN passed from the CPE to the host if AFTR is > +offerred by the service provider. > + > + > + > + > > DNS discovery mechanisms are enabled for IPv6. Both stateless > DHCPv6 @@ -517,6 +564,12 @@ > mode. Some current devices work well with dual-stack but fail to > recognise connectivity when IPv4 DHCP fails, for instance. > > +It is desirable for mechanisms which enable IPv6-only host > +operation, to also support IPv4 as a fallback for legacy devices and > +support DHCPv4 for legacy IPv4 only hosts and for IPv6 DS devices > +which fail to operate without IPv4 and DHCPv4. > + > > > > @@ -551,7 +604,8 @@ > expect the resulting network to operate. > Significant manual configuration is rarely, if at all, possible, given > the knowledge level of typical home users. Thus the network should, > - -as far as possible, be self-configuring. > +as far as possible, be self-configuring. For the benefit of the > +atypical more advanced user, manual configuration should be supported. > > > The equipment also needs > @@ -623,6 +677,17 @@ > infrastructure to allow the rest to operate. In such cases, > the user should ideally have some useful > indication of the failure mode encountered. > +There are no topology secenarios which could cause loss of > +connectivity, except when the user > +creates a physical island within the topology. Some potentially > +pathological cases that can be created include bridging ports of a > +router together, however this case can be detected and dealt with by > +the router. Routing cycles within a topology are in a sense good in > +that they offer redundancy. Bridging cyslces can be dangerous but are > +also detectable when a switch learns the MAC of one of its interfaces > +on another or runs a spanning tree or link state protocol. It is only > +cycles using simple repeaters that are truly pathological. > + >
> >
> @@ -636,6 +701,14 @@ > and private networks. > > > +Cascading NATs are somewhat common in IPv4 home networks. Many > +devices such as SIP devices and some streaming video devices have a > +WAN side and LAN side Ethernet port and in their installation > +instructions either recommend or insist on being the device closest to > +the WAN for QoS reasons. A user may comply and string these together > +resulting in two or three or potentially more cascaded IPv4 NAT. > + > + > In general, the models described in > > and its successor RFC 6204-bis > @@ -656,6 +729,9 @@ > subnets, with > no direct connectivity between them within the homenet. Isolation may > be physical, or implemented via IEEE 802.1q VLANs. > + > Demarcation of the CER. The CER(s) may or may not be managed by > the ISP. If the demarcation point is such that the customer > can provide or manage the CER, its configuration must be simple. Both > @@ -688,6 +764,23 @@ > A separate discussion of physical infrastructures > for homenets is included in > and. > + > + > > > In the following sections we give some examples of the types of > @@ -707,7 +800,8 @@ > topology itself may also be complex, and it may not be possible to > assume a pure tree form, for instance (home > users may plug routers together to form arbitrary topologies > - -including loops). > +including cycles. > + > > >
> @@ -863,7 +957,9 @@ > A general recommendation is to follow the same topology for IPv6 > as is used for IPv4, but not to use NAT. Thus there should be > routed IPv6 where an IPv4 NAT is used, and where there is no NAT > - -there should be bridging if the link layer allows this. > +routing or bridging may be used. Routing may have advantages over > +bridging together high speed and lower speed shared media and bridging > +may not be suitable for some media, such as ad-hoc mobile networks. > > > In some cases IPv4 NAT > @@ -925,12 +1021,14 @@ > typically include. Applications may > of course do different things, and this should not be precluded. > > + > > > For the single CER Network Model C, multihoming may be offered by source > routing at the CER. With multiple exit routers, the complexity rises. > Given a packet with a source address on the network, the > - -packet must be routed to the proper egress to avoid BCP 38 > +packet must be routed to the proper egress to avoid BCP 38 > +() > filtering at an ISP that did not delegate the prefix the address is > chosen from. While > the packet might not take an optimal path to the correct exit CER, the > @@ -939,11 +1037,12 @@ > that the packet is routed in the most efficient manner to the correct > exit. > > + > > > There are various potential approaches to this problem, one example > being described in > - -. > +. > Another is discussed in, > which explores support for source routing throughout the homenet. > This approach would however likely require relatively significant > @@ -951,6 +1050,8 @@ > given the source address. Such changes should preferably be > minimised. > > + > > There are some other multihoming considerations for homenet > scenarios. First, it may be the case that > @@ -967,6 +1068,7 @@ > While we should not specifically target walled garden multihoming as > a principal goal, it should not be precluded. > > + > > > Host-based methods such > @@ -1049,7 +1151,7 @@ >
> > > - -
> +
> > Today's IPv4 home networks generally have a single subnet, and > early dual-stack deployments have a single congruent IPv6 subnet, > @@ -1063,9 +1165,11 @@ > routers and thus need multiple subnets, for > the reasons described earlier. As part > of the self-organisation of the network, the homenet should subdivide > - -itself to the largest possible subnets that can be constructed within > +itself to the largest practical subnets that can be constructed within > the constraints of link layer mechanisms, bridging, physical > - -connectivity, and policy. > +connectivity, policy, and where applicable performance or other > +criteria. For example, bridging a busy GbE subnet and a wireless > +subnet together may impact wireless performance. > > > While it may be desirable to maximise the chance of link-local > @@ -1073,6 +1177,15 @@ > multi-subnet home networks are inevitable, so their support must be > included. > > + > >
> > @@ -1109,6 +1222,31 @@ > homenet will need to adapt to the prefixes made available to it > through the prefix delegation method used by its upstream ISP. > > + > +It is important to note that for the purpose of a homenet, a /64 > +prefix is subdividable. specifically states > +"Subnet numbers must be assumed to come from the network part. This > +is not to preclude routing protocols such as IS-IS level 1 > +(intra-area) routing, which routes individual host addresses, but says > +that it may not be depended upon in the world outside that zone." > +Prefixes longer than /64 are not globally routable but may be used by > +protocols such as IS-IS or OSPF to subdivide a /64. Subdividing a /64 > +effectively requires a managed address space, disallowing allocation > +within that /64 though SLAAC and disallowing > +any technique which requires the use of the full lower 64 bits such as > +CGA. > + > + > + > +If faced with allocation of a /64 prefix, or a prefix that is too > +short to support a /64 for each subnet it may be necessary to > +subdivide one or more /64. This need may arise if some providers > +refuse to allocate anything but a /64 to home users, small office > +users, or very small businesses. The need to get the network running > +may have to be weighed against other needs such as CGA. > + > + > >
> > @@ -1123,7 +1261,8 @@ > and thus make no assumptions about the stability of the prefix > received from an ISP, or the length of the prefix that may be offered. > However, if only a /64 is offered by the ISP, the homenet may be > - -severely constrained, or even unable to function. > +severely constrained, or even unable to function if the /64 cannot be > +subdivided due to conflicting requirements (such as CGA). > > > The internal operation of the home network should also not depend on > @@ -1142,6 +1281,12 @@ > their prefix pool) changing. It is not expected that ISPs will support > Provider Independent (PI) addressing for general residential homenets. > > + > > When an ISP needs to restructure and in doing so renumber its customer > homenets, "flash" renumbering is likely to be imposed. This implies a need > @@ -1154,6 +1299,8 @@ > is an extended version of an initial numbering process, the difference > between flash renumbering and an initial "cold start" is the need to > provide service continuity. > +The depricated addresses would remain usable within the homenet as > +described in. > > > There may be cases where local law means some ISPs are required to change > @@ -1177,6 +1324,11 @@ > The introduction of any new homenet protocols should not make any form of > renumbering any more complex than it already is. > > + > >
> > @@ -1213,6 +1365,30 @@ > scope through filtering at the border(s) of the homenet, as described > in RFC 6092. > > + > +If a routing protocol (or static routing) is not used, then ULA or GUA > +connectivity across subnets cannot occur. ULA connectivity requires > +that host routes (IPv6 /128 routes) be used. In a very large network > +this would pose a scaling issue. Homenets should be sufficiently > +small that scalability is not at all an issue, even is the absence of > +the route aggregation afforded by GUA subnet routes. An interior > +routing protocol adjacency (IS-IS or OSPF) should not be attempted by > +default on a provider interface, and will generally require a shared > +secret with the provider, implying a need for configuration. If such > +an adjacency is configured, route summarization of GUA routes is > +required and no ULA routes should be advertised to the provider. Any > +sensible provider will provide route filters on their end. More > +likely no routing protocol adjacency will exist between the homenet CE > +and the provider. For medium sized businesses (not a homenet) a BGP > +adjacency might be used, but still no OSPF or IS-IS adjacency. > +Similarly the provider would pay no attention to distance vector > +routing protocol information erroneously sent from the homenet. The > +homenet interior routing information would therefore always be > +confined to the homenet. > + > + > >
> > @@ -1230,7 +1406,8 @@ > . > Then each subnet in the homenet should receive a prefix from within the > ISP-provided prefix(es). The ISP should only see the aggregate from > - -the homenet, and not single /64 prefixes allocated within the homenet. > +the homenet, and not single /64 (or longer) prefixes allocated within > +the homenet. > > > Delegation should be autonomous, and not assume a flat or > @@ -1281,14 +1458,18 @@ > > Several proposals have been made for prefix delegation within a homenet. > One group of proposals is based on DHCPv6 PD, as described in > - -, > - -, > +, > +, > and. > The other uses OSPFv3, as described in > . > More detailed analysis of these approaches needs to be made against the > requirements/principles described above. > > + > > >
> @@ -1385,6 +1566,8 @@ > evaluations of common routing protocols made against the type of requirements > described above. > > + > >
> > @@ -1406,10 +1589,41 @@ > to be able to operate securely, end-to-end where required, but also be > robust against malicious traffic direct towards them. We simply > note at > - -this point that software on home devices will have an increase in > +this point that software on home devices may have an increase in > security if it allows its software to be updated regularly. > > > +
> + > +Security by way of obscurity (address translation) or through > +firewalls (filtering) is at best marginally effective. The very poor > +security track record of home computer, home networking and business > +PC computers and networking is testomony to its ineffectiveness. A > +compromise behind the firewall of any device exposes all others, > +making an entire network that relies on obscurity or a firewall as > +vulnerable as the most insecure device on the private side of the > +network. > + > + > +However, given home network products with very poor security, putting > +a firewall in place does provide some protection, even if only > +marginally effective. IPv6 global reachability may increase the need > +to solve the underlying problem of certain insecure home and business > +computer and network products. The use of firewalls today, whether a > +good practice or not, is common practice and whatever protection > +afforded, even if marginally effective, must not be lost. > + > + > +
> + >
> > An IPv6-based home network architecture should embrace > @@ -1465,6 +1679,8 @@ > to be configured on a CER. Such methods should be able to > be automatically updating. > > + >
> > > @@ -1577,7 +1793,11 @@ > There are naming protocols that are designed to be configured and > operate Internet-wide, like unicast-based DNS, but also protocols > that are designed for zero-configuration local environments, like > - -mDNS. Consideration should be made for how these interact with each > +mDNS. It has been suggested that Dynamic DNS could be made to operate > +in a zero-configuration mode using a locally significant root domain > +and with minimal configuration or using a DHCPv6 based (details > +to-be-defined) means of automated delegation populate a global DNS > +zone. Consideration should be made for how these interact with each > other in a homenet scenario. > > > @@ -1634,6 +1854,8 @@ > to multicast service discovery requests. Those same parts > of the network may have less capacity for multicast traffic that > may be flooded from other parts of the network. > + > In general, message utilisation should be efficient considering > the network technologies the service may need to operate over. > > @@ -1650,7 +1872,7 @@ > > > Current service discovery protocols are generally aimed at single > - -subnets. If service discovery is to operate across the an entire > +subnets. If service discovery is to operate across an entire > homenet, by adopting an approach like that proposed as Extended mDNS > (xmDNS), then > support may be required for IPv6 multicast across the scope of the > @@ -1682,12 +1904,14 @@ > > The homenet architecture proposes that any existing > protocols that are designed to only work within a subnet should be extended > - -to work across subnets, rather than defining proxy capabilities > +to work across subnets or not used by homenet, > +rather than defining proxy capabilities > for each of those functions. However, while > it is desirable to extend protocols to site scope operation rather > than providing proxy functions on subnet boundaries, the > reality is that until all hosts can use site-scope discovery protocols, > - -existing link-local protocols would need to be proxied anyway. > +existing link-local protocols would need to be proxied anyway or other > +solutions found which are not link local in scope. > > Some protocols already have proxy functions defined and in use, e.g. > DHCPv6 relays, in which case those protocols would be expected to > @@ -1812,10 +2036,14 @@ > > > &rfc1918; > + &rfc2462; > &rfc2475; > &rfc2775; > + &rfc2827; > &rfc3022; > + &rfc3177; > &rfc3646; > + &rfc3972; > &rfc4192; > &rfc5533; > &rfc5969; > @@ -1826,22 +2054,26 @@ > &rfc6296; > &rfc6333; > &rfc6555; > - -&I-D.baker-fun-multi-router; > - -&I-D.lynn-homenet-site-mdns; > - -&I-D.townsley-troan-ipv6-ce-transitioning; > - -&I-D.baker-fun-routing-class; > - - &I-D.howard-homenet-routing-comparison; > - -&I-D.herbst-v6ops-cpeenhancements; > - -&I-D.vyncke-advanced-ipv6-security; > - - &I-D.ietf-6man-rfc3484bis; > - - &I-D.v6ops-multihoming-without-ipv6nat; > - - &I-D.baker-homenet-prefix-assignment; > +&I-D.baker-fun-multi-router; > +&I-D.lynn-homenet-site-mdns; > +&I-D.townsley-troan-ipv6-ce-transitioning; > +&I-D.baker-fun-routing-class; > + &I-D.howard-homenet-routing-comparison; > +&I-D.herbst-v6ops-cpeenhancements; > +&I-D.vyncke-advanced-ipv6-security; > + &I-D.ietf-6man-rfc3484bis; > + &I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat; > + &I-D.baker-homenet-prefix-assignment; > &I-D.arkko-homenet-prefix-assignment; > &I-D.acee-ospf-ospfv3-autoconfig; > - - &I-D.ietf-pcp-base; > - - &I-D.hain-ipv6-ulac; > - -&I-D.chakrabarti-homenet-prefix-alloc; > - -&I-D.arkko-homenet-physical-standard; > + &I-D.ietf-pcp-base; > + &I-D.hain-ipv6-ulac; > +&I-D.chakrabarti-homenet-prefix-alloc; > +&I-D.arkko-homenet-physical-standard; > + > + > > > > @@ -1953,7 +2185,7 @@ > Clarified simple and advanced security some more, and RFC 4864 and 6092. > Stated that there should be just one secret key, if any are used at all. > For multihoming, support multiple CERs but note that routing to the correct CER to avoid ISP filtering may not be optimal within the homenet. > - -Added some ISPs renumber due to privacy laws. > +Added some ISPs renumber due to privacy laws. > Removed extra repeated references to Simple Security. > Removed some solution creep on RIOs/RAs. > Load-balancing scenario added as to be supported. > > ------- End of Forwarded Message > > From v6ops@globis.net Wed Oct 3 04:30:45 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5988C21F8667 for ; Wed, 3 Oct 2012 04:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 WHT4QgWGQ10q for ; Wed, 3 Oct 2012 04:30:44 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43321F85A4 for ; Wed, 3 Oct 2012 04:30:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2BD4A870098; Wed, 3 Oct 2012 13:30:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+Dgjs0jpijN; Wed, 3 Oct 2012 13:29:59 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 67EE287005F; Wed, 3 Oct 2012 13:29:59 +0200 (CEST) Message-ID: <506C21B1.9080100@globis.net> Date: Wed, 03 Oct 2012 13:29:53 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: Damien Saucez References: <201210010121.q911Lsbp031067@gateway1.orleans.occnc.com> <2C25872F-9E9D-49B4-BEDA-C82E0EBC485F@gmail.com> In-Reply-To: <2C25872F-9E9D-49B4-BEDA-C82E0EBC485F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Wassim Haddad , curtis@occnc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 11:30:45 -0000 I have read the draft and don't see how it advances Homenet. IMHO If an MSP wants to deploy some tunnel brokers on the Internet to terminate what boils down to a pair of GRE tunnels, they can do so without the IETF providing any new standards work, and it'll all work just fine. I'd prefer it if people concentrated on http://www.ietf.org/id/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt regards, RayH Damien Saucez wrote: > Curtis, > > Thank you for the comments. > > Our target in this document is to raise the question of multihoming > in personal and/or small/medium enterprise networks, so for now > we were not looking at the mobile device such as smartphones > connected to both 4g and wifi (for this, the multihoming solution > must be implemented directly on the device). We believe that > SOHO would be interested being multihomed but can't afford the > cost of operating multihoming themselves. This is why we suggest > the MSP which is a way to outsource multihoming complexity. > > Now, let's go to the technical part. We didn't want to provide > solution so far but we had in mind the following: > > 1. traffic is tunnelled between the network and the MSP. > > 2. addresses assigned to devices in the network belong to > the MSP (or at least are advertised by the MSP in BGP) and > then they never change. > > 3. the MSP box has one "wire" (possibly vie wifi or 3/4G) per > ISP to which the network is connected and each NIC connected > to this "wire" receives addresses dynamically. > > Putting these three points together, it means that the gw are > invisible to the devices in the network, that addresses of devices > never change during communications and that traffic always go > through the MSP (even though it is possible to avoid this). > > I agree that there is no such thing as the MSP so far, but there > is a bunch of very big service providers that exist today, that are > peering with virtually every significant network and that would > certainly be happy to be the "first hop" for all the communications. > > > Thank you, > > Damien Saucez > > On 01 Oct 2012, at 03:21, Curtis Villamizar wrote: > >> In message<08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> >> Wassim Haddad writes: >> >>> Dear all, >>> >>> We have submitted a problem statement for multihoming in homenet. >>> Comments appreciated! >>> >>> Regards, >>> >>> Wassim H. >> Wassim, >> >> You are proposing a solution, not submitting a problem statement. >> >> A problem with your solution is that the most common multihoming is >> the mobile device having IP access through both WiFi (via DSL or cable >> or hotspot) and 4G mobile. In this case the "MSP middlebox" you >> propose would have to be inside the mobile device, which is already >> both one of the gateways and the end host. >> >> Another problem is the current non-existance of a Multihoming Service >> Provider (MSP)" somewhere out "in the cloud" to replace the source >> address of packets. >> >> No where in your document does the principle issue with multihoming >> get addressed. The source address used by the host must be chosen >> somehow by the host or replaced somewhere. The function of the "MSP >> middlebox" as described is only to redirect outgoing packets. If the >> source address reflect going through ISP2, and that link goes away, >> then the packets can now go out through ISP1 but the problem of using >> the wrong source address remains. >> >> If the source address is somehow provided by the MSP, then the traffic >> has to be tunnelled from MSP middlebox to MSP as might be implied by >> the last paragraph in section 4 where it says "In addition, if Gw1 and >> Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the >> MSPMB will be configured automatically as well". The word "address" >> barely appears in the draft except for the prior statement and one in >> the intro saying why Shim6 or MPTCP should not be used. The word >> "tunnel" doesn't appear at all. The word "source" (as in "source >> address") doesn't appear at all. >> >> So you don't seem to be proposing a viable solution or perhaps you had >> something to do with tunnelling in mind that you didn't describe at >> all clearly. >> >> Curtis >> >> >>> Begin forwarded message: >>> >>>> From: "internet-drafts@ietf.org" >>>> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt >>>> Date: September 25, 2012 10:55:38 AM PDT >>>> To: "i-d-announce@ietf.org" >>>> Reply-To: "internet-drafts@ietf.org" >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : Multihoming in Homenet >>>> Author(s) : Wassim Haddad >>>> Damien Saucez >>>> Joel Halpern >>>> Filename : draft-haddad-homenet-multihomed-00.txt >>>> Pages : 7 >>>> Date : 2012-09-25 >>>> >>>> Abstract: >>>> So far, multihoming in Homenet must be supported by the hosts as >>>> there is no mean to use simultaneously the different Internet Service >>>> Providers of the "Homenet" without risking flow disruption. In this >>>> memo, we describe the problem statement for multihoming in Homenet. >>>> We also propose a high level solution that answers this particular >>>> problem. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > From curtis@occnc.com Wed Oct 3 10:36:44 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EE021F864D for ; Wed, 3 Oct 2012 10:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlJfAaq3HL9D for ; Wed, 3 Oct 2012 10:36:44 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id BA52721F85A1 for ; Wed, 3 Oct 2012 10:36:43 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q93HaKKx077003; Wed, 3 Oct 2012 13:36:20 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210031736.q93HaKKx077003@gateway1.orleans.occnc.com> To: Ray Hunter From: Curtis Villamizar In-reply-to: Your message of "Wed, 03 Oct 2012 09:18:06 +0200." <506BE6AE.5070708@globis.net> Date: Wed, 03 Oct 2012 13:36:20 -0400 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:36:44 -0000 In message <506BE6AE.5070708@globis.net> Ray Hunter writes: > Why not just add RFC 6177 BCP 157 > http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in > draft-ietf-homenet-arch? > > That's a lot shorter than re-hashing the whole discussion within Homenet. Clearly some providers aren't getting it so repitition may help, but not repitition of the entire argument made in RFC6177. For example: This document obsoletes RFC 3177, updating its recommendations in the following ways: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition, implies multiple subnets and multiple devices. One provider is doing a trial allocating /128 addresses and alegedly targeting this at *business service*. /64 later (no date). shorter prefixes still later (also no date). So either they are not reading RFC6177 or they are not getting it. Wording which refers to RFC6177 would help. Adding the one sentence below to that would also help. How about: If home networks are to avoid having to subdivide /64s, then consumer oriented service providers MUST allow customers to easily request and get prefixes shorter than /64 and SHOULD provide these shorter prefixes at no additional cost. Allocation of shorter prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. If there is no objections we can end this part of the thread and move on to the rest of the suggested changes to the draft. > Curtis Villamizar wrote: > > Now that we beat summary item #12 to death, can we please turn our > > attention to the remaining 18 summary items listed below and the diffs > > to the draft? > > > > btw- I think the concensus on summary item #12 is that maybe we can > > add the following points to the framework. Subnets longer than /64 > > are bad. Some devices don't support DHCPv6, therefore SLAAC is > > essential. Consumer oriented service providers of must allow > > customers to easily request and get prefixes shorter than /64 and > > preferably at no additional cost if we are to avoid having to > > subdivide /64s. > > > > Curtis [ ... trim ... ] I think your reply was just concerning the above paragraph so I trimmed the rest. Curtis From jabowden@centurylink.net Wed Oct 3 11:48:57 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9870C21F8620 for ; Wed, 3 Oct 2012 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AgEJyJrkiOjO for ; Wed, 3 Oct 2012 11:48:57 -0700 (PDT) Received: from mailrelay.embarq.synacor.com (mailrelay.embarq.synacor.com [208.47.184.3]) by ietfa.amsl.com (Postfix) with ESMTP id EA45421F85C0 for ; Wed, 3 Oct 2012 11:48:56 -0700 (PDT) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=BdRaI8R2 c=1 sm=0 a=mhuKW4xE6qBSEwXRqgE/8Q==:17 a=FB6NmUnAAagA:10 a=ovU4EIyFVtQA:10 a=YTHtZiAxaJsA:10 a=8nJEP1OIZ-IA:10 a=I_5RNyk1AAAA:8 a=vAYkDPdjcR4A:10 a=Xkf0Kvx1AAAA:8 a=BqEg4_3jAAAA:8 a=48vgC7mUAAAA:8 a=nvW98YzmJzhO8puL1BIA:9 a=wPNLvfGTeEIA:10 a=mwvyeZAJh9gA:10 a=lZB815dzVvQA:10 a=mhuKW4xE6qBSEwXRqgE/8Q==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.embarq.synacor.com smtp.user=jabowden@centurylink.net; auth=pass (LOGIN) Received: from [64.91.32.219] ([64.91.32.219:24710] helo=[192.168.1.20]) by smtp.centurylink.net (envelope-from ) (ecelerity 2.2.3.47 r(39797/39798)) with ESMTPA id 7A/52-17441-7988C605; Wed, 03 Oct 2012 14:48:56 -0400 Message-ID: <506C889B.4070709@centurylink.net> Date: Wed, 03 Oct 2012 13:48:59 -0500 From: Jeff Bowden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201210031736.q93HaKKx077003@gateway1.orleans.occnc.com> In-Reply-To: <201210031736.q93HaKKx077003@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:48:57 -0000 Curtis, I agree with your addition of that paragraph with the one exception of removing the "at no additional cost" phrase. I agree it should be that way but it is up to the individual ISP and not the IETF as to what should and should not be charged for. Yes, lets move on. Best regards, Jeff Bowden On 10/3/2012 12:36 PM, Curtis Villamizar wrote: > In message <506BE6AE.5070708@globis.net> > Ray Hunter writes: > >> Why not just add RFC 6177 BCP 157 >> http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in >> draft-ietf-homenet-arch? >> >> That's a lot shorter than re-hashing the whole discussion within Homenet. > Clearly some providers aren't getting it so repitition may help, but > not repitition of the entire argument made in RFC6177. > > For example: > > This document obsoletes RFC 3177, updating its recommendations in the > following ways: > > 1) It is no longer recommended that /128s be given out. While > there may be some cases where assigning only a single address > may be justified, a site, by definition, implies multiple > subnets and multiple devices. > > One provider is doing a trial allocating /128 addresses and alegedly > targeting this at *business service*. /64 later (no date). shorter > prefixes still later (also no date). So either they are not reading > RFC6177 or they are not getting it. > > Wording which refers to RFC6177 would help. Adding the one sentence > below to that would also help. How about: > > If home networks are to avoid having to subdivide /64s, then > consumer oriented service providers MUST allow customers to easily > request and get prefixes shorter than /64 and SHOULD provide these > shorter prefixes at no additional cost. Allocation of shorter > prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. > > If there is no objections we can end this part of the thread and move > on to the rest of the suggested changes to the draft. > >> Curtis Villamizar wrote: >>> Now that we beat summary item #12 to death, can we please turn our >>> attention to the remaining 18 summary items listed below and the diffs >>> to the draft? >>> >>> btw- I think the concensus on summary item #12 is that maybe we can >>> add the following points to the framework. Subnets longer than /64 >>> are bad. Some devices don't support DHCPv6, therefore SLAAC is >>> essential. Consumer oriented service providers of must allow >>> customers to easily request and get prefixes shorter than /64 and >>> preferably at no additional cost if we are to avoid having to >>> subdivide /64s. >>> >>> Curtis > [ ... trim ... ] > > I think your reply was just concerning the above paragraph so I > trimmed the rest. > > Curtis > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From sm@resistor.net Wed Oct 3 12:23:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4B821F84B8 for ; Wed, 3 Oct 2012 12:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 fRbHrxyRwLI3 for ; Wed, 3 Oct 2012 12:23:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8721F8498 for ; Wed, 3 Oct 2012 12:23:26 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q93JNK3g009628 for ; Wed, 3 Oct 2012 12:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349292204; bh=C5W1/oA5L14PdYDZaxKxdPROuFN/jD+KP31hJqpWLrU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Iiq1C4BDuoRfbxGDrVB/ogA8VUYJAWRP2/B957VctUKpdw3sj/nJtB/1CgOy6yifF pvrB9/Xjk7pJcsV+k5c23Z7C81ZYDc3POcCmGl/qBvKxGOxh/xV4UXQEMTQkaWRJpL AdbQgQ+I033dZr9uXdpBRH3C9yL8ZRjhHFvUPkw4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349292204; i=@resistor.net; bh=C5W1/oA5L14PdYDZaxKxdPROuFN/jD+KP31hJqpWLrU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=FCO0F7AlWS9XG1YUNJ4++u3zP54vMhp0u8klJDtjNG1xoMSbxlml8Z/ummOaIxHgW /eWWF5aUz8LXovyqQn9ZF5fmLyFh8eXcHDs0hK5htCY3+H2kUHvXdXzCUQUA12sL0+ /3nr7f2/yCSHfsarP9LsUY4fFY/e/qHHu1fNhseo= Message-Id: <6.2.5.6.2.20121003122113.0b37d5e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Oct 2012 12:23:08 -0700 To: homenet@ietf.org From: SM In-Reply-To: <506C889B.4070709@centurylink.net> References: <201210031736.q93HaKKx077003@gateway1.orleans.occnc.com> <506C889B.4070709@centurylink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:23:26 -0000 At 11:48 03-10-2012, Jeff Bowden wrote: >I agree with your addition of that paragraph with the one exception >of removing the "at no additional cost" phrase. I agree it should >be that way but it is up to the individual BCP 157 contains some non-technical text. It may be better to avoid any text that will cause political issues. Regards, -sm From mark@townsley.net Wed Oct 3 12:35:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A3B21F850D for ; Wed, 3 Oct 2012 12:35:48 -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.149, 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 znG3mxJaHFmN for ; Wed, 3 Oct 2012 12:35:47 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 398B221F850C for ; Wed, 3 Oct 2012 12:35:47 -0700 (PDT) Received: by eekd4 with SMTP id d4so4671469eek.31 for ; Wed, 03 Oct 2012 12:35:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=w3npci/mmZIfCqh/DFiagWHmzUs3iRz+jp03gLwNNyk=; b=gonDOgpSE6FoJFg8Q/EZJ9JtrM9N0zHV5vB92DCiROF/i8mMMCG0Z+VQii9UZmd4bf 2M9G8xzIjz0cHW1sOWjDinzHa8P9ou6s3zlQl7vWGsbZJzWU2eNEhkNL5+Xs9IFxGjRa b/LbtWQKI6yZ96ihfjCEkSIDrBLBSCsKS9jADqiqjtjjs4dFRcuQVxtd7/zXKZgM9JC4 HfyntzthA11SrXIcSKOR4uIy7/cGLxl5h5187zyaQe7DsC8noyvo9ZGoMilFmUYPjcW2 f2CI0HPxjVvgyuvC4Y6y8Vd8mr5rgxcFaDcetuex5NRKQVfiE0JslTyticoQ2vWvi+VZ 3Ttg== Received: by 10.14.218.134 with SMTP id k6mr4265412eep.14.1349292944972; Wed, 03 Oct 2012 12:35:44 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id r45sm11295091eem.6.2012.10.03.12.35.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Oct 2012 12:35:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_83793F2E-6DF3-465B-BBB1-25A605AA048C" From: Mark Townsley In-Reply-To: <506C889B.4070709@centurylink.net> Date: Wed, 3 Oct 2012 21:35:22 +0200 Message-Id: References: <201210031736.q93HaKKx077003@gateway1.orleans.occnc.com> <506C889B.4070709@centurylink.net> To: Jeff Bowden X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkRgycUVAncBFxE/o41lCiFxncSLIWyud6pFntauN1786FQyBQRWh2GeyLgVXqvFWirYgk+ Cc: homenet@ietf.org Subject: Re: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:35:48 -0000 --Apple-Mail=_83793F2E-6DF3-465B-BBB1-25A605AA048C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What about taking section 5 (summary) of RFC 6177 as a guide and apply = it to our specific case? I don't think we would conflict with any of the = statements, but we could provide a bit more justification and direction = than what is there for the homenet specifically. For example, the = "operational considerations" for the site can be further refined to mean = the automatic prefix distribution mechanisms running in the homenet = router (as there is by definition no human operator of the network = assigning prefixes, but an algorithm that we have designed). =20 Also, RFC 6177 dances around the "cost" issue with this type of = language: - assigning a longer prefix to an end site, compared with the existing prefixes the end site already has assigned to it, is likely to increase operational costs and complexity for the end site, with insufficient benefit to anyone. In the homenet context, we could expound a bit on the "insufficient = benefit to anyone" case, suggesting that /64-only residential service = can lead to: - IPv6 not reaching all devices in the home, despite IPv6 being provided = by the ISP. (Clearly this should be something that an ISP does not want = to happen, or why else would it even have gone to the trouble to deliver = IPv6 in the first place?) - CPE employing NAT or other techniques that introduce complexity and = unpredictable behavior into the home network that could lead to service = calls and disruption, even if these mechanisms are not a part of any = IETF recommendation.=20 Finally, at the protocol level perhaps we should state that, by default, = DHCPv6 PD in a homenet-capable router always "hint" that it would like a = /48 prefix (as can be done today, but rarely is I believe) - i.e., the = CPE by default "asks" the ISP for the maximum, as clearly that is what = any CPE would like to have to work with if it actually knows how to = distribute /64s within the home network. Protocol-wise, this is only a = "hint" of course, the ISP can provide a /56, /60, or even /64 if it = wants. But why not go ahead and nail down that if you are a router that = actually knows how to handle a large prefix, mention that fact in the = initial protocol exchange. - Mark On Oct 3, 2012, at 8:48 PM, Jeff Bowden wrote: > Curtis, >=20 > I agree with your addition of that paragraph with the one exception of = removing the "at no additional cost" phrase. I agree it should be that = way but it is up to the individual ISP and not the IETF as to what = should and should not be charged for. >=20 > Yes, lets move on. >=20 > Best regards, > Jeff Bowden=09 >=20 >=20 >=20 > On 10/3/2012 12:36 PM, Curtis Villamizar wrote: >> In message <506BE6AE.5070708@globis.net> >> Ray Hunter writes: >> =20 >>> Why not just add RFC 6177 BCP 157 >>> http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in >>> draft-ietf-homenet-arch? >>> That's a lot shorter than re-hashing the whole discussion within = Homenet. >> Clearly some providers aren't getting it so repitition may help, but >> not repitition of the entire argument made in RFC6177. >>=20 >> For example: >>=20 >> This document obsoletes RFC 3177, updating its recommendations in = the >> following ways: >>=20 >> 1) It is no longer recommended that /128s be given out. While >> there may be some cases where assigning only a single = address >> may be justified, a site, by definition, implies multiple >> subnets and multiple devices. >>=20 >> One provider is doing a trial allocating /128 addresses and alegedly >> targeting this at *business service*. /64 later (no date). shorter >> prefixes still later (also no date). So either they are not reading >> RFC6177 or they are not getting it. >>=20 >> Wording which refers to RFC6177 would help. Adding the one sentence >> below to that would also help. How about: >>=20 >> If home networks are to avoid having to subdivide /64s, then >> consumer oriented service providers MUST allow customers to = easily >> request and get prefixes shorter than /64 and SHOULD provide = these >> shorter prefixes at no additional cost. Allocation of shorter >> prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. >>=20 >> If there is no objections we can end this part of the thread and move >> on to the rest of the suggested changes to the draft. >>=20 >>> Curtis Villamizar wrote: >>>> Now that we beat summary item #12 to death, can we please turn our >>>> attention to the remaining 18 summary items listed below and the = diffs >>>> to the draft? >>>>=20 >>>> btw- I think the concensus on summary item #12 is that maybe we can >>>> add the following points to the framework. Subnets longer than /64 >>>> are bad. Some devices don't support DHCPv6, therefore SLAAC is >>>> essential. Consumer oriented service providers of must allow >>>> customers to easily request and get prefixes shorter than /64 and >>>> preferably at no additional cost if we are to avoid having to >>>> subdivide /64s. >>>>=20 >>>> Curtis >> [ ... trim ... ] >>=20 >> I think your reply was just concerning the above paragraph so I >> trimmed the rest. >>=20 >> Curtis >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_83793F2E-6DF3-465B-BBB1-25A605AA048C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Also, RFC 6177 dances = around the "cost" issue with this type of = language:

      =
- assigning a longer prefix to an end site, compared with the
        existing prefixes the end site already has assigned to it, is
        likely to increase operational costs and complexity for the end
        site, with insufficient benefit to =
anyone.

In the homenet context, we could = expound a bit on the "insufficient benefit to anyone" case, suggesting = that /64-only residential service can lead = to:

- IPv6 not reaching all devices in the = home, despite IPv6 being provided by the ISP. (Clearly this should be = something that an ISP does not want to happen, or why else would it even = have gone to the trouble to deliver IPv6 in the first = place?)
- CPE employing NAT or other techniques that introduce = complexity and unpredictable behavior into the home network that could = lead to service calls and disruption, even if these mechanisms are not a = part of any IETF recommendation. 

Finally, = at the protocol level perhaps we should state that, by default, DHCPv6 = PD in a homenet-capable router always "hint" that it would like a /48 = prefix (as can be done today, but rarely is I believe) - i.e., the CPE = by default "asks" the ISP for the maximum, as clearly that is what any = CPE would like to have to work with if it actually knows how to = distribute /64s within the home network. Protocol-wise, this is only a = "hint" of course, the ISP can provide a /56, /60, or even /64 if it = wants. But why not go ahead and nail down that if you are a router that = actually knows how to handle a large prefix, mention that fact in the = initial protocol exchange.

- = Mark


On Oct 3, 2012, at = 8:48 PM, Jeff Bowden wrote:

Curtis,

I agree with your addition of that = paragraph with the one exception of removing the "at no additional cost" = phrase.  I agree it should be that way but it is up to the = individual ISP and not the IETF as to what should and should not be = charged for.

Yes, = lets move on.

Best regards,
Jeff Bowden =



On 10/3/2012 12:36 PM, Curtis Villamizar = wrote:
In message <506BE6AE.5070708@globis.net>
Ray Hunter = writes:
=  
Why not just add RFC 6177 BCP = 157
http://www.rfc-editor.or= g/bcp/bcp157.txt as a normative reference = in
draft-ietf-homenet-arch?
 That's a lot = shorter than re-hashing the whole discussion within = Homenet.
Clearly = some providers aren't getting it so repitition may help, = but
not repitition of the = entire argument made in RFC6177.

For = example:

=    This document obsoletes RFC 3177, updating its = recommendations in the
=    following ways:

=       1) It is no longer recommended that = /128s be given out.  While
=          there may be some = cases where assigning only a single address
         may = be justified, a site, by definition, implies = multiple
=          subnets and = multiple devices.

One provider is = doing a trial allocating /128 addresses and = alegedly
targeting this at = *business service*.  /64 later (no date). =  shorter
prefixes still = later (also no date).  So either they are not = reading
RFC6177 or they are = not getting it.

Wording which = refers to RFC6177 would help.  Adding the one = sentence
below to that would = also help.  How about:

=     If home networks are to avoid having to = subdivide /64s, then
=     consumer oriented service providers MUST allow = customers to easily
=     request and get prefixes shorter than /64 and = SHOULD provide these
=     shorter prefixes at no additional cost. =  Allocation of shorter
=     prefixes than /64 is recommended in RFC 6177 BCP = 157 [RFC6177].

If there is no = objections we can end this part of the thread and = move
on to the rest of the = suggested changes to the draft.

Curtis Villamizar = wrote:
Now that we beat summary item = #12 to death, can we please turn = our
attention to the remaining 18 summary items listed below = and the diffs
to the = draft?

btw- I = think the concensus on summary item #12 is that maybe we = can
add = the following points to the framework.  Subnets longer than = /64
are = bad.  Some devices don't support DHCPv6, therefore SLAAC = is
essential.  Consumer oriented service providers of = must allow
customers to easily request and get prefixes shorter than = /64 and
preferably at no additional cost if we are to avoid having = to
subdivide = /64s.

Curtis
[ ... trim ... ]

I think your = reply was just concerning the above paragraph so = I
trimmed the = rest.

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


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

= --Apple-Mail=_83793F2E-6DF3-465B-BBB1-25A605AA048C-- From curtis@occnc.com Wed Oct 3 13:00:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536CD21F8442 for ; Wed, 3 Oct 2012 13:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncKDJ2EE8RCq for ; Wed, 3 Oct 2012 13:00:41 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA921F8440 for ; Wed, 3 Oct 2012 13:00:41 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q93K0c9i077852; Wed, 3 Oct 2012 16:00:38 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210032000.q93K0c9i077852@gateway1.orleans.occnc.com> To: Jeff Bowden From: Curtis Villamizar In-reply-to: Your message of "Wed, 03 Oct 2012 13:48:59 CDT." <506C889B.4070709@centurylink.net> Date: Wed, 03 Oct 2012 16:00:38 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:00:42 -0000 In message <506C889B.4070709@centurylink.net> Jeff Bowden writes: > Curtis, > > I agree with your addition of that paragraph with the one exception of > removing the "at no additional cost" phrase. I agree it should be that > way but it is up to the individual ISP and not the IETF as to what > should and should not be charged for. > > Yes, lets move on. > > Best regards, > Jeff Bowden The "at no additional cost" phrase is consistent with RFC6177. See first paragraph in section 2 "2. On /48 Assignments to End Sites". Looking back at some of the original motivations behind the /48 recommendation [RFC3177], there were three main concerns. The first motivation was to ensure that end sites could easily obtain sufficient address space without having to "jump through hoops" to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification. As a comparison point, in IPv4, typical home users are given a single public IP address (though even this is not always assured), but getting any more than one address is often difficult or even impossible -- unless one is willing to pay a (significantly) increased fee for what is often considered to be a "higher grade" of service. (It should be noted that increased ISP charges to obtain a small number of additional addresses cannot usually be justified by the real per-address cost levied by RIRs, but additional addresses are frequently only available to end users as part of a different type or "higher grade" of service, for which an additional charge is levied. The point here is that the additional cost is not due to the RIR fee structures, but to business choices ISPs make.) An important goal in IPv6 is to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks" and to ensure that end sites can easily obtain address space. The phrase "SHOULD provide these shorter prefixes at no additional cost" is much shorter, more direct, and after all is only a "SHOULD". There is no justification to charge more for a shorter prefix than /64 other than providers tendency to charge for anything they can charge for even if there is no incremental cost to them. I think that phrase should stay. btw- At some prefix length (maybe shorter than /56 or /48) it is not unreasonable to expect some form of justification. After all, a /56 provides 256 subnets and a /48 provides 64K subnets and that is a lot of subnets for a home or soho or small business. Curtis > On 10/3/2012 12:36 PM, Curtis Villamizar wrote: > > In message <506BE6AE.5070708@globis.net> > > Ray Hunter writes: > > > >> Why not just add RFC 6177 BCP 157 > >> http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in > >> draft-ietf-homenet-arch? > >> > >> That's a lot shorter than re-hashing the whole discussion within Homenet. > > Clearly some providers aren't getting it so repitition may help, but > > not repitition of the entire argument made in RFC6177. > > > > For example: > > > > This document obsoletes RFC 3177, updating its recommendations in the > > following ways: > > > > 1) It is no longer recommended that /128s be given out. While > > there may be some cases where assigning only a single address > > may be justified, a site, by definition, implies multiple > > subnets and multiple devices. > > > > One provider is doing a trial allocating /128 addresses and alegedly > > targeting this at *business service*. /64 later (no date). shorter > > prefixes still later (also no date). So either they are not reading > > RFC6177 or they are not getting it. > > > > Wording which refers to RFC6177 would help. Adding the one sentence > > below to that would also help. How about: > > > > If home networks are to avoid having to subdivide /64s, then > > consumer oriented service providers MUST allow customers to easily > > request and get prefixes shorter than /64 and SHOULD provide these > > shorter prefixes at no additional cost. Allocation of shorter > > prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. > > > > If there is no objections we can end this part of the thread and move > > on to the rest of the suggested changes to the draft. > > > >> Curtis Villamizar wrote: > >>> Now that we beat summary item #12 to death, can we please turn our > >>> attention to the remaining 18 summary items listed below and the diffs > >>> to the draft? > >>> > >>> btw- I think the concensus on summary item #12 is that maybe we can > >>> add the following points to the framework. Subnets longer than /64 > >>> are bad. Some devices don't support DHCPv6, therefore SLAAC is > >>> essential. Consumer oriented service providers of must allow > >>> customers to easily request and get prefixes shorter than /64 and > >>> preferably at no additional cost if we are to avoid having to > >>> subdivide /64s. > >>> > >>> Curtis > > [ ... trim ... ] > > > > I think your reply was just concerning the above paragraph so I > > trimmed the rest. > > > > Curtis > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Wed Oct 3 14:21:00 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8787F21F8574 for ; Wed, 3 Oct 2012 14:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6JD7s2zkayH for ; Wed, 3 Oct 2012 14:20:59 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8271D21F8575 for ; Wed, 3 Oct 2012 14:20:59 -0700 (PDT) Received: by iado25 with SMTP id o25so1479306iad.31 for ; Wed, 03 Oct 2012 14:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EBf86CFxdwFbicD+9MnjMe6Zp9QVDYNaLcOSiL7Gjmc=; b=y+KtEcofz8T0fDeKhFlGkoPyrXqNymN5XKJgCgOAtZ39AYUETJhA4U9Vpf38Rqb2gh c1Mv20lhKp/EXPO0MXFvEdyHCRaz4IsdheDasEIxWUgW/Lupmb8MfJzdU2Pk7lwbmlj1 Z2NrHBmQ4H9DQp1gG8trm0pqABihU+jzLCsbArVzpJCFHCd1n7f1UIuonHPB89iaUWHS LKMoNc+CJmcjXDCwLnWaLi6iPc82FzB0iorCLVgFk3Aj3iNNzRZrJ7t08SDKRMqCe3Ah /Z0FU+HT93N9cQFhzb7gy46fUKYyAsmt7x4toK8n2HlPqWsj6FTNkA68mwzTSwIuNonn jYZQ== Received: by 10.50.10.166 with SMTP id j6mr3358725igb.13.1349299258802; Wed, 03 Oct 2012 14:20:58 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id uq6sm12027870igb.14.2012.10.03.14.20.57 (version=SSLv3 cipher=OTHER); Wed, 03 Oct 2012 14:20:58 -0700 (PDT) Message-ID: <506CAC3F.5060902@gmail.com> Date: Wed, 03 Oct 2012 22:21:03 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: <201210031736.q93HaKKx077003@gateway1.orleans.occnc.com> <506C889B.4070709@centurylink.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] fwd: draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:21:00 -0000 Top posting: while I agree with Mark's points, I think the shortest path to where we need this draft to go is to accept Curtis' text as is. Brian On 03/10/2012 20:35, Mark Townsley wrote: > What about taking section 5 (summary) of RFC 6177 as a guide and apply it to our specific case? I don't think we would conflict with any of the statements, but we could provide a bit more justification and direction than what is there for the homenet specifically. For example, the "operational considerations" for the site can be further refined to mean the automatic prefix distribution mechanisms running in the homenet router (as there is by definition no human operator of the network assigning prefixes, but an algorithm that we have designed). > > Also, RFC 6177 dances around the "cost" issue with this type of language: > > - assigning a longer prefix to an end site, compared with the > existing prefixes the end site already has assigned to it, is > likely to increase operational costs and complexity for the end > site, with insufficient benefit to anyone. > > In the homenet context, we could expound a bit on the "insufficient benefit to anyone" case, suggesting that /64-only residential service can lead to: > > - IPv6 not reaching all devices in the home, despite IPv6 being provided by the ISP. (Clearly this should be something that an ISP does not want to happen, or why else would it even have gone to the trouble to deliver IPv6 in the first place?) > - CPE employing NAT or other techniques that introduce complexity and unpredictable behavior into the home network that could lead to service calls and disruption, even if these mechanisms are not a part of any IETF recommendation. > > Finally, at the protocol level perhaps we should state that, by default, DHCPv6 PD in a homenet-capable router always "hint" that it would like a /48 prefix (as can be done today, but rarely is I believe) - i.e., the CPE by default "asks" the ISP for the maximum, as clearly that is what any CPE would like to have to work with if it actually knows how to distribute /64s within the home network. Protocol-wise, this is only a "hint" of course, the ISP can provide a /56, /60, or even /64 if it wants. But why not go ahead and nail down that if you are a router that actually knows how to handle a large prefix, mention that fact in the initial protocol exchange. > > - Mark > > > On Oct 3, 2012, at 8:48 PM, Jeff Bowden wrote: > >> Curtis, >> >> I agree with your addition of that paragraph with the one exception of removing the "at no additional cost" phrase. I agree it should be that way but it is up to the individual ISP and not the IETF as to what should and should not be charged for. >> >> Yes, lets move on. >> >> Best regards, >> Jeff Bowden >> >> >> >> On 10/3/2012 12:36 PM, Curtis Villamizar wrote: >>> In message <506BE6AE.5070708@globis.net> >>> Ray Hunter writes: >>> >>>> Why not just add RFC 6177 BCP 157 >>>> http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in >>>> draft-ietf-homenet-arch? >>>> That's a lot shorter than re-hashing the whole discussion within Homenet. >>> Clearly some providers aren't getting it so repitition may help, but >>> not repitition of the entire argument made in RFC6177. >>> >>> For example: >>> >>> This document obsoletes RFC 3177, updating its recommendations in the >>> following ways: >>> >>> 1) It is no longer recommended that /128s be given out. While >>> there may be some cases where assigning only a single address >>> may be justified, a site, by definition, implies multiple >>> subnets and multiple devices. >>> >>> One provider is doing a trial allocating /128 addresses and alegedly >>> targeting this at *business service*. /64 later (no date). shorter >>> prefixes still later (also no date). So either they are not reading >>> RFC6177 or they are not getting it. >>> >>> Wording which refers to RFC6177 would help. Adding the one sentence >>> below to that would also help. How about: >>> >>> If home networks are to avoid having to subdivide /64s, then >>> consumer oriented service providers MUST allow customers to easily >>> request and get prefixes shorter than /64 and SHOULD provide these >>> shorter prefixes at no additional cost. Allocation of shorter >>> prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. >>> >>> If there is no objections we can end this part of the thread and move >>> on to the rest of the suggested changes to the draft. >>> >>>> Curtis Villamizar wrote: >>>>> Now that we beat summary item #12 to death, can we please turn our >>>>> attention to the remaining 18 summary items listed below and the diffs >>>>> to the draft? >>>>> >>>>> btw- I think the concensus on summary item #12 is that maybe we can >>>>> add the following points to the framework. Subnets longer than /64 >>>>> are bad. Some devices don't support DHCPv6, therefore SLAAC is >>>>> essential. Consumer oriented service providers of must allow >>>>> customers to easily request and get prefixes shorter than /64 and >>>>> preferably at no additional cost if we are to avoid having to >>>>> subdivide /64s. >>>>> >>>>> Curtis >>> [ ... trim ... ] >>> >>> I think your reply was just concerning the above paragraph so I >>> trimmed the rest. >>> >>> Curtis >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > > ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Sat Oct 6 07:14:31 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF2721F8622 for ; Sat, 6 Oct 2012 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQlifjEGd240 for ; Sat, 6 Oct 2012 07:14:30 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86B21F8621 for ; Sat, 6 Oct 2012 07:14:30 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7057854iec.31 for ; Sat, 06 Oct 2012 07:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qhxxgdeJmmRstq019Nj6evzWTy8WnDKOo9IoPDYwDCA=; b=qSVMFFnNrL2kjOazm9Xy1gdMK+aN8eFiD2hctzKL4pQ59rfevjXzi73dPZbgxJcszo DbEcTCi8WtmlVVNddkJ1TX+6HXSzf35m91QguMZ7LrJOJjDMjn19z5a6MuxUIDTNZAcj cLs6sfEX+Lx5wRkio/Jd7yAUGN0+QjrUwadgBoYgjmLvyqO8zk5DNLeKA5w+oUFtTWPB XnodmuoEm/QtOGAKaXrC326eNrTgyoj+YaF6y3MRDqfrWFWeMwGGRtz0aR3MVf3fuCQh M2wLP/++cYcG57wyu82L45ADj3OtOKnqlBYdlXNn1Fzl5bxO2iFBJx5lYU/KRot9Jny0 R2YA== Received: by 10.50.202.73 with SMTP id kg9mr3798347igc.42.1349532869975; Sat, 06 Oct 2012 07:14:29 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id u4sm3167658igw.6.2012.10.06.07.14.29 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 07:14:29 -0700 (PDT) Message-ID: <50703CD2.2020708@gmail.com> Date: Sat, 06 Oct 2012 15:14:42 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet@ietf.org References: <20120925175537.27212.40311.idtracker@ietfa.amsl.com> <08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> In-Reply-To: <08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Fwd: I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 14:14:31 -0000 Well, I've decided that I simply don't understand the proposal. It doesn't discuss the addresses and prefixes involved. I suggest that you need to add that plus a description of "a day in the life of an application layer session" during a series of link failures and restorations. There seems to be a single point of failure - the MSP - but the point of multihoming is to get rid of single points of failure. Also, are you implying that session continuity is a requirement? In most homenet scenarios that I know of, a transport session reset is already a common event that applications (or users) need to recover from on a daily basis. It seems that the kind of connection manager that has been discussed in MIF would deal with this scenario (see for example draft-seite-mif-cm). Regards Brian Carpenter On 26/09/2012 18:26, Wassim Haddad wrote: > Dear all, > > We have submitted a problem statement for multihoming in homenet. > Comments appreciated! > > > Regards, > > Wassim H. > > > Begin forwarded message: > >> From: "internet-drafts@ietf.org" >> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt >> Date: September 25, 2012 10:55:38 AM PDT >> To: "i-d-announce@ietf.org" >> Reply-To: "internet-drafts@ietf.org" >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Multihoming in Homenet >> Author(s) : Wassim Haddad >> Damien Saucez >> Joel Halpern >> Filename : draft-haddad-homenet-multihomed-00.txt >> Pages : 7 >> Date : 2012-09-25 >> >> Abstract: >> So far, multihoming in Homenet must be supported by the hosts as >> there is no mean to use simultaneously the different Internet Service >> Providers of the "Homenet" without risking flow disruption. In this >> memo, we describe the problem statement for multihoming in Homenet. >> We also propose a high level solution that answers this particular >> problem. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00 > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From cheshire@apple.com Wed Oct 10 23:26:22 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFAD21F8666 for ; Wed, 10 Oct 2012 23:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcnGwKHqHAPm for ; Wed, 10 Oct 2012 23:26:22 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id C418521F860D for ; Wed, 10 Oct 2012 23:26:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MBP00IVMTUI2D73@mail-out.apple.com> for homenet@ietf.org; Wed, 10 Oct 2012 23:25:42 -0700 (PDT) X-AuditID: 11807137-b7fa46d000006f75-57-50766666c7f4 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id CC.58.28533.66666705; Wed, 10 Oct 2012 23:25:42 -0700 (PDT) Received: from [10.143.192.103] (unknown [217.39.5.120]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MBP009I7TUSAE40@kencur.apple.com> for homenet@ietf.org; Wed, 10 Oct 2012 23:25:42 -0700 (PDT) From: Stuart Cheshire Date: Wed, 10 Oct 2012 23:25:40 -0700 References: To: homenet@ietf.org Message-id: <4D671EC0-533F-4C92-8C99-028EAAE815B5@apple.com> X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42IRnG6nppuWVhZgMLPHwOL9okMsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOPdjFWPBAoWKz/tbmRsYN0l1MXJySAiYSEx5tZAVwhaTuHBv PVsXIxeHkEA7k8TZhfvZIZx5TBIfH55kB6liE9CSePH5ChuIzQxkr995nAnC1pZ48u4C2CRh AUuJ9TtamEFsFgFViYnn2sDiQgI2Ev8fXWDpYuTgEBEQkWieHgoS5gUKtxztZYOwDSWWXN/C DnGQrMTOO6dZJjDyzUKybRaSbbOQtCxgZF7FKFiUmpNYaWiml1hQkJOql5yfu4kRFEoNheY7 GLf/lTvEKMDBqMTD+2J1aYAQa2JZcWXuIUYJDmYlEd7ZSWUBQrwpiZVVqUX58UWlOanFhxil OViUxHmDl5cECAmkJ5akZqemFqQWwWSZODilGhhdFy7h+bn1eZei/AXvV/ty3UQOLnUUjjjV /9f3W8q/7Wpn73C8yj0hMCf8/K7T18qrEnXXpNZrJx/ea3rMqaT1jO1T8//z2/c2HH52/Fen 5Y7yugtTjqlbq8lcyT9T2TJjPVODVvX9ao3VB2KWvY550HqQOfLI7XeLNvJNfC7qyC+bepd3 vXSvEktxRqKhFnNRcSIA/ovwtyECAAA= Subject: [homenet] Fwd: New mailing list for DNS-SD/mDNS Extensions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 06:26:23 -0000 Of possible interest to the homenet community, I think: > From: Stuart Cheshire > Date: 10 October 2012 15:53:30 PDT > To: IETF Discussion > Subject: New mailing list for DNS-SD/mDNS Extensions > list-id: IETF-Discussion > > A new IETF mailing list has been created for discussions regarding DNS-SD/mDNS Extensions: > > > > This is in response to recent events in the industry and marketplace. > > In August, EDUCAUSE delivered a petition to Apple asking for improvements to Bonjour (aka DNS-SD/mDNS) to allow discovery of services beyond the local link. > > > > > > In principle DNS-SD can already be used in conjunction with conventional unicast DNS to enable wide-area service discovery, but in practice this capability is not widely used. This disconnect between customer needs and current practice suggests that we need to revisit how to solve this problem. > > In response to this customer demand, Aerohive, Aruba, Cisco, and Xirrus have all recently announced "Bonjour gateway" products which allow service discovery beyond the local link. However, these were brought to market rapidly, and it's unclear whether they represent a desirable long-term direction for service discovery protocol development. Other companies are also reported to be developing their own "Bonjour gateway" products, not yet announced. > > It would be beneficial for the end users, network operators, these vendors, and for the long-term health of the Internet to bring this work into the IETF where all interested parties can collaborate on it. > > Proposed Scope of Work: > > The MDNSEXT mailing list discussions will focus on service discovery solutions suitable for: > > 1. Enterprise networks > 2. Academic/Educational/University networks > 3. Multi-link home networks, such as that envisaged by HOMENET* > 4. Mesh networks, such as SE2.0/ZigBee/6lowpan-style networks > > * It is hoped that MDNSEXT can develop a solution that is suitable for all four network environments, including the HOMENET case. Of course the HOMENET WG is free to evalulate for itself whether it wishes to adopt the MDNSEXT solution, or develop something different. > > Proposed Goals: > > 1. Enable discovery of services across multiple links. > > 2. Zero configuration operation possible, but not mandatory. > - i.e. Zero configuration operation is supported by the protocols, > but administrative control is also available on networks where that > is desired. > > 3. Scalability, in terms of: > - Network traffic > - CPU and memory requirements on network entities > - User interface (huge flat list is not user friendly) > - Having a smooth continuum of operation from local link to site to > global, rather than wildly different incompatible modes of > operation at different network scales > - Granularity of services available on a server (extend the notion of service?) > > 4. Suitable for both local (zero-config) and global (configured) use > - i.e. Suitable out-of-the box defaults should enable zero- > configuration use on many small- to medium-sized networks, while still > allowing for administrative control in networks where that's desired. > > 5. Incremental deployability > - Identify what changes to existing network elements will be > required, and attempt to minimize those changes. > - Don't break existing DNS-SD/mDNS functionality and devices > > A BoF session is tentatively planned for 1520-1650 Tuesday 6th November 2012, subject there being enough interest to warrant moving ahead to that stage. > > Stuart Cheshire From tjc@ecs.soton.ac.uk Thu Oct 11 02:37:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A8721F8723 for ; Thu, 11 Oct 2012 02:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOnMveKx6Rw4 for ; Thu, 11 Oct 2012 02:37:24 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E168321F870A for ; Thu, 11 Oct 2012 02:37:23 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9B9bJLs023680 for ; Thu, 11 Oct 2012 10:37:21 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9B9bJLs023680 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1349948241; bh=ePL4OPzwrlwEg+LjWL71nLz29aM=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=xlXHqpCL0/zOwgrMnZvqsqpmmHumlYmZaiOTP9/RqLGHmN6r/IXAqDoFfqD+6Yd8D f8q7wkl74+8cz5iRWIp/yzo2uhT6S59aD5nn38vWsmbnxTi37mmpWlIbnmk6NFs2Q3 qXcJPOP8Zx5mkGjJYQuY+HMXeRYSeR+94k45SHWs= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9AAbJ04306622656s ret-id none; Thu, 11 Oct 2012 10:37:21 +0100 Received: from ip-205-010.eduroam.soton.ac.uk (ip-205-010.eduroam.soton.ac.uk [152.78.205.10]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9B9bJvq018711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Oct 2012 10:37:19 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <506A07D1.8050605@gmail.com> Date: Thu, 11 Oct 2012 10:37:20 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9AAbJ043066226500; tid=o9AAbJ04306622656s; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9B9bJLs023680 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:37:24 -0000 On 1 Oct 2012, at 22:14, Brian E Carpenter = wrote: > As far as I can tell, multihoming is not mentioned in the homenet = charter, > but it is discussed in draft-ietf-homenet-arch, without a clear = conclusion. > There is an argument for a specific analysis document on this topic, = before > we discuss our favourite solutions. A homenet arch -05 is about to be published. As Brian says, there is a brief section in the arch text about = multihoming, which we believe captures all that needs to be said. The = section tries to describe the architectural implications of different = approaches in the context of the architecture goals. For example, = nothing in the architecture should preclude use of shim6, if the hosts = support it. If people have specific comments on 3.2.4 where this is contained, = please make them and we can consider those. Tim= From tjc@ecs.soton.ac.uk Thu Oct 11 04:09:30 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429A421F86D3 for ; Thu, 11 Oct 2012 04:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPNPQV-7mJkj for ; Thu, 11 Oct 2012 04:09:28 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D876B21F8686 for ; Thu, 11 Oct 2012 04:09:27 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BB9PIi013711 for ; Thu, 11 Oct 2012 12:09:25 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9BB9PIi013711 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1349953765; bh=q2dwcrAdc3+tueB+ZTLmFtkf7I4=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=OFhx1n6/pm+kqCcNARCbY47i9uNxA/6ssaql59zbAmyyiimAeoiRL8nBo7kzy+OuB V+I4oZ/t30QYjFjhfAdTGQQ41g+ODWn6Vf3RrNbYcd9PERbzyS0yrq8LD1AceFTotf dHIORV+ia2NgQ27x5Zu71KoWE6+++Y8BFpWFkuak= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9AC9P0430663265Va ret-id none; Thu, 11 Oct 2012 12:09:25 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BB9PGM007521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Oct 2012 12:09:25 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: Date: Thu, 11 Oct 2012 12:09:25 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201209302333.q8UNXOR7029594@gateway1.orleans.occnc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9AC9P043066326500; tid=o9AC9P0430663265Va; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9BB9PIi013711 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:09:30 -0000 On 1 Oct 2012, at 13:59, RJ Atkinson wrote: >> Consumer oriented providers handing out /64s >> to home nets is also bad. >=20 > Agreed (s/consumer-oriented/any/).=20 >=20 > HomeNet WG ought to be VERY clear about this. >=20 > HomeNet WG ALSO ought NOT "enable" or "encourage"=20 > such behaviour by encouraging ANY scenarios=20 > where SLAAC can't work properly. There is clear consensus in this thread that homenet must support SLAAC = and DHCPv6, and thus the architecture text should reinforce the comments = that Ran has made. The residential deployments I am aware of in Europe all support at least = /60 and up to /48. The most common is probably /56. We should not add = complexity to homenet scenarios and break SLAAC to account for ISPs that = might currently only offer a /64. =20 There have been recent discussions elsewhere I believe on limitations of = prefix delegation in certain types of mobile networks where only a /64 = is offered currently, but those one would hope are temporary until = DHCPv6-PD is supported there. Curtis can of course take proposals to 6man for discussion, but the = architecture text here would not include those. Tim= From tjc@ecs.soton.ac.uk Thu Oct 11 04:21:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283DD21F86D0 for ; Thu, 11 Oct 2012 04:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwFRiOkG35kV for ; Thu, 11 Oct 2012 04:21:38 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 605B221F865B for ; Thu, 11 Oct 2012 04:21:37 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BBLQm6016618 for ; Thu, 11 Oct 2012 12:21:26 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9BBLQm6016618 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1349954486; bh=W6/eOU1dL86DTYtJjJmaliVkfao=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=tyE4HVLVXCIu88QWnpUzDV29s2oBTCJy0NYRmNsfeBmYneKXeORaGwPputLDJAMFq VQGYVUKcuXkADS7fpdlxzWbtBkeGItref9yYm1ufAE7Xu6sDFlKa8QgbA8asXja++I JiQ9e4050iiw7XrQynFgpvPsh0FHgKYZA4ytLUQI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9ACLQ0430663407pX ret-id none; Thu, 11 Oct 2012 12:21:26 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BBLQol010121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Oct 2012 12:21:26 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <506CAC3F.5060902@gmail.com> Date: Thu, 11 Oct 2012 12:21:25 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210031736.q93HaKKx077003@gateway1.orleans.occnc.com> <506C889B.4070709@centurylink.net> <506CAC3F.5060902@gmail.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9ACLQ043066340700; tid=o9ACLQ0430663407pX; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9BBLQm6016618 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:21:40 -0000 On 3 Oct 2012, at 22:21, Brian E Carpenter = wrote: > Top posting: while I agree with Mark's points, I think the shortest > path to where we need this draft to go is to accept Curtis' text as = is. The text has been tweaked in 3.4.1 to incorporate Mark's suggestions. Everything else we need is stated in RFC6177, which is cited in that = section already. Tim > On 03/10/2012 20:35, Mark Townsley wrote: >> What about taking section 5 (summary) of RFC 6177 as a guide and = apply it to our specific case? I don't think we would conflict with any = of the statements, but we could provide a bit more justification and = direction than what is there for the homenet specifically. For example, = the "operational considerations" for the site can be further refined to = mean the automatic prefix distribution mechanisms running in the homenet = router (as there is by definition no human operator of the network = assigning prefixes, but an algorithm that we have designed). =20 >>=20 >> Also, RFC 6177 dances around the "cost" issue with this type of = language: >>=20 >> - assigning a longer prefix to an end site, compared with the >> existing prefixes the end site already has assigned to it, is >> likely to increase operational costs and complexity for the = end >> site, with insufficient benefit to anyone. >>=20 >> In the homenet context, we could expound a bit on the "insufficient = benefit to anyone" case, suggesting that /64-only residential service = can lead to: >>=20 >> - IPv6 not reaching all devices in the home, despite IPv6 being = provided by the ISP. (Clearly this should be something that an ISP does = not want to happen, or why else would it even have gone to the trouble = to deliver IPv6 in the first place?) >> - CPE employing NAT or other techniques that introduce complexity and = unpredictable behavior into the home network that could lead to service = calls and disruption, even if these mechanisms are not a part of any = IETF recommendation.=20 >>=20 >> Finally, at the protocol level perhaps we should state that, by = default, DHCPv6 PD in a homenet-capable router always "hint" that it = would like a /48 prefix (as can be done today, but rarely is I believe) = - i.e., the CPE by default "asks" the ISP for the maximum, as clearly = that is what any CPE would like to have to work with if it actually = knows how to distribute /64s within the home network. Protocol-wise, = this is only a "hint" of course, the ISP can provide a /56, /60, or even = /64 if it wants. But why not go ahead and nail down that if you are a = router that actually knows how to handle a large prefix, mention that = fact in the initial protocol exchange. >>=20 >> - Mark >>=20 >>=20 >> On Oct 3, 2012, at 8:48 PM, Jeff Bowden wrote: >>=20 >>> Curtis, >>>=20 >>> I agree with your addition of that paragraph with the one exception = of removing the "at no additional cost" phrase. I agree it should be = that way but it is up to the individual ISP and not the IETF as to what = should and should not be charged for. >>>=20 >>> Yes, lets move on. >>>=20 >>> Best regards, >>> Jeff Bowden=09 >>>=20 >>>=20 >>>=20 >>> On 10/3/2012 12:36 PM, Curtis Villamizar wrote: >>>> In message <506BE6AE.5070708@globis.net> >>>> Ray Hunter writes: >>>>=20 >>>>> Why not just add RFC 6177 BCP 157 >>>>> http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference = in >>>>> draft-ietf-homenet-arch? >>>>> That's a lot shorter than re-hashing the whole discussion within = Homenet. >>>> Clearly some providers aren't getting it so repitition may help, = but >>>> not repitition of the entire argument made in RFC6177. >>>>=20 >>>> For example: >>>>=20 >>>> This document obsoletes RFC 3177, updating its recommendations in = the >>>> following ways: >>>>=20 >>>> 1) It is no longer recommended that /128s be given out. While >>>> there may be some cases where assigning only a single = address >>>> may be justified, a site, by definition, implies multiple >>>> subnets and multiple devices. >>>>=20 >>>> One provider is doing a trial allocating /128 addresses and = alegedly >>>> targeting this at *business service*. /64 later (no date). = shorter >>>> prefixes still later (also no date). So either they are not = reading >>>> RFC6177 or they are not getting it. >>>>=20 >>>> Wording which refers to RFC6177 would help. Adding the one = sentence >>>> below to that would also help. How about: >>>>=20 >>>> If home networks are to avoid having to subdivide /64s, then >>>> consumer oriented service providers MUST allow customers to = easily >>>> request and get prefixes shorter than /64 and SHOULD provide = these >>>> shorter prefixes at no additional cost. Allocation of shorter >>>> prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. >>>>=20 >>>> If there is no objections we can end this part of the thread and = move >>>> on to the rest of the suggested changes to the draft. >>>>=20 >>>>> Curtis Villamizar wrote: >>>>>> Now that we beat summary item #12 to death, can we please turn = our >>>>>> attention to the remaining 18 summary items listed below and the = diffs >>>>>> to the draft? >>>>>>=20 >>>>>> btw- I think the concensus on summary item #12 is that maybe we = can >>>>>> add the following points to the framework. Subnets longer than = /64 >>>>>> are bad. Some devices don't support DHCPv6, therefore SLAAC is >>>>>> essential. Consumer oriented service providers of must allow >>>>>> customers to easily request and get prefixes shorter than /64 and >>>>>> preferably at no additional cost if we are to avoid having to >>>>>> subdivide /64s. >>>>>>=20 >>>>>> Curtis >>>> [ ... trim ... ] >>>>=20 >>>> I think your reply was just concerning the above paragraph so I >>>> trimmed the rest. >>>>=20 >>>> Curtis >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Thu Oct 11 04:24:12 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849E321F865B for ; Thu, 11 Oct 2012 04:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRfkVLpijL7D for ; Thu, 11 Oct 2012 04:24:11 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 9A82E21F8623 for ; Thu, 11 Oct 2012 04:24:11 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BBO69W017301 for ; Thu, 11 Oct 2012 12:24:06 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9BBO69W017301 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1349954646; bh=5TrsIUIUJLzKaG9fTboXQB1Ey3w=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=P9c9zXYekm3qoaR5XHcTU4wt9Gz1hGCofTqRLXC7Sypx0pz/IOjbujSso9klLkvUw P2L5I0Ti5+0eeqoWA25tOB5o7sMy42bJNK19hT0AED0Ey13SlS8r2xO3t/tEXTPo5C rFbOYAORejLvD0PRMpnxefUDQHdKl+VVCMm5lGZQ= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9ACO60430663447hq ret-id none; Thu, 11 Oct 2012 12:24:06 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BBO6AP010840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Oct 2012 12:24:06 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> Date: Thu, 11 Oct 2012 12:24:06 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9ACO6043066344700; tid=o9ACO60430663447hq; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9BBO69W017301 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] Border Router Discovery Protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:24:12 -0000 On 26 Sep 2012, at 15:35, RJ Atkinson wrote: > On Tuesday, 25 September 2012, Teco Boot wrote: >> It might be the right moment to come up with my earlier work=20 >> on border router discovery. I have to update to incorporate=20 >> the homenet-arch, and remove details for MANET/Autoconf.=20 >>=20 >> Intro & highlights: >> http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt >>=20 >> If there is interest, I'll resubmit for Homenet.=20 >>=20 >> Teco >=20 > Yes, please. =20 >=20 > Please don't remove the details for MANET/AutoConf, > but perhaps put those details into their own section(s).=20 >=20 > The operational reality is that the IETF needs more tools > for automatic configuration, zero or minimal configuration, > site resilience in the face of upstream link changes, > and also site renumbering. >=20 > A well designed tool for border router discovery ought > to work well in MANET environments, AutoConf environments, > ZeroConf environments, HomeNet environments, and probably > also for renumbering events. I think BRDP is very close > to what is needed. I would not want to lose generality > of solution merely because it is being discussed in one > particular IETF WG at the moment. >=20 > Cheers, >=20 > Ran >=20 > PS: I'd also be quite happy to see BRDP go out as an > Experimental status RFC initially, whether through > the IETF track, IRTF Routing RG, or the ISE-track. > BRDP seems very useful and useful protocols tend > to self-deploy into environments where they are useful. We also have Eric Kline's draft in similar space: = draft-kline-default-perimeter-00. Both can hopefully contribute to the solution for this problem space in = homenet. Tim= From ot@cisco.com Thu Oct 11 04:50:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234221F862A for ; Thu, 11 Oct 2012 04:50:27 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpihs7F15yXp for ; Thu, 11 Oct 2012 04:50:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C746321F8625 for ; Thu, 11 Oct 2012 04:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=762; q=dns/txt; s=iport; t=1349956226; x=1351165826; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aQJtePVoZf3MEc14xS4aI1Gz8vRVR2WdYpZkUq5DavU=; b=JPO2kwfWenjmsneXUNK+TNYqu5Yh8hMXRLU/jKg6Ex0vL1Od/Z2eIzES ZnF7YLAxVjWwLOs6rnqRv/loivw9s0SoHVxMa1PqNwVl/sujFvi5BqBry dP+Q07Kv6WkSCHFdaG1VMPaoRSiVqBXMopddu/4L3qfZNQj8Kt9w82bSv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGKxdlCQ/khM/2dsb2JhbABEDr83gQiCIAEBAQMBEgEnPxALDjhXBi4Hh1wGmSqgGpEHYAOVbY5FgWuCMj0 X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="77389167" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 11 Oct 2012 11:50:25 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9BBoOcg014489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Oct 2012 11:50:25 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 11 Oct 2012 13:50:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51059699-AA09-4C04-A7CB-2DCACA5587BA@cisco.com> References: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> To: Tim Chown X-Mailer: Apple Mail (2.1498) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Border Router Discovery Protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:50:27 -0000 >> PS: I'd also be quite happy to see BRDP go out as an >> Experimental status RFC initially, whether through >> the IETF track, IRTF Routing RG, or the ISE-track. >> BRDP seems very useful and useful protocols tend >> to self-deploy into environments where they are useful. >=20 > We also have Eric Kline's draft in similar space: = draft-kline-default-perimeter-00. >=20 > Both can hopefully contribute to the solution for this problem space = in homenet. I have read the BRDP framework document, but I failed to understand how = BRDP solves the problem of how a border is discovered. it explains well how to act when a border has been established, but I = don't understand how BRDP helps getting to that point. pointers? cheers, Ole From brian.e.carpenter@gmail.com Thu Oct 11 05:22:07 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C6721F8619 for ; Thu, 11 Oct 2012 05:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.653 X-Spam-Level: X-Spam-Status: No, score=-101.653 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sS6TP1SU7FOl for ; Thu, 11 Oct 2012 05:22:06 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1B721F853A for ; Thu, 11 Oct 2012 05:22:05 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so921637bkc.31 for ; Thu, 11 Oct 2012 05:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UNypzOKR4GkDnX0aVkP7KYaa5eHjAq5Y2WD+pZP4PgI=; b=TexjwV624cXJGL5zWg2yhIEzF9riHUGihCflb5NLdMSCHnV86NOkr5gtZOjjgkf+ef bFxyN++cCTUiOhzomHN82YIwvwr7zxKFid0elL8UoL0yboGmwAjzq8sS7N8Q3IanDLht TJ8EN26eAvNidp8X4ZMGRI4lTNM3nQmIEvyvbiazs94vVws/OBOg/9bfQIso0Yu9vMFc MvaHmSyUJIeM3d5IPpFuk3/V5UDKhe2tIbpH4Gvtw3LGrJwReCLoqIuRNkc3OWW/l6Pv HWQ8WxkeGI014ZQ8YGoq9t1u9wzZ0X6rYrQYmmGZpTL+k+qVfyECZl2dr3b8mjJ4dAiq GtYQ== Received: by 10.204.146.19 with SMTP id f19mr262597bkv.4.1349958124580; Thu, 11 Oct 2012 05:22:04 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-30.as13285.net. [2.102.217.30]) by mx.google.com with ESMTPS id z22sm3476261bkw.2.2012.10.11.05.22.01 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 05:22:02 -0700 (PDT) Message-ID: <5076B9F1.4070503@gmail.com> Date: Thu, 11 Oct 2012 13:22:09 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <201209302333.q8UNXOR7029594@gateway1.orleans.occnc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:22:07 -0000 On 11/10/2012 12:09, Tim Chown wrote: > On 1 Oct 2012, at 13:59, RJ Atkinson wrote: > >>> Consumer oriented providers handing out /64s >>> to home nets is also bad. >> Agreed (s/consumer-oriented/any/). >> >> HomeNet WG ought to be VERY clear about this. >> >> HomeNet WG ALSO ought NOT "enable" or "encourage" >> such behaviour by encouraging ANY scenarios >> where SLAAC can't work properly. > > > There is clear consensus in this thread that homenet must support SLAAC and DHCPv6, and thus the architecture text should reinforce the comments that Ran has made. > > The residential deployments I am aware of in Europe all support at least /60 and up to /48. The most common is probably /56. We should not add complexity to homenet scenarios and break SLAAC to account for ISPs that might currently only offer a /64. +1. We are supposed to be specifying the future, not the past. Brian > There have been recent discussions elsewhere I believe on limitations of prefix delegation in certain types of mobile networks where only a /64 is offered currently, but those one would hope are temporary until DHCPv6-PD is supported there. > > Curtis can of course take proposals to 6man for discussion, but the architecture text here would not include those. > > Tim > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From brian.e.carpenter@gmail.com Thu Oct 11 05:37:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B48721F8742 for ; Thu, 11 Oct 2012 05:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.654 X-Spam-Level: X-Spam-Status: No, score=-101.654 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aP5TMX+7aMP for ; Thu, 11 Oct 2012 05:37:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91AB321F872A for ; Thu, 11 Oct 2012 05:37:40 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so931743bkc.31 for ; Thu, 11 Oct 2012 05:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Guq2A67SuNDGIAT6t0ad/taMwg9P9KsGQTGZHakCoO8=; b=a4+eY2w6JMH5qx17h7ksQGd6/I4Q7GFQCgXUQJyuSGl+R9+icL6iUuONVumGE72vs5 Kri8Im+lh5glIVbWy9BhVFRWpI7M3bgLMPM6f/9MuY6nPLx07T+27VYszVB0aaMc2rTG Cdr+DlhsmmGQcr1dpWibJmNVOpdOIntd7sVpax0b9dy5nb2xi1n8NBqJh+s+R1Oys101 mr3PXGJBdiXuoyaCQZJPhQ2Ntz8+igkc2Qqo/fcZaotfaZ3LkyiKLRghvXeSvsys7CAY uEo6ht7wTpjxbT5OJNZ/BPJgkeITCEC0YOPsRIwTR9Gdml1qXAQ7oREfN/3jZeZL1B4m tRkw== Received: by 10.204.0.71 with SMTP id 7mr251243bka.102.1349959058997; Thu, 11 Oct 2012 05:37:38 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-30.as13285.net. [2.102.217.30]) by mx.google.com with ESMTPS id gy18sm3527194bkc.4.2012.10.11.05.37.29 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 05:37:30 -0700 (PDT) Message-ID: <5076BD91.9020803@gmail.com> Date: Thu, 11 Oct 2012 13:37:37 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: [homenet] homenet-arch-04 [was draft-haddad-homenet-multihomed-00] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:37:41 -0000 On 11/10/2012 10:37, Tim Chown wrote: > On 1 Oct 2012, at 22:14, Brian E Carpenter wrote: > >> As far as I can tell, multihoming is not mentioned in the homenet charter, >> but it is discussed in draft-ietf-homenet-arch, without a clear conclusion. >> There is an argument for a specific analysis document on this topic, before >> we discuss our favourite solutions. > > A homenet arch -05 is about to be published. > > As Brian says, there is a brief section in the arch text about multihoming, which we believe captures all that needs to be said. The section tries to describe the architectural implications of different approaches in the context of the architecture goals. For example, nothing in the architecture should preclude use of shim6, if the hosts support it. > > If people have specific comments on 3.2.4 where this is contained, please make them and we can consider those. " Host-based methods such as Shim6 [RFC5533] have been defined, but of course require support in the hosts." Perhaps you should mention MPTCP here too. My concern about the whole section is that it leaves things open; it would be better if the architecture could suggest an immediately available solution, as well as leaving open alternative solutions for the future. I think that draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat is the closest thing we have to an immediately available solution, and it's in the RFC Editor queue. Nit: your reference to this I-D in homenet-arch-04 is broken. Brian From tjc@ecs.soton.ac.uk Thu Oct 11 07:22:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1747821F8554 for ; Thu, 11 Oct 2012 07:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_31=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 Orc7h4G3Kkxa for ; Thu, 11 Oct 2012 07:22:08 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id CECCB21F8552 for ; Thu, 11 Oct 2012 07:22:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BEM3d0032408 for ; Thu, 11 Oct 2012 15:22:05 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9BEM3d0032408 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1349965326; bh=lOnO/xJowT3iDglXJMW2F2lqDMk=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=zYZZgOqUVyxblZbCXuwMEonzEmz94N758Yv79i2FzZkx0jF6SHjcwoyHQdmmFIwq+ 7CSDbLSYqQ7EXBBEc5ihODxtFTbeTWN+xBR8aZnP8RZbyBrk47tTQtOLflV1RjRXvT SGA9gP3c40O7mjPdWzJLZfGExakl+vCkMxIfzZK0= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9AFM30430600494OQ ret-id none; Thu, 11 Oct 2012 15:22:05 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BEM3K6018849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Oct 2012 15:22:03 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <201210022154.q92LsG1P069291@gateway1.orleans.occnc.com> Date: Thu, 11 Oct 2012 15:22:02 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210022154.q92LsG1P069291@gateway1.orleans.occnc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9AFM3043060049400; tid=o9AFM30430600494OQ; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9BEM3d0032408 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:22:11 -0000 On 2 Oct 2012, at 22:54, Curtis Villamizar wrote: > Now that we beat summary item #12 to death, can we please turn our > attention to the remaining 18 summary items listed below and the diffs > to the draft? Hi Curtis,=20 Many thanks for these suggestions. =20 Comments in line. > The diffs are below. Hopefully we can all read unified diffs of an > xml file. I'll also summarize some major points here. >=20 > 1. Must be capable of self configuring but should allow manual > config. That was already in there, but have added your edit to the intro. > 2. A few citations could stand to be removed. Some drafts are > expired and don't look like they were entirely completed. Some > of the expired drafts look good but just managed to expire. We'll remove some of these. This was also suggested in Vancouver. = Final judgements can be made as we approach WGLC, but I expect a bigger = cull then if those documents are still expired with little sign of = further work on them. For now they may help inform the discussion. > 3. I am proposing that we drop the "well known name" as a means to > discover the border(s). This seems to me like a real bad idea. Done. > 4. In "Global addressability and elimination of NAT" > (false-)security concerns about losing NAT are cited but no > advantage to global addressability is cited. I think that is an > oversight but didn't add text here. (yet) Some advantages have been listed. Some more text has been added. I = don't think we need to convince on the benefits of IPv6. > 5. In a few places I've pointed out that firewalls (and NAT and > anti-virus) provide very ineffective security and we should be > very up front about saying so, though we can acknowledge that in > the absense of reasonably secure home products, we can't get rid > of them just yet. Indeed. > 6. Proposals for IPv6-only MUST provide some accommodations for > legacy IPv4 only hosts or plain vanilla DS hosts. I called this > IPv4 fallback on an otherwise IPv6 only network. I split the > bullet on NAT64/DNS64 into two. Fair enough, but that's not the focus here, and I've made that clear. I haven't added information about IPv4 fallback, as that's not a focus = of this text. > 7. If some topology can casue things to be broken, then what the > homenet WG specified is broken. Added some text on pathelogical > cases. The only true pathological case is a loop in a set of > repeaters if a routing protocol is used and switches either > detect cycles or use IEEE spanning tree or link state protocols. We have said that as far as possible the architecture should support = arbitrary topologies. Your paragraph is added. > 8. Cascading NATs are common. Added text as to why. This is already included in two places, so added a pointer. We're = trying to de-duplicate text where possible. > 9. Questioned why we mention VLANs. An unsophisticated home user > is not likely to be playing with VLANs. Note added. > 10. Should we get rid of physical standard references? I think so. That was a 'plug' for Jari's draft. Now removed. I suggest you send = your specific comments on that to him :) > 11. Modified "bridge whenever possible" text. Also "Largest > possible subnets" section title changed to "Largest practical > subnets" for reasons given in comments. That's a better choice of word, agreed. > 12. This is sure to be controversial. I pointed out that using > subnets longer than /64 is OK as long as they are not leaked > into global routing. Please read the text and changes before > exploding on this topic. It may be necessary to subnet a /64 if > that is all a provider will give you and you need subnets. It > does work and it is no more unnatural than subnetting a class-A > network would be in 1990. It means using DHCPv6 and not using > RA prefixes for GUA (otherwise SLAAC implementations would > likely try to use the whole bottom 64). Not included (see other email). > 13. There are a few minor wording changes, minor clarifications, > etc. Thanks - many included, some re-reworded :) I have also left "loops" in, rather than "cycles" - I hope you don't = mind. > 14. There may be more fuss about confining interior routing within > a border than needed. I added a paragraph that might help (or > might not). I think your comment about carrying extra information in OSPFv3 has at = least in part been followed in Jari's work, for example. > 15. In the security section I added a subsection named "Marginal > Effectiveness of NAT and Firewalls". (btw- Firewall horror > story at bar BOF on request.) Your soapbox is added, in brief! > 16. Added "It has been suggested that Dynamic DNS could be made to > operate in a zero-configuration mode using a locally significant > root domain and with minimal configuration or using a DHCPv6 > based (details to-be-defined) means of automated delegation > populate a global DNS zone." Maybe a draft is needed on this > but for now please discuss on list. Added. > 17. Suggest that any mechanism that is subnet-only has to be > extended to site *or abandoned by the WG* rather than proxied. > Old text said extended but not proxied (sic). Proxying is still in scope; I don't think we can rule that in our out as = yet, bearing in mind we'd like a solution that works with existing = hosts. But see the new mdnsext BoF and mail list and push thoughts = there... > 18. Updated references (one draft is now RFC, one individual draft > is now WG draft, noted those that are expired). Noted. > 19. Question on "ISPs renumber due to privacy laws". What's that > all about? Germany, I believe. Also note that some other big ISPs have stated they = don't plan to give long-term static IPv6 prefixes to residential = customers. Many thanks, Tim > Curtis >=20 >=20 > BTW- The file still compiles and I made some updates to the references > section which means the entity defines up front are edited. I'm quite > sure you'll want to pick and choose diffs or hand edit the changes you > want back in. Hopefully you'll want something. :) >=20 >=20 >=20 > - --- draft-ietf-homenet-arch-04.xml.orig 2012-07-16 = 10:00:38.000000000 -0400 > +++ draft-ietf-homenet-arch-04.xml 2012-09-22 22:06:24.000000000 = -0400 > @@ -4,13 +4,17 @@ >=20 > > > + > > + > > + > > > > > > + > > > > @@ -52,8 +56,8 @@ > PUBLIC '' = 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc348= 4bis.xml'> >=20 > - - - - PUBLIC '' = 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.v6ops-multihomin= g-without-ipv6nat.xml'> > + + PUBLIC '' = 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-= multihoming-without-ipv6nat.xml'> >=20 > PUBLIC '' = 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-homenet-pr= efix-assignment.xml'> > @@ -202,8 +206,9 @@ > which case such networks may use increasing numbers of subnets, and > require methods for IPv6 prefixes to be delegated to those subnets. > The assumption of this document is that the=20 > - -homenet is as far as possible self-organising and self-configuring, > - -and is thus not pro-actively managed by the residential user. =20 > +homenet is as far as possible > +capable of self-organising and self-configuring, > +and is thus need not be pro-actively managed by the residential user. = =20 > >=20 > The > @@ -258,6 +263,9 @@ > "Advanced Security". Describes advanced security functions for a = CER, as=20 > defined in , > where the default inbound connection policy is generally "default = allow". > + > CER: Customer Edge Router. A border router at the edge of the = homenet. > LLN: Low-power and lossy network. > NAT: Network Address Translation. Typically referring to IPv4=20 > @@ -283,10 +291,9 @@ >
>=20 > > - -Service providers are deploying IPv6, content is becoming available = on > - -IPv6 (accelerated recently by the World IPv6 Launch event) > - -and support for IPv6 is increasingly available in devices and > - -software used in the home. While=20 > + > +While=20 > IPv6 resembles IPv4 in many ways, it changes address allocation = principles,=20 > making multi-addressing the norm, and allowing direct IP = addressability=20 > of home networking=20 > @@ -323,9 +330,14 @@ >=20 > Documents that provide some more specific background and depth on = this=20 > topic include: > - -, > - -, and > - -. > +, > +, and > +. > + > + >=20 > The addition of routing between subnets raises the issue of=20 > how to extend mechanisms such as service discovery which currently = rely=20 > @@ -340,6 +352,10 @@ > Here, there are a number of choices. These include > an appropriate service discovery protocol, or the use of a=20 > well-known name, resolved by some local name service. > + > Both might have to deal with handling more than one router responding > in multihomed environments. > > @@ -357,6 +373,9 @@ > allowing every device on every link to be assigned a globally unique=20= > IPv6 address.=20 > > + > > The end-to-end communication that is potentially enabled with IPv6 is=20= > on the one hand an incredible=20 > @@ -373,6 +392,12 @@ > would only be used on private networks or the device itself doesn't > have the computing power to apply the necessary security methods. > > + > > IPv6 networks may or may not have filters applied at their borders, = i.e. > at the homenet CER. > @@ -498,11 +523,33 @@ > should be considered in IPv6-only environments: > >=20 > - -Ensuring there is a way to access content in the IPv4 Internet. = This can=20 > +Ensuring there is a way to access content in the IPv4 Internet. > + > + > +This can=20 > be arranged through incorporating NAT64 > and DNS64 > functionality in the home gateway router, for instance. Such features > - -are outside the scope of this document however, being CER = functions. > +are outside the scope of this document however, being CER functions. > +Legacy IPv4-only hosts could not function in a network for which the > +DNS server implements DNS64. Therefore a DNS64 NS may need to = disable > +DNS64 translation for DNS queries arriving via IPv4 transport. > +This can also be arranged through use of > +DS-Lite, with the = DS-Lite > +B4 implemented in the host and the DS-Lite AFTR implemented in the > +CPE, or the AFTR FQDN passed from the CPE to the host if AFTR is > +offerred by the service provider. > + > + > + > + >=20 > DNS discovery mechanisms are enabled for IPv6. Both stateless > DHCPv6 @@ -517,6 +564,12 @@ > mode. Some current devices work well with dual-stack but fail to > recognise connectivity when IPv4 DHCP fails, for instance. >=20 > +It is desirable for mechanisms which enable IPv6-only host > +operation, to also support IPv4 as a fallback for legacy devices and > +support DHCPv4 for legacy IPv4 only hosts and for IPv6 DS devices > +which fail to operate without IPv4 and DHCPv4. > + > > > > @@ -551,7 +604,8 @@ > expect the resulting network to operate. > Significant manual configuration is rarely, if at all, possible, given=20= > the knowledge level of typical home users. Thus the network should,=20 > - -as far as possible, be self-configuring.=20 > +as far as possible, be self-configuring. For the benefit of the > +atypical more advanced user, manual configuration should be = supported. > > > The equipment also needs=20 > @@ -623,6 +677,17 @@ > infrastructure to allow the rest to operate. In such cases,=20 > the user should ideally have some useful=20 > indication of the failure mode encountered. > +There are no topology secenarios which could cause loss of > +connectivity, except when the = user > +creates a physical island within the topology. Some potentially > +pathological cases that can be created include bridging ports of a > +router together, however this case can be detected and dealt with by > +the router. Routing cycles within a topology are in a sense good in > +that they offer redundancy. Bridging cyslces can be dangerous but = are > +also detectable when a switch learns the MAC of one of its interfaces > +on another or runs a spanning tree or link state protocol. It is = only > +cycles using simple repeaters that are truly pathological. > + >
>=20 >
> @@ -636,6 +701,14 @@ > and private networks.=20 > > > +Cascading NATs are somewhat common in IPv4 home networks. Many > +devices such as SIP devices and some streaming video devices have a > +WAN side and LAN side Ethernet port and in their installation > +instructions either recommend or insist on being the device closest = to > +the WAN for QoS reasons. A user may comply and string these together > +resulting in two or three or potentially more cascaded IPv4 NAT. > + > + > In general, the models described in=20 > =20 > and its successor RFC 6204-bis = =20 > @@ -656,6 +729,9 @@ > subnets, with > no direct connectivity between them within the homenet. Isolation may > be physical, or implemented via IEEE 802.1q VLANs. > + > Demarcation of the CER. The CER(s) may or may not be managed by > the ISP. If the demarcation point is such that the customer > can provide or manage the CER, its configuration must be simple. Both > @@ -688,6 +764,23 @@ > A separate discussion of physical infrastructures=20 > for homenets is included in > and . > + > + > > > In the following sections we give some examples of the types of=20 > @@ -707,7 +800,8 @@ > topology itself may also be complex, and it may not be possible to=20 > assume a pure tree form, for instance (home > users may plug routers together to form arbitrary topologies=20 > - -including loops). > +including cycles. > + >=20 >=20 >
> @@ -863,7 +957,9 @@ > A general recommendation is to follow the same topology for IPv6 > as is used for IPv4, but not to use NAT. Thus there should be=20 > routed IPv6 where an IPv4 NAT is used, and where there is no NAT > - -there should be bridging if the link layer allows this. > +routing or bridging may be used. Routing may have advantages over > +bridging together high speed and lower speed shared media and = bridging > +may not be suitable for some media, such as ad-hoc mobile networks. > > > In some cases IPv4 NAT > @@ -925,12 +1021,14 @@ > typically include . = Applications may > of course do different things, and this should not be precluded.=20 > > + >=20 > > For the single CER Network Model C, multihoming may be offered by = source=20 > routing at the CER. With multiple exit routers, the complexity rises. > Given a packet with a source address on the network, the > - -packet must be routed to the proper egress to avoid BCP 38=20 > +packet must be routed to the proper egress to avoid BCP 38 > +() > filtering at an ISP that did not delegate the prefix the address is > chosen from. While=20 > the packet might not take an optimal path to the correct exit CER, the=20= > @@ -939,11 +1037,12 @@ > that the packet is routed in the most efficient manner to the correct=20= > exit. > > + >=20 > > There are various potential approaches to this problem, one example > being described in=20 > - -. > +. > Another is discussed in ,=20= > which explores support for source routing throughout the homenet.=20 > This approach would however likely require relatively significant=20 > @@ -951,6 +1050,8 @@ > given the source address. Such changes should preferably be > minimised. > > + >=20 > There are some other multihoming considerations for homenet > scenarios. First, it may be the case that > @@ -967,6 +1068,7 @@ > While we should not specifically target walled garden multihoming as > a principal goal, it should not be precluded.=20 > > + >=20 > > Host-based methods such=20 > @@ -1049,7 +1151,7 @@ >
>=20 >=20 > - -
> +
> > Today's IPv4 home networks generally have a single subnet, and > early dual-stack deployments have a single congruent IPv6 subnet, > @@ -1063,9 +1165,11 @@ > routers and thus need multiple subnets, for=20 > the reasons described earlier. As part > of the self-organisation of the network, the homenet should subdivide > - -itself to the largest possible subnets that can be constructed = within > +itself to the largest practical subnets that can be constructed = within > the constraints of link layer mechanisms, bridging, physical > - -connectivity, and policy. =20 > +connectivity, policy, and where applicable performance or other > +criteria. For example, bridging a busy GbE subnet and a wireless > +subnet together may impact wireless performance. > > > While it may be desirable to maximise the chance of link-local > @@ -1073,6 +1177,15 @@ > multi-subnet home networks are inevitable, so their support must be=20 > included.=20 > > + >=20 >
>=20 > @@ -1109,6 +1222,31 @@ > homenet will need to adapt to the prefixes made available to it > through the prefix delegation method used by its upstream ISP.=20 > > + > +It is important to note that for the purpose of a homenet, a /64 > +prefix is subdividable. specifically = states > +"Subnet numbers must be assumed to come from the network part. This > +is not to preclude routing protocols such as IS-IS level 1 > +(intra-area) routing, which routes individual host addresses, but = says > +that it may not be depended upon in the world outside that zone." > +Prefixes longer than /64 are not globally routable but may be used by > +protocols such as IS-IS or OSPF to subdivide a /64. Subdividing a = /64 > +effectively requires a managed address space, disallowing allocation > +within that /64 though SLAAC and = disallowing > +any technique which requires the use of the full lower 64 bits such = as > +CGA . > + > + > + > +If faced with allocation of a /64 prefix, or a prefix that is too > +short to support a /64 for each subnet it may be necessary to > +subdivide one or more /64. This need may arise if some providers > +refuse to allocate anything but a /64 to home users, small office > +users, or very small businesses. The need to get the network running > +may have to be weighed against other needs such as CGA. > + > + >=20 >
> > @@ -1123,7 +1261,8 @@ > and thus make no assumptions about the stability of the prefix > received from an ISP, or the length of the prefix that may be offered. > However, if only a /64 is offered by the ISP, the homenet may be > - -severely constrained, or even unable to function. > +severely constrained, or even unable to function if the /64 cannot be > +subdivided due to conflicting requirements (such as CGA). > > > The internal operation of the home network should also not depend on > @@ -1142,6 +1281,12 @@ > their prefix pool) changing. It is not expected that ISPs will support > Provider Independent (PI) addressing for general residential homenets. > > + > > When an ISP needs to restructure and in doing so renumber its customer=20= > homenets, "flash" renumbering is likely to be imposed. This implies a = need=20 > @@ -1154,6 +1299,8 @@ > is an extended version of an initial numbering process, the difference=20= > between flash renumbering and an initial "cold start" is the need to=20= > provide service continuity. =20 > +The depricated addresses would remain usable within the homenet as > +described in . > > > There may be cases where local law means some ISPs are required to = change > @@ -1177,6 +1324,11 @@ > The introduction of any new homenet protocols should not make any form = of > renumbering any more complex than it already is. > > + >=20 >
>=20 > @@ -1213,6 +1365,30 @@ > scope through filtering at the border(s) of the homenet, as described > in RFC 6092. > > + > +If a routing protocol (or static routing) is not used, then ULA or = GUA > +connectivity across subnets cannot occur. ULA connectivity requires > +that host routes (IPv6 /128 routes) be used. In a very large network > +this would pose a scaling issue. Homenets should be sufficiently > +small that scalability is not at all an issue, even is the absence of > +the route aggregation afforded by GUA subnet routes. An interior > +routing protocol adjacency (IS-IS or OSPF) should not be attempted by > +default on a provider interface, and will generally require a shared > +secret with the provider, implying a need for configuration. If such > +an adjacency is configured, route summarization of GUA routes is > +required and no ULA routes should be advertised to the provider. Any > +sensible provider will provide route filters on their end. More > +likely no routing protocol adjacency will exist between the homenet = CE > +and the provider. For medium sized businesses (not a homenet) a BGP > +adjacency might be used, but still no OSPF or IS-IS adjacency. > +Similarly the provider would pay no attention to distance vector > +routing protocol information erroneously sent from the homenet. The > +homenet interior routing information would therefore always be > +confined to the homenet. > + > + >=20 >
>=20 > @@ -1230,7 +1406,8 @@ > .=20 > Then each subnet in the homenet should receive a prefix from within = the=20 > ISP-provided prefix(es). The ISP should only see the aggregate from > - -the homenet, and not single /64 prefixes allocated within the = homenet.=20 > +the homenet, and not single /64 (or longer) prefixes allocated within > +the homenet. > >=20 > Delegation should be autonomous, and not assume a flat or > @@ -1281,14 +1458,18 @@ > > Several proposals have been made for prefix delegation within a = homenet.=20 > One group of proposals is based on DHCPv6 PD, as described in > - -, > - -, > +, > +, > and . > The other uses OSPFv3, as described in > . > More detailed analysis of these approaches needs to be made against = the=20 > requirements/principles described above. > > + > >=20 >
> @@ -1385,6 +1566,8 @@ > evaluations of common routing protocols made against the type of = requirements > described above. > > + >=20 >
>=20 > @@ -1406,10 +1589,41 @@ > to be able to operate securely, end-to-end where required, but also be > robust against malicious traffic direct towards them. We simply > note at=20 > - -this point that software on home devices will have an increase in > +this point that software on home devices may have an increase in > security if it allows its software to be updated regularly. > >=20 > +
> + > +Security by way of obscurity (address translation) or through > +firewalls (filtering) is at best marginally effective. The very poor > +security track record of home computer, home networking and business > +PC computers and networking is testomony to its ineffectiveness. A > +compromise behind the firewall of any device exposes all others, > +making an entire network that relies on obscurity or a firewall as > +vulnerable as the most insecure device on the private side of the > +network. > + > + > +However, given home network products with very poor security, putting > +a firewall in place does provide some protection, even if only > +marginally effective. IPv6 global reachability may increase the need > +to solve the underlying problem of certain insecure home and business > +computer and network products. The use of firewalls today, whether a > +good practice or not, is common practice and whatever protection > +afforded, even if marginally effective, must not be lost. > + > + > +
> + >
> > An IPv6-based home network architecture should embrace=20 > @@ -1465,6 +1679,8 @@ > to be configured on a CER. Such methods should be able to=20 > be automatically updating. > > + >
>=20 >=20 > @@ -1577,7 +1793,11 @@ > There are naming protocols that are designed to be configured and > operate Internet-wide, like unicast-based DNS, but also protocols > that are designed for zero-configuration local environments, like=20 > - -mDNS. Consideration should be made for how these interact with = each > +mDNS. It has been suggested that Dynamic DNS could be made to = operate > +in a zero-configuration mode using a locally significant root domain > +and with minimal configuration or using a DHCPv6 based (details > +to-be-defined) means of automated delegation populate a global DNS > +zone. Consideration should be made for how these interact with each > other in a homenet scenario. > >=20 > @@ -1634,6 +1854,8 @@ > to multicast service discovery requests. Those same parts > of the network may have less capacity for multicast traffic that > may be flooded from other parts of the network. > + > In general, message utilisation should be efficient considering=20 > the network technologies the service may need to operate over. > > @@ -1650,7 +1872,7 @@ >=20 > > Current service discovery protocols are generally aimed at single > - -subnets. If service discovery is to operate across the an entire > +subnets. If service discovery is to operate across an entire > homenet, by adopting an approach like that proposed as Extended mDNS=20= > (xmDNS) , then > support may be required for IPv6 multicast across the scope of the=20 > @@ -1682,12 +1904,14 @@ > > The homenet architecture proposes that any existing=20 > protocols that are designed to only work within a subnet should be = extended > - -to work across subnets, rather than defining proxy capabilities=20 > +to work across subnets or not used by homenet, > +rather than defining proxy capabilities > for each of those functions. However, while > it is desirable to extend protocols to site scope operation rather=20 > than providing proxy functions on subnet boundaries, the > reality is that until all hosts can use site-scope discovery = protocols, > - -existing link-local protocols would need to be proxied anyway. > +existing link-local protocols would need to be proxied anyway or = other > +solutions found which are not link local in scope. > > Some protocols already have proxy functions defined and in use, e.g.=20= > DHCPv6 relays, in which case those protocols would be expected to > @@ -1812,10 +2036,14 @@ > >=20 > &rfc1918; > + &rfc2462; > &rfc2475; > &rfc2775; > + &rfc2827; > &rfc3022; > + &rfc3177; > &rfc3646; > + &rfc3972; > &rfc4192; > &rfc5533; > &rfc5969; > @@ -1826,22 +2054,26 @@ > &rfc6296; > &rfc6333; > &rfc6555; > - - &I-D.baker-fun-multi-router; > - - &I-D.lynn-homenet-site-mdns; > - - &I-D.townsley-troan-ipv6-ce-transitioning; > - - &I-D.baker-fun-routing-class; > - - &I-D.howard-homenet-routing-comparison; > - - &I-D.herbst-v6ops-cpeenhancements; > - - &I-D.vyncke-advanced-ipv6-security; > - - &I-D.ietf-6man-rfc3484bis; > - - &I-D.v6ops-multihoming-without-ipv6nat; > - - &I-D.baker-homenet-prefix-assignment; > + &I-D.baker-fun-multi-router; > + &I-D.lynn-homenet-site-mdns; > + &I-D.townsley-troan-ipv6-ce-transitioning; > + &I-D.baker-fun-routing-class; > + &I-D.howard-homenet-routing-comparison; > + &I-D.herbst-v6ops-cpeenhancements; > + &I-D.vyncke-advanced-ipv6-security; > + &I-D.ietf-6man-rfc3484bis; > + &I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat; > + &I-D.baker-homenet-prefix-assignment; > &I-D.arkko-homenet-prefix-assignment; > &I-D.acee-ospf-ospfv3-autoconfig; > - - &I-D.ietf-pcp-base; > - - &I-D.hain-ipv6-ulac; > - - &I-D.chakrabarti-homenet-prefix-alloc; > - - &I-D.arkko-homenet-physical-standard; > + &I-D.ietf-pcp-base; > + &I-D.hain-ipv6-ulac; > + &I-D.chakrabarti-homenet-prefix-alloc; > + &I-D.arkko-homenet-physical-standard; > + > + >=20 > > > @@ -1953,7 +2185,7 @@ > Clarified simple and advanced security some more, and RFC 4864 and = 6092. > Stated that there should be just one secret key, if any are used at = all. > For multihoming, support multiple CERs but note that routing to the = correct CER to avoid ISP filtering may not be optimal within the = homenet. > - -Added some ISPs renumber due to privacy laws. > +Added some ISPs renumber due to privacy laws. > Removed extra repeated references to Simple Security. > Removed some solution creep on RIOs/RAs. > Load-balancing scenario added as to be supported. >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Thu Oct 11 07:28:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED5F21F8625 for ; Thu, 11 Oct 2012 07:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIK0Touy9NHU for ; Thu, 11 Oct 2012 07:28:08 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 2134421F86DA for ; Thu, 11 Oct 2012 07:28:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BES4TL001038 for ; Thu, 11 Oct 2012 15:28:04 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9BES4TL001038 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1349965684; bh=2ScxCsTVwuKM64Kr9WRL9OFxDXg=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=G7A9UbABKHAmYZBwDGu+Pt6H/578ulxVWzuiOSlhA9PI1CAdph8oSj8wVh4Vnto7u /M6V7h4fNZx0xn3PYzcJoxYSxURcvM2bIGKB/zLGv8C0x7wUAmYOPT7KAcUiwQd+VZ wYOEC75RyQxos6iupmMDeONAB6ABoSjJR2T2G164= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9AFS40430600533oM ret-id none; Thu, 11 Oct 2012 15:28:04 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9BES47Y019944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Oct 2012 15:28:04 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <5076BD91.9020803@gmail.com> Date: Thu, 11 Oct 2012 15:28:04 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <5076BD91.9020803@gmail.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9AFS4043060053300; tid=o9AFS40430600533oM; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9BES4TL001038 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] homenet-arch-04 [was draft-haddad-homenet-multihomed-00] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:28:09 -0000 On 11 Oct 2012, at 13:37, Brian E Carpenter = wrote: > On 11/10/2012 10:37, Tim Chown wrote: >>=20 >> If people have specific comments on 3.2.4 where this is contained, = please make them and we can consider those. >=20 > " Host-based methods such as Shim6 [RFC5533] have been defined, but = of > course require support in the hosts." >=20 > Perhaps you should mention MPTCP here too. Well, shim6 is just an example, there's no intent to create an = exhaustive list. > My concern about the whole section is that it leaves things open; it = would > be better if the architecture could suggest an immediately available > solution, as well as leaving open alternative solutions for the = future. > I think that draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat is the > closest thing we have to an immediately available solution, and it's > in the RFC Editor queue. The question then is whether the chairs would like a solution proposed = in this section at this point. If they do, then the above draft is a method that could be applied = now/soon, and future work might lead to a homenet routing protocol that = allows source and destination based routing (for example). >=20 > Nit: your reference to this I-D in homenet-arch-04 is broken. Fixed, thanks. Tim From teco@inf-net.nl Thu Oct 11 10:03:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BCF21F860B for ; Thu, 11 Oct 2012 10:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOMff5QET6Xj for ; Thu, 11 Oct 2012 10:03:46 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C8EBB21F84F2 for ; Thu, 11 Oct 2012 10:03:45 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so387348eaa.31 for ; Thu, 11 Oct 2012 10:03:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+OwyorT0SQBAp5x8Mv7mTuSI+0NETVP9998zhkax23M=; b=VlAwcrJyZALR6UyqiH49pkJaSFmH5thfbF6HSmIExCAfqp4Dwwi5Ddtiuk6idSnOc2 9E+QwsQa34dHXYGKnl0vmA2K5vnX52w3R9KQgX+7MSr6DclnofYqAX7JW833siBoi69b 5/0PT0++lgnw0dv3qEMlBxvkdQdzcYekyFrW9h4vU+DjKIxA6OclBnuLpD3313ZYMb5V Kc7Zhubinu6yp+nhYmXVLnQphTaPJUx+Z5gOxSGqeBAeYUPZq9aI9FcTbMmGOnZKYgwZ F9JV+4wpd49wl17R2wh38cnVMCu9Y5XES3Om92GTQrCcVsKojvpez2R3M4Kj9PUvglW9 Mn4w== Received: by 10.14.221.8 with SMTP id q8mr2786151eep.28.1349975024364; Thu, 11 Oct 2012 10:03:44 -0700 (PDT) Received: from [10.87.63.99] ([80.187.201.33]) by mx.google.com with ESMTPS id m42sm7755008eep.16.2012.10.11.10.03.41 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 10:03:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <51059699-AA09-4C04-A7CB-2DCACA5587BA@cisco.com> Date: Thu, 11 Oct 2012 19:03:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> <51059699-AA09-4C04-A7CB-2DCACA5587BA@cisco.com> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkxxdGT9pO+qzVVuTIIObjSPGJ8h/s8e9aoDwe2mrSILHB1WkcARmk44gaWKoIrd4qDN66m Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] Border Router Discovery Protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:03:46 -0000 Op 11 okt. 2012, om 13:50 heeft Ole Tr=F8an het volgende geschreven: >>> PS: I'd also be quite happy to see BRDP go out as an >>> Experimental status RFC initially, whether through >>> the IETF track, IRTF Routing RG, or the ISE-track. >>> BRDP seems very useful and useful protocols tend >>> to self-deploy into environments where they are useful. >>=20 >> We also have Eric Kline's draft in similar space: = draft-kline-default-perimeter-00. >>=20 >> Both can hopefully contribute to the solution for this problem space = in homenet. >=20 > I have read the BRDP framework document, but I failed to understand = how BRDP solves the problem of how a border is discovered. > it explains well how to act when a border has been established, but I = don't understand how BRDP helps getting to that point. pointers? I merge the old BRDP drafts into one, to be submitted soon. Now I have = to tweak a bit for Homenet. I do this in slack time, I hope to do some = of it before Atlanta. In a MANET and in general, uplink interfaces (wired, cellular, satcom) = are distinguished easily from MANET interfaces. In homenet and ethernet, = we could have fixed assigned and color marked interfaces, but this is = not our target. So here we need an additional tool.=20 After an interface is discovered as an uplink interface, and it has = received a prefix (e.g. DHCP-PD), then BRDP propagates this information = downstream in the edge network. This could be used for perimeter = discovery also. If there is no border router upstream, ask for a prefix = with DHCP-PD. If it has assigned such successfully, start acting as = BRDP. Other checks would be useful (draft-kline-default-perimeter). I'll add this in the to be submitted homenet-brdp. Teco >=20 > cheers, > Ole >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Fri Oct 12 04:30:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B886921F8573 for ; Fri, 12 Oct 2012 04:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hOpc1q9-a9s for ; Fri, 12 Oct 2012 04:30:08 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 155A821F846A for ; Fri, 12 Oct 2012 04:30:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9CBU1wo017241 for ; Fri, 12 Oct 2012 12:30:01 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9CBU1wo017241 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350041401; bh=GB/iOb1saHnFtCIVcVWZfhqG9JA=; h=From:Subject:Date:To:Mime-Version:References; b=yydpkQnmNI+UlD2E1L7VgwCnxXJg6C4vS3CXLO7izF4Z/yaGAefleTid56bXilFV0 9MQpp8I9LaNL6kspwU8Fl2aNWg/MqDbznryTHTp5XSiiFwUhCx2xjzj25/FS4vFvkl QwInDzMZbpQPFo6g33LM5e0QluOAt4o3sSKRPYoI= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9BCU10430608006x9 ret-id none; Fri, 12 Oct 2012 12:30:01 +0100 Received: from ip-205-015.eduroam.soton.ac.uk (ip-205-015.eduroam.soton.ac.uk [152.78.205.15]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9CBU1db004162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Oct 2012 12:30:01 +0100 From: Tim Chown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: Date: Fri, 12 Oct 2012 12:30:01 +0100 To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9BCU1043060800600; tid=o9BCU10430608006x9; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9CBU1wo017241 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [homenet] draft-lynn-mdnsext-requirements-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:30:08 -0000 A heads up: http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00 Discussion on the problem statement is encouraged, preferably on the = mdnsext list. You can join here: = https://www.ietf.org/mailman/listinfo/mdnsext Tim= From mbehring@cisco.com Mon Oct 15 02:25:45 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9421F86A2 for ; Mon, 15 Oct 2012 02:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrcQntcNBQe6 for ; Mon, 15 Oct 2012 02:25:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B15FF21F8694 for ; Mon, 15 Oct 2012 02:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2730; q=dns/txt; s=iport; t=1350293141; x=1351502741; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=W9HFPtIQJrG3HFja5luE7Blfl1IisR4ohOOJC/ncI2M=; b=g6U701SIUBlVsT2Lip1SQxab3pd8jWtjtmhGMyXqCDgqu2iCA/LmyIAf ZAW2bQpWE+W9nt9RZUaqpDOVp599J1pV8ov6OELq2HjDNmMJaPQkUgLnH D9qptdaIIALdmVo9uhMvHmQaxLsNpYQdnkAGWW5fadB2lV/Kc2ljKQt4A I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIzVe1CtJV2Y/2dsb2JhbABFhhK4bHiBCIIgAQEBBBIBEBFFDAYBGQQBAQMCBh0DAgQwFAEICQEEDgUIARmHYgudS40fkhuBIYo4hSsyYAOXAY0wgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131629452" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 15 Oct 2012 09:25:41 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9F9PfuX028222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Oct 2012 09:25:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 04:25:41 -0500 From: "Michael Behringer (mbehring)" To: "homenet@ietf.org" Thread-Topic: draft-behringer-homenet-trust-bootstrap-00.txt Thread-Index: Ac2qtv9dNQ0BExdWQlSbg6OV8R9k6g== Date: Mon, 15 Oct 2012 09:25:40 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F566BB7@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--30.671700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Max Pritikin \(pritikin\)" , "Steinthor Bjarnason \(sbjarnas\)" Subject: [homenet] draft-behringer-homenet-trust-bootstrap-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 09:25:45 -0000 SG9tZW5ldCwgDQoNClJlZ2FyZGluZyBmaW5kaW5nIHRoZSBib3VuZGFyaWVzIG9mIHRoZSBob21l bmV0LCB0aGVyZSB3YXMgYSBsaXZlbHkgZGlzY3Vzc2lvbiBhdCB0aGUgbGFzdCBJRVRGLiBXZSBk b2N1bWVudGVkIGFuIGFwcHJvYWNoIHRoYXQgd2UndmUgYmVlbiB3b3JraW5nIG9uLCBhbmQgd2hp Y2ggd2UgYmVsaWV2ZSBtaWdodCBiZSBhcHBsaWNhYmxlIHRvIGEgaG9tZW5ldC4gDQoNCldlJ3Jl IHJlbGF0aXZlbHkgbmV3IHRvIHRoZSBob21lbmV0IFdHLCBzbyBhcG9sb2dpZXMgaWYgdGhpcyB3 b3JrIGlzIG91dCBvZiBzY29wZSAvIGNvbnRleHQgLyBvciBnZW5lcmFsbHkgbm90IGFwcGxpY2Fi bGUgZm9yIHdoYXRldmVyIHJlYXNvbi4gDQoNCkZlZWRiYWNrIHJlcXVlc3RlZCEgKHNlZSBiZWxv dykNCg0KTWljaGFlbCwgTWF4LCBTdGVpbnRob3INCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogMTUgT2N0b2JlciAyMDEyIDA5OjI2DQo+IFRvOiBN aWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpDQo+IENjOiBNYXggUHJpdGlraW4gKHByaXRpa2lu KTsgU3RlaW50aG9yIEJqYXJuYXNvbiAoc2JqYXJuYXMpDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmVocmluZ2VyLWhvbWVuZXQtdHJ1c3QtDQo+IGJvb3Rz dHJhcC0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVocmlu Z2VyLWhvbWVuZXQtdHJ1c3QtYm9vdHN0cmFwLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgSC4gQmVocmluZ2VyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtYmVocmluZ2VyLWhvbWVu ZXQtdHJ1c3QtYm9vdHN0cmFwDQo+IFJldmlzaW9uOgkgMDANCj4gVGl0bGU6CQkgQm9vdHN0cmFw cGluZyBUcnVzdCBvbiBhIEhvbWVuZXQNCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMTUNCj4g V0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogNA0KPiBV Ukw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWJlaHJpbmdlci1ob21lbmV0LQ0KPiB0cnVzdC1ib290c3RyYXAtMDAudHh0DQo+IFN0YXR1czog ICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZWhyaW5nZXIt aG9tZW5ldC10cnVzdC0NCj4gYm9vdHN0cmFwDQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVocmluZ2VyLWhvbWVuZXQtdHJ1c3QtDQo+IGJvb3Rz dHJhcC0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBBIGhvbWVuZXQgbXVzdCBiZSBhd2Fy ZSBvZiBpdHMgYm9yZGVycywgYW5kIHRoZSByZWFsbXMgd2l0aGluIHRob3NlLg0KPiAgICBUaGlz IGRvY3VtZW50IHByb3Bvc2VzIGFuIGFwcHJvYWNoIHRvIGJvb3RzdHJhcCB0cnVzdCBpbiBzdWNo IGFuDQo+ICAgIGVudmlyb25tZW50LiAgVGhlIGlkZWEgaXMgdG8gc2VsZWN0IG9uZSBkZXZpY2Ug YXMgdGhlIHRydXN0IGFuY2hvcg0KPiAgICBhbmQgdG8gZW5yb2xsIG90aGVyIGRldmljZXMgaW50 byB0aGUgZG9tYWluLiAgVGhlIHJlc3VsdCBpcyB0aGUNCj4gICAgY3JlYXRpb24gb2YgYSBkb21h aW4gb2YgdHJ1c3QgaW4gdGhlIGhvbWVuZXQsIHdpdGggYSBjb21tb24gdHJ1c3QNCj4gICAgYW5j aG9yLiAgVGhpcyB0cnVzdCBtb2RlbCBjYW4gc3Vic2VxdWVudGx5IGJlIHVzZWQgdG8gZGV0ZXJt aW5lDQo+ICAgIGJvdW5kYXJpZXMsIGFuZCB0byBhdXRvbm9taWNhbGx5IGJvb3RzdHJhcCBuZXR3 b3JrIHNlcnZpY2VzLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From Efrain.Fino@videotron.com Mon Oct 15 13:02:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5121F87CA for ; Mon, 15 Oct 2012 13:02:34 -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 VofDn094IdsF for ; Mon, 15 Oct 2012 13:02:34 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0DB21F89B5 for ; Mon, 15 Oct 2012 13:02:34 -0700 (PDT) Auto-Submitted: auto-generated From: Efrain.Fino@videotron.com To: homenet@ietf.org Message-ID: Date: Mon, 15 Oct 2012 16:02:21 -0400 X-MIMETrack: Serialize by Router on DOMSMTP01/SRV/Videotron(Release 8.5.3FP1|March 07, 2012) at 2012-10-15 16:02:23 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Received-SPF: none Subject: [homenet] Efrain Fino est absent(e) / is out of the office X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 20:02:34 -0000 Je serai absent(e) du 2012-10-15 au 2012-10-19. I will be out of the office from July 5th returning on July 16th. From mark@townsley.net Tue Oct 16 01:51:02 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A137221F8894 for ; Tue, 16 Oct 2012 01:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 fzCz14I20Xlg for ; Tue, 16 Oct 2012 01:51:00 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAE5B21F884D for ; Tue, 16 Oct 2012 01:50:51 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3623526eek.31 for ; Tue, 16 Oct 2012 01:50:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=km4CoEfrncxAz3dsMGA9bf8FeDDImJn+uyubCEXZGwU=; b=YPTYBCOdDzxWdISsViFyGbxU5HPTzUVWFMINMo2ucLnrugr67byAMhK5qOgxKpI8lq zM4rTdw3/PkAHBHzvvY6Aqr5SPcapfILuVB1KHMkWFDDEqqVp/wBig4som4QqXEMq2Pa FVw6Yi17eH0cgjljn4w6i/VlJHyvRhZ57h+hLt0UkFB6POklb7wlq0LYArJBUed2q1Xv yxqe8QykxGV9thaNW7Imb6e5cI0CAEEckYkvStbhdRN+OBFjyQS+pJIvSCFVlEs1dM56 vFHXL8IJ8WDqHX90KEBxj08Ya1hMcdzYoxei/YB+m9FpFU2NNMkqpSKcLRfkNkx6zkig r2Fg== Received: by 10.14.0.68 with SMTP id 44mr19947147eea.1.1350377450606; Tue, 16 Oct 2012 01:50:50 -0700 (PDT) Received: from ams-townsley-89111.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id t1sm28846268eeo.3.2012.10.16.01.50.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:50:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F566BB7@xmb-rcd-x14.cisco.com> Date: Tue, 16 Oct 2012 10:50:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <438230FB-A750-47CB-B7D1-75A2DF66473E@townsley.net> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F566BB7@xmb-rcd-x14.cisco.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlFJL4azlStn3uTBcJGb6EaHDsglW/87LX91DDyJB8QfBqyDYI3jLUqsaCm1g5YCcfj5BU/ Cc: "Max Pritikin \(pritikin\)" , "Michael Behringer \(mbehring\)" , "Steinthor Bjarnason \(sbjarnas\)" Subject: Re: [homenet] draft-behringer-homenet-trust-bootstrap-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:51:02 -0000 Group, I'd very much like feedback on whether this is applicable for our agenda = in Atlanta. Guidance is much appreciated. Please read and comment to the = list. Thanks, - Mark On Oct 15, 2012, at 11:25 AM, Michael Behringer (mbehring) wrote: > Homenet,=20 >=20 > Regarding finding the boundaries of the homenet, there was a lively = discussion at the last IETF. We documented an approach that we've been = working on, and which we believe might be applicable to a homenet.=20 >=20 > We're relatively new to the homenet WG, so apologies if this work is = out of scope / context / or generally not applicable for whatever = reason.=20 >=20 > Feedback requested! (see below) >=20 > Michael, Max, Steinthor >=20 >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: 15 October 2012 09:26 >> To: Michael Behringer (mbehring) >> Cc: Max Pritikin (pritikin); Steinthor Bjarnason (sbjarnas) >> Subject: New Version Notification for draft-behringer-homenet-trust- >> bootstrap-00.txt >>=20 >>=20 >> A new version of I-D, draft-behringer-homenet-trust-bootstrap-00.txt >> has been successfully submitted by Michael H. Behringer and posted to = the >> IETF repository. >>=20 >> Filename: draft-behringer-homenet-trust-bootstrap >> Revision: 00 >> Title: Bootstrapping Trust on a Homenet >> Creation date: 2012-10-15 >> WG ID: Individual Submission >> Number of pages: 4 >> URL: = http://www.ietf.org/internet-drafts/draft-behringer-homenet- >> trust-bootstrap-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-behringer-homenet-trust- >> bootstrap >> Htmlized: = http://tools.ietf.org/html/draft-behringer-homenet-trust- >> bootstrap-00 >>=20 >>=20 >> Abstract: >> A homenet must be aware of its borders, and the realms within = those. >> This document proposes an approach to bootstrap trust in such an >> environment. The idea is to select one device as the trust anchor >> and to enroll other devices into the domain. The result is the >> creation of a domain of trust in the homenet, with a common trust >> anchor. This trust model can subsequently be used to determine >> boundaries, and to autonomically bootstrap network services. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Tue Oct 16 01:56:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543FD21F88AB for ; Tue, 16 Oct 2012 01:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 9hW0RuLY2vu9 for ; Tue, 16 Oct 2012 01:56:39 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9F21F8688 for ; Tue, 16 Oct 2012 01:56:39 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3626694eek.31 for ; Tue, 16 Oct 2012 01:56:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=05OuibGBw3pRUKQifg/7SvCdsioGteQXOFKzqVGLsAA=; b=Oo0bi4dwDBnqVBVQsWJqdKT+kj8RHiSEQg2PmhNZ5uVQc8GQN6vCaNSukZZg1Y+vb4 M32z/+vlBtoZhsCsL7fFNZEu5zlgov2NfHwGijVe9b0LoHUoWFNUI76XfRTeWbcf2PDg jcERjzX4VWXwgE6rftj+vCc1OVBIhiW8vGUmoY43srQAxpOr8+7ixS1Fq51Vrehh/ojK vCf3ZPwyKuttgeBGXXZndXFjb9ydewPzuwhEUWEpoUXYQroftA7LeBJfik0OvzApT3/2 XD5w5/FeIQJbQ8/9UYXSYwXQGGQx/Zb/jS7FTISfFuKh0YPdqZh1ppaaVb08d6UttdD8 l3Kw== Received: by 10.14.203.65 with SMTP id e41mr5163493eeo.34.1350377798674; Tue, 16 Oct 2012 01:56:38 -0700 (PDT) Received: from ams-townsley-89111.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id i1sm28872750eeo.8.2012.10.16.01.56.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:56:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Tue, 16 Oct 2012 10:56:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> <51059699-AA09-4C04-A7CB-2DCACA5587BA@cisco.com> To: Teco Boot X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlvMyaH6dHhw2HE4N3S1STTpy3oWYjXsPi6g9yuB9KA/N1MVthyW4Y9XbLGjaoSPIM7vMwc Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= , Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] Border Router Discovery Protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:56:40 -0000 On Oct 11, 2012, at 7:03 PM, Teco Boot wrote: >=20 > Op 11 okt. 2012, om 13:50 heeft Ole Tr=F8an het volgende geschreven: >=20 >>>> PS: I'd also be quite happy to see BRDP go out as an >>>> Experimental status RFC initially, whether through >>>> the IETF track, IRTF Routing RG, or the ISE-track. >>>> BRDP seems very useful and useful protocols tend >>>> to self-deploy into environments where they are useful. >>>=20 >>> We also have Eric Kline's draft in similar space: = draft-kline-default-perimeter-00. >>>=20 >>> Both can hopefully contribute to the solution for this problem space = in homenet. >>=20 >> I have read the BRDP framework document, but I failed to understand = how BRDP solves the problem of how a border is discovered. >> it explains well how to act when a border has been established, but I = don't understand how BRDP helps getting to that point. pointers? >=20 > I merge the old BRDP drafts into one, to be submitted soon. Now I have = to tweak a bit for Homenet. I do this in slack time, I hope to do some = of it before Atlanta. If you would like to present this in Atlanta, it would be nice to have a = homenet targeted document for people to review.=20 >=20 > In a MANET and in general, uplink interfaces (wired, cellular, satcom) = are distinguished easily from MANET interfaces. In homenet and ethernet, = we could have fixed assigned and color marked interfaces, but this is = not our target. So here we need an additional tool.=20 >=20 > After an interface is discovered as an uplink interface, and it has = received a prefix (e.g. DHCP-PD), then > BRDP propagates this information downstream in the edge network. In this way, BRDP sounds more like what is being done in = draft-arkko-homenet-prefix-assignment. > This could be used for perimeter discovery also. If there is no border = router upstream, ask for a prefix with DHCP-PD. If it has assigned such = successfully, start acting as BRDP. Other checks would be useful = (draft-kline-default-perimeter). Right, I don't see anything inconsistent here vs. what draft-kline has = been talking about.... Just one more heuristic.=20 - Mark >=20 > I'll add this in the to be submitted homenet-brdp. >=20 > Teco >=20 >>=20 >> cheers, >> Ole >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Tue Oct 16 02:09:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9216D21F86A2 for ; Tue, 16 Oct 2012 02:09:05 -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 jDjaqyMFvSFE for ; Tue, 16 Oct 2012 02:09:04 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA8A21F8670 for ; Tue, 16 Oct 2012 02:09:04 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so1469501eaa.31 for ; Tue, 16 Oct 2012 02:09:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ZYelqZfll4DMl+rLTLqExwyOoK7ePDhgwUuavaroX4k=; b=bzz0auDcPlxAd0F6qRJoIpUoDMToQ8yr0R0th3EK7RixnwqeDP8zSxomOIiLv/0pIE cUysVJgrjuf8UoJ0iX2+lyUYDuSne+5NctzA41/BpbxSWCbWaid+b0hcs71Sby5gbHFf 7BZ/WR8CiEVd/6RMOv1kZj4TDfLhexh3fER9NqlB7CnutLl/54OZPnnN3afxa9bcuD+g 9Kou9aIhJ+CdLI/wFlWR1zkSzT/I6XIO9UMTEJ/BmC3bY/O0B+H+QZnSQqvB3kKxe2Ug Q3eUKAUZSglpv4SdrdDFPordSQnt9YOrbCUb2kKLpQiPTuGZkWuOm3TdbePLIwfxUowa 1daA== Received: by 10.14.198.133 with SMTP id v5mr19995697een.7.1350378543174; Tue, 16 Oct 2012 02:09:03 -0700 (PDT) Received: from ams-townsley-89111.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id i1sm28922790eeo.8.2012.10.16.02.08.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 02:09:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <5076BD91.9020803@gmail.com> Date: Tue, 16 Oct 2012 11:08:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88A5FEC2-FDAF-4F9F-80A2-AD722ADE2CCB@townsley.net> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <5076BD91.9020803@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlOJuvQE8XennXuPNXWUPU0xjnA3zvFOhso80guDrSWaZKVxRKH2pzxTBN0Y7TXj0jGBqCA Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] homenet-arch-04 [was draft-haddad-homenet-multihomed-00] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:09:05 -0000 On Oct 11, 2012, at 2:37 PM, Brian E Carpenter wrote: > On 11/10/2012 10:37, Tim Chown wrote: >> On 1 Oct 2012, at 22:14, Brian E Carpenter = wrote: >>=20 >>> As far as I can tell, multihoming is not mentioned in the homenet = charter, >>> but it is discussed in draft-ietf-homenet-arch, without a clear = conclusion. >>> There is an argument for a specific analysis document on this topic, = before >>> we discuss our favourite solutions. >>=20 >> A homenet arch -05 is about to be published. >>=20 >> As Brian says, there is a brief section in the arch text about = multihoming, which we believe captures all that needs to be said. The = section tries to describe the architectural implications of different = approaches in the context of the architecture goals. For example, = nothing in the architecture should preclude use of shim6, if the hosts = support it. >>=20 >> If people have specific comments on 3.2.4 where this is contained, = please make them and we can consider those. >=20 > " Host-based methods such as Shim6 [RFC5533] have been defined, but = of > course require support in the hosts." >=20 > Perhaps you should mention MPTCP here too. >=20 > My concern about the whole section is that it leaves things open; it = would > be better if the architecture could suggest an immediately available > solution, as well as leaving open alternative solutions for the = future. > I think that draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat is the > closest thing we have to an immediately available solution, and it's > in the RFC Editor queue. draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat seems highly relevant = to the work in this group as it is all about what to do when there is = more than one router and more than one prefix in a site, specifically = with respect to IP assignment and routing. It defines "Multihomed with = Multi-prefix" (MHMP) for a host, which is precisely what we would be = setting up hosts to be able to do in a homenet with more than one ISP = upink with different prefixes. So much the better than its publication = is imminent.=20 - Mark >=20 > Nit: your reference to this I-D in homenet-arch-04 is broken. >=20 > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Tue Oct 16 02:34:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6730D21F8743 for ; Tue, 16 Oct 2012 02:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCASz6VD21HO for ; Tue, 16 Oct 2012 02:34:14 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46EFE21F843A for ; Tue, 16 Oct 2012 02:34:08 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2726198bkc.31 for ; Tue, 16 Oct 2012 02:34:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=uq/RMMc6li5etmPN9L6vPOgH1zTOtGcqp/HK4OJEB4s=; b=iFz1mywbqY/9cU6QgbbGhD6iaUn1rPLiWTEVOmg42jUj34d3rNX7wDNPsyget6IbXK rY4s0eH2RqMEFXCfydbk8pLLxGxBZ5+LDjS9qnQHlPBYb6B+q8+7HXJ72ZN5+EmbjDP6 DTZ1D+Cr/cjuPrzkCDIgwybFNYPSrcd/6y5eXGNkKoz3YYD79DvIDQTiPmFxCnT4W40Y v3h8xPblnO2iPF/YSMFaf+4aHvfY1c9+VMSVYAgYDnXVPmhnNCCKgdkBE6ji6yQlbJUO mLAQHPJCb8ve1o5FX6KJNXSXxO2lA/Hpr/gpVH3d38kJ1axW6uwSvk0UMMR3AyvKytXF QcXQ== Received: by 10.204.9.130 with SMTP id l2mr3840272bkl.56.1350380047247; Tue, 16 Oct 2012 02:34:07 -0700 (PDT) Received: from [10.175.161.26] ([188.205.88.52]) by mx.google.com with ESMTPS id e13sm10020735bkw.12.2012.10.16.02.34.04 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 02:34:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Tue, 16 Oct 2012 11:34:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3472FF9D-F700-4D88-8D68-B467B4CF2F0C@inf-net.nl> References: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> <51059699-AA09-4C04-A7CB-2DCACA5587BA@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkGFiiRQs8nDsoDVHxzWfXKh3LWoH1E9NFJmf+In5nsurXa/Qwpu+0eMmnW2DRoeXawPxJ8 Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= , Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] Border Router Discovery Protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:34:15 -0000 Op 16 okt. 2012, om 10:56 heeft Mark Townsley het volgende geschreven: >=20 > On Oct 11, 2012, at 7:03 PM, Teco Boot wrote: >=20 >>=20 >> Op 11 okt. 2012, om 13:50 heeft Ole Tr=F8an het volgende geschreven: >>=20 >>>>> PS: I'd also be quite happy to see BRDP go out as an >>>>> Experimental status RFC initially, whether through >>>>> the IETF track, IRTF Routing RG, or the ISE-track. >>>>> BRDP seems very useful and useful protocols tend >>>>> to self-deploy into environments where they are useful. >>>>=20 >>>> We also have Eric Kline's draft in similar space: = draft-kline-default-perimeter-00. >>>>=20 >>>> Both can hopefully contribute to the solution for this problem = space in homenet. >>>=20 >>> I have read the BRDP framework document, but I failed to understand = how BRDP solves the problem of how a border is discovered. >>> it explains well how to act when a border has been established, but = I don't understand how BRDP helps getting to that point. pointers? >>=20 >> I merge the old BRDP drafts into one, to be submitted soon. Now I = have to tweak a bit for Homenet. I do this in slack time, I hope to do = some of it before Atlanta. >=20 > If you would like to present this in Atlanta, it would be nice to have = a homenet targeted document for people to review. Yes. I the few cycles I had, I pushed a single Homenet document. There is = more rework needed, any input/help/other support is welcome.=20 http://www.ietf.org/internet-drafts/draft-boot-homenet-brdp-00.txt I'm not sure I can get an -01 out before next deadline. Teco=20 >=20 >>=20 >> In a MANET and in general, uplink interfaces (wired, cellular, = satcom) are distinguished easily from MANET interfaces. In homenet and = ethernet, we could have fixed assigned and color marked interfaces, but = this is not our target. So here we need an additional tool.=20 >>=20 >> After an interface is discovered as an uplink interface, and it has = received a prefix (e.g. DHCP-PD), then >=20 >> BRDP propagates this information downstream in the edge network. >=20 > In this way, BRDP sounds more like what is being done in = draft-arkko-homenet-prefix-assignment. >=20 >> This could be used for perimeter discovery also. If there is no = border router upstream, ask for a prefix with DHCP-PD. If it has = assigned such successfully, start acting as BRDP. Other checks would be = useful (draft-kline-default-perimeter). >=20 > Right, I don't see anything inconsistent here vs. what draft-kline has = been talking about.... Just one more heuristic.=20 >=20 > - Mark >=20 >>=20 >> I'll add this in the to be submitted homenet-brdp. >>=20 >> Teco >>=20 >>>=20 >>> cheers, >>> Ole >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From teco@inf-net.nl Tue Oct 16 07:57:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08C221F8843 for ; Tue, 16 Oct 2012 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 k6v9mJ6wRIRB for ; Tue, 16 Oct 2012 07:57:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF98921F8889 for ; Tue, 16 Oct 2012 07:57:00 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2921116bkc.31 for ; Tue, 16 Oct 2012 07:56:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2q84jGZWX54UboBuHvyKajAKHDrz0JcdN/fHpT91otY=; b=JNyXRN7Xb44j1hI4NNmLXxbN8HbLRKAumw1stWEIq4ZTX/gT6frGZcUatHkodvNQEf EJosCRfIAispJWi0hauS+fDahRJDSVa2b58bENTl0yWw0EIApIv0sc6bvdRdWcfPslKx rpv9TBmfINedLLazbb80+i8Sv7wAnD8lS4Da+sHb9xpjNqjvDdqDICFbYGj53KfiWAm5 IEeQfUX94IgFvFiLC6jI5XzEuL/2auX4sNlny3aRV47UkY0mhip8IDhfQKni55hECwws +qBhMlprAW5FtlRwGnoRdo79c4bVfGgSmOWfbF9IkdsvzK2kn3Tt93+yk76WyyVvc3qM PZRQ== Received: by 10.204.0.74 with SMTP id 10mr4331463bka.83.1350399419286; Tue, 16 Oct 2012 07:56:59 -0700 (PDT) Received: from [10.87.44.59] ([80.187.201.33]) by mx.google.com with ESMTPS id s20sm11034526bkw.15.2012.10.16.07.56.56 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 07:56:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Tue, 16 Oct 2012 16:56:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B6A5F6B-077F-453F-B061-77519820DEE6@inf-net.nl> References: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> <51059699-AA09-4C04-A7CB-2DCACA5587BA@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmiMJmdLw3isg2+Ujn/FHk0hNaahd75P/M7qQ/02htulROtgXQmp7sjZa0w73c4UNTO8pXG Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= , Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] Border Router Discovery Protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 14:57:02 -0000 Op 16 okt. 2012, om 10:56 heeft Mark Townsley het volgende geschreven: >=20 > On Oct 11, 2012, at 7:03 PM, Teco Boot wrote: >=20 >>=20 >> Op 11 okt. 2012, om 13:50 heeft Ole Tr=F8an het volgende geschreven: >>=20 >>>>> PS: I'd also be quite happy to see BRDP go out as an >>>>> Experimental status RFC initially, whether through >>>>> the IETF track, IRTF Routing RG, or the ISE-track. >>>>> BRDP seems very useful and useful protocols tend >>>>> to self-deploy into environments where they are useful. >>>>=20 >>>> We also have Eric Kline's draft in similar space: = draft-kline-default-perimeter-00. >>>>=20 >>>> Both can hopefully contribute to the solution for this problem = space in homenet. >>>=20 >>> I have read the BRDP framework document, but I failed to understand = how BRDP solves the problem of how a border is discovered. >>> it explains well how to act when a border has been established, but = I don't understand how BRDP helps getting to that point. pointers? >>=20 >> I merge the old BRDP drafts into one, to be submitted soon. Now I = have to tweak a bit for Homenet. I do this in slack time, I hope to do = some of it before Atlanta. >=20 > If you would like to present this in Atlanta, it would be nice to have = a homenet targeted document for people to review.=20 >=20 >>=20 >> In a MANET and in general, uplink interfaces (wired, cellular, = satcom) are distinguished easily from MANET interfaces. In homenet and = ethernet, we could have fixed assigned and color marked interfaces, but = this is not our target. So here we need an additional tool.=20 >>=20 >> After an interface is discovered as an uplink interface, and it has = received a prefix (e.g. DHCP-PD), then >=20 >> BRDP propagates this information downstream in the edge network. >=20 > In this way, BRDP sounds more like what is being done in = draft-arkko-homenet-prefix-assignment. Yes. The BRDP info could be distributed with the routing protocol. I = chose for RA because it is IGP agnostic and info is delivered to hosts = also. Hosts can benefit from knowledge about the multi-homed network. = For MPTCP, this is essential. I moved BRDP towards centralized prefix management with DHCP-PD, where = the CPE =3D border router =3D DHCP server that manages the to be = assigned /64 prefixes. This would remove the non-volatile requirement = from non-CPE routers. And would provide an information base for a = (web-based) management tool.=20 The boot-homenet-brdp draft includes the mechanism for SA based routing. = Can be used with arkko-homenet-prefix-assignment also. >=20 >> This could be used for perimeter discovery also. If there is no = border router upstream, ask for a prefix with DHCP-PD. If it has = assigned such successfully, start acting as BRDP. Other checks would be = useful (draft-kline-default-perimeter). >=20 > Right, I don't see anything inconsistent here vs. what draft-kline has = been talking about.... Just one more heuristic.=20 Added in my draft, with pointer to kline-default-perimeter. Teco >=20 > - Mark >=20 >>=20 >> I'll add this in the to be submitted homenet-brdp. >>=20 >> Teco >>=20 >>>=20 >>> cheers, >>> Ole >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From internet-drafts@ietf.org Fri Oct 19 09:00:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03921F870E; Fri, 19 Oct 2012 09:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAlzntYlWZPZ; Fri, 19 Oct 2012 09:00:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B8921F877C; Fri, 19 Oct 2012 09:00:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 09:00:00 -0700 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:00:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Architecture for IPv6 Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-05.txt Pages : 43 Date : 2012-10-19 Abstract: This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define an architecture for IPv6-based home networking, while describing the associated principles, considerations and requirements. The text briefly highlights the specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual- stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tjc@ecs.soton.ac.uk Fri Oct 19 09:36:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2C821F8748 for ; Fri, 19 Oct 2012 09:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpb44JOFLYDD for ; Fri, 19 Oct 2012 09:36:51 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id BB80121F8794 for ; Fri, 19 Oct 2012 09:36:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9JGalbC030496 for ; Fri, 19 Oct 2012 17:36:47 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9JGalbC030496 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350664607; bh=HTU7G3aMYo/6lAxfxVlI+N/9D1Y=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=3y/74VXAGUA1iTln+a/DDWRkB10GBuCTKxqHjIR4TTAkCwKZFuH2cqhOIHY3FpVlE GafJVJbovcSRQlja8FDd7Ju1sO8b1ECK6lLapWUsEZy1NZ8F4f1NHwI5qc/SWE2Bn9 zOgmuGeBfAx9igij3m0V3nwYhILft7NzY02Zo/sw= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9IHak0430662631bJ ret-id none; Fri, 19 Oct 2012 17:36:47 +0100 Received: from ip-205-169.eduroam.soton.ac.uk (ip-205-169.eduroam.soton.ac.uk [152.78.205.169]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9JGahYm004148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 19 Oct 2012 17:36:43 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_41736944-B536-40DF-9437-5B06FC0FD689" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Fri, 19 Oct 2012 17:36:42 +0100 References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> To: "homenet@ietf.org Group" In-Reply-To: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9IHak043066263100; tid=o9IHak0430662631bJ; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9JGalbC030496 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:36:52 -0000 --Apple-Mail=_41736944-B536-40DF-9437-5B06FC0FD689 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, The architecture text has been updated to -05. See: http://tools.ietf.org/html/draft-ietf-homenet-arch-05 We can take comments towards a -06 over the weekend. The most = substantial changes are in the Naming and Service Discovery section = (3.7), so if you have limited time please focus your reading there. One item where there seemed to be a lack of a firm conclusion (despite = some firm statements each way) was the question of using a single global = name space or separate internal and external name spaces. The current = text essentially says: * The default is to use an ISP-provided domain in the homenet, but with = the user able to use an independent domain name instead if preferred. * If no global domain is available, the homenet uses either a ULQDN = (preferred) or ALQDN, and these are scoped to the local homenet (i.e. = the homenet can only be reached remotely if using a global domain). The open issue is whether the LQDN should be used alongside a global = FQDN if one is available (with appropriate mappings/CNAMEs and reverse = entries to the global FQDN as proposed I think by Curtis), or if the = global domain is available then no local domain should be used. Tim On 19 Oct 2012, at 17:00, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Home Networking Working Group of the = IETF. >=20 > Title : Home Networking Architecture for IPv6 > Author(s) : Tim Chown > Jari Arkko > Anders Brandt > Ole Troan > Jason Weil > Filename : draft-ietf-homenet-arch-05.txt > Pages : 43 > Date : 2012-10-19 >=20 > Abstract: > This text describes evolving networking technology within > increasingly large residential home networks. The goal of this > document is to define an architecture for IPv6-based home = networking, > while describing the associated principles, considerations and > requirements. The text briefly highlights the specific implications > of the introduction of IPv6 for home networking, discusses the > elements of the architecture, and suggests how standard IPv6 > mechanisms and addressing can be employed in home networking. The > architecture describes the need for specific protocol extensions for > certain additional functionality. It is assumed that the IPv6 home > network is not actively managed, and runs as an IPv6-only or dual- > stack network. There are no recommendations in this text for the > IPv4 part of the network. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-arch >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-homenet-arch-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-05 --Apple-Mail=_41736944-B536-40DF-9437-5B06FC0FD689 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

The architecture text has been updated to = -05.


We= can take comments towards a -06 over the weekend.  The most = substantial changes are in the Naming and Service Discovery section = (3.7), so if you have limited time please focus your reading = there.

One item where there seemed to be a lack = of a firm conclusion (despite some firm statements each way) was the = question of using a single global name space or separate internal and = external name spaces. The current text essentially = says:
* The default is to use an ISP-provided domain in the = homenet, but with the user able to use an independent domain name = instead if preferred.
* If no global domain is available, the = homenet uses either a ULQDN (preferred) or ALQDN, and these are scoped = to the local homenet (i.e. the homenet can only be reached remotely if = using a global domain).

The open issue is = whether the LQDN should be used alongside a global FQDN if one is = available (with appropriate mappings/CNAMEs and reverse entries to the = global FQDN as proposed I think by Curtis), or if the global domain is = available then no local domain should be = used.

Tim

On = 19 Oct 2012, at 17:00, internet-drafts@ietf.org = wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Home = Networking Working Group of the IETF.

Title =           : Home = Networking Architecture for IPv6
Author(s) =       : Tim Chown
=             &n= bsp;           &nbs= p;Jari Arkko
=             &n= bsp;           &nbs= p;Anders Brandt
=             &n= bsp;           &nbs= p;Ole Troan
=             &n= bsp;           &nbs= p;Jason Weil
= Filename        : = draft-ietf-homenet-arch-05.txt
Pages =           : = 43
= Date =            : = 2012-10-19

Abstract:
  This text describes evolving = networking technology within
  increasingly large = residential home networks.  The goal of this
=   document is to define an architecture for IPv6-based home = networking,
  while describing the associated principles, = considerations and
  requirements.  The text briefly = highlights the specific implications
  of the introduction = of IPv6 for home networking, discusses the
  elements of = the architecture, and suggests how standard IPv6
=   mechanisms and addressing can be employed in home = networking.  The
  architecture describes the need = for specific protocol extensions for
  certain additional = functionality.  It is assumed that the IPv6 home
=   network is not actively managed, and runs as an IPv6-only or = dual-
  stack network.  There are no recommendations = in this text for the
  IPv4 part of the = network.


The IETF datatracker status page for this draft = is:
https://= datatracker.ietf.org/doc/draft-ietf-homenet-arch

There's also = a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-homenet-arch-05

A = diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-05

= --Apple-Mail=_41736944-B536-40DF-9437-5B06FC0FD689-- From mike@mtcc.com Fri Oct 19 09:55:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4850521F8753 for ; Fri, 19 Oct 2012 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 JnL-yvSfUJOk for ; Fri, 19 Oct 2012 09:55:57 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 6043321F873F for ; Fri, 19 Oct 2012 09:55:57 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9JGtKJr009016 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 09:55:21 -0700 Message-ID: <508185F8.7020104@mtcc.com> Date: Fri, 19 Oct 2012 09:55:20 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Tim Chown References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1237; t=1350665724; x=1351529724; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-iet f-homenet-arch-05.txt |Sender:=20 |To:=20Tim=20Chown=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=xnly0PMRjkKHS2K9r5+owrsw2KV6cfpuPAZaM5ytlww=; b=qW6IdYq3CZzCEq1YVObWQwPELYYnSwDvDEyX4bO3G+USOj/I9flMx5Yuyf wgRmpbomBJDwf0QyBdYayGmpygg5jQ16qhdpXxXc56Jw1XEhxsr76vfRZbWT kh/rhcJppFfqLQgFwP/kHj/TMOI0+t7NYwMtz3dtgizuaqhz87eJg=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:55:58 -0000 On 10/19/2012 09:36 AM, Tim Chown wrote: > One item where there seemed to be a lack of a firm conclusion (despite some firm statements each way) was the question of using a single global name space or separate internal and external name spaces. The current text essentially says: > * The default is to use an ISP-provided domain in the homenet, but with the user able to use an independent domain name instead if preferred. > * If no global domain is available, the homenet uses either a ULQDN (preferred) or ALQDN, and these are scoped to the local homenet (i.e. the homenet can only be reached remotely if using a global domain). If you get an ISP's name couldn't you always with or without their cooperation generate names of the form host..isp.net? Where is either statistically unique (cf ULA's), or is human-significant and unique (eg, host.casasanchez.customers.isp.net). Doing so would potentially take the "otherness" of .local away, and make the human factors issue less stark. Also: if we end up with a repository in the CPE, say, it makes transitions between vanity domains, hosted domain (ala ISP or some cloud service), and local/isolated domains easier it seems to me. Mike From damien.saucez@gmail.com Fri Oct 19 10:01:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD89121F8742 for ; Fri, 19 Oct 2012 10:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 y35xpU5A0VTi for ; Fri, 19 Oct 2012 10:01:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E73C621F8765 for ; Fri, 19 Oct 2012 10:01:45 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so347559eek.31 for ; Fri, 19 Oct 2012 10:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=d+Lvt4U+rlBGsCUKwL2ZIpvawCnuL2UmKQXjOiJDn50=; b=P1PpneYa5niOGEuFEd34rbyviNm31qqbvtE8QjmnagLWdf5ZMhMsRYO9rie7o94AdD vRdolvAQCxbWQa3ck1MzkDsuTgG5rv8jCTUbFNp5tbNJsmEENb9S6MzMGu/QsIFaY9eH f+wIe9lLniqc2E7T2rNyowstu9Um74r3ZCV7Z/hiAOZb2I0qBKvfPiI0C+MBo1CCG2Qb 2Ggc+UEN/lPOoQ85hx1aBl3ua415oynaObB1ENvpJQCeQV6oKQ+cw02bSbnwwX7uAY+/ shskAYjqCQhbtyYQJWWSH1QC2/l38T83W+1NfkoGAyjWSB6LL1Q6IbUDHBSwMw2mEbMI Vxfg== Received: by 10.14.175.71 with SMTP id y47mr2849110eel.36.1350666105111; Fri, 19 Oct 2012 10:01:45 -0700 (PDT) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPS id c6sm3473573eep.17.2012.10.19.10.01.43 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 10:01:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: Date: Fri, 19 Oct 2012 19:01:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> To: mark@townsley.net, ray.bellis@nominet.org.uk X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Wassim Haddad Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:01:46 -0000 Regarding all the discussion around this document I think a f2f = discussion could help. Would you please give us a time slot to discuss this during next = meeting? Thank you, Damien Saucez On 11 Oct 2012, at 11:37, Tim Chown wrote: > On 1 Oct 2012, at 22:14, Brian E Carpenter = wrote: >=20 >> As far as I can tell, multihoming is not mentioned in the homenet = charter, >> but it is discussed in draft-ietf-homenet-arch, without a clear = conclusion. >> There is an argument for a specific analysis document on this topic, = before >> we discuss our favourite solutions. >=20 > A homenet arch -05 is about to be published. >=20 > As Brian says, there is a brief section in the arch text about = multihoming, which we believe captures all that needs to be said. The = section tries to describe the architectural implications of different = approaches in the context of the architecture goals. For example, = nothing in the architecture should preclude use of shim6, if the hosts = support it. >=20 > If people have specific comments on 3.2.4 where this is contained, = please make them and we can consider those. >=20 > Tim > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Fri Oct 19 10:17:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A762821F870F for ; Fri, 19 Oct 2012 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpWrHEQYWV5n for ; Fri, 19 Oct 2012 10:17:04 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id DE40021F86B0 for ; Fri, 19 Oct 2012 10:17:03 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9JHGTvj016420 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 10:16:29 -0700 Message-ID: <50818AED.7090001@mtcc.com> Date: Fri, 19 Oct 2012 10:16:29 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Tim Chown References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1575; t=1350666992; x=1351530992; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20service=20announcement=20vs=20service=20discove ry |Sender:=20 |To:=20Tim=20Chown=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=96G12n/MGjv50u7L+9Fo1a4z1Qd4aTrSVt2tlLNKB/A=; b=Uy/V+aPNAoZABn1x3yd/ADtkmGyrWCX0D48gvrMnddlf3c8lkqvIAy8/Vh +d383ndy4dJyGJhYA+c/HxBIoEIbbG6Gv70xNvZnQFuHt23jgXtRpNBhrW68 TWn3uOxFGYa4cX3RyIuEbnqcUDyrHr7AqciIAmhLcw7vUKz/i4/gw=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:17:04 -0000 On 10/19/2012 09:36 AM, Tim Chown wrote: > > > We can take comments towards a -06 over the weekend. The most substantial changes are in the Naming and Service Discovery section (3.7), so if you have limited time please focus your reading there. One thing that I'm not sure whether it's been discussed or not is service announcement. By service announcement, I mean where instead of multicasting out a message looking for the canonical printer with all of its nasty properties especially for things with batteries and lossy/slow networks, a device would instead announce its presence to something that would later serve it up (eg, bind9, say). That is, if we can posit a dns repository in our home edge routers, we can avoid some of the insanity that ensues when you say that something MUST be strictly zeroconf. I think we are long past the days where strict zeroconf should be the driving principle; littleconf should be a valid option too. Service announcement could also feed into things like Search where instead of having preset categories which make sense perhaps only to those who chose the category at the factory, we could also have structured and/or free-form text with lots of keywords and other identifying information that an indexer might find useful. Mechanistically, we already have things like IXFR for DNS, so it's not likely that this is wholesale invention, though it may well involve some tweaks. IXFR also gives the possibility for enrollment and access control which is pretty problematic with service discovery. Mike From v6ops@globis.net Sat Oct 20 14:32:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7851A21F848D for ; Sat, 20 Oct 2012 14:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_05=-1.11, J_CHICKENPOX_34=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 ecR3z9rxaHXN for ; Sat, 20 Oct 2012 14:32:30 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id A109921F846F for ; Sat, 20 Oct 2012 14:32:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2DDDC8700E0; Sat, 20 Oct 2012 23:24:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ7x3a-7iNwe; Sat, 20 Oct 2012 23:24:12 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8F12D870044; Sat, 20 Oct 2012 23:24:12 +0200 (CEST) Message-ID: <50831676.1070203@globis.net> Date: Sat, 20 Oct 2012 23:24:06 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 21:32:34 -0000 Tim Chown wrote: > Hi all, > > The architecture text has been updated to -05. > > See: http://tools.ietf.org/html/draft-ietf-homenet-arch-05 > > We can take comments towards a -06 over the weekend. The most > substantial changes are in the Naming and Service Discovery section > (3.7), so if you have limited time please focus your reading there. Thanks for editing this, Tim. As requested, comments towards -06 Substantive Comments ==================== Section 2.1 /The addition of routing between subnets raises the issue of how to extend mechanisms such as service discovery which currently rely on link-local addressing to limit scope. There are two broad choices; extend existing protocols to work across the scope of the homenet, or introduce proxies for existing link layer protocols./ I think there is a viable third choice: Take existing (heavyweight) Internet protocols, like DNS and OSPF, that already scale to cover large routed infrastructures, and attempt to reduce the amount of expert configuration required so that they are suitable for use in networks that do not enjoy expert management. By the time we've invented proxies and gateways from current mDNS to LLN and Internet DNS, we may well end up spending more effort on two-way name-space content synchronisation than we'd ever imagine. Section 2.4 Use of ULA should probably also mention the following challenge: Selecting a suitable prefix for use with an address scheme based on ULA also presents a challenge when multiple routers are present. The default source and destination address selection rules of [RFC6724] only provide priority of ULA over GUA within a single /48 ULA prefix. If ULA is to be preferred over GUA and multiple routers are present in the home network, either the routers will have to co-ordinate selection of a single /48 ULA prefix for use across the entire home network, or all end nodes and routers will have to receive delegated prefixes from each of the union all /48 ULA prefixes in use in the home network, or a non-default address selection policy will have to be distributed to all end nodes in the home network e.g. via [draft-ietf-6man-addr-select-opt-06] Section 2.6. / Ensuring there is a way to access content in the IPv4 Internet. This can be arranged through appropriate use of NAT64 [RFC6144] and DNS64 [RFC6145], for example, or via a node-based DS-Lite [RFC6333] approach./ Can of worms. Out of scope. Long term there will be no IPv4, or IPv4 gateway may be outside of Homenet. Suggest deleting the DNS64 text. Section 3.0 Is zero config a serious requirement? I just replaced a faulty ADSL2+ modem/ router. There's loads of config in there for ATM VC's etc. All I had to do was go to a web page and select my provider from a drop down list. Minimal config and wizard config seems good enough for me and for existing products. s/as far as possible, be self-configuring./as far as possible, be self-configuring, or manual configuration should be kept to a minimum, and possibly aided by user-friendly "wizard" configuration tools./ Section 3.3.1 3 realms gives 3 borders. s/ then the borders will include that from the homenet to the ISP, and that from the homenet to a guest network./ then the borders will include that from the homenet to the ISP,that from the guest network to the ISP, and that from the homenet to a guest network./ Section 3.4.1 / ULAs should be used within the scope of a homenet to support routing between subnets regardless of whether a globally unique ISP-provided prefix is available./ Do we have sufficient knowledge of the current state of play of ULA implementations running in parallel with GUA to be able to make this a "should"? Personally, I'd be perfectly happy with a GUA address scheme as long as my provider gave me DHCP-PD lease times that were an order of magnitude longer than any typical outage (say a week compared to a one day's down-time). On the other hand ULA-only operation should definitely be supported in stand-alone homenets. Section 3.4.4 / In cases where two /48 ULAs are generated within a homenet, the network should still continue to function./ In cases where two /48 ULAs are generated within a homenet, the network should still continue to function, meaning that both ULA prefixes should be used for delegation throughout the homenet./ Section 3.5.1 IPv4 is out of scope. s/In IPv4 NAT networks, the NAT provides an implicit firewall function. [RFC4864] describes a "Simple Security" model for IPv6 networks,/[RFC4864] describes a "Simple Security" model for IPv6 networks,/ s/RFC 4864 implies an IPv6 "default deny" policy for inbound connections be used for similar functionality to IPv4 NAT./RFC 4864 implies an IPv6 "default deny" policy for inbound connections./ s/It should be noted that such a "default deny" approach would effectively replace the need for IPv4 NAT traversal protocols with a need to use a signalling protocol to request a firewall hole be opened./It should be noted that such a "default deny" approach would require use of a signalling protocol to request a firewall hole be opened for inbound connectivity./ Section 3.6.5 s/This could then be used with security settings to designate where a particular application is allowed to connect to or receive traffic from./This could then be used with security settings to designate between which nodes a particular application is allowed to communicate, provided ULA address space is filtered appropriately at the boundary of the realm./ Section 3.7.1 /whether support may be required for IPv6 multicast routing across the scope of the whole homenet/ Section 3.5.1. has already said multicast routing is "desirable", which I consider a mistake in an environment with so many battery-powered devices. Even in wired devices, power consumption is becoming more important (see banning incandescent electric light bulbs), so we should allow devices to enter a low power state whenever possible should they so desire. I think 3.7.1 is more accurate. If site-wide service discovery via multicast is required, it probably implies that site-wide multicast routing is required (unless someone comes up with a subnet to subnet name space forwarder that can take part in two disjoint link-local multicast domains and cope with large-scale topology loops). I don't consider multicast routing in homenet "desirable" on its own. Section 3.7.3 /the homenet will need to uck and tse a local name space/ ? I definitely prefer ULQDN to ALQDN. I still to remain to be convinced why the default name space & name serving scenario cannot be 1) that an IPv6 CER acts as a DHCPv6-PD client 2) that this also triggers the CER to become an authoritative DNS server for the homenet (advertised to local nodes via DHCPv6 or RA, togetehr with appropriate domain search list), 3) that the ISP delegates the reverse resolution zone related to the PD lease to this customer-controlled DNS server 4) plus provides a delegated forward resolution zone to the homenet for the customer to populate e.g. customerXXXX.isp.net on the customer-controlled DNS server If the ISP link goes down, the user can still resolve their own local names (on their own server) 5) If necessary we hide that ISP defined zone in another user friendly name 6) The ISP provides secondary (off site) back up for the user-controlled primary server, via standard DNS zone transfers 7) or the user signs up to a dyndns type service or other DNS service outside of the ISP if she wants to use her own DNS domain. It's the way we've done delegation for years elsewhere on large networks, so why not in the home networks too? Section 3.7.4 /It is highly desirable that the homenet name service must at the very least co-exist with the Internet name service./ I would submit that it is highly desirable that the homenet name service IS the Internet name service. No gateways. No proxies. No 2 way synching of content. No timeout synchronisation problems. No 2nd guessing authority. No complexity of extending DNS e.g. via DNSSEC. No problems with highly mobile devices changing tethering. /As described in [I-D.mglt-homenet-naming-delegation], one approach is to run an authoritative name service in the homenet, most likely on the CER, which caches results, and to have the homenet's ISP provide a secondary name service./ This exactly matches my comment above for 3.7.3. And I think this draft is an excellent straw man that any alternatives should have to beat to be considered for inclusion in homenet as the default solution. I have no problem with "better" or "extended", if that can be clearly demonstrated. /This might imply that state information should be distributed in the homenet, to be recoverable by/to the new CER./ Or backed up to a configuration server hosted at the ISP? e.g. a new DNS primary could populate itself from the ISP secondary server if it detects it has a blank zone file (by querying your own zone name for NS glue records in the delegating DNS). Section 3.7.7 Must also include search domains for local FQDN-derived zones. Nits ==== s/homenet/Homenet/g ? s/and is thus need not be/and thus need not be/ Section 2.5 s/it is better to not expose/it is better not to expose/ s/ideally zero configuration/minimal, and ideally zero configuration/ Section 3.2.1 s/Routing cycles within a topology are in a sense good in that they offer redundancy./Loops within a routed topology are in a sense good in that they offer redundancy./ s/Bridging cyslces can be dangerous /Bridging loops can be dangerous / s/It is only cycles using simple repeaters/It is only loops using simple repeaters/ Section 3.2.2 s/Some may or may not be walled gardens./Some may or may not provide a default route to the Pubic Internet./ Section 3.5.1. s/Where multicast is routed cross a homenet/Where multicast is routed across a homenet/ Section 3.6.3 s/testomony/testimony/ Section 3.7.5 s/ISP should should not /ISP should not / Section 3.7.6 s/dicovery/discovery/ > The open issue is whether the LQDN should be used alongside a global > FQDN if one is available (with appropriate mappings/CNAMEs and reverse > entries to the global FQDN as proposed I think by Curtis), or if the > global domain is available then no local domain should be used. I prefer the latter. To me the easiest way to achieve a simple and clear implementation is to define that a homenet is either stand-alone (with ULA + local name space) or "normally attached" (with FQDN and GUA and sufficient timers and caches to keep it up during temporary outages of the ISP link). I suspect that implementing "sometimes attached" homenets with coexistence of ULA & GUA and LQDN & FQDN is going to be a lot tougher. But maybe some developers can jump in and keep me honest on that assumption. regards, RayH > > One item where there seemed to be a lack of a firm conclusion (despite > some firm statements each way) was the question of using a single > global name space or separate internal and external name spaces. The > current text essentially says: > * The default is to use an ISP-provided domain in the homenet, but > with the user able to use an independent domain name instead if preferred. > * If no global domain is available, the homenet uses either a ULQDN > (preferred) or ALQDN, and these are scoped to the local homenet (i.e. > the homenet can only be reached remotely if using a global domain). > > > > Tim > > On 19 Oct 2012, at 17:00, internet-drafts@ietf.org > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Home Networking Working Group of the >> IETF. >> >> Title : Home Networking Architecture for IPv6 >> Author(s) : Tim Chown >> Jari Arkko >> Anders Brandt >> Ole Troan >> Jason Weil >> Filename : draft-ietf-homenet-arch-05.txt >> Pages : 43 >> Date : 2012-10-19 >> >> Abstract: >> This text describes evolving networking technology within >> increasingly large residential home networks. The goal of this >> document is to define an architecture for IPv6-based home networking, >> while describing the associated principles, considerations and >> requirements. The text briefly highlights the specific implications >> of the introduction of IPv6 for home networking, discusses the >> elements of the architecture, and suggests how standard IPv6 >> mechanisms and addressing can be employed in home networking. The >> architecture describes the need for specific protocol extensions for >> certain additional functionality. It is assumed that the IPv6 home >> network is not actively managed, and runs as an IPv6-only or dual- >> stack network. There are no recommendations in this text for the >> IPv4 part of the network. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-homenet-arch >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-homenet-arch-05 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-05 > From tjc@ecs.soton.ac.uk Mon Oct 22 06:12:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1057321F8BAD for ; Mon, 22 Oct 2012 06:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 5SPEjyUAvzRk for ; Mon, 22 Oct 2012 06:12:54 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 16E1221F8BB1 for ; Mon, 22 Oct 2012 06:12:53 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MDCnK1008786; Mon, 22 Oct 2012 14:12:49 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MDCnK1008786 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350911570; bh=4qPAm1z1FAG0iOWSFRFIWPs2Sig=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=GnDkTC3X006tfsiedQIe/zTJZK6HNIc2nOznEpgFjtRfIjFwdbflkoaY5/6QAM+rM GCNZM37/YAT/HZB54QaSSMEhF0uuf7G204anCcy4YHO15tRInTN/+8KphZE7KLhrc2 Lu7nWSdl+btiwmQ3ZeVSrzSnIqCfrSWvczp+k1vc= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9LECn0430611478ij ret-id none; Mon, 22 Oct 2012 14:12:50 +0100 Received: from ip-205-178.eduroam.soton.ac.uk (ip-205-178.eduroam.soton.ac.uk [152.78.205.178]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MDClJ0025913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 14:12:47 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> Date: Mon, 22 Oct 2012 14:12:47 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> To: Damien Saucez X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LECn043061147800; tid=o9LECn0430611478ij; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MDCnK1008786 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: ray.bellis@nominet.org.uk, "homenet@ietf.org Group" , Wassim Haddad , mark@townsley.net Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:12:55 -0000 On 19 Oct 2012, at 18:01, Damien Saucez wrote: > Regarding all the discussion around this document I think a f2f = discussion could help. >=20 > Would you please give us a time slot to discuss this during next = meeting? Obviously meeting slots are up to the chairs to allocate, but my = understanding is that homenet is not attempting to introduce any new = multihoming solutions. But if there's 'cheap wins' those can be taken. Therefore what seems to be on the table for homenet are: a) approaches like shim6 which rely on host support. The homenet arch = should not preclude those. They are, on paper, here today. b) embracing multiple prefixes and solving that challenge with existing = tools - see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04. This = could be the 'cheap win'. c) adding better tools in a new homenet routing protocol, i.e. = supporting source *and* destination address based routing. This is most = likely some time off. d) NPT66 (RFC6296), which the homenet arch does not recommend, but see = draft-bonica-v6-multihome-03. I would suggest you look at = draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 and see how your = approach compares. Your draft doesn't cite it (and doesn't seem to have = any references yet, but I note that may simply be because it's an early = version). Tim >=20 > Thank you, >=20 > Damien Saucez >=20 > On 11 Oct 2012, at 11:37, Tim Chown wrote: >=20 >> On 1 Oct 2012, at 22:14, Brian E Carpenter = wrote: >>=20 >>> As far as I can tell, multihoming is not mentioned in the homenet = charter, >>> but it is discussed in draft-ietf-homenet-arch, without a clear = conclusion. >>> There is an argument for a specific analysis document on this topic, = before >>> we discuss our favourite solutions. >>=20 >> A homenet arch -05 is about to be published. >>=20 >> As Brian says, there is a brief section in the arch text about = multihoming, which we believe captures all that needs to be said. The = section tries to describe the architectural implications of different = approaches in the context of the architecture goals. For example, = nothing in the architecture should preclude use of shim6, if the hosts = support it. >>=20 >> If people have specific comments on 3.2.4 where this is contained, = please make them and we can consider those. >>=20 >> Tim >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Mon Oct 22 07:22:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D639021F85F5 for ; Mon, 22 Oct 2012 07:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 LyPZFlruqr3m for ; Mon, 22 Oct 2012 07:22:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C59C21F85C1 for ; Mon, 22 Oct 2012 07:22:18 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MEMGHL026504 for ; Mon, 22 Oct 2012 15:22:16 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MEMGHL026504 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350915736; bh=sDiVS8KuAKZfvNQxhyUsOJV1DbI=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Mn5K8saI8phyl4G8gmvSpC/82Yv0SUa8bqvjYB5deWQ2CDOwvFdyPYnr39TlyLg3G YsBX7P9h3SIpV1lVXe5nDsc45OOUkaW3tgcJBa8Jg6THIuV23s6GA3wlDdZmGTVG+q 3xml0UM3KQWI78hGBorukG7kj2cY0t8fr+jtcQWw= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9LFMG0430612149OA ret-id none; Mon, 22 Oct 2012 15:22:16 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MEMEn1015908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 15:22:14 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <50818AED.7090001@mtcc.com> Date: Mon, 22 Oct 2012 15:22:14 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LFMG043061214900; tid=o9LFMG0430612149OA; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MEMGHL026504 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:22:20 -0000 Hi Mike, Thanks for the comments. On 19 Oct 2012, at 18:16, Michael Thomas wrote: > On 10/19/2012 09:36 AM, Tim Chown wrote: >>=20 >>=20 >> We can take comments towards a -06 over the weekend. The most = substantial changes are in the Naming and Service Discovery section = (3.7), so if you have limited time please focus your reading there. >=20 > One thing that I'm not sure whether it's been discussed or not is = service announcement. > By service announcement, I mean where instead of multicasting out a = message looking > for the canonical printer with all of its nasty properties especially = for things with batteries > and lossy/slow networks, a device would instead announce its presence = to something > that would later serve it up (eg, bind9, say). I think this is covered in 3.7.4, certainly possible. > That is, if we can posit a dns repository in our home edge routers, we = can avoid some > of the insanity that ensues when you say that something MUST be = strictly zeroconf. > I think we are long past the days where strict zeroconf should be the = driving principle; > littleconf should be a valid option too. And I don't think this possibility is excluded at all by the current = arch text either. It talks of an authoritative name service running on = the CER, with a dynamic registration service (e.g. dyndns). I have = added 'as far as possible' to the unmanaged text. > Service announcement could also feed into things like Search where = instead of > having preset categories which make sense perhaps only to those who = chose the > category at the factory, we could also have structured and/or = free-form text with > lots of keywords and other identifying information that an indexer = might find useful. That's probably straying a little into the UI side. Again, I don't = think we preclude that. =20 > Mechanistically, we already have things like IXFR for DNS, so it's not = likely that > this is wholesale invention, though it may well involve some tweaks. = IXFR also > gives the possibility for enrollment and access control which is = pretty problematic > with service discovery. I think these issues may come up in the mdnsext BoF - I encourage you to = join that list and give comment there. Tim From tjc@ecs.soton.ac.uk Mon Oct 22 07:26:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEAB21F894D for ; Mon, 22 Oct 2012 07:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 sDTA1RL-lQ9x for ; Mon, 22 Oct 2012 07:26:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 541F621F8976 for ; Mon, 22 Oct 2012 07:26:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MEQV34027393 for ; Mon, 22 Oct 2012 15:26:31 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MEQV34027393 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350915991; bh=rzay43zjTdL4Ap6c3Gu3euDuRe4=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=QrUC+b6NN6ayFjwe4moD7EvuEnr6pbDvpsWkbO7sIXFgL7gqfHitfphnoe8sAjt1e xVbl5o7Qtl5nxDlpIrLQMUM6p5mdMZxeuMKr6b/LIO17o+AQqipAt7xZodInG5LrT2 Mad7CsY0pRnrFXLpk70t6MHAswoyGslkP3Rgn28Q= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9LFQV0430612188du ret-id none; Mon, 22 Oct 2012 15:26:31 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MEQTpx017210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 15:26:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <508185F8.7020104@mtcc.com> Date: Mon, 22 Oct 2012 15:26:29 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <508185F8.7020104@mtcc.com> <4AEFFCDA-CAF0-4164-92DB-EDB98B3B12CC@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LFQV043061218800; tid=o9LFQV0430612188du; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MEQV34027393 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:26:38 -0000 On 19 Oct 2012, at 17:55, Michael Thomas wrote: > On 10/19/2012 09:36 AM, Tim Chown wrote: >> One item where there seemed to be a lack of a firm conclusion = (despite some firm statements each way) was the question of using a = single global name space or separate internal and external name spaces. = The current text essentially says: >> * The default is to use an ISP-provided domain in the homenet, but = with the user able to use an independent domain name instead if = preferred. >> * If no global domain is available, the homenet uses either a ULQDN = (preferred) or ALQDN, and these are scoped to the local homenet (i.e. = the homenet can only be reached remotely if using a global domain). >=20 > If you get an ISP's name couldn't you always with or without their = cooperation > generate names of the form host..isp.net? Where = > is either statistically unique (cf ULA's), or is human-significant and = unique (eg, > host.casasanchez.customers.isp.net). I would assume here that the name the ISP delegates includes such a = unique string, e.g. cust1234.someisp.net. Maybe for an extra fee = they'll let you pick a unique string to replace 'cust1234'. Personally = (and I note at IETF85 we found that half the homenet attendees had 110+ = domains each!) I believe it's important to allow the homenet to use an = ISP-independent domain name as simply as possible. > Doing so would potentially take the "otherness" of .local away, and = make the > human factors issue less stark. Also: if we end up with a repository = in the > CPE, say, it makes transitions between vanity domains, hosted domain = (ala > ISP or some cloud service), and local/isolated domains easier it seems = to me. Certainly keeping as much of this as simple as possible for the homenet = user, while not precluding more advanced options, is important. tim= From tjc@ecs.soton.ac.uk Mon Oct 22 08:58:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0721F8C26 for ; Mon, 22 Oct 2012 08:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_34=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 14hLemuHvcAa for ; Mon, 22 Oct 2012 08:58:30 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 0847E21F8C01 for ; Mon, 22 Oct 2012 08:58:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MFwPSO021243 for ; Mon, 22 Oct 2012 16:58:25 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MFwPSO021243 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350921505; bh=vYZKAbTt+7umpTVcrKyWooT0ne0=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=mQ0175MLNKOjvo1nvW4AwqtvybLpsipR+psgMM3yY31bqAR3d6SYChbXoQkwxYiEw pUrCmem4KU4pYSKLhLp0631D45pkx5RxwYh9Dmmr61PbgJ5rEGDhyYzToy9scTXTth TwcNp6H/wO0WVUK5ArmCOMpLyxZcABpZLdauVWZw= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9LGwP0430613250mA ret-id none; Mon, 22 Oct 2012 16:58:25 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MFwNjb013136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 16:58:24 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <50831676.1070203@globis.net> Date: Mon, 22 Oct 2012 16:58:23 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50831676.1070203@globis.net> <170CE147-21DA-4B77-8F37-2F49FBD0414B@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LGwP043061325000; tid=o9LGwP0430613250mA; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MFwPSO021243 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:58:32 -0000 Hi Ray, Thanks for the thorough review, as always :) On 20 Oct 2012, at 22:24, Ray Hunter wrote: > Thanks for editing this, Tim. >=20 > As requested, comments towards -06 >=20 > Substantive Comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Section 2.1 >=20 > /The addition of routing between subnets raises the issue of how to > extend mechanisms such as service discovery which currently rely on > link-local addressing to limit scope. There are two broad choices; > extend existing protocols to work across the scope of the homenet, or=20= > introduce proxies for existing link layer protocols./ >=20 > I think there is a viable third choice: Take existing (heavyweight) > Internet protocols, like DNS and OSPF, that already scale to cover = large > routed infrastructures, and attempt to reduce the amount of expert > configuration required so that they are suitable for use in networks > that do not enjoy expert management. I think the current text supports this, e.g. using OSPF to carry prefix = information rather than using DHCPv6 PD. It also seems that we're = leaning heavily towards the naming protocol being DNS-based. > By the time we've invented proxies and gateways from current mDNS to = LLN > and Internet DNS, we may well end up spending more effort on two-way > name-space content synchronisation than we'd ever imagine. The example of service discovery above was just that; there may be other = protocols that in current home networks assume a single subnet that may = need similar consideration. I recall we were going to try to list those = at some point - I'm not sure we ever did. Anyway, it's a good point so I have added a bit of text to clarify. > Section 2.4 >=20 > Use of ULA should probably also mention the following challenge: >=20 > Selecting a suitable prefix for use with an address scheme based on = ULA > also presents a challenge when multiple routers are present. The = default > source and destination address selection rules of [RFC6724] only = provide > priority of ULA over GUA within a single /48 ULA prefix. If ULA is to = be > preferred over GUA and multiple routers are present in the home = network, > either the routers will have to co-ordinate selection of a single /48 > ULA prefix for use across the entire home network, or all end nodes = and > routers will have to receive delegated prefixes from each of the union > all /48 ULA prefixes in use in the home network, or a non-default > address selection policy will have to be distributed to all end nodes = in > the home network e.g. via [draft-ietf-6man-addr-select-opt-06] I think there's nothing precluding adding multiple ULA /48's to the = policy table as being local. I have added a note about this to 3.4.2 which talks about stable = internal addresses. > Section 2.6. >=20 > / Ensuring there is a way to access content in the IPv4 Internet. This > can be arranged through appropriate use of NAT64 [RFC6144] and DNS64 > [RFC6145], for example, or via a node-based DS-Lite [RFC6333] = approach./ >=20 > Can of worms. Out of scope. Long term there will be no IPv4, or IPv4 > gateway may be outside of Homenet. Suggest deleting the DNS64 text. I agree this is very tempting, as we say in the intro 'there are no = recommendations in this text for the IPv4 part of the network'. But = this is a brief note, to just indicate that there are complications = accessing legacy IPv4 content for IPv6-only homenets. It would be good to get other comment on this. The text has been kept = deliberately as high-level as possible, e.g. not talking about issues = with where the DNS64 function is hosted, and we state at the end of 2.6 = that the specifics are out of scope of this text. > Section 3.0 >=20 > Is zero config a serious requirement? I just replaced a faulty ADSL2+ > modem/ router. There's loads of config in there for ATM VC's etc. All = I > had to do was go to a web page and select my provider from a drop down > list. Minimal config and wizard config seems good enough for me and = for > existing products. >=20 > s/as far as possible, be self-configuring./as far as possible, be > self-configuring, or manual configuration should be kept to a minimum, > and possibly aided by user-friendly "wizard" configuration tools./ I think you mean 3.3? If so, this uses the phrase 'as far as possible'. = I have also changed 'must be unmanaged' to add the same qualification = in response to Mike's email. > Section 3.3.1 >=20 > 3 realms gives 3 borders. >=20 > s/ then the borders will include that from the homenet to the ISP, and > that from the homenet to a guest network./ then the borders will = include > that from > the homenet to the ISP,that from the guest network to the ISP, and > that from the homenet to a guest network./ Changed. > Section 3.4.1 >=20 > / ULAs should be used within the scope of a homenet to support routing > between subnets regardless of whether a globally unique ISP-provided > prefix is available./ >=20 > Do we have sufficient knowledge of the current state of play of ULA > implementations running in parallel with GUA to be able to make this a > "should"? Personally, I'd be perfectly happy with a GUA address scheme > as long as my provider gave me DHCP-PD lease times that were an order = of > magnitude longer than any typical outage (say a week compared to a one > day's down-time). On the other hand ULA-only operation should = definitely > be supported in stand-alone homenets. We have had this discussion a few times, and the included text was the = consensus, i.e. a homenet should run GUA alongside ULA, rather than just = using the most recent valid GUA. Very happy to hear other comments as to whether there's been a shift = here. > Section 3.4.4 >=20 > / In cases where two /48 ULAs are generated within a homenet, the > network should still continue to function./ In cases where two /48 = ULAs > are generated within a homenet, the network should still continue to > function, meaning that both ULA prefixes should be used for delegation > throughout the homenet./ Do they both need to be delegated, or just routed? For example if two = LLN network gateways pick their own /48? Perhaps something like " = meaning that hosts will need to determine that each ULA is local to the = homenet."? > Section 3.5.1 > IPv4 is out of scope. 3.6.1 I think. > s/In IPv4 NAT networks, the NAT provides an implicit firewall = function. > [RFC4864] describes a "Simple Security" model for IPv6 > networks,/[RFC4864] describes a "Simple Security" model for IPv6 = networks,/ >=20 > s/RFC 4864 implies an IPv6 "default deny" policy for inbound = connections > be used for similar functionality to IPv4 NAT./RFC 4864 implies an = IPv6 > "default deny" policy for inbound connections./ >=20 > s/It should be noted that such a "default deny" approach would > effectively replace the need for IPv4 NAT traversal protocols with a > need to use a signalling protocol to request a firewall hole be > opened./It should be noted that such a "default deny" approach would > require use of a signalling protocol to request a firewall hole be > opened for inbound connectivity./ I think it's useful here to compare the IPv6 approach to what's = commonplace today for IPv4 homenets. So personally I'd prefer to keep = this as is. > Section 3.6.5 > s/This could then be used with security settings to designate where a > particular application is allowed to connect to or receive traffic > from./This could then be used with security settings to designate > between which nodes a particular application is allowed to = communicate, > provided ULA address space is filtered appropriately at the boundary = of > the realm./ Changed. > Section 3.7.1 > /whether support may be required for IPv6 multicast routing across the > scope of the whole homenet/ >=20 > Section 3.5.1. has already said multicast routing is "desirable", = which > I consider a mistake in an environment with so many battery-powered > devices. Even in wired devices, power consumption is becoming more > important (see banning incandescent electric light bulbs), so we = should > allow devices to enter a low power state whenever possible should they > so desire. I have edited 3.5.1 to make this concern/limitation clearer, and removed = mention of it here. > I think 3.7.1 is more accurate. If site-wide service discovery via > multicast is required, it probably implies that site-wide multicast > routing is required (unless someone comes up with a subnet to subnet > name space forwarder that can take part in two disjoint link-local > multicast domains and cope with large-scale topology loops). I don't > consider multicast routing in homenet "desirable" on its own. Agreed. > Section 3.7.3 >=20 > /the homenet will need to uck and tse a local name space/ ? It seems I submitted the pre-ipsell .txt file, sorry :) > I definitely prefer ULQDN to ALQDN. >=20 > I still to remain to be convinced why the default name space & name > serving scenario cannot be > 1) that an IPv6 CER acts as a DHCPv6-PD client > 2) that this also triggers the CER to become an authoritative DNS = server > for the homenet (advertised to local nodes via DHCPv6 or RA, togetehr > with appropriate domain search list), > 3) that the ISP delegates the reverse resolution zone related to the = PD > lease to this customer-controlled DNS server > 4) plus provides a delegated forward resolution zone to the homenet = for > the customer to populate e.g. customerXXXX.isp.net on the > customer-controlled DNS server > If the ISP link goes down, the user can still resolve their own local > names (on their own server) > 5) If necessary we hide that ISP defined zone in another user friendly = name > 6) The ISP provides secondary (off site) back up for the = user-controlled > primary server, via standard DNS zone transfers > 7) or the user signs up to a dyndns type service or other DNS service > outside of the ISP if she wants to use her own DNS domain. >=20 > It's the way we've done delegation for years elsewhere on large > networks, so why not in the home networks too? I believe the current text is fully in line with such an approach - if = it isn't, please highlight where so we can update it. > Section 3.7.4 >=20 > /It is highly desirable that the homenet name service must at the very > least co-exist with the Internet name service./ >=20 > I would submit that it is highly desirable that the homenet name = service > IS the Internet name service. > No gateways. No proxies. No 2 way synching of content. No timeout > synchronisation problems. > No 2nd guessing authority. No complexity of extending DNS e.g. via = DNSSEC. > No problems with highly mobile devices changing tethering. >=20 > /As described in [I-D.mglt-homenet-naming-delegation], one approach is > to run an authoritative name service in the homenet, most likely on = the > CER, which caches results, and to have the homenet's ISP provide a > secondary name service./ >=20 > This exactly matches my comment above for 3.7.3. And I think this = draft > is an excellent straw man that any alternatives should have to beat to > be considered for inclusion in homenet as the default solution. I have > no problem with "better" or "extended", if that can be clearly = demonstrated. OK, I think we're in agreement here then :) If not, please clarify. > /This might imply that state information should be distributed in the > homenet, to be recoverable by/to the new CER./ > Or backed up to a configuration server hosted at the ISP? e.g. a new = DNS > primary could populate itself from the ISP secondary server if it > detects it has a blank zone file (by querying your own zone name for = NS > glue records in the delegating DNS). Yes, that could be an ISP service. I'll add text. > Section 3.7.7 > Must also include search domains for local FQDN-derived zones. Added. > Nits > =3D=3D=3D=3D >=20 > s/homenet/Homenet/g ? I'm OK with little h. > s/and is thus need not be/and thus need not be/ >=20 > Section 2.5 > s/it is better to not expose/it is better not to expose/ >=20 > s/ideally zero configuration/minimal, and ideally zero configuration/ >=20 > Section 3.2.1 > s/Routing cycles within a topology are in a sense good in that they > offer redundancy./Loops within a routed topology are in a sense good = in > that they offer redundancy./ > s/Bridging cyslces can be dangerous /Bridging loops can be dangerous / > s/It is only cycles using simple repeaters/It is only loops using = simple > repeaters/ Corrected - I thought I'd nailed all those! > Section 3.2.2 >=20 > s/Some may or may not be walled gardens./Some may or may not provide a > default route to the Pubic Internet./ >=20 >=20 > Section 3.5.1. > s/Where multicast is routed cross a homenet/Where multicast is routed > across a homenet/ >=20 > Section 3.6.3 > s/testomony/testimony/ >=20 > Section 3.7.5 > s/ISP should should not /ISP should not / >=20 > Section 3.7.6 > s/dicovery/discovery/ All nabbed, thanks - my ispell mistake, sorry. >> The open issue is whether the LQDN should be used alongside a global >> FQDN if one is available (with appropriate mappings/CNAMEs and = reverse >> entries to the global FQDN as proposed I think by Curtis), or if the >> global domain is available then no local domain should be used.=20 > I prefer the latter. OK, that's pretty much what 3.7.3 says. Thanks. > To me the easiest way to achieve a simple and clear > implementation is to define that a homenet is either stand-alone (with > ULA + local name space) or "normally attached" (with FQDN and GUA and > sufficient timers and caches to keep it up during temporary outages of > the ISP link). I suspect that implementing "sometimes attached" = homenets > with coexistence of ULA & GUA and LQDN & FQDN is going to be a lot > tougher. But maybe some developers can jump in and keep me honest on > that assumption. >=20 > regards, > RayH Thanks for all the comments. -06 will be out very soon. Tim >=20 >>=20 >> One item where there seemed to be a lack of a firm conclusion = (despite >> some firm statements each way) was the question of using a single >> global name space or separate internal and external name spaces. The >> current text essentially says: >> * The default is to use an ISP-provided domain in the homenet, but >> with the user able to use an independent domain name instead if = preferred. >> * If no global domain is available, the homenet uses either a ULQDN >> (preferred) or ALQDN, and these are scoped to the local homenet (i.e. >> the homenet can only be reached remotely if using a global domain). >>=20 >>=20 >>=20 >> Tim >>=20 >> On 19 Oct 2012, at 17:00, internet-drafts@ietf.org >> wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Home Networking Working Group of = the >>> IETF. >>>=20 >>> Title : Home Networking Architecture for IPv6 >>> Author(s) : Tim Chown >>> Jari Arkko >>> Anders Brandt >>> Ole Troan >>> Jason Weil >>> Filename : draft-ietf-homenet-arch-05.txt >>> Pages : 43 >>> Date : 2012-10-19 >>>=20 >>> Abstract: >>> This text describes evolving networking technology within >>> increasingly large residential home networks. The goal of this >>> document is to define an architecture for IPv6-based home = networking, >>> while describing the associated principles, considerations and >>> requirements. The text briefly highlights the specific = implications >>> of the introduction of IPv6 for home networking, discusses the >>> elements of the architecture, and suggests how standard IPv6 >>> mechanisms and addressing can be employed in home networking. The >>> architecture describes the need for specific protocol extensions = for >>> certain additional functionality. It is assumed that the IPv6 home >>> network is not actively managed, and runs as an IPv6-only or dual- >>> stack network. There are no recommendations in this text for the >>> IPv4 part of the network. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-homenet-arch >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-homenet-arch-05 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-05 >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Mon Oct 22 09:15:47 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DD521F8923 for ; Mon, 22 Oct 2012 09:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 7wruUOGoRAsc for ; Mon, 22 Oct 2012 09:15:46 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBD221F84C9 for ; Mon, 22 Oct 2012 09:15:45 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9MGF9iB001485 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 09:15:10 -0700 Message-ID: <5085710D.7020503@mtcc.com> Date: Mon, 22 Oct 2012 09:15:09 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Tim Chown References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1398; t=1350922513; x=1351786513; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20service=20announcement=20vs =20service=20discovery |Sender:=20 |To:=20Tim=20Chown=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=sqvGzdzSE4WXxuAiyVmiEt5Mb4MkmUtt25qg5wex+8M=; b=mBOyvc+RXJbrvSioT+Jo8H3HefpaJ/oKz4roBlxQ7mwWCBkCbqqt6vonPA VL60Mz6YGMd96FFc3zpKWP/KPLF2CpfA2RhLCgi5Wd/uIHScokajWeNkKDgO A+qkCuTZ+ZsNSkoS+MzRlikNM0ORapAhUOx8/VauY1LKHRY12KRVY=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:15:47 -0000 On 10/22/2012 07:22 AM, Tim Chown wrote: > > And I don't think this possibility is excluded at all by the current arch text either. It talks of an authoritative name service running on the CER, with a dynamic registration service (e.g. dyndns). I have added 'as far as possible' to the unmanaged text. It's been hard for me to gauge what is and isn't in scope on the naming front. For the most part, this wg looks like it's only interested in putting some band-aides on mdns/dns-sd. That's a mistake, IMO, because there's nothing inevitable about a zeroconf driven design. We should consider littleconf solutions especially for naming because there is no way that mikes-toothbrush.mtcc.com got named that way coming from the factory. > >> Mechanistically, we already have things like IXFR for DNS, so it's not likely that >> this is wholesale invention, though it may well involve some tweaks. IXFR also >> gives the possibility for enrollment and access control which is pretty problematic >> with service discovery. > I think these issues may come up in the mdnsext BoF - I encourage you to join that list and give comment there. > Correct me if I'm wrong, but I'd think that a mdnsext bof is interested in extending mdns. What I'm talking about has nothing to do with multicast, dns or otherwise. So I'm not sure that my participation would be all that welcome. Mike From internet-drafts@ietf.org Mon Oct 22 09:23:39 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EAF21F8BC0; Mon, 22 Oct 2012 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 ro+vKn8QLTjX; Mon, 22 Oct 2012 09:23:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B349D21F8B9F; Mon, 22 Oct 2012 09:23:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022162338.15335.86285.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 09:23:38 -0700 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-06.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:23:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Architecture for IPv6 Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-06.txt Pages : 44 Date : 2012-10-22 Abstract: This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define an architecture for IPv6-based home networking, while describing the associated principles, considerations and requirements. The text briefly highlights the specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual- stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kerlyn2001@gmail.com Mon Oct 22 09:31:00 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8194421F89B5 for ; Mon, 22 Oct 2012 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 5JXjArK+n3dU for ; Mon, 22 Oct 2012 09:30:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE921F897C for ; Mon, 22 Oct 2012 09:30:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2074926lbo.31 for ; Mon, 22 Oct 2012 09:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uEh9MBZ+0vE3x7TzRzj1qEHZ1VUMze1QMIqtyXJjNR8=; b=DokoIo8kBFqWuAMvIgUYADVdRgU1s7syUsB2Y/oAjEAQa6CEccD1TaI921YP2nGxfw caBJmbiGpIeeWuGUyyQxe22coYQvmS3Ka6dnUeSyQIP1XsnpCT9wk7SIeX6zdvm23c1n OqmPzqYO1HBDu4PwiU0zo/3XxyO7/ie89Smw8uwq1FjOMnE4gq2EhSmV61euAR24CNyF UFItBJHqQzwPrPeO5P/A8casFZSvFot/mnivLKSBxT1csycEgahyaEGmk5SCwHPmXUbx e0dHAaKcWrf5fw2hBNHQpK47piw4S0X+5370YbD0xVRT9PZTTy5iS1Yv3qhs5iuQxcCC BTkw== MIME-Version: 1.0 Received: by 10.152.48.111 with SMTP id k15mr8760875lan.17.1350923457708; Mon, 22 Oct 2012 09:30:57 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.82.9 with HTTP; Mon, 22 Oct 2012 09:30:57 -0700 (PDT) In-Reply-To: <5085710D.7020503@mtcc.com> References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> <5085710D.7020503@mtcc.com> Date: Mon, 22 Oct 2012 12:30:57 -0400 X-Google-Sender-Auth: ziHuc5zn_kGp6SrSV-9LNrx4Omo Message-ID: From: Kerry Lynn To: Michael Thomas Content-Type: multipart/alternative; boundary=bcaec55243b0d0c2f104cca86067 Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:31:00 -0000 --bcaec55243b0d0c2f104cca86067 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 22, 2012 at 12:15 PM, Michael Thomas wrote: > On 10/22/2012 07:22 AM, Tim Chown wrote: > >> >> And I don't think this possibility is excluded at all by the current arch >> text either. It talks of an authoritative name service running on the CER, >> with a dynamic registration service (e.g. dyndns). I have added 'as far as >> possible' to the unmanaged text. >> > > It's been hard for me to gauge what is and isn't in scope on the naming > front. For the most part, this wg looks like it's only interested in > putting > some band-aides on mdns/dns-sd. That's a mistake, IMO, because there's > nothing inevitable about a zeroconf driven design. We should consider > littleconf solutions especially for naming because there is no way that > mikes-toothbrush.mtcc.com got named that way coming from the factory. > Not sure how you can draw that conclusion; there seem to be lovers and haters of mDNS. To the extent that it's unsuited for multi-link topologies, a BoF has been approved to discuss problems and requirements. I hope that folks interested in a DNS-based solution to service discovery and naming will join the mdnsext mailing list. I have nothing wrong with littleconf per se, but there seems to me a chicken and egg problem: how does one engage a device (presumably running a web-based UI) initially in order to administer it? Is that by address or by name? If by name, then how does it work? > > >> Mechanistically, we already have things like IXFR for DNS, so it's not >>> likely that >>> this is wholesale invention, though it may well involve some tweaks. >>> IXFR also >>> gives the possibility for enrollment and access control which is pretty >>> problematic >>> with service discovery. >>> >> I think these issues may come up in the mdnsext BoF - I encourage you to >> join that list and give comment there. >> >> Correct me if I'm wrong, but I'd think that a mdnsext bof is interested > in > extending mdns. What I'm talking about has nothing to do with multicast, > dns or otherwise. So I'm not sure that my participation would be all that > welcome. > > The mdnsext BoF is interested in extensions to DNS-SD and mDNS, including the possibility of using the latter to bootstrap (seed) a DNS directory, perhaps under some guidance from a lay user. Regards, -K- Mike > > ______________________________**_________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/**listinfo/homenet > --bcaec55243b0d0c2f104cca86067 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2012 at 12:15 PM, Michael Thomas <mike@mtcc.com>= wrote:
On 10/22/2012 07:22 AM, Tim Chown wrote:

And I don't think this possibility is excluded at all by the current ar= ch text either. It talks of an authoritative name service running on the CE= R, with a dynamic registration service (e.g. dyndns). =A0I have added '= as far as possible' to the unmanaged text.

It's been hard for me to gauge what is and isn't in scope on the na= ming
front. For the most part, this wg looks like it's only interested in pu= tting
some band-aides on mdns/dns-sd. That's a mistake, IMO, because there= 9;s
nothing inevitable about a zeroconf driven design. We should consider
littleconf solutions especially for naming because there is no way that
mikes-toothb= rush.mtcc.com got named that way coming from the factory.

Not sure how you can draw that c= onclusion; there seem to be lovers and
haters of mDNS. =A0To the extent that it's unsuited for multi-link= topologies,
a BoF has been approved=A0to discuss problems and re= quirements. =A0I hope
that folks interested in a DNS-based soluti= on to service discovery and
naming will join the mdnsext mailing list.

I = have nothing wrong with littleconf per se, but there seems to me a chicken<= /div>
and egg problem: how does one engage a device (presumably running= a
web-based UI)=A0initially in order to administer it? =A0Is that by add= ress or by
name? =A0If by name, then how does it work?
=A0

Mechanistically, we already have things like IXFR for DNS, so it's not = likely that
this is wholesale invention, though it may well involve some tweaks. IXFR a= lso
gives the possibility for enrollment and access control which is pretty pro= blematic
with service discovery.
I think these issues may come up in the mdnsext BoF - I encourage you to jo= in that list and give comment there.

Correct me if I'm wrong, but I'd think that a mdnsext bof is intere= sted in
extending mdns. What I'm talking about has nothing to do with multicast= ,
dns or otherwise. So I'm not sure that my participation would be all th= at
welcome.

The mdnsext BoF is interested in extensions to DNS-SD= and mDNS, including
the possibility of using the latter to boots= trap (seed) a DNS directory, perhaps
under some guidance from a l= ay user.

Regards, -K-

Mike

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

--bcaec55243b0d0c2f104cca86067-- From brian.e.carpenter@gmail.com Mon Oct 22 09:31:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E327421F8674 for ; Mon, 22 Oct 2012 09:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.676 X-Spam-Level: X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7h9uw3SEj9Z for ; Mon, 22 Oct 2012 09:31:54 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE39B21F8519 for ; Mon, 22 Oct 2012 09:31:53 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1007195bkc.31 for ; Mon, 22 Oct 2012 09:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SlwnD7k/yFdzB53eToYNZMh4KVWBieyeqPvKvTbMYLc=; b=q5VtyfS2K9/TeKDc4GTMSc9U9quhjeFOEDGqbmyzk+0GRT4JM4HR7Xl8CUyew98GIJ 2n0xetM7kptSxIvyF2WPSFyVdsVmBhYzIYZt99tG14oDWS57eRYGfcP7B215IZZMOBj6 hiOividIMYmQETeuKtzOCCJfYimWwwhIcSHK/Lebo87EkYXI2fS/2dNVXNhDlcRYBqgC 7Pm/AS9lsLBhprRYJMIrGidUXG+gwtfv1fvvplbE2dhHNq0NwaTY/33IpAzvHI1Epvyz sLYnr28Irga92unUkccTXTVTR7dUjFEdZjOR+pEMXJvoFzFbe87IY8WiCyBNTh6FJj5P P+ng== Received: by 10.205.127.146 with SMTP id ha18mr2924113bkc.130.1350923512832; Mon, 22 Oct 2012 09:31:52 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-216-204.as13285.net. [2.102.216.204]) by mx.google.com with ESMTPS id z22sm4152127bkw.2.2012.10.22.09.31.50 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 09:31:51 -0700 (PDT) Message-ID: <508574F5.3030504@gmail.com> Date: Mon, 22 Oct 2012 17:31:49 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> In-Reply-To: <50818AED.7090001@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:31:55 -0000 On 19/10/2012 18:16, Michael Thomas wrote: > On 10/19/2012 09:36 AM, Tim Chown wrote: >> >> >> We can take comments towards a -06 over the weekend. The most >> substantial changes are in the Naming and Service Discovery section >> (3.7), so if you have limited time please focus your reading there. > > One thing that I'm not sure whether it's been discussed or not is > service announcement. > By service announcement, I mean where instead of multicasting out a > message looking > for the canonical printer with all of its nasty properties especially > for things with batteries > and lossy/slow networks, a device would instead announce its presence to > something > that would later serve it up (eg, bind9, say). e.g. an SLP Directory Agent, designed for this purpose some years ago. [RFC2608], [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832] This is not exactly a new problem. Brian > > That is, if we can posit a dns repository in our home edge routers, we > can avoid some > of the insanity that ensues when you say that something MUST be strictly > zeroconf. > I think we are long past the days where strict zeroconf should be the > driving principle; > littleconf should be a valid option too. > > Service announcement could also feed into things like Search where > instead of > having preset categories which make sense perhaps only to those who > chose the > category at the factory, we could also have structured and/or free-form > text with > lots of keywords and other identifying information that an indexer > might find useful. > > Mechanistically, we already have things like IXFR for DNS, so it's not > likely that > this is wholesale invention, though it may well involve some tweaks. > IXFR also > gives the possibility for enrollment and access control which is pretty > problematic > with service discovery. > > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From mike@mtcc.com Mon Oct 22 09:43:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0C211E808D for ; Mon, 22 Oct 2012 09:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPDub16HK6Gt for ; Mon, 22 Oct 2012 09:43:14 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id BE9A611E80AE for ; Mon, 22 Oct 2012 09:43:13 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9MGgVbg011098 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 09:42:31 -0700 Message-ID: <50857777.7050508@mtcc.com> Date: Mon, 22 Oct 2012 09:42:31 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Kerry Lynn References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> <5085710D.7020503@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2147; t=1350924155; x=1351788155; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20service=20announcement=20vs =20service=20discovery |Sender:=20 |To:=20Kerry=20Lynn=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=J17opATDBL6L9y876IZ4/Io1Sz7/v258KxLEGTXDCaU=; b=fGLLNXaLswZLRAcRZSzg+4Ewmzv7MwzajD3Q4zZrV/i7/a9B0NFcjCSsK5 ZtgPfBMonPZtw65SdqaAhVTHnyYhgGE8qysaTpf7tgIiFGVgGT76zq8A/kaN Ll5tyPiwt3JpZ10c+fNTfxeb7L9L35EQrxCJHTzBoBK7NfXm2tjIQ=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:43:14 -0000 On 10/22/2012 09:30 AM, Kerry Lynn wrote: > On Mon, Oct 22, 2012 at 12:15 PM, Michael Thomas > wrote: > > On 10/22/2012 07:22 AM, Tim Chown wrote: > > > And I don't think this possibility is excluded at all by the current arch text either. It talks of an authoritative name service running on the CER, with a dynamic registration service (e.g. dyndns). I have added 'as far as possible' to the unmanaged text. > > > It's been hard for me to gauge what is and isn't in scope on the naming > front. For the most part, this wg looks like it's only interested in putting > some band-aides on mdns/dns-sd. That's a mistake, IMO, because there's > nothing inevitable about a zeroconf driven design. We should consider > littleconf solutions especially for naming because there is no way that > mikes-toothbrush.mtcc.com got named that way coming from the factory. > > > Not sure how you can draw that conclusion; there seem to be lovers and > haters of mDNS. To the extent that it's unsuited for multi-link topologies, > a BoF has been approved to discuss problems and requirements. I hope > that folks interested in a DNS-based solution to service discovery and > naming will join the mdnsext mailing list. As I mentioned, what I'm thinking about doesn't need multicast at all. So it would be pretty bizarre to discuss getting rid of the need for multicast dns on a mailing list that is bent on extending it. > > I have nothing wrong with littleconf per se, but there seems to me a chicken > and egg problem: how does one engage a device (presumably running a > web-based UI) initially in order to administer it? Is that by address or by > name? If by name, then how does it work? The device just announces itself to a repository, and the repository serves up its name. No need to multicast each time you need to resolve a name, it just unicasts it or maybe anycasts it at boot time, perhaps on a renewal timer. If the rfc's that Brian's note references are applicable, so much the better. Mike From tjc@ecs.soton.ac.uk Mon Oct 22 10:17:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BBE21F847F for ; Mon, 22 Oct 2012 10:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 np0I5eCC2NA7 for ; Mon, 22 Oct 2012 10:17:32 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED7111E80A4 for ; Mon, 22 Oct 2012 10:17:32 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MHHSxn005482 for ; Mon, 22 Oct 2012 18:17:28 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MHHSxn005482 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350926248; bh=0WeHa4+zmGdItKCt93hQII/doDc=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=p2isqixkDaTb4G96qmtlGmnHDp4fWOvHJaJOoqxhyuDlClJZCjiZoDQe6u+Ncru85 OPZ1Nu/xt6SB4UlH8iy3m5MeO11ihXZHoJZAY9baPZ4wK4mqnIiavCVwbWqw683DOv aABntu2lpsxNdZWx2Zb7JdsSga4vAkMhdfppeuy8= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9LIHS0430613801jj ret-id none; Mon, 22 Oct 2012 18:17:28 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MHGsG4002113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 18:16:55 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <20121022162338.15335.86285.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 18:16:55 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20121022162338.15335.86285.idtracker@ietfa.amsl.com> <51CD0E39-EE34-4B7D-A50A-C68F0892993B@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LIHS043061380100; tid=o9LIHS0430613801jj; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MHHSxn005482 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [homenet] draft-ietf-homenet-arch-06.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:17:35 -0000 Hi, The -06 that I've just posted includes some comments made since last = Friday. Tim On 22 Oct 2012, at 17:23, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Home Networking Working Group of the = IETF. >=20 > Title : Home Networking Architecture for IPv6 > Author(s) : Tim Chown > Jari Arkko > Anders Brandt > Ole Troan > Jason Weil > Filename : draft-ietf-homenet-arch-06.txt > Pages : 44 > Date : 2012-10-22 >=20 > Abstract: > This text describes evolving networking technology within > increasingly large residential home networks. The goal of this > document is to define an architecture for IPv6-based home = networking, > while describing the associated principles, considerations and > requirements. The text briefly highlights the specific implications > of the introduction of IPv6 for home networking, discusses the > elements of the architecture, and suggests how standard IPv6 > mechanisms and addressing can be employed in home networking. The > architecture describes the need for specific protocol extensions for > certain additional functionality. It is assumed that the IPv6 home > network is not actively managed, and runs as an IPv6-only or dual- > stack network. There are no recommendations in this text for the > IPv4 part of the network. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-arch >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-homenet-arch-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-06 From mike@mtcc.com Mon Oct 22 10:31:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665B611E80E0 for ; Mon, 22 Oct 2012 10:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 CAknuLsbVW92 for ; Mon, 22 Oct 2012 10:31:00 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id DD19311E80DE for ; Mon, 22 Oct 2012 10:30:59 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9MHUIX7027552 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 10:30:18 -0700 Message-ID: <508582AA.3030900@mtcc.com> Date: Mon, 22 Oct 2012 10:30:18 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> <508574F5.3030504@gmail.com> In-Reply-To: <508574F5.3030504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1421; t=1350927021; x=1351791021; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20service=20announcement=20vs =20service=20discovery |Sender:=20 |To:=20Brian=20E=20Carpenter=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=iPH5KvMnYA6o55tgzU9K+R7mOJHIdKFndisJ9ufiVQk=; b=C8ks55LSOllVjrtYZtSnbTSH77NLmFTlAWmF4owYwgCedwcvwoe+pJIFAw 8eEVoYMQFlOI7cSWvlhjJZcXSnZI71qouBRmEJxM7jdoJ6epvhDBKq1wDVMn am5R+5z3+kkUuWRJoqx0xWs0il8dlbWVPHcUvTZx/RQdWdvICSbis=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:31:01 -0000 On 10/22/2012 09:31 AM, Brian E Carpenter wrote: > On 19/10/2012 18:16, Michael Thomas wrote: >> On 10/19/2012 09:36 AM, Tim Chown wrote: >>> >>> We can take comments towards a -06 over the weekend. The most >>> substantial changes are in the Naming and Service Discovery section >>> (3.7), so if you have limited time please focus your reading there. >> One thing that I'm not sure whether it's been discussed or not is >> service announcement. >> By service announcement, I mean where instead of multicasting out a >> message looking >> for the canonical printer with all of its nasty properties especially >> for things with batteries >> and lossy/slow networks, a device would instead announce its presence to >> something >> that would later serve it up (eg, bind9, say). > e.g. an SLP Directory Agent, designed for this purpose some years ago. > [RFC2608], [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832] > This is not exactly a new problem. > I looked this over, and I don't think it's what I'm thinking of. I'm thinking of literally having a device do an IXFR to a real DNS server. Or something that looks pretty similar to an IXFR, but the key being that it's a real DNS server. No multicast required ever. In any case, even if this isn't new ground maybe the problem was that they didn't hitch their wagon to DNS. Deployment of SLP is I'm guessing pretty thin. Mike From jhw@apple.com Mon Oct 22 10:43:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE7121F894D for ; Mon, 22 Oct 2012 10:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjj7LVaU07Ra for ; Mon, 22 Oct 2012 10:43:22 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 81BAB21F889F for ; Mon, 22 Oct 2012 10:43:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MCB00JGJ2HV0854@mail-out.apple.com> for homenet@ietf.org; Mon, 22 Oct 2012 10:43:19 -0700 (PDT) X-AuditID: 11807136-b7f616d000005570-7e-508585b633f7 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 49.45.21872.7B585805; Mon, 22 Oct 2012 10:43:19 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MCB00H9B2JYK360@fenugreek.apple.com> for homenet@ietf.org; Mon, 22 Oct 2012 10:43:18 -0700 (PDT) From: james woodyatt In-reply-to: Date: Mon, 22 Oct 2012 10:43:10 -0700 Message-id: <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1620) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUi2FCcqLu9tTXAYOFpAYv3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoErY9vV7ewFx5gr3i97wdLA+JSpi5GTQ0LAROL0vOOMELaYxIV7 69m6GLk4hARmMEnsWrsEypnHJLHg+g2wKmYBLYn1O4+DdfMK6ElMnzCRBcQWFnCVOHFwKZjN JqAi8e3yXSaQZk6BdkaJU98XsoIkWARUJaZv2MQEMUhfonfPQzYIW1viybsLrBBDbSQ+3d7H DrH5H7PE4Xf7wYpEBJQl3s77D3WrrMTia+uYJzAKzEJy1CwkR81CMncBI/MqRsGi1JzESkNT vcSCgpxUveT83E2M4AAsNNvBuOOv3CFGAQ5GJR7exustAUKsiWXFlbmHGCU4mJVEeJUDWgOE eFMSK6tSi/Lji0pzUosPMUpzsCiJ82b7NwQICaQnlqRmp6YWpBbBZJk4OKUaGLP+WOk1p2w7 eenDxO/hipx13q3xT9UkXm48aMo6d8YvqWaLn1b/b3vMDDaoF84z/2bz3WT7vEeTNCKj8hZU Bd/aICY/x622/0inzuvXf5m+brwT6uTkNPdj07Vnt5ez/b6RcGdJ5J2q1kdXWKRYPfY+fy5Y 5di+QG2qBPMs6eT+osNsbSKrM5VYijMSDbWYi4oTAZ0tr/E8AgAA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:43:24 -0000 On Oct 22, 2012, at 06:12 , Tim Chown wrote: > > Therefore what seems to be on the table for homenet are: > [...] > d) NPT66 (RFC6296), which the homenet arch does not recommend, but see draft-bonica-v6-multihome-03. > [...] Why is this option still on the table? Who is arguing for it? Can we strengthen HOMENET arch to deprecate NPT66 explicitly? -- james woodyatt core os networking From mellon@fugue.com Mon Oct 22 10:47:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4769E11E80DF for ; Mon, 22 Oct 2012 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 GBfh8s8ctJmg for ; Mon, 22 Oct 2012 10:47:49 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 43C8511E80A4 for ; Mon, 22 Oct 2012 10:47:49 -0700 (PDT) Received: from kali-6.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 5433B238092A; Mon, 22 Oct 2012 13:47:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> Date: Mon, 22 Oct 2012 13:47:45 -0400 Content-Transfer-Encoding: 7bit Message-Id: <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1499) Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:47:51 -0000 On Oct 22, 2012, at 1:43 PM, james woodyatt wrote: > Can we strengthen HOMENET arch to deprecate NPT66 explicitly? Yes, please. From tjc@ecs.soton.ac.uk Mon Oct 22 11:08:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1740311E80E0 for ; Mon, 22 Oct 2012 11:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 Ii9vkpQb2Pr2 for ; Mon, 22 Oct 2012 11:08:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3C81B11E80A4 for ; Mon, 22 Oct 2012 11:08:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MI8rKJ015438 for ; Mon, 22 Oct 2012 19:08:53 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MI8rKJ015438 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350929333; bh=YJcrWTDV1T+E9Ml7z73ZEy5EI/c=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Kg5DfcGdz02/rbBRJ8aqr7OJRo87O2I3PnId/kACT+I/LDg4mlmL9QqRQSZzQRrbu a/1C2W/ZvbnzSNc31qky0YFVt+zdD3uhujgc6XoUdHJB4y5AZr/lCsIWAVuWJrVtLw C1+h8tpGyLEYnYduWe2xTysEtoBN7jEeKZe4M6PU= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9LJ8r0430614075XL ret-id none; Mon, 22 Oct 2012 19:08:53 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MI7ZR1014231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 19:07:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> Date: Mon, 22 Oct 2012 19:07:35 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LJ8r043061407500; tid=o9LJ8r0430614075XL; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MI8rKJ015438 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:08:56 -0000 On 22 Oct 2012, at 18:47, Ted Lemon wrote: > On Oct 22, 2012, at 1:43 PM, james woodyatt wrote: >> Can we strengthen HOMENET arch to deprecate NPT66 explicitly? >=20 > Yes, please. I meant 'on the table' as there is a draft out there = (draft-bonica-v6-multihome-03.) describing how to do it. If there's consensus to explicitly recommend against it in homenet-arch, = we can do that. Personally, I would not like to see NPT66 deployed in = home networks. It would be interesting to hear Fred, Margaret and Ron's views, as the = authors of the above. Perhaps their target is managed enterprises... Tim= From mike@mtcc.com Mon Oct 22 11:28:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C232A11E80EE for ; Mon, 22 Oct 2012 11:28:52 -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 hlXXfBMJtp3t for ; Mon, 22 Oct 2012 11:28:52 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 1D24611E80A2 for ; Mon, 22 Oct 2012 11:28:51 -0700 (PDT) Received: from sjc-vpn4-266.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9MISleE015156 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 22 Oct 2012 11:28:48 -0700 Message-ID: <5085905A.8030206@mtcc.com> Date: Mon, 22 Oct 2012 11:28:42 -0700 From: mike User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=983; t=1350930531; x=1351794531; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20mike=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=s/yo5Jjp0RVbJQwBWgWPTyS6WJSQuo6R+NC+IceBpKk=; b=mUqCPlhNj97MY/a2Z9jePI37z1xrSTMovuL+eNZhoMf0KWDgZ2qvn4MghM TH011iLkfTXreyN5tWdxG6v2gkOQkJ4PYxnPA0C1GGFVZfrhnLqI0Etp/19h YDzuHAbvIjXrq7fPLUoq4uqtPGRIBn1HQuVESzfRRjaZSC1Ku7Dl0=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:28:52 -0000 On 10/22/12 11:07 AM, Tim Chown wrote: > On 22 Oct 2012, at 18:47, Ted Lemon wrote: > >> On Oct 22, 2012, at 1:43 PM, james woodyatt wrote: >>> Can we strengthen HOMENET arch to deprecate NPT66 explicitly? >> Yes, please. > I meant 'on the table' as there is a draft out there (draft-bonica-v6-multihome-03.) describing how to do it. > > If there's consensus to explicitly recommend against it in homenet-arch, we can do that. Personally, I would not like to see NPT66 deployed in home networks. > > It would be interesting to hear Fred, Margaret and Ron's views, as the authors of the above. Perhaps their target is managed enterprises... > I'd say that until we have source address selection that actually works and is widely deployed, that taking anything off the table is premature. Source address selection applies just as much on a homenet as anyplace else. Probably even moreso when you consider corporate VPN's. Mike From mike@mtcc.com Mon Oct 22 11:50:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BEF21F8880 for ; Mon, 22 Oct 2012 11:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4+b7YtgifJH for ; Mon, 22 Oct 2012 11:50:02 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id AF3EC21F84FE for ; Mon, 22 Oct 2012 11:50:02 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9MInR2x022537 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 11:49:27 -0700 Message-ID: <50859537.2040906@mtcc.com> Date: Mon, 22 Oct 2012 11:49:27 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Tim Chown References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <508185F8.7020104@mtcc.com> <4AEFFCDA-CAF0-4164-92DB-EDB98B3B12CC@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1249; t=1350931770; x=1351795770; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-iet f-homenet-arch-05.txt |Sender:=20 |To:=20Tim=20Chown=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=zgj6p2oKeQPCbbdw7mCCBTUhyMe6X/92785CtAIZcGo=; b=BE0tQ65FkNIsHLmOEZjc78uIpXYWwc6HKcnyRYpLhfXjIYspqf6oyFWfmE tatWxox1H+nmSfjvMnU8hXdSJKZ1DWjlSKqkhQLvop/xbnJokn6u/Ih0FuKQ Fvdt/eRe4uHkVIcG7hj/mgXIxLni1YuI4arHfYcDEDE0hb+rOIyHI=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:50:04 -0000 On 10/22/2012 07:26 AM, Tim Chown wrote: > On 19 Oct 2012, at 17:55, Michael Thomas wrote: > >> >> If you get an ISP's name couldn't you always with or without their cooperation >> generate names of the form host..isp.net? Where >> is either statistically unique (cf ULA's), or is human-significant and unique (eg, >> host.casasanchez.customers.isp.net). > I would assume here that the name the ISP delegates includes such a unique string, e.g. cust1234.someisp.net. Maybe for an extra fee they'll let you pick a unique string to replace 'cust1234'. Personally (and I note at IETF85 we found that half the homenet attendees had 110+ domains each!) That's assuming that the ISP knows anything about me camping on their namespace at all. If I run a DNS locally -- say in my home router -- I could use their name space regardless of whether they sanction it or not. It might only work in my home, of course (ie, users of my DNS server that is camping on somebody else's namespace). > I believe it's important to allow the homenet to use an ISP-independent domain name as simply as possible. Right, and is the reason that the DHCP linkage of the Orange draft is problematic. Mike From jhw@apple.com Mon Oct 22 11:57:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2233E21F8909 for ; Mon, 22 Oct 2012 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBxdsFYj68yi for ; Mon, 22 Oct 2012 11:57:51 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id CD11321F88FC for ; Mon, 22 Oct 2012 11:57:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MCB007ZZ606O020@mail-out.apple.com> for homenet@ietf.org; Mon, 22 Oct 2012 11:57:49 -0700 (PDT) X-AuditID: 11807134-b7f346d0000074ea-ac-5085972db692 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id C8.82.29930.D2795805; Mon, 22 Oct 2012 11:57:49 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MCB00H8F60CK380@fenugreek.apple.com> for homenet@ietf.org; Mon, 22 Oct 2012 11:57:49 -0700 (PDT) From: james woodyatt In-reply-to: <5085905A.8030206@mtcc.com> Date: Mon, 22 Oct 2012 11:57:48 -0700 Message-id: <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> To: mike X-Mailer: Apple Mail (2.1620) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUi2FCcqKs7vTXA4MM1eYv3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/GVySwF1/gq5my7w9TA+Ji7i5GTQ0LARGL6s6dsELaYxIV7 64FsLg4hgRlMEk2LTjFBOPOYJPp2b2QHqWIW0JJYv/M4E4jNK6AnMX3CRBYQW1jAVeLEwaVg NpuAisS3y3fBajgFNCT2t25gBbFZBFQlZpy6zggxR0Ri68fTTBC2tsSTdxdYIWbaSPSsWAe1 eBubxO72TWDniQhISDQuWsgCcaqsxOJr65gnMArMQnLTLCQ3zUIydwEj8ypGwaLUnMRKQxO9 xIKCnFS95PzcTYzg8Cs02cF48Cf/IUYBDkYlHt5bN1sChFgTy4orcw8xSnAwK4nwKge0Bgjx piRWVqUW5ccXleakFh9ilOZgURLnzfRvCBASSE8sSc1OTS1ILYLJMnFwSjUwyss6r7nTvriT SXfC8qqTbQyFrA6ypVWbKu+K+X6e2W89Vyu3/fjrZCYz7ZaL1+L2sk8NKwlbdvbY2YMtt/tq /idZ86u/ydZgK00/Y3Dgr/dP21WP3+z1NrH86tHLqph2ak/u66iQ0EsrJ33bx7VOg2Pilm8T Bc13iNgzCBsJrn24JawtLbRXiaU4I9FQi7moOBEAIAH1IDsCAAA= Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:57:52 -0000 On Oct 22, 2012, at 11:28 , mike wrote: > > I'd say that until we have source address selection that actually works and is widely > deployed, that taking anything off the table is premature. Source address selection > applies just as much on a homenet as anyplace else. Disagree. My opinion is that the potential for catastrophic damage to the utility of the Internet by the ubiquitous deployment of NPT66 in residential gateways poses too grave a risk for us to continue seriously entertaining it as a viable approach to any of the problems in our ambit. I would say that it MUST be deprecated by the arch document. For anyone arguing in favor of using NPT66 in residential gateways, I think it's fair to ask them for solutions to the problem statement in I-D.carpenter-referral-ps in support of that idea. Referral in IPv4 was badly broken by the introduction of NAT44, and the ubiquitous deployment of NPT66 in residential gateways would repeat the error with IPv6. I would say HOMENET should not be seriously considering that as an option. Is there any significant disagreement on that point? Are there people here who might be willing to stand up and argue that the referral problem is secondary to other objectives well served by deploying NPT66 in home network access routers? If so, then what are those objectives? I'm having a hard time understanding what they might be. > Probably even moreso when you consider corporate VPN's. Actually, VPN is usually just a special case of MIF, i.e. individual hosts are multihomed, not the whole homenet. This is a much simpler situation to manage, and solutions for that space are already ubiquitous. -- james woodyatt core os networking From mike@mtcc.com Mon Oct 22 12:03:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D60421F8B3E for ; Mon, 22 Oct 2012 12:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 kYAtPEtV6NFJ for ; Mon, 22 Oct 2012 12:03:13 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id A239E21F8A25 for ; Mon, 22 Oct 2012 12:03:11 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9MJ0S5U026311 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 12:00:30 -0700 Message-ID: <508597CC.3040700@mtcc.com> Date: Mon, 22 Oct 2012 12:00:28 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Kerry Lynn References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> <5085710D.7020503@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1606; t=1350932433; x=1351796433; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20service=20announcement=20vs =20service=20discovery |Sender:=20 |To:=20Kerry=20Lynn=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=aIr7AM4zTLeq1vJIpIyXQ0CMZmjaDbJYB25ZgUl1fGM=; b=gw5xUwspDPHJtyrtxbuZJ1M4HY3bAifOfKxMcupS3QqkIDuBrRvLwHFjtm r1PsUAxYBM5Gl8E6PG0qGcd24M1PUJ+q0UOGrOmRUoTSVoNSAffyYLZvdjfP rqsLH8CMsZGk2XrApKcYOED6qWcAlJZqnSrREkV0NArd8qd81OzSI=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:03:14 -0000 On 10/22/2012 09:30 AM, Kerry Lynn wrote: > On Mon, Oct 22, 2012 at 12:15 PM, Michael Thomas > wrote: > > On 10/22/2012 07:22 AM, Tim Chown wrote: > > > And I don't think this possibility is excluded at all by the current arch text either. It talks of an authoritative name service running on the CER, with a dynamic registration service (e.g. dyndns). I have added 'as far as possible' to the unmanaged text. > > > It's been hard for me to gauge what is and isn't in scope on the naming > front. For the most part, this wg looks like it's only interested in putting > some band-aides on mdns/dns-sd. That's a mistake, IMO, because there's > nothing inevitable about a zeroconf driven design. We should consider > littleconf solutions especially for naming because there is no way that > mikes-toothbrush.mtcc.com got named that way coming from the factory. > > > Not sure how you can draw that conclusion; there seem to be lovers and > haters of mDNS. I just re-read the charter and it seems that it precludes discussing anything else besides mdns/dns-sd: For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. I wasn't around for the drafting of the charter, but it seems very short sighted to not even talk about what the problem is before mandating a solution. So if you don't think mdns is The Answer, it looks like you're SOL. Mike From mike@mtcc.com Mon Oct 22 12:18:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48011E809C for ; Mon, 22 Oct 2012 12:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bojqZPFCwwah for ; Mon, 22 Oct 2012 12:18:55 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 96E3B21F86EB for ; Mon, 22 Oct 2012 12:18:55 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9MJIpBM032481 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 12:18:51 -0700 Message-ID: <50859C1B.7070707@mtcc.com> Date: Mon, 22 Oct 2012 12:18:51 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: james woodyatt References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> In-Reply-To: <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2769; t=1350933534; x=1351797534; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20james=20woodyatt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=EohFHdeSAq87UTpWQuDAH8pickj3cbp6l3ihpBFFn/8=; b=rhgg/tHPxaSsitm/j5Cx7XouUVckMc4x4WGFfChtGSLqpHQEji3kjnU9Y7 BwNlhFjNPJ7ISSvh+GyJejoN0BN7XWGnbOC6hVQgT5t0jAmguPokOARaPT3x ZlSZNmfdxNkE8zKjYRd4LpFcKKlL42HMZKqIiOLSHSq4rHCvDAXDA=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:18:56 -0000 On 10/22/2012 11:57 AM, james woodyatt wrote: > On Oct 22, 2012, at 11:28 , mike wrote: >> I'd say that until we have source address selection that actually works and is widely >> deployed, that taking anything off the table is premature. Source address selection >> applies just as much on a homenet as anyplace else. > Disagree. My opinion is that the potential for catastrophic damage to the utility of the Internet by the ubiquitous deployment of NPT66 in residential gateways poses too grave a risk for us to continue seriously entertaining it as a viable approach to any of the problems in our ambit. I would say that it MUST be deprecated by the arch document. > > For anyone arguing in favor of using NPT66 in residential gateways, I think it's fair to ask them for solutions to the problem statement in I-D.carpenter-referral-ps in support of that idea. Referral in IPv4 was badly broken by the introduction of NAT44, and the ubiquitous deployment of NPT66 in residential gateways would repeat the error with IPv6. > > I would say HOMENET should not be seriously considering that as an option. Is there any significant disagreement on that point? Are there people here who might be willing to stand up and argue that the referral problem is secondary to other objectives well served by deploying NPT66 in home network access routers? If so, then what are those objectives? I'm having a hard time understanding what they might be. I'm not saying that I like NPT66. I'm saying that IETF has failed to deal with source address selection such that we're now at the point of address exhaustion with v4 with nothing working in real devices besides 3484 which is inadequate, and a lead time of 5+ years before anything is likely to be widely deployed. So we all know what happens when host devices don't do it: the network in its own hacked way does it for them. So regardless of whether we like it or not, NPT and other kinds of network hackery are just an expedient away. NPT at least doesn't have some of the most egregious sins of NAT. >> Probably even moreso when you consider corporate VPN's. > Actually, VPN is usually just a special case of MIF, i.e. individual hosts are multihomed, not the whole homenet. This is a much simpler situation to manage, and solutions for that space are already ubiquitous. > No, sorry. Corporate VPN's using v6 and the lack of a coherent source address selection mechanism causes breakage in bizarre and unpredictable ways. You are not going to get the results you hope for if your mac uses an ISP prefix to get back inside the corpro firewall, uRPF if nothing else. SLAAC changes a lot of things over v4. Mike From lorenzo@google.com Mon Oct 22 20:33:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC211F0C54 for ; Mon, 22 Oct 2012 20:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.875 X-Spam-Level: X-Spam-Status: No, score=-102.875 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLdagQsIzbWn for ; Mon, 22 Oct 2012 20:33:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20F811F0429 for ; Mon, 22 Oct 2012 20:33:10 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3714361obq.31 for ; Mon, 22 Oct 2012 20:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7bRzpnlLzVkGGDBaXPe0nC/zJgjRFZbQ7x4zSB+D54g=; b=YtDqNktxluicfgtt0Z3b0jg0KSB9LfKYUojJKvv+Dp/yDBNVCZbok6Zx4ndAiThJqy KVwJdj/+FNmZBPqds+o/sOi6MdDeWm2bKi9czDcf4lPkLcAi00RscVSvTGDonp4nP48d OXyUl+lkneKK3/Uvsafq03jAfj1GbFmLl2kkQYzmGok8RqSdVeZSgqlSuMzY+r/vw0CG EZHEILZBLUM6Lr9i7e6RL5C1tR/YBzPWLn6EQ7jZPmQFWMaofVlaoP/uEmI5uxQk5yzF CDe/26wPyBWosebgpG7+yEaCt9xacnJr2/IdxsRUql5C6f8sRiz/y3hMXUT1xCLG6Gtl AzEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7bRzpnlLzVkGGDBaXPe0nC/zJgjRFZbQ7x4zSB+D54g=; b=cMVyrpRAacde5IpZ/bz37OamRoAXH5XWVWT9EmqvScII3O8IGMLdq5vREybeXvVX7F YUDYuK1ppo0v9WXgc2yHPfSj4rHtTgCw/0ZtoVd9f2SQDzgDU9s6n2YUGy5hv9cxCwa6 BgzFKdmubxCNksytOeo3KEUna/idkvnetaFrKP0SvpbDjuWgTIASrtjPno/Y1WNcPeZ1 oUqEhIj3YXmSP2niJVbKhko/qHcYoJNQqQn9JIjsnkymXzRKuoRR8vZjbEQYIYXHRU64 sP8dM1TQYbbUFGAx/tfv3lgmgClz7SR4l5+h1ZPxMVxFnm6czxfIyhcYJptxEcHuy+Hd 09Pg== Received: by 10.60.154.231 with SMTP id vr7mr2407520oeb.119.1350963189303; Mon, 22 Oct 2012 20:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 22 Oct 2012 20:32:49 -0700 (PDT) In-Reply-To: <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> From: Lorenzo Colitti Date: Tue, 23 Oct 2012 12:32:49 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=bcaec550b6f600cb0e04ccb1a184 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkmNSnTnXCqKlvSJ9uP8NmyUQtRP6G5mgDdkKmsaMe/xPbJKU/8geuo1SvzkJKc0HKrnJM8I6k4aFpy4scOCU12KUziSKih5Yv+joUEn7JBTdsSiZai5auDEdY4mHfzMuVUm8TbNYi0RMIK96d66a8ZJtmoAgRFSpdgFLZ0bz6xkI2TmPxy6Mgh2yXaZLSSnzFruGnc Cc: homenet@ietf.org, mike Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 03:33:13 -0000 --bcaec550b6f600cb0e04ccb1a184 Content-Type: text/plain; charset=ISO-8859-1 Since earlier on this thread someone was asking for consensus: for the record, I agree with all James's points. I think that homenet should declare that NPT66 is not a supported means for multihoming in home networks. Yes, there is a multihoming problem, but no, NPT66 is not a solution/ NPT66 is simply moving the problem to the application layer in a half-baked attempt to solve some, but not all, of it. I'd like to note that both NPT66 and Ron's multihoming draft state clearly that some of the problems, for example the referral problem, cannot be solved by either solution. We need to do better than that. On Tue, Oct 23, 2012 at 3:57 AM, james woodyatt wrote: > Disagree. My opinion is that the potential for catastrophic damage to the > utility of the Internet by the ubiquitous deployment of NPT66 in > residential gateways poses too grave a risk for us to continue seriously > entertaining it as a viable approach to any of the problems in our ambit. > I would say that it MUST be deprecated by the arch document. > > For anyone arguing in favor of using NPT66 in residential gateways, I > think it's fair to ask them for solutions to the problem statement in > I-D.carpenter-referral-ps < > http://tools.ietf.org/html/draft-carpenter-referral-ps> in support of > that idea. Referral in IPv4 was badly broken by the introduction of NAT44, > and the ubiquitous deployment of NPT66 in residential gateways would repeat > the error with IPv6. > > I would say HOMENET should not be seriously considering that as an option. > Is there any significant disagreement on that point? Are there people > here who might be willing to stand up and argue that the referral problem > is secondary to other objectives well served by deploying NPT66 in home > network access routers? If so, then what are those objectives? I'm having > a hard time understanding what they might be. > > > Probably even moreso when you consider corporate VPN's. > > Actually, VPN is usually just a special case of MIF, i.e. individual hosts > are multihomed, not the whole homenet. This is a much simpler situation to > manage, and solutions for that space are already ubiquitous. > > > -- > james woodyatt > core os networking > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --bcaec550b6f600cb0e04ccb1a184 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Since earlier on this thread someone was asking for consensus: for the= record, I agree with all James's points.

I th= ink that homenet should declare that NPT66 is not a supported means for mul= tihoming in home networks.

Yes, there is a multihoming problem, but no, NPT66 is n= ot a solution/ NPT66 is simply moving the problem to the application layer = in a half-baked attempt to solve some, but not all, of it. I'd like to = note that both NPT66 and Ron's multihoming draft state clearly that som= e of the problems, for example the referral problem, cannot be solved by ei= ther solution. We need to do better than that.

On Tue, Oct 23, 2012 at 3:57 AM, james woodyatt <jhw@apple.com<= /a>> wrote:
Disagree. =A0My opinion is that the potential for catastr= ophic damage to the utility of the Internet by the ubiquitous deployment of= NPT66 in residential gateways poses too grave a risk for us to continue se= riously entertaining it as a viable approach to any of the problems in our = ambit. =A0I would say that it MUST be deprecated by the arch document.
For anyone arguing in favor of using NPT66 in residential gateways, I think= it's fair to ask them for solutions to the problem statement in I-D.ca= rpenter-referral-ps <http://tools.ietf.org/html/draft-carpente= r-referral-ps> in support of that idea. Referral in IPv4 was badly b= roken by the introduction of NAT44, and the ubiquitous deployment of NPT66 = in residential gateways would repeat the error with IPv6.

I would say HOMENET should not be seriously considering that as an option. = =A0Is there any significant disagreement on that point? =A0Are there people= here who might be willing to stand up and argue that the referral problem = is secondary to other objectives well served by deploying NPT66 in home net= work access routers? =A0If so, then what are those objectives? =A0I'm h= aving a hard time understanding what they might be.

> Probably even moreso when you consider corporate VPN's.

Actually, VPN is usually just a special case of MIF, i.e. individual = hosts are multihomed, not the whole homenet. =A0This is a much simpler situ= ation to manage, and solutions for that space are already ubiquitous.


--
james woodyatt <jhw@apple.com> core os networking



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

--bcaec550b6f600cb0e04ccb1a184-- From lorenzo@google.com Mon Oct 22 20:35:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4C61F0C86 for ; Mon, 22 Oct 2012 20:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjbkYR3C1J2Q for ; Mon, 22 Oct 2012 20:35:39 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA71F0C69 for ; Mon, 22 Oct 2012 20:35:39 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3756041oag.31 for ; Mon, 22 Oct 2012 20:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=rG3Xi64tMbRmLd1AnLpRbCLMlvfFZJ9/aTHJylVHxYw=; b=Lj75QRWgXjNowr4i360xwPJM1KqJ4OXQfXOMX9bpOEFNLQ/27QNZZzjB5V3DWTbkI1 cR5VV6ydFyEqaX8yVa+vDnIALO/feJ7g2pbX844i5PuKw69uRyGX5eQ66PIW3g7Z7pAt ViTmn3X6e1BEybkgeNpWD84NhCo978O/95X1nW1h+Ar5uZJiaQi6v24rspmv/2vVTpcY WsQiqkJWTR8QLZykzV7yN2PDjir4V+kw+THL1kFDqR0yOBm736eGJe2tuYiNx4R+UAVU 07gPSL+nPLgl6+3y8bfhTSsodTSIomf8Gn3jyHNXJvlFOUa1fW8x2dSyDdfMMEEmaRRB Se8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=rG3Xi64tMbRmLd1AnLpRbCLMlvfFZJ9/aTHJylVHxYw=; b=XyIZY/D3uODfeur92GJ1J5D07T9MjqHEgI+V0ZBkSEDDQVefblQKdt7Nr95y0O1nL3 NPewS23eBu3MYbyN7r0o/+ALoSOSBD47ejZfwGKTgaZLLeVJjnhizZKRMHI2v3QccSpp OI7EOgsCCJt3IMjOd6x1uRweTLmJS18IGd3nYVH9/YoY+EFEYjE2Ils8sYO6gdcun2bm UgilRird7YNpwjvIh/N4Zl48kYUYdS0XIx6w8SfxQ+4b5ADsXxS7grxq60A29MZbSw7v H8yMeggFPj4kQFYCeJbmxGoo0eAMOyz5LgiR0zdp7hrlmmJglcyGtRCYXpTnEgIjEpQ4 Uz7w== Received: by 10.182.38.101 with SMTP id f5mr8924997obk.80.1350963339229; Mon, 22 Oct 2012 20:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 22 Oct 2012 20:35:19 -0700 (PDT) In-Reply-To: <50859C1B.7070707@mtcc.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> From: Lorenzo Colitti Date: Tue, 23 Oct 2012 12:35:19 +0900 Message-ID: To: Michael Thomas Content-Type: multipart/alternative; boundary=f46d04463008f07b1204ccb1a9db X-System-Of-Record: true X-Gm-Message-State: ALoCoQnZjUoBMhAvUIM45QOxhQet2TMFFPW2tDvLmLuJjVsFk8r3clhjTcA4gdC6loBiQynR0IEQc5H55dvgZXTG+GbgsSMG+bZhVQ9a/47OqycSNGAlNOjHisGE3K6mxn/i/xBxBIBr+BWD5ArMNDIjF787+O1pFBTkAWuaE8GBmAvcsqV7nHo6BJ/6OaVg+ENoSibI95l8 Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 03:35:40 -0000 --f46d04463008f07b1204ccb1a9db Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas wrote: > No, sorry. Corporate VPN's using v6 and the lack of a coherent source > address selection mechanism causes breakage in bizarre and unpredictable > ways. You are not going to get the results you hope for if your mac uses an > ISP prefix to get back inside the corpro firewall, uRPF if nothing else. > SLAAC changes a lot of things over v4. > VPN clients already modify the routing table to ensure traffic going through the VPN goes through the VPN, to enforce policies around split tunneling, and so on. Mine even monitors the routing table for changes so it can act on them. Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here. --f46d04463008f07b1204ccb1a9db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <mike@mtcc.com> = wrote:
No, sorry. Corporate VPN's using v6 and the lack of a= coherent source address=A0selection mechanism causes breakage in bizarre a= nd unpredictable ways.=A0You are not going to get the results you hope for = if your mac uses an ISP prefix=A0to get back inside the corpro firewall, uR= PF if nothing else. SLAAC changes=A0a lot of things over v4.

VPN clients already modify the routing table to= ensure traffic going through the VPN goes through the VPN, to enforce poli= cies around split tunneling, and so on. Mine even monitors the routing tabl= e for changes so it can act on them.

Can you explain why this behaviour, combined with the &= quot;prefer matching interface" rule in RFC 3484, is not sufficient? I= f not, then there is no problem to solve here.
--f46d04463008f07b1204ccb1a9db-- From Ray.Bellis@nominet.org.uk Tue Oct 23 01:30:03 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05121F86B1 for ; Tue, 23 Oct 2012 01:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 Xrznm5HMKSBu for ; Tue, 23 Oct 2012 01:30:01 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6383A21F8673 for ; Tue, 23 Oct 2012 01:30:01 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=YdBZQ9Qdiau04rcmA4+o2s5m/aG+qzfS4FR+Y9Wq2bxBiGUxOgNlq9iO IqhrN1TRanALJqmO4RCBoKoOrgP71LRim7kI/fTJc3NeLENoel8B6vE+Y ERX6HLGMAj5FM71; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1350981001; x=1382517001; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20I-D=20Action:=20draft-hadda d-homenet-multihomed-00|Date:=20Tue,=2023=20Oct=202012=20 08:29:59=20+0000|Message-ID:=20<2D068486-D56A-4AD0-BD0F-F 5E3F84D5204@nominet.org.uk>|To:=20james=20woodyatt=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|Content-ID:=20<16fe2663-10f2-487a-b74 7-758af49d9eae>|In-Reply-To:=20<52E31542-3B7C-4EC1-9B2C-3 C9D8E6B3BB1@apple.com>|References:=20<201210011801.q91I1t fW056624@gateway1.orleans.occnc.com>=0D=0A=20<506A07D1.80 50605@gmail.com>=0D=0A=20<10328E81-3C94-455B-9A37-B421200 A5C38@ecs.soton.ac.uk>=0D=0A=20=0D=0A=20<7F6E A97D-5DA8-4872-A647-D879B1955824@gmail.com>=0D=0A=20<49FC FE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk>=0D=0A =20=0D=0A=20<7F4B245F-9355-4134-9176-EB7DB1 634469@apple.com>=0D=0A=20<77A8749D-DF81-4816-8277-CB6986 1E524A@fugue.com>=0D=0A=20=0D=0A=20=0D=0A=20<508 5905A.8030206@mtcc.com>=20<52E31542-3B7C-4EC1-9B2C-3C9D8E 6B3BB1@apple.com>; bh=DNBmeA4hASmzm8ynDgHmCwap7vDlY2pV6zwaSGueE4Y=; b=zYpPGbpsJahAjnSxn+UZ+YsVGSmwHZJw0vZjd0JCaAkDp0KWL0Z2diH2 wjPki1tGuYk+Pa5QTEx0QROvfY/wrZkuqPLCby11ilBaZTZpC03rj0ZR1 FIVr01641rybEAM; X-IronPort-AV: E=Sophos;i="4.80,635,1344207600"; d="scan'208";a="44078022" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 23 Oct 2012 09:30:00 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Tue, 23 Oct 2012 09:30:00 +0100 From: Ray Bellis To: james woodyatt Thread-Topic: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 Thread-Index: AQHNn/7XOo0fsnT9I02dv6625qLXl5ek4tyAgA70ZwCADQ7OAIAEdwmAgABLjACAAAFHgIAABYuAgAAF5gCAAAgiAIAA4uyA Date: Tue, 23 Oct 2012 08:29:59 +0000 Message-ID: <2D068486-D56A-4AD0-BD0F-F5E3F84D5204@nominet.org.uk> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> In-Reply-To: <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <16fe2663-10f2-487a-b747-758af49d9eae> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:30:03 -0000 On 22 Oct 2012, at 19:57, james woodyatt wrote: > I would say that it MUST be deprecated by the arch document. The arch document is Informational and contains no RFC 2119 keywords. Ray From lorenzo@google.com Tue Oct 23 01:51:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191FE21F8662 for ; Tue, 23 Oct 2012 01:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KNA-VDCvabJ for ; Tue, 23 Oct 2012 01:51:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04A9621F84EE for ; Tue, 23 Oct 2012 01:51:16 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3917403obq.31 for ; Tue, 23 Oct 2012 01:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=MbVpSckpDHiDufgk9/WkVZ4kCGydQdaBqd3hF5v+5Y4=; b=RPJjaQhlWo8o04rLa5+TRnKO5P2UOxHNrbSlEVcQaXXu66+6Z5iWJR0FqC3Ly1B/dU UuevJPGorkD3w+NADWq61cVMsMoqU7hqIRvE0hi08k6MzzBg1OVuTjPWTV3AvynwE26K ZMIuoI3fw9/d9kaBa+k9jGRvMXwFjcoxzNA5P/QCMmy424qbI9K3MCIvV6eLCCIySTfb SOF39rdbl6R7KMie2ss72HfSofVgFukD5XPBOt1NbYcBrv33QbtBFlgli48GMjJcL86P TEWP6Y/zqCAI91ReEESelHttXYUiA0JghA8h4pf8oNeuy6tfqpSbKnKvR3E3UiO0a1tc 1MMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=MbVpSckpDHiDufgk9/WkVZ4kCGydQdaBqd3hF5v+5Y4=; b=k0iCZ+Rd6f9/xTiDiURnABSFKyTWnKLe7J2O6oBpVY+E8aD+sqpzgMbXN46d+VJ1WD Mm9mL80owv8K65+rtpxXbmUwGsKiqsUZKsW57c6otg0rRapf6hrfShNpQPNT9UyOh8d8 mWpCIvG9GbZsBU4+LNLAMsRIDWyLe5MdU9pivggBo4hrC5wzsJzgnxxNRbXxHaF9q0n4 OsTwfVl9869dyFBcodqKNvG+7ZqbG1naRvGaV1xLybibxtviBBRNzYzoVgdRCwmLPV69 2MF+F+PfymNtDLx1VZ6t10xjEbnUw9Zc/kcooALpPzAwFZb/am9XF5aAV0npBXwqyNWV EIJw== Received: by 10.182.221.97 with SMTP id qd1mr9089657obc.6.1350982275205; Tue, 23 Oct 2012 01:51:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 23 Oct 2012 01:50:55 -0700 (PDT) In-Reply-To: <2D068486-D56A-4AD0-BD0F-F5E3F84D5204@nominet.org.uk> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <2D068486-D56A-4AD0-BD0F-F5E3F84D5204@nominet.org.uk> From: Lorenzo Colitti Date: Tue, 23 Oct 2012 17:50:55 +0900 Message-ID: To: Ray Bellis Content-Type: multipart/alternative; boundary=f46d0446325c9c8a2704ccb61250 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkvDYjGKhu2bPWYIeqUbUimHJVwC9xU7LgkAUCF+xDAio/8s8+4HbOs03VK9PJpiG+IyD/tenVgUnwwCn+VYSTOusqinnsqz4VmhjqCEyCSPdXDdX6ck2L0cjPijzZG+zi0Rxa5BxM80kML6sBzr3iB9/JTFeWOcAkhcvqeKyZVWU9F0cRTQpT7NkF23CPj0KSaSevp Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:51:18 -0000 --f46d0446325c9c8a2704ccb61250 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 23, 2012 at 5:29 PM, Ray Bellis wrote: > > I would say that it MUST be deprecated by the arch document. > > The arch document is Informational and contains no RFC 2119 keywords. > It can't deprecate it, but it can say that NPT66 is not supported in the homenet architecture. --f46d0446325c9c8a2704ccb61250 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2012 at 5:29 PM, Ray Bellis <Ray.Bellis@nominet.= org.uk> wrote:
> I would say that it MUST be deprecated by the arch d= ocument.

The arch document is Informational and contains no RFC 2119 keywords.=

It can't deprecate it, but it can = say that NPT66 is not supported in the homenet architecture.
--f46d0446325c9c8a2704ccb61250-- From Ray.Bellis@nominet.org.uk Tue Oct 23 01:54:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B8E21F85AB for ; Tue, 23 Oct 2012 01:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 LgYEpAqsycDG for ; Tue, 23 Oct 2012 01:54:15 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5E09721F861F for ; Tue, 23 Oct 2012 01:54:13 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=Q5LuVC6u/IQ2aKu0kGIxGA2s4BKDm0pZAKQlfagTgcrkVknboXkif4cm 1AiLHdkj9tuphEE1SVcORMuPWJN2D5HmqOkbqYTj6VSfqnTM0ehaufeoj fEOUU5bdEoTkRrm; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1350982453; x=1382518453; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20I-D=20Action:=20draft-hadda d-homenet-multihomed-00|Date:=20Tue,=2023=20Oct=202012=20 08:54:11=20+0000|Message-ID:=20<841450C4-733D-441D-9757-0 1FD20E120B6@nominet.org.uk>|To:=20Lorenzo=20Colitti=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<614c254f-c41d-4a5b-ad63-5359918ebdb0> |In-Reply-To:=20|References:=20<201210011801.q 91I1tfW056624@gateway1.orleans.occnc.com>=0D=0A=20<506A07 D1.8050605@gmail.com>=0D=0A=20<10328E81-3C94-455B-9A37-B4 21200A5C38@ecs.soton.ac.uk>=0D=0A=20=0D=0A=20 <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com>=0D=0A=20 <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk>=0D =0A=20=0D=0A=20<7F4B245F-9355-4134-9176-EB7DB 1634469@apple.com>=0D=0A=20<77A8749D-DF81-4816-8277-CB698 61E524A@fugue.com>=0D=0A=20=0D=0A=20=0D=0A=20<50 85905A.8030206@mtcc.com>=20<52E31542-3B7C-4EC1-9B2C-3C9D8 E6B3BB1@apple.com>=0D=0A=20<2D068486-D56A-4AD0-BD0F-F5E3F 84D5204@nominet.org.uk>=0D=0A=20; bh=cP49NVISVQgnj5duZgV9BjyY6H+x64Y8eO/IHR/HAmE=; b=e/iC22A39OmR7twFCSapvFxVr0s7sAHZr78bK74gyS7/XbUhmSWxbdGA I2zxaZLD/8701M0zGTkGZ/gZm/OyjI4CA2GeYEd0dHmj20Qxo2dOxZmUy xZbfHSzPb17uYNk; X-IronPort-AV: E=Sophos;i="4.80,635,1344207600"; d="scan'208";a="44078298" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 23 Oct 2012 09:54:12 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Tue, 23 Oct 2012 09:54:12 +0100 From: Ray Bellis To: Lorenzo Colitti Thread-Topic: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 Thread-Index: AQHNn/7XOo0fsnT9I02dv6625qLXl5ek4tyAgA70ZwCADQ7OAIAEdwmAgABLjACAAAFHgIAABYuAgAAF5gCAAAgiAIAA4uyAgAAF2YCAAADqgA== Date: Tue, 23 Oct 2012 08:54:11 +0000 Message-ID: <841450C4-733D-441D-9757-01FD20E120B6@nominet.org.uk> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <2D068486-D56A-4AD0-BD0F-F5E3F84D5204@nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <614c254f-c41d-4a5b-ad63-5359918ebdb0> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:54:15 -0000 On 23 Oct 2012, at 09:50, Lorenzo Colitti wrote: > It can't deprecate it, but it can say that NPT66 is not supported in the = homenet architecture. Indeed. Ray= From tjc@ecs.soton.ac.uk Tue Oct 23 02:46:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6321F86AA for ; Tue, 23 Oct 2012 02:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 xtDkNo0VUiFk for ; Tue, 23 Oct 2012 02:46:27 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id CD08921F8654 for ; Tue, 23 Oct 2012 02:46:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9N9kM7h019918 for ; Tue, 23 Oct 2012 10:46:22 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9N9kM7h019918 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350985583; bh=UY41FzI/r98Lg26jM6HRey5QtJg=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=jtUGDVcM1QyILx2L9cej1p/bwPCIPwG/pb6NFEjscwaE9gBnOYt7lKpIKMaKyG/fh pxczxc6q8H0CmgSPHbWF08C1Rr1xGh+sHaRXr5JhRZ7NA88nMGUmwgO1EdMBv3tZUt 01krCkz0+xOWcctjh1wwtY3aqJgGEHr61Tncf6CM= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9MAkM0430618069md ret-id none; Tue, 23 Oct 2012 10:46:23 +0100 Received: from ip-204-200.eduroam.soton.ac.uk (ip-204-200.eduroam.soton.ac.uk [152.78.204.200]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9N9kKWI014210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 23 Oct 2012 10:46:20 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <841450C4-733D-441D-9757-01FD20E120B6@nominet.org.uk> Date: Tue, 23 Oct 2012 10:46:21 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <2D068486-D56A-4AD0-BD0F-F5E3F84D5204@nominet.org.uk> <841450C4-733D-4! 41D-9757-01FD20E120B6@nominet.org.uk> <4662A74C-A693-4DAE-ABE3-7C87D84E4417@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9MAkM043061806900; tid=o9MAkM0430618069md; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9N9kM7h019918 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:46:27 -0000 On 23 Oct 2012, at 09:54, Ray Bellis wrote: >=20 > On 23 Oct 2012, at 09:50, Lorenzo Colitti > wrote: >=20 >> It can't deprecate it, but it can say that NPT66 is not supported in = the homenet architecture. >=20 > Indeed. We can capture those sentiments in -07, and use Brian's draft as just = one example of why.=20 When I said 'it was on the table', that was as something that could well = happen. Personally, I would rather see the approach in = ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 shorter term, and hope = for better support in routing protocols longer term. BTW, please note that RFC 3484 is now replaced by RFC 6724. It may take = some time to adjust :) Tim= From brian.e.carpenter@gmail.com Tue Oct 23 03:38:31 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D127021F86B1 for ; Tue, 23 Oct 2012 03:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKoe-1bfhedl for ; Tue, 23 Oct 2012 03:38:31 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E221F86AD for ; Tue, 23 Oct 2012 03:38:30 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1291471bkc.31 for ; Tue, 23 Oct 2012 03:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6k9wa5Dqho8cIIhRjt0in5yStrB+6bIcGsIFWzPyHHw=; b=ozM/mklGhcXZi+CFN0S9Zt36TjfiK1u2oTM6W8AWKVTUJkFsMUrT/Vstjl+jRbQ7B5 +q7KBoKU9o/IcXxvOP+d2nKRnQe0+T7p1isfagDIEMXHEODdpaSearEhHTNZf5Bq1K+l 1HGEiYyXWW+3naPcoPpwPFnYhOnoTPEAsvwFZiDuchPDzlnr+LSVbyHy0XGVtGbFJdfx 5F1z6JF4EOr5W7Pc+3TmQ/DORFv5NnZ2hnwHZqQluCMUtRAoyTzJjR1O8c/JkC4Ox45F U2oCrd7l/+Lux3oMxzTJENmgDTwsuurCxyGAhhup07zQcPXxt90nXPYBxyikj2uDEo9c cx8Q== Received: by 10.204.151.9 with SMTP id a9mr3430354bkw.2.1350988710160; Tue, 23 Oct 2012 03:38:30 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-57.as13285.net. [2.102.219.57]) by mx.google.com with ESMTPS id k21sm5323413bkv.1.2012.10.23.03.38.28 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 03:38:29 -0700 (PDT) Message-ID: <508673A5.2020700@gmail.com> Date: Tue, 23 Oct 2012 11:38:29 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <20121019160000.25306.98107.idtracker@ietfa.amsl.com> <50818AED.7090001@mtcc.com> <508574F5.3030504@gmail.com> <508582AA.3030900@mtcc.com> In-Reply-To: <508582AA.3030900@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] service announcement vs service discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:38:32 -0000 On 22/10/2012 18:30, Michael Thomas wrote: > On 10/22/2012 09:31 AM, Brian E Carpenter wrote: >> On 19/10/2012 18:16, Michael Thomas wrote: >>> On 10/19/2012 09:36 AM, Tim Chown wrote: >>>> >>>> We can take comments towards a -06 over the weekend. The most >>>> substantial changes are in the Naming and Service Discovery section >>>> (3.7), so if you have limited time please focus your reading there. >>> One thing that I'm not sure whether it's been discussed or not is >>> service announcement. >>> By service announcement, I mean where instead of multicasting out a >>> message looking >>> for the canonical printer with all of its nasty properties especially >>> for things with batteries >>> and lossy/slow networks, a device would instead announce its presence to >>> something >>> that would later serve it up (eg, bind9, say). >> e.g. an SLP Directory Agent, designed for this purpose some years ago. >> [RFC2608], [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832] >> This is not exactly a new problem. >> > > I looked this over, and I don't think it's what I'm thinking of. I'm > thinking of literally having a device do an IXFR to a real DNS server. > Or something that looks pretty similar to an IXFR, but the key being > that it's a real DNS server. No multicast required ever. > > In any case, even if this isn't new ground maybe the problem was that > they didn't hitch their wagon to DNS. Deployment of SLP is I'm guessing > pretty thin. I'm told that it's widely implemented (at least in printers) but rarely used. All I'm saying is that it should be on the candidate list. (And if the WG charter limits the list of candidates, that's a bug in the charter that will need to be fixed.) Brian From fujiwara@jprs.co.jp Tue Oct 23 03:47:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B2221F86BB for ; Tue, 23 Oct 2012 03:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXhXgYRY4sx2 for ; Tue, 23 Oct 2012 03:47:58 -0700 (PDT) Received: from off-send02.tyo.jprs.co.jp (off-send02.tyo.jprs.co.jp [IPv6:2001:df0:8:17::20]) by ietfa.amsl.com (Postfix) with ESMTP id 3393921F86B6 for ; Tue, 23 Oct 2012 03:47:58 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send02.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q9NAlrZZ018113 for ; Tue, 23 Oct 2012 19:47:56 +0900 X-AuditID: ac120820-b7fd46d0000058b8-13-508675dcb6c7 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id C5.F1.22712.CD576805; Tue, 23 Oct 2012 19:47:56 +0900 (JST) Date: Tue, 23 Oct 2012 19:47:55 +0900 (JST) Message-Id: <20121023.194755.229760265.fujiwara@jprs.co.jp> To: homenet@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsWyRoiFT/dOaVuAwf92Hov3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoErY/W97awFE1krGrsWMDYwzmXpYuTkkBAwkZi8ZQkbhC0mceHe eiCbi0NI4CSjxJemY+wgCRYBbYn5i6+B2bwC1hLn2p4ydTFycIgIiEg0Tw8FCQsDlew6/Qys hE1AUmLz51ZmiJl2Eieer2AFKecVEJT4u0MYJMwsoCXRM+MxO4QtL7H97RzmCYw8sxCqZiGp moWkagEj8ypGmfy0NN3i1LyU4tx0A0O9ksp8vayComK9ZBC9iREcKhwKOxhnnDI4xCjAwajE w/vxRGuAEGtiWXFl7iFGSQ4mJVHejvy2ACG+pPyUyozE4oz4otKc1OJDjBIczEoivKb2QDne lMTKqtSifJiUNAeLkjjv8bM7/IQE0hNLUrNTUwtSi2CyMhwcShK8x0uAGgWLUtNTK9Iyc0oQ 0kwcnCDDeYCGzwCp4S0uSMwtzkyHyJ9iVOU40z3vIaMQS15+XqqUOO9CkCIBkKKM0jy4Oa8Y xYHeEeadD5LlAaYDuAmvgIYzAQ0352kFGV6SiJCSamBkq51ievbHI/7CK+9aov1+bu16qc++ zTfYgzFMLeH6Ph6xG9/8nxqrC6+4FMGVUntomfF0709z5A3nhhpWnjvm+mMy5/l8RlkB5iX7 vT0s3OcVaF/i/T2h+s9i88LODbaHuzdHeuoUZYhMc9pQ6NtRvJWv4uLB+wxLz9qVbpS9Lvmf J/C4z3YlluKMREMt5qLiRACNbhWVxAIAAA== Subject: [homenet] draft-fujiwara-smallest-homenet-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:47:58 -0000 I submitted draft-fujiwara-smallest-homenet-01 http://www.ietf.org/internet-drafts/draft-fujiwara-smallest-homenet-01.txt Although access control for home servers is very important, managements and setups of access controls are difficult for most of users. "Connecting a new node to the same link" is easiest way of access control. One of solutions is to use link-local addresses for communications of clients and servers. Is it in a scope of homenet WG ? Does anyone have interests for the idea ? I would like to discuss access control of home servers and small homenet. Regards, -- Kazunori Fujiwara, JPRS From mike@mtcc.com Tue Oct 23 08:20:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0017D11E80E7 for ; Tue, 23 Oct 2012 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 vu7BE18a9rLp for ; Tue, 23 Oct 2012 08:20:13 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B59E11E80A6 for ; Tue, 23 Oct 2012 08:20:13 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9NFK7ZG023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 08:20:07 -0700 Message-ID: <5086B5A7.3040706@mtcc.com> Date: Tue, 23 Oct 2012 08:20:07 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1367; t=1351005610; x=1351869610; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20Lorenzo=20Colitti=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ggmj+iTnrAfXOhHcbb9SOUXzJ9BCxH2GXRMEAH6oYNg=; b=jE1cIwBk8DWpjklVJtCRQ/8Bh82+8VdAiiDiPZUq5MAkZ7j/vwPR/hiI5M gU9cZCf3gTVs8NqvVZ0GQKS5xsSDyEL9A73y4De/ArFjvDwmdzI68Zj7GxsZ MWISrHm7ZakVtwD/GdURvyJpB0fR4JpJp6cIMHND0VCULcYSruCFg=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:20:15 -0000 On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: > On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas > wrote: > > No, sorry. Corporate VPN's using v6 and the lack of a coherent source address selection mechanism causes breakage in bizarre and unpredictable ways. You are not going to get the results you hope for if your mac uses an ISP prefix to get back inside the corpro firewall, uRPF if nothing else. SLAAC changes a lot of things over v4. > > > VPN clients already modify the routing table to ensure traffic going through the VPN goes through the VPN, to enforce policies around split tunneling, and so on. Mine even monitors the routing table for changes so it can act on them. Routing is irrelevant. > > Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here. Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::, but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues: 1) the packet gets rejected via uRPF 2) the return packet splats against the inside firewall since it's not allowed outside 3) the packet makes it outside unarmored with sad faces from the security team Mike From teco@inf-net.nl Tue Oct 23 09:56:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E6D11E80CC for ; Tue, 23 Oct 2012 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82pYOw66SZOs for ; Tue, 23 Oct 2012 09:56:23 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6F1F0419 for ; Tue, 23 Oct 2012 09:56:22 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1746491eek.31 for ; Tue, 23 Oct 2012 09:56:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=6ErtoKwcIl2WGDPX2ywIS5BTS+3cX4ZcDAZs3Xj1hDg=; b=DO6yavdpYf+GgG6984+C37ICIV79OIcpsw/ShA4vlDMfYaKb/IAGQTkfeJ16/XWWrH wCiHTECk/fQv9cyMcGAeT8l5iV7bgH7P0E4PPaluyUEQTUiiiy8MdFI/yIaqefEWgAUC OzCaFUQ18zCD8l5L7D+3NyCtp4Di28T/D19lYOxsPOpA9ZO1iYgAIIY7phlppFGXB5O/ Ua+WNJsLpKNa9oUB8ScBiwVTAHfcc+hsoQDirfcb9LIHtSDoh7cImuZX94x2N6x1RO8b uhHmESQ2B+9TIHyU3Uz2BjpQP6hhRHMJB6D7QYYfQ95yCaWrs3+xRglMwDK/AlNEld37 HpOQ== Received: by 10.14.216.193 with SMTP id g41mr8598949eep.37.1351011381038; Tue, 23 Oct 2012 09:56:21 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:4183:8674:893b:f478? ([2001:470:7a9b:1:4183:8674:893b:f478]) by mx.google.com with ESMTPS id s1sm21721492eem.9.2012.10.23.09.56.19 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 09:56:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <5086B5A7.3040706@mtcc.com> Date: Tue, 23 Oct 2012 18:56:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQk/psuk+QAhV/WAICsuXzM9dLUh7/pZST7lntJ22ZdA6EMx/MtACwb6Z2oMdRcc2eGJjgP8 Cc: homenet@ietf.org, james woodyatt , Lorenzo Colitti Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 16:56:24 -0000 Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende geschreven: > On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: >> On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas > wrote: >>=20 >> No, sorry. Corporate VPN's using v6 and the lack of a coherent = source address selection mechanism causes breakage in bizarre and = unpredictable ways. You are not going to get the results you hope for if = your mac uses an ISP prefix to get back inside the corpro firewall, uRPF = if nothing else. SLAAC changes a lot of things over v4. >>=20 >>=20 >> VPN clients already modify the routing table to ensure traffic going = through the VPN goes through the VPN, to enforce policies around split = tunneling, and so on. Mine even monitors the routing table for changes = so it can act on them. >=20 > Routing is irrelevant. >=20 >>=20 >> Can you explain why this behaviour, combined with the "prefer = matching interface" rule in RFC 3484, is not sufficient? If not, then = there is no problem to solve here. >=20 > Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you = 2000::, > but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your > 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues: >=20 > 1) the packet gets rejected via uRPF > 2) the return packet splats against the inside firewall since it's not = allowed outside > 3) the packet makes it outside unarmored with sad faces from the = security team Employer should also provide 2001:yyyy::. Or make server accessible via = Internet. BRDP will handle this scenario nicely, also for existing hosts. Teco >=20 > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Tue Oct 23 10:19:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB0811E8099 for ; Tue, 23 Oct 2012 10:19:35 -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 63+biIZt1a2V for ; Tue, 23 Oct 2012 10:19:34 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id B090C11E80D1 for ; Tue, 23 Oct 2012 10:19:33 -0700 (PDT) Received: from sjc-vpn2-630.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9NHJTbX000304 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 23 Oct 2012 10:19:30 -0700 Message-ID: <5086D19C.4040002@mtcc.com> Date: Tue, 23 Oct 2012 10:19:24 -0700 From: mike User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2092; t=1351012773; x=1351876773; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20mike=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=sGZyUk6JvblcQEZ71Z+oC7khMr/R1jbJNZRyVSwkrTI=; b=VjVLtkvuSwuuCEdk0kj3PEB/mZu2QWwp2lzLZmD7+6Xar0nAFGYzQpuCi7 P+PyOSkNjuqAfIE5S7cQ2yOYkugwu65RzSJYJmUGO+kuWs01ZaoDyoWt86qr nXfNQDhvG3GBo03qeWyLPHfQ3mRVx4h29puihWoVYl4t4PDRNWSkI=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:19:35 -0000 On 10/23/12 9:56 AM, Teco Boot wrote: > Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende geschreven: > >> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: >>> On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas > wrote: >>> >>> No, sorry. Corporate VPN's using v6 and the lack of a coherent source address selection mechanism causes breakage in bizarre and unpredictable ways. You are not going to get the results you hope for if your mac uses an ISP prefix to get back inside the corpro firewall, uRPF if nothing else. SLAAC changes a lot of things over v4. >>> >>> >>> VPN clients already modify the routing table to ensure traffic going through the VPN goes through the VPN, to enforce policies around split tunneling, and so on. Mine even monitors the routing table for changes so it can act on them. >> Routing is irrelevant. >> >>> Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here. >> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::, >> but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your >> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues: >> >> 1) the packet gets rejected via uRPF >> 2) the return packet splats against the inside firewall since it's not allowed outside >> 3) the packet makes it outside unarmored with sad faces from the security team > Employer should also provide 2001:yyyy::. Or make server accessible via Internet. > BRDP will handle this scenario nicely, also for existing hosts. > Presumably, the reason it's behind the corpro firewall is because they don't want it accessible to the internet at large. I'm not sure if giving each host a prefix in 2001:yyyy's address space is scalable either for the hosts, the SLAAC announcements, or just carving up 2001:yyyy's addresses, especially if you have a large VPN population. I've done that myself, and I have doubts that it's the right approach. Mike From teco@inf-net.nl Tue Oct 23 10:25:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8EE11E80D5 for ; Tue, 23 Oct 2012 10:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek-5s86e20tV for ; Tue, 23 Oct 2012 10:25:31 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B10E11E80D1 for ; Tue, 23 Oct 2012 10:25:31 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1759493eek.31 for ; Tue, 23 Oct 2012 10:25:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jxB4IazJLuaev8k1eZp2Bx3uruuPSvL2bs/1qNTIOEQ=; b=UqH52QWhYk4aFmQdFS5wvzKeR67rf01QqlU+IcxcFge753vPJLDGZMFMI5QqP5yKN8 n/dDy4JWN9xORoVxMSbK7OVVpK5cekaoZe5NuIFj+3ReIfZMES+0jruKJRx7DBfryHDM pP2tnJooZH8B6lR8D4xxotaHvmjPa9qyK/0y0b0jo1hysJjhawdLGqDvS6EHEMAY+5aq dBrmsGb4YVN1zB4b8Rshll/fud94drkG5tFoN99N8fq11+18SGBJu6QzSqvATXmBXgg2 Xg63lnb8v1Xk5woQ2nByV3q/xyngBeSSrGLNPfCs2Vu2V559CPGmnIS9zCs4vzycBRAV sZWQ== Received: by 10.14.199.134 with SMTP id x6mr18074425een.31.1351013130539; Tue, 23 Oct 2012 10:25:30 -0700 (PDT) Received: from [10.175.173.28] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id t7sm21847972eel.14.2012.10.23.10.25.29 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 10:25:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <5086D19C.4040002@mtcc.com> Date: Tue, 23 Oct 2012 19:25:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91FB983E-7D99-434E-9B09-B842D53F7A31@inf-net.nl> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <5086D19C.4040002@mtcc.com> To: mike X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmThvg274h8Mws8yGJ9CQknCNGAXZHsRo0uQ7JQFAcpL8TT1fG7a6WbufsyzYJboQuiUNaH Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:25:32 -0000 Op 23 okt. 2012, om 19:19 heeft mike het volgende geschreven: > On 10/23/12 9:56 AM, Teco Boot wrote: >> Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende = geschreven: >>=20 >>> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: >>>> On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas > wrote: >>>>=20 >>>> No, sorry. Corporate VPN's using v6 and the lack of a coherent = source address selection mechanism causes breakage in bizarre and = unpredictable ways. You are not going to get the results you hope for if = your mac uses an ISP prefix to get back inside the corpro firewall, uRPF = if nothing else. SLAAC changes a lot of things over v4. >>>>=20 >>>>=20 >>>> VPN clients already modify the routing table to ensure traffic = going through the VPN goes through the VPN, to enforce policies around = split tunneling, and so on. Mine even monitors the routing table for = changes so it can act on them. >>> Routing is irrelevant. >>>=20 >>>> Can you explain why this behaviour, combined with the "prefer = matching interface" rule in RFC 3484, is not sufficient? If not, then = there is no problem to solve here. >>> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you = 2000::, >>> but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. = Your >>> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity = ensues: >>>=20 >>> 1) the packet gets rejected via uRPF >>> 2) the return packet splats against the inside firewall since it's = not allowed outside >>> 3) the packet makes it outside unarmored with sad faces from the = security team >> Employer should also provide 2001:yyyy::. Or make server accessible = via Internet. >> BRDP will handle this scenario nicely, also for existing hosts. >>=20 > Presumably, the reason it's behind the corpro firewall is because they = don't > want it accessible to the internet at large. OK. > I'm not sure if giving each host a > prefix in 2001:yyyy's address space is scalable either for the hosts, = the SLAAC > announcements, or just carving up 2001:yyyy's addresses, especially if = you have > a large VPN population. I've done that myself, and I have doubts that = it's the > right approach. I can't get why employer doesn't assign a 2000:: address to the server, = other=20 than test uRPF filters and get protocol designers crazy :-) Teco >=20 > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Tue Oct 23 10:28:29 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0014B1F0C89 for ; Tue, 23 Oct 2012 10:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 exy0EDiW4Ubb for ; Tue, 23 Oct 2012 10:28:28 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 473701F0425 for ; Tue, 23 Oct 2012 10:28:28 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9NHSONL003496 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 10:28:25 -0700 Message-ID: <5086D3B8.3040909@mtcc.com> Date: Tue, 23 Oct 2012 10:28:24 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Teco Boot References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <5086D19C.4040002@mtcc.com> <91FB983E-7D99-434E-9B09-B842D53F7A31@inf-net.nl> In-Reply-To: <91FB983E-7D99-434E-9B09-B842D53F7A31@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=648; t=1351013308; x=1351877308; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20Teco=20Boot=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=f3OQ1X00ShC7Qe3ftGl43EXgk+hxdUg4vMj7hF8+Vxc=; b=Lyh3573+D7YngIDC+68Q5SbE3kt/3Cnj80SzQvp687DNJ6f816FIpPBZKw jg6hInNBmDiPaGwBd0Sp27EFVCodWBgvCuUNHdyjjMJULn5cipjyofrqs6+h TXvfI4Fhq2YEcCyBMrzMepznBfIfqVPFQPhsXkwhHPuJGIqNk8Y+I=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:28:29 -0000 On 10/23/2012 10:25 AM, Teco Boot wrote: > > I'm not sure if giving each host a > prefix in 2001:yyyy's address space is scalable either for the hosts, the SLAAC > announcements, or just carving up 2001:yyyy's addresses, especially if you have > a large VPN population. I've done that myself, and I have doubts that it's the > right approach. > I can't get why employer doesn't assign a 2000:: address to the server, other > than test uRPF filters and get protocol designers crazy :-) > They ran of space in the 2000:: allocation? They merged two companies? There's lots of reasons why a company would have multiple prefixes. Mike From jhw@apple.com Tue Oct 23 10:51:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16B21F865E for ; Tue, 23 Oct 2012 10:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvYdeuPP6Nuf for ; Tue, 23 Oct 2012 10:51:59 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6E021F8654 for ; Tue, 23 Oct 2012 10:51:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MCC00HWGXK8T6I2@mail-out.apple.com> for homenet@ietf.org; Tue, 23 Oct 2012 10:51:58 -0700 (PDT) X-AuditID: 11807136-b7f196d00000447f-e5-5086d93ebd40 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 61.FF.17535.E39D6805; Tue, 23 Oct 2012 10:51:58 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MCC003RHXMLQ740@aniseed.apple.com> for homenet@ietf.org; Tue, 23 Oct 2012 10:51:58 -0700 (PDT) From: james woodyatt In-reply-to: <2D068486-D56A-4AD0-BD0F-F5E3F84D5204@nominet.org.uk> Date: Tue, 23 Oct 2012 10:51:56 -0700 Message-id: <2B5E9FA7-97C7-4F35-A389-B1617208917D@apple.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <2D068486-D56A-4AD0-BD0F-F5E3F84D5204@nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1620) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUi2FAsrmt3sy3A4HODhMX7RYdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMX3HLraCs8wVU6f3MzUwvmTqYuTkkBAwkXjTeoIZwhaTuHBv PVsXIxeHkMAUJonHl/ZCObOYJO4vmcICUsUsoCWxfudxsG5eAT2J6RMmgsWFBVwlThxcCmaz CahIfLt8F6iGg4NTwElizVwdkDCLgKrEilnPmCDG6Ev07nnIBmFrSzx5d4EVYqSNxPET39gh 9s5nl3i9twWsQQRo79b9H6AulZVYfG0d8wRGgVlITpqF5KRZSOYuYGRexShYlJqTWGloqpdY UJCTqpecn7uJERx8hWY7GHf8lTvEKMDBqMTDm3iiLUCINbGsuDL3EKMEB7OSCG/2RaAQb0pi ZVVqUX58UWlOavEhRmkOFiVx3qTjQCmB9MSS1OzU1ILUIpgsEwenVAMjZ4pU0v5lfco6Lqdn t+fNjiyok1/RqmTAZ+QcxMa3dd6mBWmndlv7vL109O+UpP4lZsWFKwx9OhZILRK74O7Lq7RY wexwxpwzCxhvP39n9en74k0x6r3r38UnCLVLPeJk8jnt9sG3P93yU4C3wrkFjKsc0k1lP6ua T6sorBFTdP6frhYgZ6jEUpyRaKjFXFScCACDZR7aOgIAAA== Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:51:59 -0000 On Oct 23, 2012, at 01:29 , Ray Bellis wrote: > On 22 Oct 2012, at 19:57, james woodyatt wrote: >> >> I would say that it MUST be deprecated by the arch document. > > The arch document is Informational and contains no RFC 2119 keywords. My email to the list was an individual exhortation, and it contained no RFC 2119 keywords. -- james woodyatt core os networking From jhw@apple.com Tue Oct 23 11:01:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5ED11E8099 for ; Tue, 23 Oct 2012 11:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu1H7Tea76n0 for ; Tue, 23 Oct 2012 11:01:43 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 821E021F86AF for ; Tue, 23 Oct 2012 11:01:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MCC00HVUY19T6J2@mail-out.apple.com> for homenet@ietf.org; Tue, 23 Oct 2012 11:01:39 -0700 (PDT) X-AuditID: 11807137-b7fd56d000002bf1-06-5086db82fe06 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 32.6D.11249.28BD6805; Tue, 23 Oct 2012 11:01:39 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by cilantro.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MCC00AJCY2QQJ30@cilantro.apple.com> for homenet@ietf.org; Tue, 23 Oct 2012 11:01:38 -0700 (PDT) From: james woodyatt In-reply-to: <5086B5A7.3040706@mtcc.com> Date: Tue, 23 Oct 2012 11:01:37 -0700 Message-id: <0435F886-1E8B-4302-832F-C9D0269981A4@apple.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1620) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FAspNt8uy3A4OomJov3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr41JvK3vBW/aK2a9kGhiXs3UxcnBICJhItH1262LkBDLFJC7c Ww8U5uIQEpjGJPF54ykoZw6TxMWH95hAqpgFdCR6v39jBrF5BfQkpk+YyAJiCwu4Spw4uBTM ZhNQkfh2+S5YPaeAhsSBi3fZQWwWAVWJ6XP/sUPM0ZZ48u4CK8QcG4mvq7dBLXvFLjF3ySyw BSIC+hJPj/xigzhPVmLxtXXMExj5ZyG5YxaSO2YhmbuAkXkVo2BRak5ipaGZXmJBQU6qXnJ+ 7iZGcIgVmu9g3P5X7hCjAAejEg8v57G2ACHWxLLiytxDjBIczEoivNkXgUK8KYmVValF+fFF pTmpxYcYpTlYlMR5k48DpQTSE0tSs1NTC1KLYLJMHJxSDYycMwJOu89X77Rzd1y63Xu3efvW Ezd4Vq+PzEgs71tduHeNd8Feu32pf1Y8k0iwEF206OXGRS95NMNSRFTNU3ZGfxG437zd6+gl 7ecx97I3RM27ZbgvOcJrnaq7V/CHc0tWlRZbe2a2zJWfIXY6Z+8tqY/vj29dyvl3huBJ7p8/ ywoq3ze+adyoxFKckWioxVxUnAgAZx7MUS0CAAA= Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:01:44 -0000 On Oct 23, 2012, at 08:20 , Michael Thomas wrote: > On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: >> >> Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here. > > Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::, > but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your > 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues: My IPv6 stack doesn't pick a 2001:xxxx:... address. When the VPN client connects, it inserts a more-specific host route to 2001:yyyy::/z via the VPN pseudo-interface, so the IPv6 stack picks the interface address assigned by the VPN access concentrator as the source address for application flows to the 2001:yyyy:/z network. Hilarity does not ensue. Happy faces on the security team. -- james woodyatt core os networking From teco@inf-net.nl Tue Oct 23 11:20:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8320421F86D2 for ; Tue, 23 Oct 2012 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 PLwuEuPWpGSV for ; Tue, 23 Oct 2012 11:20:58 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1681E11E80DC for ; Tue, 23 Oct 2012 11:20:56 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1782861eek.31 for ; Tue, 23 Oct 2012 11:20:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=0TimzHeOrc+9iVBzRLYwd+g5TeSz6o6OxlrmplMwC0M=; b=EjgoLvT34I35GGENE27MKKMSRs6wKplE/Ka9YBH6iazDfKgFeAd+qnHbcC89uUVMJR qYVE8ScAx38NAfvFVoTHlzmLn9IV8LFKiaCJUIDF2GH8Cl+fM/0P95IKBzGcexRMq/CG ypLbBpfB9Mx+GMg0nERHMVS4dpexsGHAr63Jx+G1IAxZks5TxoRckrnSl+yR5LU5dodx sgzApOOPTYfxge7Qld3KocMMx/cjljeig2NP12RzzOBQgr3Bd1G409HQJ5VbDB79P26K axvRjHwVGHEbMLuOCaCZxTYDLX8k6Tm9cn2FGgzgcfbHmBeMKlrcxKRXqaDzZGg1Fh1S DIYA== Received: by 10.14.207.68 with SMTP id m44mr1543600eeo.40.1351016456251; Tue, 23 Oct 2012 11:20:56 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:4183:8674:893b:f478? ([2001:470:7a9b:1:4183:8674:893b:f478]) by mx.google.com with ESMTPS id f3sm15379235eeo.13.2012.10.23.11.20.54 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 11:20:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <5086D3B8.3040909@mtcc.com> Date: Tue, 23 Oct 2012 20:20:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <726CCE0C-035F-41E2-88EA-B018293B3A42@inf-net.nl> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <5086D19C.4040002@mtcc.com> <91FB983E-7D99-434E-9B09-B842D53F7A31@inf-net.nl> <5086D3B8.3040909@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmoYPBodsQOdAMvCQ2Zk4jAtJk3a150nkXKVRLMbayMHS7bZuCDyBNsrsUKKWtr5TVITYDT Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:20:59 -0000 Op 23 okt. 2012, om 19:28 heeft Michael Thomas het volgende geschreven: > On 10/23/2012 10:25 AM, Teco Boot wrote: >>=20 >> I'm not sure if giving each host a >> prefix in 2001:yyyy's address space is scalable either for the hosts, = the SLAAC >> announcements, or just carving up 2001:yyyy's addresses, especially = if you have >> a large VPN population. I've done that myself, and I have doubts that = it's the >> right approach. >> I can't get why employer doesn't assign a 2000:: address to the = server, other >> than test uRPF filters and get protocol designers crazy :-) >>=20 >=20 > They ran of space in the 2000:: allocation? Ran out a /16 prefix? I can arrange a course on setting up an address = allocation scheme. > They merged two companies? Yepp, the need for renumbering keeps business going. We have a nice WG = for this. Please check their drafts for your scenario, I can't find it. = Request to add it? I think that in general, enterprises do not permit a VPN termination in = homenets, where internal traffic is exposed to the Internet. At least, = sad faces from the security team. That brings us back to the MIF use case, with VPN and Internet = provisioning domains. And VPN kit on a host. > There's lots of reasons why a company would have multiple prefixes. Yes.=20 On MIF and VPN termination in the homenet, a host can get addresses from = multiple DHCP servers, each with own DNS server(s), just like a normal = MIF node. What is the problem? (other than get BRDP in place and a = couple of sad faces :-). Teco >=20 > Mike From jhw@apple.com Tue Oct 23 13:20:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5301F0CAA for ; Tue, 23 Oct 2012 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32WdicSvxyPX for ; Tue, 23 Oct 2012 13:20:18 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id B226F1F0CA3 for ; Tue, 23 Oct 2012 13:20: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 Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MCD00H6W4D4T643@mail-out.apple.com> for homenet@ietf.org; Tue, 23 Oct 2012 13:20:18 -0700 (PDT) X-AuditID: 11807130-b7f286d000002ac2-97-5086fc02ff5d Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (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 85.F3.10946.20CF6805; Tue, 23 Oct 2012 13:20:18 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by orrisroot.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MCD00GJ04HUJB60@orrisroot.apple.com> for homenet@ietf.org; Tue, 23 Oct 2012 13:20:18 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: <20081.1351020585@obiwan.sandelman.ca> Date: Tue, 23 Oct 2012 13:20:18 -0700 Message-id: <410528EE-63CB-4791-934A-F54C7BEF3F51@apple.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1620) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUi2FCcpcv0py3AYP93eYv3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+SH2YwF25krzr18z97AeJ2pi5GTQ0LAROLExw9sELaYxIV7 64FsLg4hgZlMEsuXnGaBcOYxSey8uR2sSlggQOJT4z4WEJtZQEti/c7jYJN4BfQkpk+YyAJR 4ypx4uBSMJtNQEXi2+W7YDWcAsYSl4/NBbNZBFQlZlxYzQYxR1viybsLrBBzbCQWTd8KdcUr dom5S2YxgyREBPQlnh75BXWqrMTia+uYJzAKzEJyxywkd8xCMncBI/MqRsGi1JzESkNDvcSC gpxUveT83E2M4PArNNjBuPYn/yFGAQ5GJR7e9BNtAUKsiWXFlbmHGCU4mJVEeCffBQrxpiRW VqUW5ccXleakFh9ilOZgURLnjT8OlBJITyxJzU5NLUgtgskycXBKNTCauHRs3aJ+X0exaKJQ kGeZwu0vt1d+qnt//ExzadMB7/e6Gn92RagZaN64vGmlX9riW6GWvcs8D6S5tm9QPFT3bbbb UvMsuU2LbvordmpaSNblihw/55ZZ+kVq3ZK/Uyuamp0cdsj9kJloxvTpYmp/Ssypjztuzgls Zdq/xeS8ftXMovMPNPKVWIozEg21mIuKEwHG8jaeOwIAAA== Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 20:20:19 -0000 On Oct 23, 2012, at 12:29 , Michael Richardson wrote: > > And the virtual machine on your laptop uses? > (the current answer: NPT66) p1. NPT66 is lousy for this problem; other approaches are proven to work better, but alas I'm not sure I can talk about them here just yet. p2. laptops are so 20th century... haven't you heard? -- james woodyatt core os networking From rja.lists@gmail.com Tue Oct 23 14:14:02 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76CE11E80DC for ; Tue, 23 Oct 2012 14:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 dKYROqHUq3k3 for ; Tue, 23 Oct 2012 14:14:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 331E711E80BF for ; Tue, 23 Oct 2012 14:14:02 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so5236865vbb.31 for ; Tue, 23 Oct 2012 14:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=G0OnhA2D7FsN6sKI2rXg1XOLzhTTTFstDQ3nY1cQiRA=; b=L9C4WhdGykEIJO9yBssdefSBaqn9AnyR1lddDl7IduEq8eS0eP3vjSriNV6JVA5+uB 1WWfJiAHG+53O3oObciYif1U7jweLE+qmpcnpyeJee1KNFVX5uf1K6VOKSJ8/z25OY05 8XP1lBn8ASKapvB5kva91x0l7FfNBbvuAMR4/F6Kwuw4QHl7HGIUnmOH4bmeXFqH9vVH xdNEg4p5LBfFcOuVKR+LVg6u3T21fLgvltwGQGyrS+6aTDrJWEWaLp5W+q/cgwNOx1nb iJ+I8diO3dimP3UcoOdpvSAR2bHqahze6p1pyoHn6TVX76il39gINiLTETk1DcwxTU4+ GueA== Received: by 10.52.36.40 with SMTP id n8mr18347121vdj.52.1351026841567; Tue, 23 Oct 2012 14:14:01 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id f10sm14236606vdk.5.2012.10.23.14.14.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 14:14:00 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 23 Oct 2012 17:13:58 -0400 Message-Id: <4C5FCEF8-5DE1-41BD-B741-0A33203E7A17@gmail.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:14:02 -0000 I agree with Lorenzo Colitti, Ted Lemon, James Woodyatt, and various others about the adverse operational impacts of using NPT66. So I also agree that the Home Net Architecture document (and any other applicable Home Net documents) ought to clearly indicate that NPT66 is NOT part of the HomeNet Architecture and is NOT a recommended approach. It might be useful for James Woodyatt's notes about these technical issues to get written up as an Informational RFC, to help document the technical issues/operational issues for any new participants here (and more generally for IETF newcomers who might not immediately grasp the issues). Yours, Ran PS: Yes, I understand this won't stop a vendor from shipping NPT66, but we can at least make it clear that NPT66 has significant technical limitations and unresolved issues, so is NOT part of the Home Net solution set. From lorenzo@google.com Tue Oct 23 17:27:45 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1129611E8118 for ; Tue, 23 Oct 2012 17:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnIo7XJh6q-3 for ; Tue, 23 Oct 2012 17:27:44 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3385C11E80D7 for ; Tue, 23 Oct 2012 17:27:43 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so4896765oag.31 for ; Tue, 23 Oct 2012 17:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=e5bncUlwxH2X3B7jvX62eTFVd7WV4kFZ9TRqugaYslw=; b=X8lUuP8OzVCLzJIqlf/TWSEcezzg4Vvrf21RJVnBnD/DfyZjMlzRu0pEPqoesTvSSG uNrYBQ9ybaiBaMAXj51BOul8kqam978iA4ww6HhVw/wA10RzN3cy6adN94+EPj1ZbXHZ j+Mwi6/Yly2ayV1T19kx4L//XETOY5U8dxTXyC7bhj1HCH+wXIq8qoOSFQQUxaCKHiFR qHYgN40iFqDRqk79qI9C6SCJ/dVLEZsEeQLqFXMM6zzXNOp9E7ngSvjNcV20N3ryjU6a AVcVbEuKunIXyYNjbj+lDvDy5Go7Cf0RiuWOpBALeySboWEb8XaY89YN/RnWZcqgt1NN YyCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=e5bncUlwxH2X3B7jvX62eTFVd7WV4kFZ9TRqugaYslw=; b=fwgNbPZ4WiDmeSMtUqL+ywIdTtbS4xEcuUcqZizeXZqD1jiKlylO2615mwr/Gt6XMR TB980kFkgaLwPYOLdfIcVnn7fQdp24DP243BzkrsnG/Twy+cYLzni+IALp0L00tevyHZ z9sCzHqgJzQnCl31IXwL+GFBtBFORwxE5XQxQeReBz8F/zW5I9XrMqyobeYDziUI0orh EvydB/fZPAJp1q8t5EA3k6CE703HvKeT7yey7pHqx1gdUKXFfXR2kVbJhI1LPn0NFSIt NXmGSWgJmdoK8qdMdMB5IIO3JJAU2Qzpyt+LtG2M6JjwdII4X/vec9DAeqvNbMf15gdN h6zg== Received: by 10.60.14.165 with SMTP id q5mr12999377oec.28.1351038463517; Tue, 23 Oct 2012 17:27:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 23 Oct 2012 17:27:23 -0700 (PDT) In-Reply-To: <5086B5A7.3040706@mtcc.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> From: Lorenzo Colitti Date: Wed, 24 Oct 2012 09:27:23 +0900 Message-ID: To: Michael Thomas Content-Type: multipart/alternative; boundary=e89a8fb1f468b2244004ccc327af X-System-Of-Record: true X-Gm-Message-State: ALoCoQmVg55Oceaz1fv7Y1VidEwUIhYHonMh3r+xtZ1LIHqgvCAhsud8pjZa30OXCObdnLHif+aZCUbIs536O6IlTzxqYURZUuTyCsp97jqJYFm8wPLuicGK6Ps9lzeOMm+VnJmaB4Gaa7XySm9q9jy/GBmbqEsO8wxQald39Kr3gYOGWgn50PQcGO2fBpqkAYJMYFiPEVtn Cc: homenet@ietf.org, james woodyatt Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 00:27:45 -0000 --e89a8fb1f468b2244004ccc327af Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 24, 2012 at 12:20 AM, Michael Thomas wrote: > On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: > > On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas > mike@mtcc.com>> wrote: >> >> No, sorry. Corporate VPN's using v6 and the lack of a coherent source >> address selection mechanism causes breakage in bizarre and unpredictable >> ways. You are not going to get the results you hope for if your mac uses an >> ISP prefix to get back inside the corpro firewall, uRPF if nothing else. >> SLAAC changes a lot of things over v4. >> >> >> VPN clients already modify the routing table to ensure traffic going >> through the VPN goes through the VPN, to enforce policies around split >> tunneling, and so on. Mine even monitors the routing table for changes so >> it can act on them. >> > > Routing is irrelevant. Sorry, but no. Routing is not irrelevant: Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB. The choice of outgoing interface is a routing decision and thus the routing table can be used to influence source address selection. > Can you explain why this behaviour, combined with the "prefer matching >> interface" rule in RFC 3484, is not sufficient? If not, then there is no >> problem to solve here. >> > > Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you > 2000::, but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. You missed the "your employer configures your routing table to point 2000::/64 and 2001:yyyy::/64 to the tunnel interface" step. Your employer has to configure your routing table today for IPv4 (either a default route or more-specific routes to private addresses for split tunneling). In IPv6 said employer needs to give you more specifics. > Your 3484 v6 stack picks 2001:xxxx for the source address. Nope. A routing lookup tells the kernel that the tunnel interface will be used to send to that destination, and the RFC3484 stack will pick 2000:: as the source address due to rule 5 above (note that you don't need to invoke 5.5 in RFC 6724 to make this work; RFC3484 is sufficient). > Hilarity ensues: 1) the packet gets rejected via uRPF > 2) the return packet splats against the inside firewall since it's not > allowed outside > 3) the packet makes it outside unarmored with sad faces from the security > team As James said, none of this happens. Now - if we want to make this in a routed network where the VPN tunnel is not terminated on the device itself, then RFC 3484/RFC6724 are not sufficient. But that problem not substantially different to the "multihomed with two ISPs problem", which we are trying to solve anyway. I believe this can be solved properly using source/destination routing. --e89a8fb1f468b2244004ccc327af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2012 at 12:20 AM, Michael Thomas <mike@mtcc.com>= wrote:
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:

On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:

=A0 =A0 No, sorry. Corporate VPN's using v6 and the lack of a coherent = source address selection mechanism causes breakage in bizarre and unpredict= able ways. You are not going to get the results you hope for if your mac us= es an ISP prefix to get back inside the corpro firewall, uRPF if nothing el= se. SLAAC changes a lot of things over v4.


VPN clients already modify the routing table to ensure traffic going throug= h the VPN goes through the VPN, to enforce policies around split tunneling,= and so on. Mine even monitors the routing table for changes so it can act = on them.

Routing is irrelevant.

Sorry, but no. Routi= ng is not irrelevant:

=A0 =A0Rule 5: Prefer o= utgoing interface.
=A0 =A0If SA is assigned to the interface that= will be used to send to D and
=A0 =A0SB is assigned to a different interface, then prefer SA. =A0Sim= ilarly,
=A0 =A0if SB is assigned to the interface that will be us= ed to send to D and
=A0 =A0SA is assigned to a different interfac= e, then prefer SB.

The choice of outgoing interface is a routing dec= ision and thus the routing table can be used to influence source address se= lection.=A0


Can you explain why this behaviour, combined with the "prefer matching= interface" rule in RFC 3484, is not sufficient? If not, then there is= no problem to solve here.

Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::,= =A0but also has 2001:yyyy::. You connect to a server on 2001:yyyy::.

You missed the "your employer configures you= r routing table to point 2000::/64 and 2001:yyyy::/64 to the tunnel interfa= ce" step. Your employer has to configure your routing table today for = IPv4 (either a default route or more-specific routes to private addresses f= or split tunneling). In IPv6 said employer needs to give you more specifics= .
=A0
Your=A03484 v6 stack picks 20= 01:xxxx for the source address.

Nope. = A routing lookup tells the kernel that the tunnel interface will be used to= send to that destination, and the=A0RFC3484 stack will pick 2000:: as the = source address due to rule 5 above (note that you don't need to invoke = 5.5 in RFC 6724 to make this work; RFC3484 is sufficient).
=A0
Hilarity ensues:=A0
1) the packet gets rejected via uRPF
2) the return packet splats against the inside firewall since it's not = allowed outside
3) the packet makes it outside unarmored with sad faces from the security t= eam

As James said, none of this happens.

Now - if we want to make this in a routed network wh= ere the VPN tunnel is not terminated on the device itself, then RFC 3484/RF= C6724 are not sufficient. But that problem not substantially different to t= he "multihomed with two ISPs problem", which we are trying to sol= ve anyway. I believe this can be solved properly using source/destination r= outing.
--e89a8fb1f468b2244004ccc327af-- From lorenzo@google.com Tue Oct 23 17:33:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EC911E812A for ; Tue, 23 Oct 2012 17:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URpTTHv5kHzc for ; Tue, 23 Oct 2012 17:33:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0111E8129 for ; Tue, 23 Oct 2012 17:33:08 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4846080obq.31 for ; Tue, 23 Oct 2012 17:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KU7cIAErF+yqPpkzdOKh7WZGZJCHeOSTv3FYzw2p6yo=; b=aP+gqvtnZ+yodCEQgztr8xdFM6egBsTxJTrqkeQavipIse3ruxLQ/6zTJN88j+IZ6d g0mBBfioy4QIeeQWSLVb2v0Uiinpg1WivwWN22iKcnWyqWycl419h7oL+G9skVD6z1Gj cMQ5ERafVNpWplPsd8H6f0vorKldkBfvis00+NtKpCRZFz+mhN7j8uyQmrnkzJVom8Aq p8cMu75d0quNSiQmDJZroJx8dfKDRSQ3s40gY8f2YxDHfkjIOdrRcwTsptSslOLY8S0l U3dDUAm+uv54ofR/0r5YiGVt7vULRHDLF4umEJz15OTLOPR4//h7voByi/S9OmBTOBRV glnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KU7cIAErF+yqPpkzdOKh7WZGZJCHeOSTv3FYzw2p6yo=; b=DwHQAdWWBayJte8H2ckNIAd4eD9LuCvwtyVlm+Ezje2lsmJV24BWvacgDOj5d0zium SDL30TddmpsGbZBQ9dMpdVZuSgTGn4WkBeTpcoSPrHYmIPxbTcAxHpImkU8aUnHiLPK/ D8W8bzVDXmHbP2My5bM9XVSpPLzlux6+2mkzUktGIMDKeN2ClrwvUyUUakRvO+sILZZ9 e46Gb6II9l0cx3A4Nbu+Thfkj8ar5oUMR6PQRiXEDf6r3tRwogQBqNen4GNCfkN2qwRG Xglmc1gaktmWCa2BM+MZ8hWoDuK3+PGb8FPbZQwkXve/V3USLQISnPUZa5nxphcnBGtZ SN/A== Received: by 10.60.154.231 with SMTP id vr7mr5096185oeb.119.1351038787763; Tue, 23 Oct 2012 17:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 23 Oct 2012 17:32:47 -0700 (PDT) In-Reply-To: <24641.1351011789@obiwan.sandelman.ca> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <24641.1351011789@obiwan.sandelman.ca> From: Lorenzo Colitti Date: Wed, 24 Oct 2012 09:32:47 +0900 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=bcaec550b6f605bd5004ccc33b59 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkUzoYuoo2OPA1Xkkg2WT8hrS8AsbaKYq+cz1SAdAsHoieKEAp74zyxxwbOHHMUl2g9yMUcsOOSPcLVf+sJ2r3+ZSvW7NilprFxvjh0nRdBUqZNzoJZ8ue0N4suvhPDt0N3gbRzaOYho5qVwIFWHV5ooygyerLJZrwWBYPzFgrpRVBvxOZgsmiYlQHorU/iYec1QYcT Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 00:33:09 -0000 --bcaec550b6f605bd5004ccc33b59 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 24, 2012 at 2:03 AM, Michael Richardson wrote: > That solves the routing problem. > But, what about the naming problem? (whose DNS server do you use?) > NPT66 doesn't solve that either, right? I believe the DNS problem needs to be solved using split DNS at the domain level, because in the general case that you have more than one VPN there's no other way to do it. > Will this solution work if it's more than just your laptop? > If the VPN terminates on a gateway device? > This is a multihoming problem which needs to be solved anyway, and I think it can be solved using source/destination routing. > (Or, for instance, what about the virtual machines that you might > run on your laptop) > If the VMs are bridged, it's no different from the multihoming problem. If they are not, then how are they going to get addresses? --bcaec550b6f605bd5004ccc33b59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2012 at 2:03 AM, Michael Richardson <<= a href=3D"mailto:mcr+ietf@sandelman.ca" target=3D"_blank">mcr+ietf@sandelma= n.ca> wrote:
That solves the routing problem.
But, what about the naming problem? (whose DNS server do you use?)

NPT66 doesn't solve that either, right?

I believe the DNS problem needs to be solved using sp= lit DNS at the domain level, because in the general case that you have more= than one VPN there's no other way to do it.
=A0
Will this solution work if it's more than just your laptop?
If the VPN terminates on a gateway device?

<= div>This is a multihoming problem which needs to be solved anyway, and I th= ink it can be solved using source/destination routing.
=A0
(Or, for instance, what about the virtual machines that you might
run on your laptop)

If the VMs are brid= ged, it's no different from the multihoming problem. If they are not, t= hen how are they going to get addresses?
--bcaec550b6f605bd5004ccc33b59-- From mcr@sandelman.ca Wed Oct 24 16:11:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FBD21F8C8D for ; Wed, 24 Oct 2012 16:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUiD9EWEDEBW for ; Wed, 24 Oct 2012 16:11:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id DA45B21F8C87 for ; Wed, 24 Oct 2012 16:11:33 -0700 (PDT) Received: from sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id CE05A81AA; Wed, 24 Oct 2012 19:03:57 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AA853CA0BC; Wed, 24 Oct 2012 19:11:31 -0400 (EDT) From: Michael Richardson To: james woodyatt In-reply-to: <410528EE-63CB-4791-934A-F54C7BEF3F51@apple.com> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <410528EE-63CB- 4791-934A-F54C7BEF3F51@apple.com> Comments: In-reply-to james woodyatt message dated "Tue, 23 Oct 2012 13:20:18 -0700." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Oct 2012 19:11:31 -0400 Message-ID: <29926.1351120291@sandelman.ca> Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 23:11:42 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable james woodyatt wrote: JW> On Oct 23, 2012, at 12:29 , Michael Richardson JW> wrote: >> And the virtual machine on your laptop uses? (the current >> answer: NPT66) JW> p1. NPT66 is lousy for this problem; other approaches are proven JW> to work better, but alas I'm not sure I can talk about them here JW> just yet. My example of VMs on a laptop is just to make the gateway-is-external-to-the-host situation tangible to people who might think that corporations would never deploy a gateway machine for a corporate VPN. (We know that they do, it's in Baker's document...) JW> p2. laptops are so 20th century... haven't you heard? Yup. The quad-core processor in my the tablet I'm typing this on=20 keep suggesting I boot up qemu to I can play minesweeper. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiHWjAAoJEKD0KQ7Gj3P2cqsH/2nZFH0w0Tkv0wyrvS2ISmcD hHufOy10BL1Uk24dYs7WWMMmKMg/g7675GHeV80seHzcgRCaSAVAkLK3AsbogKuU GfXXZc3GC+udL1vQoAu9L7lwUChyGFDZ2B4vIDFw/oKbvi6wurQAAuFPLn5W2Wem 1fbueHoeQLseL71H9n4gQr45Nz4b5VT8ndysjAeEl/RHtPBFDY13ffHu59eaXhRc rA3aMeLhMGuCo21uBAxvtNb/4rfoapRBb7yzygE8gpOP4TO+KdLS2ZLjja1kFXZ9 rO1t69sjZwQanVfhovvQ+UpeINpLZHrLMT1oqBeUFNZiOkX7AFC85g20MSu6/ok= =RoTm -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Oct 24 16:25:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B1E1F0C4C for ; Wed, 24 Oct 2012 16:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raD8u3NMGxWe for ; Wed, 24 Oct 2012 16:25:54 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B777E1F0419 for ; Wed, 24 Oct 2012 16:25:54 -0700 (PDT) Received: from sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id 8D86181AA; Wed, 24 Oct 2012 19:18:17 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 320A6CA0C6; Wed, 24 Oct 2012 19:25:40 -0400 (EDT) From: Michael Richardson To: RJ Atkinson In-reply-to: <4C5FCEF8-5DE1-41BD-B741-0A33203E7A17@gmail.com> References: <4C5FCEF8-5DE1-41BD-B741-0A33203E7A17@gmail.com> Comments: In-reply-to RJ Atkinson message dated "Tue, 23 Oct 2012 17:13:58 -0400." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Oct 2012 19:25:39 -0400 Message-ID: <30773.1351121139@sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 23:25:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable RJ Atkinson wrote: RJ> It might be useful for James Woodyatt's notes about these RJ> technical issues to get written up as an Informational RFC, to RJ> help document the technical issues/operational issues for any RJ> new participants here (and more generally for IETF newcomers who RJ> might not immediately grasp the issues). ...+1 RJ> PS: Yes, I understand this won't stop a vendor from shipping RJ> NPT66, but we can at least make it clear that NPT66 has RJ> significant technical limitations and unresolved issues, so is RJ> NOT part of the Home Net solution set. more importantly, if said document was written from a SHOULD point of view rather than a strict SHOULD NOT, it might be possible for a large buyer of either equipment or services to use it as part of an RFP. This could be a media ISP procuring settop boxes, or a hospital procuring digital TV services, or a government department procuring a managed VPN service, etc. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiHjzAAoJEKD0KQ7Gj3P2cmAH/3Lfp+lHPeppI8suvR3mA8XS zMR1lhvkNU6n3goVbXaa4zOz6k3qbYZnbS6F/cgHCpVvaUcJZuRAsx9t/Jirewwy +opDGFEJHX8fIuw243YRcy7bbiA2dX7kWqQhHQjFFX0KiMUcnvqNHPmH6AVT5IHb PxRK6qTBiW940dDOPMpvXppqOVlDNE7sPtEFvH1RBpbfZdrD5UfGlvqpK7lEdEV+ EK+9F65IkBgKa2pf6PnL5MHtNRm3LY0gKyNbiw/bBw2D714Rw8F/tfns0VZQ8qVo IK5la12fjECqc+0TOPaNTOeaA+iiqA8NQou9WTiYHsQrkYGb+LKoxTDePGjKsNI= =k6xq -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Oct 24 16:29:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B959321F86BE for ; Wed, 24 Oct 2012 16:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX5Ew2PziYvz for ; Wed, 24 Oct 2012 16:29:20 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4623C21F86A2 for ; Wed, 24 Oct 2012 16:29:20 -0700 (PDT) Received: from sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id 9DFBA81AA; Wed, 24 Oct 2012 19:21:44 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0042ACA0BC; Wed, 24 Oct 2012 19:20:00 -0400 (EDT) From: Michael Richardson To: Lorenzo Colitti In-reply-to: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <24641.1351011789@obiwan.sandelman.ca> Comments: In-reply-to Lorenzo Colitti message dated "Wed, 24 Oct 2012 09:32:47 +0900." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Oct 2012 19:20:00 -0400 Message-ID: <30501.1351120800@sandelman.ca> Sender: mcr@sandelman.ca Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 23:29:20 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Lorenzo Colitti wrote: >> That solves the routing problem. But, what about the naming >> problem? (whose DNS server do you use?) >>=20 LC> NPT66 doesn't solve that either, right? LC> I believe the DNS problem needs to be solved using split DNS at LC> the domain level, because in the general case that you have more LC> than one VPN there's no other way to do it. I agree... NPT66 doesn't solve the problem. If I was forced to build such a system, I would put a private copy of a stub resolver in my app, and do DNS requests inside. In the walled garden situation, however, if I had to hide the AAAA records (which I think is fundamentally broken, but...), then I'd have NS delegations from the public DNS into name servers that live in my walled garden. So, you could see that my streaming TV system is at=20 walledgarden.tvservice.jp, but you couldn't resolve server23.walledgareden.tvservice.jp. >> Will this solution work if it's more than just your laptop? If >> the VPN terminates on a gateway device? >>=20 LC> This is a multihoming problem which needs to be solved anyway, LC> and I think it can be solved using source/destination routing. Agreed, which is why I brought it up. I'm trying to say that since it's not enough to force the host always get it right, we need to make sure we have a solution which improves when the host helps, but doesn't depend upon it. >> (Or, for instance, what about the virtual machines that you might >> run on your laptop) LC> If the VMs are bridged, it's no different from the multihoming LC> problem. If they are not, then how are they going to get LC> addresses? In homenet, if we router where we bridged before, then it would be routed. So, my virtualizer should learn to speak homenet routing protocol. (go see what nvo3 wants them to do...) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiHegAAoJEKD0KQ7Gj3P2TpoH/AnuDNc6sVgrI0xVm7ByuWX/ A8LAtXOWyEeWz8H8nnvISMvc4rZaoez71iIyeID1Tu9tUxLBGNurf2OW5j7SwpzH 0l6pJKEpjbUwcHWqN/7eG46bfeW5DDqA2XMwNr+p1w7hlr/uqpt9o+kUprY0KqYt HKuYetHdyewqAtV3n6thPsfMDK3yrI7W28BmWAkCZDRtqLVXCdGaiK2RwhmbQLiN H1y+IoX9pbNivYquSVzZLjVHJWDz+E8CVjBYzV+DDyLsEdVdot/r7OpGaaX+U75W s0WC3O70Kmr3BUXeIj9cT9IvKZNePZpdN4xBgYTwQeMnc5ZiCy26Z94ZfpiazrA= =e7/l -----END PGP SIGNATURE----- --=-=-=-- From lorenzo@google.com Wed Oct 24 17:11:44 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556391F0419 for ; Wed, 24 Oct 2012 17:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuCL0tYDvA4f for ; Wed, 24 Oct 2012 17:11:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4721F8C4B for ; Wed, 24 Oct 2012 17:11:39 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1170306obq.31 for ; Wed, 24 Oct 2012 17:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=fNXqUAsBM+NEsbTeyD1gIrrQzfp6zT0DkDvkKdOlGoQ=; b=cF/eo+kQ5nOeE4u5ysuDqPtpxiJiddN9LJYbOl+KjsIE7LujCLeBGFXyVFw64E5BKP 0YRozPDpSi5lu215rD98lB99ep8r5leOTGmP0yddl54Nw5L47BQzdgj39TiGREKSI0qY 1YOaDhBxm+GWymcGu4Hg0xOHQE5hwiAMCvF+T8wDiI5AwOCXN7x4GV0ECGlF49SYEyNL jIQVBDAccPwFveZqPFFluuodmrTq89h+wRiCvhGPBRTBUB0Q/cGQbUGBFx6xEOywkN/l bJuGE0w3bx3t6ly/1JLEEiPKT+THlrLIB5n9j+3GYJyTwemLFp4tTvi9CoGAK5SVsDdj 1zEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=fNXqUAsBM+NEsbTeyD1gIrrQzfp6zT0DkDvkKdOlGoQ=; b=kvBT7m5pT8nWsplPfjTQJJIRVejuDsnHcH0NtBtlNdcdpmjQ+hNOm//OiNx8O7KcWQ 5iZhEXQkwadApToHl7DrbsHAIwsD5Exh225vPHxNkyVH5cDlQTnOFUnI3GYN4r6XdjaP eyz1fu9v3y0ZfNGNeXM/rg4cEn1lOWpetvwiGAzhFYTZXWtyeMNUvbfgW5EnA9A6zbcG xIap8ofmUl3wzL8onaDS3kO0dCc8oBm+evAu/53R4uviOHKy9G8ngswzOaLQRAJSulYQ bBafZI7FGCOO8SJTVcI8JqFa9w0ivusMk6F52htz5zSfv/89jGtymqBtq4ORbabSMdKA MLxw== Received: by 10.60.14.165 with SMTP id q5mr15855577oec.28.1351123898914; Wed, 24 Oct 2012 17:11:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Wed, 24 Oct 2012 17:11:18 -0700 (PDT) In-Reply-To: <30501.1351120800@sandelman.ca> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <24641.1351011789@obiwan.sandelman.ca> <30501.1351120800@sandelman.ca> From: Lorenzo Colitti Date: Thu, 25 Oct 2012 09:11:18 +0900 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=e89a8fb1f4680ad68304ccd70ccc X-System-Of-Record: true X-Gm-Message-State: ALoCoQkcPzhxgyLdK1QoSpX/XLONy2113qnj4TLpp/rQb8bYaisXgPITsf9yOiDURy2SmMRFbzIo25P3sBGfxbUK05cmpW1Y75WTjdO8lHqutbAXVQkSdwCQYBQGe6B5O3igQtidWSWd71l8qa1eV4P3fLpMD+YYBWenGH9BT3L/PldNyUtdIYPMH3ZU3Zd0HxnANySQmaID Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 00:11:44 -0000 --e89a8fb1f4680ad68304ccd70ccc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 8:20 AM, Michael Richardson wrote: > In the walled garden situation, however, if I had to hide the AAAA > records (which I think is fundamentally broken, but...), then I'd have > NS delegations from the public DNS into name servers that live in my > walled garden. So, you could see that my streaming TV system is at > walledgarden.tvservice.jp, but you couldn't resolve > server23.walledgareden.tvservice.jp. > Solution: from the border router which discovered the DNS entries for tvservice.jp, inject those DNS servers into the mesh with a tag that they only be used for tvservice.jp, and pass that around in the routing protocol. No? --e89a8fb1f4680ad68304ccd70ccc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 8:20 AM, Michael Richardson <<= a href=3D"mailto:mcr+ietf@sandelman.ca" target=3D"_blank">mcr+ietf@sandelma= n.ca> wrote:
In the walled garden situation, however, if I had to hide= the AAAA
records (which I think is fundamentally broken, but...), then I'd have<= br> NS delegations from the public DNS into name servers that live in my
walled garden. =A0So, you could see that my streaming TV system is at
walledgarden= .tvservice.jp, but you couldn't resolve
se= rver23.walledgareden.tvservice.jp.

= Solution: from the border router which discovered the DNS entries for tvservice.jp, inject those DNS servers into = the mesh with a tag that they only be used for tvservice.jp, and pass that around in the routing protocol. No?
--e89a8fb1f4680ad68304ccd70ccc-- From n@arifumi.net Wed Oct 24 23:25:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908F221F903C for ; Wed, 24 Oct 2012 23:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1feX++7tHF3z for ; Wed, 24 Oct 2012 23:25:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0100421F8F26 for ; Wed, 24 Oct 2012 23:25:18 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1591183vbb.31 for ; Wed, 24 Oct 2012 23:25:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=4UZ8Atf+57FiFT5bCVILqmy5e4GTWrb3ryGF/UP3K88=; b=TjIOPzHpimTZI83LeGdUf872yRV+sThaCygUAMCTSzr3kLocHJBtHlj1DP0N+OuZ81 ng88+WmVPA8W+i60lrpNMXL5PixLgjH3X7uVza9yINTyVS2Vs2QIYyq8WZJ8WCcVsXxi mwkov+EJBZUa+XbS9/ibdPIClSjRkFFRy2JJscsiCtbLIxTOcgs53OJk5RlvFaXzAqnZ sFw1W/ICCEl3PiRd9lHwB8wIID66thoBfyQZ8BAkVEVIYPEhRoNgXBSGyROYYu06ljdU ec6Lm5Qwt7PA2G/wmOdIURjNS6evkCD0PcECKOc8VLToOKixxhMgp5xVDsoJHXdEpAmU 3SBg== MIME-Version: 1.0 Received: by 10.58.64.196 with SMTP id q4mr33785573ves.3.1351146318325; Wed, 24 Oct 2012 23:25:18 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Wed, 24 Oct 2012 23:25:18 -0700 (PDT) X-Originating-IP: [192.47.162.190] In-Reply-To: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> Date: Thu, 25 Oct 2012 15:25:18 +0900 X-Google-Sender-Auth: ngFs0CHvPLtODXwnqPdR9eTXjW8 Message-ID: From: Arifumi Matsumoto To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmI/ERN5hU97qFdgr5mNlas3SRw3XrKnCnGN4BeEFS97JflTQXVF5Nad40YAzZDWA/sHop5 Cc: homenet@ietf.org, Michael Thomas , james woodyatt Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 06:25:19 -0000 Hi, > Now - if we want to make this in a routed network where the VPN tunnel is > not terminated on the device itself, then RFC 3484/RFC6724 are not > sufficient. Even in such a case, you can configure manually the policy table on each host to meet the needs of such source address selection. This mechanism is included in both RFC 3484 and RFC 6724. Moreover, the policy table auto-configuration protocol is now at WGLC state in 6man. Thanks. From mike@mtcc.com Thu Oct 25 06:38:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F6D21F8977 for ; Thu, 25 Oct 2012 06:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stQQnKAgyNGm for ; Thu, 25 Oct 2012 06:38:38 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 0129A21F8974 for ; Thu, 25 Oct 2012 06:38:37 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9PDcTEf032398 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Oct 2012 06:38:30 -0700 Message-ID: <508940D5.60806@mtcc.com> Date: Thu, 25 Oct 2012 06:38:29 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Arifumi Matsumoto References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=960; t=1351172314; x=1352036314; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20Arifumi=20Matsumoto=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=QlcT1r+ABhVRZ2/SQgbTSaUpAiriaTTOuCDthLumT1Q=; b=C7u0tzbZt7CJXo7bFyx5HPr4rrASAtHog5+FmnW7gCY6lpcGvx9z3CE9wc oBEAAbKK+BtyzNZExGG/qlkCVA9TexPiDjwpzM7zbg+vhA3GgcuGn3cubEbr lBB4HJYdl+QOY4BlNB5ui7Z/G0FCuSUzkpFIt9irk/7WvLYqPnDx0=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org, james woodyatt , Lorenzo Colitti Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:38:38 -0000 On 10/24/2012 11:25 PM, Arifumi Matsumoto wrote: > Hi, > >> Now - if we want to make this in a routed network where the VPN tunnel is >> not terminated on the device itself, then RFC 3484/RFC6724 are not >> sufficient. That was, in fact, what I was thinking about. > Even in such a case, you can configure manually the policy table on each host > to meet the needs of such source address selection. This mechanism is > included in > both RFC 3484 and RFC 6724. > > Moreover, the policy table auto-configuration protocol is now at WGLC state > in 6man. > My only point is that until such an auto-configuration protocol is widely deployed, there is a real risk that NPT will be deployed as the stopgap that never goes away. History is on the side of network-based fixes when hosts can't do the right thing. This working group can snarl all it likes about such heresies, but it won't alter the outcome if there's a perceived need. Mike From mcr@sandelman.ca Thu Oct 25 07:20:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FC921F89C6 for ; Thu, 25 Oct 2012 07:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvLyhRjImIkN for ; Thu, 25 Oct 2012 07:20:37 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA6021F896B for ; Thu, 25 Oct 2012 07:20:37 -0700 (PDT) Received: from sandelman.ca (unknown [67.71.177.200]) by relay.sandelman.ca (Postfix) with ESMTPS id 2CC3A81A9; Thu, 25 Oct 2012 10:12:59 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AC02ECA0C6; Thu, 25 Oct 2012 10:20:35 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-reply-to: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <24641.1351011789@obiwan.sandelman.ca> <30501.1351120800@sandelman.ca> Comments: In-reply-to Lorenzo Colitti message dated "Thu, 25 Oct 2012 09:11:18 +0900." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 25 Oct 2012 10:20:35 -0400 Message-ID: <31084.1351174835@sandelman.ca> Sender: mcr@sandelman.ca Cc: Lorenzo Colitti Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:20:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Lorenzo Colitti wrote: >> In the walled garden situation, however, if I had to hide the AAAA >> records (which I think is fundamentally broken, but...), then I'd ha= ve >> NS delegations from the public DNS into name servers that live in my >> walled garden. So, you could see that my streaming TV system is at >> walledgarden.tvservice.jp, but you couldn't resolve >> server23.walledgareden.tvservice.jp. >>=20 LC> Solution: from the border router which discovered the DNS entries f= or LC> tvservice.jp, inject those DNS servers into the mesh with a tag tha= t they LC> only be used for tvservice.jp, and pass that around in the routing LC> protocol. No? While it's reasonable for my TV settop-box to pay attention to that extension, why would my laptop or browser know about it? This really seems invasive to multiple layers of the stack, and I think it is completely unnecessary. Zone delegations solve the problem using existing protocols and existing software. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiUqyAAoJEKD0KQ7Gj3P2rP0H/jW3lbQcJP2jcw9WCT/AO5ZL ucetClaGoUOHGqEymHPDOZ0NTpp308lNi4Gof0/qIZIHPzdp3nLSMyp0kEy0zDHQ 9HZa5/AqtcZw0O5rOlEnI2nA3s1VBcTxoMPLVIQFtdpbxl4+cvgXOEmr5xiMUQcB 9yOJRceYybHvgTuvIMLWtP5cXvsLWtbPPwKreQmytrcVhpqTIycWeoTfHedG2BR3 HEEfmtBQwqQCoDXZZ2Fsr+DNds7LjcjNkG7NV5jgixOb56NDufaR+QM0Qb/ZlfiJ 0x1oHwhBR8X3MOyhwJiLhPeWh7YPkmBVpgojWS4hvvY400xGx/wguHHXuELYOQI= =tDAc -----END PGP SIGNATURE----- --=-=-=-- From rja.lists@gmail.com Thu Oct 25 09:08:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627FF21F89BD for ; Thu, 25 Oct 2012 09:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 f-koXI+HkoHv for ; Thu, 25 Oct 2012 09:08:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C552121F8956 for ; Thu, 25 Oct 2012 09:08:18 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2238083vbb.31 for ; Thu, 25 Oct 2012 09:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=nXGjgOKHAY4Otf8giaAqYb/qWcxQpKbVEy2yvfe+QoY=; b=tbM0D1OUGt4L23Wy8kCG1EfmYY7B0ZZ9P3zMxr28DwNHBwSQtlJp9EIz++kjOMlzm6 DsY0W5/Kf6D7fjSctgfQ1amBHySK03dxQjTOtUHpp2lVH+dCzgpTXpm4NmfMf1+h9wuK Vm6cxLdWuKgpZOR6VNkKVhZZnDf60V4XzsvXtAWjWI/Wl4CI8ZiEg/kwyNaqKUUVFGeX rN3ZG6aitoduI7Qgf0W15SeOxV1CAmlGKholb5GRnmuQySzS/D56Kf58/XGnFVUHmcp3 CbUdSmQ/OWhR0kt3nU7YQmmt4cdDhkeeSIDAj1oF5qsciqMhRvmBHrz5c6ky+59F+KPr B82w== Received: by 10.58.23.202 with SMTP id o10mr36061823vef.57.1351181298315; Thu, 25 Oct 2012 09:08:18 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id r6sm19226273vdj.8.2012.10.25.09.08.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 09:08:17 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Oct 2012 12:08:15 -0400 Message-Id: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:08:19 -0000 On Thu, 25 Oct 2012 09:11:18 +0900, Lorenzo Colitti wrote, in part: > ...from the border router which discovered the DNS entries > for tvservice.jp, inject those DNS servers into the mesh > with a tag that they only be used for tvservice.jp, > and pass that around in the routing protocol. No? I'm not comfortable with overloading a routing protocol for use as a DNS transport mechanism. I'm also nervous about both DNS authorisation and DNS authentication. Who is allowed to make which DNS advertisements and how do I authenticate the received DNS advertisement as both valid and authorised ? (NB: With ordinary DNS, the answer is DNSsec. With mDNS, DNSsec also probably can work.) Surely there is some alternative approach that doesn't require such overloading and complexity. Yours, Ran From mike@mtcc.com Thu Oct 25 09:30:17 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A463921F893C for ; Thu, 25 Oct 2012 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 oW4YuAyVPnXq for ; Thu, 25 Oct 2012 09:30:17 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF721F892C for ; Thu, 25 Oct 2012 09:30:16 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9PGUDR3004585 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 25 Oct 2012 09:30:13 -0700 Message-ID: <50896915.6080404@mtcc.com> Date: Thu, 25 Oct 2012 09:30:13 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: homenet@ietf.org References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <0435F886-1E8B-4302-832F-C9D0269981A4@apple! .com> In-Reply-To: <0435F886-1E8B-4302-832F-C9D0269981A4@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1388; t=1351182616; x=1352046616; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=vi3cqnALLoRQFPJF2Uro/46NIKKXnVGvN/OCgo/bNI8=; b=NlliAOUuT9atL4hI2oWlotnx2k+UCSbjSuE9f4dHadLj9EywhS/h117Aki mu9TxC4dYy/dSnWVumEAs7ZPDWaiSeXtA8XdZ3q4oLooitttGZvda3BGQx5b CRZWED0zTc/RZ05uXmXUVgQs03Kc5L71oUykI8XNmFE9B/y5/hvgg=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:30:17 -0000 On 10/23/2012 11:01 AM, james woodyatt wrote: > On Oct 23, 2012, at 08:20 , Michael Thomas wrote: >> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: >>> Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here. >> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::, >> but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your >> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues: > My IPv6 stack doesn't pick a 2001:xxxx:... address. When the VPN client connects, it inserts a more-specific host route to 2001:yyyy::/z via the VPN pseudo-interface, so the IPv6 stack picks the interface address assigned by the VPN access concentrator as the source address for application flows to the 2001:yyyy:/z network. > > Hilarity does not ensue. Happy faces on the security team. > > As I alluded to in my previous note, this doesn't work unless the vpn is terminated in host devices. When it's router-router, it fails as I mentioned because the hosts are clueless. I expect that walled off overlay networks will be more rather than less prevalent in v6, especially when homenets are truly visible -- though access controlled -- from the outside which is pretty untrue today with v4/nat. Mike From sander@steffann.nl Thu Oct 25 10:32:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC1F21F8920 for ; Thu, 25 Oct 2012 10:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.247 X-Spam-Level: * X-Spam-Status: No, score=1.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKWh856yLTYm for ; Thu, 25 Oct 2012 10:32:41 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 6C41B21F88BD for ; Thu, 25 Oct 2012 10:32:33 -0700 (PDT) Received: from [192.168.1.100] (178.115.249.157.wireless.dyn.drei.com [178.115.249.157]) by mail.sintact.nl (Postfix) with ESMTP id 275A32002; Thu, 25 Oct 2012 19:32:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> Date: Thu, 25 Oct 2012 19:32:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13C65695-2D64-4987-B744-17C2A6F685A9@steffann.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1499) Cc: homenet@ietf.org Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 17:32:41 -0000 Hi, > I'm also nervous about both DNS authorisation > and DNS authentication. Who is allowed to make=20 > which DNS advertisements and how do I authenticate=20 > the received DNS advertisement as both valid and=20 > authorised ? Yes. The routing protocol saying 'please use this address to resolve = google.com' might cause some problems... With DNSSEC in place it can = still cause a denial of service when unsigned or invalidly signed data = is returned. Met vriendelijke groet, Sander Steffann From lorenzo@google.com Thu Oct 25 17:33:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F021F8847 for ; Thu, 25 Oct 2012 17:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.894 X-Spam-Level: X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSXBsCRoMR9y for ; Thu, 25 Oct 2012 17:33:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED121F8830 for ; Thu, 25 Oct 2012 17:33:58 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2439816obq.31 for ; Thu, 25 Oct 2012 17:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=LdbcGbaTZZ7BtazyME694FhM0zeinon8vFHX8DZYtws=; b=KcOwObx5+XyKEed9GrvlJrJ6JrZWNNPfM2qeF+uBqLc7tIB/3vXDLmCwFFjK9b3EXt /Pr07qe8smVPOqiCLZa/syNT55pGmFW7j7WjjlVuR2ts0jsaVqu7YEzZTjn7SHrSDRv9 MAV6LbKLSTOo+C5JTj+JwPolHVFFJe4HEw5cu9dMUI3+CDL58ETXWUgi3r8hSsvcAc2c poLLmwCr5xmg847YVCWZt4bOUT+e9NCBW1PzCNmwh40Ip/3nT12f0rEJ7tRJLk4/vyA7 KEHfebzU5mKyXW/0kt0eP/gbd3Ykj+gE+JKM6KBAo9QEXAecrPWoXciZFDmKVHJxmazq +G9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=LdbcGbaTZZ7BtazyME694FhM0zeinon8vFHX8DZYtws=; b=DnObhTBXTw25ZFRLRdStx1d6uyYnIuG7v3WRLEw/ovXWMTVZ4X0e3JElMRd4aHRijN qHGze5ZWe7OcpnvFVnenlX9o89FmVJSGeUnjx78TPFZBLwFT+yfl2HxmmVfJSdXgui+4 6ljKZ5puCVbV/NP4O35MyUbPlxMqVLn4e2KFNK0mjeADuakuj1GKeo3FttgYECyTSPvX CH0nhSQyRwF0wtentfV54eSo7ihuAlV6brtkXjyBjrTU5ZxaXrDmTsrcSaILiFYqM08x Qpg6YB9a9miR5i5mkVxNAkFhTiYwmkc9ixDh6mk6gXJVLWCI8n1/B1qHFFZMKHkcUHh3 u7dQ== Received: by 10.60.12.99 with SMTP id x3mr2270271oeb.27.1351211638454; Thu, 25 Oct 2012 17:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Thu, 25 Oct 2012 17:33:37 -0700 (PDT) In-Reply-To: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 09:33:37 +0900 Message-ID: To: RJ Atkinson Content-Type: multipart/alternative; boundary=e89a8ff25610b9f91104cceb79a7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnMHFJ2n6FIicn7JHHeF7uOF7FHVchXSB15pNQvXg3tQo8bz7hFzvPmwOkuV8zrdXQsZqvDlsBTeHX7NnhzNrb+J2dNF+n2J0Cyzn5xuSC05yBKsI56WRHQVq3r8aARF9QMbd/Hofn7yn6CQfAnjXSFYVdVg24JfKXuMFIUvTf6conB65Hv1qAy/nbtDU4CF7oLArFY Cc: homenet@ietf.org Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:34:00 -0000 --e89a8ff25610b9f91104cceb79a7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 1:08 AM, RJ Atkinson wrote: > I'm not comfortable with overloading a routing > protocol for use as a DNS transport mechanism. > Sorry, I didn't mean "routing protocol". I meant "Homenet DNS Information Distribution Protocol" (HIDP). I would expect a useful way to carry HIDP would be using the homenet routing protocol which the homenet needs to implement anyway, but other implementations such as global IPv6 multicast, its very own DHCPv6 option, SMTP between homenet devices, or carrier pigeon are possible and encouraged. After all, this is the IETF: there's always more than one way of doing things, and at least one of them is always a DHCPv6 option. But seriously: why are you not comfortable with this idea? We need a routing protocol for the homenet anyway. A link-state routing protocol can carry multiple TLVs, including TLVs for DNS servers. Routing protocols can be authenticated. The devices that need to propagage DNS are likely going to be home routers. Why not use the routing protocol? > I'm also nervous about both DNS authorisation > and DNS authentication. Who is allowed to make > which DNS advertisements and how do I authenticate > the received DNS advertisement as both valid and > authorised ? > I don't see a difference. There is no authorization or authentication today. When you get a DNS server via DHCP, you believe it, or choose not to believe it, based on no information at all. If there's a rogue DHCP server on the link that hands you a rogue DNS server, then guess what, you lose. The only thing that would change here is that you would use HIDP to distribute that information more than one hop away. Whatever mechanism that you want to use to authorize and authenticate DNS servers can be used regardless of whether you learn them via HIDP or via DHCP. > (NB: With ordinary DNS, the answer is DNSsec. > With mDNS, DNSsec also probably can work.) > > Surely there is some alternative approach that > doesn't require such overloading and complexity. > Well, let's see. You have an ISP that hands you a DNS server using DHCPv6. You're also connected to a walled garden that hands you a global but partitioned IPv6 address that can only reach the walled garden, and gives you its own DNS server. You want things to work more than one hop away. How would you implement this? --e89a8ff25610b9f91104cceb79a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 1:08 AM, RJ Atkinson <rja.lists@gmail.com&g= t; wrote:
I'm not comfortable with overloading a routing
protocol for use as a DNS transport mechanism.

Sorry, I didn't mean "routing protocol". I meant &quo= t;Homenet DNS Information Distribution Protocol" (HIDP). I would expec= t a useful way to carry HIDP would be using the homenet routing protocol wh= ich the homenet needs to implement anyway, but other implementations such a= s global IPv6 multicast, its very own DHCPv6 option, SMTP between homenet d= evices, or carrier pigeon are possible and encouraged. After all, this is t= he IETF: there's always more than one way of doing things, and at least= one of them is always a DHCPv6 option.

But seriously: why are you not comfortable with this id= ea?=A0We need a routing protocol for the homenet anyway.=A0A link-state rou= ting protocol can carry multiple TLVs, including TLVs for DNS servers. Rout= ing protocols can be authenticated. The devices that need to propagage DNS = are likely going to be home routers. Why not use the routing protocol?
=A0
I'm also nervous about bot= h DNS authorisation
and DNS authentication. =A0Who is allowed to make
which DNS advertisements and how do I authenticate
the received DNS advertisement as both valid and
authorised ?

I don't see a differen= ce. There is no authorization or authentication today. When you get a DNS s= erver via DHCP, you believe it, or choose not to believe it, based on no in= formation at all. If there's a rogue DHCP server on the link that hands= you a rogue DNS server, then guess what, you lose. The only thing that wou= ld change here is that you would use HIDP to distribute that information mo= re than one hop away. Whatever mechanism that you want to use to authorize = and authenticate DNS servers can be used regardless of whether you learn th= em via HIDP or via DHCP.
=A0
=A0 (NB: With ordinary DNS, th= e answer is DNSsec.
=A0 =A0With mDNS, DNSsec also probably can work.)

Surely there is some alternative approach that
doesn't require such overloading and complexity.
<= br>
Well, let's see. You have an ISP that hands you a DNS ser= ver using DHCPv6. You're also connected to a walled garden that hands y= ou a global but partitioned IPv6 address that can only reach the walled gar= den, and gives you its own DNS server. You want things to work more than on= e hop away. How would you implement this?
--e89a8ff25610b9f91104cceb79a7-- From lorenzo@google.com Thu Oct 25 17:34:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827B21F84C0 for ; Thu, 25 Oct 2012 17:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.896 X-Spam-Level: X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujh3cW41zUIb for ; Thu, 25 Oct 2012 17:34:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D23DF21F848F for ; Thu, 25 Oct 2012 17:34:37 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2440174obq.31 for ; Thu, 25 Oct 2012 17:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=osPhji/5M4IpVSvoCWogXNRzkhzSAMdMxvv5CA/ZVWU=; b=VlDQwFYFe7Qkv02k8pdQ8u0a7I8iPSCAD/1k70dI6kxonzKYJqHmJ3+gzEkZtENyhX S+jxmfwjR0ndA3aqvnEnVcgASipys68G2+AG/0NQaLcBlAhrHLywbmhfyEbyD++PGCx9 6v034TspXEZs3IugZAAh/x8iM6XO9hb/W3LjqbMBFhntovrKeKV0UA9GNGokTJ8fv1IU SXx6buxqpBWTYKk4HnCQetoXZAQk1U1riG/9tCK/eTVG2SR4x9UCV4+DSx80zfc8kQiT Rjd/MulCSgyQ/rAQjcPLhV/ZfBKV+KE85yf9aFu2znDCvC0DAh6RDJSa53OodV7CM44w HqCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=osPhji/5M4IpVSvoCWogXNRzkhzSAMdMxvv5CA/ZVWU=; b=bJWhJGOv1GQdKDo/nNQ+4B4RNELfbCHtXmQuPtvFXXqXGgsjszL13kilFWATTsEajQ YRZNlmjb2RlhyV5vJqphght7KnPiJphiB76Oh4cIG3RZlOvSyNYsL4FTW69dHf7nM3qc l1fLz5GEiLoVv9t8AUW8SY0g1+vBlmT8gWrRoIcm6u/tgHuKeup2NwftDWo4GaCRpENV tMVwhhdFH2n/Fx9/YFB7qTcx47LG1V2x/0yyR8JJml8kKDBMkKEtkgtUMVeWFOgkIeao cbdRYPktbtDzBryxNXQfFFBpJiH0HPQ6UcUjDr6Tf3y4FKkXgBBnDWW7J00EZTWFuTj+ 3OjQ== Received: by 10.182.150.37 with SMTP id uf5mr17245423obb.10.1351211677427; Thu, 25 Oct 2012 17:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Thu, 25 Oct 2012 17:34:17 -0700 (PDT) In-Reply-To: <13C65695-2D64-4987-B744-17C2A6F685A9@steffann.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <13C65695-2D64-4987-B744-17C2A6F685A9@steffann.nl> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 09:34:17 +0900 Message-ID: To: Sander Steffann Content-Type: multipart/alternative; boundary=bcaec51f95550ca90f04cceb7c35 X-System-Of-Record: true X-Gm-Message-State: ALoCoQka9B7ZvexiHH/pJOSUnExR/pGuOdBzq/FIRZOCKsmrayOk5ragorw+/LgSlxQkJzkbXONdAlBTeCiRgxiZIgDFwSSiY2Qk5reh+JR+ksMcD3Xmno7w2c9xS6QR4fE9Gfvkvoi6pxOp3g1mCRLZZH8ZKg8Unza5S/iidaomM/ra/lyLXF47Vjchn6eYQdDNRvOty/nT Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:34:38 -0000 --bcaec51f95550ca90f04cceb7c35 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 2:32 AM, Sander Steffann wrote: > Yes. The routing protocol saying 'please use this address to resolve > google.com' might cause some problems... With DNSSEC in place it can > still cause a denial of service when unsigned or invalidly signed data is > returned. > No more than a DHCPv6 server saying "please use this DNS server for everything". Right? --bcaec51f95550ca90f04cceb7c35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 2:32 AM, Sander Steffann <sander@steffann.nl&= gt; wrote:
Yes. The routing protocol saying 'please use this add= ress to resolve google.com<= /a>' might cause some problems... With DNSSEC in place it can still cau= se a denial of service when unsigned or invalidly signed data is returned.<= /div>

--bcaec51f95550ca90f04cceb7c35-- From teco@inf-net.nl Thu Oct 25 23:24:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F08021F8630 for ; Thu, 25 Oct 2012 23:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R0ttm8FpLnA for ; Thu, 25 Oct 2012 23:24:50 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C17F021F8427 for ; Thu, 25 Oct 2012 23:24:47 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1008103eek.31 for ; Thu, 25 Oct 2012 23:24:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ny+VDWq+OxBZZSiDtCmYNydyiKZcHv/v5kllIFPQyzs=; b=J94h1S0J85ThuP4QKqYsBRjgUTIkh3qz5s4kFgBRYiroFixTl7oHUsOfiitDi/DkSN 44la5eT5vEaX0QVoKzELjjKPoe6JnbPD2JCvF5y5MxVTLRwadLSJi/a57F/rsgkOCzDI +PPECuhAIoVd/fk+Mf0MPQeiSk6PTt1ZyPNjooUlHG3JuiFC72amPqoZDyVOtywbmFZ1 sEkEhSfEzmE6gF74pJI/EWO17BUSpyaLt+eEE+L3F0YJXoYcNqrOZbqHkrb3zmoDkW2i PB1vvA/xHwXrCxafZEbk4QwQ0BHo02t7lrxKxPrEN2LoFUvivCdBYhrMp4La1T3SXsi4 0ZHA== Received: by 10.14.203.65 with SMTP id e41mr30005450eeo.34.1351232687154; Thu, 25 Oct 2012 23:24:47 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id o47sm782943eem.11.2012.10.25.23.24.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 23:24:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D70CA41-D9B5-4CD1-8C19-512D9BA605AC" From: Teco Boot In-Reply-To: Date: Fri, 26 Oct 2012 08:24:44 +0200 Message-Id: <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnf8PdDYgc1xylCICEH1LDC52/LXe2AgEanMG8ji2PkYVphu2CrU6lzkUEGllraqF7qOjoz Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 06:24:51 -0000 --Apple-Mail=_3D70CA41-D9B5-4CD1-8C19-512D9BA605AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Op 26 okt. 2012, om 02:33 heeft Lorenzo Colitti het volgende geschreven: > On Fri, Oct 26, 2012 at 1:08 AM, RJ Atkinson = wrote: > I'm not comfortable with overloading a routing > protocol for use as a DNS transport mechanism. >=20 > Sorry, I didn't mean "routing protocol". I meant "Homenet DNS = Information Distribution Protocol" (HIDP). I would expect a useful way = to carry HIDP would be using the homenet routing protocol which the = homenet needs to implement anyway, but other implementations such as = global IPv6 multicast, its very own DHCPv6 option, SMTP between homenet = devices, or carrier pigeon are possible and encouraged. After all, this = is the IETF: there's always more than one way of doing things, and at = least one of them is always a DHCPv6 option. >=20 > But seriously: why are you not comfortable with this idea? We need a = routing protocol for the homenet anyway. A link-state routing protocol = can carry multiple TLVs, including TLVs for DNS servers. Routing = protocols can be authenticated. The devices that need to propagage DNS = are likely going to be home routers. Why not use the routing protocol? Because we need this info in all nodes. I'm not sure we shall have = interactions between hosts and the routing protocol. > =20 > I'm also nervous about both DNS authorisation > and DNS authentication. Who is allowed to make > which DNS advertisements and how do I authenticate > the received DNS advertisement as both valid and > authorised ? >=20 > I don't see a difference. There is no authorization or authentication = today. When you get a DNS server via DHCP, you believe it, or choose not = to believe it, based on no information at all. If there's a rogue DHCP = server on the link that hands you a rogue DNS server, then guess what, = you lose. The only thing that would change here is that you would use = HIDP to distribute that information more than one hop away. Whatever = mechanism that you want to use to authorize and authenticate DNS servers = can be used regardless of whether you learn them via HIDP or via DHCP. > =20 > (NB: With ordinary DNS, the answer is DNSsec. > With mDNS, DNSsec also probably can work.) >=20 > Surely there is some alternative approach that > doesn't require such overloading and complexity. >=20 > Well, let's see. You have an ISP that hands you a DNS server using = DHCPv6. You're also connected to a walled garden that hands you a global = but partitioned IPv6 address that can only reach the walled garden, and = gives you its own DNS server. You want things to work more than one hop = away. How would you implement this? BRDP. Teco. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_3D70CA41-D9B5-4CD1-8C19-512D9BA605AC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Op 26 okt. 2012, om 02:33 heeft Lorenzo Colitti het volgende geschreven:

On Fri, Oct 26, 2012 at 1:08 AM, RJ Atkinson <rja.lists@gmail.com> wrote:
I'm not comfortable with overloading a routing
protocol for use as a DNS transport mechanism.

Sorry, I didn't mean "routing protocol". I meant "Homenet DNS Information Distribution Protocol" (HIDP). I would expect a useful way to carry HIDP would be using the homenet routing protocol which the homenet needs to implement anyway, but other implementations such as global IPv6 multicast, its very own DHCPv6 option, SMTP between homenet devices, or carrier pigeon are possible and encouraged. After all, this is the IETF: there's always more than one way of doing things, and at least one of them is always a DHCPv6 option.

But seriously: why are you not comfortable with this idea? We need a routing protocol for the homenet anyway. A link-state routing protocol can carry multiple TLVs, including TLVs for DNS servers. Routing protocols can be authenticated. The devices that need to propagage DNS are likely going to be home routers. Why not use the routing protocol?
Because we need this info in all nodes. I'm not sure we shall have interactions between hosts and the routing protocol.

 
I'm also nervous about both DNS authorisation
and DNS authentication.  Who is allowed to make
which DNS advertisements and how do I authenticate
the received DNS advertisement as both valid and
authorised ?

I don't see a difference. There is no authorization or authentication today. When you get a DNS server via DHCP, you believe it, or choose not to believe it, based on no information at all. If there's a rogue DHCP server on the link that hands you a rogue DNS server, then guess what, you lose. The only thing that would change here is that you would use HIDP to distribute that information more than one hop away. Whatever mechanism that you want to use to authorize and authenticate DNS servers can be used regardless of whether you learn them via HIDP or via DHCP.
 
  (NB: With ordinary DNS, the answer is DNSsec.
   With mDNS, DNSsec also probably can work.)

Surely there is some alternative approach that
doesn't require such overloading and complexity.

Well, let's see. You have an ISP that hands you a DNS server using DHCPv6. You're also connected to a walled garden that hands you a global but partitioned IPv6 address that can only reach the walled garden, and gives you its own DNS server. You want things to work more than one hop away. How would you implement this?
BRDP.

Teco.

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

--Apple-Mail=_3D70CA41-D9B5-4CD1-8C19-512D9BA605AC-- From n@arifumi.net Thu Oct 25 23:37:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F821F8608 for ; Thu, 25 Oct 2012 23:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKcF-dBuX43J for ; Thu, 25 Oct 2012 23:37:26 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D243721F85AF for ; Thu, 25 Oct 2012 23:37:25 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2961268vbb.31 for ; Thu, 25 Oct 2012 23:37:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=upMZGKWIgeX7Ma9pKEGIQtsoMX3PhWPM7QN07KeUTc4=; b=RiBC67j23efzRemy8FsxDth9am7gg5AKpc4aIMCpr7SDCrf5ib8kuiURqIiJZu+a+6 eeyDyslNaLApNBQG8Tj6LGS1kewB+UEkPYtOvzCuYX8uN8ATILnFW0Yn1tNXhbl6u6Pu X1APdnMHE1I8lzr6eLAtFo5rYVuTyjZfVQQt/J0yq0u55dpPCtPSxWhbhc3DMJqT/rMQ 9shSC8sKcudJBFesRRurQeiHFOfDCCqWGFgUSwNPauLNX+MfcdfqW/X3+uB2G4hBMiNd SYzvUz+3lHXCn0ok5Hvrp/UvcIWc0iyLohxOQPX4w5UGwS+OENoRmUfkpraBFXoqvv9I p2KQ== MIME-Version: 1.0 Received: by 10.52.66.36 with SMTP id c4mr28843744vdt.6.1351233445165; Thu, 25 Oct 2012 23:37:25 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Thu, 25 Oct 2012 23:37:25 -0700 (PDT) X-Originating-IP: [222.147.76.182] In-Reply-To: <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> Date: Fri, 26 Oct 2012 15:37:25 +0900 X-Google-Sender-Auth: nLDvQ8z0qJRLBJlbzPov--DAA3Q Message-ID: From: Arifumi Matsumoto To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmsi3GZaGcuLTiZ5npFYwH1+JFqeP6fG3/evHcy04fUEdCNX4f3OKCIEyzHn1XEKE4/QqgJ Cc: homenet@ietf.org, RJ Atkinson , Lorenzo Colitti Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 06:37:26 -0000 Hi, a DHCPv6 option to deliver such kind of information, that is, relation between DNS domain names and DNS servers, is almost baked. https://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12 Thanks. 2012/10/26 Teco Boot : > > Op 26 okt. 2012, om 02:33 heeft Lorenzo Colitti het volgende geschreven: > > On Fri, Oct 26, 2012 at 1:08 AM, RJ Atkinson wrote: >> >> I'm not comfortable with overloading a routing >> protocol for use as a DNS transport mechanism. > > > Sorry, I didn't mean "routing protocol". I meant "Homenet DNS Information > Distribution Protocol" (HIDP). I would expect a useful way to carry HIDP > would be using the homenet routing protocol which the homenet needs to > implement anyway, but other implementations such as global IPv6 multicast, > its very own DHCPv6 option, SMTP between homenet devices, or carrier pigeon > are possible and encouraged. After all, this is the IETF: there's always > more than one way of doing things, and at least one of them is always a > DHCPv6 option. > > But seriously: why are you not comfortable with this idea? We need a routing > protocol for the homenet anyway. A link-state routing protocol can carry > multiple TLVs, including TLVs for DNS servers. Routing protocols can be > authenticated. The devices that need to propagage DNS are likely going to be > home routers. Why not use the routing protocol? > > Because we need this info in all nodes. I'm not sure we shall have > interactions between hosts and the routing protocol. > > >> >> I'm also nervous about both DNS authorisation >> and DNS authentication. Who is allowed to make >> which DNS advertisements and how do I authenticate >> the received DNS advertisement as both valid and >> authorised ? > > > I don't see a difference. There is no authorization or authentication today. > When you get a DNS server via DHCP, you believe it, or choose not to believe > it, based on no information at all. If there's a rogue DHCP server on the > link that hands you a rogue DNS server, then guess what, you lose. The only > thing that would change here is that you would use HIDP to distribute that > information more than one hop away. Whatever mechanism that you want to use > to authorize and authenticate DNS servers can be used regardless of whether > you learn them via HIDP or via DHCP. > >> >> (NB: With ordinary DNS, the answer is DNSsec. >> With mDNS, DNSsec also probably can work.) >> >> Surely there is some alternative approach that >> doesn't require such overloading and complexity. > > > Well, let's see. You have an ISP that hands you a DNS server using DHCPv6. > You're also connected to a walled garden that hands you a global but > partitioned IPv6 address that can only reach the walled garden, and gives > you its own DNS server. You want things to work more than one hop away. How > would you implement this? > > BRDP. > > Teco. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From lorenzo@google.com Thu Oct 25 23:44:39 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5157C21F8449 for ; Thu, 25 Oct 2012 23:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq8duQbKUDsY for ; Thu, 25 Oct 2012 23:44:38 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 327E321F8462 for ; Thu, 25 Oct 2012 23:44:38 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so8523iak.31 for ; Thu, 25 Oct 2012 23:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=xBthhjBkKcsE35SpG2+oiUoDq88rY2Bqr8bhRQ9r8ns=; b=jBF/pj0KZIaloXC5I9D8g94Dn6el04ydogFwIG1BwG7miPM+MtdXPjX2VxYaI3dsbd 2AFIfO8oohE7fm2CZX3V+Z1hvEPs3KIqHwK4SS8T5NdfUslKyE4OfubkDjE7lo7d9mqZ PICgnbttPIsWTTkUmrdAypd6Rk3ItkmQsSgWQuPlz6bF44uDVPVvQLcP+HY37JoXnr8i h8RWDhBHG/cULIXmyYcXjGS+FXBOFtPO6ctr64r88c49V3uHO2oeVqFgCLMYOdV7FhOL IgnTePCNPfCmfonb8S5G51MeGH8lHS0P76HRm/RikunWdJYusRBCzZoBAAJZxK9kmZFs S6Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=xBthhjBkKcsE35SpG2+oiUoDq88rY2Bqr8bhRQ9r8ns=; b=PkVw1JN6TjToPOXgGeT2xK3269RlrdCAwfrbZWPjVIbaGqKxSrN+BsdwymQCJcN9F1 fawel2O8mF7jkqHX7E2upzgSiuAT0ey1geciPFbLRh7e3kL74LaDa12ovIQhFSxWKpxG BTT/db2oCUlfY4v3caXdJNjHqWfwPQdUaihxzxdRrJujYnx1/DapEK88x9Di8bP/if9h Y08V7fUIzaBm96/uVJcBHRn4xG+Rcca7tX/Xg8rEUi8FMqFQJitxCUaVphV1kRmQcI/u EgTnrgEhQAAWqlb4xsUF54HDwFjYJ/iHPWU5h/WWyEEZ9EsrwfRUxMyicEFbs7P+7RJ4 WVDw== Received: by 10.50.57.169 with SMTP id j9mr1171604igq.16.1351233877397; Thu, 25 Oct 2012 23:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.23.137 with HTTP; Thu, 25 Oct 2012 23:44:16 -0700 (PDT) In-Reply-To: <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 15:44:16 +0900 Message-ID: To: Teco Boot Content-Type: multipart/alternative; boundary=14dae93410754550fe04ccf0a7aa X-System-Of-Record: true X-Gm-Message-State: ALoCoQnYuhMxCOLWtFg6be77d719mzDyNWGbfWiMSDv98NVC37IH8RUVS1NK1QH77LHQGqWnZsePRfVw0l2wKHJqwAgPYyiZrCDl9SanplbyIC/4wT0ckplVtCmb5N4KIowQI47pShoXKx2il1bMXv2h0p7RNrN7qmRkJYVmsx2H1UTXYGR15po/Qgr6Fr1AsXDcMcufyTHk Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 06:44:39 -0000 --14dae93410754550fe04ccf0a7aa Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 3:24 PM, Teco Boot wrote: > But seriously: why are you not comfortable with this idea? We need a > routing protocol for the homenet anyway. A link-state routing protocol can > carry multiple TLVs, including TLVs for DNS servers. Routing protocols can > be authenticated. The devices that need to propagage DNS are likely going > to be home routers. Why not use the routing protocol? > > Because we need this info in all nodes. I'm not sure we shall have > interactions between hosts and the routing protocol. > You don't need to. You can have interactions between hosts and routers. > Well, let's see. You have an ISP that hands you a DNS server using DHCPv6. > You're also connected to a walled garden that hands you a global but > partitioned IPv6 address that can only reach the walled garden, and gives > you its own DNS server. You want things to work more than one hop away. How > would you implement this? > > BRDP. > The question was not how to make routing work in such a setup, the question was how do you make DNS work such that the walled-garden DNS server (which could return REFUSED for anything not in the walled garden, like NTT's does) is used only for that zone. --14dae93410754550fe04ccf0a7aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 3:24 PM, Teco Boot <teco@inf-net.nl> w= rote:
But seriously: why are you not co= mfortable with this idea?=A0We need a routing protocol for the homenet anyw= ay.=A0A link-state routing protocol can carry multiple TLVs, including TLVs= for DNS servers. Routing protocols can be authenticated. The devices that = need to propagage DNS are likely going to be home routers. Why not use the = routing protocol?
Because we need this info in all nodes. I'= ;m not sure we shall have interactions between hosts and the routing protoc= ol.

You don't need to= . You can have interactions between hosts and routers.
We= ll, let's see. You have an ISP that hands you a DNS server using DHCPv6= . You're also connected to a walled garden that hands you a global but = partitioned IPv6 address that can only reach the walled garden, and gives y= ou its own DNS server. You want things to work more than one hop away. How = would you implement this?
BRDP.

=
The question was not how to make routing work in such a setup, t= he question was how do you make DNS work such that the walled-garden DNS se= rver (which could return REFUSED for anything not in the walled garden, lik= e NTT's does) is used only for that zone.
--14dae93410754550fe04ccf0a7aa-- From lorenzo@google.com Thu Oct 25 23:46:12 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770BE21F8449 for ; Thu, 25 Oct 2012 23:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkFtSA3He7R1 for ; Thu, 25 Oct 2012 23:46:12 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14E9621F85F4 for ; Thu, 25 Oct 2012 23:46:07 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so9303iak.31 for ; Thu, 25 Oct 2012 23:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7YZXOXo3S99TMR7BxprqEXg1KLjQwVNUJblcXUrqUQM=; b=APoIbu9xxa2V384omt8EVgF0MOnYwiUyJ29W3dPcZ6o2bi/p60vJcNgv5C+EaQ0QDg wtmaK2XTW3yE7ZhRTVbYCUBb00A/qDaqUfZ4AffUxLNJA9PGx42vNeBv4aezj0dTgCTG 6ntuVCpWkLaEmOXL/Rvcd+TW5rG53rSzDs/zIFJRuVHdonv7RwQBwNIFj2k5J1jn1ObH GEzxb0HnXh9Khtr6cmdosy4Yf3O/8fNtSBaN8OsN7Dl44j6t9Q+ViFO0hKyerD5IZNpR ZHXB14+/XNurYraO/bnZV5xvrDxqGlbLUpWZiI0EC45iU1NW97DCCiWWS5n3mWulB7Xf cNVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7YZXOXo3S99TMR7BxprqEXg1KLjQwVNUJblcXUrqUQM=; b=BZ5MwQhCUwecYtDKKiGIocQZhTOK5cKpReET+849pboEy5iFavqpV+Pm5rtKsPqaMj E8Rp5tJ7Up5ArBa1JWifSswAGMmaqElEeLaDef2vzGiDWiRumtR4VJvRwzHlTzmzdO6N LyNdCD12RSLPLVZBlFkGn9U98uKrmP4dFPt8DDzLLAeub9LYkrHinrbrF7mWAcJVj2hI CryUby0nu75UpAUvvbA2wc/A4glEdFbDRVsQYNpKJvoAKQqnVAgQgyespHCgTulnR5hI x/6kb/cxFBwrX4Fu8EdVynAPeRYJ7QqghhYSvAagaX/P/znq7zGXPbXcfLQA6GLEc+/a f7rw== Received: by 10.50.188.168 with SMTP id gb8mr1216734igc.4.1351233966694; Thu, 25 Oct 2012 23:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.23.137 with HTTP; Thu, 25 Oct 2012 23:45:46 -0700 (PDT) In-Reply-To: References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 15:45:46 +0900 Message-ID: To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=14dae9340ce597e02c04ccf0ac4a X-System-Of-Record: true X-Gm-Message-State: ALoCoQlpmrlWy4RKFRDwBZxVEctpR+z/fs44ZNv75NAoNJ50ghaj51n5d359+/+YYITJQvOUhiD2OMA2CerRhh9gXoJDozSPjD39EBeLQRzei/pHST5vN+xxx3QOBB93/lpk02MY83VcGIyonuY2sFcqyz3fCzO/NyQPwuJiSbG41dVe1le3hpqL7Cqo+k2RbYnAn7Ku2Y4g Cc: homenet@ietf.org, Teco Boot , RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 06:46:12 -0000 --14dae9340ce597e02c04ccf0ac4a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 3:37 PM, Arifumi Matsumoto wrote: > a DHCPv6 option to deliver such kind of information, that is, relation > between DNS domain names and DNS servers, is almost baked. > https://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12 Sure, but you still need to propagate that information to all the homenet routers and DHCPv6 servers. In the general case, your host won't be adjacent to that DHCPv6 server with this information, or it may be using another DHCPv6 server instead. --14dae9340ce597e02c04ccf0ac4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 3:37 PM, Arifumi Matsumoto <arifumi@nttv6.net&= gt; wrote:
a DHCPv6 option to deliver such kind of information, that is, relation
between DNS domain names and DNS servers, is almost baked.
https://tools.ietf.org/html/draft-ietf-mif-dns-server= -selection-12

Sure, but you still need = to propagate that information to all the homenet routers and DHCPv6 servers= . In the general case, your host won't be adjacent to that DHCPv6 serve= r with this information, or it may be using another DHCPv6 server instead.<= /div>
--14dae9340ce597e02c04ccf0ac4a-- From teco@inf-net.nl Fri Oct 26 00:29:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A0A21F8451 for ; Fri, 26 Oct 2012 00:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7LGLbqAtx8f for ; Fri, 26 Oct 2012 00:29:58 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9833E21F8450 for ; Fri, 26 Oct 2012 00:29:57 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1030700eek.31 for ; Fri, 26 Oct 2012 00:29:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IwH0NyTdq6PT10q0/Jvuy3ERc6QyJboDQfjpttxrwdM=; b=XVj/+cpi7DXaWlZkec0hCfvGzEmW9MoTOcHi1RG6sqHwnqwG2LEoEaEZYD3q969hoU st4aufnI9KBdIvMBTCE7AmJS4VHxEIcng6q9f3tFam9O87VjaAYYErXs0MVJ7agzSpbg ZS/IpRsyqAYU0ek93jhoANT8bQupcYtuSV3Z++D87OLHFA6L569MGK4UBn1RTfw5tjC9 14oSyAU8PRzJuzAXUZGOfV+1CWqpv58L5zuIIjNxd6RgPM3qeaMWooeW7Tskg2l0n0TZ pUcAg6fqjqwqLH5XbKOHRSnTW5+AbY+vAMsydFuF5u6K6FWwtRGbWMg1RmBAg2xkBWmU rqgg== Received: by 10.14.172.137 with SMTP id t9mr30291377eel.2.1351236596613; Fri, 26 Oct 2012 00:29:56 -0700 (PDT) Received: from [10.175.173.38] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id f3sm1036612eeo.13.2012.10.26.00.29.53 (version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 00:29:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <50896915.6080404@mtcc.com> Date: Fri, 26 Oct 2012 09:29:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <994FBBCB-0844-4182-927B-6ED5A7B19986@inf-net.nl> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <0435F886-1E8B-4302-832F-C9D0269981A4@apple! .com> <50896915.6080404@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnZGreuTfZD+9Nb8dV8TgxW94OePv3dqOjrUo1S8pV6sqRFMHaTyfuTnpIuzHtnDvenvKhq Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:29:59 -0000 Op 25 okt. 2012, om 18:30 heeft Michael Thomas het volgende geschreven: > On 10/23/2012 11:01 AM, james woodyatt wrote: >> On Oct 23, 2012, at 08:20 , Michael Thomas wrote: >>> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: >>>> Can you explain why this behaviour, combined with the "prefer = matching interface" rule in RFC 3484, is not sufficient? If not, then = there is no problem to solve here. >>> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you = 2000::, >>> but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. = Your >>> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity = ensues: >> My IPv6 stack doesn't pick a 2001:xxxx:... address. When the VPN = client connects, it inserts a more-specific host route to 2001:yyyy::/z = via the VPN pseudo-interface, so the IPv6 stack picks the interface = address assigned by the VPN access concentrator as the source address = for application flows to the 2001:yyyy:/z network. >>=20 >> Hilarity does not ensue. Happy faces on the security team. >>=20 >>=20 >=20 > As I alluded to in my previous note, this doesn't work unless the vpn = is > terminated in host devices. When it's router-router, it fails as I = mentioned > because the hosts are clueless. I expect that walled off overlay = networks > will be more rather than less prevalent in v6, especially when = homenets > are truly visible -- though access controlled -- from the outside = which is > pretty untrue today with v4/nat. More thoughts on this scenario. Assume the company has many branch=20 offices (e.g. 1000 small sites, with 2001:xxxx::/48 from ISP),=20 where main office has 2000::/48. Each branch office is equipped as=20 a homenet, the gear is cheap and just acts as the requirements. It provides Internet access and VPN to main office and indirect to all=20 other branches. Branch office managers set up their homenet equivalent=20= to the branch offices. This doubles the number of VPN tunnels.=20 For Internet access, nodes on branch offices / homenet configure a=20 2001:xxxx:0:mmmm::/64 address. Main office nodes configure = 2000:0:0:nnnn::/64.=20 We better not send 2000 routes during VPN tunnel setup, for access to main office and each branch office / homenet. We better configure a 2nd=20= address on nodes in the branch offices / homenets, for connectivity=20 to nodes in main office or branch office / homenet. VPN tunnel provides a 2000:0:0:zzz0::/60 prefix to each branch office / homenet and nodes configure an additional 2000:0:0:zzzz::/64 address for=20= access via VPN. Routing shall forward packets with destination inside the site based on destination address. For packets outside, routing shall use the = source address. Source addresses in 2001:xxxx::/48 are send to ISP,=20 source addresses in 2000:0:0:zzz0/60 are send via VPN tunnel. IGP / VPN servers in main office may have to handle a bench of prefixes,=20= prefix handling on tunnels is kept low. On source address selection, nodes prefer a 2000:0:0:zzzz::/64 for destinations within the company, 2001:xxxx:0:mmmm::/64 for elsewhere. Is this the model we have in mind? How can source address selection pick the 2001:xxxx:0:mmmm::/64 address = for a destination out of 2000::/16, but not 2000::/48? This is a MIF = problem. Use RFC 6724 policy table Label? Supersede Rule 8? Now, company acquires another and 2001:yyyy::/48 is connected to the = main office. Branch offices / homenets wants to connect to a 2001:yyyy::/48 address = via=20 the VPN. I see multiple options: a) circumvent problems: first renumber acquired company to 2000::/48 b) push a 2001:yyyy::/48 route on VPN tunnels c) add another VPN prefix on all branch offices / homenets for = 2001:yyyy::/48 Option a is the preferred solution, let's pass this to 6renum. Homenet = protocols may help. Option b makes branch office / homenet IGP more complicated due to route=20= redistribution, source address selection and ingress filtering. Option c makes VPN stack more complicated, due to assignment of multiple=20= prefixes. NPT66 & happy eyeballs could help. But IMHO these are hacks. Opinions? Teco >=20 > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From lorenzo@google.com Fri Oct 26 00:33:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F42921F842E for ; Fri, 26 Oct 2012 00:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuuNrBYrVWiX for ; Fri, 26 Oct 2012 00:33:35 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6174821F841A for ; Fri, 26 Oct 2012 00:33:35 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3835588iec.31 for ; Fri, 26 Oct 2012 00:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=+DzIMa0vBSA6pwZdlpkKbAzm16EFxZv+MktM+WyYmzs=; b=dXwL5//3FWAor58lDyIzrIIYEt+IVn38dJk6YRSGsUiiUIrAHeujOHjsUWL9Ms1Sgu NhXYZF11FgfOm3ePHUbvDdvIwt8zaLtd2v/7rz0kX+d76cbAUyu8x6Q1xkZ0OMs/v0JK l3tAJ5k8X85xKGe49gYLF8P604mvY7fTEjgReJycxF2KudGI3RdQe4tH7zdONSS2y5CE dQigWp98El2SOOk3pTBj9Cwe2hSGz9qTyBkZq0/RqCYTK7UHDeGztPQaygkQ4CT3nmlE Y9qe2iLyvSMjKUnPaagNrXIsShJt+8x//tOHIITWNoTrnvSayJYEXxRCRWIwdZjujL+5 x7wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=+DzIMa0vBSA6pwZdlpkKbAzm16EFxZv+MktM+WyYmzs=; b=n0kGMIS7GxKBuly8mihMUQW933egX234lUX+LubWNiio6DCXdBGBkX1h2cSvF4sryz l4k3USVHLeD/mpbXkuYzBEQL9aCYL8Q42i8fYPtYo39raB+ilUpCwq0dpz5dQHzmwswg 2PupLNkl9oZPpc6vXkuk7+uFuQzfAL3urQrfByG1jJIhjmbgnAn1K3kGFMdR0sD660zX KmX9Y95AhHNm+Rp5VGVAILoJh+3bvVmMFX+bv983xAzsvi74WQYZQ8iJ54T16Y46V1Tk vRN1oi1NqpXinjBwUO4I3tdrxpQHmYpfKjgVOBhm0HSjyQzsjNC8fSIbNUszC2WRbS6w +qzQ== Received: by 10.50.222.226 with SMTP id qp2mr1176244igc.74.1351236814946; Fri, 26 Oct 2012 00:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.23.137 with HTTP; Fri, 26 Oct 2012 00:33:14 -0700 (PDT) In-Reply-To: <31084.1351174835@sandelman.ca> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <506A07D1.8050605@gmail.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <24641.1351011789@obiwan.sandelman.ca> <30501.1351120800@sandelman.ca> <31084.1351174835@sandelman.ca> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 16:33:14 +0900 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=14dae934089d5cc2ee04ccf1565a X-System-Of-Record: true X-Gm-Message-State: ALoCoQm/0ajGXhaTlObgRW7oEdUFBlmtZCjgkgIk3lK0qHAdEsa1LelkuK9HOsZaKAeF5KahKilhC3RFgk3QCPJ+j7+iQFOmleyPB+p9MPVEU0wKYp+K/ihLitzivdCJQctNEzJb9I/GyHsUr9ZumeYN2zcQGV46sN19EEMfNJJTRv+mdnjfB7pnHs7f9rxmxSOKJA6gG/zk Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:33:36 -0000 --14dae934089d5cc2ee04ccf1565a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 11:20 PM, Michael Richardson wrote: > LC> Solution: from the border router which discovered the DNS entries > for > LC> tvservice.jp, inject those DNS servers into the mesh with a tag > that they > LC> only be used for tvservice.jp, and pass that around in the routing > LC> protocol. No? > > While it's reasonable for my TV settop-box to pay attention to that > extension, why would my laptop or browser know about it? > Except that evidence from real deployments (e.g., NTT) is that the operator's DNS servers are handed out to all boxes on the network. So if you plug your laptop into the walled garden, that's what you get. > This really seems invasive to multiple layers of the stack, and I think > it is completely unnecessary. Zone delegations solve the problem using > existing protocols and existing software. And yet. --14dae934089d5cc2ee04ccf1565a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 11:20 PM, Michael Richardson <= mcr+ietf@sandelm= an.ca> wrote:
=A0 =A0 LC> Solution: from the border router which dis= covered the DNS entries for
=A0 =A0 LC> tvservice.= jp, inject those DNS servers into the mesh with a tag that they
=A0 =A0 LC> only be used for tvservice.jp, and pass that around in the routing
=A0 =A0 LC> protocol. No?

While it's reasonable for my TV settop-box to pay attention to that
extension, why would my laptop or browser know about it?

Except that evidence from real deployments (e.g., NTT) is= that the operator's DNS servers are handed out to all boxes on the net= work. So if you plug your laptop into the walled garden, that's what yo= u get.
=A0
This really seems invasive to = multiple layers of the stack, and I think
it is completely unnecessary. =A0Zone delegations solve the problem using existing protocols and existing software.

A= nd yet.
--14dae934089d5cc2ee04ccf1565a-- From teco@inf-net.nl Fri Oct 26 00:37:30 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1521F8451 for ; Fri, 26 Oct 2012 00:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hpe62vUnomM for ; Fri, 26 Oct 2012 00:37:29 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2665821F8450 for ; Fri, 26 Oct 2012 00:37:29 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1033676eek.31 for ; Fri, 26 Oct 2012 00:37:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=1+adDUL5OnK97dFCgYOhIMnBmwtxdOw2MCrSOgBkS/Q=; b=GaFSOXEj5kGJ3sdXV4XgXeFqKwlYvgUjOBJolbucVx8ORtevP+zqcEQeCY7phgR3aP INeu9XVH5HW7Kwp+wGf7XlVyMQOyE3ZnY1oOmbpCFJAffM8QNw4IKbQVIyxTiUsGyPvD nE0FKgiiBaxlzP0iTQm+eCrz1tnFEatAbh0oBCnnz+ccWa9rfylrJeslabjTjO6Wgi+M R0H5owS1Bs1rZ5pvjCppjriqYuTG8ULsU3XMJe2dDmktJOKIHvu4LVbVbA1433HWfY8g wnblVFB/A1ybYeb62PbYVeIXzrERvjab9xv0meR4UrroVBbEJCSnCRrj8wB9syHAf+r6 LNGA== Received: by 10.14.214.2 with SMTP id b2mr30165634eep.32.1351237048326; Fri, 26 Oct 2012 00:37:28 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id f3sm1066681eeo.13.2012.10.26.00.37.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 00:37:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_CAB794D2-ACC0-460A-9027-F12A7B580C02" From: Teco Boot In-Reply-To: Date: Fri, 26 Oct 2012 09:37:26 +0200 Message-Id: <8DB04CA5-3A1A-49B3-9E58-4C588CB797B1@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQloTWni4pUU+vX8fXIcfN/EEtp9rzkSiX/Q+wrsJSDE/yQuJyr355CodZHQnRdwuPImyVfI Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:37:30 -0000 --Apple-Mail=_CAB794D2-ACC0-460A-9027-F12A7B580C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Op 26 okt. 2012, om 08:44 heeft Lorenzo Colitti het volgende geschreven: > On Fri, Oct 26, 2012 at 3:24 PM, Teco Boot wrote: >> But seriously: why are you not comfortable with this idea? We need a = routing protocol for the homenet anyway. A link-state routing protocol = can carry multiple TLVs, including TLVs for DNS servers. Routing = protocols can be authenticated. The devices that need to propagage DNS = are likely going to be home routers. Why not use the routing protocol? >=20 > Because we need this info in all nodes. I'm not sure we shall have = interactions between hosts and the routing protocol. >=20 > You don't need to. You can have interactions between hosts and = routers. >> Well, let's see. You have an ISP that hands you a DNS server using = DHCPv6. You're also connected to a walled garden that hands you a global = but partitioned IPv6 address that can only reach the walled garden, and = gives you its own DNS server. You want things to work more than one hop = away. How would you implement this? >=20 > BRDP. >=20 > The question was not how to make routing work in such a setup, the = question was how do you make DNS work such that the walled-garden DNS = server (which could return REFUSED for anything not in the walled = garden, like NTT's does) is used only for that zone. BRDP provides pointers to DHCP server for each provisioning domain, = where servers may be multiple hops away. Hosts get addresses (DHCP or = SLAAC) and then can get the additional info with unicasted DHCP for each = address, using the MIF extensions. Maybe we have to tweak DHCP a little = to support this. Teco= --Apple-Mail=_CAB794D2-ACC0-460A-9027-F12A7B580C02 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Op 26 okt. 2012, om 08:44 heeft Lorenzo Colitti het volgende geschreven:

On Fri, Oct 26, 2012 at 3:24 PM, Teco Boot <teco@inf-net.nl> wrote:
But seriously: why are you not comfortable with this idea? We need a routing protocol for the homenet anyway. A link-state routing protocol can carry multiple TLVs, including TLVs for DNS servers. Routing protocols can be authenticated. The devices that need to propagage DNS are likely going to be home routers. Why not use the routing protocol?
Because we need this info in all nodes. I'm not sure we shall have interactions between hosts and the routing protocol.

You don't need to. You can have interactions between hosts and routers.
Well, let's see. You have an ISP that hands you a DNS server using DHCPv6. You're also connected to a walled garden that hands you a global but partitioned IPv6 address that can only reach the walled garden, and gives you its own DNS server. You want things to work more than one hop away. How would you implement this?
BRDP.

The question was not how to make routing work in such a setup, the question was how do you make DNS work such that the walled-garden DNS server (which could return REFUSED for anything not in the walled garden, like NTT's does) is used only for that zone.

BRDP provides pointers to DHCP server for each provisioning domain, where servers may be multiple hops away. Hosts get addresses (DHCP or SLAAC) and then can get the additional info with unicasted DHCP for each address, using the MIF extensions. Maybe we have to tweak DHCP a little to support this.

Teco
--Apple-Mail=_CAB794D2-ACC0-460A-9027-F12A7B580C02-- From lorenzo@google.com Fri Oct 26 00:39:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454F221F8447 for ; Fri, 26 Oct 2012 00:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftc9PowDYK5K for ; Fri, 26 Oct 2012 00:39:07 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 882C921F845A for ; Fri, 26 Oct 2012 00:39:07 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2692608oag.31 for ; Fri, 26 Oct 2012 00:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=5H52b53sT7yhvPolMEJwKEROr16yVDrxl+7atKfQGnI=; b=NgIc9zF/7zCKHSvRoiaEOfXfFNJYAA1sWbDAemf6MwNRXB/wNbdl2LmZ6kUJrGEws0 jX5m7UZpGoFSlfglCvyMqSSFm6O0kUVcKjDGPmguYDspCgBQ6R/iNJ7/9Xl/XcYwISZl ERUHqXAMhN0eNI+/nYXzXaWsgNNrnaksd3BZn/4EpMp1wyGA/goVO/jzpBs6oha957wg lnZTVGAZNt6+xd5DeAXf6/gxgj7HDDKGaxE0KGZp8kr3ODtho4qVIRrvZBnN7nCHKeVa i4IR68iczzjCkBT00al/J6wtCfZCAI2E6n7V0i2FJFD2JhkgBGk2ZUfHUqy+9CcILkGn SKvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=5H52b53sT7yhvPolMEJwKEROr16yVDrxl+7atKfQGnI=; b=S/9n4U0TK1W8gTXgKfdzG0mHs4p8IzbJc9WFQRBUnDAjfcwCaX626/5AlyrmjRPrR6 K4XiEOEbDLJesEl3zqfg8DB7cRvKiqJ1Ptp5bMxADBxNwSr4KDoKob3Gltx9Rdcv8jY/ ZpF1+LR5RCnhhoD3Qq8LSWmQtoYDM5FCjWNTv+bMid+8giCZsT+1GGNuSJl4D/EQtvX8 iwCMlcNl13P2YLmjbciiaa+pFcoT0p89duilHST4kkFsk+VmeLgjq4yjoI4opSM8MFQp kM1v/qWnoOLk5lceuShrveI7oJxrcnPNvjSeLeXdJRAr+M+ThiWAaTWnYw9vN/SLRp5H RqiQ== Received: by 10.60.14.165 with SMTP id q5mr19401379oec.28.1351237147130; Fri, 26 Oct 2012 00:39:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Fri, 26 Oct 2012 00:38:45 -0700 (PDT) In-Reply-To: <8DB04CA5-3A1A-49B3-9E58-4C588CB797B1@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> <8DB04CA5-3A1A-49B3-9E58-4C588CB797B1@inf-net.nl> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 16:38:45 +0900 Message-ID: To: Teco Boot Content-Type: multipart/alternative; boundary=e89a8fb1f46829796404ccf16ac3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQleJ3elLKiw4G4aYyCu91+CfqRu8o+xbIN+2vNuX8s8nLDjUwIf2yg3N/xM6Mk6yiaz78ak2cU74HySPAzaQo4XvCHhT/fCX6B587ETk6rjyBqEsHP/qsq7zv8T/QyKo6BpMy8nd3nk6IsSd7jVAKYZ8goQ9yuO4PooY1mhyTpUD1D+Fka/0cdtjf2N/dI6d/SCH3N+ Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:39:08 -0000 --e89a8fb1f46829796404ccf16ac3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 4:37 PM, Teco Boot wrote: > Hosts get addresses (DHCP or SLAAC) and then can get the additional info > with unicasted DHCP for each address, using the MIF extensions. Maybe we > have to tweak DHCP a little to support this. > Just "maybe" ? :) --e89a8fb1f46829796404ccf16ac3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 4:37 PM, Teco Boot <teco@inf-net.nl> w= rote:
Hosts get addresses (DHCP or SLAAC) and= then can get the additional info with unicasted DHCP for each address, usi= ng the MIF extensions. Maybe we have to tweak DHCP a little to support this= .

Just "maybe" ? :)
--e89a8fb1f46829796404ccf16ac3-- From teco@inf-net.nl Fri Oct 26 00:40:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784EF21F8476 for ; Fri, 26 Oct 2012 00:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAaGUsgqtSNz for ; Fri, 26 Oct 2012 00:40:04 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87021F8467 for ; Fri, 26 Oct 2012 00:40:03 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so851449eaa.31 for ; Fri, 26 Oct 2012 00:40:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=1nCOIh0v32d57eig6oq5zZx1ihzRV0BtcGqx598YdDI=; b=kkEinjAie3t1zK3g6EGgBZveNS3OkOLsi0h4wHYaLsF4glm066uVpWc5Et+eCto+p5 vIBxdqdeRIWjgH5NWqZ7sRUiLPeaDmPdCRgS2U7XFuPZyGg5qvQI2nhAkvnPAMRx1NVr ERupJvikqfBXQYw44omR8LP3+sDsFcPjMzh8ssOE7Ely61dbyhweBQjE+Bk7RyepWEaz ij7TZLRvfAxxeXd2HH10qVkGhRfkjxQ5rIUqdfqzXOwvo4pefGHWe1fL4kvW4/X59hjV mxW4KJp1adVp51p5nU8nhucp2yTLa5DKhuKVPGqE3e8i2hs+jowCW6frhjgvvXI/sdBq OCMA== Received: by 10.14.194.71 with SMTP id l47mr29738263een.6.1351237202719; Fri, 26 Oct 2012 00:40:02 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id e7sm1102132eep.1.2012.10.26.00.40.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 00:40:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_31369F65-63A0-4798-BF5A-70C3919D12D0" From: Teco Boot In-Reply-To: Date: Fri, 26 Oct 2012 09:39:59 +0200 Message-Id: References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQke1Z6YdyyAp3BdESrgo1frj3RKDCEHHQgjehirG4ai7IiSLuhOp4nwJQEp0fT/719iGKt9 Cc: homenet@ietf.org, RJ Atkinson , Arifumi Matsumoto Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:40:04 -0000 --Apple-Mail=_31369F65-63A0-4798-BF5A-70C3919D12D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Op 26 okt. 2012, om 08:45 heeft Lorenzo Colitti het volgende geschreven: > On Fri, Oct 26, 2012 at 3:37 PM, Arifumi Matsumoto = wrote: > a DHCPv6 option to deliver such kind of information, that is, relation > between DNS domain names and DNS servers, is almost baked. > https://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12 >=20 > Sure, but you still need to propagate that information to all the = homenet routers and DHCPv6 servers. In the general case, your host won't = be adjacent to that DHCPv6 server with this information, or it may be = using another DHCPv6 server instead. No, BRDP and MIF-stack solves this. All routers in Homenet forward the Border Router (which is also DHCP = server or relay). DHCP info is never merged, nodes get the info one by one, for each = provisioning domain. Teco= --Apple-Mail=_31369F65-63A0-4798-BF5A-70C3919D12D0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Op 26 okt. 2012, om 08:45 heeft Lorenzo Colitti het volgende geschreven:

On Fri, Oct 26, 2012 at 3:37 PM, Arifumi Matsumoto <arifumi@nttv6.net> wrote:
a DHCPv6 option to deliver such kind of information, that is, relation
between DNS domain names and DNS servers, is almost baked.
https://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12

Sure, but you still need to propagate that information to all the homenet routers and DHCPv6 servers. In the general case, your host won't be adjacent to that DHCPv6 server with this information, or it may be using another DHCPv6 server instead.
No, BRDP and MIF-stack solves this.
All routers in Homenet forward the Border Router (which is also DHCP server or relay).
DHCP info is never merged, nodes get the info one by one, for each provisioning domain.

Teco
--Apple-Mail=_31369F65-63A0-4798-BF5A-70C3919D12D0-- From lorenzo@google.com Fri Oct 26 00:47:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F5521F84AD for ; Fri, 26 Oct 2012 00:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szkUGUlRYmXx for ; Fri, 26 Oct 2012 00:47:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71DFE21F84A4 for ; Fri, 26 Oct 2012 00:47:32 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2658764obq.31 for ; Fri, 26 Oct 2012 00:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=qK66rw2rETrRvS0CSbk6xJXWOCfRUnQFI/LVQmgmQKU=; b=Ujq+mbSET6kugvr/Y6pIVu/4NF26oZTDXXin1culzvNVtd0ZdjpADEG3ad+jRwUP09 UCDW7r9HpDkMV0s/1tJh46jYUCVi83SiRDWUk2uesha8NWFC0BDoCURQzecwhTXaW0I/ Hpdv5MTMmKCAATna4/Nz+eRWxFggWmz7MoXrw5OckwgzMKtEFmQL73CyAoFy9m0+89oc Zxt1n1JEgF/QEepr83sP2DE+EjE0lLbMGsaSg9TGJ1uUlPcwkYNnNsRa8HOzmfPQFFZG 0j/iR3tJGk+bfv7lnNeTLZ1VVMCwi/fobSiTJ1PAp3mowxRVvMHk21kD0V/o+A5U16qb ZXKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=qK66rw2rETrRvS0CSbk6xJXWOCfRUnQFI/LVQmgmQKU=; b=DR6BnRBeqZR2Qoi8pTAECzZls2Dyaj2WiM0pCaG1+Ix83Np6bUq+Yt3eQNyaIa08Sc /fArFYXfuHRxG8LBdz/g21p/P7d0Mq+rxFU2QJefBE069pUDrLenRHgovgtV2jF3QP4O k6Jpdvug9hWRJYd2BzHQbJ8XNoqOo1QXq5/qbzcWE1DupxKOVNqLGUmJhN3F//vCC62+ anq+pvfRB5vAKEmvb3XE/EWgHUdir0KtrOtArCNwHUWTFMc6+e3HFMnx/T2k3vHpjj9g /FOkn8rwmYHwv9+YfFqQuS9Tyk2bJxSmPAwGPfzGsMtPNPzbIOZ+a8n5iliLDT8R/eKc Kbdg== Received: by 10.182.221.97 with SMTP id qd1mr17387333obc.6.1351237652041; Fri, 26 Oct 2012 00:47:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Fri, 26 Oct 2012 00:47:11 -0700 (PDT) In-Reply-To: References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 16:47:11 +0900 Message-ID: To: Teco Boot Content-Type: multipart/alternative; boundary=f46d0446325c41d13604ccf18852 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn1+GhvaUdopgPAhANcFfwd0y6YuufZn8vA9B2J/fZretTzR/lupfqQ+b7GOFC3eX42KArYY8SBfNv6M69y7kWjwj/KhMVbaGdupwpiISL5jwJDWkLlBQ0H6iFDNtfPHQvnXg+M8FFsR8JbXKtztkWrmeWcC0u+EFbYx4Yh7dhTOkxSVp1K4koq7CLBCiNFJOAaEqrv Cc: homenet@ietf.org, RJ Atkinson , Arifumi Matsumoto Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:47:36 -0000 --f46d0446325c41d13604ccf18852 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 4:39 PM, Teco Boot wrote: > Sure, but you still need to propagate that information to all the homenet > routers and DHCPv6 servers. In the general case, your host won't be > adjacent to that DHCPv6 server with this information, or it may be using > another DHCPv6 server instead. > > No, BRDP and MIF-stack solves this. > All routers in Homenet forward the Border Router (which is also DHCP > server or relay). > DHCP info is never merged, nodes get the info one by one, for each > provisioning domain. > Ok, but then you need to change the hosts to implement the MIF stack? --f46d0446325c41d13604ccf18852 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 4:39 PM, Teco Boot <teco@inf-net.nl> w= rote:
Sure, but you still need to propagate tha= t information to all the homenet routers and DHCPv6 servers. In the general= case, your host won't be adjacent to that DHCPv6 server with this info= rmation, or it may be using another DHCPv6 server instead.
No, BRDP and MIF-stack solves thi= s.
All routers in Homenet forward the Border Router (which is als= o DHCP server or relay).
DHCP info is never merged, nodes get the= info one by one, for each provisioning domain.

Ok, but then you need to change the = hosts to implement the MIF stack?
--f46d0446325c41d13604ccf18852-- From teco@inf-net.nl Fri Oct 26 00:50:17 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5CA21F84D5 for ; Fri, 26 Oct 2012 00:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkag8TlixmCq for ; Fri, 26 Oct 2012 00:50:16 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C05621F84A9 for ; Fri, 26 Oct 2012 00:50:16 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so854880eaa.31 for ; Fri, 26 Oct 2012 00:50:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=iJUuB17h8X9l3ZhV6zB5mFA/VuWqLMU2kfDjZnvuYQs=; b=YAT5ULifx8q2ISWphI3Sk+/psA9ht4lGXlmljlxCh5pDRZxecGsY5ZZATvgbEjQtCI mpNY5ws1+ujh6ZCf+olsfr09DtzrDXmrKUlX1rKR0IkOaxDmoWsNHGKZBlrTMotPbfMt nqZeUFpFzo+Q3/ySrGb5v3SA/JnlQlpfxkPQbgGOwH+bbLmURU8X43UjeXeO2CzHEjpd wi+FnyHjRx6ZdHrZD//VwFo8VXmiSPAC2se+ZHMx7dOFpePEb1oZDc80u9j0566uo2p5 RN9hhF0scnPQeQUaK4aWT3waPMvf4UtCcRWyBsmugNqpfq5q4i6j/C1OF6fSg3uShYGI LQ0Q== Received: by 10.14.173.195 with SMTP id v43mr29620985eel.39.1351237815708; Fri, 26 Oct 2012 00:50:15 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id g47sm1131718eeo.6.2012.10.26.00.50.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 00:50:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1A185C5-A0C4-4B1D-8D65-157208E203C2" From: Teco Boot In-Reply-To: Date: Fri, 26 Oct 2012 09:50:13 +0200 Message-Id: <788C7E82-54FB-43FB-AF3A-3E0739D8BE41@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> <8DB04CA5-3A1A-49B3-9E58-4C588CB797B1@inf-net.nl> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl/H/782kaK5s1n6WRLcV0m8K8eLj+vuHwmlnTQ1wzzqpTowAMbwJ8+/E6c/SHkcbp2NmE6 Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:50:17 -0000 --Apple-Mail=_D1A185C5-A0C4-4B1D-8D65-157208E203C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Op 26 okt. 2012, om 09:38 heeft Lorenzo Colitti het volgende geschreven: > On Fri, Oct 26, 2012 at 4:37 PM, Teco Boot wrote: > Hosts get addresses (DHCP or SLAAC) and then can get the additional = info with unicasted DHCP for each address, using the MIF extensions. = Maybe we have to tweak DHCP a little to support this. >=20 > Just "maybe" ? :) We have to do something, OK? Better just tweak than do it all over = again. The question is, does DHCP support the following: The MIF node has = configured a bench of addresses with SLAAC. Now it learns that there is = a DHCP server somewhere that has important info for the provision domain = for one of the addresses. Can the node get this info, with the already = configured address for that provisioning domain, with a unicast? Nodes = will be updated anyway for MIF, so let's go for it. Far better than = merging info from multiple provisioning domains into a single DHCP = server. Not? Teco --Apple-Mail=_D1A185C5-A0C4-4B1D-8D65-157208E203C2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Op 26 okt. 2012, om 09:38 heeft Lorenzo Colitti het volgende geschreven:

On Fri, Oct 26, 2012 at 4:37 PM, Teco Boot <teco@inf-net.nl> wrote:
Hosts get addresses (DHCP or SLAAC) and then can get the additional info with unicasted DHCP for each address, using the MIF extensions. Maybe we have to tweak DHCP a little to support this.

Just "maybe" ? :)

We have to do something, OK? Better just tweak than do it all over again.

The question is, does DHCP support the following: The MIF node has configured a bench of addresses with SLAAC. Now it learns that there is a DHCP server somewhere that has important info for the provision domain for one of the addresses. Can the node get this info, with the already configured address for that provisioning domain, with a unicast? Nodes will be updated anyway for MIF, so let's go for it. Far better than merging info from multiple provisioning domains into a single DHCP server. Not?

Teco

--Apple-Mail=_D1A185C5-A0C4-4B1D-8D65-157208E203C2-- From teco@inf-net.nl Fri Oct 26 00:55:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EB421F8468 for ; Fri, 26 Oct 2012 00:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zky4Q6s+E-kA for ; Fri, 26 Oct 2012 00:55:39 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 298EB21F845C for ; Fri, 26 Oct 2012 00:55:38 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1040686eek.31 for ; Fri, 26 Oct 2012 00:55:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=b+NH8I/b0C8caipGuTlo+Qnw7K+w8tBuJfNIYPwerAU=; b=iTqGcYpcVZIdG+4761UMLmH4fhaJzi4o6Lj11LNvgwSuJTf5EWU5sYguMN9oEYxV3F ZIsHrAE7y6sEx2rGrKqcJE6NDIspg2B0O0KJPAMgj8Y2R1zSy21/jRF9cexaDQWA4uQY 0A1qj4n9SLrsfJV4uphGQ74RBSLX/javTpaIAv3ZnA6UMaXmk3SV9Hsn0WCt4jaa4pTR sciWVGiyt/YoTjr16+65Sh3Wj97RDww9AaL3/yMaer82FIEZkfri0xVZROH4YKaYp7XX nSTsDBTKIPYs8LXbVYHjC+KyZDO+8WcJN4T6JtFgrC+lz2vlUTbFtAdJo+eR2ntVKWWL cWjg== Received: by 10.14.203.3 with SMTP id e3mr16640288eeo.35.1351238138156; Fri, 26 Oct 2012 00:55:38 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id o47sm1143212eem.11.2012.10.26.00.55.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 00:55:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F2F0F92-3B09-485E-AFE4-A02DC8668A98" From: Teco Boot In-Reply-To: Date: Fri, 26 Oct 2012 09:55:36 +0200 Message-Id: References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQntN2xxeDjXuhpeXsVx+YmEdIxB7FT1Og22RL58YMuq4c5Sd/5PyUG7y1ctPydTLripNXij Cc: homenet@ietf.org, RJ Atkinson , Arifumi Matsumoto Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:55:40 -0000 --Apple-Mail=_4F2F0F92-3B09-485E-AFE4-A02DC8668A98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Op 26 okt. 2012, om 09:47 heeft Lorenzo Colitti het volgende geschreven: > On Fri, Oct 26, 2012 at 4:39 PM, Teco Boot wrote: >> Sure, but you still need to propagate that information to all the = homenet routers and DHCPv6 servers. In the general case, your host won't = be adjacent to that DHCPv6 server with this information, or it may be = using another DHCPv6 server instead. >=20 > No, BRDP and MIF-stack solves this. > All routers in Homenet forward the Border Router (which is also DHCP = server or relay). > DHCP info is never merged, nodes get the info one by one, for each = provisioning domain. >=20 > Ok, but then you need to change the hosts to implement the MIF stack? I suggest we kindly ask MIF WG to take care. It is in their scope to = better support multihoming. Then, we can focus on home network gear and = the protocols to get needed info to all nodes, including the MIF hosts. Teco= --Apple-Mail=_4F2F0F92-3B09-485E-AFE4-A02DC8668A98 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Op 26 okt. 2012, om 09:47 heeft Lorenzo Colitti het volgende geschreven:

On Fri, Oct 26, 2012 at 4:39 PM, Teco Boot <teco@inf-net.nl> wrote:
Sure, but you still need to propagate that information to all the homenet routers and DHCPv6 servers. In the general case, your host won't be adjacent to that DHCPv6 server with this information, or it may be using another DHCPv6 server instead.
No, BRDP and MIF-stack solves this.
All routers in Homenet forward the Border Router (which is also DHCP server or relay).
DHCP info is never merged, nodes get the info one by one, for each provisioning domain.

Ok, but then you need to change the hosts to implement the MIF stack?

I suggest we kindly ask MIF WG to take care. It is in their scope to better support multihoming. Then, we can focus on home network gear and the protocols to get needed info to all nodes, including the MIF hosts.

Teco
--Apple-Mail=_4F2F0F92-3B09-485E-AFE4-A02DC8668A98-- From lorenzo@google.com Fri Oct 26 01:05:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABAA21F841D for ; Fri, 26 Oct 2012 01:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Kow6nJ2yok for ; Fri, 26 Oct 2012 01:05:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 285CB21F841C for ; Fri, 26 Oct 2012 01:05:40 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2671446obq.31 for ; Fri, 26 Oct 2012 01:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=BKd2y4v6nC1Un9Xk7qk+wCN1JSatsL1NDNEcn31D3j4=; b=AGcsDeMpa0oV+3i5+9NIu9CKPja5QqWWonBSU5i7bG8jGWcQxTPnjl2kppXGODw3XK ZcXrrgmKM6OQobm7ZKAa24hkfMEgxn2vetsVaaXL6UiCM4MMbqNI8CXiORBw32/US2dH PAAmAKZ7oaQS9/Q63+sSRaZOXa33HlXDjO9Q4Y286TECJ+XhJnRnvninjrQI+Tfw5N8F bOxLwATFHQXUxgWoebSzF1gZgMGzIyw0/wH0rI2DHN3BzMPbhmN3xCATK7kCwbkmnoIZ XW3JrRp4B6bD2u+u8iB8d2rHrLMuw9YqIGydqcISWn6M87WV76W4TdXDUXAgk3aDAkDF FknA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=BKd2y4v6nC1Un9Xk7qk+wCN1JSatsL1NDNEcn31D3j4=; b=lug/bDLtJ9qayLmzocpTnW0Ee9rMXYJECVU3A0ZjEWi7Y0q/jr2v8sfoMttKUuCnOg 0WyO3mL9+UvStE1fWZKtXajH8rnm7ilcaSAK6zgZ9VIBl4zjlweml7WwNvGX6mAEgaos CDqb3Lpk8OhcnAwD6Qg2UTkt4Gs1DVALY+5eKMZbCgT1iSUO9xSqC4yEHRSt4TKx/04A Ukz8e42Ya95+mDsYf/MdO+eCyyw1ttFli6ZrtjSkjF7/8ORdVpZzQcxWDZJWNhS/NNSG iftS0vYDX8iGma7YAv5+JdwOUCvnqj24unHO2imN7FvnMbom6FwnwhOXJ4SiHOMZdHUf 7OKA== Received: by 10.182.221.97 with SMTP id qd1mr17413154obc.6.1351238739741; Fri, 26 Oct 2012 01:05:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Fri, 26 Oct 2012 01:05:19 -0700 (PDT) In-Reply-To: <788C7E82-54FB-43FB-AF3A-3E0739D8BE41@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> <8DB04CA5-3A1A-49B3-9E58-4C588CB797B1@inf-net.nl> <788C7E82-54FB-43FB-AF3A-3E0739D8BE41@inf-net.nl> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 17:05:19 +0900 Message-ID: To: Teco Boot Content-Type: multipart/mixed; boundary=f46d0446325c16cda404ccf1c9d8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkSLSr2wpwT64x59grMDwdW6tUBMHEGJZw5jisBQfit5iNW7vYIfXdMSndi086YEfW1KvzR1tHx77TJV1REBMflDFvP64x+GJ1H2gUYl6Eii7kper2/+Si56kb2hi8TtX0Ynn0tRfn8Rm1Ww7EC6p+r1C5EwDA9uXP+y2tOelhAglWuOxZA55jV16xWns/HDNTgjWQV Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:05:41 -0000 --f46d0446325c16cda404ccf1c9d8 Content-Type: multipart/alternative; boundary=f46d0446325c16cd9504ccf1c9d6 --f46d0446325c16cd9504ccf1c9d6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 4:50 PM, Teco Boot wrote: > The question is, does DHCP support the following: The MIF node has > configured a bench of addresses with SLAAC. Now it learns that there is a > DHCP server somewhere that has important info for the provision domain for > one of the addresses. Can the node get this info, with the already > configured address for that provisioning domain, with a unicast? Nodes will > be updated anyway for MIF, so let's go for it. Far better than merging info > from multiple provisioning domains into a single DHCP server. Not? > Can we get by without a DHCPv6 server at all? DHCPv6 servers are stateful and DHCPv6 is a protocol based on promises that are valid for a predetermined amount of time. In a homenet, DHCPv6 servers (i.e., CPE routers) may be plugged in and unplugged any time, and there is no way to invalidate their information, which means the hosts are stuck. Using a routing protocol and not using DHCPv6 solves this issue, because a router is allowed to deprecate a prefix that has gone away even if it was originally announced by someone else, and NUD will let hosts work around broken routers in a reasonable amount of time. --f46d0446325c16cd9504ccf1c9d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 4:50 PM, Teco Boot <teco@inf-net.nl> w= rote:
The question is, does DHCP support= the following: The MIF node has configured a bench of addresses with SLAAC= . Now it learns that there is a DHCP server somewhere that has important in= fo for the provision domain for one of the addresses. Can the node get this= info, with the already configured address for that provisioning domain, wi= th a unicast? Nodes will be updated anyway for MIF, so let's go for it.= Far better than merging info from multiple provisioning domains into a sin= gle DHCP server. Not?

Can we get by without a DHCPv6 serve= r at all?

DHCPv6 servers are stateful and DHCPv6 i= s a protocol based on promises that are valid for a predetermined amount of= time. In a homenet, DHCPv6 servers (i.e., CPE routers) may be plugged in a= nd unplugged any time, and there is no way to invalidate their information,= which means the hosts are stuck.

Using a routing protocol and not using DHCPv6 solves th= is issue, because a router is allowed to deprecate a prefix that has gone a= way even if it was originally announced by someone else, and NUD will let h= osts work around broken routers in a reasonable amount of time.
--f46d0446325c16cd9504ccf1c9d6-- --f46d0446325c16cda404ccf1c9d8 Content-Type: application/pdf; name="Homenetstrawman.pdf" Content-Disposition: attachment; filename="Homenetstrawman.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h8r0aupx0 JVBERi0xLjQKJSDi48/TCjQKMApvYmoKPDwKL1R5cGUKL0NhdGFsb2cKL05hbWVzCjw8Ci9KYXZh U2NyaXB0CjMKMApSCj4+Ci9QYWdlTGFiZWxzCjw8Ci9OdW1zClsKMAo8PAovUwovRAovU3QKMQo+ PgpdCj4+Ci9PdXRsaW5lcwoyCjAKUgovUGFnZXMKMQowClIKPj4KZW5kb2JqCjUKMApvYmoKPDwK L0NyZWF0b3IKKP7/AEcAbwBvAGcAbABlKQo+PgplbmRvYmoKNgowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjcKMApS Ci9SZXNvdXJjZXMKOAowClIKL0Fubm90cwoxMAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVu Y3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjcKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVE ZWNvZGUKL0xlbmd0aAo5CjAKUgo+PgpzdHJlYW0KeJydkNtKw0AQhgdyNw8ietHNng+XihZRQbds jAheiNIGSatR3x9nt4TaYkFlycz/s7OT+WZAwTjmM1kLoznlpyUOSIKLYL3hulTseirKaYnKGmd5 ed5vjHRaySx63DE5dtjiin5SH/dv3SPHxUeZZPzeF//q3eEcI3UdUPkRbKMK1WhyngjNnNSaB5Qi MCO8ViNWmeEkYT19XX0KtJrq03x7XVIxI4V0KLRnVhnqk9av0zMegoEZ3EELVxDhAio4hQamcEm+ hXNSLd02pCq4Jd3Q/T3cUIxHmF7wLBFK3I8S/0LqJAXNHQsheF8YmdA0sOdmj/yGL1HJH/AVN7Q+ ayxqyZz1zmzh14Sf8SI8kKrggOJ1gaeV/Boxny880HkrCmVuZHN0cmVhbQplbmRvYmoKOQowCm9i agoyODgKZW5kb2JqCjEwCjAKb2JqClsKXQplbmRvYmoKMTQKMApvYmoKPDwKL1R5cGUKL1BhZ2UK L1BhcmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjU0MApdCi9Db250ZW50cwoxNQowClIK L1Jlc291cmNlcwoxNgowClIKL0Fubm90cwoxOAowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVu Y3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjE1CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRl RGVjb2RlCi9MZW5ndGgKMTcKMApSCj4+CnN0cmVhbQp4nJ1QywrCMBDMeb5EBdukefaoqFepBD2L 0hZpq1X/H5OUUCx4kSWZGbI7u5seLKHwsRyIFNThpUUPRyjLlZFUhIypdkkeWnAltaKhvBlFpgXP PGkwEf6ucULnmqSr5lGfKapXmCSeZ/WXd40ShXPtwU1cbGRhqyg86sx7sTyRzAgeFwrd1xbp7t69 GZRwSbb8/ijuiqg2LAMTJlFc0hx2KLdXzMiCHMiG7MlxDnvD1rqpit9TDY9FiA/opElzCmVuZHN0 cmVhbQplbmRvYmoKMTcKMApvYmoKMTkwCmVuZG9iagoxOAowCm9iagpbCl0KZW5kb2JqCjE5CjAK b2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAK XQovQ29udGVudHMKMjAKMApSCi9SZXNvdXJjZXMKMjEKMApSCi9Bbm5vdHMKMjMKMApSCi9Hcm91 cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagoyMAowCm9i ago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjIyCjAKUgo+PgpzdHJlYW0KeJytVFFP wjAQPsPb/Q5jNNHRbu3WPmoAiRBxZDI1ezEaIAZQ1Ed/hj/Yu85BwJmwhVy6uybtd9/3td0SpSeQ 4ywvtBKUn+a4RCqEtKHRQrkV23NaxGmOQaijULjts/XEj1TgczHDrQl/p5jigpo0z2dv00eBkw/H pBjvk1rYUxxjTKhLDEwhbF05VcWEszKMZTwTBIHRhSDX/SLBZud18SnzRcl40yjLw3q+xiTflDzj MRzBEGKKLnQghT7c00ghy04wecF2QtTi/6nFlZnL0HiilLWP7hi3WbNSa5RCLT1fmmiD/cF3QXNX OB3xpwQKJBnRgB59R2RAg+zoQYuMuSJrRrXa2Ohvm6pAK/lS2b3pL8X6NUDCIUSUWXqWwQO50IVb 6NZrZPUeLfBViaE1LSjFIukDiiGpHrkbMIQbijuyok+zlnsg/Fwa0CZXUlrXpYidXbxzfX+q35hw JdPSEyFqakPmV1VAKTTrLAOD7JjeeU48P2CuTiGEgPKARMZw7Sxo8dFTvnSmxDv/FDh+ABHgA+oK ZW5kc3RyZWFtCmVuZG9iagoyMgowCm9iago0MDQKZW5kb2JqCjIzCjAKb2JqClsKXQplbmRvYmoK MjQKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIw CjU0MApdCi9Db250ZW50cwoyNQowClIKL1Jlc291cmNlcwoyNgowClIKL0Fubm90cwoyOAowClIK L0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjI1 CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKMjcKMApSCj4+CnN0cmVhbQp4 nK1Uy07cQBCcaG/9HTmEQ8zY8/CYWyL2kVUUsLExoL1EiWAVLSSb5JjPyAdT3cYgOybCCxrNu11T VTPtLcWRJi5vm4GzGv2Xa9oSBjrOfHDaSkR/jiDursl4l3otn28eJklqTcKDDfUm3K6pphscsv9u 82P9WdPVL2HS1p9XO2Gv6ZJyoG7JhFbYw0hUtRPubWCsEAVjTHCtIDn9fUn7s+83v+MmqLzsGpVx zaLEUdl8VH6lN8qpQp2pWn1UuVruUfmNpiX45I/zyUfTjX2I9CDVhOTu+lRZXhasJRdHSRzSDuVX f1uaT4VzKTcDUOq1aC/UsToUD2ZqglrAiw+YLbFb3e1gbfSxvpURazOg489YwFg7aQfAoGSOUqmF OkVB+wy2zkb6xdgOganVHixlshew9wjlf3RN8jh6lkSp76GPJcqJkRjIj503HZoeD+AEpQDXGk/j EP0UzGt5FpVarbDI74dDjlCX2OQbmEg+zbB2hluR3MIaR3Ds6LsRhiGLUjC0z5F6n1gGien7enfM rEEs8a5S5xB/Dksa8adiTYHkYi/zxr/q7g+0wGiCrUL6+21OvmNBOJEQTsX5bjwz+y/PnR201r+Y g4NY6kCs+CSeca4s5c3N4eSi42TXwKk8slp2ORqrT/6tc7kFMJZSTAplbmRzdHJlYW0KZW5kb2Jq CjI3CjAKb2JqCjQ5NwplbmRvYmoKMjgKMApvYmoKWwpdCmVuZG9iagoyOQowCm9iago8PAovVHlw ZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRz CjMwCjAKUgovUmVzb3VyY2VzCjMxCjAKUgovQW5ub3RzCjMzCjAKUgovR3JvdXAKPDwKL1MKL1Ry YW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKMzAKMApvYmoKPDwKL0ZpbHRl cgovRmxhdGVEZWNvZGUKL0xlbmd0aAozMgowClIKPj4Kc3RyZWFtCnicrVRNU9swEF0mt/0lcKjR h2XLvbUTQkqZJk4MTttcOjCQYQI0bY/9Gfzgvl3jMgS3QzIZj6zdlfS072mlFdvEsHxvGiOkBv3F La8YhrFFFoNJdca6j0nS3bLPQp4ZXb58clyeeifGktcc+S+45jtscvhu+X3xzfD1T82kbT+ut8Je 8BWXQF2xjy2xJ0tZtY70aRSsmETvfQwtId39fcWHg/u7X7aZVF09F6qQViQucNUsqi55n+b79JVq GtIZldSnEfVoQBPYJWIDjJzSZ7Sa5vMDrm74qEK25b+zLTcmY7OYmE4ijvVk14kI+SKmKQebOBvz Z4T2Hto0XwsXcvl1QFFGM5rim0CcGsKM4Y9Ukin6ISIztU4h1ic6h9+HdYxeIidYNURU4h8QGT3K rGNbJVnkL5PcFOiveDYtdqZeJ9YL+dbFqukjBJORKWZMtM6OVdYp4mcqdFORMjpTfxvpspayM10F 8/s/gN51AFoT5A52gdFbzViKQ8rgRHkIpxKe3KiavqgeUGDLbX2R4EHbURG4AsM2ZG4HRdCJRQGk +zjuiT4vR4/35hxCNEcsRdHTox3Lbdl0Z3nUfOo6Nu69+rmS7w8SLSEmCmVuZHN0cmVhbQplbmRv YmoKMzIKMApvYmoKNDU4CmVuZG9iagozMwowCm9iagpbCl0KZW5kb2JqCjM0CjAKb2JqCjw8Ci9U eXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29udGVu dHMKMzUKMApSCi9SZXNvdXJjZXMKMzYKMApSCi9Bbm5vdHMKMzgKMApSCi9Hcm91cAo8PAovUwov VHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iagozNQowCm9iago8PAovRmls dGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjM3CjAKUgo+PgpzdHJlYW0KeJydUMsKwjAQzHm+RA+2 eTc9Klg8CFKMehalLdJWq/4/JimlWPAiy+7OkNlXOrCIwtuiB0pSly8NOjhAWaqNojIoptyJfGog tEo0DeX1SHgiBfegxoT4WOGE1g2Jl/WjOlOUr7DJ4M/yr94VCuSuawdhhsNGFK4aiM8J971YGilm pBgOCtNXFnF2b98MWjqRLb4/iisVUamNAZMm0kLRFLYvt1fMiCAHsiU5yVzckx3ZkOMc9oa1dfvl v/frH/NgH8aXSwwKZW5kc3RyZWFtCmVuZG9iagozNwowCm9iagoxOTcKZW5kb2JqCjM4CjAKb2Jq ClsKXQplbmRvYmoKMzkKMApvYmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAKUgovTWVkaWFC b3gKWwowCjAKNzIwCjU0MApdCi9Db250ZW50cwo0MAowClIKL1Jlc291cmNlcwo0MQowClIKL0Fu bm90cwo0MwowClIKL0dyb3VwCjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZpY2VSR0IKPj4K Pj4KZW5kb2JqCjQwCjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKNDIKMApS Cj4+CnN0cmVhbQp4nK1U32/TMBA+FO3lQEJ75B3xQ4M0ie3EfgRtbbVW2zLSZKC+INBWoW6jgz+F P5jP12ZjnYe2qIpi312c7777fPaC0zhh/7xfGkYnmL+d84JhJKnLrUm0rFj3schP56xyU+SJ/D6/ cbJCq8wbc15z/Djjhi+QpPdh/nP2NeGzX8Kkfa/OOmHP+JRLoC5Y2bawG0uqah0/a+uxbGyVUta0 BUn2jxX3+pcXv9Plour0tlDOvy7ODFfLn6rv/IYUTWhMJfUxfqJDGlL9lqsfvFeBVXk/q/LRpNPc xkmQcMayg+uEfZHOas0mjbPUFreIP/nT0nwonCn8EICiDPUPKYIGx7C83acG4wAx7zX0BV8mdEDP ETlerS5pl45Eu32KOpFxRYBMjeQjJDiiYSfQVKu7qI9FupY+dWZj2gexyEDQE0i8EhJNOEGkweu3 4xCRkcwDKLO+HZGs25eY12zSiVemA03RWbHMBfTvqFgQiyz16CVqH4siW6JcjXEABbZEk9GqQf/R qlN+pdwGlVFuc+c4iAVdvBYHq07xXRRJJJKe+n+XPYVa2/i2LYf8HeW4GiOoNxY9ux1wrUIn/DXt 0Cugf6YXyKDgP7u+fGrh2AhXv4e1XEYnckk3NJ0itCellNjuXYSn0wdf1/75C/MFRAcKZW5kc3Ry ZWFtCmVuZG9iago0MgowCm9iago0OTUKZW5kb2JqCjQzCjAKb2JqClsKXQplbmRvYmoKNDQKMApv YmoKPDwKL1R5cGUKL1BhZ2UKL1BhcmVudAoxCjAKUgovTWVkaWFCb3gKWwowCjAKNzIwCjU0MApd Ci9Db250ZW50cwo0NQowClIKL1Jlc291cmNlcwo0NgowClIKL0Fubm90cwo0OAowClIKL0dyb3Vw Cjw8Ci9TCi9UcmFuc3BhcmVuY3kKL0NTCi9EZXZpY2VSR0IKPj4KPj4KZW5kb2JqCjQ1CjAKb2Jq Cjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKNDcKMApSCj4+CnN0cmVhbQp4nJ1QywqC QBSd9fmOFrVIZ5yHuixIhNoIE7aNQiXUsvp/ujMiUdAmLjPnnLnvGSACDmfLkWjFCU8dBhDhIjWJ 5spHfGsKctBBGh0b7tPbt4hiJSNHWnwJdzco0VOTcNXemiNH/fCTTOde/1W7QYWCqg6QybTYm/mt JuEwjlwtkQZaJEpOC/nua4swu/ZPAaMoyFafH+WTIFQSGKl5Cjum2jPmbMb2LGNbtmMly4mV7EAv +QL2go2l+Yrf843OwtsLsCtKxwplbmRzdHJlYW0KZW5kb2JqCjQ3CjAKb2JqCjE5NwplbmRvYmoK NDgKMApvYmoKWwpdCmVuZG9iago0OQowCm9iago8PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApS Ci9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjUwCjAKUgovUmVzb3VyY2VzCjUx CjAKUgovQW5ub3RzCjUzCjAKUgovR3JvdXAKPDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0Rldmlj ZVJHQgo+Pgo+PgplbmRvYmoKNTAKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0 aAo1MgowClIKPj4Kc3RyZWFtCnicnU8xDsIwDNzvL6SOE6fpiMTCyMRcIUiHBCj8X8JJhJA6Isu+ O8k+2yusIdTYdSKeFC8FK5SQnUIU8q1jq7WpQoELMgZq4/knePSOK8nYiFoXnHHXJcM+P5eZkN7t km++0l/eC244qesKljgSm4n7cyziIhtrIU44Gq3g4KPoslA/GY5lTleHw0MNenwAAuc1ogplbmRz dHJlYW0KZW5kb2JqCjUyCjAKb2JqCjE0NwplbmRvYmoKNTMKMApvYmoKWwpdCmVuZG9iago1NQow Cm9iago8PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQw Cl0KL0NvbnRlbnRzCjU2CjAKUgovUmVzb3VyY2VzCjU3CjAKUgovQW5ub3RzCjU5CjAKUgovR3Jv dXAKPDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKNTYKMApv YmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo1OAowClIKPj4Kc3RyZWFtCnicrVbL jtMwFL0oO2+Q2IwQW2BAiNSJ7SRlBxr6Rm06actjNgg0U6HOQIEln8EHc3zddPowVZupLMePXh/f c1/uXEShFLa9dBOjJcYv12IuMJFRPcmM1CyxuYaQHa6FSkyaSD4+u13EqVaxnczExsJ+p2IibnBJ 7fXsx/SzFFe/WJOy/7yqhD0VlyIH6lyorCR2O2NW5cKOOrNYWZgppTJTEuLb3xSi1vh+8ztyQsXl uqHqttfD2IjCHSq+imekaEQtalOPPlFAZzRG61GHchpgP6fJc1F8E28L6Jj/X8f8YApRkoXSq34s 2J+b6lvK9UxrYaIwjrJ0jca9v6Wa+8KZ1H48UCTBe0xdWGNEQ3pPE6xH2AlgpSFmA8we0EM6WexZ qQHbroNmrdnB3J4aH6xUUpKMpPKw/LMDUMUewEga/nrAKIP+rRWWPXi7g/U570zQG+h97LixD4kx 9yEkA2ritGXZ4LPYuwNbY47I1gdGj1ciu/RfwCxX/dzEytrB+bwNPzbu5sdYpsdj5gWjV4jVFrPa jsAAsyHHs/31I/rFBd1fOO+cRRtLUTbKoZrZqhIjj1BkN/QKDrXaMsOVxE2RSeK9U9yrGqe4F4ue cCY32cvbeW4j4N0isr15vYwSGz0DVy+qx4gy2kO3Yox4weiUXtBT1PoPcHGA8bS6tlomx9PWC4aI PuN64/LRWt35aleF2XWJ1mGabFxSOTh1XYdZFB/j+fFBoSzXUKz8yeweoACmGXLe9jlrT+hRdXca nWzT2eVNL54ztA8LXHLo2mXNnUNd2thHpMVjm/e6a48Rp+Lefz1s+wceecOSCmVuZHN0cmVhbQpl bmRvYmoKNTgKMApvYmoKNjIwCmVuZG9iago1OQowCm9iagpbCl0KZW5kb2JqCjYwCjAKb2JqCjw8 Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAKXQovQ29u dGVudHMKNjEKMApSCi9SZXNvdXJjZXMKNjIKMApSCi9Bbm5vdHMKNjQKMApSCi9Hcm91cAo8PAov UwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iago2MQowCm9iago8PAov RmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjYzCjAKUgo+PgpzdHJlYW0KeJytVU1v00AQHWT1 sgegR35AoRXgrr279voISk3aBqVuHCdALwjURigtBBAnfgY/mLfjOMGpK9UmWu3HeMfP783Mrhci 8KVw7WW5MFpi/nQtFgILGSSRNVKzx6YNJzddCxWZOJL8+nxthLFWoVvMxYbhxpmYiBt85PDV/Nvs oxRXP5hJ1b9fdcKeiUuRAXUhlK2ErVesqjLcrK3Dsr5VSllTCeKvv87FYfr15mdQOuWX9UAlrid+ aERevpR/Fvtk6JymNKEBZXRyIPIv4igHn+xuPllrukFkfdlINRScu02qTl5itRYm8MPAxjXKD/5U NO8LZ2I3NEDRHtSP6Q31MXroZSycVcB2MXkLK8Uzj72KZaR6PJ9jVflNYHl0xj6nrQlGleBAhr68 pfh3W8BAGh4bwOjigEV79IIiUpj3UASPlgKPIW1KQxa8Csd/yDGhb8Eg2oqcJrC1nPegPkTrQ4hH J7DKzGYs7oy9+vQY+RlxTgcQO6C0I5fE3ubSFmpV5qGRDWHqVueNWHSxj3ikdFqrcg92jyt4h3dT PBthp0dHHEcPe853zDse9sZcIgP6QDvdi0LJwI/AUG+jKBrBKObTWID7CM1lfvJPwfNdx1oKVu8U DZfnvnYP3p+KLsUJhRrVoKNq2n61BjTKaWsCA8tdsN/lqj6+4yg/o+f0FE/e0RNYCnYte931aan4 Gg23oa8RrLlUncgpktXnhBVckg9XV/Las91vzLW/O3txNAplbmRzdHJlYW0KZW5kb2JqCjYzCjAK b2JqCjU1OQplbmRvYmoKNjQKMApvYmoKWwpdCmVuZG9iago2NQowCm9iago8PAovVHlwZQovUGFn ZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjY2CjAK UgovUmVzb3VyY2VzCjY3CjAKUgovQW5ub3RzCjY5CjAKUgovR3JvdXAKPDwKL1MKL1RyYW5zcGFy ZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKNjYKMApvYmoKPDwKL0ZpbHRlcgovRmxh dGVEZWNvZGUKL0xlbmd0aAo2OAowClIKPj4Kc3RyZWFtCnicrVRNj9MwEB3U21xQb/wAECBB6sQf cbiBdkNLF0q6abNCe0Gg3Qp1FwqI0/6M/cE8TxW6DUFqImRlPI7t5/dmxt5wHCkO7fnWsUah/3TF G4aj4sx5q4ysaI6xKHRXrJ1NnZLt690gSY1OgrPmxiDYFVd8jUNGL9ffVh8VX/4QJvX3/bIX9oov uADqhrWvhe08UVUPQm98wPKR11p7WwuS01+VPMq/Xv+Mt4vKi/1AZeHLosRyud1UfuYn5GhMOZ3R gk6oovPzp1x+4eMSlIp/Uyo6M46dj1Qr24QlfU22QWHmjWEbR0ns0z3W925rmofC2TSYFih6RhMa QDjNEYUBHSESY+kH9Igs3b87WUmgCnhzsRVNZfEEwQvbPmDbjGadyblabKySSP2l9qYrYKys2BYw iJqBfU7vwNvTiB6K2Bz857REG9AxvAW9hp6FyB9DZ07DniRC+pskukL9KYZEqZb49KuGVqxmOYT8 hpLY5XohMxUyXtAbjE/lTyUxnSO2dW0cBduPmHEtxMJ5leRkIvkaS27e4rSTvVp8D7ukaf8aTDK4 ON79jxpsBbvz6BwW0TMoqmcVPaYH3cmYrTzWJo0cCJk9db86A1oN2woGTUMwHUp+psgVsiFVEQrr BWm5cafyf4kXQ+7awa9uaL8BvJU28QplbmRzdHJlYW0KZW5kb2JqCjY4CjAKb2JqCjUwMQplbmRv YmoKNjkKMApvYmoKWwpdCmVuZG9iago3MAowCm9iago8PAovVHlwZQovUGFnZQovUGFyZW50CjEK MApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0NvbnRlbnRzCjcxCjAKUgovUmVzb3VyY2Vz CjcyCjAKUgovQW5ub3RzCjc0CjAKUgovR3JvdXAKPDwKL1MKL1RyYW5zcGFyZW5jeQovQ1MKL0Rl dmljZVJHQgo+Pgo+PgplbmRvYmoKNzEKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xl bmd0aAo3MwowClIKPj4Kc3RyZWFtCnicnVDLCsIwEMx5vkQP1qR5NDkqKB48WIiPqyhapK1W/X/c pJRiwYssm50hs88GIuEINmmBVpziqUIDAlw4YzVXUTHkJAqhgjQ6Mzymlz1JMyXTAEoMSHgL7FFT k+msfBRHjusrTtL58/pX7QIX5FS1gbTdYj2KW3UkxCwNtYRLtLBKdgvF7nOP6fJevwWMIpG/fB9K OJUY7qSFUDYxUnMH36b7M0ZMsxXz7MDWbEtoQ56zPduN4W9YeJox/z1j+5lH+wDz80u/CmVuZHN0 cmVhbQplbmRvYmoKNzMKMApvYmoKMjAwCmVuZG9iago3NAowCm9iagpbCl0KZW5kb2JqCjc1CjAK b2JqCjw8Ci9UeXBlCi9QYWdlCi9QYXJlbnQKMQowClIKL01lZGlhQm94ClsKMAowCjcyMAo1NDAK XQovQ29udGVudHMKNzYKMApSCi9SZXNvdXJjZXMKNzcKMApSCi9Bbm5vdHMKNzkKMApSCi9Hcm91 cAo8PAovUwovVHJhbnNwYXJlbmN5Ci9DUwovRGV2aWNlUkdCCj4+Cj4+CmVuZG9iago3NgowCm9i ago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjc4CjAKUgo+PgpzdHJlYW0KeJytVM1O AjEQHsNtDsbHUBNL/7d78KABVDSS1RXEcDEaJQZU1KOP4QM7La7KWg2sZDPTmW779ZufzAQF4+i/ ralhNKf1aowTJIOL1DrDdThR9umQX8aorEksD9dHX45MtJLeGGHJ8XqIPbynR+o7o8fhJcfb58Ck kKfbSthDvMGMUCeoXBHYlxWiKhy/auexHHNKKWeKgMLruznWWw/3L2J6KL+ZTVTqJWXSYD69lF/j Ohg4gXPowRFk0IYanMIZ7fRIWiSdDczvsJkTw+x3htnCAQjrGI+SlxiqWSbvA06d1mgEk8IlM0Gs vBU054UziVcRKNiG/ZCBtRB/BgeUmfbC8LagK7hk/Aff10UBBTdBR8BAQhP6xNLXsQsdGAz+QFfy d3R6ObEl9EWJftZJpJw5YaxaQqGiWFAPPXtMlepSvzZI9qvXSWoZoVuxTlEwGGwQSU+19tFa/dBq bdIZ7fyHfKqYXRr5GBhsUrI9325g3yGrQdxrtLsX7BpFdED6Ag7J8vvdoDPSDdJ75X/VyCmVRsiF CVat6VXiGI3oWcDKTa9pMGshlzGcYlBgKectWKVsTvvo7PvwnntU++8d7E1RMgplbmRzdHJlYW0K ZW5kb2JqCjc4CjAKb2JqCjQ1MQplbmRvYmoKNzkKMApvYmoKWwpdCmVuZG9iago4MAowCm9iago8 PAovVHlwZQovUGFnZQovUGFyZW50CjEKMApSCi9NZWRpYUJveApbCjAKMAo3MjAKNTQwCl0KL0Nv bnRlbnRzCjgxCjAKUgovUmVzb3VyY2VzCjgyCjAKUgovQW5ub3RzCjg0CjAKUgovR3JvdXAKPDwK L1MKL1RyYW5zcGFyZW5jeQovQ1MKL0RldmljZVJHQgo+Pgo+PgplbmRvYmoKODEKMApvYmoKPDwK L0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo4MwowClIKPj4Kc3RyZWFtCnicnVDLCsIwEFzw Np/hSQ/WpHn2qKAoilCJehZFi9RH1f/HJKWIghdZNjuz700FnjAE6dVASebt7owKHjCeaauYjBnf 3CcFc4bQymgWy8s3SY0UaQAlvkh4C2xw8UP6g/JWbBmOj7hJo/fjX70LHJD7rhWEbQ57o3hVQ4I1 aejFs0RxK0VzUJw+dOiPr5cnh5Y+yR0+P8pkCZPaGgUubaKFYhlcXe726JChJa1oTDOa0Jra1CJB c9pEzzTGFsHfhTth5PzO+e+d62Ae5QV6rk1sCmVuZHN0cmVhbQplbmRvYmoKODMKMApvYmoKMjA5 CmVuZG9iago4NAowCm9iagpbCl0KZW5kb2JqCjExCjAKb2JqCjw8Ci9DQQoxLjAKL2NhCjEuMAo+ PgplbmRvYmoKNTQKMApvYmoKPDwKL1N1YnR5cGUKL0ltYWdlCi9JbnRlcnBvbGF0ZQp0cnVlCi9X aWR0aAo3OTMKL0hlaWdodAo3ODMKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0JpdHNQZXJDb21wb25l bnQKOAovQ29sb3JTcGFjZQovRGV2aWNlUkdCCi9TTWFzawo4NQowClIKL0xlbmd0aAo4NgowClIK Pj4Kc3RyZWFtCnic7N0JWFtV2gfwtLX6uTvOuM2o4z6uqJ/7OPMpOm4zozg6tTqi44yWcR90HC0t tBXX1G7UtkJpCWurQJd0S1uaLlBKCqQsLU1LQ6FLgAYIEJZAbi79Trabm5UkBE6W/++5+rQhhJf0 nHvenPvec06fBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgJES mNCOAgAAACAkCaxoBwIAAAAQepBKAQAAAPgNqRQAAACA3wQ8tGMBAAAACD1IpQAAAAD8hlQKAPyA UwcAgBmu8QGAH3DeAADg4JQIAL7CeQMAgINTIgD4BLPZAAB8OCsCgE9wxgAAcIATIwB4D2cMAAAH ODECgPdwxgAAcIBrfADgJZwuAABcwrkRALyBcwUAgEs4PQKAN3CuAABwCZP2ADAsnCgAANzBGRIA hoWzBACABzhJAoBnOEsAAHiAiSkA8AynCAAAD5BKAYAHOEUAAAwL50kAcAfnBwCAYeFUCQDu4PwA ADAsTOADgEs4OQAAeAlnSwBwhjMDAICXcMIEAGc4MwAAeAnT+ADgDKcFAADv4ZwJAHz4hAUA4BOc MwGAD+cEAACf4BMoAPDhhAAA4CucOQHADJ+tAAD8gDMnAJjhbAAA4Ad8DgUAM5wKAAD8g/MnAJzG qQAAwF84fwIAJqgBAPyGUygA4CQAAOA3pFIAgJMAAMBI4CwKEMnweQoAYIRwIgWIZOj+AAAjhFQK IJKh+wMAjBzOpQARC90fAGDkcC4FiEyYlAYACAicTgEiEzo+AECg4IwKEIHQ8QEAAgVnVIBw4k2P xnQ0AEAA4aQKEE58SqXGLCoAgPCG8ypA2EAqBQAw9nBeBQgPXk4yo8sDAAQWrvEBhAdv+jL6OwDA aMCpFSAM+JRKjWVgAABhD2dXgDCAVAoAgBbM+QOEgWE7Mno6AIB/UIkKEPYE9oZ9zhiHBwAQ0pBK AYQ9n1KpMY4NACDU+VRBgdMsQChCKgUAMHow8w8Q9obt5ujjAAAjgU+sAGFM4MTDc8Y+PACAMICJ KYAwhlQKAGAMYP4fIFwNm0qhdwMAjBw+twKEK6RSAABjwPlk6+F8SyVCAPAPujYAwNgYNpvCR1eA kINPSQAAYwanXIDww++z+IgEADDavJ+YohUhAPjE+1SKUoAAAGHF5VmXf47FB1iA0IJUCgBgLLmc lXKXTVGMEwC85DmVwocjAICA835iil6MAOAVhy6MVAoAYAy4O/dyZ1qcewFChbvO6+4JAAAQEMPm Tjj9AoQEpFIAAFR4SKUE7otXASDYeE6lMMMMADBKPExDCdzXUAFAsPEylaIXIABA2PJwIQATUwAh wcNnIpd/BQCAAHI57yRwhWKQAOCBhy58GnPLAACjz+VpFtkUQKhAKgUAQBcmpgBCmpepFL0AAQDC nLtkCakUQEhAKgUAQJ27ky2yKYAgh1llAIBg4OF8i7MxQDDDlDIAQJBAKgUQipBKAQAECS8npqjE BgDuIJUCAAgSns+6OCcDBCF3HROpFAAAFZ7PujghAwQbL1MpWuEBAEQanHsBQou7DotUCgCAFpx7 AUIIUikAgGCD0y9ACPEmlaISGABAxMIZGCBUeOit6MgAABThDAwQEjx0VaRSAAAU4SQMEBKQSgEA BC2chAGCnzep1NhHBQAAp/GRFiAUIJUCAAhaSKUAghw6KQBAkMNZGiCYoYcCAAQ5fOYFCGbongAA wQ/naoCghe4JABD8MDEFELTQNwEAgh9SKYDghL4JABAqcLoGCELomAAAoQIffgGCEHolAEAIwUkb iHiRKHH58qSM7KTlmUmZ2cYjI3tGZs4MUXaS8ciZYXpwhsj4CPmz+Uvmr5I/J5kfyTQ+0/Rk8khO kvUJiZnZ5j9Pz8hJWJr1yXfZtH/dYIdeCQAQQjAxFTnIP/Gny5dPX05SmixjpiQyZUeZlnRoTA9j ZmVMt8wxGLO1jOzP0tJov0NBAV0SACC04Lwdrsg/6NSMjERRTqIoy5S0mFKX4D64uaxEY46XOS0i kyt0SQCAkIPzdnh4dNasaRkZSaIs85wP9bwoMMmV8YphtnkOLUIyK/RHAICQg0/BoeuTH7ITl2cm iSzFSNQzn1E/THNriRnGsqu4MM2s0BkBAEIRzt4hJME49ZQd2KmnmZk5367MX7R2feaWosLi3ZLy yh3VNaUH6ioO19cebTx84kRjS2tze8epzk51V1d7d3dHt1aj7ens6enq7SUH+espTefJtvam1lNK VfOh4yf2H22srD9Ssv/Algr5mt178qQ7lm3avHCNmPyUwKVVxip34+VLkeiDhQtp/7MEDDojAEAo wsRUkPto3rzE5ZmmG+hGVPL0eXbewtXinCLpRln5nrqDJOdp7ujQ9vWxLDtmv4veYCDJWENzs7xe ub2qhiRaJH+bV7B6pGmV8a7DnMT00L49ED0RACBE4QQenKb/kJVknHXx8ya7L3NXpm3YJC4tKzuo ONrS0tXbOzQ0RPt3ckvPMCSvq2k4Kt1X/eOOXYvWriOJnx+/tWkxh6wZy7PeEIlo/04+QzcEAAhd OIcHjwSRyJQ7Zfs6AfXtyvzcbdt3VNccPHa8o1sbzImTNwwsq2pvrzhcT7LBJes2zMrK9f0KoHHl hxBaZgHdEAAgdGFiirqkpZnG1S99mYCamZVLcoz1ZbIqZUN7t5b2bzC6GIPhZFvbXsWh/J3Fs38q 9GGeynj5z/j/dxcvpv1LDAN9EAAgpOE0TsUnP5jvv/M6fcrMSV2/cWvlvobm5kE9Qzt8atq7uysP 1xfuKpmTv8rra3+WdauC9tof+iAAQEjDxNRYIqO5cdVxrzOo+YVrxHvKDjQ29Q0M0I496HRoteWH Dudu2/5FzgovcyrjQlVBllChAwIAhDqcycdG0nJTabQXSdTMzJxlm7aUHjjYEe4X7wJFbzDUnzi5 oWyvt7cEinISM3KCpJgKvQ8AIAzgZD564tLSpmdkWfYC9ngkZ+flbtteWX+kV6ejHXUIO9XZuaum drF4vZeTVNOXZdENGL0PACAMYGJqNExLS0v0Yj2oz7PzVm7feaCxaUCvpx1yWFF3dW2vqlm4RuxF TmWspJo0aRKVONH1AADCA87nAZRkWtZg2FWhlm6UlB863I8iqFHWqtFsk1fNKxz22l92oigrfswr qdD1AADCAyamAmL6ssxhM6j5hWuk+6rDfhGDYDM0NNTQ3Jy/s9jzEqDmpT6nZ2SMTVTodwAAYQOn 9BEyXsvzWFI+KyuXjONNra2hvoRmqOsbGCg7qBi+mEqUM3X0Z6jQ6QAAwgnO6n4gb1ficMtDzf6p cHtVjba/n3awYOdkW/vqklIPk1Tmq7SJaZmjFwM6HQBAOMHElK9mZGZ6vjVv2aYttUcbDWO4azD4 qqe/f3tVtfDHfA83+iVlZk8dnUt+6HEAAGEGJ3YvTV+W5aEmalZW7qqS3S0dGtphgrcYg0Ferxzm qp8oJ2FRgFdOQI8DAAgzmJga1tRlOR72y/s8O2/dHpmmp4d2mOCnhubm5ZIt7i/5Ga/6BWoDGnQ3 AIDwg3O7BwkZGUmZbiejvshdISmv7O7rox0mBEBTa2vmliIPM1TTM7IEs2aN8KegrwWQYNajgrmT BfNMR9w9tMMBgIiG07uzSZMmJYqy3I2qX+X9uG1fFZYoDz/HT6mzt27zcL0vKSN7JK+PvhZAxgxq /suWY95LtMMBgIiGiSkHZLhMclNb/nl23ubySmw0HN5OtrWJNrueoTJvPfPRsmX+vTI6WqAYp6Tm 81Opl2lHBACRDmd4s6lLlhhXOXBzRa+weHcnaqIiRv1JlbuidJJpJ2Zm+9pf8JklgATzX7LlUeSY TWcPIAAADk7yxPQMt2VRWVu3NXd00A4Qxho7NLTviHJO/ip3CVXS8hzvXw29LFAEkybZT0lNph0R AIBRJJ/kE9Oz3a1bvkS8Qalqph0g0KRnmOLa/V/l/ejq/r7sGaKsuLQ0b14nkrtYYAnmvWw3JTUH hVIAEBQi9jyf5GYyigydZQcVLBbbBBNtX1/BrhJ35ejT0odffipiu1jA2adSmJICgGARgVcfpqWl ubuil7+zWItVDsBJQ3PLwtVil9NTSRnZj3pcLSHS+tcoEcybhCkpAAhaEXWqN12acZFHpaxe29CM K3rgloFli2v3f5GzwuX9fUlLXe/fF4EfVUaJQ5WUYBbeTwAIIhFytp+6ZEmSq5mo5Oy8ndW1jMFA O0AIAZ09vTlFUpfZVKLIxdpTkdCzxoBg3ot2U1JzMSUFAEEn7E/405e7noxKXb9R3dlFOzoIMfJ6 pctydNLGPli4kP/MsO9ZY8NhLSnBB8/QjggAwFF4n/CTXC1gPisrd0d1jQHl5eCXrt7eLFcLpBuX Ssi0XewL7541NoxVUvyCc6xwDgBBKVyv8b27eLHLCvPv165TtbfTjg5CXuXh+i9zVzo3sESR5c6+ sOxWY8y4455dlRSmpAAgSIXfOT9paabzRb2ZmTlbKuSojIJA6ezpXbZps8vqqV9FRYVftxpjgtkO y3JiSgoAgleYTUy5vFPvu58KG1taaYcG4YZl2W3yqplO2dRf3/sgbDoULXabF5OcCjvFAEBwC5tU KinDxUU90eainn4d7dAgbClVzcIfC/hN7pHnXyC96YKLL6YdWqgSzHrGLpXC5sUAwe2S+3ovvD/S 7+QKg1TqDZHIOYmamZkj3VfNDg3Rjg7CXE9/f+aWIq7h3XjnXaQ3PfW32KRMH/bsA45DHiWY/SLt iADArUsf7Ln0wb7LHuy75IFe2rHQFOrX+BIyMpIyHeejvl2Zf+SkinZoEClIxr6jusbc9s45/wLS lf6ZNNO8ToLA46Lo4EAwy+HGPUxJAQS1yx7ovcyUShmzqfsiOpsaP348Ofn//JdXLjw28G0jm9zA JjUyCUeZ/zYwHyuZD48w79UzH9Qz8UrmkyPMZ0eZxEZmVhP7VSM754QhU8Wsa9VtOtJBJXKXedTS jZKu3oj+B4VAYdihPsPQqQH2YC+7t5st7WJ3dbJSDbulg93Yzq5tY1e3sevaWEkHW9TB5jdqPinY QrrS+AkTZq7Z/HXh+i9WFszMznNYdQo8sFuT05hKYUoKIKhdas2jyHHp/RG0BdusWbM2tg6mN7ML Thi+aDRMUzKvbD5wwS13/fqrnCtk+gkleoHXxwV79DdW6B+pZl5TMJ82sDMamdnHDYtPGApaDfkN mtH+RWZkZiaJHK/rrS4pxZ164B+SOLUMsDs17MpWQ+pJg/CYgXyOeKqWualCf+Ee7zrFjj7BvY8L Yj+9TKa/s1IfU933/v7uaQe7Pz+qn3/csPQku/6UPj8/n/YvGqQEswT2BeeYkgIIdiR9sqVSD/QK 7gnnvdhm7dixpplZcoKMDsxnDcyf9zNX7fUhZfLpOLdUf98+/dv1huQmduFxQ0azfv2J/oD/Romi HOfFo3bV7A/4D4LwpmOHFL3s+jY2XWWYftTwcJX+vNLR6hq/2qt/ppZ86GBIkkY+cRS2GPLr6mi/ AUFEMN9+8+K5SKUAgt3F93XwJ6YuCceJKYFAsLqF+f6EIeEo+9A+ZvTGCHfH+BL99eX6Nw4ZhE3M MhWbf6I7IL/XdOc99XJWHGhsCsiLQyTQs0P7e9i8VsPHSuaGCmNDHeOuQT5x3F9l/FyTctzwk4qZ hZIqY8E5qqQAQs9lD9rKpchBO5xAWtcyuOi4YeZRJrqGOWu36ez9ed64m+4+950vAzYc5B8RpJZ4 e6xqvLZc/+5hw9xjhqxmw6YjR/z+1RIzshwWj5r9Y8EJdVsA3z0IV+zQkLKPLTjFzjhquLHc1Iy3 aATPx51/b7RgaWlg+sWuAUF6mfddY8LO/v+rZpIajR951qj1tN8hagRz7auk5k6mHREAeOUXvGt8 poqpcKhVXtHCzGliXqizzkGRkeIvb1/9m1tXr149ODhoMBg2bd78q7hEwY7+EQ4ZE6W9b+bv2FJW XrmvqnJYcvlluy0/8fZKfeJRJvUkk93q88qZSRmO81GL1q7v7AmHfzgYVYahoYpulqQr98itbXjJ TsFtD/ztb387dOjQ0NBQR0fHf7/8VvDdupFnU9eJD89ZJ91bVUOa/bA9I3XDNvN3nVOqjznAfHeM WaFiaL9bFNhXm78smIRlOQFCg0CQf+kD4VN8XqgemHfM8GQNY7ta8Z/FL7/8ikKhGLJfXon8dXdp 6a1v/teYaI1s1BhXov+bQr+xtb9d2zvkcRGnXfsP8b/xyr36qQ1M2knW+0UYnBfhTN+4WTc46P9b BpHhQI/xJovruPrAXQPn3/VwampqT0+PwzN7e3uF3y+eMCNz5AnVr/bqvzxmqGnTDnhsoqTXPLyr mfsu0nkfr2HmHmPyWyKoYdvtuIcpKYBQM23uIJdKXftoX4hOb8yaNWvRcebvCmbibruT+fml+h1N p9xlOOTxmpqa38b9R7D2+IhGDUm7IPqvTz/9tErlaSkn8uPuLVY7fO+tFXohGTVUA8P+js6LHmRu KRpkIvHzO3ivh2FzWwz373NstC9U96m73FbuDQ4OLs/OOfujBSNNqOZLJlx5/aJFixiPDfVYc4vD N55BPqEcZBYeN8zasSPwb0rwsd9x72XBrEdpRwQAPjjZyl7+kG1iKlccekPzRnXvd8cM17i/I++a cn3JMU8JlVKpfPaDTwUr6ly/wq4BwapG118q6hL8YfIfnniioaHB5euTB1mW5f7acELl/CITSvRv HTIsOc46fzsnUZTlkEflSXdg0QPw7GAPm3jU4PD5gn+8eaCvvVvr7ttJ/rNqrfjnb88ydgGXr0D6 hbsvfb9t3JU3LFiwYGDA9ccEdmiI32Xe3HHYxbyWjPm2yZDfHOY7Hwm+c9i8GFNSAKEn9j86LpV6 +p8hdtb68dRAYgNzpvvBgjtuqNDv8ZhQqVSqNz5LshXf/nRY8Nf3J159Y9y/3k7bf8LxBbdpBU+9 +sij0fX19e5eUzXAvlBnzJSmNQwe7+g2DR1Dr+444jK8h6v0Kcdc57HGOnP7PKpwV4mB9ZR6Aezt ZmMOMN7MHb1d16vROl7p4xi3LZZuv+atz4xt3vwtX+ULHnjqutujFqZnvKRwesEfisdd/ZvZs2fr dK5PJiSJkmjYS8r0N1XoVx/r0g0YL+Rpe3pcxkbywM8amMxj4Xyxzy6PIn+e9TztiADAZ1tKDPzi 8wP1ITNGi0/1fqpkfLqP++YKfflxtwkVYSy+/fyrW//33rS0tKamJvOc0pfHDLYXkfYK/vTGbx/+ nXMJFkc9yL56yHEUI7lc4fHu6lNd7mK7U65fcMLxzZ9u2n2Dn0et2yPDznrgWWU3G13jQ78gx4d1 PR7uXyBNvby8/J6nnn019rWioiKtVkse0RvYc/kLjJCPIdfc+tVXX/X3u15IjXzLji72V04TyK8f Yg60dk6r73MZ2LgS/UdHmLWqwC/OFgwEX0+y33QPU1IAIclgGLrr2X4ulfpUGBofAGfNmvVlk6eL Fx6O2yr18hNqz1XiHM2gNY8iSVTMlHsfePDAgQPuvlczyL5d79VUgMvjif1M6gnbZbsZTvNRG8r2 Bubtg/Cl0rGvK/xshJ8oerp7vb39ZM4Ja9dYXi64/o6ZM2f2utmxiPSXsm72unI/+8WEEv3njYa0 ysrAvUnBQjDvJX4eJZiHG/cAQtXsdFvx+fWP9fXpQmDS4/sTzNXl/ict5lmgmmPNnhMq8tWXzZcw vll197331dTUuHu+Vs9+0mAYSTzm49MGg3m5QtO+MHbzUatKdnuZ/kEk++HkSNvhNEV3z3DbOHbp rT/lwWemTZvmfDOgGWmx+3rYWytH2i8uK9MvcHMFPHQZNy+2WwMBU1IAISwUi88/9HvyR9IueH+2 4PYH7334d+np6RqNp83y6vtY7nPx9iY166pCqY9hZzQFIIkyH1fKmEUnDInp2Q77663cvtPlTwfg axlgb67wt/kt3yt47q2JV904ZUrctm3bPLQ3kiC9br2E/Qd5b2uX1jnJJ48c6GXvcbp50O/j3foQ OC/5xG5Kav5kwRxsXgwQ2kKr+Fx8qO1uuT+p1LlZlR9mFBYfOKzt17FDQ54PAzt0t/1AcH6pfklj j7bPUrahM7DCE4ZxARopuOOjQ/0z7POo7K3bcL8eeKOog/Wn1e3ov2PBqsUbttWrWklLG7Zr1Pc6 fnZ4uFpfdrLdnH2RJIp8Bvl9dYD7xS2VTFqz2/sNQ44g7h6HZTlpRwQAIxVaxeffKHRjv6Ee/3hZ oZ9zwjBhdF787T1H+XnUsk1b9Fg/CryT2+pXKhWgg3zWWHjS8PT+UXnxibv1yUdCo5LTG3bV5liW EyAshFbxeXKdNuBzQZbjszTjDmL0BiNyTJWruDzqh3UbsZ45eG/GIderCoz02KQWvP21bT0EGsdN FfqpyjDZpE9A2KVSyKMAwkQIFZ+/u+v4z8sCfa7+4sfzr7pu9erVLS0tyd/Nn/C+0MVzfigW/OtL b4/ETONNf75H8ln5CXMeNSd/lbYvtHfzgTEWu8fFMrAjOkgbfurVPzzxRGNjY3l5efRbHxpLqpyf 9vH33vYLkpK5fIXhjv+V6+c0hsnHCscpKdy4BxAuQqj4/FXJgccr/clSXB+Ltk/41fVLly7lb29B /izZvOXm1z60pUO7Bm6Ouru1tVXtWVu7WtNV1aL59hhzg+8FwONK9DNlDSSP+iJ3RXNHB8U3GULR WyWNZwQwj3r5ozv/9x7+6h/kD6SNf/7d3AlJGbanTU0nhukXRHuHqqNr48nufx5mzvI9mMn7deK2 Nrpvb6BgLSmAMBYqxefPr6l7be+pAIwUObWCG6KSk5PdrcxsYNnn6qxP/svbZEzxENUgwxzsYxep DHeP4K6lByv6p20pn5mZozh2fHTePAhnr26qeaTS9VqXvh3vz776xptLS0vdrb+h7NFz6dANt9/p +XY/zYB+eyf7oZI5fwQljh/XdobHlnyCOS+h4BwgjG0uZkKi+JykUjdmlv6+YgRDxpomwV2/f+ed d7q7XW/qyg4Nbdawl3GXETepn332Oc/LOvX19X05/3vBfInfUU3crX+9rPkj8a7dB+pG552DMPeX tZWv7j55ll9L11qOGdkXXnXthg0b3GVH3Q5LqL30YVVVlYeQSK85ePDgg+9MNa5D4m9UD1T0P7up LkxSqXnYvBggnIVK8TlJpQRzNr4obbiyzM1uqiX6B1/6+4WT3zOmTA5f2qIR/N/zL7zwQmtrq8sX J0nUtk72Cpn9d937uFqt5p7DsGyfm4ms3t7eGXMWCL7f5sd48UZV14WLioTFtaPyrkEEIKnUeQu3 vFnV6baZfV345OtvCf67xMWX5ksm/urazMxMg5uVN3r07LRG+2UQtmiefPpp/uW/Lt2gy42NyJf2 799/z9ufGTugj/3i8rLByTubbsneEwaplGDei9i8GIILo5IUEJImu7VGGJ1Ox+DmcX+FRPG5OZUa N2fjm7LmK9xkU89+t5x8rD58+PDHM5InvDFdUNQl2NEveO6th3//+4aGBpfzS+TBnV3sVU57hAmy 9k1NmHbalGUp+th/N1jWkvpW0THg5va6np6eqd/OFSzZ6f148XKV9vrM3eT3KmxoH923D8IXSaVI E7p62a7Xqrrd3eVaXbufnCQ3SSQPvhonmC02PiiqFFxzq1AoHBgYcPmyvQw70+U6tA/9saWlhTyh nzFs6GDvNV3avqZcLzvW6q6LVVdX3/lOgvc3A166Z3DK3tbxczeGRyr15JpvuDzqvMX/6B7AfSVA maZYKDARq4yJk05dm5oQK+BExSSLJCqkVD5yKD7PWxeM76A5lSIHOcH+Y8/Jm/e6yqZ2DRxtbDQ/ n3zKrqioeO+DD6qqqtyd4Xd3s9e42yMsp3ZHh/7bEwbnSo+JJfqMw2p362d2d3d//IXQuM2rx8Hi zN36N6u7r80oMf9Sq48ilQI/mVMpcly1bNeU6u7/cXWl7855P5l7Afl/Z2dnTl5eUlKSu51f+hjW bjtv++NpycHSbl49Ie+4Z59e0dzmrrtVyuW3vTN92Ftcr9878JasecLcTeQ3CoNUqqH71MSUV7lU 6vOyQtoRATCShChjyhSdoiFplVwkcC2+NnzWxx0jwV98zqVS5uOPkkMvVPWOdzoP/2G2aNhN68wb rfpxqx3/uLBUv+5Ii7vaEjJavT/zK3c3gF8rG3hX3vbzJdu4XwepFPiNS6XIcdGioncq1Te6+qBR IfdU3WQWkMX8n64dPNHuem8m0vX27t17079cJ1Tk5z63r/e5rfXcrxMGqdQ/i1K5POqc719v78fg BLQxijhTqhQrUnB/Nk1GxeVJpAWi5Gjukdg8tFefBH/xuUMqRY5rlxe/v6/9jnLHUaP+iNLD6xgM hjemfW5cAGpk44X5uGqvfneT6+saREdHR1z+dv7zzy3Vv1atjdlaP87+d0EqBX7jp1Lm48+bD71R rXWYUL15fqHnTxmNx47//MU4Qe7+gHSN1w/0dWjd7ndcKtt7nbSV//xbygfer+q4QVTK/0VCPZUS zJt09vevc6lU/M4s2hEBnNbKU82Zk7iJUeRZM6moZCVjewaXX4kwM+ULg2HozuAuPndOpczHY+L9 71R33lI+yJ2Tfz87c9iJqZ6eng0bNv4+dopgesbIR4075Pr9KrXzD+1l2PQWy14zJImaVNX7Zpnq Z4u3Of8WSKXAb86pFDku/H7rP/acfLm6h59Q7Smv8PxSpA03NTUJ56f87IW3ApJTTa3r6ut3nOU2 b9j34kHLc27aO/h2ddeTG+rGOf0WIZ9KzbetgXDGgr8d6w6TNbIgyGjlUolYIhZLZJphHjQqNk87 RQnVp9XCKEvKVKC0K+xpEsebH48WysbiNwgj/OLzGx4PuuJzd6mUqXpq0+Pr9r9XpXliX/85poGj +GiLdmDQm6Omuf39PY0B2VnvseqBJnXHkAkZKV4/ZNl8+eaKwX9Ua/9RevLSH7a7+xWQSoHfXKZS 5uMXS6R/333izeru20yfNa5bo+jSedUv2vt0qw403isLwK4x40r0CxRtg3rj/i+DBnZdO3udqUDx 7FL9Y/v636vufGpD3RnzNrmMP6RTKcGsZ43rHlhTqdc3L6YdEYQprcx6SS5apvX4oJHSnCTFpMhP a4otzzGmVfbUUkuSFZ3q+mo9uDHGxedviESJ5MjInpGZk5SRlZSRM4P8WZSdlGn8v3EXFZHpr8ZH csj//5271t14wR3XZ5S8XnKcfMJ9WK6bOJJldkZwPFenN48UV+/Vv1rd806l+rG1tf+zYLPnyJFK gd88pFLm46z5kkfW1JCm+Fp1z7V7B0e1/bs7SOL0z8MMSavOKNE/WDlAOukbpSduMt2+6uG4Jas0 hFOpubYpqXHzX97fhgV4YXRo5TGWrCmGl0q5evD0aZ3CUmSep9BZr/QJooXFjq/JKBOs9VJyXOLz 0SgVn380b15SZuZ0ki9lZiUZ0yTzkePT8d/swmFTKfMxbs7GO3LL3ipr/ld11zP7+q4p14/WPshO xwV79A/IB16v7nl3X/ufNiku+H6rlzEjlQK/DZtKccd5C7c+s/Hgu/K2v9doH5QPXLhn7FIp8sni 6X39/6rpniJrvmvF3vFzvQr41qzSuMpK2m+wPwSzHuWvJfXntULaEUH4YlSi+DgiNi7FdpnO5YOn T8tTzBlWQhNJq2otqZRxhsqRVhTjIhMDbzgUn9cd8bP4/JPvsmcsz0rKME8o5VhmmUZ2eJ9K8Y+r 0nc+tb6OnL3f3qf5W3XP/1YO/qIskJkV+ax9XblxjIir6X67Qv3Kzsa78mTDzkEhlYIA8j6Vss1T LdgclSubvOMoabRxpk8c15frzxnBDi/Ox8/L9HdVDr5c3fN2lSZub8vTG+uuXrbL1zhvzdo9IzOX 9hvsD/6UFDlKTipoRwRAqJKjbNNQKmmyOVuKy3Nun7ZUCrNSvnIoPv9stg/F5/9JS0tanpmU4c+M 0+ilUg4fye/7seKFoiNTylRxZATZpyH5z0vVvY/s090r199Rqb+xwvjZ+dIyPfm0ftZuY6H4xWX6 X8r015brb6nU3yXXP7Rv4M/7+v5Ro42r6oyrbCMDxGvFx/6wbr8fYwRSKQgUP1Ip508cj4trX93V RJq0sWFXdf6zRvvnqj7S4O+WGxs/+bxAOgLJjkinIF3jgj3GbnLVXmOXub1ST7oP6USTqnqn1HQb u1WFmnSxF7cduf+nCu8nZt2nUjmJ6dm032Of8fOoh35Moh0OgBHTVGBOj1JN9+XV5sXz/2oPqdSI OBSfq1xvtGJB3uUkY8mTsZYpIFNPo5pKuTwuXFR0k6jkrjzZg/mVj6ypfmpDXcyWwy9tb3i9+Njf djaSvOtPEsXj4v2/K9x378q9t+fs+WXaDnclskilgIqRp1LOx4S5m65I204aPGn2DxfuI13gj5sU pDuQTkG6xuTtR0k3IZ3l0bU1pOPcnSe7KXP3RYuKAh6GMZXKyiWnF9rvsW8cpqTWNYTkNUoIP7Ui 85Lm8eZLflytlOdZKVzg84ND8fmU6S42lYhLS5uRmZmUmZ00svTpmxU/LRavF20uWrl959rdezaX V+6sqS07qJApDu1VHK44XF95uF5ef4T8ofRA3U8VNaORSgXJgVQK/DYaqVSQHOZUyni6WB5KKzLx q6Suz/j3sGuzAIwJdYp5FYQEqfnvWq5WKtVFrVRqjLXsPBgX7Q4B/OLzW57q5x4XzJpFTmgz/JqA +i6/MGvrts0VlSQvqj+pOtXZOaj37Q7Bhq4+6if20TuQSoHfwjiVui2r1JJKZWZPmjSJ9jvtFcF3 L/KnpBZXb6UdEYCJSmJe30BoXWiKS6UEcQWO4zF3A2BMKial/ONQfH7pA71Tl+XMEOUk+ZI7zS9c s6p4917FoabW1n43+6X6JLxTqRX1SKXAT8+uDttU6tZsLpXKCZXLfIJ5k/mp1CAbjFuaQgRSWhY2 j63lZpl0tdY9jONq7aeeNLIUyzoJKVii008Oxee//dthL5OoH9ZvlJRX1jUd0/b3D/9jfKTs7AvE ybkofmN1qrSWHCkbZTEp9AcL85FS0xzwdwwixCM/7Q3XrmFcVypnJXeGiReJaL/ZwxAIJ/Gv7gnm vUw7IogIGpWqiVBpGLcPWi/YxYl5z2EKrDvEGPfjs1EJret7uqpIB2/xi8+v+r+uhPQV7tKnr1f8 lL+zuOpIQ4/T9hCBVdvWM8LTcvyuE05tglUerIvmpzT1fR5i0DRUO7xmjLhecbJF9JPPqx84HJ9X YPk+8NMDeXtGvWssqfa44rEuNZ17Zomo6oSiRdOk7mpSt0ukspEEdnNW6ew1m3gnHNcTUx8sXDh1 WU6SSDQjMzPRtK5voijLuNiveT0W04yW6Q+mJX9N6wCb12kx/jkj2/L48pzEjKzE9Gzyan7/WzhM SQlmhcZFyTDEqCQFhKTJvmUzjE7HEJSiGiU6bjVO3sLmDg9aFzZPlqr432q7xicQJOQVq7U6jUqe bP1OLHU+Qg7F5y9NLXaufZKUVxw7dYplx2jj4+qRpVKpvBxJ26NVdehsK5l1HOWGjJQGTwkhc7LW 4WUlXcbHFbt2jnAs+/euw6P31kF4uy+3dCRtz6uuscTzR1NGZE6lMuucT7yM+liMv7FduKho+6Gj 3GnHmCOlikjOM8OUF5l3Q5iROUq3D1syrhmiLJKYzVie9dGyZZ7/IQTC5+xSKUxJ0aMpFppzAbHK 3Jx1teLU2GguaxDExCVLah03SwlVXqx2bt1Tz/l2PEaazHtf7Bj3Ox7jXyX88IvP73juhPn08u3K /HV7ZI0treyY35PSNWA4b+EW/07IMVJrl+lRCzO5GSRpXr2lVSlLS/ipFKNWxqXvjMstcThil1i+ N2rJzoSNtcUnLWNQrXSkqdTygx5XnQBwL/ew2u+G523XWFJrypEYibgk1qlfxOXujDJ+1065ZSE6 trayNnljnVxt+XtTpZ/zZhPnbTrVr0/fuHkUMiV/DvOk1gxRTiJJ6tIyyWDD/4dwyKME3/1lTP79 wRkjSTCvRJliarcaUazrXCEur5Z2qIGgU8Q7lzzZP2jZwjiuwNVkgVYijHN8a6JixQrMSAWAQ/G5 MKfs0PEThrGag3KmZ9mHfvSvJkQqM5du9bfEOn5ps7TH9KWeY9G8VErb4Dj75PCCtQa72EaeSq1v QqMFPxWd7PK34XndNSyp1GDqEvevZp25km2R2l6ky3TG6Ff5NzEVlbNHx7AVh+upJ1EeJ6+ykpZn /t/3iQ5X96g0BjBiFJYCa1P9jyLPlifECvOkkoLkONs8jAi1QCaMViUvlkqMpHKFCrNRgTKSlc9H ibBK5c94kakw5+FyqdT5q9FihbxJLauUR9mlUo41UfZHUUFTl0rdpVT3mdvbCFOpa9J3NfbQf3sh RLX0Mzdnloxu1/AilYoWnzA+xaDmZ01xpebvc07VvDq+qDxJvntHdQ3tfGn447EfZtpVSc1/kVZ7 AOvKk6brU9a0ylgLJFZyz6kVWR+OESGXglHlsPJ5n47yQnOV7bprfd+iJUbaYvruQVtlrPvDeoHv WELunoRVMrvjp5Iox+dvNn+oH2EqtfDAKSziByPxw0F/rvH50DUsqRQr3SKLd+gXq2Rx6aYrg0tk knpVcVUt/z6OArXp04Zfs1K/TNtepjZeQ99Td3DYTOabFT8tWLX2h/UbRZu3rpDuWF1SulFWvm1f 1e79dRWH62uPNh5obKpuOCqvV5YfOlx2ULH7QN2umv3bq2qK5FWbKyrFe8pyt21fsm6D8Md8P/Ko aaLMcxe8zuVRty7+yFRnlZ0Q9LcchgqdSi4WiyVisUyp8fwgYbmYFSVUnz6tthZNOS2dpLRe/4op xjUBGE0Oxed56yjP+ZF8I7O+Y+I8iW/jxRbTeDGo9uZzsceyc1bkOOJI5SNOpV7atL+pVz82byCE K1U/83qRwudUyvuuYUmlXGNO1rn6Lqn4pKU3Ncl8rpWaMHfTssPt5prM7t6+r/J+5PKW7/ILl0u2 rNm9Z1dN7f6jjar2dt1gICd1DSzb2dN7/JS6rukYSbq2VMjzdxYvXC2e6T6V+mPal/wpqSnLFnFf au/uDmBsEUueYrkkFyWUeX6Qy5FiUowreMuEluLr5GLHInOu3DpFjlwKRterH9uKz5/5J/3l4wfY oTk1LePn+rALnl+pFKvt0Wn7B/mHrr892XGxHekIZ6Ue+qm8rC3wa3BBBKps748u9G2tTj9SKWZw UGPfL7SDjLKqwuH5CbuOcYOT9mR9tC9RkWPcnI1fV6n6GFtlZmdPj7z+yClNp57efeyDDHNC3VZx uH59mWzpRsmXuZYFr5JE2T9L+adtp5jv3+dnWac6O2kFHE7kKZaMKDpF7vlBnUJkfjDPePma2/0k 2imTOt0kTrBMS7nYNgUgkByKz+uOUCs75/To2ZQDp86c7+3clGW8OK1LcVXmEZUpl+w/JpFV25ed e66VCkwq9dTaqtJTyKMgYPa29ces93zHhL9dw5uyc/N35dYqe7izBCMr9XldqYnzNpGPS52DLk41 jMHg/CAt7NBQe3f3gcamhE15/Cmp19LnI5UKOFWxKC42Li42NkXS5PlBa36VYHrI0568ulpL0hWT glQKRlcQFp8TOgOb19B5Q0axVyfndMsdGvItLmprE6rMCxq0x/JTqSYvxyM/U6kJczd9VtZUqwnA fjoAfAe7BhLLj5NsJMBdw5pKOV3jtj9yFdx41VRfH+v7kum/Tt+ZrdTw56P4BoNyacX/zZ3K5VE3 pH34XX4hUil6VMnmVRCExaa/Nlkv4sUrnC6q2DbzRSoFoy/Yis/NhoaGik/1xe8+6kXp1B6F+bOs izu+ZUrTl3QnLXUm3i2GMKJU6u7cPdnKzm49/fk9CEs9DJvb0Hn/Sm9WDvG6a3CzUp5SKeurDWpS Mn1Oos6Yt+ndXcodLX1jv2bdSGxtquFPSRXWG4t2Tmk699QdzC6SfpGzAqnUWGKaCszZkWW7E21t fJTlNj3n8hSkUjCWgq34nI+MGvlN3S9s3O+5eip2l3Wz4K6W5HTrOoTpcoXl8hortu78Yk6ldC31 MUuksZk7HY6YJQ4bxPiWSl29dOfc2tYazQDu14PRdqBrcMGBU9ctH+aOV2+7hnWJTvGqndHpjv0i NlMaNWdj9EbzhhRsQe5mQUpRTHpR9BLTkS6N9jg9NX7uxmfX1fx4tCsUP188XvgFl0fdKIpnh+x+ BcZgGNDjppKxU2tZizNeaRmmNNZaKcftek8jlYIxF2zF5w5O6Qw/NXa9se2Q++XQi8QttgxQ29Wn 6rJdqWziFc163jjm9GCL/T3d3t7BF5WzJ+XAKVmbjkESBWPFMDRU0a77vk59zwoPBUvedY1hNo4h XUCaUOX+KY4dx3Kck7Ll1a0HVx7tau4PoiIo71W2NvCnpNL3S2lHFOHU5lv6ohK4fwhbrZTcqXly qVRsaliseQ5BLwiLz51p9WxRc++ig+o/iqvPclWULqxUO+ZJhj7JFrssyPN2xqd7TjikUsWmFaFd lpqQ49rlu6bvPU7SvMMkOCRRQANpeEd69AWN3TMqjrsrLxy+awyznfFp2Uap0EPfse84E+dJnlxT RXK8Lc29XSE4E8WZtGE+l0ddnvavAQYTUFSpJOareUKZ7f5R66yUoEDp2MblqbHWxRBCe5FOjaK4 oKBA7ILxYalMoR2dS0mMRiFKjo81Vv7HiY1vr6bY+BMLike244zS9CrkP7Gsafhne00ll+QVFEj8 fU1GpyU0xAjezeAsPndpaGjolI7deLJnbm3rIwXy8xZudfgMHi+Wp2ypTpFWC1c5L7kZgGP83I3X LS/+59YD38iOVGsGBllkUBAUSDa/v3Mwr6Hz49KjN4hKnK6Jj3rXODdly+/yK76raVl/oqel3xDq l7mPdLaMn/8Kl0oJK8S0I4p0SssGMbH8a3nWS36WTWR4NNZVqVzc3BdauPW13ItOLQ5kWkIw1sTV TEjSUUZujsN+mS9fX1fB2w4wThmwJFAtNIcbLyF/UYqFJAGMd4FkhSkOSbdGKU2OtXuHo+NS5Go/ IxMuDcbicw/Ih/FWHbujtY+MHeTsPXlz3VXpI90pz8MY8dBPFQmyY0sPta880rZoZ8WXKwuL5FW0 3wMAF3TskKJ7kOQzpLlO23v84fwKp08cATt+tXTnXzcdmF3dktvQub21r1nHhs30bFzRUi6PumDx P7oGPE5owwjpNKomIzV/TsDuQesEVJyYP8gxygJuXOanWCqpdRX00N84pjbVzW7N9pwXKR0J3s6G UdExcZIm5rQuAKmUbXV6kxRZgFZPVYmjeC8oE3pIPqP5qbXSuviYkyix0zynN4K5+HxY5POvlhmq 1gysOa5dfrhj/v7WxPLjL28+eHdu2RVp2yf4suDnBd9vvVFU8sSaqg+KG76tbv5B0bbCOkborRNQ eoOhub2D7q8M4A2GHWoxfeJYebSTNGZhdcuHJQ1Pra26KXP3hd/7kF+Nn7vpstTtd+WWkc8sJD0j XYx0tDXHtPKOgW5mKNQnoJy19nb+z8LXuFTqs5I82hGFuVrrhbooodz1g5pi8+iYLFXZfytXLkUG yYRipVqn08gLkm2Ddegvdc6lUskSpU5nughlplbVFhfE2SaP4gM3yWN781O5OkpGLckTEZJav3M2 XZ5DVhgvDkjI1hlLczrNXfaNcsZPufkzb1GxQqm8Vi7lBRid6l/TCfLic5+Qj8YD7FDXIHtUOyhv 7y871VvS0rNDpS062SU53rWuSbP6aMfaRs2GY51bjndJT3bvataWtvbubeurOK6+8Tc3/+PNtxhc uYNwRBp2n2HolM5wsFNHGjxp9qTx/3fekot+ccm8dVLSKUjXIB1k0/FO0llIlyEdh3SfyrZ+pXaw c5DVsUNhM+/kwdSSFVweddbC2ObekB+OgxyXLfDvtuM/2CS2bBfj4mqdSupuDiIqQRJKkwJucO9D qsuiL63cOn8ULQ3cvJTCcuU0VjH8c72mcf6XcnG/gB+va8mdLIlZk2XxsWHu3GQklqU0BNHJvHai q7Xu3hglVvnTfEKi+Hy0nTp1iryD48ePJ3+gHQvAGLn55ptJsy8sLKQdSFDQDvZftMS2U8yUoqW0 Iwp/ijzL8BUrqnX5oGUL47gClx/ytUpJHL+yx/xdQnF4ZMC1tvp5l7+QbV7O/AS1rCCZSCG/PiMv EMYYp2KiRLybdDXKYmF8rHWeJjouIUWqsCVhjFouSk2Nj+bexlRRqsi0WopaTL6QmiqWq407HeSl JAsJ8nPssy1NbQr54SkpQmGewyUy7qJhgrhWnGD5B0uQuKjy8ml769NqS4ZmucSpk5vfD6cJTHvW eU7yRIcIFNapKZHCnzwvhIrPR9W9995L3sPly5fTDgRgLBw4cIA0+LPOOqsbO/OazK5Yx+VR4+e/ cljTTDsi8AajUsilEiNpsVylCYPpKAtfUynb3oUxtvzS+r2MLJVX980TnSwxJz5aeYrzV5NltrLz aFOtFK+Yin/7pK6Aezg6xX6SzFoZLogu1pJExnoR1lUxmy/bW5/mZizNE1w6a/mcSOGpDWhklqot pxsWTC9i5H8TCrni89FA0nnjv0pMDO1AAMbCrFmzSIN/7rnnaAcSFAYNzC+XvsOlUn9dP592RBDp bBf4XC7/ppZaM6kYcxG3qzL1qDzTBAt3w6Px2fHCArE4JSHG9ohp32ddkzQhPp7LwmLiEhLik4tV xtke8zdbL8JqbS8WLTRnTSopV6XmeLVRp8izfCU2z7RSttz63VESp+uS3m9vbau/Mr8sbz0xYV6e MD42JtooJiYuJa+Yf1ue9V2Kkqh06lppqjAhziQhOVVa63E6ywshXXweKNXV1eT9Pffcc0lWSjsW gFF3xx13kAaflZVFO5CgsGz/dv6ynOUtStoRQaTjUqMEscJYa65Wq1Wm/zUppAW8e9ViLGXSXJJg zC+EElv+oJFZnxyVKrNlC03c3Y6CWLl10ONqpWq5b9c6pFLGa2RcHhabpzzN1HJ/TZA4ZiPF1u0S ky05FiO2lio5zwt5v731aa3Msr+19UF+uugkRmy5ZmebPYuOcVFqFxWX2jSy8T+cis/9dvXVV5M3 c/369bQDARhdR44cIU39jDPO0GjCo65kRNgh9jeZH3F51GMFX9COCMDbxRDyrDs6c8+PSpDwX8d6 m5uL1EUmtCRB3OoE1hfh1fk7zkoZqSTJjnEIjOXfjqmDbTkp27JgGm5hhCih3/Xyass8WHSx9QRm mbyKMpeexyYkJ8fbLRsVLVVb19aI4hfYRZE0LYb/wMiW0UDxOfHBBx+QN3LKlCm0AwEYXV9//TVp 6k8//TTtQILCqvq9/CmpLU01tCMC8CKVioqTKLXOz7cv+7YtRJCnUOs0PFqdUmJZXolLk7hUSu4x lbIrjrJwsR+i2loZxdv0x5hfcb+YY4W6txhxnEPao0mxpkNCiS1j1CqltjCNS5NpC8xzYqZsKjZF Yq2tY2r5K2mMYNkrFJ8TRUVF5G284oorwm/BHAC+e+65hzT19PR02oEEhQdWJnJ51F25n9EOB8CI S41iU8RymayYTyqVKxyvRFmfb7taZ8JbgMs931Mp4+oB/GQq1UVtvN1yUtHR1lsHeVNA0f4t+6mr Nb9wXIHtQrxG1aRUKhRNjmHwV3NV6GyFXlFOa1vxirJGsK47is9Pnx4cHLzgggvIOymTjeidBAhm x44dI418woQJanUg10kOUTuO1/GnpFYeKqUdEYARr+zcq6kbF1mQka4g3mnBCCfczXF+p1Ii59p4 tduFv3j8WV/UehdelMSrBaC4pTtjZFrb7o3Oq3VxheuOv6mPHIrPV6yPxOLzyZMnk3dy2rRptAMB GC1z5swhjfyxxx6jHUhQeHr1N1wedd3yDw1sJNY2QBAabjEEd893SKW0qda1BCRNGq3Gnlars2Dc voibC3xi64qWXFLksAgBt2xCVGxCampqig35m5CbKvPjapokwbIWJ/87GRNXT+fm5YwFYNzUk4v7 IlWS6ECkUqdRfH76dF6e8c7N22+/nXYgAKPloYceIo188eLFtAOhr0bdxJ+SWlK9lXZEABYBSqV0 3B4zXIG67WtKSXJCcnKCUKbyLZXirX5gY7/IvCrZOhlW4GrLZVslmK+byFhL2fnLunITSvFipx9m mz2LI8ketzNOgtMzuSWnRniB7zSKz8mbqdGcccYZ5M1sbGykHQtA4DU3N48zUalGuohKGPjbpoVc HnVJ6pR+JhJrRCE4BSiV4paytC3BZKXhrnaJHG8D9JhK8RZDSC7WnFZxxUgCoXVvZZ1CZE2wXN+m xzRx3xXL+1nDbm9ty5oKmmzP4R50WiD0tMw6DWXO2XRuNsLmvxvCEe8QjeJz4rHHHiNv5oIFC2gH AhB4CxcuJM37d7/7He1A6GvsUp+x4G9cKvWlbPVo/BSNorigoEDsgvFhqUyhHZ1KCkajECXHxxoX 5IkzbXavKTb+xIJihU/XUxiFVOwy/IK8vLwCca1Tla9/VHJJXkGBROZq/sKbKHVawnTFKnzqUgKV SvFWJBBEx+cpNaatf1Vy2zU23ga+XqRSvCU6rbkZd9WMy4uk1uWkYvPc7ean5tbG4lajGn5769On i83fFpVs91GQUdquN8YKZUqVjmF0mqaCZFvNvXVSjleHHxUnqTU+U6uuTYm1TqKNYIkGPhSfkyTK 2Liio2kHAhB4jzzyCGne8+djNe/T70kzuDzqvEV/1+h6RuOncNteuBedWuxnCuEOo5LwS42Fctv2 H1G+3TOlTRmuZjk6IW/EQ491b5F444JISrGQJIDxLpCsMMXh7nmNUppst3yQIDouRa4Oh4TK71TK eetnjSxV4Fa0lFe87XJdKXPqYU6llAXxtm+0/cPbLucJ4gq01jvsPG+1bFtU07qmwbDbW5OUKcHp CWZqmYuNbzixqbxmry52v8xElNjP9RkcnWiJ9OLzhoYGgWn1ws7OTtqxAASSWq2eMGECad5NTQEe u0NOW3/32Qtf41Kpj3dlj9IP8nKhxeQRX1Pg422UFhUdEydpYsiA6F8q5c2t9CQZHFH0KrF5HDZX IMuEHpLPaH6eoBQnjPaASJFCZPlHdHFznKfnxzrdmmbkcutnQUyyzD7ttL4I7+KXtdbIWJvEm/yJ L7DbEUCnzONePnPjUsufYvM8hM5L+C0/btjtrbm7Ap3rvk4bZ4Al8S7aTozI+aOKTpka5/TUmASZ V7cEegvF57fffrvxHysvj3YgAIGUlpZGGvb9999POxD6kkp/4vKoiSmvntC2j9IP4lKpZIlSp+Pd QaVW1RYX8EY3f+4Kd/9DnW5TYtSSPBEhqfUp6+FSqWipSsfoOFq1SilJsd0NLxzBqobW5bjN4yl3 u3qUM/4Qz595i4oVSuW1cilvHSPeRSuw4rZ+lhbL5EpVeL5DGpVCZlp6i/yeslqlh1xOq1LKyPOM z5TKlYFfGQbF59OnTyd9cfLkybQDAQikJ554wjjqCYW0A6GsV6+7eMmbXCr1xpYlo/ezbKsDuZ4s kHN7gnm4FOIrbic1d3UqXrPdSO4yfG6HtWj/7x+3lvta7uRqSo7y5gUZiXW5pOhk3o1julrrtEmU OKAzDAC+cig+n/pdxBWf7927l3TFCy+8UK/X044FIDA0Gs3EiRNJw66vr6cdC2Xz5Ru5PGrc/JcP tp8cvZ81XMWL7Qqa+QlqWUEykSLWnGbkBcIY41RMFP8Sj0ZZLIyPtc7TRMclpEgVtiSMUctFqanc ZY5YYaooVVRremEx+UJqqlhOnszI8lKSSUotJD/HPtvS1KaQH56SIhSa9/QYJpXi7h/n167oVHKx WCwRi2VKjecHjayXbCyXOK2VOclSj3eYaoqtv2Kyw8UbhXVqSqQYyV5qAAEQ4cXnQ0NDl19+OemM W7dinRkIEyKR8fbku+66i3YglOkNzFXp73KpVIz4u1H9cb6mUrbdK3h7rFq/l5GlOu58xs3MWG5P krsovk2W2crOzVt18IqpBAW2siLexmqWm8qHm5Wy1jXF8W7U4irt+XVZLh88bbtV3/L63L3qIoWn OSUuhXPeotf4Irw1JwEoQvH5lClTSD99//33aQcCEBh/+tOfSJP+4osvaAdCWVbdLv6ynHtUh0f1 x/G2/3CVi6il1kwqxlxt5KpMPSrPNMFiu+OJPDteWCAWpyTYisJjUo3zQromaUJ8PJeFxcQlJMQn F6s83tIebbn7m7fuIne10W6laD5Gp5HbdoCNLubliby9zOSeH7Rt02a9rZ5bIEiYlyeMj42JNoqJ iUvJK+bXR1vfpSiJSqeulaYKE+JMEpJTpbVYMA2CyLDF50NDQyWVhu+zw/MS2Pr160lH/fWvf007 EIAA0Gq1Z511FmnSdXV1tGMZddrB/qW12wYYF6cmcta6LesTLo/6/U8zRzsYLjVKECuMteZqtVpl +l+TQlrAu1ctxlImzSUJxvxCKLHlDxqZ9clRqTJbttAkFVpfwraPLVcrVct9u9bTQouxecrTTC33 V26dH/s7+BwqwG1S5XZlXqpiUZxxPavYFEmT5wdPa2Uxlp9oeZCfLjqJEVuu2dlmz6JjXNyyFRWX 6rjXLwAlHorP2zuHFufqH/yrsZ7qj2+FZ5Pt7+8/55xzSK+srq6mHQvASJl3RLrllltoBzIWjnS2 kDTpirS3vy0Xdw/08b+0rqGSPyW14ehIN9salpeLIeQ5Ljdt3IaD/zrW29xcXNKSWRdb5LYzc7k6 kIvtPyQutv8QxIt553SvFkNIEBX7NwyoLfNgtkkty+SVOVWLjk1ITo63WzYqWmpMLk13+dmlc1Ek TYvhP2BdqgiALufic/M01L8SB678nS3FeuLv4ZlKEc8//zzpkcnJybQDARipv/zlL6QxJyUl0Q5k LJQ113PJ0gWL//FZSV5Lr2WNuId/nMF96fbsT8g5bbSDGT6VioqT8O7Y5p6fZ7cyko67zz9PodbZ 7UirU0osyytxaZL3m9IWONZeOeymYUulYpNTTXXrFsLkBH7qYr//mpcYcZxD2qPhVgQVSmwZo1Yp tYUZJ2ZOawvMt++ZsqnYFInG8rOZWts1R3/2yQUYDfzi86v/r++BF/v581Tm45FX+2mHOVoyMjJI f7znnntoBwIwIn19fRE1xbq+Qc6feiLHWQtjpxQtXXmolP9g9sHiMQiGS41iU8RymXHBGxupVK5w vBJlfb7tap2JV7NDvqdS/M1ejVIda+O5n8u7VsijlHCXF/nl696xrokdx1vsUaNqUioVCqf9aBje 1mkKna3QK8ppM1xeUdZIN6UFCIjjzQbn3MnheHhy2KZSp06dGj9+PDZ+hVBXUGAchq677jragYwR 0YGdDqmU83H1svcY1jAGwfDKzr3KNNzspKYriB9uBxfezXF+p1JOC2sPcwcfIU2wXIDzcn8TjvUu vCiJVwtAcUt3xsi03J9drNbFFa477y0CMMbaNLZqKM/HfS+EbSpF/Pa3vyVd8ocffqAdCID/Jk+e TJrxZ599RjuQMfJd5fphU6l3ti0bm2ACtCmtNtW6loCkSaPV2NNqrYuQM25fxM0FPrFtF1izePtF CIZPpawl7j6nUpIEy1qc/G9jTFw93e5eQm7qycV9kSpJNFIpoMpcDRU33a4ayvNx93PhnEp9++23 pEs+88wztAMB8NPAwMD5559PmnF5eTntWMbI1JIVw6ZS5Lg7d+rKQ6UGdnR3cwhQKqXj9phx3n1M p5QkJyQnJwi5HcS8TKV4qx/wprbsqp7cLobAvS5XxOVbbRKjsO3sxv0w64RSvNh50zRu9iyOJHvc zjgJTs/klpzCBT4Ye95PQzkctz3TN/yrhyyFQkG65FlnndXb20s7FgB/iMVi0oavuuqqMSixDhJv bU3zJpUyH9ct/3BJ9dZ+ZrT2dAhQKsUtZWlbgslKw13tEjneBugxleIthpBcrDmt4oqRBELb3sqe a6W0Uts2fNFS7jqdTqNqMlJred9j/yCXNRU02Z7DPWhdINRGZp2GMu8vo+OVTtlfOLW9G8KA7hAN 4I3VWxhfkyjz8ZsnwzmVIm644QbSK1etWkU7EAB/vPbaa6QBf/TRR7QDGTvPr5vjfSplPi5NjftS tlqj6wl4MIFKpbhpHGOiEZ+n1Ji2dVHJhVw+xNvA14tUirdEpzU3466aGYveLd9oK3ePSRCmCK1S iGT+HXzRvDXMuSmjKKHc3YOWZdKjku3qUBml7XpjrFCmVOkYRqdpKki21dxbJ+V4dfhRcZJa4zO1 6tqUWGtMUUIkUkDF0h/1fqRS10aHeSr1n//8h/TL119/nXYgAD7T6/U/+9nPSAPevXs37VjGzu9/ mulrKmU+Xt+8OODB+J1KOV9Q08hSBW7xJoXcrCsVw0ullAXxtm+05RyqZC47iiswfautwNuDWKGU PzPE/cr8i4l2DzLKBKcnmKllLja+sf2gVN41O3Wx+2UmosS+3k4IEDhf/TDoayp15e/CPJXatWsX 6Zm/+MUv2FGuqQAIOIlEQlrv5ZdfHlGt95asj/3IoyZtmD8a9/QpRJbJJKeb4zw/P9ZlmbdWKYlz vpMvJlmmZly9CO/il7XWyFibxJv8iectRGB8ljKPe3nT/I/W0+rjxo1pkvmbKVt+ep7l5fl1UHYP Wrcwdq77IjQKSbyLJcxjRMXOBVTK1Dinp8YkyLy6JRBgFH309YCv2RTtkEeXwWC4+OKLSQctLh6L VWgAAuitt94iTfe9996jHciYuiR1iq951CubFo52/XngMCqFXEqyZIm0WCZXqsJzIUqNSiEzLb1F fk9ZrdJDGqpVKWXkecZnSuVKXNYLedXKhg1le7mjo7ubdkT+MBiG/v6pb9kUw4R5Oevrr79OxqNP PvmEdiAAPiCfAi655BLSdLdv3047lrEzNDQ0YcErPuVRsZJFoZNHAYSzaenpM0TZMzJzzMfa3Xto R+Q/3cBQzNs671Opfl2Yp1KFhYVkPLrppptoBwLgA/I53XxtmuRUtGMZOxpdj0951BtblrBDyKMA gkISL4/6dmV+38AA7YhGpLtnKDrW24URyJNpxzu6tFrtmWeeSUYlhcJxI1GAoPXuu++SRjtlyhTa gYypek2z93nUlKKlkbNGBECQS1yeyeVR5KhSNtCOKABOtQ/d9xevsqn2zvA/Fz399NNkVBIKhbQD AfAKyRCuuOIK0mg3b95MO5YxtUd12Ms86h3pMuRRAEHio3nzZohseZRo81baEQXM0ePsbc8Mn0q1 qMN/enzJkiVkVHr44YdpBwLglZKSEtJiL7roIr1eTzuWMeW8l7HL44PtItqRAoBNYqbt0t7n2Xnt oVlt7k7tIfa6x4ZJpY41h38qdeLECTIwjR8/vq2tjXYsAMOLjzfeex6B66F5s5fxRzuzaYcJADYf LVuWxJuS2lFdQzuiwCupNFz1e0+pVMPx8E+liHvuuce4OIxIRDsQgOFdffXVpLmuW7eOdiBjbdi9 jD8tzqMdIwDY4V/aS1ktZsL0Tpn125nLH3KbSikaIiKV+vzzz8nY9Pzzz9MOBGAYe/fuJW31vPPO 0+kibs1nz3sZT9u9knaAAGBn+g9ZSbxqc6WqmXZEoyhzldttZfYfjohUqqqqigxP5557bgQOTxBa Pv30U9JWX375ZdqBUOBhL+MZe/JpRwcAjpJ4VVKizUW0wxl1c5a5zqbkB8JzLs7ZVVddRUaoDRs2 0A4EwBPzHtyFhYW0A6HA3V7GX8iwIzlA0EkUifgLIJyMjGrkqd+52KRvb3WkpFLvvfeecV+ruDja gQC4ZZ4+Pfvss3t7e2nHQoHLvYy/LRfTjgsAXOCvybly+07a4YwRlh2aMt1xW5mSykhJpbZu3UoG qV/+8pdYjgaCVmJiImmlL7zwAu1A6HDey3hO5XraQQGAC5+mp3N51MysXHVXF+2Ixs6gfuivH9ht K7NDFimp1ODg4Pnnn0/GqfLyctqxALh26623kia6YsUK2oHQ4bCXccq+TbQjAgDX+FNSa3aX0g5n rPX2DT35hi2b2lISKakU8dJLL5Fxavr06bQDAXChrq6OtM8zzzyzO7wWuPMSfy/jcfNfXly9hXZE AOBawqIsruB8ZmZOe7eWdkQUtGmGHppk2VZmww6GdjhjJzc3lwxVd9xxB+1AAFxITk4m7fPPf/4z 7UDo4PYyJnlUWu022uEAgFtJGbYpqfydxbTDoeZYMxv1Z2M2taYoglIpjUZzxhlnkNGqsbGRdiwA ju68807SODMzM2kHQod5L+Px819Zvn877ViCGsuypQfqtsmrzEdjyynaEUFkiUtLm8G7utfc0UE7 IpoOHmFv/ENf/qYISqWI6OhoMlqlpKTQDgTAjlKpJC2TpPodkXpe2qM6TPKorLpdtAMJAVVHGriB LEmEnXRgTCXy8qjsIintcOiTVRtWb4msVGr+/PlkwHr88cdpBwJg59tvvyUt88knn6QdCDWbjlbl KXbTjiI0GFh2Tv4qbjibhi2xYAzxC86bWltphxMUWDayVgYwf/afOHFiVyTduQnB77777iMtc+nS pbQDoYakB7RDCCUl+w/YJqYyMTEFYyQpM5NreGkbcI9t5Lrtttsi+X5zCELHjh0jbXL8+PGnTqHu BbyiGxz8MnelNZXKicfEFIwJ/vLm1coG2uEANQkJCRG7xxkEp3nz5pE2+eijj9IOBEKJpLySVzGV RTscCH/TeMtyfrsynzFE0GJK4KCsrIwMWxdddJFer6cdC4DRww8/TNrk999/TzsQCCUd3VrbFIEo h3Y4EP5Ixs41uSL5PtrhAE1DQ0OXXXYZGbm2bcPaNUBfc3Pz+PHjx40bd/LkSdqxQIjJ2LzVNjG1 DBNTMLqSRLadYjp7InGfUOB76623SCr1wQcf0A4E4PSiRYtIa/ztb39LOxAIPTUNRzExBWNj+jLb lFSedAftcIC+devWkcHrmmuuoR0IgGWts7lz59IOBEKP3mD4esVP3ABHGhLtiCBs8ZflPHT8BO1w gL7+/v6zzz6bnHZqampoxwIRra2tbcKECViBH/y2oWwvN8BNx318MDri0tK4Tfe+XZmPpUvA7Lnn niPj1xdffEE7EIhoS5cuJe3w3nvvpR0IhKrGllbefXy4xgejIlFkWwNho6ycdjgQLJYvX06GsPvu u492IBDRnnrqKdIOv/nmG9qBQKhih4Zm/1iAVApGVRJvOSlVezvtcCBYtLa2mm+bam5uph0LRKjO zs6JEyeSVKq+vp52LBDC1vOu8SUtRzYFAfbRvHnc1b3v16yjHQ4El4ceeoiMYqmpqbQDgQiVmZlJ WmBUVBTtQCC0HW1usaVSGUilIMBmZNju3Suu3U87HAgu33zzDRnI/vjHP9IOBCLUs88+S1rg559/ TjsQCG0sy36d96P1Gh/244MAm8ErlGrv1tIOB4JLXV0dGcj+53/+p7cXS43BWNNqtWeddRZpgaQd 0o4FQt7K7Tutq0tlv4H7+CBwHp01i1sGYdHa9bTDgWB0/fXXk7Fs9erVtAOBiLNixQrS9n7zm9/Q DgTCQfmhw1irE0ZDYoZtOSnpvmra4UAw+vjjj8lw9sYbb9AOBCLOiy++SNre9OnTaQcC4aBDa9uP LykT1/ggYPgrczZ3dNAOB4LRzp07yXB2ySWXsFhwDMZQX1/fOeecQ9peVVUV7VggTMwvXINyKQi4 GdZ79+YV4vINuGYwGC6++GIyopWUlNCOBSJIYWEhaXXXXXcd7UAgfKwq2c2tLoUdZCAgPkuzTUlt 2ltBOxwIXrGxseS089///pd2IBBBXnnlFbQ6CKy9ikPcqJeAynMIhCSRbRmE+hMnaYcDwSs/Px/V vzCWBgYGLrjgAtLqZDIZ7VggfJxsa7dtxpeRRTscCAdJ1kKpz7PzBhmGdjgQvLRa7ZlnnknGtcOH D9OOBSLCunXrSHu78sorh4aGaMcC4cPAssnZeSiXgkAhpykulcqQbKUdDgQ78z5os2fPph0IRIS/ //3vpL39+9//ph0IhJu0DZuQSkGgJC2zXd3bVYNFzmEYixcvJkPb7373O9qBQPjT6/U/+9nPSHsr Li6mHQuEmzW7S61jH1IpGKlEXqHUyTZsYQzDOH78OBnaJkyY0NbWRjsWCHObN28mje3yyy/H+hsQ cCX7D1iXlsr55DtkUzAiXB71dd6PLKoRwAt33303GeAyMzNpBwJhbsqUKaSlvfPOO7QDgTB06PgJ bviblpFBOxwIbdzinNlbt9GOBULDrFmzyAD3wgsv0A4EwpnBYLjkkktIS9u2DacmCLz27m7e9jGY lQL//Vck4trSjuoa2uFAaNi3bx8Z4M4777yBgQHasUDY2r59O2lmP//5zxncVgyjwMCyM63DX6II 6yGA/2YstxVKKVXNtMOBkHHllVeSYW7jxo20A4Gw9d5775E29uabb9IOBMLW7J8KsakxjBxpP+aG RJJz3eAg7XAgZLz77rtkmPvXv/5FOxAIT0NDQ7/85S9JG9u0aRPtWCBs/bB+I9ZDgJFLsm69t2jt OtqxQCgx31pFBjssnAijobS0lDSwCy+8cBAf8WDU5G7bjlQKRo67ure2tIx2LBBKyAB3/vnnk8Gu ogKbNkLgffTRR6R1vfbaa7QDgXC2bo8MF/hghKalpXGpVNlBBe1wIMRMmjTJuFR+UhLtQCAM/frX vyata+3atbQDgXBWJN+HWSkYoRkZ2Vwq1djSSjscCDE5OTlksIuKiqIdCISbiooK8y2iOp2OdiwQ znbV1GIxBBihpIwcLpXqw13t4KOOjo4JEyaQIa+pqYl2LBBWPvvsM9KuJk+eTDsQCHNlBxXcIEg7 FghVXM35d/mFtGOBkPTII4+QIW/hwoW0A4GwcsMNN5B2lZ+fTzsQCHPy+iNcKvXRvHm0w4GQxK2E kF0kpR0LhKS5c+eSIe8Pf/gD7UAgfNTU1JBGdfbZZ/f29tKOBcJc7dFGLpWKF4lohwMhKcmaSm2p kNOOBULSkSNHyKg3ceLErq4u2rFAmEhKSiKN6i9/+QvtQCD8HWhs4lKpz9LSaIcDoeejZcu4JlR+ 6DDtcCBU3XrrrWTgW7lyJe1AIEyYW1Rubi7tQCD88WelkEqBH6Yvt92+hy1jwG9Tp04lA98rr7xC OxAIBwqFgjSnM888s7u7m3YsEP5qGo5y4+AHqPkE3yUtz+SaUIdWSzscCFV79uwhY99FF12EPWdh 5L744gvSnP70pz/RDgQiQrWygRsHP12+nHY4EHqSRJZZqZlZuQaWpR0OhCqWZS+99FIy/EmluHkB Ruquu+4ibSkjI4N2IBAR9h1RcqnUGyg7B9/NsKZS8wpX044FQtubb75Jhr9///vftAOB0NbQ0EAa 0hlnnNHR0UE7FogIe+oOYl0pGAluVkq0eSvtWCC0icViMgJee+21tAOB0CYUCklDeuKJJ2gHApFi e1UNUikYiSRr+yncVUI7FghtfX19Z599NhkEa2traccCIez+++8nrSg1NZV2IBApNu2tsOzBl4mN Y8AfXCouKa+kHQuEvGeffZYMgl9++SXtQCBUHT9+fNy4cePHj29txX6gMEZWl5Ra9+DDrBT4g0ul SvYfoB0LhLz09HSSSt1///20A4FQtWDBAtKEHnnkEdqBQATJKZJiVgr8NnXJEi6V2ndESTscCGGG oSGdYUhxvFlgsvWYpriT3a5ht3awm9rZdW3s6jZW3MZubGe3dLBSDburk93TxVZ0s4d62bZBtt8w xAwN0f4lIDDMjaFjkD3Sx1Z2G/+hvW8M0U88SdrP/JQU2r8ERJBFa9dZUikRUinwWYJIxKVSR06q aIcDIYMdGtIMsrIutvAUm64yzD1u+FTJvFDH3F6pP/uVeMEDTwp29AtK9N4cP9ujv6VS/+f9zMdK 5rtjhqUqw0+n2N2dxvzKgOQqFHhoDL8o04/zrhlwjeHSD7+5+J7fvytXozHAmPkq70dc4AO/8Zc6 b27HfcfgCTM0dLyf3drOZrUYvmoykOTnUpkPo6RPBxlSH6/Rz2o0ZDQbJO2sso/VsxhJgwgaA4SN /sFBbhxMwh184LtE60bGWOoc3GGHho7p2NVq9ssmwz1y/Vm7R2vEdHdM3K2/rVKfeNSQf4qt78Xs BE1oDBB+Wjo03Dg4Y3kW7XAg9CRmZHFNqKdfRzscCC7qAXZDGzv3uOG3Vfrx5rHsgzln3/7AhOnL AjY45tQKUku8PTa23inXf91kWKNmT+jIqI5hdOygMUC4OtDYxI2DiemolQKfcetzkmMQW6eBCRmV GvrZrGbDs/uZM83TDqsaBY++eM/9D+zatctgMAwODopy8s6Nnzvy0fPCrepPCrftqpBX7ttXOZwd pWXm75pQon+0Rp+uMhzoYdn/Z+9O4KOqzv6BBypara3VYq22Yt1al0p9xbZW36pYX/9abakKrVXq TgQUiYBIlgkhLBLClsiSSDKTHchCSCALZCP7vu9kISH7wiRMkpnMyv+Eydy5mcwkmeQmZ5bf93Pq R0MyeTLccn6cc+5zMYfOJlwMYPGSikqYM+e23t60ywHzw+OP5qit2CCG67qkI/PmX0pYc9zbazdt 2tTa2qrzF38yjUZGn7nzM2eb1OEZzqE3Z8o+r5endg2KhsQTLy94ZJSzv/D3BTLvNkWjGM+OnBW4 GMAahCSloBMCzASzKrUj6DjtWoAyuUoV06N8t0quc8vVQ/my8rZuQ5OaUqlMTrnwwCebbRJFM5pD Q+tsfv+/tra2ognP7Mnl8h9n6n7ta2Wy8C6lFEeRuYOLAazHwYhInDmHmSAhXH0J7TkZTrsWoKlX qvRqVdyRbXB2e6ZEVtXeY2gOJR8vKChYsmqjTUyn/ldI6Lc5067/lyIu2Tz14scff9zT02Poxdkb N7FFleNf5JZMmXuz4rIEKxIcwMUA1kMqk2/V3r6HVSmYDmZVal9YBO1agJpWidKxUT6V5YLnSmS1 Hb0TzKHV1dUvr9k0sqqg/pJj2Tavrrzt/t84OPJca67qvuDpyzZ/ePm9994z9IgQ8oJVQ8qni2Q/ zpR5XBL3igZV1z2SKtRbnm2tvHoQE+iM4GIAq9LQ3oHb92CGnAX+mih1inYtQEf3sHJD/ZSmTmYs LZPVd000hzY3N7+z5su/vPTS8ePHycyonvJeq2C9yJl2mz/9v3/961/t7e2GXqRerHyhVM96SFJr X0yz/tmTjHer5HVDmECnCRcDWJuUklImSjngzDlMC48/uiq1H1HKKsmUKvfLCqOmTma8Uia71H1l ijehlw0oR78wptPmuTfeeuut8UeX1VTXOxeNmWqNHJsb5ANyTKBGw8UAVsj/fKKmzzl292CanDUt OveHI0pZo5he5S3jDu4aNV4vkzZ3GjyHrEZ+9Tf51z9/9a7XX3+jubnZ0Oe3DyvfrppRPWTMT5eF dCpm5w2zZHN9MXy2AxcD0KVUqZhHxuDpezBtTJQ6EB5JuxaYa+SPkbUXjdvN0Y7IJpsPHGweWvzq 62+EhoZKJBP1dz1zZXQV4s5sWUWH/rWLHqny/ZrpFjNu/K1cJlFgLcIIuBjACrX29GofGcPH7Xsw TTy/0bNSByIQpaxO57Dy9qzpzE13Hk10DokqqLskkUqV1++ommBI5MofjV3ruDdXFt7UPyyVqcvo kynX1HE2b6rHggxZ2QBmTyPgYgArxD4oxfPBmXOYJuasFO7gs0KVg0pu5yxjx4YGxdeN0zycM+lI FmL2NAIuBrBC35+N00SpABsbG9rlgLliHme8+3go7Vpgrp3rFM/WzPjFHu0t8DTGTRmyMz0y2m+w OcHFANZmUCJhOkrhzDnMhJOmGcL2wBDatcBc86u7wv3MtdZt0cO/zcrKunTp0mp7ZxuXQD2fszvS 5rMdUx3fRkxv9jzbOUz7DTYnuBjA2pTUNzC7e458P9rlgBnjaaIUGXi0urUJret+OFfK2bzJ87t9 0QNnz55VKrWbKWKxOOj4iTs/sdd+WmTTu+++2z2pnt5OYX9mm9DhkuIuw223DQ3yJblXMHsaARcD WJtgzaP3nAUB9odwUAqmj+l2ToZMLqddDsypU3Wd7xYYbG9oxDgQt+Ce+/38/BQK/XedD8kVjxdo Pvl3z/T19RkqieT5Iam8cEC587Li13nTL+ntIlFDP2ZPI+BiAKsilkq3BQTjeTHACZ6vHxOlhiT4 08a6kNlzaXT5AznD0583ffNsfv3Ynj17pFKp3m8hUyr9OhU3MZ/vlb579+6Jq+rt7f3E0dUmoGTa Vd2RJV2e3Nh4FdezEXAxgFUpuFinvXdPgCUpmBEnvnaDTzgwQLscmFNk9rTZG/NxTsethhozxnQu /ff7C97fYnNu3HpFeIPN757ZsGHDgIHLRq5UBnUpbx77yj964FH2PDssV0hl+s8Dd3d3v2/vYhNU buzUuSBDtqqg90ee5zB7GgUXA1gVQXyCZkkq0PEoohTMCM9XG6VaDTyKHSyVevb84cH41YW9hiZQ N7/jCoWioKDgvfVf26w/YJM6bBPbbfPnv7377rs9Bi4YhVJ1slu3fdDIsPeJPH36+ico80XKd6pH PnhTuizoYpehzaCOjo53NjnZnKg2Yuos7rv9cOJNB+MxexrFRC6GYFwMMPuuDg5p793zQ2dOmKkt PtrLqbalhXY5MKfUsycZNx+MX1PQ84tsPaeO50U2DQ0NqT9fKpUmJiV9/sUXhh72QebNiB7lbQYm 4tsCCvKvKjY0KH4w7pd+li2La+hQGngKW1tb29sbHCe9of62LNnaYiGZOslPhNnTWCZ1McTjYoDZ lFzM6syJNggwY+s8PZkrqqiunnY5MKeY2ZOMH+yLfTe1aWnB0PhZaZvP5H9rIxNfdK/yduPvrmKP X+fJcps7DT3W9vLly/+wc7CJuKT3a5/Kl3yS3f7Dg/HqHwezp7FM7WJ4ABcDzA6FUukeGs7kqI3e 3rQrAkvARKn08gratcCcYs+e6vE/x/PXlvQt0jl7fKbd0BkYNbFY/NwnX9rsi53J1MmMJUWy6vYe Q3NoU1PTa1FF7M9fmC1bVdL/wuky9g+C2dNYpnkxPF0kq8HFAJyqbGpmZj105gSuuAQEqS+qc/mF tGuBOTV+9iTjhv2xbybUfVpy9Vc52i0eB+9JjmWSee3KlStBISGPvPWBzd6zM59DXyuTtvYKx3+X Hqlya5OCmTffLxG9m9rErD9g9pw2XAxgJfzOJWijlC8OnAM3mNN3EWkZtGuBOaV39mRmn3+ev7im pO/ZQsmCDJlNXG/jlauiYemk46pEmt7YviKznZNFiQ8rhoSikTUQpUpVIFK+VDbywfnpsqcKhm1L r76T0vjj784bqh+zp1FwMYA16BQKWaekcOAcOMPTXFe+cedo1wJzaoLZUz3m7Y1ZHJTzaXb7qpKr TxYMz+diQpzG+G+NXH3w5pF86Uclos/yOv8UWvCDfbETVI7Z01i4GMAahKWmM1HKiY/dPeCMs99o w/O9oRG0a4E5Nensyd7oeSascHVe56rSq38tktydM3dT58Js2V8KJR+XitYUdC89XXrTuO0bzJ6c wMUAFu/KVdFW/yDmlNSWI0doVwSWg3mi8Va/QAXrgVlg8aY+ezJj/r7YB/npf4+v+Syvc3Vx3/KS wcfzpT/N4nK6vDVT9tt82bLioc9K+lfnd72dWPeof+aC/RMtO2D2nDlcDGDxorKyWQfOsbsHXHJm PYaPhHba5cDcmcbsqTPuOJz4XHjRv5IbVuW02+Z32xYJV5WK3ioe/Evh8JJC2eMFsofyZb/Kld2Z LftxpuymjJGZcWG27Je5sgfzRn71qULZc0XDZKL8pFRkWyy0Lei2ze14J+XSC6dKfuGVPJPCMHsa CxcDWLb+wUHtQ/cEAY58Pu2KwKI4+mqjVEN7O+1yYO7MfPYcP+btjfnZkcRH/DOfCsl5NrRw6enS 12Kq/nn+4jspje+nNZOZ8c2EOvKRl6LKng0rfCok9zH/zJ8fTZq/j+MyMHsaCxcDWLbIjEztkhQ6 nAPXNnp7M1dXQe1F2uXA3JmN2dNEBmZPY+FiAAvWJezbyuolZS8Q0K4ILJCL5iReXF4+7Vpg7mD2 BAYuBrBgQYnJ2h4IWJKC2bHVf3QH+Wh0TElDY1pZeUHtRb0dhsGSRFzsoD7Nzd7sWd8vof0GmxNc DGCpLnV0srf2nLAkBdz5xtvbSTBy+k6d0p3HjazKKto1wuwKrmmnPs3N3uyZ1TnR801ABy4GsEhK pfJI1FnW1IZeUjBTm9wDnPn+I/FJEMi+cU/v4Medp10vzK4jJZepT3OzN3tGXdJ91AhMABcDWJK2 3t4j0WdjcvLSyytYW3sBDseO0S4NzNWmowFOfgHkKpo0PiFKWRXPoibq09wsjfn7Yk9c7KL9BpsT XAxgSXxizzH9ErVRCu3NwXgrXFycrq9B6d2/m3RkV1XT/glgdlUKxdSnudkbya39tN9gc4KLASzJ jqDjOjMazy9g7eHDtOsCc7LFZyR+8/yMWIMiY2fwiUOnowPOJ0ZlZufj2LkV6BTLbj+cSH2am42x YH9s2RUx7TfYnOBiAEvicSpKd44TBH6IA+cwNTw/P57f5Oeg1MMzMupUemZmRWV9W/uAGH/UWB2l SrU2tY76TDcb429RJRIFnoJkBFwMYEmK6xrGT3k8QQBu34OJOfH9Rw6TTxafSFaPzc2vbGoelODu YLgW0yK6xeMc9cmO2zF/X2xIQx/tt9b84GIAS1LdfHlXyMnxacqR70+7NDBFPF//Sffyvj8bl1ZW 0d2PAwMwhkypci+1tIZCm7MuDciwCmE0XAxgYYQDA95nY/UuT63z9KRdHZgKp2MBvAn38vaFRSQW FV8R4SHFYFC3RLEhs5H6lMfVeDe+qk4kpf2mmitcDGBhFEplbG6+njTlF7AFm31W70OBwGnC3lCB Ccn1be1KHB2HKWgdkjvmNlOf+GY+bJMvVvfjESEzgosBLE9V8+VdwSfGrU2RIaBdGlBzvcGm/gTl GhAclZmNjTwwVu+wwqu65w6zvYfrFo9z7qUdlwdltN9IS4CLASyPUDTgdWbcZp8gwMnXj3ZpMNdW uLg48/X3idrqF3g6I0s0NES7RjBXcpUqpnXg3XNV82hPhcaO106XhDddlSqxBssZXAxgeeQKRUxO np40JcBBdCvi5OtraDHK71xCxxU8GQE40CVR+NcL/xKaT31OnMr4fWCWd01v4wDWH2YFLgawPJVN zTvHbfY5oxG6dRh98ou+3lC1La20qwOLolKpGgZk/vV9fz9TeuOBOOpT5Pjxg32xL4YXHKvtreiX 4kDgrMLFAJanu79/f/ip8QfRbVxcaJcGs2XLkSN6d/R2Hw/Nra5VKnGfL8yWrmHl2ZaBvWWdz57M m78vlvqkScbvg7J2FrdHNotahhRoyD+XcDGAJRkQS8b3SSBT7YoVK2iXBtxz9NXf7iAiPUMixU2+ MBfI3/SbB+WnmkU7itqWhOTcdDB+jmfMBftjH/fPdMy9fPLS1YsimQKTJj24GMBiSOXykKSU8S2n bL29aZcGXHLk+48PUTuDT5Q2NNIuDayRnEyjQ/Lz7YP+dcKdRW1vRJf+/GjyLM2Ytx9O/GtEkUtB K//ilbjWwfoBuQwHiU0JLgawAOSvBuMPovMEgSuw02cpSDYev6/3fUyccGCAdmkAI38ECaXKnB5J eNPVYzW9+8o6N2c3vRlT/rvArIVHkoy67YtMlI/6Z5K5eENmo3tph3dNz8lL/Rld4p5hJdYczAIu BjBrSUUl49emsNNn7mxsbHh+uutRW/2DyG83TkaBySIznUShujKsvHhVWtAjzuocTOsYSG4TnW/p j73cF3VJeKrxyvbg07ff+fNt/ONJbaLUdlFm52B+z1BN/3CPRCFWqOSYKy3FpBfDvpjU2++8y879 0LmWflwMQF16ecX4JglkLqZdF0yTrbf3+B7m+8Iimjo7aZcGMFPbtm0jfzqtXr2adiFA2eHDh8mV sHz5ctqFAIzKra4Zv9NHuyiYjs2+vuMPmfvGnRMP4/EHYAn27t1LJtD//ve/tAsByo4ePUquhLfe eot2IQBaRXX1W3XXptC908w4HDs2vgPnyZRUuUJBuzQAbhw5coRMoG+//TbtQoAyb29vciX885// pF0IwBh5NbXj1qaQpsyGnUDgPK4DZ0xOHjrOgSXx9/cnE+irr75KuxCgzMfHh1wJ//jHP2gXAqAr o6JSp9mUsy/SlBn4av9+3rj1qLSyCtp1AXAsPDycTKB/+ctfaBcClPH5fHIlvPHGG7QLAdAjubhU 54Y+h2NIUyZtxYoVOuejXPyDiusbaNcFwL3Y2FgygS5ZsoR2IUCZn58fuRL+9re/0S4EQL+4vAKd 9Y3Nvr60iwKDdH6zdgQdr2tto10UwKxITU0lE+gjjzxCuxCgLCAgAFu9YMpUKtWJlNSxE3QAWnea Jh5/zHqUa2BIc1cX7aIAZktBQQGZQBctWkS7EKAsKCiIXAn/93//R7sQAINkCsX3Z+N0dvpoFwW6 eAJ/nX29mssttIsCmEVVVVVkAv3Zz35GuxCgLCQkhFwJf/3rX2kXAjCRQYnkQHgke6Z2RJoyJTy+ v85zYYrq6mkXBTC7mpubyQT6wx/+kHYhQNmJEyfIlbB06VLahQBMoru/f1fwCXYXdJ5AQLsoGOHA 5+scNU8vx/16YPl6enpsrsMjkKxcaGgouQxeeOEF2oUATK62pVXn0BSOoFO3ztOTN7aFVHxeAe2i AOaCWCxWR6kBPJXbukVERKAtBpiR8Y88pl2RtdN5xF5EeoYKfTjBasybN4/MoZ14pqR1i4yMJJfB c889R7sQgClRqlQB5xPHpCn07aTHaex6VGBCkgI7HWBNfvSjH5E5tLGxkXYhQFNUVBS5DP785z/T LgRgqoaGh/eHnWLP4F/j0BQNOkekDoRHSqRS2kUBzKmf//znZA4tLy+nXQjQdObMGXIZ/OlPf6Jd CIARWrp7XPyD0BuBIp0jUtsCglt7emkXBTDX7r//fjKH5ubm0i4EaIqJiSGXwdNPP027EADjjHum DLb55pRO64PsqmraFQFQ8Pjjj5M5NDk5mXYhQFNcXBy5DJ566inahQAYR6FUep+NZfdGsOfzaRdl LXRaHxxPvkC7IgA6/vjHP5I59MyZM7QLAZrOnTtHLoMnn3ySdiEARuu9KtoeFMJOU7QrsgqOR/3Z UWp/+CkckQKr9eKLL5I59OTJk7QLAZoSEhLIZbB48WLahQBMR15NLXt5xImPNDXr2DkKR6TAyr3+ +utkDuVjSdy6JScnk8vgd7/7He1CAKZDpVL5xMazm3au8/SkXZQlc/b1xxEpAMa//vUvMod+9913 tAsBmi5cuEAug8cee4x2IQDT1NXXty0gWLswJUDTztny1f797Lv2AhKSaFcEQNmHH35I5lA3Nzfa hQBNaWlp5DJ45JFHaBcCMH2JRcWsW/kCN3p7067IMjnztTnKNTBEKMLDMsDaff7552QOdXZ2pl0I 0JSRkUEug9/85je0CwGYPplCcTDiNM6fzyp7gYC9tZdaWka7IgD6Nm/eTObQTZs20S4EaMrKyiKX wYMPPki7EIAZYT/pmCcIcEL/c67xBNoc5RkZJVcoaFcEQJ+LiwuZQ9esWUO7EKApJyeHXAb3338/ 7UIAZkoQn6BNU3jMMaccxzaSauzooF0RgElwd3cnc+j7779PuxCgKS8vj1wG9913H+1CAGaq44pw K7v/uQ/6n3PD1tubvSQVkZ5BuyIAU3H48GEyhy5fvpx2IUBTQUEBuQzuvfde2oUAcCAyIxMP5uMc j6/NUbtCTg5KJLQrAjAVfn5+ZA597bXXaBcCNBUXF5PL4Je//CXtQgA4cHVoyDUwhNnj433vR7si s2fr7e3MaoCQX3uRdkUAJiQsLIzMoc8//zztQoCm0tJSchncfffdtAsB4EZsbj77VA/tcswee0nK 60yMSqWiXRGACYmJiSFz6NNPP027EKCpvLycXAZ33XUX7UIAuHF1aEjbsVMQYP89TkxNn86S1MWW VtoVAZgWdZvrRx99lHYhQFNlZSW5DO68807ahQBw5mx2LnpMcYK9JOV9NpZ2OQAmJz8/H7duQXV1 NbkM7rjjDtqFAHCmf3CQWZjiCQI2+/rSrsgsYUkKYFLq5YiFCxfSLgRoqq2tJZfBT3/6U9qFAHDp dEYW66l82OObDvK+YUkKYGJNTU1kDr355ptpFwI01dXVkcvgJz/5Ce1CALjUcUXIfiofuchpV2Rm NrkH8FhtOS+2ttGuCEzU4ODggQMHeNZqw4YNNtc5OTnRrmV2vfPOO2+88QbtKkzUF198Qa6BBQsW 0C7E5GzZsmXp0qWrV6+mXcis2LVrV4elN6z2jTunXZjyRVcE47BzFJakYALBwcE2AABWycHBgfaf wbOrsqkZh8+njd3eHEtSMIH+/v6tW7eus2JvvvnmP//5T9pVzLr58+eTieOjjz6iXYiJeuONN1as WEG7CpPzyiuv2FzvA0+7kFmxefPmpqYm2n8Gzy6lUrk3NIJp17nO05N2RWaDx9cuSX1/No52OQBA 34IFC8ic2NaGv1iBEdQ9bF944QXahcD0pZSUavf4+GjXOVXs3b2q5su0ywEA+tSrUhZ/MgS4dfr0 aXLZPPvss7QLgem7IhJpD5/7YY9vSuwP+TNRyv1kuEKppF0RANA3b948Mid2dXXRLgTMCR4HYBmO xcQzx6U2HztGuxwzwGP1QEgsKqZdDgDQp1Kp1Idse3p6aNcC5uT8+fPksvn9739PuxCYkfzai2gw ZRTmwPlWv8C+gQHa5QAAfQqFQh2lrly5QrsWMCfqJys99thjtAuBGRFLpazO5zguNQn2gfOAhCTa 5QCASZDJZOoo1dfXR7sWMCeZmZnksnn44YdpFwIzFZSYzDxE5htvb9rlmDQcOAeA8YaHh9VRSiQS 0a4FzEleXp4NHlJpEdh7fI587PEZhAPnAKCXWCxWR6nBwUHatYA5KS4uJpfNPffcQ7sQmCnR0BDr ITK4j88gJz4OnAOAHiRBqaMUyVS0awFzon7e95133km7EOCA99lYpiWCDZ7HZwDPDwfOAUAPkUik jlLDw8O0awFzcvHiRXLZ/PSnP6VdCHDgQmkZs97i4IOFKT3WHj7M7O75nUugXQ4AmJD+/n51lJLJ ZLRrAXNy6dIlctnccssttAsBDrT29GhbIqBXpz7s3b2c6hra5QCACREKheoopVAoaNcC5qS1tZVc NgsWLKBdCHBAoVTuCDrOPI+PdjmmiNndI6MfJ0sBgKW3t1cdpVQqFe1awJx0d3errxzahQA3/M8n Mm3Paddicl50cXHW7O4djY6hXQ4AmBZMiDA9fX196itHLpfTrgU4kFpazmp7LqBdjmlx9tXu7qWU lNIuBwBMS2dnJ5kN58+fT7sQMDPMvZ9DQ0O0awEONHd1o7uUIc4C7e5exxUh7XIAwLS0t7eT2fCG G26gXQiYGalUqo5S/f39tGsBDsgVChf/IE1gwB7fGDy/0d29/WGnaNcCACZHfXj4xhtvpF0ImBk8 CNvyHDodjZPn4zkc0+7uxebm0y4HAExOc3MzmQ1/+MMf0i4EzM8NN9xALp729nbahQA3wtMyEKXG 4/G1u3uN7R20ywEAk4PuQDBtN998M7l4mpqaaBcC3MioqGQyw6aj2OMbxbRB2BVyEs/dA4DxGhoa yGx466230i4EzM9PfvITcvHU1dXRLgS40dDeznoYn4B2OaaCaYMQnJRCuxYAMEVkHiSzIZkTaRcC 5mfhwoXk4qmqqqJdCHCD/Vxj3MSntkUgYN6T9PIK2uUAgCmqra3Fk9Rgeu6++25y8ZSWos2OhVCp VK6BIZpGnYhSI5jn7pHR1NlJuxwAMEXV1dVkNvzZz35GuxAwP4sWLSIXT34+7mmyHJ6RUeh5zsbz G719z8U/SIZutACgT2VlJZkN77zzTtqFgPl58MEHycWTlZVFuxDgTGBCElpLsTFnzr3OxNKuBQBM VHl5OZkN77rrLtqFgPl59NFHycWTmppKuxDgzNmcXM2xc0Spa7be3ugoBQCTKi0tJbPh3XffTbsQ MD+LFy8mF09iYiLtQoAzaWUVaC3F4PG1B6XKGi/RLgcATFRxcTGZDX/5y1/SLgTMz5IlS8jFExuL jQ/LUVB7kQkPX+3fT7scypxYUap/cJB2OQBgogoLC8lseO+999IuBMzPM888Qy6eqKgo2oUAZ6qa mpnwsPnYMdrlUMbcvuceGk67FgAwXfn5+WQ2vO+++2gXAubn+eefJxdPeDhmGctxqaNT26XT19r3 +HiC0bfiRAoOBAKAQbm5uWQ2vP/++2kXAubnr3/9K7l4jh8/TrsQ4EyXsI+JUk58qz55vmLFCuat SC5G8zQAMCg7O5vMhg8++CDtQsD8vPrqq+Ti8fdHL0fL0T84yIpSVv0763RMe1CqtKGRdjkAYLoy MzPJbPjwww/TLgTMz9///ndy8fj4+NAuBDgzIBYz+cHZ17qjlK8f81a09vTQLgcATFd6ejqZDX/7 29/SLgTMz9tvv00unqNHj9IuBDgzNDzMOivlR7scmpz8tKtSYqmUdjkAYLouXLhAZsNHH32UdiEw p1QqVWZmYlpa7EzGSy+NHDtfv371DF/Hy8v96tU+2m8JjJBIpdonGlt3aylnzZnz3cdDadcCACYt OTmZzIaPP/447UJgTh0//n1u7rny8oyZDE/P3Y899tuoqOCZvMiBA04bN64Uia7SfktghEwu165K WXfDc6YTwvcxcbRrAQCTlpiYSKLUE088QbsQmDsxMaEXLkTNMEdxMgSCfTzeJ87OqxClTIRMoWAd O7fqVSmmE0JEegbtWgDApJ0/f55Eqd///ve0C4E5kpGRGBd3nHqIIiMqyt/e/qO9e+0QpUyHmH1W yopXpV50cWHehwslZbTLAQCTFh8fT6LU//zP/9AuBOZCZWVxRIQv9RBFxoULUZs3f0ByFKKUSbk6 NKS9g8+KmyFs8Qlk3gc8fQ8AJhYbG0ui1NNPP027EJh1ra3NwcGHqYcoMvLzE7/++gN39/WIUqam 96pIu8FnxXfwOfH9mfehrbeXdjkAYNLOnj1LotQf//hH2oXArDtwYOuBAzxTGA4Otm5u69Q5ClHK pHQKhawNPgHtcqjhsZpKDYgltMsBAJMWHR1NotQzzzxDuxCYdadPB6WnR5rC2L9/C5OjEKVMSnNX tzZK+WFVamQolEra5QCASTt9+jSJUs8++yztQmDWIUrBpKqamrV9pay4jz3TCWFHEB4xCQCTOHXq FIlS//u//0u7EJh1iFIwqdzqWiZKfWjNG3z80Si1NzSCdi0AYOrCw8NJlHr++edpFwKzDlEKJpVU VKI5KGXVTaWcNatSh6PO0K4FAExdaGgoiVIvvvgi7UJg1rGjVHJyaELC8TkeFy6EI0qZuOisHM2q lPU2lSJ4mqU537hztGsBAFN34sQJEqVeeukl2oXArGNHKT5/f0JC9FyO+PhTwcHfIUqZuKDEZGaD j3YtNDFnpUKSL9CuBQBMXUhICIlSL7/8Mu1CYNaxo9SpU3N9c5ZUKg0OPoQoZeI8TkWNRikrbnV+ bWRVajRKRWZk0a4FAExdUFAQiVKvvPIK7UJg1iFKwcQUSqWLf5CmE4JVRynmrFR8XgHtWgDA1AUE BJAo9eqrr9IuBGYdohRMrPfqVW0nBL71NpW6xnqW8YVSPIAPAK6pVCq5SiVRqHqlyvZh5WWJslGs vDikrBpUlg0otx3xHbmD75XXaoeUDWJls0TZNqzslirFcqVMSb5URbt84AyiFEystqUF/TnVmGPn 2VXVtGsBayGsTgobEVUvlBv4FFFO1PVPSSrTfIa8Pu36h6LShEZ+O/UXkv9F5TTNoGpdbYVxwWFh cYZeUy4RiUQSQz/fNblITUL5EQMKlYoEoYw+5eluZUCH4lCLYkeT4tMa+f8Wy+7Pk92VI7stS/bD DNm8dJmNegjybX54i43tdvLvN2XIfpIl+3m2bFGu7OlC2cpqufMlhUeLQtCuiOhWJl1RtoiVUiXC lblClIKJZZRXMlFqs68v7XJoYo6dI0rBnCn0WGpznVuOgVgkyhn9jMUems8QeSxWf2hpjsiYbyav trVh2NYbzDbG6nZT12MXp+cXJWWj33SZQLdYeVuUh91iG5bFK72iyjirawrEClXdkDK2R+nbrth6 SfFSqez2LE1SmspIGZrKp92SKftDkezrerlXqyKqR1kmUg7IsWxlThClYGKhF9I0Z86t+va9a6wo lVVZRbsWsBZlXivVIcKj0ECUkhSOfsZSL00UEQmWjaaTQmOiVHeaGzu2eBgKb8Zqi1ps8AUlwUx6 W+o15pe7c1baGLBS0M1NZQZJFKqcfiW/XbH2ovzRfNkNU89OMx7z0mX35creq5YfblUkXlFeleEZ VWYAUQomdiAiEmfO1Zhj55kVlbRrAWsxh1FKEqyTXeyiOFn/qR9NS7Zl4zbo6sPstN9OWz/7Rxj5 BTdBVFJclJvtUuZDy7wKuShNl0ypKhUpgzoUdnXyX+RczzZB5TZ/+8AmsGzOohR7/DhzZCvQp02R 0acUK7BIZboQpWACQ8PDrINSVh+lNG9FRjmiFMyRuYtSwiRtUrEx/ssNv67XMv3BTN4UNWbzjhWl yC+NfnCxXRmrhvo4V80ne3C0ZDaKBJW4XqVzo+KBPE2S2ey14N6Hd+zY0dPT09nZaeu4zeZo2szT 0Y8Eueu9g48FHz/m43NsMvv5AeqvWpgt+/yiPKxL2SvFIpUpQpSCCdS1tjH5wcm6m0pdY0Wp9PIK 2rWAtZizKFWt2WmzjyqLsh/NOPZxeg6KS9oKo6Ki4qKicuqFE39wRPdoQnNN09mUa3JlBanFY6OU qNBr9Bfs08Z+Vb1mP3AlFzFvhFQ5EqLs6uS3ZmoCzydbH/v9/5w7d04uH5P++vr6HL51t9kdOfNA 9XKZLKRD2to/oJzsQBQvtYL5qhvSZe9UyU92Kq7KEahMC6IUTCClpJTJD5uOWn2U0mzwpZWV064F rMVcRSnNyXCbpWmia8I0zeLP+KPgrJPwi91yJv4g0RRlp7eSNFfNcfoozSbfmCjlMfox17FRSl42 +pMtdePkuFSxSLmzSXHb2JPki1L7e/oNzj5DQ0P7j3j/wOEYB1t4HziQzNbb2ztBhcPDwwvGftWC DNkXdfIkoXLSGAZzBlEKJuAbdw5P32Mw3c7RVwrmzNxEKUl1sGaxJ1jCfk2bxXHjIkuhhybOeBRO /EHt+Sv1y2ow59sXjyw6VY+rf2QtS7NktdgrTbMyJu8OttNsQtrO9ByXTKmK7Fb+qdhgzllfNdA/ MGjoy8nk5Rcc8qMv90wzRH2y9de/eTQtLW0qt+mF5FWMf4V7cmSCdoUIy1OmAVEKDJHK5NsCgjUH paz99r1rrDv4UkpKadcC1mJuohSzRuSapE5O8ihNE4KVAt3WH21pAtuVtrYrV3qwtv/0fvCaKEdd yJiNQmGO5kS5/Ui/BUnhMt36RxR6sRozLF1pZ2fL2g9cltQ2oyQlUSi92xTaHT3D4+sq0dXBIUOv o1Aoos6cueszZ5vU4dEvIf/iHGCz5KXHnv6TbVqDntf8bMe9D/0mJSXFUIgalCudmxQvlMpS24Ry hYJ8RKlU/jJ9cPxLzU+XuVxSdAwjTdGHKAWGXGQdlOJZ/UGpa6xu58nFiFIwR+YiSmnbSa1kbrIT Mo0RFk9/K607Sb1RuJTVKlR7a15wtcRA/WptBpsh6B6gMo5UqfJsUSzIMGIRybFaNDAkNvSCJOqk XLjw0IpPf7DoN5988mlqaurg4CBJSrwmxZjX+WLP3fc/lJCQQD5f7+uQgLe7ZcyX/CBdtqVe2tzb f+Fyr6HaNtbLkaaoQ5QCQ+LzCliPjOHTLoc+ptt5UlEJ7VrAWjBRystQKppxlOrWnIxabJ+k/ai8 mkkywfXTazMuj1JHNNaBqzLBaGpb6aXZJRdp62eFxTa3kXWy0YWoxctGVqU0e3vXj6i7TTNNkYQT 2KG4yZgcxYyt1f2DYoNvBXlldkbqlbJCkd3BO3/9QFxcnKEQJVUoPVsVPzD8re/Mnqiw3c2KYXRK pwpRCgw5dDoaB6XYnDVnpeLz8ThjmCNMlLIdf2hJbaZRakw7qaVLF6stZW2nLR17knyqJGXqF7YN qx8tS3siS6BNJPLRTyOJi/lgmYCpaVlUGfODS3KC7Zmqwpqms8eXd1W5KGdap5s0Y2dNn1gyPPF3 IbHqrcrrn8/z+9l9D5w5c8ZQiJIplb4digUzqIeMGzNkEd1YmKIJUQr0Yj/FGFFKzVmzwReZkUm7 FrAWU1iVYqLItKJU9/h2UuPZTeMhMsIc9Rbh4jjNuSbmaDrJUvZ2drZ2I2xXakPbSlvyn3ZxTT1e mk8c/1OnuS3TxDGj7/4gCce1ST790HIs2+aNj2667zerV68ZHDR4Ip2oGlSqv+S2uPaWnit6P0eh VIV0KW+ewnmtqYzllXKJAmmKGkQp0CutrFwbpXBQ6jrmrFRwUgrtWsBalGlSBbO2o6stTtPGgNkg MyJKMe2kFq+09/Ly8tAi/+XGRJ9pPEQmTt2citVLkxWlJuKWc1lT/8rCcftpkmrB6M/mYXTD8wG5 8tH8aWWV7xJfd9oTFne+o7tn0nvuyCc8XjDmy9+uklV2CpkvVKpUkb3K2zgKUeqxIENWOoAoRQ2i FOh19EwME6XWeXrSLsckMGeljsXE064FrIVQ02HJUCelas1eGKsFkzZKTfY44zamT2aYnmac2jUx ox8ioznKzl47akrysrW1s9elfR7MSjt7O1v7pKaeCeqXlHlNO0pdEiunF1Ruz5Y9UzLV8YiBtPbL XFlo+3DsFeXEB5+mPeKvIEpRgygF4/UNDGBJajzmrJTnqSjatYDVEDGtA2xsBbrhQVQdxmyPuWnb iTNRamXZhAGIWeExdJuevCmMiTnaBS6JsK1pRLeI9epjPyjSBJ4pnGiSj1arPSsl8tKkq5W6z9oT BWuaIrgZv1BW2DcrGWZkBJRo+yHQGPPTZeGdMmPfEOAKohSMl15eoW2D4DvXV4XJYlp0up0IpV0L WJEc1r7YUjuPtLL6tra2+rKcYDdW56XFbm3ar9A2HFhma+86bhmIsLPzqpdcS9K0k1oZrNs8SqPb TZNq7ONGvwOz57jYTZtzdD6Ypv6yxa5t+l+WTTT6paw7+JqitMfLV7qF1QtFcrmku6nQQ9tcyrba +NsKTzX1cR9jBAU29z/m5uZ27vz5x//7uU1onZ7PiWq18S+a6phWKrshXRbSMr0bLYEDiFIwnsep KGZJau3hw7TLMRVO/NEo5eIfNJUexQAcaXOb5Gj40rgxLStFXpMfSlqW0605r26zNMlw6yjtzXSa ngbMrh97i23MB+X19uM+wTBN8BvTDEEoMNhVaoSb7hP9piS+WfhADndrR+ENNk/8+auvvhoYGFC/ Pvljoamp6XMnFxuen/bTUoefWPJ09qRycrKLSlIqLjoXt99t/D2GN2fIYjsQpahBlAIdzV1d2iUp NDln4fkytzQGDg1Pcjc0AJfkbVFudvpTlK1bTpvOHCoKnjCHXLcyq0Czu7cyeIITVXLmWLuNrbqB Z3XwaCXsc1BjPqi5KzB4SitHIsFKvWWI0oLZTzzWWLwyqszorT21pOYr/y7gYmEqttvm2dffeeed np4evd9ocFj6dJHmk9/4qKamZoKqSADrkyou9Cu/alBM+yz6iwVDhT0Gu7LDbEOUAh2RGZk4KKWX k68f88609+q/wRlgFslFTdWFaUlx1yXlFFaPOa1kkeTC+sK0uKgRYVFxOWVNM1l5SW6+8mpczd3Z 0umHqKRBm799sPSlly5duqR3aZp8sHJQ+Ufm0X5n2t9evnziReyqqqonPttikyiadlULMmTvZ7aV IkrRgygFbMMy2fagECZHvejiQrsiE+IkEDBRqrKpmXY5AGAcEqXm74tdVdBj8KkxCf23/98Km32x +n/1va+fePKpsrIyQyGqekj5bMnYL3ny+d7eXvbnGPragoKCx1bbj0Q146PUf4v6Fx5JRJSiCFEK 2HKra7S7e3wsSY2xwsWF6YeQUVFJuxwAMA6JUjZ7Y356KGFVcf8NBmLJkePhQqFQEBC4aMWnI4fA 1R9ft+/eh36Tnp5uKAhdHFK+UDru1Xxzt27dqv4EoVTh16lYlDvSKqGopcvQ6+Tk5P5mtZNNinjq Oeqt4oFHArJv2B+LKEURohQwlCrVwYjTTJRy8vWlXZHJYW7iO5udS7sWADCOOkqRsfBI4urivlv0 HUxacKKSTEzXrgeb1tZWt4Me9z72RHR0tN4nv5DPaRArXy7TH3Ju2n2qSTR89opSe25KM54tkTV0 9RoKVBmZmQ+s5U0aqOany94rET0WmE1+IkQpuhClgFHVfBkPi5kY01oqMCGZdi0AYBwmSpFxq+f5 1Xldj+TquaHPMziM/VWGAk+TRPlaxTRPN6nHP0vFncJ+vaWS17+QmrZorYuhxgh3ZknXFgvv9UlV /ziIUnQhSgHDJzZeuySFA+f6OAtGo9R3kdG0awEA47CjlHq8Flfzfono1rHLUz8IrZNIJjrePiyV vnXAf+Q+vhnkKGasLh+4Oqg/BSmVyqSUlF8eOTemvHTZsqLB99KaF+yPY34QRCm6EKVAraW7h3Xj XqANDpzrwzzReHtgCFpLAZiX8VFKfXTqk+y2t4oH2U8W3uN/fOKXUigUxcXFa75xnPfe15xkKtcq oURfixWFUnWqR8ns6L1UKP68sOc+nzSdnwJRii5EKVALSkxmtZPCkpR+PM2qFBlXrk72pFgAMCV6 o5R63O2dQgLVeyUDv8odCS3zIpsGxBLVFEjl8uyahvey22aepn6QLvOu6ZbLRxtc9MmUB1sV6oD3 0yzZsuKhtQXdj18/GTV+IErRhSgF13SXpNDh3CAe+iEAmK0JopR63HYo4e/xNWuLet8qGVw4Ow8d nnT8KFPm26H4Z+XIv9+SKXu5SLymWPhOyqV7vFMmqBxRii5EKSD8ziWwopQ/7XJM11f79zPHpZKK SmiXAwBGmDRKMeMur+R/JTesLRb+o3jowbyRnbW5TFP35IwkqNUl/R9ktDwkSJ9KwYhSdJlmlHJ3 X79161qFQjHH9VinSx2drBv3Au35fNoVmTSe5rhUcFIK7VoAwAhTj1Lsjb+Xo8pW5bSvLrqysmTg D4XDt0732S4TjBszZI/nS1eUDK4u7vssr/ONuJoH+WnzjKkTUYou04xSTk6fdna2znExVot94x56 IEyK6dK5P/wU7VoAwAjTiFLscYvHuaeO57534ZJtXqdtYa9tSf+HpQOvFQ09VSj7Va7s9qyR/ThD 61fz0mU3Z44cebo7R/ZEgfTlIvF7JQPkFUZeJ6/rw4yW58KLbj+cOO3aEKXoYkcpkmoEggNzPKKi +DpRytnZNi8vTalUYFVqDlRcamIvSW05coR2RaaOJ/Bn3i7J9VZ+AGAWZhilxo8F++N+9f2Fp4/n vRZT9XZi/XupTR9ntqzKbluV07Eqr3NVfteqvK5VuR2rcto/yWpdmdq0IqnhjbiaP4cW3O+bdotH PIeVIErRxY5SdIc6Sm3fvprHW3P48PZNmz7q6Gij/fZYOJlcvi8sAqekjOLE10apps5O2uUAwFRx HqVMZyBK0WVSUcrNbZ2Ly1ry70FBHl9//SGOnc+25OJSdgOEb7y9aVdkBhz5fOZNSyuroF0OAEwV ohTMEpOKUps2vX/hQvjZs35bt65xdv4UUWpW9Q0MugaGaKMUlqSmjDl5jsfHAJgRy45SRT2DtN9g 6xUc7BUY6BEYeNDbe6eX13Yvrx1zOY4e3U4G+b7kn7t22R054pqSErZjx1fu7ut37LBDN+lZFZKU wspRgStWrKBdkdlgGnXuCj6hxFUKYCbONfVQzzyzF6XOt2DxgZrBwQGh8IpA4HH6tM+WLR9/++0X czl27lz7me2bX657x9V1XXx8EMlRe/duIR93clrV3y+k/d5YsvLGS+zT5s6+WJIyAs9P2/O84wou VADzcLKuk3rmmb0oFXSxm/YbbNUyM5PCw73S0yOjo/mbN3+wZctHczm+/PIdO7uV6j0+H5/dLi6f OTuvys9Pp/2uWLJBiWT38VDWkhQaIBiH56M9eZ5TVUO7HACYkoCqduqZZ5bG/H0x3hXttN9g69XW 1sTnu1M/KEVGRIS3s/PqHTvW2G/5ZOeO9S5b1+7cYedzzP38+VMXa8sVCjntt8pyhKWmsx8Ts0Ug oF2RmbFxcWHewJMpqbTLAYApKe8doJ55Zm+cbuih/QZbKal0+OjRndRDFBnnz4e4uHy+Z8+XGzas rK0pqa+vaGqqaWtrrK4uSk6O9hPs37F9fVRUUFcX2iPMVHXzZfbWnhMfS1LTwRyX2nMijHYtADAl XRL5bYcSqGeeWRoZnXjAOh0CwcHk5FDqOSot7dS3324kOWrjxpV73R3ZFfb19dZdLK+sKLh8uS4z 45z7ns2nIvyGhgZovWPmTiQWs7f2nAWBNi4utIsySySCMm9jW28v7XIAYHJKlerT5FrqmWc2xmN+ GT0SNLWm4Ny5U9HRfOo5iozDh123bfvMweEjO7v/HDq0U2+1Mpmsrq6ioaEyLTV297ebGhpwQMVo KpVqzGOL8bi9GXDka9/GlJJS2uUAwJScauq/8UAc9eTD+ThU2YV73udeVVWZo+NqDw9n9ThwwOng wbke5JuSsXfvFienVSRK2a3/z8YN7/n7H56gbIVCUVVZVF9fcWC/U0lJzpy9XZYhraycnaN42Nqb ARsXF+Y+Pq8zMbTLAYApkShVjrnN1JMPt+PNs2VNgzLab601qq2tNJElqYCA/a6uq+3Wv7Np48rN X38ik03+ULPOzlaSpjw9nJua6ubgvbIMl7u7XfyD2I8ttkVv85lxFmj3+ERiMe1yAGBKGgdk78ZX Uc8/XI0nAjIzutDnnA6TilLr1v2b5Kj169/t7p7qE836+novXiw7sN9JIsEUNrlBiWRf2Cl294Mt PoG0izJ7PF8/5i0tqL1IuxwAmKqKvuEPE2uop6CZjz+fzEvqQJNzarq6Ovj8g/7+nurh5rb54AHH uRx79mx2cfli27Z1jo62X9n958sv38nLSzPqR2hsqElJOZOefm6W3iIL0D84WNZ4aVgm48edH7u1 h4acHPjG25u5jy84KYV2OQBghIYB2baCVrM+N/Vpcm1ODxYTTIi31/azZ76fy+Hrs5MkqK83/ZcM u/X/OXHcZxpl11QXHzrkyvm7YRlkcvm+sAgyy3tGRo1pbI6GnNxhjkttDwyRytD6DMCciOXKkMb+ p4NzqIciY8cvvVOOVPd0iHHLnmmhGKU2bnhvzx6H6ZVdVVXk7f2tQoHLSY/6tvYxCUpzRGrt4YkO 9oNR2C0RShoaaZcDAMZRqVTlfdJ9ZZ13eydTD0hTGbd6nt+S05zWJVbgfj3TQytKbdq48ptvVsnl 0/zrfH19VVjoMRyX0qumpVUnR/H8AnhobM4pJ2/tcSn/84m0ywGA6ZArVZnd4v1lnQ/x06iHJUNj 4ZFEp7zLcW0DEgVClImiFaXs1r935cr0e93X1VUEBx0aHpZw+FZYjJ7+q2Nz1Mg/aRdlgZjjUlv9 gwZwHx+A2VKoVCXC4YD6vi/SGn5+NIl6dtIsQ517J77q+5re9C7xsBIhyuSUluaHhvLVw81ts6cH by7Hnj3f2NvbHju2j6lBPQQCz6m336yoyD9yePusvkvmS6FUbgsIZi9J0a7IMvFYvTqzKqtolwMA MyVWqLJ6JD61V95PqP4ppQfN/PBg/GtRJYequhPaB/tlStpvCejX3y8MCTlSXp5hamP9+ndbW5un 8iNIpcM1NcV83/2z/V6ZryNRZzXdDwJtbGxol2OZ7Pl8JkodRa9OAAsikinTu8THG/v2lXWuPF/1 a5/UebMZn+7ySv77mdJdxe3+dUKSoLokSjQwN3FBQUdKS9OoByed4ea22dHx4ylGqYqK/NCT39fX Yx3AoIi0DGaWp12LJSNJlXmfu/v6aZcDABwjkWZAPnJAPapF5FXdS9LO2tT6lyKKHuSn3ep5bhqp 6aYDcYuOXXj2ZN5HSbXbCloPVXaHN13N7ZX0y1RKxCczkZeXnpgYTj046YzExAgHh49dXVdPJUrV 1VUUFqbzffeRf1cqsfipX3p5BTPF2+HA+azhsdqex+bm0y4HAGYXSVZSpUokV10akOX1iM+3iSIa +0LqewMu9vhWd3tXdR0q7zhQ2v73TS5PvvIPj5LWo5WdPtVd/rU9wfW9oY3CuBZRVvdQ7VVpn0wp Uaiw9GSOxOKhwMDvqAen8WPLlk/c3dcbilLHj3v7+R1UDx+fvWQcPbJLIDjg7Ly2t7d77t9Gs3Cx tY2Z4h19cVZqtny1fz+TpnYGnxiW4WFYAHDtV7/6lY2NTXl5Oe1CgHsnThwrLr5APTjpDA8P5+3b V+/da7d166qOjladmvPzR9asxn8V+UHWr393YEBE5Z00fVcHh5go5cTHHt8sYj+PL7d6qvdNAIAF u+uuuxClLFJZWUFsbAj14KQzMjJi7O0/IjnKzW3d/v1OOjVLpcMBAZ56v3DnzpHohSg1gV0hJ5nm nLRrsWQOAgETpTwjo2iXAwD0LVy4kESpqioc6LUoMpnU39+DenAaPxwcVu3Z86W7+3oXl7WkSJ2y IyL8CwuTx39VevpZB4ePt29fgyg1Ad+4c4hSc8PZT7swVd/WTrscAKDs9ttvJ1GqpgbL1Bbl1KmA goIk6sFJZ3z//bfbtn22d6+do+On3d2dOjU3NzdERgr0fqGT02d79qxHlJrY2excph8C7VosHM9X 2/kcTzcGgNtuu41Eqbq6OtqFAGfq6qqjovypByedkZ+fuGXLyNaes/OqwsKs8WX7++vf2jt1ypfH +5R8oZPTp+h2PoG8mlrtyXM+n3Y5luxFFxdnTVeErX6B3f3oigBg1W699VYSpRob8XROC6FSqfz8 THFrj8db7eb25fbta06d8h9fdkpKTEbGWb1faG//CclRO3asDQsTzPnbaU6au7q1J8+xMDXLnAT+ zLsdnppOuxwAoOnmm28mUaq5eUqdEsH0ZWQkBgUdiojwNanh6eni7Lxq9+515F/G19zV1enubq/3 C93cNru6rt6z58s9e7bM/ZtpXiRSKesmPj15FTjkcOwY825v9Q/q6b9KuyIAoObGG28kUaqlpYV2 IcCN6Oig4GAPUxt79nzj7r5+27Z1crl8fM2JiWcEgr16v9Dd/ZvrW3uficVDc/9mmp1dwSdw8nzO OLM6n0ekZdAuBwCoueGGG0iUam/HTSgWIjU1Jj090tTG99/vcnJa1dfXo7fmrKzkhITjer/Q23un s/OqioqiOX4bzdThqDOak+eIUrPO0ceHade51T+o9yoWpgCs1Lx580iU6urqol0IcCM+PvzwYVdT G66u68vLCw3VnJub5uHhrPcLt2378sSJY3P5Bpq1oMRk3MQ3l9jtOiPSsTAFYI1UKpXNdb29vbRr AUsml0/z+RqtrZc4LcTCnc3JxarUXNrCate51T+oS9hHuyIAmGtyuVwdpYRCIe1aAGCmMsorR6OU X+CLLnpO+APn2A849juXQLscAJhrUqlUHaWuYpcfwPyVN15ipvUtAgHtcqzCFj6fec/JqLmMW3gA rItYLFZHqcHBQdq1AMBMtXT3MHM6j489vjnCvpXP49RphVJJuyIAmDsDAwPqKCWRoIk0gNkTicXa huc4LjVX7Pl8HitNZVZU0q4IAOZOf3+/OkpJpboPlgUAs6NSqbYFBGNVau7x+NootTP4xCD+cgpg NYRCoTpKKRQK2rUAAAcORkQyJ89p12JFVri4OPtpz5+H4VEyAFajp6dHHaXIX2Zp1wIAHBDEJ6Af AhXOfH/2+fPq5su0KwKAudDZ2Uly1Pz582kXAgDciMzIGp3NEaXmHPvElPvJcDEOTgBYgba2NhKl brjhBtqFAAA3kopKsCpFi/3YxgiRGZm0KwKAWdfS0kKi1E033US7EADgRmZFFaIURU6sE1Nk1LW2 0a4IAGZXU1MTiVK33HIL7UIAgBtFdfXMPL728GHa5VidF11ceKw0tTc0Ymh4mHZRADCLGhoaSJT6 8Y9/TLsQAOBGdfNlbWspPp92OdbIgfVgPjKCEpNxXw+ABbt48SKJUrfddhvtQgCAG5c6OrUNz/Hs GEp4Y7f50ssraFcEALOlpqaGRKk77riDdiEAwI1OoVC7KuXjR7scK7Vi7Dafi39Qc1cX7aIAYFZU VlaSKHXnnXfSLgQAuNE/OKhdD+H70y7HevEEAh5rYWpvaARaoANYpLKyMhKlfvGLX9AuBAC4MSyT sTb4cBMfTTp38/mfT1TiSccAFqe4uJhEqXvuuYd2IQDAGRf/IPXc7YTH8NHmLBiTps5k59CuCAA4 VlhYSKLUvffeS7sQAODM7uOhmobneAwfZZvcA3SOoGeUV9IuCgC4lJeXR6LUr3/9a9qFAABnPE6d 1jzRGGel6ON976ezNlXZ1Ey7KADgTHZ2NolSDz74IO1CAIAz3mdj8Rg+k8IbG6VcA0NauntoFwUA 3MjIyCBR6uGHH6ZdCABwJuB8oubYOTb4TIXONt/u46Hdff20iwIADqSlpZEo9cgjj9AuBAA4cyIl FVHKBOmkKbcTYd39SFMAZi8lJYVEqccff5x2IQDAmdALaYhSJsjW25v8jrDT1J4TYT1IUwBmLjEx kUSpxYsX0y4EADgTlpqOKGWathw5onMEfc/J8J7+q7TrAoDpO3fuHIlSTz75JO1CAIAzEWkZmjv4 cOzc5GwRCHROobsjTQGYs7i4OBKllixZQrsQAOBMZEamZppGlDJFTt5+7ChFxrfHT+IhfQBm6uzZ syRK/fGPf6RdCABw5nRmtmZVCht8JmqLz0gD1TEdEgKCKy410a4LAIwWFRVFotSf//xn2oUAAGei s3LQ7dz02X/vzxu7NoVe6ADm6NSpUyRKPffcc7QLAQDOnMnOxQafWXDy9dU5hU7G2excBZ56DGA+ wsPDSZR6/vnnaRcCAJyJycnDsXNzsYXP1+mQQMaxmPj+wUHapQHAlJw8eZJEqaVLl9IuBAA4E5eX j1UpM/KVj4+zn+7a1LfHT9a2tNIuDQAmFxISQqLUyy+/TLsQAOBMfH4BzkqZl3WenuPPTZFxLr8Q m30AJi4wMJBEqVdeeYV2IQDAmfMFhWjRaXbIH8XO43b6rm/2xaHrFIAp8/f3J///fe2112gXAgCc SSwsZiZi2rWAcZz4geMPom8LCE4pKcXyFIBp4vP5JEq98cYbtAsBAM6cy8eqlBnjfe/HG3d0iozv Tkc3d3XTrg4AdB07doxEqWXLltEuBAA4czYnF3fwmbVN7gF60xQZZ7Jz5AoF7QIBQMvLy4tEqTff fJN2IQDAmciMLHQ7twB6N/vIiMrKpl0aAGgdOXKERKnly5fTLgQAOBN6IQ0bfJZh5Pky46LUt8dP 0q4LALS+++47EqX+/e9/0y4EADgTnJSiiVLY4DN74xemvg1BlAIwIQcPHiRR6t1336VdCABwRhCf gChlMZgo5XUmRv0vp9IzaRcFAFr79u0jUWrlypW0CwEAznwfE4ezUhaDWYzKra5taO9IK6sYlslo FwUAWu7u7iRKffDBB7QLAQDOHI46gzv4LAZPsyqVVVlFuxYA0GP37t0kSn388ce0CwEAzhyMOI0N PovBrEqllVXQrgUA9Ni5cyeJUqtWraJdCABwxj00HHfwWQxmVSq5uJR2LQCgh6urK4lSn332Ge1C AIAzu0JOaqKUP+1aYKaYKJVQWES7FgDQw8XFhUSptWvX0i4EADizLSAYG3wWw1nT9jwuL592LQCg B4/HI1Fq3bp1tAsBAG4olUrmdA3u4LMATJQ6nYkm5wCmyMHBgUQpOzs72oUAADcGxBImSjny/WiX AzPFPIwvOCmFdi0AoMc333xDotSGDRtoFwIA3Oi4ImSilBMfG3xmj6f53TwWE0+7FgDQ4+uvvyZR ivyTdiEAwI261jYmStnz+bTLgZniCUZ/Nz1OnaZdCwDosWHDBhKltmzZQrsQAOBGcV0DE6W+8vGh XQ7MlLPAX/27uQuP3gMwSevXrydRytHRkXYhAMCN9PIKJkrRrgU4wONrH2SsUCpplwMAur744gsS pXg8Hu1CAIAbcXn56IRgSZjHGZMhHBigXQ4A6Fq7di2JUi4uLrQLAQBuhKWmo9W5JeEJBEyUamjv oF0OAOj67LPPSJTavn077UIAgBuC+PNYlbIk9of8mSiVX3uRdjkAoOvTTz8lUWrXrl20CwEAbnwX GT068yJKWQrm2THnC/DsGACT89FHH5EotXv3btqFAAA3vmUewOeHKGUhmCh18kIa7VoAQNcHH3xA opS7uzvtQgCAA3KFQtufE1HKUjBR6uiZGNq1AICulStXkii1f/9+2oUAAAf6BweZKIVmCBaD5zd6 XMo1IFiJfggAJuY///kPiVIeHh60CwEADrR097CeZYwH8FkIR1Y/hK6+PtrlAMAY//rXv0iU+u67 72gXAgAcKG1o1G7wHcMGn4VwOKa9iY/8FtMuBwDGWL58OYlSR44coV0IAHAgubiU6YSwYsUK2uUA N2y9vZkodS6/kHY5ADDGm2++SaKUt7c37UIAgAPoz2mpmJPn/ucTadcCAGP84x//IFHKB888BbAI Xmdi0J/TIvH8RqPUt8dPqlQq2uUAgNbrr79OohSfz6ddCABwYGfwidGdID6ilEVxEmiPS3UJcfIc wIS89tprJEr5+/vTLgQAZmpALGHdvocNPovC8/NjfnPzampplwMAWq+88gqJUkFBQbQLAYCZaurs 0t6+JxDQLge4tGLFCuY3Nyw1nXY5AKD117/+lUSp48eP0y4EAGaq8GIdM9tu9vWlXQ5wjDkutTc0 gnYtAKD14osvkih18uRJ2oUAwEydLyjE0/csGBOlyBCKBmiXAwCjnn/+eRKlwsPDaRcCADMVknwB UcqCOfG1USq3GselAEzFc889R6JUZGQk7UIAYKa+Ox2NM+cW7Kv9+5013aUCE5JplwMAo5555hkS paKjo2kXokOVHisLj5VFjxvhp2XRCfLq9tlqq1KdIN2wRrxmo3jNHpnk2jVhrZx8x/BYuXAmLzqg iD49Wnw9VuVhdihVKteAYKxKWTaeZlXKNTBEJpfTLgcARvzhD38gUers2bO0CxlrQP7yM0N3TThe dpQ2Szj+tvHbWd/i1WHRtWtlXuLr/ynOmUEEqg8TMy+75rSCu3oBtK5cFTG7P47oz2mhePxA5ne5 tqWFdjkAMGLJkiUkSsXFxdEuZCyJ/P3JopQ67bRx+E3lijXMKy8Xr/GQkb/yFXIQpZTur7JqXj48 owUuAAPKGi9po5QPOsVZpi18PvO7HJ2VQ7scABjx5JNPkih1/vx52oWMxUSpV4frB1SiPpVQM9ou K8K9JEwy2RDL3SLPgPwt9cuukYo0H+uukPkFS/3C5N3TXUqXNEp1EmD0ZY4KBmCJzy9gJtmv9u+n XQ7MFua4lHtouBJPkAEwAU888QSJUklJSbQLGYuJUh9qUw1bWfBomnp5D4enBRTqb/pWMJd7cOl7 xDpR6i0vnHAA7vnGnRuNUniQsUXjCbR7fI0dHbTLAYBrjz32GIlSKSkptAsZi4lSy/VHKUmFVGe/ rDtftn3P8HYvGfnPwtPDb13fU/OrYP7KpkoPG35/+cgHl7w69PKHEs8weTfrqFVhrNTbYzSeLVkj GVmJur7e1V0i8+ZLvYNl3fJr8h65+55hd4/h7XukZWP3+8pipds9hj29hv1SlWN+QbtpKCmrlS3R /HszV28UwHVKlWpH0HHcvmcNHFnHpaIys2mXAwDXHnnkERKl0tLSaBcy1uRRalgTpaTqKKU51ERi knb9x7NkJEqRCLRm7LqQZojjG9VZS+X56vhfHXfsXMI6TOUoY5aW2Ft47vljolR31jBr9Uy1XfNd vCuwLA9c6u7vx9P3rAT5E5tZmNoVclKuwJ0sAJQ9/PDD5P+YmZmZtAsZa7INvnQPTXDyGE00ZXzd fTQyQmpVJP+wTrCL3YNl0WHDb7E+UjiyvqRK4g9v2Mi8gthxu8SRL2e9rPrTrokqWKkpS52alExA YorRUIWsYVXCKnLJduzxAZeK6xuYKOXA59MuB2YXj9Wrs7oZhy8BKHvggQdIlMrJMbE7QVjHzqt7 VN3tyu4eZVvPyD+rS+Se2swz5F0yurzDjlLve8iYU+I5mtB110ap9nY/udJTs3j1Fl/zdzq55qwU X/u3PJ0oNfKCXsw3ktSzv++rw7rbdj2alg6vDnerv8NlGfO1ZVx3cgBrFpOTN7okJQiw9famXQ7M Lp6PPxOlTl4wsT0FAOtz3333kSiVl5dHu5CxptgMYaOMySOsBR+Z9nXYR5V01oGY+/WY7gSab8o+ Fj4+SrGXodgjvFF3z646bPTw1fvac+xK9+Wjn789S3kNgCPfx8Rp5lZ0lLIKzB7ftoDgQQn+YgZA 07333kuiVGFhIe1CxppClFrjJWPv/TFRKoQVaSS1UiZ0CSXajgpkSAYUjprtvNGeUVONUtfkjTKd Yt7Xc9Oftp1UfI/2o9XBzCqZDH/8AScUSqVrYIhmVQoHpawC+9HGaWUVtMsBsGr33HMPiVIlJSW0 CxlLG6XE0fnynCx5OmskZcmb+3SXgLSZhxVQ2EebDA+jo9S1kUSk7W1114fS8V03tSluZINPvOTV kTsHlyxnH+gSp/dx9oaBNeu4ItSeOUefc+uw+dgx5iEy+8NPocEUAEV33XUXiVLl5eW0CxmLdex8 iks3ejPPFKPU6LElo6JUGCtKrdFzNn58Oyk9C2t4iAxwoeBinfbMuQ+ilLXgCbQLUxdbWmmXA2C9 Fi5cSKJUZWUl7ULGmqwZwnj6o1SJlDlAJRq7wUcG+YhkZOh+02ls8K0JGxuKWG0THL2k3l4jLadG B1/q7qhJWcv1LGcBGCs6K4d5ivGKFStolwNzxNnPj4lSQYnJtMsBsF533HEHiVI1NTW0CxmLoygl YTLPmvGrW6p4r+HteyTuYZrHq8/s2Hl0u/alu1M1ba82ss7AM+Ta/gx4iAzM3HeR0ThzboVsXFyc NSemtvoF9vRfpV0RgJW67bbbSJSqq6ujXchYHEUpEns2aEKLurMTQ5ivSTvMHuLUopS2GcL1FgfR GzVpavloxwN2Oyl3A7fpRTuOfsJbfDSYghkZEEtYB6Vw5ty6OAm0XRFOZ2TRLgfASt16660kSjU2 NtIuZCzOohT7UJPYL18xElzkqsLYYWY1yVPTmWoqUYp9+MpPnc2YpgpMLuqRMw+IqTZw0kuYxRQw rhsVgDHKGi8xk6kzzpxbGYdjx5inG28LCL46OES7IgBrdPPNN5Mo1dTURLuQsSRM06epniZiMk/O gM6vKL01a0Tjx8t75NrYpPmmeqPUyMvKFRtYX8h8TluCNpiF1KrKNO0OlkzwqGVWD3Y8RAZmgnVQ KvAbNOe0Ps6spxvH5xXQLgfAGt10000kSrW0tNAuZCzm2La+m+P00nQn0F2Vuk6V5CUZn6Mcw+Rj so7mm7KbRGlfVnKt/jTzIpLqMV+pCme2+dZI/TXJza92oowUv300cenrSQUwVR6nTuOglDVzEgiY hakdQcfFw8O0KwKwOjfccAOJUu3t7ZN/qpmT9ykLs+TxCbKkVHlhrUKI/phg/q4ODbF293BQykqx uyIkFhbTLgfA6sybN49Eqa6uLtqFAIDRShoatVHK1592OUCHI+uRfNuDQgbEYtoVAVgRlUplc11P T8/knw0AJuZ0RhYzh2729aVdDlDDXpg6m51LuxwAK6JQKNRRSihEq0gA87M3NAK7e0DwfLULUy7+ QVdEUzxkCmaDTNN79uzhWRkHBwfaJUyOFKmOUps3b56zbxoQgMOxxmlpaeH2t2D79u0md88mGI/9 6D2cOQf2wlR4ajrtcoBjBw4csAHQ+Nvf/kb7kjQzeXl5nP8urFq1ivaPBTOVWlrGTJ2OPn60ywHK HI7587TROrAVxzYsS2dnp4ODwzprsmzZMjJbLVy4kHYhk1u0aNF99903l9/x6NGjtC9JM9PU1MTt b8HGjRurq6tp/1gwU8di4piOUi+6uNAuB+hjrVIGep2JVanQsw7MWEpKColSjz/+OO1CAMAyDUmG t2qfF4PdPRixxSeQvc1XUHuRdkUA05eZmUmi1EMPPUS7EACwTCX1DdpH7/HRBgFG8VjNz3cfD0XH TjBf+fn5JEotWrSIdiEAYJlCL6Qxz92zP4QoBaPWeXqy09SZ7BzaFQFMU2lpKYlSv/jFL2gXYr76 0wrjwgoTo8aNsNy4qJKs6iuDs/N95dUlEXYBjrYhjrZnEiXXrglb88h3DCvMM6pbhHywPorUqaf+ uOC06KjqGiGeFQMzoFAqd4WcxCOMQS9HvrYxwla/wMaODtoVAUxHdXU1iVJ33HEH7ULMlrh46YF3 bCYcS8MimqTcfld5XOTH2m9xKEB07VpZwufX//PzHGP6B4saAyYunrxgcGMvt9WD9ahrbdPu7gmw JAVjkNmH/YzjfWEREinHf1YCzIGGhgZyMd966620CzFb0vKVk0Wp62nHp43Db6qot2Ve2ftz27hU +bVrhdOLUs0nJi/+wDsedUhTMB3sJuc8XzTnBF08Pz9ntJkCM9fS0kKi1I033ki7ELPFRKlDR+rF w6LBfqFmtHXXhCW4MmnErpC7VpPi8mXqlw2IYDoFdzenCtIiBFlZ3cZsyTFRavGZLMk1uUQ6rB6i wd76xkTbQ0xgC0CXeTCWQqn8VrO7x0NnTjCAvTBFRlnjJdoVARinq6uLRKl58+bRLsRsMVHK94Te 5x+UpY2mqaVn8rj7rvXqb7osrX6GL8REqWUJ5Xp+uT9Ls3250ajFLgDiImt3D03OwRBbb2+StJlL ZVfIyf7BWTpiCjAr+vr61D2lZTIZ7VrMExOlvPVHKQmzg6ZZ2Omui3M9c8Q1IVF4TV6Y67Ps0Mc2 Bz4WNDN/dPSnZfms9B754OJDHy/1dfXIyurWHh+QFxZGe8W5jS4lBRwUpJ0QFNaMvGxjolfyCa+0 xG7FNXl/sduZI25xPq5nTpSNjUBlhSdc4wI8EnwEFa3XJo1S13o9vBGlYJoiMzKZ+dFBIKBdDpgu J4GA3f9cEJ+App1gRsRisTpKDeJvAdMzeZTSnOv2PqGOUoUJG0fXqXy1R8c9GvvJL5EIpD0ENWZs jOtQN13p9zg0/ld9dI+dS2u0rxOWKGeK6Yhmvsrt+vGnSaLUYJ5mVcq1GrfygTHY9+7x8AhjmIwz a2GKjKzKKtoVAUyVQqFQRymhEGdhpmWyDb60OE1wiitWf6Qs2XFcFvo4uHWQ5B/WCfaNbmlxUVkB y7QfcSwcWRcaTko+Yheykfk0+0g3++Q81stuvP5pJCNFaFNTtfrQeKerJoYtjRvdbWSi1FLdKCUX dhe7ji5JvbM4jsPdSbAKtS2t2pmRj909mMRmX192mynXgOAuYR/togCmav78+SRKdXZ20i7EPLGO nVf393df6e3u723rJ//srG7M8gj5nMkzXtfXna5pM8/IktTKuFTmlHiOJnTZhERob/dTtHr4jr7C suQazQdHQ5f2I+Oi1MgLJjCJy7WeHeEOHWFOwLPv4Ft86GPtYCc934juWXwHwTKFp2Vod/eO/f/2 7iSojSzdFzjLXvWqI17cXvWqVx130auOu+ioG9H7Fy/iKm7fqLrRVd1VrtFVuOyyAWUKGWMbTBlj zGABUkopBBgxzzMGzGwmGzMKzIzNZGYQGvxSEohESoEASUeC/y9OVFRXI/QpjaU/55z8DtogwMno o8t8iYXFBiNmwyEw/OY3v+Gi1NTUFOlCApObzRAyyncOHmGPNP+e33D4fQ77G0S8cnjz2O75vw63 0R08KX9VzjlKffw4EyGwGvh37fzhAQ1uNUNIiGtcwJkOcAo7en2EOgOre3Ba9NFlvqIWtECHwPDb 3/6Wi1I63XnvBbuk3IhSV6ob+Gt/9iil4UWanZmDXUwZ5Sv6zRVeU4Wd7YlQh9vo3I1SHw3z5Q7F fNZ4OJH18UiUEj9tzLVsXLeN6rTQw2VEyxxa+bLhI4B7OodHeOfuYXUP3BUklfKPOeZGcz82TUEA +N3vfsdFqYEB/LieyWGUEheO9rQNdjQejpbawdcTm47zOQeZR9zFa+vrXqvMU0cpzmDjYW+rIHmu w5a4w23ndUJZelsXfbBdij+xBnC8lJJy+0chJVOSLgcCiThZxZ+bCleqByexaAL+7ve//z0XpXp7 e0kXEpgOt53nupk0BDOPm1Hqlf7Ik7oVpVp4UYrX0tPheV00Q/j4cbVhf9/UwR2IAMdbWF3lzyqQ LgcCj4Rh+Zum7qRnzC7hwAXwa3/4wx+4KNXRgVu0zuSkZgjOhKPU+EHX8fyG9aMLfNxY329CfrDE do4FvistR2afTo5S9vsKXdyiCOCgsrOLd+4eVvfgLBxaoMc8y1nb3CJdFIBLf/zjH7ko1dSEk4/O xENRaseeedgip9mtzfLqpIjiuOiWHsPRJz3TtvN/FvJ2PZ0YpQz2TVw4OwbcYDKZHjzLsX8C3ohB lIKz4D6V+BNT3EgqLNlFK2nwV3/605+4H9ra2lrShQQmD0UpLvYEH6QdzcyR7VUrowdNPuUHKcu9 KHXYDCEhaeGjoTDjIE3J0uzNDY7fK7W+0GI/hu/fi1vce31wqQ1NTWNKCjziplzuMDeVXlNnQhd0 8Et//vOfuShVXl5OupDA5LEoxd/U9D0zOmGZOTKudnWl2SeUHh90pnInSvFbdDIz1lb29qYKluC0 /0DeHq3r0dVsdHmabTyuZiO0/Dv4vm9EO3xwg6qqxv7BJ5YjSsG5UAwjOXpDX2kb9qKAP/rLX/7C RanCwkLShQQm/euDpk/u7sq2Zx6nU+2WnrIu95z/Z3HL4bLcwZMKRinLtzXqgg8fePjOM9ubZP+G Gmu+cm+7u7gcfaXADYura7wpKWw4Bw+g5ErJ0ZW+toGhkx8G4Ft//etfuSil1WpJFxKY7KfdOd0c 58pBdwJxl8ABwZu11RHOYSa05fWRpk4HT8pvEnX4bfUfde3RB4+NPnp23q424+DgP+umLP7klcBI uB7R2LKAfsPgntK2jsMeCAw6nINniBUqhzTVOTxCuiiAI/72t79xUUqj0ZAuBPYZNt91DbaU9zbU 9nd0zUys6E9+CABxu3t7kemZ+1NSSvW1tDTSFcHFQSlYhzSF847BgwYGejo6Gs4z/uM/LAt8NB1y zu+Tl8cuLuIgP4BLqm1g6HB1D+2kwNNopePcVOMrFy1cAE6joiK3ri7/9esX5xkSyS//9m//p6go 4zzfRK2O+/nnT2dmJklfEgAgwGw2P84rPIxSckQp8DDnM2W4UduN5tJwLm1t9aWlmnPmKI+M4mJ1 aOgXERFfI0oBXE6jM7PocA7eJhJKU5WdXaTrgkA1NPQ6JyeVeIjiRlNTyc2b//j112BEKYBLS1Fe dbjhXIEN5+AtnwilqZK2djP6TcEpzc/PqNVPiIcobnR11XE56sGDnxClAC6tqYUF/uca92FHuiK4 yARX+gpetKB7J7hvc3NDLn9IPETZRkjIv6KirnI5ClEK4NJKr6lDh3PwJcutUk5pKqehyWQykS4N AkNSUtTDh+LYWPJDIvk+MvJbW45ClAK4nN6trPDbct6SyUhXBJeFc5pSVlZv7aCfMJysuDizqSnf H0ZKyt3o6KuIUgCXmbahifdZhikp8CnuR84hTT3U5s0tLZOuC/wdohQA+Inl9fVwVbq9l9SNZEQp 8DWKcew3FaHO6BkdI10X+DVEKQDwEwXNrby2nLhxD8igFWqHNGW7rc+IrVPgAqIUAPiDpbU1qX1K imFvyTAlBcRQTit93Egrq1jfFjjrFABRCgD8QfbzxsOPLQZtOYEwMcPQToEq5lnO1PsF0qWB3+FH Kbn8YU4O6+OhUsUhSgFccnPLy/wT9yi5nHRFAB/DUlNpxnFu6jar6RgaJl0a+Bd+lNJqCZy9rtEk IEoBXHJsdS1OigE/9IlUKnFqkmDrOrWt15OuDvwFohQAkDXx7h2/Jyd2SYG/ETMs7ZSmYrJzRmdm SZcGfgFRCgDISi2twC4p8HN0mkpweqqopW13b490dUAYohQAENT/doL/wRSqUJCuCEBYaILKuSM6 N2Jz8sbm5klXd/GNzc0xFVUDE/4YDBClAICUPYPhoTYPU1IQKEQikYRROS/2cUPb0IRWCd5jNJke PMvhrvNdTdaO/+1SQ5QCAFLqe/t4N+6xV+PjSVcEcDKJXOV8Z5/tU75tYMhkNpMu8AJa2diwX+ce nd81n0eUAgAiVjc3I9QZ/ChFuiIAd92UywW3TnEjubgUvac8bkevt19hTW096XIcIUoBABHPeD05 uRz1iVRKuiKA06GE7uyzjcy650tra6QLvFDs96fcZjX+ttUfUQoAfO/t/Dv+5w6lwIl7EJBCkpK4 XwQEA5VUlV7S2r65s0O6xgui5c2A/dr2jY2TLucIRCkA8DGD0fikoIjf3px0RQDnImYYidDuKW5E pmfW9fShn+f5rW5u2q9qRm096XKOQJQCAB/jPll4d+2xVCp2SUHAE4lENMMKdkuw7Uiv7urGDNU5 yUrKbNczws/W+BClAMCX3n/4cJvVHH7KKJCj4OK4KZdb0pSLQHUnPaO84+X61hbpMgPS8vr60+Iy +8XsHB4hXdEhRCkA8BmT2ZxSWs77cGFvxCBKwUUTlirczNO+azq36cXM4hLpMgOD2WzWzc5l1NaH q9Id7pQkXdohRCkA8JnWgcEjHyty7DaHC4tSqGily0DFDe7Xilfjb40mE+lK/dS2Xt/yZuBxXoGr C+g/cRRRCgB848PGZmR6Jn+XFOmKALwrKCiIlisF+3naR8yznJquHnRO4JtbWi5obr3D6zsnOLiv IV3pPkQpAPABs9nMVFTx3wavy2SkiwLwBS5QUYzaVQcq+0gtLe8cHvHDU1F8ZnVzs+XNgH1vuath Xzy9k57hJ5cLUQoAfKDpdT//zVCMBghw+bg6cYY/IljNs+eN/W8n/OoONa9a39pqHRhMK6s4IUFZ Q5SYYfj70NoHh0iXb4EoBQDeNre0zL9rD42k4DITy13e4ueQqdJr6rpHdVs7u6RL9oqN7e32wWF5 eWX4SZeCy5+0gqXkctsDQxnG/n89ys03+cFmM0QpAPCqPYMhPr+Q/8Z4S4ZdUnDZ3UhmKUZ14qqf xNo1ncsbz3tfTS0s+ENsOA/9nmFkeqai42ViYfGJL9y2lkcxAvf58r/GHzqfI0oBgFcVt7YdWdrD bnOAA1dkMv7mnxPHXU2Wpra+bXBofnklUGKV0WSafL9Q39uXVlYpPdrQ4PgQJVa4nL6m5Ur7VyYU FJnNZl++ImeIUgDgPUNT0w5vj6QrAvBHlkkqBReo3M1UEuuma3l5ZdXLroGJyTV/avvJZScu6XWN 6ErbOlJLK7g63X1RlnbxlneJE+9JEYlE/Gs1ODnlm5fmCqIUAHjJ8vr6PU0WP0cFMwzpogD8Wphl W7Xanc1UDiMqM5tLVsWtbW0DQ+Nz8xvb274p2GA0Lq+tj83NtQ8OFTS3JheXHjnOwJ0JqP3dUOpf TvP+QCtU9u8gKynz2utzC6IUAHjDnsFwZDsE9/smzogBcBuVytLubaZyOW2lzojPK1RV1XAJp763 r3tUNzw9M/V+YXF1dXNnx83WoCazeVuv/7Cx8W5lZfL9e+47dA6P1HT15DQ0pZZWxGTnnLhp/Jg5 KOs0FCtOPkurXpFUyv9uutm5M3wTT0GUAgBvyG18gaU9gPMTKxRcprL+PTr1VNXxIzI9Myoz+0GW lktEv2bnxmrzHuXmP84riM8v5DJYzLOcIz11PTSs7SAsm8lDkpLOeWUo5nBiKqmoxERuxxSiFAB4 XPvgkEOOuoKGnADnY+2dblkIO+bEZD8d1tknSqHmYqEHL4ht0759dI/qPPjNTwVRCgA8a2ph4UgX KYa9mZpKuiiAi4ZiGMt+IUumYt2/B9A3g7ZmJ1vkC0nzYh856179/Sf9NTt3z2Dw3nMdA1EKADzo w8bGgyzt4TuqEmcWA3jdFZmMTlFaWgTYtlcxp2iw4JFJJ9szWo5vPuvep7O/cN665/PeVz57aj5E KQDwlB29/klB0ZFfTpXYIgVAgEgksmyyUirFCqXlBEDmYFnw9LNYtH2iyZqUrP/T0l9UolDRcvUt 0mv3/NcSmZ7ps1sX+RClAMAjjCaTsrLaYZKfdFEAIOy7xEQua4WkqSm5PNSys50J44b1X8TWQaco b6amXo2PDwoKIl3scYKkUn6ayn/R7PsaEKUAwCPyX7Q4zPnfPDgzCwDAeyhejylujM/N+7gARCkA OL+GvlcOiwKUTEm6KAC4LPgNuOJyC/aMRl8+O6IUAJxT5/CIw3zUMYdnAQB4HJ2i5L8LVXd1+/LZ /TZKUdRXW1ubvq8HAE6ld2yc3+6Y+91QrMAtewDga/wWplJV+vzyis+e2j+jlETyZV9fp++LAYBT GZiYdDjqncLpMABAwucMw09TT4vLfNb/nB+lMjISWfaJj4dWK3OIUhER3xQWarjajL5d6wSAUxmd mXU8txS37AEAORL5kf3n9b19vnlefpQiO2xR6v79H0JC/pWcfFcs/ubNm17fXAQAOK3xufkIdYZD 85lPpFLSdQHApcZ/UwpXpU++X/DBk/pVlIqKuhoa+s+Ghtz8/NSwsC+x7RzAPw1PzzjmKIYVIUcB AGnX0tL4y3yx2rwdvd7bT+pXUer69c8qKzU1NVkRET/iDj4A/9T/dsJhfxQ3rsXGkq4LAMDCoc1U 9vNGbz9jTo4yKyuRGxpNfHp6HMERGxv28GFIY2NedPTNBw9+pOmv9fpdb798ADiVrhFduGOOQitO APAvDifjdI/qvPp0y8uLExNjWVlpKlXszZufR0R8HRHxjS/Hla/+349X//vGjX/k56dVV2cmJUXc vv0tTX+p0w169YUDwGm1Dgw6Hs7FsCFJSaTrAgA44kYMy1/mi0zPfP/hg1efcXi4X61+1NSUX1qq un79f2/d+ocvx48//ve33/7X8+c5XAFZWQk0fYXLV2VlWq++ZAA4FbPZXNnZ5XTOKXstjUAHFQCA E4UpFPz3q7jc/O1dby11bW5uPH16j+wuqcbGPO6f5eXq8PBvo6KuXv/5Mwn9TeSdn+Ie0Zr0xBdN lVNTY2ZfdYcAAAd6gyGj7rnzfBTW9QDAn9GKI+9aqqoak8nk8Wfh8klKygPbjBDZwdUQGRn84MGP P//86ejo68nJkdnZt9PTup6e5rKyLC7s3b/3c2VF7vKyL+5qBAC79a2t5OJS5xyFfeYA4OeCgoIc Nk1VdL70+LPk5anKy9XEcxQ34uLou3e/u3XrH7elV+3lGQyGd/PTg4M9A2+6pqZG6+qKou7fKC7K 2NnZ9vilAABnc8vLv2bnOq7rMewVmYx0aQAAJ7uRzDqkqd6xcQ9+/+7ulqysBOIhihsq1UOJ5Kvw 8K+uBf9PzIMwwWp3d3eGhnrHxwdrawuio268HR/24KUAAGc9o2N3jjaPsu2PEolEpEsDAHAXrVTS vDexCFYzs7joke88Pz978+aX8fHhtvH4MU1qxMVRFPX13bvfBf/09xvXP3v8OOKYsg2Gvf7+lzpd /6NYcV9vu0cuBQA42DMaC5pbnSejaJwLAwABSHz03SwqM3tpbf3833Zx8V12dhLx+agmyxnKyTT9 ZXDw/3A5KvinT5eXT86K8/PTXJriEuDY2ND5LwUA8C2trSUWFjtNRuF8PQAIYLTySN/O2Jy89e3z bhbyqyj1/ff/df3nT3/88e99fZ1u1r+6ujQ6+vpRLLW9vXnOSwEAdq/G397VZDnnqDCGIV0aAMDZ iUQih01TSYUl5zxTZm3tw9OnUXJ5rG38+mtoXBzlyxEbGxYZGXz37jWp9AcuRAX/9Pf8fM2pXsLE xEjzi8qa6oLzXAcAsNna2c1+3ugcomg0MweACyEkKYnft5MbivIqg9Hoqe+fmnq/pDjFlyMr8xGX oH658b/c+Pnap3Fxt89Q9uBgd/zjcE9dBIBLa3ByKjpLK7Cop8TNegBwcYQwDH30XS6rvsHkocaV BKPUjeuficO+MZnOEguHh/vUbDx6I4BnTS0sbGzvkK7CR7Z3d3MaXwhMRjFqiVxFujoAAA8LS1VZ 3t94b3c5DU0ead1JMEpdC/5sbW31bGVPTY2VlGSsrXn3YB24VEpa27m/WTHPcrbPt4bu/8xmc/eo TnAyilayIQoF6QIBALyCVjg2m9J6Ik2RilLcGBp6feayJyd1hQXs6urKOV8+wEdrtCi25qj9Nm66 MdIVedHM4lJKSbngbXrc72tX4+NJFwgA4EUUF6U8kaampsYrKwtsIyYmJDk5wpcj/jH1y40vkpOj 7TXYRnFxdn9/j5svYWCgm1E8NBj2TvvaARxYc1Qb/69V2+DFbLWxubNT2NwaLrAtyrIzSixHxwMA uBQcJqa4kf288VRpiosfSmVce3uVv41ffvm8tfW5m69iaKg3Pl56pksIcMg5R3FjfvmizXbu6PV1 PX2CvQ5oHAcDAJcPpRRIU0a301R+vrqzs+b16xd+NVJTH4SFfdHZ+cKdlzA81FdVldvZ2XiOqwgg nKPqenpJ1+VJu3t7DX2v7mU8E5qJskxGUWgbBQCXEs2oHN4S2aoa/Z7hxAeOjw8XFCiJByeHwUW7 kJAv7t373p0oNTs7MTjY/TiONhoNZg/dxgiXEPfbR26T4/1rNd3uLjH7vx29vul1f1RmtmCIopUs 9zaCnVEAcJlRCse5qafFZZs7x93HbTIZlcrHxIOT85BIvo2OvuoqSpWVaVWqeNuQyx9yIyEhgmEe RUWF6HSDXrvAcJFxv3ew1bXOASOxsLh3bNz9OV7/tLS2VtrWEZme6WImyrKidzM1lXSZAADkUU5z U3G5BSvrG66+vqwsu62tgnhwchjp6U8kkq9+/TU4MvK77u5Wh5rfvh1xNY1248Y/pqbGvXyN4QLa 2tmVlZS5jBlK9UNtbn1v34eNADuZyGw262bn1NV1x7w0rOgBADignfZNPcjSzi0vO3/l3Ny0VptK PDg5jJ6e57dufcHlqJiYn27fvmo82sWd+2hQqeIFH/jkiTQ8/CtEKTitDxsbj/MKjw0b+yNcqVZW VveNje957nABL1n4sFrT1ROrzTvuFTGsWKEKCgoiXSwAgN+hGZVDL/S7mqzRmVmHL1MqhTMJ2XH7 9o/37//ARSmK+urDB8fbpmpri5ubSwUDWEjIF9wDEaXgVOaXV2Ke5ThljBMyFfcXqrC5dXh62t8y 1drWVnP/QHJR6UmxkKW5ECXFHa8AAC5RCpVDv6lwVXpz/xv7F3CZpKmphHhwchgFBQxF/YvLUTT9 VX9/t8OLWl1dycxMEnxgZGRwVNQPiFJwKm8mJu+kZxzdeq2mlJZmSrdkjv1vBccddYamtv7lyOjG NrETi4wm09v5d1Uvu5MKS04smFaylEL9CUIUAIAbaLljmuJGXlOzwWhcXl7MzEwmHpwcRl9fo21p LyLim5KSLOdXlJHxlPsa5wc2NRWHhf2Te2B4+JXFxfe+v9QQcMxmc31vn1PMsKx58b8sJCnJMsd7 0iSV5GCDenFrW49ubHlt3dv16w2Gyffvm/sHMuueC/aGcl7Lsy79K71dGADABRPKMBKnrVOykjKV 6smrV03Es5PDuHfv53v3vr9//4fk5HvOr+XVq5cVFVmCD6Sor2NifoqKupqUJPBAAAdcDsmqb3DO UbSLpHE1Pl6sUNJOJwscM6KztJra+pquHi5ZTS8s7pzvCD+TybSyvqGbnWsfHC5sbuUym1SV7mYl lhzIqCkZQhQAwBmJkx1/pw5/mqDVptbV5fvV4EoKC/snl4ju3Ak2mRz3n+zu7iYkRAo+UKWKo2nL 7X5S6fcGw8l9tOCS+7CxKbgQRqecHDZuyVjLTbLuTVI5h6vU0nIuXxU0t1a97H7R/6Z7VNf/duLN xOQANyanBq2jVzfWOjBY39tX1t6Z19TMVtXE5Ra4H5yOhiiWUqg+x915AADn9l1iIn/Xx/3EB6mp UdxIS+NGtJ+MyEjLLXsUdWVzU2BxpLu77fFjiYsHXrPuUf9ydnba99cWAsvIzKxzg0rud42bcrn7 3yQoKEicprQcJu405Ut80Af/DElK8t5lBAC4hLg3f/vb/iMmsakp398GF+1o+svR0TeC9Y+MDBQV KQQfmJJyPyLi6+rqQh9fUggsRpOp6mW3QPxg2PPM29AploU/y18ut9f+vJSgLGXIlUhQAABeJbFu 9oh6GpeSep8/DmaoSI7IyGvV1fmuKh8dHbDOSgk/MCHhji8vIwSc1c3N1NIK5xBFMWpPPUVoguUu D9v0L+2FsCQQnxjrS1CyYQyD3lAAAD7DvevSjJJKU/CHRM7UdXVtbW1ub2+RGs4tpPhMJpOrB/b3 9xj9rLcP+JWhqen7mYJH93prJ/YVmUwst5xnZ71vTi05zX71Y7OTNaoxakqhupHMnlwHAAB4B/cm LNgwh62qWdvaIl0dgMfsGY1l7Z2C8zlUqk+jyOeWX2EYLgJRCjXFqCz7rKwpy7Y4ePhPy9jvybD/ NQqVWKFGcAIA8DdBUinl1BGdG/c0Wb26MdLVAXjA9MJivNBxMNyP/XeJiaSrAwCAi4D7tVfwtm5N bT3B1s0A52QwGqu7esKdGgjYO5kDAAB4ynWZTHCL7P3MZ6/H35KuDuDU5pdXEguLhSajWHc6RwEA AJyWrU+C4O6prPoG7J6CQGEwGut6+gS7WXI/3ldkMtIFAgDARRYmdMQMNyLTM1veDJhMJtIFAhxn bG7ucV6B4I1vlEJFujoAALgURFLp/t1DTiOpqGR6YZF0gQACNra3tQ1NrroH4N43AADwMZphBI/D CFeqi1ratnd3SRcIsM9kNrcPDt/TZAnkKIYVMwhRAABAhqUHjlIl2FQwOiu7c3gE631A3OT790+L y1xNRomTsagHAACE0Qwj2CqBG08KikamZ0gXCJfU8tp6Vn2Dy37gco+dBQMAAHBOIpGIYlSCn1nc UFZWzy8fd9oLgGdt7+6Wd7y8zWoEG2/SShaH+QIAgB8Kk8kEWyXYNlDlv2hGwwTwNqPJ1PJm4H6G 4FF63GBpOVb0AADAr1EKFe1ivS9CnVHW3rmOBungBVyIejkyGqvNczU7SinZT6RS0mUCAACczNot QeDkPnugKu94iRNnwFO4ENU1onuUky8coqwzpTflctJlAgAAnM61tDRX633cuKPOqOjkAtUO6TIh gJlMpp7RsbhcFyHKsr1cje3lAAAQ0CiZ0tX0lCVQpWdUdLxc3dwkXSYEGIPR2DUy6qpvuXV7ORfj cZQeAABcEGKFWrD9lG1IVek5jS9wlx+4Y1uvb+h7/SBL6+rHiftJoxRqkUhEulIAAAAPoxj1MUt+ trYJozOzpMsEP/VhY6OsvTMyPdP1jxBLKdlrsbGkKwUAAPAiiVwleCCyfSQUFHeP6vaMRtKVgr+Y WljQNjRJVenH/NhQjOqKTEa6UgAAAB+RKJXHB6p7Gc/KOzoXV1dJVwrE7O7tdQwNJxYWH/NzQitZ mmG/S0wkXSwAAAABFMO6akJlH4qKqtfjb404zu8yebeyUtzaduxa3n6rKHQ5AAAAoC0zVCcEqugs bXVX9+LqGuliwYt29/a6RnSppRUn/TywYobFch4AAACf2NqH6vh96dyQlZS1DQxt7qAh1cVhMplG pme0DU0R6ozj//RpJUvJ0eIAAADApWCGsex+OXYblcTaPyG9pu71+FvsTg9oc0vL5R2d0cd0NthP UJZ7P8MYhnS9AAAAgSFIKrV1Tjimvadt3NVk5TU1D05OIVMFkPnlldru3if5RScu7FqaRDGqYIQo AACAM7mZmiqxHOd3wiQVNyLTM5/VN7waf7u7t0e6ahBgNpunFhYqO7seuT7n5XAaypqiKSQoAAAA TxCJRNZJqpNmMKzjNqtRV9d1jYyu48RkP7BnNI7OzJa0tcdk57jzx2fZDcWow1JTSRcOAABwAYUq FLRCfXxDKv5ILCyuetk1PjdvwPKfby2urrUODLLVtSfuJD+YhrLuhlIoSBcOAABwKVAMQytYiXvz VLblv/SauvbBoaW1ddK1X1jbev3g5FRxa1tsTp6bfy62/eQUw34ilZIuHwAA4DKyHpTs7tqfbcRk 52Q/b2wfHH638sFsNpN+BYFtY3un/+1EaVtHYmFxuNt/BNabNC0hCg02AQAA/ESYQmHZnX6aTMWN +xnPNLX1L16/mV5YxCKgO7jwubC62qMbK2xufZxXeKqrLWFY6x15apw4DAAA4LdCU1S2RgqSk7p9 OgypKj2psKSgubVjaHhmcQnJym55ff3V+NuKzpeK8qoTD3MRTFCWPw4F+pMDAAAEkusy2X779FNO VdnGbVaTXFRa2NzaOjCom51b29oi/YJ8ZEevn3y/0Dk8Utbeqaysvp/x7AxXzxafuBGKhgYAAACB LyyNpZTsGaaq+OOuJiultLzgRUtz/5uRmdmltbVAn7kymkwr6xtjc/O24KSqqnGzZYHgsPZTtQRX LOEBAABcVJ9bb/3bj1VnzQz8wWWPtLKKnMYXtd29XSOjXCxZWlv3tzah+j3D8tr65Pv3fWPjDX2v CppbmYqq2Jw8qSr9nC+fPkhQXHwKTVCRfqEAAADgOyKRiE5TUYxK4sYJNacdEeqMWG2erKRMU1tf 2Nxa093TNjDUqxsbnJwan5ufXVpaWltb397WGwxnrt9gNG7u7HAZaW5peXx+nvvOPbqxtsGh572v SlrbM+uep5ZWxOXmn2V304kJitmPT7gFDwAAAGwsh9QoVLSCtbSL9HT2OGaEq9LvarLuZz6LztLG ZOc81OZx+Sc+rzChoCipsCSxsPhJflFcbgEXzLj/Nzor+17GMy4d3WY1PqvQuvHJ0nRCrFRTcnlQ UBDpPysAAADwd2EyGaWwHP9n27juqQXBABgHr9cyuCvAMCKRiPSfBgAAAAS2T6RSSi6nGDWlsO1d 99huK7KDtr8WRiW2LHQq0bIAAAAAfONaWhqdppLIVYczV75dHDzVXJO1xzhrm2cTW6ebriM1AQAA gP+5Gh8vtnRfV3IpS2xdJZRY57LsU0CW/6L0zF53Wzo6XJKzpiaKUVGM7RkZrhIRTrgDAACAi+gT qTTYmnYomZKSy+kUJS1XhykU4jQug6nFaUpawXL/wiUi7r+Hcl/GfXFa2k25/LpMhpU4AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgBP9fzeZRfgKZW5kc3RyZWFt CmVuZG9iago4NQowCm9iago8PAovU3VidHlwZQovSW1hZ2UKL1dpZHRoCjc5MwovSGVpZ2h0Cjc4 MwovQ29sb3JTcGFjZQovRGV2aWNlR3JheQovQml0c1BlckNvbXBvbmVudAo4Ci9MZW5ndGgKODcK MApSCi9GaWx0ZXIKL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO3debxVU/8H8HOn5tIcEkUpoolI hkRS0VOoDEllJioVxSMkpAyFhIhHo6hQoic0GKKnmTRHA83Dbbq3O67nnDtwu3efe8/Za6392Xvt z/uPX/f3e73s813f8/387j1n7712IEBERERERERERERERERERERERERERERERERERERERERERETk nDseRVdA5EJ/iEvQJRC5z0QxAl0CkfvcJDagSyBynzLJ4jx0DUTu87kYjC6ByH16iuXoEvwhrlMZ dAkUhcrp4nR0Db7QTwxDl0DRmC/6oEvwhe/FvegSKBq9xQJ0CX5wUpo4A10DReMMkV4JXYMPdBa/ oUug6CwTd6JL8IFx4mV0CRSdJ8UsdAk+8Ke4Gl0CRae+SC6NrsF4DcWx4ugaKEobRSd0CcYbKGai S6BoDReT0CUYb4F4AF0CRauZOJiArsFwZVPFmegaKFoxO8W16BoMd4NYhy6BoveWeAtdguHGipHo Eih6rcWOGHQNZtvK38lelJDIG1y1Ok8klUTXQDbwBle9BojZ6BLIjk68wVWrb8VD6BLIjjLJoj66 BoOVThF10DWQLTPFk+gSDPYvsRFdAtnTUyxDl2Cwt8Tr6BLIHt7gqtPvoh26BLJpAW9w1aaeOF4K XQPZ1Ic3uGrziJiDLoHs4g2u+swVfdElkG3LRE90CYYqmSzqomsg257knTSaXCe2oEsg+3iDqy6j xRh0CSSBN7hqslG0R5dAEkaIiegSjFRHpHDTWi+7hDe4atFbfIMugWTE7BSt0TWY6CvRH10CSeEN rjqUSBLnomsgKdeKv3iDq3JtxDZ0CSSnWKJohq7BPK+Jd9AlkKRJYji6BPOsFx3RJZCkTmI9ugTj 1BKp5dA1kKQyx3mDq2q9xHx0CSRtFm9wVW2WeAxdAkm7kze4KtBybYu/fy5+TJwPLIXUqMIbXBWY muc7jGvEn8BKSJUFoje6BO/7I8/uda+I94CVkCp9+FFRWiWRJxhrxE3AUkgV3uAqr12eYJwu0soj ayFVlvMGV1nP5AnGfeI7ZCmkzGDxOboEr5udJxificeRpZAy54kk3uAqZ9c/wUg4LBpDayEpzQb+ 86Tdjfy0KKem+CcYV4mdvF7Zw74U7/7980u8wVVOlzzBGCE+gNZCcvoI0SP35+a8wVXOS3mC8avo Aq2F5FRMFkkNcn6O3SmugRbjdQvFntxgVBfpFbHFkJz/CLEh9+Lot7kLkozYw+KL3GDcLX7EFkOS Lgn++p+e8zNvcJVynjjySm4wpvNiZa9bHUzGgOwfix3iDa4S7hTzRuQEIz5RXAiuhiT1CgYj7bLs nyfzBlcJb4nhucG4Quzh716PK58kNokd1bJ+7swbXCUsEzflBmOYGA8uhqSNE9NWi3lxoR/LHOdG SLYVTxGn5wZjpbgNXA1Ju0gkXXxYDMv6eZb4N7ga72om9gRygnFKZkZldDkkbZXo01lkZm3LfadY iq7Gsx4WM3OD0VP8jK6G5N0vVgdGioO1Alk3uNZAl+NVE8Tg3GB8LJ4BF0MKlDsqLk/4USwLXU64 kDe42rVeXJsTjLgD4mJ0NaTAWDExUH1P1uWEfcU8dDUeVS5TVM4JxqViXyy6HFKgqUiuGGiVIbqH rpzmDa72tBKbAjnBeE5MRldDSiwV/UKPqAxdTrj8n6ttKRqPiym5wVgmuqGrISXuEWsDgZjZocsJ eYOrTZ+KR3KCUTUzsyq6GlKizBFxZSBQcYuYHjifN7ja86e4NCcYd4gl6GJIkTGhvwMCFx4X/QOb xI3oarzoZJFeOicYU8RQdDWkSGNxPHSq9n6RdtlLYgK6Gi/qIFYGsoMRu080R1dDqvycvTP3BPHX DbzB1Y7ns77tDgWjmTgQh66GVOkpNoSuky61WizYyxtcbfha3BPIDsYQMRVdDClT6pBoFfq37mGR wRtcbTggGgWyg7GYX3ib5A3xSda/nYXgDa7RO1skxweyglE5I/MUdDWkTgORmv3l+6hgMnilT7S6 Zm9+EAxGV7ECXQyp9GPOXqsJi4R4EVyL97wmRob+CQZjgngBXQypdIfYnP0XVPU9vME1aovEraF/ RoiX94jL0cWQSiUPimuzf2qVIcpia/Gc+CRRO/TvCDFfJMajqyGlRokZOT+1vxNaiAc1EQeyft2O EKliGroYUqu+SDsZXYNX3Sf+m/XvCCHEXeBaSLXvuHueXeNyLo8KBaM6uBZSravYwhvP7PlF/Cvr 32AwfgGXQsqV2C/aoWvwplLpIvukXjAY3MvRPK/wJiV7Lhfbsn8IBuNKaCWkQz2Rzj+Q7eifu2H8 CHGYlyYbaB73Q7JlqhiY/cMI8Sm2EtLiZrGNtxLY8Lu4KvuHy39tga2EtCi2N+fbFYpGJZF5EroG 0mq4mI0uwYPahjZZIZPVyczg3rVRe1p8iC6BNPuaO1xE7wvxELoE0qyT+IsXh0Zrt7gIXQJplrBL 3ICuwWvOEKnF0TWQbi+IOegSvKYzdx70gTMzM2qia/CYl8Sb6BJIvzleume5fN0WXXoPfe39j7/6 YdXvf+3cvXf/wcNH9m3f+Mv/Fv53+thh/Xu0b3629q14F3C/HD+4Qex0/eU+Made1n3IxEVbj4tI 7F/x+ejHbrlY1zm42MN81K0fxO8QndA1hBdzZsfBn/yWFFEg8tvx7eheV6vf86m+OMLbWPxgqPga XYKl+CYPjv3piK1I5LVr9pD2StPRU8xXeThyqzMyMs9C15Bf1X8NW3BMOhP/+Ovzx5ur+oNxDO9N 8okv3PVOV7nlvc0KM/G3Y98MvlzF+Yelbv7TkxRqL3YXQ9eQo2TrESsydaQiR/K8AedIllg8RZyu ZK3kdnF/ilvQNYRUf3BuZF87yfn9jbYlJKq8WOxWtmJyt6dd8HGy3qDFOn9VnOjYzO62v8x9WMxS uW5ysdPSxdnQAuq/sNaxUOQ4/vltZWzVOl48pXj15Fqfi1dwL1617zKnU5EtaVpnG39TrRNt1PeA 3Kmd2Ae6XrTEzV+kYWKR5cDoRlEWXC5TVNbSCXKh2K2iK+J1G76TCExFtmUPRPVx42qxWVc3yH2e FN85/poJN3+PDkW2pPFR3Hc0KOsJ6eQTp6YJ2e/3o3TK0zvQgchjUedItxGaIfpp7Qu5ywwxysmX azolFZ2FfLY+Wj6iyv8Ul2nuDbnJteKAzFmv6FwxFx0DK0ffiGDDlJNFuvb7PchFYn8Xdzj0Um1+ QEcgnJS3axZVfAexyoEWkXs8nv18Xt1ibgSdtIhM6rgiLjR+TrznRJvINaqlivP0v8p1v6JHvyjp H55Z2ALminv1d4nc5BPxhu6XuGgBeuwjkTKqUvglHBDRnhEkj7taJJbS+gK1P0aPfKQSB4X7IqKO SOb+dD4Ts0nofKpxlTfc9gVtYbZ3t76t+zZnPonlin/9t1Gu36nCeI+KxdqOHffwIfSsR2nZxVbr GOXs6Z5BwULud/IFyUKVFNFQ06EvXo6e8+hljq1YcCGLxG2aWmSlxJ5gHdx0G26KeEvLcSu8nYGe clv23RWTbyXxSaKOlhZZ6xWqgh/24a4Uh3Wc1e2+Bz3hti3K9yu0sTiQPysaxW0KlsAH+7jAenGP 8mPWmo+ebhmpz5zw2fdeMVd5g8K7LVTBFQ6+IIXRTyxVfci7D6NnW9KKBnlW8554TnWDChH6YPY/ B1+Pwql0XFyg9ICnzEbPtbzUJ/85c7HKyWd5tgm9ekfnXo/CmyjGqjzcLfvRU63E0vo56ymVLtRv hRvW/OBLr+cuua5wuThSVtnBKkxFT7QqSffktme7su4U6cLQK+s85UpRWKPufNKFf4DHWaWPyoWW 1E/MUNWdok0PvuwOPtLMJfqIFYqO9GAKepiV2hT68PWRGKSoO0WrHTr309+xl6PCVUhS80DSMlPQ k6xaSp9AYLO4WkVzIvJu8DUTyzn2clSED8U4BUep7/jGgg6YeprI1PWUpgJODu3i+7xTr0ZFai6O yb/5t6l8tIV7bBRrFXQ4MiOCr3f8ZMdejor0i+gle4gh6AnW5isVHY5EudBGdHquXDPeybW0HLaX +EXuACUmo8dXn3Sn7msNXW+e4eT1iuZ4IF3PrQEnHRPNZf77KovQ06vV646ccSsW2oxuqhOvZJ59 QtMVye+LSe0f6PfYE089+8KIF5975smBA/p0vbRWpN+PnPs7enQ1m+7EqYV7Q690oQMvZKDQJclj 1B4y9vxBs39a81eaxd0TSTs2Lp//3vVFfi6/Gr9Js25Hl3z5ZMNIN/S0+UasD76Ok9fxmuTpYO8O qdu9IL71OwvXHyhiJlK3Lf28d/VCjtLRiUeFuUDihu/ea6fvuYWdQq/h3CkTs9RIDzbvLjXHimkx bW1ypEPx148DLe75zNIV+agLpx1f/1krTR84FgcPv1zPoX1gVrB7SnYvqP+fX6N7zHzmlnl3W/2l fZ8372C17+jqCTo+5l0dOnZnDQf2h+tD7ZPfvaDF/L02RiJtzQsF7oIdoHToPGL/d9dIvwX5hba8 3qz3U4zJ4rYL+Y/fdeYdtDkRGev6n3j7s7mn9QqX+N25km9CPg1DR71P7TGd8Oq3LrE52L+0+X// r5dHv5TYkX9KTETy4rp5jjVUzZh50Y4xSncn/Ch4yN3OPZNBGbfuv3pT1Cs5+XvJzQG3/HP1yKNq FuFNaT+drm6+aoW+VXHu8nZ1jAnGWaulX/PgsJxj3adgAV62tn6hrY7GmODhjkT2dCd3MSUY1dYo eNEjQ7KO1dVv30cVsCGCpzFFpEpS8GgjFB3MUYYEI1bNI1N3tQseq4Ofzl+E8bOizZefDx4rpbCT qK5lSDAeU7T5+JLYwNU+Od9dqPQhSqarTOjqA28+tMmQYKxQ9LJp7c4x//qoSKxWMl39g0fKrKfk UE4zIxhlld1kN2qzqiN52/HKCoYrIXRyysGtSFQyIxg1lb3uTmVH8jgVX0z1DB2omYIDAZgRjMvR 5ZpHwe6mMb8FjzNf/jgQZgSjNbpc8yj4ZNAhdJw28seBMCMYTdHlGidTweamPwaPI3nLPY4ZwWiE Ltc4GfIXTF0ROo6TzzJTisEgK6nywQg9NGGLZx+XzGCQlRTpia6fGTzMQ7JHgWEwyIp0MF7bGjzK 8c9nuE2kt5swGGRFOhjr0SsIo0WE9TMYZEU6GPvQKwiDwSAZssGo6NZL9xkMkiEbjKfRCwiHwSAZ ksEoZWezFkeYHYwSda666e4Bz43+cOLkjz6ePnXcJHS5xpE8j9EbXX9Yhgaj5AXdX5q2ZDe6OvNl SN3CF/8Huv6wzAtG6ZZPztjg1o905pF6kuTt6OrDMysYlbu8toR3YjvqmMyTfFahqw/P68G49e8K Y5o+/TN/UThvuv1ctEPXXgivB+PN7PISrvtwD7oUv2ppOxgLg/+1W7eU8HowNgRri205dj+6Dh9b ZXcn5otD/7XMdqk6eT0YokHtETvQNfjc/TaD8Vnwv93+G7r6MDwfjG2Z6Ap8b6+9rTXrht65RxgM MtarOUNSvHbTq2/s0eepl9+dOue/s6ZP+fDdN0cOHzrojlbnWD3l8/3gf3mgDINBxjpep+FNj439 dmshXwoeWT9vwosPt8zzuLZTU4L/56EBBoMo+JfvzGdvPCvr2TsvB/+35KoMBlGuQ9+/0aXW4eAP owMMBlFeoT+70s9kMIgKSJ3Vux6DQWRB0XMZlGMwiCwwGEQWGAwiCwwGkQUGg8gCg0FkgcEgssBg EFlgMIgsMBhEFhgMIgsMBpEFBoPIAoNBZIHBILLAYBBZYDCILDAYRBYYDCILDAaRBQaDyAKDQWSB wSCywGAQWWAwiCwwGEQWGAwiCwwGkQUGg8gCg0FkgcEgssBgEFlgMIgsMBhEFhgMIgsMBpEFBoPI AoNBZIHBILLAYBBZYDCILDAYRBYiDUbHXlpNQfeB6ASRBkOvagfRfSA6gTuCwV8Y5DKuCEZrdBeI 8nFDMEpuRneBKB83BOPf6CYQ5eeCYFRMRDeBKD8XBGMEugdEBeCDUT0J3QOiAvDBeAfdAqKC4MGo k4ZuAVFB8GCMQ3eAyAI6GKeloDtAZAEdjJHoBhBZAQej0lF0A4isgIMxBL1+MsGH/1budGguSu1H t5RM8C10ijW4B91RMkMj9CQrthLdUDLDh+hJVutSdD/JEEnl0bOs1GR0P8kUD6JnWaVqPLlHiixD D7NKT6C7SeZojJ5mhdahm0nmGIWeZnUuQveSDLI9Bj3PyoxG95JM0gw9z6ok7EO3kkzyCnqgVemI 7iQZZQt6oFX5BN1JMktD9ESrUZIXnJNSA9AjrUYHdB/JMHPRI63Gf9B9JMMkl0DPtArxvBODFLsG PdQqXIXuIhlnKHqoVXgd3UUyjhEfMtaju0jGSTTgqpDT0U0kA9VDj7W8O9E9JAN1R4+1PD50j9Qb iR5raTF70D0kA81Bz7W0xugWkom2ouda2sPoFpKJMkujB1sWtwchHZqgB1vWH+gOkpE6owdb0sno BpKZ+qAnW9IN6AaSmUagJ1sSH2BMWkxCT7akeegGkpkWoCdb0l50A8lMv6EnW84p6P6RobahR1vO tej+kaEOokdbzgB0/8hQaejRlvMhun9kqpLo2ZayDN0+MpW3H6yUiG4fmeok9GzLqIjuHhnL08G4 EN09MlY59HDL6ILuHhmrLHq4ZQxCd4+M5eldOseiu0emSkHPtpTZ6PaRqfaiZ1vKUnT7yFSb0LMt ZTu6fWSqZejZlpKCbh+Z6mv0bMuogO4eGesD9HDLqIfuHhnrWfRwy7gM3T0y1r3o4ZbRBt09MlZb 9HDL6ITuHhnrHPRwy+iB7h6ZKjUBPdwyHkK3j0y1Gj3bUngNIWkyFT3bUoai20emego921KGodtH proBPdtSXkS3j0x1Cnq2pQxHt48M9Qd6tOVwq3PSw+N7nTMYpMdD6NGW8xK6f2SoxujRlsPPGKTF 7hj0aMt5Gt1AMtN49GRLehTdQDLTrejJlvQguoFkpIxK6MmWxKtrSYdF6MGWxR06SYd+6MGWdT26 g2SizOrowZZ1CbqFZKKF6LmWVhvdQjLR/ei5llYO3UIyUGpl9FzLS0U3kczzMXqqFdiFbiKZpyV6 qhVYhW4iGWcdeqhV+BLdRTLOI+ihVmEMuotkmmMV0EOtAq8iJMVGoWdaic7oNpJhUmugZ1oJPueb 1HofPdJqVEb3kcySUQ890oocRXeSjOLtnTnzWILuJJkkrQ56oFU4qc2gyQfQrSSTjEHPtLTSHUYu y0C3kQxztBp6ruVUvWtWMrqHZKAh6MmWUazT7HR0A8lIf5ZBD7d9tV/bh24fmWpuCfR423XpDH6u IH1WevNLqVY/oRtHhjt8M3rIo3fJPHTXyAfeKo4e9OjU+hTdMfKH5TXRsx6FEk/z61lyyK6m6HGP 2DWb0c0iHzn2L/TAR6bYy5noVpGvZDyMnvlI1F2G7hP5zsvoqS/aXbywnJz3Tix68AtX4RN0h8if JsShZ78wl21D94f8aloCevrDuzkF3R3yry+Koec/nL78NoqAprvzr6kYPsSbsMa78aHGCRPRbSHf exOdgoLKzkU3hUi8iM5BftV4Vo/c4EF0Ek5U/ld0Q4hC0tuis5BXyR/Q/SDKdrgBOg3/iJuJ7gZR ru2novPwt/fRvSD6x2K3nOgbju4EUV5voRORrR+6D0Qn6obORMjtvA6EXObY+ehUBAJNjqO7QJTf xrLoXJTbhO4BUUHw5yx9jO4AkZUbsLnohV4/kaW9JyNzwQ8Y5FazgbngBwxyrztxwZiKXjtRWPur oHJxP3rpRIUYD8pF9cPolRMV5ipMMKah101UqPWQJwS0RS+bqAgDAbko+Tt61URFSKzsfDCeQy+a qEivO56LetxzkNwv1fGHV85HL5koAjMczkU39IKJItLY0VyU2oVeL1FEpjsajAHo5RJFJrO+g7ko tRu9XKIITXYwGPyFQZ6RcbZjueAvDPKQ0Y4Fg78wyEMOO7UxAn9hkKc49RDwR9ELJYrGOmees1R6 D3qhRFFp7Ugw+qKXSRSdjxwJxjr0Momik1TOgVy0QK+SKFo9HQjGJPQiiaI1T38uKnGLNfKcjNO0 B4MPwyAP6qM9GPzoTR70je5ctECvkMiG1JM0B4MfvcmTbtabC370Jm+apDcY96HXR2TLPr3XS32J Xh+RPefpzEUZ/iVFHtVLZzA6oVdHZNNUncGYgF4dkU07NeYifj96dUR2adyssyV6bUS2aTyTMQq9 NiLbXtAXDD4Rg7zrS225aIBeGpF9O7QFg9tJkZdV1RWMGeiVEUm4XFcwdqJXRiShu6Zc1EQvjEjG M5qCcRt6YUQyxmsKxhvohRHJ+F5TMJaiF0YkY5ueXJRKQy+MSEaSnmC0QK+LSE5JLcF4HL0sIjl6 dl37DL0sIjkNtQSDO62Rx12lIxdxKehlEcm5XkcwaqFXRSTpBh3BaI1eFZGkLjqC0Qu9KiJJXXUE g7e1ktf10BGM2ehVEUnS8sCxDehVEUm6RUMu4nmlFHldBw3BqI1eFJGs1hqC0Qq9KCJZOm767oJe FJGsCzQEg0+MIc87Q0MwBqEXRSSrhIZgDEcvikhSooZcBMaiV0Ukab2OYHyCXhWRpIU6gvEtelVE kibqCMZy9KqIJD2lIxh/oFdFJOlWHcFIRK+KSJKO83uBdPSqiCSV1RGMVPSqiOT8pSMXgePoZRHJ maUlGMfQyyKSo+VLqcAR9LKI5LTTEoxD6GURydHzbMqD6GURSdmqJReBfeh1EUmZoCcYe9DrIpLS Q08wdqHXRSSlhp5g7ECvi0iGlpsxgraiF0YkY4ymYKxAL4xIRntNwfgGvTAiCUeKawrGVPTKiCR8 pCkXgTHolRFJ0PLMmJCh6JUR2ZdcRlcwHkEvjci+GbpyEbgDvTQi+3R9J8VnU5KX7YzXFow66LUR 2TZcWy4CxTLRiyOyq66+YAT+RC+OyKbvNeYi8D16dUQ23agzGOPRqyOyZ3OszmA8i14ekT29deYi 0AO9PCJbDmo7652lKXp9RLa8qDUXgZIZ6AUS2XCkit5gBNahV0hkwwuac8E7MsiLDlXQHYwn0Esk it4zunMRuB69RKKo7TtJezBqoNdIFLUHteeCe66R9/wS50AwpqFXSRSllg7kItAbvUqi6Ex3IheB xuhlEkXlWE1HghHLh8eQpzziSC4Cga/QCyWKwk9aLzfP43H0Sokil3KuQ7kINEcvlShyTzqVi0As nzdGnrEkwbFg8PZW8ozDtZ3LRaALerVEEbrdwVwETkpFL5coIuOdzEUgMA+9XqJIbNR7n3cB3POc 3C09638ePd/ZXATOAi+bqFCZWX/sZ97kcC4CgZ/RKycq0lDHcxF4CL1moqLsinE+GFXS0KsmKsJ2 53MRCHyBXjVRUcoDgnELetFERbkMEIySh9GrJirCA4BgBN5Dr5qoCGMQwWiEXjVREbQ+QSksPlqJ XC4REgxeYktuVwMRjPi/0MsmKlwbRDACg9HLJircfZBgVEtBr5uoUNqfiWHtbfS6iQo1CROMM3gj H7naD5hgBMaiF05UmG2gYNTkNbbkZunxoGSMQ6+cqDA1QcE4k78yyM1agILBL6bI1bqhglElEb10 ovCc27c2vwHopROF9y4sGMU2otdOFNZcWDACHdBrJwprLS4YgW/QiycKZw8wGOfyWkJyq1RgMAL/ Rq+eKByHN3U+Qfxy9OqJwoDcw5erEc9/k0s5vd35iYail09k7QpoMIqtRq+fyFIHaDAC5yehG0Bk pQc2GIG70A0gsvIIOBh8wjG50rPoYJReg24BUUFvoIMRqH8M3QOiAiaicxEI3IbuAVEBX6BjEfQU uglE+X2DTkXIh+guEOUzHx2KkIT56DYQneg7dCiyVFiL7gPRCRahM5Gt5jZ0I4jyWoyORI6ztqM7 QZTHUnQictXm42TIRVagA/G3s3ege0H0t1/RefhH3Z3oZhDlWoOOQx5nrkN3gyjHenQa8qrIJx2T S2xGh+EExaei+0GUZQs6CyeKGYFuCFHIdnQU8uvJq9DJBbagg1BAfd65RHhu+lYqR2lebEtwrjnz nRf/nCI0d1xdm19tblFIWHPQGbCWjO4L+dx0dASsZaD7Qj43AR0Ba+i2kN+9g46AtePovpDPjURH wNohdF/I555HR8DaHnRfyOeeQEfAGm8BJ6y+6AhY40PACetedASsrUL3hXzuVnQErM1D94V87ip0 BKzxhiXCOhcdAWtvovtCPlcRHQFrz6D7Qv6Wgk5AGA+hG0P+tg2dgDA6oxtD/vY/dALCaIpuDPnb THQCwqiEbgz521h0AsI5jO4M+dpQdADCWYnuDPlaL3QAwvkU3RnytZvQAQjnJXRnyNcuRQcgnG7o zpCv1UIHIJwG6M6Qn6XGoQMQTkIKujfkY+vQ8x8ev5YiHLee3wviBraE8zJ6/MPrg+4N+ZhLb2wN uQDdG/KxK9HjH17cEXRzyL9ORY9/Ib5GN4d86yh6+AvzFLo75FvL0cNfmKvQ3SHfmooe/sKU5DMy CMS1F51n+RLdHvKrbujZLxQ3RCCQi9CzX6gz0e0hn0oriZ79wq1FN4j8aQV68ovwCrpB5E/voie/ CM3RDSJ/cvGVUllitqA7RL7UBD35RRmO7hD50fEE9OAXpTG6ReRHi9FzX7R16B6RD72JHvui8UJC cl4P9NgX7bR0dJPIf85Dj30EZqKbRL5z1LVb5+RxHbpL5Dvfo4c+ErFb0W0iv3kFPfQRGYxuE/lN e/TMR6Qab1ciR6WfhJ75yLyNbhT5yxL0xEeoTga6U+QrI9ATH6lp6E6Rr7RFD3ykLkJ3ivwkrSx6 4CP2LbpX5CM/occ9cpege0U+8gJ63KPA60LIMVegpz0KDTLR3SK/OBCPnvZoTEa3i/xiCnrWo1I7 Fd0v8onb0bMeHW6kQ47IqIQe9eiU24XuGPnCj+hJj1Z3dMfIF55AD3q0Yn5Ct4z8oCF60KN2Aa8l JO02ocfchlHoppH5vHTaO1epTeiukfEaoafcjit5/pv02oCecXvGoPtGhnsOPeL2lOXm56RVA/SI 23Q59yUkjdahB9w2bmVLGg1Bz7dtsQvQvSODnYWeb/uq70M3j4y1ED3dMtrzO1vSpAd6uKU8i24f GepIafRsS4n5HN1AMtM49GhLKvsbuoNkpMvQky2rzkF0C8lAHr0cJK/WaegmknkeRY+1At3RTSTj JFVET7UKj6PbSKZ5Fz3TaryB7iMZxnv3tFqK5bMBSCVPn/XOq9in6FaSSTqhB1qZ+CnoXpI5tntq x9rCxX6A7iYZYxB6mlWKeQvdTjJEokce1BqpkeiGkhm8uGtOoV5Ad5RMkFQVPcjKDUb3lAzwBnqM NRiAbip5Xurp6CnW4a4UdF/J4/6DnmE9mv2Jbix5Wnpd9AhrUu07dGvJy95HD7A28a+je0veddzI Txg5uiWh20teNQo9vFo1/gPdX/KmI1XQs6tXpbnoDpMnPYueXN3iXuRWbBS1feXQg6tfSz4lgKLV Gz21Tij7HrrN5DGrDboPozDtdqA7TZ7SCj2xTqnwDj9pUMRmoOfVQc1WoLtNXpFcCz2tTorrexjd cPIGjz6L0rZTP8hAt5w8YKu39/23o8FX6KaT+7VFjylCq+XotpPLTUTPKEZMl1/QnSc321sZPaIo MR2XOtrpVEdfjSR1Rc8nUtsfnGpz5lfNuJmPl3yJnk2wC8c7cU944mt1A4F6DrwQKXLI5NuTIlN1 sO7rRFbek/2930LNr0PqdANPpSsk3DRT38PJUiY1z32dLtpehBSbgpxHN6n6yCod/c2Yf3+e7zbi Nup4DVJvW3ncKLpOo+fXqu1u5ncPnXziS9yt9gVIk4wWmBF0rXOeUPYFbsaPfasXOH6x7aoOTzoN A8ye29W4c/Ju6cZuGHNjBcuj91HwrpFuPyc4PHQeEdNwwOz9tru6c1LPGmEPXWqvwveP9NhzmoPD 5jl1bh+9JNpT1XvmDOtcu/DD8jnLrpfe0pkJ87CE+l2e+eS3SOJxcMX0p9oX/ExRUClupOt2j2mf K0PE1bj01oFvzvxx7e58Eck8tG31jzNe7dOhYRQPouqBebcpUtP1TZK5ytSoXffc8xs1adqsWf3T ysXYOUTsSvQ7T4VZW1b10FBkWqHfeirE3rPQ8+FfX6LffAoruXnR7x9pUl/fdVkkJ/Nm9HD4Gh8l 61aPo0fD30rwWkJ3eg89GX7XEj0BZGWGT/apdbH30TNABc0phh4Lqih/nSIptrAkeiooEOiEHgPK ZzFP7LnCOPQg0AlWWt8mQE4rvR49CpTH4orogaAcTZzYtYcis4B/R7nHAPQ0UK7Z/NztIjF8vrJL fMw7WV2l6jb0RFDImDj0JNCJLkhCzwSJjL7oMaACuqKngo60Rw8BWXgJPRd+t70RegTIStwc9GT4 26JT0RNA1irwPB/Qq/w6yrVq6n4EAYWTeAP6zadCNEhED4hPLT8T/dZToVocR4+IH2W8Uhz9xlMR bsxAT4n/bLwM/a5T0e5Hj4nfZL5eCv2eUyT6oyfFXzZeiX7DKUL90LPiI0ef4KcL73gEPS6+8REf fuEpfNSSI1ZdiX6jKUq90TPjA2tvtrVBPUHdmY6eGzdaoW6j3423x6LfY7Lj+mPKZsAU6XcFTh95 RMmhVvfkPoNedYn9J2KaKSnrZokKT+ySPVDGrKvRby5JqLdVxTgZ48ClOX0pfutcmasDEkfxaTAe V/0XZVPlfdvr5+nM6YM32ztKyqedSsDeT1KlzGdqh8vD/pfvJqKYK177PdpjpC+8lzsMmiFmqI4h 86CJVv9/vv6gRZH/TbXjgy5MhUE688up4KflgeHaU6n9sIVF766y5eP+jXjOwjCN+BH80HWFdijh wgdf/+8f1r87jqyc9uz1VR16q8hRVb91eA7dZt05kbSpxPnX93x0+LjP53797bwFC76Y8PqQvrc3 ZyRMFjvY12fBJ5RBvwHkVi3+Qk8nTNJd6OaTi1X+Ej2gIGvqF90c8rGYx1LRM4rwAW86pSI0WoWe Usft7YRuOnlAsed99hn8U36nRBFpugY9qw462A3dbvKMEi/5ZtOpr6qjm01e0nQZemIdsecOdKPJ Y+IePoSeWu0y3+HlfhS1U6agB1ezVZegW0ze1GoDenY1OtKfd2OTTcX6HUDPryYZ7/OpRiSh4sgU 9Azr8E1DdGPJ6876BD3Fyq0p/L4Loog0/xE9yUrtfICPnic12vyMnmZldvcvie4mGaTtYvREK7H3 UV5GS2pdtwQ91dL2DeJNeqReu/noyZayvX9ZdAfJUBdMVrcLuMNWdeNj50mfM0YeRo+4HV+3RjeO TFf+sai3rARLGtcI3TTyg9g2n3noHr+1fcqjG0a+cdozf6IHPiKpU69Et4r8Ja7jF67/IL56YDV0 m8iHqjzk5rN+u0Y2QTeIfKvOEJsPVtEsaUo73m1BUM1HbUHHIJ+jn9zCU3nkAk2G/oYOw98Oju/I qwTJNc4e+LMLdtz5461reX6bXKbyLR8gN0tPntO3HroFRNbO6z83GRCKzF9HteEfUORqJVr8e46T W1KlL321YyX0ookiEdf44Y93OBCKQ/NfaMMvoMhbTusw5At96Tj2w6iudfmEVPKoU65/atpvap9F k7F55rDbz+eGBuR58XU7Pj5+ifyNHIdXffZitwt41zaZpWLjG/qO+nRF9Jsb7l/z9TuDbm5aGb0A Ip2K17igbffHXh4/+/uVm3YnWUYhbd/vKxbMnDB68D3tm9Yohi6YyHnx5WucVbd+wyYXNb+iRfOm Dc+tc8aplfnXEhEREREREREREREREREREREREREREREREREREREREREREVEe/wd7t2HtCmVuZHN0 cmVhbQplbmRvYmoKODYKMApvYmoKNTM3MzEKZW5kb2JqCjg3CjAKb2JqCjEwMzkwCmVuZG9iago4 CjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MQoxMgowClIKL0ZvbnQyCjEzCjAKUgo+PgovUGF0dGVy bgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2UzCjU0CjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBo YTAKMTEKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdl SQpdCj4+CmVuZG9iagoxNgowCm9iago8PAovRm9udAo8PAovRm9udDEKMTIKMApSCi9Gb250Mgox MwowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKL0ltYWdlMwo1NAowClIKPj4KL0V4 dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdl QgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKMjEKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQx CjEyCjAKUgovRm9udDIKMTMKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFn ZTMKNTQKMApSCj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQKWwov UERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjI2CjAKb2JqCjw8 Ci9Gb250Cjw8Ci9Gb250MQoxMgowClIKL0ZvbnQyCjEzCjAKUgo+PgovUGF0dGVybgo8PAo+Pgov WE9iamVjdAo8PAovSW1hZ2UzCjU0CjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApS Cj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVu ZG9iagozMQowCm9iago8PAovRm9udAo8PAovRm9udDEKMTIKMApSCi9Gb250MgoxMwowClIKPj4K L1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwKL0ltYWdlMwo1NAowClIKPj4KL0V4dEdTdGF0ZQo8 PAovQWxwaGEwCjExCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VD Ci9JbWFnZUkKXQo+PgplbmRvYmoKMzYKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAKUgov Rm9udDIKMTMKMApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNTQKMApS Cj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0 Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjQxCjAKb2JqCjw8Ci9Gb250Cjw8 Ci9Gb250MQoxMgowClIKL0ZvbnQyCjEzCjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8 PAovSW1hZ2UzCjU0CjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCj4+Ci9Qcm9j U2V0ClsKL1BERgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iago0Ngow Cm9iago8PAovRm9udAo8PAovRm9udDEKMTIKMApSCi9Gb250MgoxMwowClIKPj4KL1BhdHRlcm4K PDwKPj4KL1hPYmplY3QKPDwKL0ltYWdlMwo1NAowClIKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEw CjExCjAKUgo+PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkK XQo+PgplbmRvYmoKNTEKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAKUgovRm9udDIKMTMK MApSCj4+Ci9QYXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNTQKMApSCj4+Ci9FeHRH U3RhdGUKPDwKL0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIK L0ltYWdlQwovSW1hZ2VJCl0KPj4KZW5kb2JqCjU3CjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MQox MgowClIKL0ZvbnQyCjEzCjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2Uz CjU0CjAKUgo+PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCj4+Ci9Qcm9jU2V0ClsKL1BE RgovVGV4dAovSW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iago2MgowCm9iago8PAov Rm9udAo8PAovRm9udDEKMTIKMApSCi9Gb250MgoxMwowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hP YmplY3QKPDwKL0ltYWdlMwo1NAowClIKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgo+ PgovUHJvY1NldApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRv YmoKNjcKMApvYmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAKUgovRm9udDIKMTMKMApSCj4+Ci9Q YXR0ZXJuCjw8Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNTQKMApSCj4+Ci9FeHRHU3RhdGUKPDwK L0FscGhhMAoxMQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwov SW1hZ2VJCl0KPj4KZW5kb2JqCjcyCjAKb2JqCjw8Ci9Gb250Cjw8Ci9Gb250MQoxMgowClIKL0Zv bnQyCjEzCjAKUgo+PgovUGF0dGVybgo8PAo+PgovWE9iamVjdAo8PAovSW1hZ2UzCjU0CjAKUgo+ PgovRXh0R1N0YXRlCjw8Ci9BbHBoYTAKMTEKMApSCj4+Ci9Qcm9jU2V0ClsKL1BERgovVGV4dAov SW1hZ2VCCi9JbWFnZUMKL0ltYWdlSQpdCj4+CmVuZG9iago3NwowCm9iago8PAovRm9udAo8PAov Rm9udDEKMTIKMApSCi9Gb250MgoxMwowClIKPj4KL1BhdHRlcm4KPDwKPj4KL1hPYmplY3QKPDwK L0ltYWdlMwo1NAowClIKPj4KL0V4dEdTdGF0ZQo8PAovQWxwaGEwCjExCjAKUgo+PgovUHJvY1Nl dApbCi9QREYKL1RleHQKL0ltYWdlQgovSW1hZ2VDCi9JbWFnZUkKXQo+PgplbmRvYmoKODIKMApv YmoKPDwKL0ZvbnQKPDwKL0ZvbnQxCjEyCjAKUgovRm9udDIKMTMKMApSCj4+Ci9QYXR0ZXJuCjw8 Cj4+Ci9YT2JqZWN0Cjw8Ci9JbWFnZTMKNTQKMApSCj4+Ci9FeHRHU3RhdGUKPDwKL0FscGhhMAox MQowClIKPj4KL1Byb2NTZXQKWwovUERGCi9UZXh0Ci9JbWFnZUIKL0ltYWdlQwovSW1hZ2VJCl0K Pj4KZW5kb2JqCjEyCjAKb2JqCjw8Ci9UeXBlCi9Gb250Ci9TdWJ0eXBlCi9UeXBlMAovQmFzZUZv bnQKL01VRlVaWStBcmlhbC1Cb2xkCi9FbmNvZGluZwovSWRlbnRpdHktSAovRGVzY2VuZGFudEZv bnRzClsKODgKMApSCl0KL1RvVW5pY29kZQo4OQowClIKPj4KZW5kb2JqCjEzCjAKb2JqCjw8Ci9U eXBlCi9Gb250Ci9TdWJ0eXBlCi9UeXBlMAovQmFzZUZvbnQKL01VRlVaWStBcmlhbAovRW5jb2Rp bmcKL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250cwpbCjkyCjAKUgpdCi9Ub1VuaWNvZGUKOTMK MApSCj4+CmVuZG9iago4OQowCm9iago8PAovRmlsdGVyCi9GbGF0ZURlY29kZQovTGVuZ3RoCjk2 CjAKUgo+PgpzdHJlYW0KeJxlkstuwyAQRfd8Bct0ERljJ+nCQopSVfKiD9XtB2AYu0g1Rpgs/PfF TJImKRIWx/O4VwzZoX6qrQk0e/ejaiDQzljtYRqPXgFtoTeW5Jxqo8KJ0lcN0pEsFjfzFGCobTeS qqLZRwxOwc90tddjCw8ke/MavLE9XX0dmsjN0bkfGMAGyogQVEMXG71I9yoHoFkqW9c6xk2Y17Hm L+NzdkB54hzNqFHD5KQCL20PpGJxCVo9xyUIWH0XZ1jVdogx4XzcnSPqW/rUp4h9GONMLMR5oqJD KhOVOdIWqUB6RNogSaRdogJ7bphA6aSV33pa0jYotsNsLq6N8nujJZrZopkSzWyLawn+T6I8uVSY jWZLQMHTz/ZGd7nMZeaXSamj93FI6WGk6SxzMRYub8eNbqlK+xfcrLY1CmVuZHN0cmVhbQplbmRv YmoKOTEKMApvYmoKPDwKL0ZpbHRlcgovRmxhdGVEZWNvZGUKL0xlbmd0aAo5NwowClIKPj4Kc3Ry ZWFtCnic7L0HfJRV1j9+7lOnt0ympDCTTHqICWEgBCKZUCIQhVBN0EhAQLABClh2Baw0C1ixgroq C7oMCWoorrGsdV1ZFRddXVkXu7yyisgqmfl9750ZiLHtvu/7+3/+n/8/Cd/n3HZuOffcc8+9zwMQ IyIjLSOZHGcuXhj8buj9byPlLiJ96uz5Z51n+HhHEcJHiNS/nHXuJbPj8mtbiay7iYoXzpk1feZf a4eMJaoaAZ6Bc5DgWpIeQ/zXiOfNOW/hxW+WPrMI8Q1E4TfOnXfmdMl7qIDo3IWI7z1v+sXz3e8o i4nuPRnlg/MvmDX/n2M+8CB+LpHzNXUHZQk8RFlKAWURxfenEJsb38/zOJU+JWLZCSR/2uhh+gsr YkFqZ9+Sl44wP+tHo0mhbzDSLdRFt5CbJtGtzEV55KHJNJopKFNK17I744vjn9CJdCPdF3+cXRHf hPwb6Dk6gh78TWFURWNRfjLNok/kD6g5fgcZaDmZaQhNYB6aTm/i92v04Sa6mX7Pfh0/glbddAXq q6E6qos/FT9KJXStskbda3yU1tJOpsXPjM+lPpRLq6TS+Jvx96iAmul+ehh9KmWdyijKoXPoalrH /PJzCN1Cv6EYs0gt8nD1SbQ0mqbQ+XQRraJN9BJzsUZ1r3ow/qv4R6RRGhWhT3PpEzaAnSI9oFji Q+Nv02m0nV7AePlvp3Ka8pB6Wqw2fnf8aUqnx5mJ7WJPqZXq9V2Xx++N/44s6E8/SGQs2plBV9JT 9CL9k76UlsaX0iiaiJb/wLJZkBVA4m9KfmmJtER+nU7AaFvQ20W0nqKYkR20k56AbP5K++gD5maZ bAybwdayLyWLNFN6Vb5T3ia/oTDlt5B3iPIho4X0AD1Gf6RX6FWmov4K1sjOZvPYbexutk+KSp9L 3ygG5UrlO6VLLYjti30XHxv/mnyUQSfTpbQUsr2f2mkb/Yn20Jf0FR1mDjaIzWH3sijbxz6XjFKu NE6aL90qPSA9Io+V18pPKQOUYco5yivK2+o16mp9uh47+mDsptgjsT/HH4//GbpjQ/0FVA+JXg6t eICepNdR+1v0Lr3P9Qf1D2FT2Rlo5UK2gt3MHmF/YH9mn2KUJH5zpSHSCLQ6T7oAcrpCukm6Ga2/ it/d0tvSu9Jn0teyKufKA+UF8r1yVO6Qd8sfKg6lQDlB6aeMU6YqccxMpXqSOlHdqG5Wn1YPajXa TG2+9rF+hX6V4Y9dJV1/i1FsTiwaa4fuGqBJl0IS99B90PttmIOXINE/ocf76BBmIYPlsEL0u5rV swZ2CjuVnc5msSvYcnYjW8fuZPex32EEGIOko++lUp00UZouzZKukpZL10nb8LtDelF6U9orHUDP vXJILpX7yaPlqfJp8vkYw0J5iXwVJLtW3iS/Kr8ufyR/LB/ArHmVPsoi5VLlduUhZZvyZ/Vk9Tz8 3qc+qXaqf1aPqkc1ScvQsrRy7Wxto/a+rukD9UZ9pf6G/pVhPstiJeh5kLr9SH6swT7SJsmtLGUH kJDNFLJj5KWYh4lYFV9RrRzDvNh4PvqWLvmVNM6pRZQo+BeynTSA/YGWapIMq6jsozb2jrRPeUY6 kfawVuZXHpLPV1+ScmgzrNEaaZe0kw2jbVKNNEW6Syb2AdtIH0DfL6ab2TnsQtrMDrDB7DJWxZbS G5JHnsiuopr4fZLCjGw0O0joAV2uzKQz6Gd/WDW9Q5/E7lGsyq9hnzroVszow/Qe+y19y9T457Bu MqzRdFiZa6HvVxO3ei1YZ0uxHv2wIOdqr9I2psGKV2lDlUvpIP2LPlF3QKOGwZJ+FJur3KP8I14V L8MKwyqjjVh3c+gkrJgPoCVPIM5jp2Olm2BLKrGqG2kqzaTLYPXWxqPxu+JXxi+Jz6OXwfst68u+ ZRuwIjrAUUMv4PcGeoutxjo86efH+VM/sZnUSZ8yH8tnlVgPB9TF6hp1k7pN/b36itYP0r6K7oRG vw9tNmEEZ9Kf6VP6hhkwN37qS2H0dxD63kTnSs3yEzScZdB8rNki2PFhyZFciFqugPTuwnp+Amvj IOzE6fR72ssk5sWIzkT7BtTTADlPQ+kHMYNXsnakzITVLqHPMG4bGyQtRHsR1HQrrFYn+vQOfQhp x0W/+sIujGBTUNc3dCrNRAsDqZFhL40/RtWwrCPkP0LeecxBw1gu+w34WrFCbZRN1eo/mER9Y2Pj g6S58hPYY+JI34DdK5NOZAvQCzvG0UXpbBwNiE1AH15nshJlr4le3C7Nii+XL4qdSy/TbzEnEWWx jt06UjcpUjv0xJohg6sHVQ0I96/sV1F+Qlnf0pLiosKC/LxQbk4w0Cc7KzPD7/N60t1pLqfDbrNa zCajQddURZYY9R0Zqm8NRgtao0pBaNSoMh4PTUfC9G4JrdEgkuq/XyYabBXFgt8vGUHJ2T1KRhIl I8dKMkewhmrK+gZHhoLRV0aEgh1s6vgmhK8bEWoORg+I8CkivEaErQjn5IAhONI3Z0QwylqDI6P1 i+esGtk6AtVtNZuGh4bPMpX1pa0mM4JmhKLe0PytzDuUiYDkHTl4q0QGKzoVzQiNGBn1h0bwHkTl /JHTZ0YbxzeNHJGZk9Nc1jfKhp8ZmhGl0LCovVQUoeGimag2PKqLZoJz+WhodXBr385V13Y4aEZr qWVmaOb005ui8vRm3oazFO2OiHov3e87HkXlruFNy7vnZsqrRvrmBnl01arlwWjn+KbuuTn82dyM OsAr5de3rqpH09dCiA0Tg2hNurq5KcquRpNBPhI+qsT4ZoVG8pTWs4NRY2hYaM6qs1sxNRmrojTh kpy2jIzI9vg+yhgZXDWpKZQTrc0MNU8fkbXVTasmXNLujwT9388p67vV4UwIdqvNngxYrN0Ds47l iZAozkMNE45JlvEehUZDIaLBM4PoSVMIYxrEH7MG0aozB6EYfpoZuKIzMSNzo8bhrascg3k654+q +Y5QcNXXBA0IHfj8+ynTkylavuNr4kGuJ8dUDfmpcLS0NFpSwlVEH445RR+HiviAsr6LO6SBofmO IAjER42Q7fTmweUQf04On+DVHRGagUh02fimRDxIMzLbKFJe2hyVWnlOZyonfTLPWZbKOcbeGoIm byPutKdHDQXH/tgdnrSRcwZHmednsmcl8hsmhhrGT20KjlzVmpRtw6TvxRL5g47lJUPRtOFNcqaU DEmZssiFUp5+rDCPNFmiSj7+aEKpZ0ZlKKVIYMH6qKN1VOLZbMrJ+UmeDt3QjakjfpBzCXKcLdnL 6ODS78eHfC/+vd5ZVsnor1IgNUyaumqV6Xt59TBAq1bVh4L1q1pXTe+IL5sRCjpCq7ZLD0kPrZo/ sjU1oR3xHaszo/XXNmMQc9hgKKtEw7aG2IrxWyNsxcSpTdsdOMmsmNTUJjFpeOuw5q15yGvaDlcl IlKlY6k8FuQxamBQ9DbJILIyt0eIlolcRSSI+JkdjESaIZXG6MwOKZHmEGn4KYMbwydfxS+8Ap2G bZNYTNM7pNpIGqlKTCaTrsQY+Q2aGpPkXayAjHCGfeQrdRyu6aoZ6zhUc0pXDdUi7DiKR7+KHGeO Mx8PBgfjaFDuPBpR6TsKKp1oi86Gn3SN+iJ2ogBdGSnRHLa0sOpwuMKDfYP9EXVy+uyMzbpm9KRR xB8I21FKoql9BmXZO6Sb2hx3WDqkhZHcNJZlymIBQmfIYcxxeIIeyZORY89xOJjDH3xguK8U/Wo5 5cBYx2E8XdXlBxw1DnSytuvQfkfXhy2lrurqfhXUUlrKQgUDwgMHVg0cEC4I5Wp6/sC8/pVKulvT NU3GQKQv4mzCYV/+lfPOWZMZi5lZ5odfsj5zH24u7YKvdGmV5dcbXgj0GzJh0aWXBdu/7drY8uAN Y6bGXMwf+wg955J9EqdOnUysbjvp8b0RY1V1WCvCQ++Id0aMRQPCWgQPxPZGGnMKkYdHMZUoJWqR qdwyiKrUWsvZdLY0S56tzjGcZfpYto/RmGQwMtlkNCq6kcGN0t3w1jSjogRVza2qmsEUycgeauJN mDOyw6Z8SZY1xdjBdkVsmi6pCo6lBovXm0Ed0vSIOcDEYWkZk1mHlBcxBoyswrjMKBl3SHmkoIQx qDLVbz7jzKRku/yHWxYcalng6xo7ctaIDzH9kG9tzSkHnBB2TVdpac1y9YTS5Zc9u/wEHye6o6Zm +bPPbtWk4ZOathnDRmuYSpv7VbCGqHliQ7QPFuJ2kuOxNoNi2hGPQVJHt2rKIP7TzBZgnvhPTo6M X5aTJsvqk7HfL+t67JLYc9IQVl3y0nPslFi7uuPoKinYtQ8uME2Pf6Seob6Ok92bkbHXGFe6V3rW 0zrteeMb8hvmr2VjvrHIUmQtdhd7FqmLjNeoBj1N93rTvN5iqUTOV/Ui9Xb1NuOL8h/Mai0bB7du goPYPjhZEkGo7U5fWFATxgF/IuL1lSkGW8TmCtsaptnZODuzR9J9YXsHK4rkuspMsv0L2xT6gkRV GRVZLCu9cIPO7HpAr9BlLLdr2zOXTEwIdwHX2xauuIcOEDS2tGXB/lJOeaCFqy1raWlhqqaEguR0 UE7Q6/GqBVx9nQ5P/8qBSi0LDIu98nnsndgKdikLM+vGmZWxv2Y8sPj+l1/YsHiTlHnawU/YDTh1 ns9uWX9GtP6Cqz6NfRv79PNbueRuwQo9CJ0105rIiQZV0Q35miugsgp1iyqpqlFW8mGpTMZ8M8Gz a5ClUSYyM3NG0FphjVhlq2IMQiEruKCk1e2WfslRcSshhlVzyqGaQwmDweGsLm9ZAIO+ndR4Z1t2 tQpT2pYhyNa0asx6MwrJKvSnX0V/Z056ThK3KLVHP5H2dQXl/uqOI7Gd38QWfIPez8C8P4F5D9Le SP2gPg19puiLDYstVxuuslztvSrTqHm1TJfXlVnkLPIVZRT1MYwyn6ZMMk41n638SrnUtzDjMdtj juetzzn+4vjIYZOztCCf50ggoxrmhjBy5skq04wuPtWuhnFpLI3Pcxqf5xJPmR2nOhb0T0NyoWuK FAgGZSkjmFuRK+X6CzeYmN0UMFWYZBOf75wl678331xAjkMHFogVlJh3TPsBJ19PC0prkJycejYg x4m5z82TBoRdVQP7B5Xk7Kc7XJj9qgFyrbSkJbb+0Q9jmx7u3H7da8zJ+veNvR3YvOzpDz7e1bJz uJT5TVfH1JVPsbNe/4DNnDb6g5eqzr3s8Jex72LfjQ7vwMxxHTgCHbDDTl8UydfU7e7tPvkklZ2l vqlKLme+1WajTAdXBDsZPIVbdMbNWbvRHOa6HPEEsiuyW7PnZy/LVrMd9u4KkdVdIU5xLDhcivFD G7guCNtRw4e5gLVgsqHYOEposMWhkF/C2LiVLiwI3cL+ymwTlmyacdvYs1986r4ti4efMWrABnWH J+fdLcs75jrTu/6iPB1rPWFGXeMcqwkNQ7HVXRhPOuXQkcgV1fbR9lP1s81nWzYZH7JtCD1m22s0 aQbN5DV4TANt9bZ6u25wGJ1um9vudgy0DbSfZF9ku8Txusl8sfFi/+LsFcYV/muysU25jRa7baJt ke0q2822+22qLWi1uK1Wi92SbvV68tMcbtbq3uCW3G4K5nBxQXDpZLBxQ1xIVodVsr6RWbhBi2qd 2m5N0ZbPD7FgqCIkhXLSu0stt9+Zx6XmaFlwuOXAoZYDKbMrJNeyAJRBTaqXn1DaYrvM8SxzVlNK bRa0cIFWCnnqHo83LUc+QQqFnM7jUg3dKs37bM+yp59qvezs9tg9b14w6YzZNX/dc3bNuFF52z5S d4x76YoH/pI16JrNsfdZ7ebmnK675LF5TcPGnGZRud0YE/9Q+RIrry/bHTlxu7Mj+7Gi5/oqMKvp MKvpvtJZ6qyihdrF1oVFb1neDFmaTZNtk3ObQ3Mss11n5cwtOqvvRdnXZN+aY3GFOuL72vsEwpxG ZvkzwuNzx4eeyn0qpCzIXRC6PPfy0N9z/x7SSk0l1rzcvFC1NRxqMDVYR+QOD51tnRW6xHpp7krr qtwHTQ9ZN+amGU1Gq5arhfwmv9WTq+eGTFaFeaf4Iv5geJ6PzfOt90m+HdIsysQyt2CZZ7LMMrdM oxhf96MzguEKFmGNcO7XsA3wfDqZgf2XEsmodihMKSsx+r6Ie5k3kuYNexv0woKMEwKFGxxRh+Ro YF84ExPoL3stqfMNE5u2UmRQ8yl89uCcgJZewI38gtJDLaX7E/SC0v0ub3VLy4ILSkuFYcyFPDKz h0Ieu5P0H21p1bkQDwhiL7a5eGx3xO6qtgZd1SYBO0/7OGKzIM1abfJxCIN6/Kc5sR9H0gebBlsH 5A6AHEdbh+fWhx40/TbXRC3NyaWYlu/h+4pQE/7LPaZjZkfX0t1ejyI0i+9IY1gwY/3yG9aeeHJ4 +3+1Ll/6xW+Zm3n12N60yy67fHR530Es+uqia+P0ZOzT2Jvs3ay1Ky4ZHx6d6TphyJRLfjf/mdlf vmRdcOaA3Opwfvns855YveSdcxjj+tUXNmm78KUuiITKjRVKhdponA8vZY1R15gq5SuypJPBCKdG WQpvpYOVRUyaDr+GlvJVhKhTtjVK86Vl0hp4yn5D18PJWRnftFXCrGBnasEawgM+zf6kTeL7DmvB jjOA7zvsvdgpynWxscrTR458NxTVjo5/rJygDKUQVbIFkTl6hiFLzfZkjMkclTU6/6+O95zGgf56 /6kFs/1nFVxTcKP/powHM7ZnPp/xQqZF06zpHs3vKdSK05v9F0nXSA9qj2rPaZYnw285pOy8yn7O vta8SOkJ4bxIbhEe/uzwvLyjeVJefTbXzQqbPXxiNqNsR3Y0+1/ZSnZ2X9afIkhNuM2TcyJZztqc SKYDD19GOAe+86OKbrGa+nJbjTxBkS0oSvTl3nXEbe7Tr8BQbCyyNgcs6y1SwMLiFmaJ2DxhS8a4 MAu3Yjaur2CM9S/OmeZl73nZOO807zyv7PX3n1uX3NQugG4vONDCd7bSRGw/PyYcgNpBsPAQhcYL u1WaUMO28my2oPlAIrKd8uKdj2dmhyflzcyTWkqbuQ8IYybbHIkpWdDCVbMQisiNmuz2eHO4bmpa KDfp0VclXHrG9490NxS4irv5bFa89LVXd3U0yJn5sU/NDl0e9ZuW3zwx5c4b/3By47yGSeyMgZ/m VTWNOHlkf4dZev+EO25uXvl4rOPaq0/OqvIb6uvbVky9riErP5g1fuSQ2GuuSl9hzZAplQVVebMg lcnQhlpog5/+HhnfZG92NXvm2Oe65nou813iv026zfKc4znfXxxv+j7RPjF8kvZJ+hEtbVDaoPQx rjGeel+zZa5FH+yq8lT55IvUi+zL1WvsK/0bXQ95trse8xhtYpYyw5w+6nKHbf2tPMXfJyyo3Rm2 7mAKmTCHLqeZIihKEZSj/mswVzuwihRkBb0646ksh8qtPGDNGWdjtoxMPcftz2hKTF/q5FR66EAp d0XgiSQ8UNCETVgABzThdHDJDqxSueC5N4rpUPrFPrOdOW7uZUvPaZydztylh175JPYZ8xx4+gPp 88qJk9ZueuKu0+aV//5pVsAUprP8h/jJsA6yK4Ts3JTF7t9OjviRSL25+nbjHdZbHRvVh0w7jTut HRkGg5uNkk7S6k3j+my0PqY9lvG86QXLm6a9liP6N1Zrlj0rPQKtSY/YnGF7+pPpr6bL6UI6fWoF tXlBpesi2LZdjbZWm2Tzubilf8yfGWb9XcKpzw4mnPvc4gQtLUtQX5agETuW2AZ+Z+JAt6e5XFg1 7YrZ5eOrJ8+sUw4rT08ItbzPtD7z+qzvo/Sx5xgiVnvY4M9OrpDS73n5B2DoI25fpMhd64v0seOB Zenj61fY6dousRG40AmUcPHOoJAruXw5bUsVxdITtl0wEDJc1bzTbV5Oou1G01ARrcupLSVefj9f VS2ieVsEUrLxRm28eRxnvLUkKhVHOmxH8C/6c3O4AEdnxqc8iM2AzznJOWKLSEvsCF7pW+Yb+MmW 2GdXz2Xu1w8wl9YVka+YPmxqoXzxlNNrahibUH7HvY+ufRe7aWns+dgTl60exc69dOnw4RdyW++D QnwIX8JDHRGcZ1iJEnQEnc3KMp9qUJ70Sekep+R2eZy2NDs5bGmMHJLbaLCb2TRz3CyZ+USYNOa0 e1jcwzw82seBeg+iai3NbTL2rzWMMzQaZEORo9w5zSk5O5gSsdrSCiT3NNrg6fRIHq4TRkvY4/de vF2aS4k5W1BzCr/jONqCTcK/n3ywZNztAmrxqK604ydpm9L6i12y0quLVZLePz3kzHGGfHdV377o 4gsLhg89ccBrr8U+ukspaLzmqol5zzqqxze8e/RxeTRfC5Ni45VWsauUs7GRGRdlL8+WXBbr/H7X WJf1U4IM/qFcwfpL/eUIGy4Nl0+zN7ub86cUT8FUnWM/4jyS5hpi7e8ZUtS/LxwjT0PRiL4HLV1e 0/Ww42aL1VxisRbaPN70MqsFW7cvj6+AR8UKEIpucwolaTdbErSoJLEAQvkJ2i+cWAjG9EyxGUxT IeK2gL2QE5upjAvcnK77/FpJsbkgw9fBiiNGvz8j44Z+rB/rYB0RE/XPy3H5K5pqkvbmEFbDApyB HAccXWLrPYDfrkMXJByV1J5AonOi8TZMjlBfuLxe4edWc8Bv5wcImCecKpsi1rn2ue65+WcVzy6d W661NFOLV/V4U3vBANispAJ7cahy26RQEJtHmjvp7WDiLmF1huyiKedX5adZl3S+edkMxp78wzKm D52/84bYl+8fvbL1rOtXzJl1ZX3hoPQ+OZ5+oTPufPjRG/YwM8t45JajJ+3acXbN9utt0pW/vfve ex7YcDeEdSP8mGb4MR5qi5TaWYBV84l0DGPDnH9j/2JGXfWoeVKTc45TZUxKcztdabJbYnYu1GxZ N5pM7nSTh8hsKjAYI8G88BYjixuZEWLGlHhy88JrfBt80nzfQZ/0hY/5yF3gSRdmC2U3pLOD6Szd 761NCB4+ZvJgjtDhZEx4PvxgcQAy9Yot1yC8IJwjnFDpPlI6VDkszL/Gg2zziiem3zUuO/ZRcPyJ 9ef3j+G00PXB+lHzV9zQtVbq99DUASNWXtP1OQYN3b4JC/FhBPlt40XbyYie1TpNtRFjo1FaZowa O427jV8Y1YCx1bjUuAEJqqzppCqynViEdtM+cLZIWMiqpismScceInQxJy+s+A3JcR0fR61YnuIC wZF0HC4oTeOdBm7i93TMrzzGlNjR78YoBd+9jRlaiRmaJm5AvuKXUu+2W521Mm/jMn9ZWJcdcppW aJytbTE9aXrB+LLpbZNpotwqS1bdZ6zXTjUs1tTHjO8pB5SjyteaOlYfa5itXaZcq9yp3KXeod2h 32EwBRSXVqqUqiVaiV5iKLc2KA2qCX4KDisGk2oyyppiVhWNX82azQbdJJtMZqVDOi+SoZYbqgM4 bc+ySuYCtoz4LSj5LbW/SrpdfNx+x+EFPqyoxJ1n4ohYW4NVstyAU6GhJrWa5PgLbcac5EVcCw4c dAG8rP5cNjkMf3TnSuZno9nU2C3s6tifY19fqe44epgtjv266wz27srYw2j6+GxOFDc4kWI+l2qj Ki1To2qnulv9QlUDaqu6VN2ABBVDkuGiyAWMUrNGfuUHs5acp/6JOVJ3fFuPtpYQaetgFQvZkO1U DO4WtIVdyJKueSxhOWwI+8KhEdJIw0jfiJAlKJcXTzS2Fi8rXl/8G+0h/UHLo9qjlmjx7uJ9xTYq Li9uRMaTxe8Va8WRjKxwLeLLRKaq5yh6RjbfNtpMeo7YPRTd4XQWZmZlFRSaoHp2R4HLGZk6oNXJ 5kGROqT6iD0jsyA7C2nzslhrFstC2rb8goJCmLviNqJC4YQYazmNDES/C1G0MFIH1AB5heHCyOAT w+WFrxa+VyjbCwOFywplKgwWVhTGC5VCf9E/alKOdfLwlrCVNYex32NLOryghZPU0nWI5Vt7gN8H JO4A2AWlfFtipWk56dxn9grP2esRS7nw2FI+vqqXMHl15+xbK+rvO33RfUVY29mF44fMOSH2UZ/a gXVzymIfKQVrfztp8uRJ004fsa6rWZp2zwk1o1bfGpOk+jun9q2/6vauo5iztdzaYc48tD7i09O8 aVMNcwxKh8IwW44RhhH2TxyqJkybU7dZNYvZzKAerMBDwrQRi6OSnzJtJnOBxcbla7Vajlk4CzuI Xe77Fk5I6gdGLrEwDiTvR3K+Z9KEkGDolObYR3njq0cvLIWhUFe/3nLHuIDU5+FZgxqvaosFlIK7 tg2fc9WvuF2bAP/1DozUCu//tsioj9lHhm/SvklXnpc+ViWXX/UbpWbHlLQpnmbfbdI6bZ3hNkuH cY/0V/Ud4x7LR+pH2sdWx0OGl6U/as8YnrOoiwwrtasMslNoodnLReRWdHe1ntGaOT9TyrTl0Pfc 9QWH+TXaATGc1O5nnOuY7ZrtmetTGN/6cJAPuzAsSndTKDevIL/bPjdhVddd/2Th2Iuf3xj7ZhUL 3nr++bfccv75t0q51zJtVez5L/4Ze+aq+MZ7Nm7ccNfGjXy8q2PnKrdhvA7KojsiJwxKG5UmucJy tbU6LZw5Qh5tHZ02IvNfmcYp2hRTs2uKZ4qvOeuw/q9MA9ZPBh+Vqrv5qDxms8Nu8+YYMub3YX2c xTabvcDh4MsmYp5Py/j9SXZtYpwLTjlQg4l07E8NN+EmpPYmvt/P1mab5mLMs31zs8R+z9WdjxlH E5wMC505rNuoVzOt/+/O3s6k2NHtTTeMwxR7rp8944przjxrBaa2cWbsb7Gu2OHYW/WTuz6Rt7dv vrv9ofvWo0enYewzMHYnZdPdkSpXjRS2ht01WWOkEdYR7jFZhvkBlm1I94ab1WbTqdYpac3e5owp 2Q+aHsw6Yjxs/cZtcZItkwtBMadzIaSZdbtD8+UY/H1cxTipFTidduE13eBgjoxAwk063G38h3oM v3RBUgBz1bmm2WlzvXP9s7MhAObUhJOTOJlxL4eFjx/b5NFVv5n26KJVTO48+84aJscOXj1z9sqr pk+/MXau5Dlp4or1zMGwx0w97e5v6+Vt96+/L7rlzt9xD305kVwlZn9jpOg2lRltbKI6W12kyuWu Jtsc23yXYjLaLQGLdIMlbpFqLeMskqVDuihSrOtY4bKkmYrI6DBWGOcbFWPGUtd6lzTNtdS1xbXb pbgcVMBkoQGStIxtYBLzO2u3s6yEG76g24I+3OI/JeGIQxhY39WVCWVYQA1R78SG6IDxU5u2mioH QRNyxKo+5pJrTraBr+nh54xobT71pBOHTChXCm47Z8SAr0+o2xT7J8ZYgRXtwBhLpKcjnZpTCxkK vU5vaJ1rnfu2wltKjLq73i25dlq3257P+SB0xHo4Vyu2TrbOst5ivs31UO52i14XiuSNKDgrd2bB ctdy9zW5V+YZqwpGavXmMdZx9vqcYbl6bl5hQZVlQA6/fRuQp2sm1WnM8VkLLbm5uSE9LzfS90LL xe5L0hcXLypZkX5VyR3pt5Rsy90Wsi5jN3iv9d1e8tuSaF/Nm+OJ5ITCnkhWIBzwsPdw6OlvyGnM vyFfyo/4ssP5GfyKJ+LFvtPYl1X0ZeV9Wd8+ORVQrv4sh5J7U+LNlqk2sTPzV3T+0os7uMiPYr8R 9zlJG8rv7LllLT1AySvEARpjGvOwgtyBOfU5k1izdyab6z3MTMwrKRk5uVJRmtUiFWVMU5hSX2Ru zGAZ9Wk6Tk34wx34FFoWZPILz5f5mSOnI0FzxYVwHo/vaw/kJeL+DBGPZCJwjpUNzK3PXWe9OffZ 3DdytZxci1VRMih5qqH+/HzT7i2rZckjsIjn5ofFHW82dn9iiVtepZUtYweZTNB7fueriJJpHpRk LHIKKWyaclCR+BA8EVTt6e+NoF5vBJV6IwOqwl5+X+eN5BfjgXrt3oC4GlO8kzMi2L/sGawxI54h JQcvrn3FD3/D17KAv+u7IBFNCCN5T5s4Uy7AT0uLONjnxV+MGM2uWnsRHpDD549Zqy1uSzUPtln4 ze+nW83V4vDOwI8dIXGHy99zFxYU5ok7XG4Qul/h8u+2+PVZBctwnX/meVX57vTRsYdPW/L2B2+/ URT7xjmtaV5FMKuAPdXcdOiLt7pYeemEyUVZ5cF0t7Nh6JTbV+26fnW/ocMCnlCf9KzZYxquufG1 KFZRIP6xtFa9G7viK5HiIOHwaiq2D7aNsTXbdX86+WRPOnldaW7mdUlu5pONukm3+Li47eTd4I16 5VaQTq/sxSG9LZ3xTaOd0vk3CgsjNovZWG4qJ5yTp8FK8GN8kU8u8Lomp9e617u3uOVW9zL3Gvdu 90G3Sm6HO+iucCtuf8bFG1LuVEO0CnZiiHgD7Y538mvgo4lbYMchccY/IL5tQNH9cKSc/ZNn/BaG A71byNTLhcavxZ2hAf0H5DulSzvNhVmFY3wzfn3ypdVm4+WXswylYF9s0hWlWZlvl/QfP7LfLezV fa//JrYS8rkOVmaiUgAP6a6I91TnWc5bVdmo+bUaqcbZIDU4P5J0cfZzKmYPmdLdbpNRS3MXpKcT N5A2j/CTEhcdP+MnGQ3HHCQDO2hghp8+AiY2mR7+UUvOAHG1ikHmJIY9cCAPymMHPzH3nE0nM39g Qu2oC0qYf/3kGWdsulXaEPPtmzVk3KL9rBOHKozTDE9wKsZpZpmRdLUoozys84fGHwb+wBFrbzuo OM4FMwaH71CYJpsNBpPFjDOr5JIzjBmmXCozP2+2YG0fjHiyg2ETqWY3+c35VGIO02DzcjImvzIw MatF1GU2esMKIyPTyES1tfxVaql4UZYZcZnJpJhNRqMkMQ1hYzW/S434sorCZmtAvNFWrF5vhsNU axonXtxWRMyKVG1WapVxiqzskCrgoi6L2C0DiAVhQmTmtzwL3fJz5Sr1nXKgBTtVi198JSHiwkPn 7rmrmqELYmmXtvD7tMQ3Diwnzcsvr9NwBHs8NokVvjDYq9kcL7GcGKTX9f6jIz1lZVKfhEyNOBEN gkwtUmGkHyRrIk0y6aoxkzxSH8WpZuhuYx+T02JxlcqlWshcLVdro+RR2jp5nSbukyMX9z0JIjQr iqoYzSbFkkkZikd1G/2mdIslREVKoVpmLDIVWvpRlTrUWE8nSSepo/TRxovoYuUi9WLjxaaLLMtp hbJcXWFcYVpueYveUvaoe4xvmfZYPqVPlf3qfuOnpv2Wf9G/lMPqEf2w8V+mw5YytSP+esSYOTis FOBh7Ii/LWImHrOk8ojHNHHJPZirR+fjoOYIHskpNjCcGcSL5xyRH0lHwBzhMbMGI65Dg4x80vmp iFtUbg/FzG972qyowY74Ke2ayQh6cqRSJksQXLKFJKZYZNVk1o0GzaDrqqooXD8sJigKmcpttTbJ BqUw1BmZjYKQ+XlkBiIkM9u2IPNbn93OMhK+Sob/lK4MX1dXhr/Ll1ACSkx/bfKU5ki8s+XXV+JJ TtFL/uotYbyFDcdOQNzybzNHrNUY8ZE2azUGfARm3xyx8JSDMPtygmj8zaCZx/alNgGxi3C/iOtX Gv/DcmSZNceizPn848y+9WWWHtsc+/LxbdCxUVIHx3dvS5u7JkPLLFi5rWLlrousLtJfUKR1+nb2 DtujH7SqBj1D8WlFWhUNMoxizezXbJFuKmCl+kA2WK9nY/R15iPaEd2YrxToJaawMtg0XBlrekYx nGyapDSbZirnmS5ml5luVm7Vd5j2KO+YjpqssqLrRpNHCSolpv5KraleMaYrftNg01jTOaaHlMeV F02HFaOO0ba7fNxe7G2Hr61wdyDd4gwzxaQrfBJBDGQ0yFwSjxWXheMy48GI3ZMXlgsko1uSjKpm NiezD5oZD0a8yDYXkOomUjVVha9qMBrNpHZI57Vp/Y38HsZsmDXOut66zypbZZ4s9TfzZNfBxGsB /t5XoVnHLcECH7/i9J/iaDksQlSesK548A+lShekvpVKhFJ3mt7qhKI/agpCp/kAExc2KfVoWbDg AsYf/ZmYV8Zn1cKWxtayU3c9x8bE1rGVsYf2vi2FJDn2DsuLGbv+zEbHHue2wxYbr0zArKax8DZX kcrS+NB9FnvY4LHawzp/aPyhepAmJT6CGRxWNU2xmm2aQ6I0TUmTFGgRv1RvhSvZwbbAoNqt5bYi CqZXpLemy/yyUfhaBWFxB+nK6hNO529oq+WIzx9eyieEFUaMkohJTOIxF6umSNbAcPLtufvZ5F5d ekqXH09uVxOfnUFaF5ziOLQf596W8sSCgk1NfPUgFpRuE7fByWXU0hB1YKsfjK2+TXHQjjhmK35w q+xg4juz5EdIH0dsVmdtmiPNj4fLV6tyNUOE0zbEE3U1JxaRbpNxuioUr8BsrDR2hIViK4fnDz91 aeP4sf5hA2ac4ceCsklfHpW2t8w4Mdf5jvXCZhLf26rSDWcUXbxvmr3ma4PfIP7mwn3/qBF/I+25 ira13357tMtBhnRh5ZngEHz60NhYGu6gb7/99lIHJdOP/VgHaMkkqTqJTdQhv0zzlQvJBdTr2dSs Pk9T2Ud0OvLOAYbL2ZSlPEyTUX4R4heC3iRVx7tQfgpwH9AfOAUoAE4DTk1iIlAHnheBTahjGq9H 0H/Q2fordCLaIuBWYDpwszqFbkHebVo1zeDpaOta1BFC+Hak361torUIr0N+My8rKOefQmOQ3xfh m9Qp8bh+HelII4S7kO5B+zfyPoMWoP0LlQvjBxAuQd2jkb8cdDLopGR/fSL8D84jxsrHuJKHIZ8l SF8LTABWA6dBPpy/AnwBxK9D2Ix+GUEtgE0hykWZGulEioKWof3hyXGTGDfGcWxM6L/o049jMu9f d6BPfFyfAK8Au7v1rSeu+x4upBFyfzF/fMxWYIj0Cg2DXGJ8XOoH8W84oHl7Ma6dgKrMpH4Gim9C P2vVbbQO8UqgRuBCYspdNE8+hDnYRpdqt9K9SCepH3CY8qXPKUPLpyrIrwn1nwrMQp3PCH2YyfsQ /xw0oHwAD+NCagXORtsvpuTEZYP4KMxrE8oe5SsCcr0KmAsZrAMu4P1D++Vc5pj3b9iU2G9Rdh/a aeBAmwEBjD0xr7QI/AtQFxPtJOYhQQHknw2Z/g54EniK9yEFoWdJiLo2kSxtin8FmgZkAK8Aa7m+ Aa1ANS+D9k0obxL6Cp3husn1g+uG+rzQ1Ym874kxiLWwOrlmzgP/aYAfKNIeptOTKEJZLp8ZXGf5 eknVzXWL60yKCp0+R+j9C3ycXKe60ZvVThrP+yDahW6lKF93qPcSTuV00ac75D20huss17cU5XLh usbXI18TSdrYbax9k2ukL/j7CF2HLqZoShbH6Kt0B+qcoq2Fnn5GY5W3aaz8RxqrXgJ6I8a3HWkY j7IHNqyUxhk6qRhzOQ68t/eg6zj0PexstHWDshmy2EN3C7nukXKVPUxVN8c/UYm9qG6WlojwD2hP sM5EHqcc3fP+0/T/DqQ31c00G+FP1T3xOMZzI18T+mesAgimKNLbgGVAiaGUrTOcwzr0yeTQiA4B 85QIDVYjVKV0Uq2SThHIKR/pk7WThN1dg/qfZ5/RdZiva/R0CsmfwDaiLelN7A8Arx/0lG569D2d 66lLKZrS156U6wy3u6AqqB/rbgewE3g7ib8D70MfRwEn8b2B22exP8BGA9cl9DV+4Jh+vkh3gV6f 0s8eelrSQz/1nnrZk/K9hdt3sbdgnaIf16XGz+0jt3HcRnI7x/e+VPmetBv/LbAdfxF2+BWamlzX xUAFUI46diXtyE44qIewRj/WXo/v1GvjO+WX4ju12+MP6ufEX9C2xe/CuIuP7amdCVvG11NqL+Vy 4vtiah9VC2h20p7dIcqifbGPThF2gLRLsP7Ophmo9498X+XrUL4L6w7yRH1XKBvpXOV9WoO+2+Ut iXRlIo3lNlFZjDDSYdN5vlleI/InKF/RYqUY4Y2gd5JT02mx9jTnib8i0v6RyONp6lS6DXpXrqyk 36hbqYnPFR+HNCD+Ep97rPkMwzK6Wyfo8Pt0h/ItxtyJMT4v6J1Cnzhve/xbPj59CHlVGePjZQDO o95NwaQ8bhWy6BQyukXoMGTB69TeEP4GqXtRfj1dZjDRHYZC2KevKUOHLRFtbaVTDREhd0Xs1//E +vgMOjaZVqju+L+E/j8cj8vfYg19hvXFwZCXTn71M7oTa2mFkE+CrubrR/6M0rmOYHyThD/xGXT8 AbpA20zXap3Quz3YC/Zg3j7DWM6hQQivVTbHv0PZkaiDeNtIHy/8E75PReK7+XrRO8mnR9A+yvA+ CP8P7cofoL830QrYkjrDZ3S/xr1s4p9YUh+gXwIivhRYAlybgEhzJCjOGTfRZTxdmkUvoBcSUZzx taD8FmvvTqqTHyKTMhv+w6d0hVROy+Wx0LsD2DNkuozHlb5UJB+gBvmI2H+WqyaqEuU82Mc/pkal GfydNFNpo5lyHGEfcAv0EXxqB01Vz4SfdQbqSUIaCB4jNWqrES6PP8zLiTaOxD0cyiVUKfi6QfQ1 Bd7n+7r1+RaM6nLoA+8v/x6+W395X4/1M9nHH+ufGCevF3yizF+pDnJ6B8hP0Nh46TraDGyQ3oYf 3klL2K3xHZBrfQ+M6h5XlrAVQCOgKEvoHtAy0E+BPcBdwC7gv5QBdDXqfgq0nZ8LOKTfw3aBIv8B 4Angb6m87uDt/Fh6dygfxnd0j6uVVM0h9YVN7/v9PFH+HgorF8MOV8R3cMiLycSh2ahYN1Cx9D7S p4CvR1wtotuUeSg7geRf6tPPAT8V3eQY6T7G1HyAev4NvNONBjnF+irj+/P/pH//HWB+lwJnCflv oBOEDn0Mn1yPP8N20RlsX/xb2HONIxGnDCHPe8iZmiekrxDpPeYPujKQy7xnOsI1HKl4z3n9pTjq ndsdKT1IQa+kCIfyN5QHesaxH0Q4NK5jfX8YP9buT2EShSGnemUS+vL+D+Oag8o5pPmIr0P+h1TI cSw+iYo5eFkOyDbEAVnv4JDepxwOeQLyJojyQzm6ybWJy1Xu5LyCX8xPSs97zg94SXkW9mg/fOZJ lNGTdl+zPddtz7SULfmxMj3WRsVP1fn/JWDtvAQ8Dzz3f7Ud6Dkj6CrgIPh0r8PfiMJXvR9nzJfp OqKuFUTfPUV0dBrsEPbgo48gbTLCBaD/BHxImwuK3ei7fQjPR94bwCvABiWTLk76lX7ERyZ4ux5M 1pef4Od838Lb+W5ggv+75cCdCP8JgJZ99wzozaBfo3wUfM2g8AGOXgEaRrwRgD4c/TPiQwHs+0cH A58A6OdRuDFHy8F/D7CY+yM/cg7936U/cf74d2niDoBahM+J/vY8Q/zbNDWfv0B7njVS8/9LNHWW +AFNygE+30sc3c4+P3vGSVHM57+SOAR8oayMd8Gn1IUfDV9W+Nzcf0xS4W/vEf4kS94pCsp9Z+6/ ct+Z+6+gd4lz3qvoz4V0Mj/ni36l9pFutlXqS7MATxKwezQcZV5Dfw7C9tixv34N33INR/Ki84wE 4i9j77LD5j7JdsW/Bn0F8WzsZcbUnpayrT+wsT/c0/6vxv/TPfK/saeOS2JuD6TSZyfRM788iVyO nnvxf4pf2rv/23v5T+zR3ffp/2k8tc+nYBxKlRx6BP2O/NAv7ekH/FL8l/zc/zTe0+/oFt/K8TP5 It7TL0nFe+IH+T/UvYQ/k4H1lkKPdfefAut0mDIv/lZqvab60HMdH1tvybi2lEYAI1OUbaQi2JFi 4NrkuSuEMPbA+KV8fzMcpUrDI1SJ+KPi31YSNifenNj74teybfClvxH/rtTViOvKK6JsUxLNv6TP PfWW++fCP4TMRN/XYC4OUTkwBHABW4Hzjs11Of/WLvaCjJ2Xn3Pl/fGvUdfXP+UL/hTFOe8Cft5D 3I64HbY4U9tKffi9hjh/d+L8+g/Yxedp7vE7vniX1i7KnC7ult+msbDzs3Emnqf8I/6weIfjw1Hj gtR7FHG3dnvyXUomvxvSv+DvfuKPJO/npug+7INf0WStjvqI9xCJu/iZKHsmv5uS/s7/TTZxh+xL 0jJ+P8X3K61Y7DG2bvfIg4FmZSCVANXJ91Snyd+i7vsE72rxTuY7iiqP0BT+Lsy0iW42Pk83GzAe 4xS6W8+iu5UL6CbTYFpn4HfIWbSW71epfRWyj/3I3R+/y8zrdqcpxtzTJxD9Gwi7Wh2/r3u7KT7D cMhmQuLdUPKe/Wd9G9RTBZQBh4APf/y+M/5K8t5zWXKPP+vYnt/znv4eOkEpFu0l7mSxZ6sW1GMR fRcy7tmXVFuQS9dP+UIp3yR5R8Xfs12RfAcXBtzJtEnCL6ijkzFf4/idmbqcfMoqmiBtij97rAx8 JnHH+Cehs6t4P5XEe7vMpM7dJPEPkt8it7iTfEO8w7s6iSXQ0wfFO7PPxF3YBG0zwO8d4zQBsvrw OLC2jiH+obIZbXGI937xZ5O4Uxkv9NOf1M1M5QiNVjYKnXEl3wnalbUAl9186OjAJC7k797E+z1B haw+g9xX0TgxRn43txl6C/nI94j7wdNSZQ21NElfCX3dAt25Au3WU0BbBxwinzYA/uEqjHskeK+g FdI/qZKDXR9/X1IQRkc4ZKJKBZ45bA/xd7/8nXDyvdoi4GaMh7/b+oqXE2UT73I5SjikTSwn+Z4w FU5LhEXaS0l8lcSD3YBy8b8D30kH+M0h6pfQr/9K9El2QFd7ADwzkpCBbP4OUDkVsvo+hvcEeDkt 7wmkc5rfE8n0jJ5AOqfDegLpw36kHz9V7qf68VPpBT2B9IL/hX78VL2hnkB66Gf619ATSG/4D/rx U3LO6wmk5/1MP8b2BNLH9uwH7NMW4EmcUR/l+yf26otB+b+feCLoPOB3COPcG5+djL+QLDfnOPhP PJDECICfpbEfxz8H7gLGHwdvK56e/Dcok+3Ez0H4S9CTEm1x3tjORNsCyTZjDyb7+jiwvVuc9x1t x95PtCfaRj9iOxJ+TPyOZPkhyXYfSvQ75gVdmCjP8/kYBd9DxxHH8ovDjnfxsU08Dt73GM7+8XsT PlOsIynL+xLtduGcGPcDZcn8FcftAr0g3hXxdzvYqw0SEafc1gqbO5fc3faq1Dvr27i909AbpYay NfhwqMPE/QZuw8V5EnZfnCf/It6rzxTIwz7yBuJ/Rx0boIc22M2rqIi3Id7LXMi/Z4nfx30O+Q0a zyF8jU6xV9fx/cB0IjVrg9GnQ5SB+jP1P9G12hn8+xKx55n1OYifBb+DvyPTabHhHrpW34t8meqx Xw1PpafOttrV8bjal8wpah5MzcYnkH4VfKkMauDt6QOI3+lUpdo+JoeH+TlXzDuX/ybgEaKjpcDJ os/oL6gTNDP13YCQyYs4k8vUV7xzeh/5jKyaF+vqKBXpRvgXj9EKo0S369PE2X26sv573wuU8fdP 2mvUV72S0lNnd+1tyPU8+NJJyu9GUvcB6t10h/IC6rqbguK9VvI+4BhN1cHft31Gd/JvJXr6NSk/ 6ph/k7wjONZGcjyc8r2z2/gF7eZvJO4UttKp/N0Yf48n/I4eNNUn/h6Pv0tDPWcI/2sonaFfir31 EarXnqXh6nD46WNouCGDgvoD5Of+mT4busn9NX6HE6Qy9U7CGo8Px/y8CHoREE2u7ynJNfcX4OGk 7ZiQSBdrE2lddyTTzwZ+DcxN5PO8+NJEuOuLRP0i79eJ8l3cVvF3cBK/o0miK3FvI9bsER7uJudb hU//Q5p6d39z0m/9efpv3qHxNcy/qfqRd/w9KX8/PCQVx/p8LQHuy8X/lPKje9LE+37hw/L3/p8l 6btJ+jLXNe7r9aQ9v1/5qe9ZftqPTa6zFP3+dy89afOx73J+gSrdvpP5Mfrv3t2J9/WwUyn6w+8P kndyx2jSL+/5Hc5xeiP8tL8l/Vhb4l6RrhPf5vwMjn3D9VX8S+2r7hQ2EuDf9PwYtD4o14dI/138 S/13x6n4xuBnoN0AvhuwvwTiXxoC3Sm5OdDnNQnEHwOeBf4GfA60A50yi38p/sXutfEvlbXdKfaO teJ88mPf103Q7ka7d6OdyWgPVlx/Ef2FFRDfNPwM4LOTHgPfDDHGr/he+LP4E9qBt2C4Bu1cA55v 0c63gn7FkZJ7So4puWBsH4n5SvU51X6y3v/pPKLOa38OPz0v8a84/rfG/XN9V5+P/xl4l4exlt5J nkveSXy7hzq+3+frRb8/xBgB/dQExLc0m+JfJvEV5PoB8Fduo5J4OvnN0sdct2ToAAfaSQLt9NSD r5JIxhPf38S7tA/je/Ux8Xf5OuDf/nBwX+rH5KPPiv8ZOviufivon8Bztjgjcd+Lv3/mdzf8G9vp SduXY3wF+9d14k4myPd6QxS6TbA/T9Hs7/t88YlJG8y/g+XfFLm0dpokx+hUnJfXKhbYpDfjH3Kg rauSeDGJtQnfL/4H4JnkN5I8/bfdIZ9AfTgQHoz20Er87qS/zf3YCxKIfZRIP96vY99IwhPGWZcw tumYb7vwX25H327HGZzRtdxfEHuEHefxxXQ9fEqb+OYmee4Xdw//BE0gB3KZpNwovhmdKPAJyvHv agDxTU7iO6XxWh6NV/aJ72sS3/zyb33fA74E7+fwOScf/7aG18H9Qe4Xyf+AHGFT5PtwxoXnLN8P OjkBRQb9Nc7oF8BH/RvCUaAP0nNBLwIuRrgA9FLgNODhZPqvqJL/rQRZRZgDZ2nlsQSVk+dqcbZ+ NQE5iDaQLr2EcldRWPoSaaMAEzA6CV5mF3w8njdMlKuUPkEbJ5NJzkyGhyPvbcCQOL+Le4Uvk3mp MsOOl1EPUL1pHXyqNGBlfIdaF9/BPqE+yiT+/VDcCmAmY/w89HjSj8JqjY8D7uH3rz/4LiD1njxJ 1ReoWr2RKjUPXaH6qQFngTrNjn24iYpgf/j315MTZ6IYP9vN4d8T82+J5T2Je+/k/bgIa7vpBONV OPfCy0p+cyyotJnEP+DLJou9U3xLz7j3tjnhkYnvp7HWUn6u3krX6ffCl7yXTkvaounJuy4n39cR rhZ3QsU0LPENVXxYwseP8/UwEbbh2N0rp/ybNq5bSV+Ql39Y9vBvruJV/F2FfCL/XkvwjgJGA0uS MhyDeu/p9v7pMY6e32z8P/1+q+f7qZ96X/RL32b80rcaP4j/h+9Uen678UvfcvxS/AfvYH7hfZny j/hT3IfmdlTP5uH4HuAPMsIc0OU48t6GLuWg3JXSQazZd7A/fEeB5J1oJtLdsF9u5YjQv+WJ+uCf 54s7V343P7/b33NYDd91NvdL5R3xZ7mdE98hkrizHN3trrbu2D3tUBovbC1savKu9jp+ThM2yCSg cTvDbRA7SCaAuJ0R95ILEc9J2CUelhZjNVyPcCPyRyfsFLdB8jTwTEPatwmbJWwmt218HcJeyRHg DMQ/TQI2SNoPCsi/T/RD+pi/q4ndmADfc2Lr+d4kbKeUqFfcQyKc/PsofO/j361PR7m6X/KXkv5l ysd8tmf8l/xClHmxO3rmH3uH8x7/1h/+wvPkSfydl+S5K/lttNZfnFeE3cFcZna7fw8n75zDYr5W khM2JfMH5wKZ5vG5TZ3pIafnkt+WpOi0BMQ+zeX4kbCVjFpEG7BxSb3ThF/Dz3f87LAp8S4iefZL neU8Sd0qwthuxT64gn/nn9zvd/H3LUn8hoP3O/nO/9z/d4BNTUB6IwHFlsQfE9Bc/wbeT8BQT2R6 kMhc85/DOiYB2zUJOKDjTiDtfCI3kO5IwIOyno1EvtOJ/GgvYyBRJtZFVpgo20cUPAOmBHtHLvbK 0A6igiBR4WH+/7X1ohe96EUvetGLXvSiF73oRS960Yte9KIXvehFL3rRi170ohe96EUvetGLXvSi F73oRS960Yte9KIXvehFL3rRi170ohf/vwbj/2MTfUk1dANpJJGDyvnfXNW+lZ4mlaStk5bVWeWH aQuATDyDwAZApoj8cLturYx0gLrcgrZ5Siu3xzsRGNxfpJfdXLlsl7yZplF/JG9um8yTN7dHRlQK 2n9Igpb3E7TNkMjW3ZWBugywlQMS2ZOhccANwHrgSUBDhzbTe0AckOWN8n1t9QHU8AAqste55Qcw vAierwJxQEbvH8BYHqAvkikKenV/u9HCm79fcGXK94PLjqcDWAZsAV4FVJqH53ogDsgI3Ye8+0iS 75PvbXMEHHUm+R5aCkjyHWRn/D8e7ZTXtTuEbG5vt6dVRuoc8i3UCEgUlU+hTkBCtWvBtpYkFG9o K+snRNjQbrJVOlB+NTq9Gh1ZjSY34MlEPALw8qvb0zy8+ivb7E7B96u2inAi0O7wVTZCChcTk2fJ 51OIAvIS0D6gZ4Jmg86QZ5JV9DPSbndULkN7tSheK6dTMbLrZA9Vgo6QMyhTFFvUZku0s6itqKQS Ix4u+0QRu2ylMKhB1tsqA8GdckQIf0W70cz7t6LNkV75hHy1rJMbpZahlDdgf0I2YWZNYiST2o3W yjV1FnkShjkJYgmgjwxSPl9UdH4bKqpzyiPlLPIg7xw5m9JB6+U+gj4k30v1oHe3F2QFOnfKNwmu G3mlaH5oQrWGtlttlZ11RnkocqPy9ZiA60Xja9oLBlVSXYFcRBWABBkvRWipUPpVCK3CrK3CTK3C TK1Cp1ZB+0heiZyVKFMuX0rz5YtoDbAeYa5W6W0Q6HYRyCuq3C77ZR8E49gJUTKkZrQbbbxnvjZX mijma7fYKmufkC+Enl+IOiPywnavr3LeTrlEDKVvuy+TM8xvg7o+IXsTUwNGD5+SJ+QsCIILJlvu 05YeiNYFEOeKHCAmvSTt5kKSXpf28OmWXkWc05eT9JUk/VOCxjul3YlFIb3G6b66LOkDVDZNepfW IyRJO6VnqAIMb0sdvBfSW9J2qgXdi/hM0O2g/UF3tOW8EOiQOtpB0Pc726wePljpmbbS8mQgkJ8M eDOTAZensi5felp6irJQxV9A80CfkjopF/RJUB9op7SQXgB9VBpAQ0C3Jemz0i6u4tLj0mM0CLS9 zca7EG3TOdnSpnHyuzZKxBrLA7uk30mbKQNFH2kryEDqxvaCvIB9J+pj0gPSwrbsgKvOJN3Lmtgh FNpAezkll3RfWxWvZE3brmBgu7RGWhPxVUXyI2WRB+WK/IqyigflYH6wLFgVfDBY55CuhwFZL2H9 SqvxrKKgBO0BIsAaaWWbUhWt68KY+LgkWobnBhFqxXO+CBGejmO5B0WoVrqaxgES6lgCLAWWAZeT guelwK+AXwOXiZSFwCLgIliT+eCYD4754JgvOOaDYz445oNjvuCYL1pfBHCOVnC0gqMVHK2CoxUc reBoBUer4OD9bQVHq+BoBEcjOBrB0Sg4GsHRCI5GcDQKjkZwNIKjUXBEwBEBRwQcEcERAUcEHBFw RARHBBwRcEQERwU4KsBRAY4KwVEBjgpwVICjQnBUgKMCHBWCIwiOIDiC4AgKjiA4guAIgiMoOILg CIIjKDgc4HCAwwEOh+BwgMMBDgc4HILDIeZnEcA59oFjHzj2gWOf4NgHjn3g2AeOfYJjHzj2gWOf dNFWeXfdH8CyGyy7wbJbsOwGy26w7AbLbsGyGyy7wbI7OfSFQhgS1GYJsBRYBnDeTvB2grcTvJ2C t1Oo1yKA80bBEQVHFBxRwREFRxQcUXBEBUcUHFFwRAXHBnBsAMcGcGwQHBvAsQEcG8CxQXBsEIq7 COAc/7lS/sdTI13OmgzYa6VlrFjQpfS5oEtor6CX0VZBf00PCvorukLQS6lK0IuoQFDUJ+hCChhY W6DKXueBCRgHTAPmAeuBLcCTgC5CrwLvAXFpQCRXsevj9PX6Fv1JXd2i79MluzZOW69t0Z7U1C3a Pk0K1mVKVmFHYVroBvFciucXADYRPGtFqFYKo90w7OwA/IalcMR5IPhFCXu1hD1ZwraUsBtKWJ1R OokpwtIFqUpCx1lTxFIwNLAXqCooHArLdP1jn3sDbQUDAx1sV4IUR0pBPwe2Ag8CVwBVQCVQBuQD AZFWgvJNkdxklbuAQiAHCPImyOMhIpfTENkuWdmD7X+wkpG3U1gEvp1thRUgHW2F40AebyucEagz sseokHtF7FHM3GbQLW2B/ch+JEEebgvsBNnYFgiDtLQVngByWlvhK4E6K5tMAYWzTkrSiRg3pxPa AlNQbHxboBiktK2wgJcuQUP5yC1mTbQfND/JlZdoKdQWGAKS2xao5qUNVMgnnmlUJrqnApzK7ejQ F9tZk8Ii5sCBwE2Bz8H+GQQL9Xgr2KGAvJrfwaZETIFdZfegcF2grc7Ey2N/2JqkUU4fDTyYvzJw J+pi+Y8Fbg+cELi+rMOA5OvQ75WiibbAFcEOaXMkLbAsUBFYWLY/cGFgTGB6YEKgJR/pbYHTA7t4 N6mZNUmbHws0osLRGEV+W+Ck/A7RxfrAJYFIoDBQHdzF5UuDEvVWle3iEqDKROt9Id+S/A6u45Or OpgzUqIf1Nfop+nD9CF6SM/V++jZutvgMjgMNoPFYDIYDJpBMUgGMrj5/9Bbyv/PV7cm/utXTeFP RYQdEn+Kf7EGWxUzSDSGomlyg9QwcRhriHaeSQ0zgtHDE0MdzDR+alQNDWNRVwM1TBoWHVTa0KHH J0SrShuieuNpTVsZu74ZqVFpRQejSU0dLM6Trs6MuoYjk66+LnM7Mea/+rrmZvJ5Ftf6al1DndX1 I37k0Zp8lh7/8XUPZkdvbZjYFN2U3Ryt5IF4dnND9PKJwdObtkt2yTpyxHbJxklz03ZlvmQfOYGn K/NHNKPYflEM2mxDMSrkBMUMwyjIi8GeDOPFMEeJcgVgR7kcTlDOZKUCUa7AZBXlFMbLbd0bHDli azAoyuQT7RVl9uZTtzLQGPCO2FpQIEqFgqyJl2JNoaDoWLGoKBBAkbKAKMLg14mKAkw0Fi0/XiQ/ WWTAsSIDRFsyO14mkCjjLkqVcRehTOn/8GfWsFLW3m/RkmdGzgqNbA2NnAW0RlcvnuOLLpsRDG5d sohnBKNyQeuMM+dwOn1WdFFo1ojoktCI4NZ+z/xI9jM8u19oxFZ6ZuSkpq3PRGaNaOsX6TcyNH1E c3ttTVPd99paeaytppofqayGV9bE26qt+5HsOp5dy9uq423V8bZqI7WirZFzud43Nm010DD+XzsL 2i6ZTdDh1syc5mEex/yhXKG3D8nxLcncoRDbSObS5qglNCxqBXhWWV1ZHc/COuNZNiTbk1m+JUNy MnewjcksB5KdoWHH/rN14oUaogPGN0RzJk5t4qoSjUz/8Tm7kP+IbB+NnDsCfxBfKIDf7iXpwh/9 WfhjP4sWLbqQPxaVXkjUEC2Z2BAdOB490XU01TqiGWknpNJkWaRtNRpHdsQ7kVmKTrCFvDkeKmWl kGDEhFOXLm3QNugSPyosbM/Irpz3BHbwpQDOcdJFbeXi+Cxd1J6bz88vC9vLByQojquctmXkVPL/ D7wKrJzmJ2jEWYbAmvw1ZWuqNvyfqS7QXWDOBhTdtgwoKL8MVJVu0l/GzFCiXQwLCCCzJBIY2KA7 u4H2LdwkIwu2eAGIoa0dqV0MvqabAT2otaFXgQMDHR6wxVBTi8HGl8AiBCJeDDUEGBMQ20th2kqh msCSpWBNEEMgPDiBAEAeAwMAb6g4eAplbmRzdHJlYW0KZW5kb2JqCjg4CjAKb2JqCjw8Ci9UeXBl Ci9Gb250Ci9TdWJ0eXBlCi9DSURGb250VHlwZTIKL0Jhc2VGb250Ci9NVUZVWlkrQXJpYWwtQm9s ZAovQ0lEU3lzdGVtSW5mbwo8PAovUmVnaXN0cnkKKEFkb2JlKQovT3JkZXJpbmcKKFVDUykKL1N1 cHBsZW1lbnQKMAo+PgovRm9udERlc2NyaXB0b3IKOTAKMApSCi9DSURUb0dJRE1hcAovSWRlbnRp dHkKL0RXCjI3NwovVwpbCjAKWwo3NTAKMAowCjI3NwpdCjQKMzMKMAozNApbCjYxMAowCjcyMgow CjcyMgowCjY2NgowCjc3NwpdCjQzCjUwCjAKNTEKWwo2NjYKMAo3MjIKNjY2CjYxMApdCjU2CjY3 CjAKNjgKWwo1NTYKMAo1NTYKMAo1NTYKMzMzCjYxMAo2MTAKMjc3CjAKNTU2CjI3Nwo4ODkKXQo4 MQo4NAo2MTAKODUKWwozODkKNTU2CjMzMwo2MTAKNTU2Cjc3Nwo1NTYKNTU2Cl0KXQo+PgplbmRv YmoKOTAKMApvYmoKPDwKL1R5cGUKL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZQovTVVGVVpZK0Fy aWFsLUJvbGQKL0ZsYWdzCjQKL0ZvbnRCQm94ClsKLTYyNwotMzc2CjIwMDAKMTAxMApdCi9Bc2Nl bnQKNzI4Ci9EZXNjZW50Ci0yMTAKL0l0YWxpY0FuZ2xlCjAKL0NhcEhlaWdodAo3MTUKL1N0ZW1W CjgwCi9Gb250RmlsZTIKOTEKMApSCj4+CmVuZG9iago5MwowCm9iago8PAovRmlsdGVyCi9GbGF0 ZURlY29kZQovTGVuZ3RoCjk4CjAKUgo+PgpzdHJlYW0KeJx9UstugzAQvPMVPqaHCGwgNBKyVKWq xKEPlfYDjL2kSMVYhhz4+5rdJk1SKZbAzO7MzmJvvKseK9tNLH7zg65hYm1njYdxOHgNrIF9ZyMu mOn09IvwrXvlojiI63mcoK9sO0RlyeL3kBwnP7PVgxkauIviV2/Ad3bPVp+7OuD64Nw39GAnlkRS MgNtKPSs3IvqgcUoW1cm5LtpXgfNH+NjdsAEYk7N6MHA6JQGr+weojIJS7LyKSwZgTVX+YRUTUsw EI6f4pjRX8pjnTTUSRKRSEQ5ISFJhKz0stpCa5CWaGLfkxYQcUHBBoO8oOAWtzST583w62Y41U3v b9uLjCzIPuPoJFrS0v9kGoNpfiy4bLmQN88iVUQrSGsIqfNmxL9mMmomJ98NNZOTb04likvf9MqX F5tAE7nCO+CFRqTxAPk2I9Sed7Hc+DKYp3HSB+/DJOH04ggtw9NZOA24G9yiwucHwMfkNQplbmRz dHJlYW0KZW5kb2JqCjk1CjAKb2JqCjw8Ci9GaWx0ZXIKL0ZsYXRlRGVjb2RlCi9MZW5ndGgKOTkK MApSCj4+CnN0cmVhbQp4nKS9CXwURdo4XFV993TPdM99JZnJZCYhE0hIAiEYpZVLjnDIYYKMBrlB hACieIaVS0RFd8VzFY9VvJYAAQLqK8uyuh4s7Hqt7irsLiq6Rnl3WVaBzHxP1czE4P7/32+/3zeT 6qquru6uqud+6qkJwgghBbUhDhkzVyyPPBH+8O9Q8yhC4uQ5S+Yuemdl88NQPgnp2rnXrJzz4qv/ YyCktyDU9NW82TNmffyvxMsIzRkL9wycBxXOGk8azlfDecm8RctvOH1l5iycb0Wo9r1rFs+cwd+2 7WcIPXIznP9x0YwbljjHCkcROjIZ2keWLJ29JP5B42twvhwh2/8I+1AAUlB4FgX4BPIjlPkC0gma p+dnTtDrNCdfwd2duYTQVvQSno9eQq+hA/gk3LUN7UUd6LfIh4bBuG5GP0PrkIimQc0d6DL4ClD/ MxzIdKBK9ATMwxPoELS9HN2K9iEv9me+RLehNdy7cNcapKNidDGagBaju/DYzHVoOjrK347q0Fh0 LVqC2zJNmbsz92WeRr9Ae7nfZrqRDQXRTPgeynwj/DHzZ9QX7rgfPYSO4vuUXciCt7RBy5+jpehh LsXjzNzMGehBFF0PfeBRIzqE95MkPH02+gL78c3cUHjKU5n2zEFoFUYpNA89jPbhAXgkiQrTM42Z Q8gL77gBnvoQ2oF2w7cTvYo+xppwMvN05iQKoAo0CsbTgX6H93Pp7lXpITBjAsxSH1QPVxaj/0Fv oCM4hn9FFguaUC1Ywo2Z95Ab9UdToLfPwp2f43+TW+F7G/c6PyJzCbLDvNxLZxv9Bv0FB3ElHo+n kj5kMXmMW4pkeGN/+M5C82G+H4Snf4qTeDfRyGHuKf4F/qxYkD6WsQNEEugR9HP0K6zDSCN4Gf4J /gD/jQwlV5FHyF+5n/HP8X+QZsCor0SL0F3oBfRv7MSD8ER8BZ6Hb8br8L34IXwIH8EnyMVkMllI vuXmca3cq/wl8J3EL+NvF9YKd4on0k3pg+nfp/+dqc6sRRMBH1ZB7+9Hj8HI9qLD6CP4HkV/xQK2 YTt8IziKp+Cb4Hsrvgs/ibfi53AHvOUI/iv+Ev8D/wufJQi+IgmRKCmGb4wsJdeTn5FHyWH4HiFf k+85H1fMJbkBXAPXzC2GXq3jNsF3F/cXPsgf5jMwz9XCZuFxYavwgnBAOClq0k9kJL9z7qnu8u5P 0yi9Pr05vSPdkfkL8gAMgzALRagBej8DvgsA3psB47ahd7EGcxfE5fgiPBZm5iq8ALfiG2AmV+OH 8S9Y33+JX4FZ+hB/C33WSZj1uR8ZQC4h4+F7JZlNWskmch/pIB+QM5zE2TgH5+HKuZFcipvNLedW cpu5du4d7hPur9xp7hx8M7zKF/HFfIJP8iP5q/jr+Mf4L/gvhOnC28JnoiouEteKneL/SgOli6QJ 0kQpJd0j7Zbek1sAO3+NdqE9qNcHH+NWccO5XehuUsMHyO/I7wCfr0KzuEYCmEq24vXkFtxBSoQb xAvIBXgcOsknYK5fJ4+T0+QCrhGPwZPQAtI/+zTRzT8PWQP/a9TFvwJj+x08+QZRw7eSb0UN7cCI 1MM7f8NV8UnubfQxdxRL/BPoT7yKfbiLPMtNACx4lb9IaEJR7lH0S64V34J2keEIqWfljYDH4/Dz wBcm42r8HZdBHBkHWFTH/Q3djhaSP6IuoOP16AE8i5+L7kY1+Gb0BXoGqKKPcK1YLnrwm2Q+v4G4 cAci/HMwunpcgjnBjVbjFPew+C35CF2HDvMq+pR7EXp/mPySa+RPCpfheUABt6C1qDWzCq0Umvg/ 4LmIw1NRnD8G3O1mrpqPQn4bcJXpwNN2A3XvAz5wMdcINX7AnLGAF1OAQzwM3weBT/CAQfOBxi8H LvY71CFOJp1ormDHwHUQ4t9OX4amZZ5BD2Xmomsz96G+wA/WZW6GJ25Fn6F70Fa8Jn0TWoIKgXI+ xWOFEeSwMCLTl2wgH5FJZPP58IXZjmM/+gq+v4STi4SX0Qb+QzQJDclszLwP2F0GHPYhdDUajY7D KL+BN1zK7Uc16XFke2YEtwTGexRNzDybKcIqmpe5Bo1Hr6BfSAKaISUBxu34DzDem9BscllmOTc7 PR/m4R6YBQtm6zrgP3dYQ6dMvtgactGFDRcMrh9UN6C2prp/VWW/vhXJ8j5lpYl4Saw4GikqLAiH ggG/z+txu5ym4bDrmk1VZEkUeI5gVDE8NqIl0p5oaecTsUsv7UvPYzOgYkavipb2CFSNOL9Ne6SF NYuc39KClnN+1NLKtrR6WmIj0oAa+lZEhsci7YeGxSKdeNrEJijfNSzWHGnvYuVGVt7EyjqUo1G4 ITLcP29YpB23RIa3j1gxb8PwlmHwuO02dWhs6Gy1bwXartqgaINSuy+2ZDv2XYRZgfiGD95OkKxD p9qDsWHD2wOxYbQH7Vx8+IxZ7RMmNg0fFopGm/tWtOOhM2NXt6PYJe2OJGuChrLXtItD2yX2msh8 Ohp0Z2R7xf4NGzsNdHVLUpsVmzVjelM7N6OZvsNMwnuHtftuPO7/4RQe7hzatK731RC3Ybh/foSe btiwLtK+ZWJT76tRemxuhmfAvSQ+omXDCHj1RpjEMZMi8DayprmpHa+BV0boSOiosuObHRtOa1oW RNqV2CWxeRsWtABoghva0WUrozuCQWtv5hgKDo9smNwUi7YPCcWaZwwLb3ejDZet3BmwIoHzr/St 2G6Y2YndbnfkCpreuzC75xorsea0NOaynpnFtEexUYAQ7ZGZEehJUwzGNIgeZg9CG2YOgmbwacZw V/ssgMj8dmVoywZjMK2n97cLcSMW2fAvBBgQ6/r6/JoZuRoxbvwL0SLFkx5Ug+v5cnsy2V5eTlFE GgowhT5exM4H9K1Y0UlisSVGBDKYPjQB5nZG8+BKmP5olAL4zk4LXQ0n7W0Tm7LnEXR1aAeyKpPN 7aSFXtmfv+KZQq+05a/03N4SA0zuQFRd9bTLiZ4/h+F1DZ83uB17/18uz85eHzMpNmbitKbI8A0t ubkdM/m8s+z1QT3XcqV219AmLkRyJRLi2FVAyuk9jelJk9bOx+FPZEg9q1OSAStZDY6MaDdaLs0e m9Vo9L+8qTNzkt7Fsh9uy3WzfXDy/PMLzjs/r3vaBg46DKJyzORpGzao510DVMu+cFQuA4xHk5ui kaHtaApQZhz+OjP7B9HUHGq3YMqG0gaAf9mq3Ol5DUO5cjN8KHb2rRgBjG7DhhGxyIgNLRtmdGba ro5FjNiGveQAObBhyfCWPOJ0ZvbdGWofsbEZ5moeHgxEQdAl22N4/cTtFl4/aVrTXjBAIusnN+0g mAxtuaR5ewlca9obQchitYTW0kp6EqEnaAyGQe4gMmsf2msh1Mau8qyCnc/sxIjVyfk6jGZ2kmyd ka8jUMdn6yxWRz+Uxwyd3NQbexhJNvcFbCSYKdgCAo1dQihqRs04HDAI3XMRbv85S0BnUYTfDy3R ldxOcj1YNQLYDdftBTPnu53F8VqhM/OdVZzoU2sTVRB0PEaCINq+UWSZ4wiS5AbVobQpRIHptjy6 o1b5FHN8A8GWbtbigNb6rD85zjiVbGjsbjC6k6mG7gY0pMGAb3cDHLDprK+nqX8VTiZd3IAaD1fD jpuqD/X9pP+hKm4n9p08mf4yewQBjm5OTyQtwrvIQBdaaqkDI8MpyYbRiWt2osftMuSWKT1uvxJx BhfhOO5F8+cb/UnjdKr7dJdxugteP6QBXpfCCWLW1g2sqxEl+HoMjI/e/7vGaa+sWll6YSyJk+mJ r+DvsP2bj7vPHmnesPnlV9NF6ch5759taWWkzCCKamDkVGgP1Mc5DHkHepy70g6U02EYZAoUvutw OFjheIeus8LXlkNVyRSHvchO7C86c31MwudH/XTFkFlbmoBvjRd0AoN0r4K5Kr6w9MZVr0xrPJye iI/hv7yyd/OGaX842/3xN+l/pGXo5VLQRwbzuwGWg6widK1Cvpe5awVJVK5VefV7AV87BBRuQgLa 5dMYhFKNpxq6GozjDQ2o8hQA51T/qrgZHRA1a8yoJ2oSnG7F9zyP70m3duH7ttJ8a/paeM/z6U/x 7WAvqmjcLhWQ7AWxE0+wEphrIASruAGphIMTJA6SBo8HXXoxaIZbAMe22J54EEZ8KnXquAHvBayg R6PL6O6iSNG/qgawwC1KpQMH1u0+NOHy6vqB3KFDrXcmGgMzroD3Xow7yQKyCPC6wgosIUs40ogb 4ZUxRILCEmgQ4JfcRUd2PGV8jiobu/pXoVaYzAFRz8WkD+7ctYvi0j44rIPecyhu+QntbEO2i9sQ vwWub+FZL0+nUgCPrmyn9h06dIjeizJfkHrAAw5N2ou4zKc73PWkM/OpFXHXP8Bhwj3ObeMItwJh N7QGQuSQyp1A5ATgx3Pwcn7njfDkBuNUl5GF9TqhXzJ1i3GQwjyZ9OAajJ/blG4KCF+fcVP6DMI9 BtCninScsAY6m7R52sPac9qbmjCWG6v/jOecmMhIEzlJUG2chDRN19/ieDfH8ZyOiKbzEvcyeRmM YoK3WCrieWiC3lL5TjJnjyCoVkFRrdqZOcZwFgqfM1SFwjdQEKGA6yxdsopjtVJbdIC0yUEo0dt0 dy0CHhUhHKE303ugcHw3vYfssnfijdvvhJF+nUymYCaTyVMUxxuMzw3KCoYYpxpON5j19YwTrOuX 5GEGHA4HTAJIp71Ih3l11uudmfcsW009V9y3nuMLChroI5pTKAVtLLdm2eq1tgn1mpWo14rDkPet T7IWwOoG4BqzxhMzOROTzd2ryc9/+vrrHekB+KpfcLvPjf5F+glgw/d3LwR4Tsl8wUeFZ1Ahnrqd UJa6F2EYn04HhMN2tdDjCTs7ycuWzcHzhWHdjpHk78x8xSibFWhLf2UyeajyUCWgy5AuZ31l90Hj YLJ/Vcjq49TojDjYcUxwZcGGgs2uZ12/1j7Q/hSSFZffXh7klCqhyrYPtDwuc8wyXKrH6XK9ZXe4 7S633aF3kqctF+2IZd8CTMPusDw416k9Dh6/S6VGJ/ZbEdo98ypjsXGbcY/BG23SMr8VjdVW+THy G34CnT21h3bDvynifAUPQA58PyDVoB32XXgfHgSYDWCF9hFEZc6mok58HwMhsKeuU/AFKKZaoZii VNudOs4GmjIhAf0eXyf3SwoARcTIGA+CD24FjG521Xm9NdUDB9QmYsVA2C7gK9zAmmrkcUtirDgx 5VXPQ9f8pOOljZdvLHvubvJR957xq+/dj+Xld536bTduMzbcefDJh3eMH+Il//tiesX09Onfv3Hv jmOUMhoBch5hPypA5Xh8FnZWkQMX4aswh0NlhZaOdd0tFIaE4kK3rhZiFDdgCqwABZhR6DMoBH2G psFRo3U+ACJAMXnovUPGb/KQTHUZB1MUkn0XBvAwyfIMCwyLTHNOjizkZkmz5AXOWZHl8nXhNfLa 8Afye15TitApLs3ShDglBgUgFihF2QWJXiiNxCJResGkvZygE+hnCL97FQUkmWcp+T4DzxhkOdGu +DKDARLkjQFUCqM4uUfTxCnGpgqVQq4Q11veIb6rfIt9t/l4n5de83np63ydpGRn8g0GRqDErh4g drHxARRNNsYcxCj5YCCwZiyB5IkVS6IoDQRgOYEnA7CQadTBmRe7e4GUO7vTXzFq4dSLp1xNLn5l bkf39UdW/yV9/Od3nHjpk+668XePW/r0kzfd+Dw/yb6gqrHqom/+PLMl/e8/bOi6FY/BN+PnfrX1 wLlPUs83dz724LZtlKsCVAMAVR+KoSqCsnDt0FCosB/lOz6Xi0zp188ZLRSFskKnXqhoFICgiJza TWGoJB1U/lLQQuFEh82WLbCLDj+XF85cvhXXgxJciUejzT3siR6GEp4cSvQ6HMpjRrKLKjCh7SLt 4R7WETHfETHbkePwCpG+P8sXc++ndVA4ZxXTSvpaeqeHsQgPG+kP48u/DN6FK3MdyCeKlXUDvLiP d5R3VOJz7csqQanCt6Bb8M38crnVtlS7Tr/RdyfagDfya+VVttXaWv0u3zvm6y5nMWDfjnAkSLNI pJJmfSMJipKFfSIaKvQjDbqxpR/uNdPLXlOw0knmWkZymcOKAD6CFuYwHMTRie/dXe1f1g4iH67v KFnmoaCyU17isTzEs6n/Gz2MBOjpVJaNdOXGlmKDy6mDg3IfnFrailqbm3EiMaCW4hzVCrxwRICG UONy98LA3uiIFyy55vPX9n+1cNG6u9KnP/ooffreq9cunLfmjjlz1w8etWnSqq0v/eS2Z7lQnwcX bPn46JY5D/SpOLj+lQzCeP89v8KT562+/aqZ61afyzRuGv9M20+e3wqcJtMN2nQzyGAJ2fHc3dju MJiw+0dHrvAdI3VCMamZIQEDqMCOlUaVMVeep7QY67lNxpvC6+J+46Rhk4VmPJVMMObZ2o1/av/U /2lXeI3XeTtnUxWB5zXdLouSpEFZFjUJ9A6qkTsoZqKIpLnhEuE4WuehdVyE19xwl1IoCHKhyImd ZImlIFn70gKLhezDNhigzXJqETRb4i6bwB/mj/LcJh7znRhbtgnafumoxm3SsEbPDYd0WCK3SW0S kX7q+OBDprG1BiDBnx80l2DA6OpC/iENwa4hxxuoJtdF9Zgk8P91/fwsz+r4INyNgwftBw+uE7I5 gHhMu23SmPZCMFs6eAcnS/syJ6nZQaHejJe2MmU4mYyBJhTjopwryiVKRYkjNb8nTZ+80P3IEx/h /31oRHG4Rth3ZgR+JT2MTMOb915/153U2tkM2tKXACmTSQXXXsQDTEbabOIUnh8RmxqbE1umrFbE +cHrhCXKMtvtwu02sdSrcP7S8kJvgaK4nIXl5X36oHBBIcxbUWGhiWR/QtQoyxBBN7JqKM8QnZQ3 iCKdeVGmTxcZrEU3xQNxcjyhhekdmkrbaRQvPLSVFqwoKIxgak5E6HWA6WnGhFiBtoXCmQ4G5GxB pIWTlkqfi1LJC6ZnGTn9UKNqHDtp7DqVrUpSlbK7gSZgGWB5NdRXmtTQwk4fJS7g7ElQ7Ku9PdRk JzEcra4bSIknEQPFqbruIpItbyaJrW8vmzN3zT2Xt/1qY/qn+MJVg0aPGfGTx9J/wouuTAydNnjy /RvTLwn7mvfOvvKZmtJX2uZub+nPXWZ65zSOWtzn7BZJG7RwxGUr+1OteU7mC2EFaM0F6N1dM8mC AoKzzJmN74R1FS1FULU+Ey1Bywva0OqCTehh4QXuF/perkN/Qz+Cjhf8s8C0OwvMggKuXCwzy8OR opH6VPflnqmBecLCgpucdzof5h6yPxzeip8mW8337S7kRkHDbQR5qqDvKKvHlCv1Las3HAjzIVeh xoUKecVIOEajRARjHCzyJSIyljXaGzlQOHN61opNNXbBRMMxJzVNX9ZwTaVaYUKTeCn2iXysuAQm zllSU837pATlRMTjdlK+xHccuDD968+60h8+sg0PPfBnXHHBazUHfvrc36Yv+nztU38lpP+3Z3+F r/3DZ3jK9mNv991y35Ppb+99Of3lhleolvMY8J5pgNEOmLvPrMpIER4qZ7HTNAodSIYuK7jIYrKP IZWiUoxS/KyGoR5jScGiAuO/Rr1/51HvuzzqFf4Y9XLl1A8o179q6EprIBeSZFEWZF7mxYA/6Cei TQU6UDnR43V7XV5ODHG+KHba4eCXw1HsVc0ogllMJsvhswqnKIb6wOYFpYMAfsaj1QOzCAoaSfQx /P0L025tXr5s3I33HlqT3o7r7/1F/+GND1wz7qX0O8I+T8HYq9OHDz6bTj83o/qlgf2Hf/nM5/8u L4RRPwmcga7e2tD9lkcUCmVZkhDH04lUlUIbkiWKHQWGs1aazI2OqBGdqEGdV/5/kKt2wRVZBMpN WiMjWDC5jyd/TKdgYzKDO5ue5EvOPcYlz73PrRb2vZQe8mJaf4lSEQgjfg2MQUF3WUk2hnsk3DMM GMKjERKxERK0/Rf9tmys41qOCNP/0X31gum9ut+r/8fBgMt2PfXjvm/lPjn3GWnvnkD7Pfil7jnQ h0VA+3uB9uPYZQVD7pCHtJTiK2UXdnIlJSjq9JE4KiSMOCO0DxiLvkI7B3qHgnGiNF4S4TgYV2kL MzWPs5Ew6ZuzOT9mEGDSN0TvJ0vbSnFpQSKiYtWgFWogMfOKHlJuNFKnc+OBzlP1t0eha2DnlF9C omYMIPQwPhYKB8OBMCdqCSPuSRQl5DifiMX9ekEUeR2uKDR2uyISnBUL8SgO2wCz3SYcCpVoFJVw cEBMsU5Sw78hmf9QXEcpPCBunsc9vD6pHwH2Qb1TbicPDKTO5MaSRfekj2z5Y/rxjp14wp8ex/i+ xLbo1bsXrzlwfXTQOkzuvfXkRWTIi7j72NJle/GVf/wAL+uY2/mzqiVtjRNXj1//+MH0d20z6rAJ 8HgaOEoxo4Q/Ukt7vxV0eWp5rlBRt6hHVKIKhNhkoOCIJInUC8AkHsw3NWOgxAwmkaqKfib5MJN8 qTawtogti3UUlCo89L9APzmHfr04jjdHPREdR8A4atGX6PwFzX6wW/L8J8eBsnBMNjCXAlATaJKM DWEQcoCSkGJwfPoAOXPgQLco7Ot+hkw7M4Ls7G6EPr4GBLUKZoFD7+yitEME6PXOQRfWsrymNpv3 rcrmZX2yeSyezQsKs7k/yHKrXDdqI8ImYZsAuArK2j1oC2pHfCWY0hPQUXQSCc4IVG5CnJD1ntBZ 8Odm5+v87HyTn53TlpHV9NjsPMl/0NyL+Q6d3rSjDdS5VHPr0obuVH5KqFuFkmKN+doBqhrBGKk2 VM58u4ssDROAsYDkCFX6yLOWQyLcf83cTv+HQBD/QyB8nspytWwnop7NB8gfoCP/fAle8SBCogN6 YpDjeS+LDKNkOCDbdZPRLwwfCjBB31hltKQ56WXBoXEKwkRWbHYkK0S1ibS/NoP20QZ93E1b2QxE XVe5kXyXH8m57Eh+MOBgkvbvN44c2W+CSpRMMjmeRDkjziqS2IyL7MixI8+OAjvKlApitEQY2wSW QPmN/QedX2VHKW8SyHTCimgpIWAtojprHewgaBzCdhA6MkgfOnD6NFZgD3mZTEVOmKuplp7jz2J+ +tljETUFk6cqgTUzxG/IDiaVHQ37MI6TDFm3IeKQ3SQk8yu0tdpvYSq1UdooB9eHj+sV9ibuCn6F foN9nS7biCDX6wPt48kYbphkyY36JXb1QfIQt1naLG/lnpVEJ3HY7VUCcQsCkcFYrRJkKMraZY7L sAVGhiwrqg0w2243KJxanG1O4txHtiId998hRORO3N9SNUWNWNptNmzbB4O0YxtcIZ1gmihgTEYc SwxsdJKpeyJCi9AmALGQrTtNSvwB6jNONfgBz5j1AeVgz8nxFNgiQxrYAkP+GwQLhdok625hJglk /avQD6bHq0jLnAUc/ADMuw+Y5TGmXYNrZXCNcsXvtttVWptzR763O1pvr4gyl+Tuunp7dR0r7uoL tTm3Y7IZbBfUmgK6bAb0x17fwDocBRaEY9h8EJfgK6q8gQH4Kiy8nJ66Ld0k7Dv7j3svnfAId+7M CP7tswP4Y2cpMT4K3LmIynh8y3anLc9JZb/mZb6KE1aUlmQw/iKSDGagTCSOkxWeEEWSeS4iikKe owg9TFvIUhKwWSvI0DkVseGIbYKtxbbE1mYTbDLoC4xt6/Cy/05x4P+Tc/coDr3YVTKVZLy69dR5 vNpJTX6wDnkGoSz5UX/6sT2aWStH4AAY3Ny/iopNgEGHbI2oh+Hv3z2iXraqs8Xqeqk4wLzvuwNQ rM4WaW0s65O3xeoluxuSi56f2u2CYkG2WABFDy1+t92Tg18S9yIdAGENphIEm4++wZF9b5xLA8BW 8bcBsNrOtlHNfCboNZ8I7yE7CqG3rAlBB3YbbnfIFwrxvMG7bT5biH/Ot9v+up3z+fwhEimwzPGu 8T4r2CQ0KZcbU8yrXNN8V/mnBi8P3el7iBiBQo5zFtoUTyICah01kCgQpLxckKjviE69RL3OdPah cKoj51U8A4hBWU+wrQAXOBIUhmIv1hEI562ZrDmTynPuxqxNQ61DsGbApHEZKFrNU+WbaSV1Bqqp RmYtAZMGzcTr8cC38YgXOtK7Xzuc3rf1t7jgwz/h0Mov7/1d+kPyFl6Ef34g/Ys/H01v2fVbPO1/ 0v9OH8a1OLQT236a/ixrzfDdgN068qMdVsVsc6GbjDHGuK8wrnDzNq0QOAzy+bParDMhM/tZNnK8 N6ffycFIEMNf0K//f1Vy/1NHD/QWYzmbujWVtap71NysVgHKGjNNCsGwI9GoCeUeq4T0ua/xmvua v0m/mV6Pb3rlsdTY/qvTdwj77M7Zuxe9nO7ufpHDG2+bfrtHp5jzBNA4GM4wB8X4nBV12uzYOTA8 rWiOvKgIDFImOdhRYscSQHYGeJ3Cmxa0fMGWLzg7M3/d6QzWQn5yZ3FprUnPC0prjVzuyOVw/Y87 CxLZ69DeyOX0ujUKCnH76PDoyCTb9PCi8FLlBvtKxxp1veMB/TlHp+OE/QuHAdIuYjrcpukwHZri DJFo0KuKTtPQNcGvKF5fMFDoo6wkQCfd50PRYgZPv9/hsMuFCfujIkXtnFaZBRVTJ4uZYikyF0oq UrKkpK2EKyn2/7cwFv+v/Ch2wdb/MGRyBBA47u/KrUznYJ2Eaw31lSBQMdj56+zZVY3s6lyvD8pp YpYqW456hzHYdA6mbAO3MolhB+4TDNSbwJ+ckOxWuN4odkMqgtTDcJp7OWPA4nXFuH4E0CnGUIv5 M6NPkA0H37nxrXcby6aMzZw6MOXay/tGx/wFP7Fm87gHnkpXCfvG/3blox8UxEvGXZduxf1Xbxxk k7qv42rqVo6ct5bajNMzX/B/B+urinis0pncTH4Zt5zn46UDuPrwUG6UNLZgeNGwkhGlk7hmaXrB 5WV3uOwxalzR+S7JF+L5QiJfKM0XYgwU2cbZQjxfSOQLpVSjHUFLZXqihJRwpfGBjtrYsPjwymmR qbEp8WtsC/SF9jnu2f6Vthv1Gx23GNeVLIuv5TbY7tA3OO4y1pTcHr9P3+zY7CnMaWp9owlnKBFU En1wAqE+QSdf3T+BZgNx6X1Xhu4IkVDcq/ctLI3juOAVKO/I+mQL+yqFhV6O8bwkWHmprMFHsxSm alRlV/YbsvrGS+y6TYiGCwpDsiTyHBFxvKQY6sD0DvUNWhTt7gE+1OVFfZn5yqSsgSN4Am7BS/Am LOJO3G65+tJX0ldDj0crCdQH96Es3G4nU/rQrun0vj7BahgTTjip+KaXnHkkd/a4fp2TKS0E+ufM WTDFqdPP6GJ+wB8cVAZYBcfp4RQdEaAx9cVSHyAIVJRq/QGLgee76gpJTXXOv1JSytzt1N/uzXmx PG6fl/cxJBVBHiSm79Gv+u0ti5+fNGH6BelrJs6fe+s/fvbU92uFfY6Xnmt/on4Q/qip7ca1Z3/+ RvqfD+EPjWvvuvySZcOGz435ZiTrnpq9+Fez5r+zyn7n3auuGF9Ts7Dsgl0rrju8bDmL8KgC2bCP ednvsHSBFMKEIxb+qHSSZTsjWV/1HjGCSSVdaMB4F85ZmycsG2MPco43/CNvtvw1zyTO5ZlCOqtA 0yfKux/qbcHAdIJ2cjz1ucHiErIeLbqUzAIhXOkCfkM6JOgvvXTmn7S3T4D0p1a0G31kqQlHE98k vynzXooGXtChavkL5BH8aHmF4xnhhEPSEDE7ycsdouJOkLx+Rnr0M2LkXBjHrDAzL1IRL454J3hJ i3eJt83LeXXmzsirg2okt1ifZYdqHlPUHnao8jmTIssO1R52qKY8VD37gR0mU9QlkmplE5HVBpi0 S6IUrjFzWsAAUIWyqywm33JgVvrse79Ln1lyYORLt3ywW9h3bvsn6XNP3Y31L7nx53a8tuvqAyz6 AQUQklZQOYf/ZCX6oITZx5nw16OBZr1zoH8UGmmOco70N6HLzSbn5X7jQflBB8mRd42Bg4Gkp1ao 1YYJw7QxnsnCZO0KzyxhlrbQs1xYrt3kcQgeakU5ZQA7kamEGUI/FONTbPEhZBVyPNgqoiTLggqz ouh2h0Nzu5xOj9fn93s6Mw07BeSP0FxzmjS3pnlAFUYCIaAPuzFGfkGWCz1+t8fjd2qKUuhxQtFp ag5HxDDdhmE6FU32ewSHaQCMoUsC5zccDkWRZQJ98judponkoM8XNC5W8EQUQRocPZAsJOCJuyPU 8RwIdOI7t2eFVCoYaOwG06Y7GOj2jxs+e9jnPfIpb9pQ2ZQLoMovsjT2NnTOzwCq6+zGwYNwaDiY L/U+gOXjAMvHBMtnh1P1Ay5lzaE4VJYzcwjRoLqc8WSHmp2aJVjQCNgJXpqK4hoXM3ZqXE7IXDVg 8NAlG4wfS9/0xtGS4CAV+776w/hYuO/nv05f+3L67VLJ506/CXgz5IH7/17CfdodTH/9zzs7uF+C cp3aGJk98uxTgD19gB+0A/ZoWNvutFPUd+hm7aV4pHypwqmyTckji11Ddh3bCjWAc6EIeNDdMKT7 YA4Hki/wmCMY84rKy6qaKIjWlqn4eyCmCOYBwrxaZgvXYnqQqW4EOQ+55aK1cItQKInEphZqSFZf xrugXzzeZYWQVCVbMpFHa0PAlg3aMRLEiSigU54CUGw8BXCiztKGxlOtDcZx41yPx7fBrGeGBgv8 aaUQAiBkAbGUTmhriho8lkKKo/XYH61XwJLZBWYOqBFZnWEAHlhHuRKWop4+5NsJl577HR8892Yz t7WDe2HW6JdeOifNfQkE4ejMCT7MX4TKUB3pa1UoulIe0IPlffTycjD0PXWhweWjylN6qnyBPr+8 pWqDvrbPw95Hgs/pnrL84kwp5a1Mj3sm8HzZ7sDLZQcDh8v+4PmkTB7mxYVUdpmUvTidPyx4DqBc bAotFfmK/MmK8tp6vr5iFH9pxVS5OTlHnp9coa3T3tS+179PmnW1dswblSW1vuqo239Vn8V9SJ9w pX2I/R774/aMXXjcvs3+rZ2za7k4uq/ykXWnLI9hiFPsbNHcLtIldbs9zPk6yfO7/fe7w2EJ0UZB xvaHl6rVYc7WZ4YxA4lMIsSjJZQL55Scr7NcuISnnLOE+phpHEAJ1a3p2KHwZyphoMReVJKXJyWd 5ArLXmqhhJGIJKoS2xJCPdXVqfQG5eeD3azQv54Z1oWx2qr6/fVkSz2u99G+XUyf6Iv7iytLXhMP i6RIHCIS0c4UYxZ8IPqZRsyCEkRmwoh2ph0zr7bYf9APdksriP4kGNlJFuXRw9obupOffUY5+vHk kK5uFuuRb9+aVXzqmdJD1QKmD9DVV9Qap6KeKQJ17DugtjQbvHMRYZqB1+Nxe32xBCdKdjCGqFiA RlzDrL0Ltr0yctmlAxZ+PBfXDF9/28qCdv+1R+5Y//wEQ/EVvxL2XX1w8fTqRfPnPZkouH3KiBfW jFs1zm3XgyVx9dq+Fza3+lvvHGPNGN3vhpNn11w4CH9SFjbKGisvbbli/IXXA0avBYymvhEDFeA2 6xEsaI4SYYAwXBCGFLUXkaKi4nBN+JLwkqJNReJgV4O3ITjWOzaYklN6kyPlvTK4QL5Gn+e41ntt cH/RR9rHvo8Df3V97fs68LeCY0WZokBEqHRUuquEIQ5LGOuYIMwRPi74F3/G0AyPnQe+EgoDU1M9 YbvNX3LEhg2bZWuxtdn47OqbjeGozZ9zS57O22cnGQ4xQ40ij40GAFH40RqrksLTthybNYjPelWY elLDxQnZj0GD3ILb8UnMF+EheDzmMFVgKNJiGj5SQNELM1TBTIHATooqmKEKps5CimGsqZe+GvvZ 8gpbpMaBwpF156kBFCuW0jURqAHl8YdKphLAH1tJppgCWuNS1BqNgU4AmiKYwwaKFZdyoCj+EIXR 99mOpduv3tZqpf/x6isLSe2Ue1e8+IvrVrwo7Ov+1z3j73lrWfrb9Ac/x5tfm3LnobePvH4I+OqE zAmuC/hVEE/LRXPV2m9zYIcNUyf6EsQh3hm2Sf4wb8N2jyTT0Uts9BKL2JEMOnqJYfih917PasIH U9U00VCZkYqGi8JDXUN9k1yTfC2uFt8j5BHuYf1p4+mgJusBdQGZzy0QrtOW6G36M9ouZbe6S9O8 2lrtb4SzF1/lWOy4zcE5MLAYa2UV8+y3QLc2oS3oGDqJFORw2NAPfQxD10vsMuNPxSEYX4ktWQQa BaYBFxRAFoPOpQwmQQaTUWFPyWEJF0lDJCLZmYdHpY0kxl6l/qHagzmNFaCSJf7U0lwIOAtbHNTc tfRUsmtpfkXLrK80Usfhj+n9ALdm7MsGctU6qZLfo+NTyHEN2wu+/eXH6X8v/fKOl/5ctC1w27T1 zz+9esHdeI1vz2FcgNUXMVm17YnQwmt+/e4HB35CPRkjAGZHs/EWeIr1tEp4Pa7X6sN0YYB7QPhy Mlm9zD0pPJfMEmYrM90t4f1F7wnvuz4JfOb6zP2t7++BzxjleYuKkkFKrmOClHalfqRE7+cdTAbo Y8hwfYR7VPhydao+V/9M/MJ7Bp+yG9jD2W2GAyjSJpkISJKz+WswipuOuGEcMbFhWmaL2WYCaVKc yBKo6aSUYzKhRUnVFCkGmYxgTaaK0xk37XTGzbwv3qSK8yUUOuZyZ8lr0mHpqJSReAqi8RInFTKU Y3xaKsyiIgMbE0sSkz5SoLB2Qu914NbGru7eRMfCnxuOM8Wbph/ojPqTowMoLwZmnAUY0BzuHfo0 aPbB296/bsF7t7dsrtzZHXnxuhW/2HrTDU+sfWzj2acex9yGiRcT+5kRxPnOW796/eN3DlKYjQEu Wgh05gGYTbJ8RSjsIVO4lJBSpthmcwuFxcpsm+zJxqyzCThuXUZLBWEW2ej8SDjjPh3k+zsHB/qH L3Y2Bi8OT3ROD1wWnuFcFJwRvkG8wXOanPYbyIsdus83wUttGM4bdmwythjEMPhQWJXQPvI8xdg8 N9sP1ADzbgB13O8C6vFZOkhdZtTo+VBkncp/OqU6ba+Ulte261gPFtGFuHiilubWxVTMFuEib41R Ilkl5bV5SEV6QSrMIJUlsDCDEVtzpJDqzRNTycbu4+MMsJdPt/YYR3TBLRf62tDdmt3K4MwH11AJ ujRPYlnHqVuKMrsJR1lEpchdua/im71fpr/F7j+/j+343Al1x5qZG7s/JhO1QVPvuPk5PNX3VAcu Amav4bL0p+nvjci2ffPw/WuHznsGuIgLQNgmvIt8WLcK3Qp2BCoDVQErsCTwiPao/pwuB/UyvT2w P8AH6HyUBYtqC2Sd0xxhFXtI0u3iORGpj7uxO+OyeF+cRxy5DzPn/87+g2rZIkAyXFS7CeGARckk YOlAJsjNLOwyZmEXU8JBFTnb+h85B5w754D7iokdthxHpQ510bFoVfSUP/AK3oei6DRWkT+ZPJ3s RQZ0bYAqzV1GV1eKmt8NVF/uAuuGLcO7DVNUJFEGDclQnCFkio4QTuJk+apVOAl0srTGjA2oGVBb R50XwNYoV/PQCPAdjz/uCt6+Yuz00KDqy4YdPsw9vLF1Ye2Iy50/V0e0XL3x3BygiEvSE7mvgCIK UTlebLXYbIK7whZ3j7UNd4tKQaCgwpZwV8TqbQPdo20j3FOlJts82xn1Xx57v1hF6UWxi0rHlm6q 2FIhDYwO7DOkYoRtRHR4n8nRyX3mSzOjM/u0VLRVfFx6IvpN7NtS0+cVPZ1ke0dZ2CUxSWJEUBWT I21oPzqCQG0lt1jVQjjsUIcXhzXV66mJ16hxv/+IDxs+y9fia/PxFTDlZEoFY2s+xtZ8PWzNx9ga Df9ltV9l2RptRcOBc2zNR5WC0SxCeLkDx1FxUclrjsOOo46Mgy9yDHGMB0HHKMYRpLB1FLPwWeab yIayOxhvcwSSFcujlL0lx/Vib6e6jB9xuO7jp2nU+PFc4PjxrIuhFYSSj4b6MAWyFKiGZPmcb0CN yfxNid5xnnO22aqHLr9lvd+OV7T/6eS1v7/rlRufmf2nLf/z1UPP3HLz1pduvGFrU3BivHrWtLr2 O3HDJw9ivPHBtnMLvjt8wwtc+e/3v/bOr1//NfVLrEOIo7FAbjxjL/IC4nt8tRw1W5h6HecHcMO5 fTrPqgb7ArU+2dRMNydg5AgLktumanHFqhlYm1HwfgV7mYzxWiz4qowd3RQECjUsTBaGxXQ7JUjb KdQXykCiuClIFCpgWIA4Ddxi56d3swXlccyZ5KsdWNvuPeklS7xbvO3ejJf3Enc8u1hnQB9O0j0p EcCcY4hnKxw5R/kZy8eolM+HWfRasjuT1QcRYWRJmMo5zjNyQq+VEGqaZtftkr00RFbN9q0wdZC6 IRh12kW7FLeLWgjrMtAloktpqxAQdTYUg/kTPWbMZGAUPea6jlv3r/jlmI7rFk64qwFUwn/cl3r6 0e6ryBPrbpp09y3dLwNNrgdANbD4DAkdsq5UBtIRjFc2KVuUdmW/clQ5qUhIKVKWKG3K47mqY0pG UYsU0LEknnCKyN2KkSiIvCpKcQHxj/Nb+HZ+P3+MF/fzJ3mC+Ah/BM54Pqsrkyl8z7zxbN54lb6V Z5yNz3M2Pu9F5CkRqXQO+XHyj2dvKdvzRmeq92631NLWpItudINZWd/R0cH//fDhsx4+cfZjGmf8 ZHoiHszG7ETvW8N5IS5cwNcIawXBJwuCxPOEF1wI6zbCuTXeFGwSHaFNlMKmYxNwdJ8PqFKPq+om Gy6yDbGNt3E0QMKqoyPKBUwwQ8HGbEpbIbNMNDoom8xsEkbbtoDL/VJ0ZG+qZlRM46XGGdQl1YqG NFKbgIVJ9YzPrKlZZ8jZOEC7bDgSsqGGsGKXQiiLEXQjVo0H1zGSph5FugNkbUd6XvHAorqBHTUX PzCK//L3v//+pofso+7jp5/dcrBxFqVXwAXuOxqxRGZYITGrW4lTxWkK59D/KZwWOSUfoJtdDFPz BSVfYCvnbDFtCne9SpxixBWl/p6TO52ltQo10iB3Cqwiyiqs1VAj8rzAi3XKSACF2FdtUq/nrlM/ 5v4mSs+IOCYmpLhcLw5Shujj9Wa+WWySmpVb+JXCQ8rr4h/4D8Tj4pfSv8XvZY9TVQWO44koSooi w4kiy3FJdEuSyPF8XFDdgqCqgLC8jAEtBeqytNmQyndih6UIPPOuFMv0LBph1oGRXezdBAqQLY5I HGxFhIeg8UA5gJ5Wf0b7DOIoG0rEMBk5GQdg5gRipgkKaPpfoiPn9IY1AzVbVWg9zVYVkj+skYF6 6qunriu6Ywtyf9IOBQnALjdw7JhzyuljFFykrOaI4tfpYj7YHtndXZaqVBTUK3JBQYNI43IL6iF7 b0eEZdujuT1cLJKiFSWTbDlNzOzfEWWL/ju8NPt0h1EvZjN2prFsuy0fiUEdbPRVzk94LLu98Da3 u4Ed6JLjDj+9+evtoWxznGrOej/ocgjjV3QTXgxLQKH4+S/TC/Brn6afuE3Yd+4V3J5e0T2LFN2Y voLi5e1wqGP0+rfdAmNQLCisblA2OKx2QDav6p/Ns/tq91txEDcOoUh4XDgq8OPhcFLgioQlQpuQ EXjg5irhsgyePokxeg9oNo8jvB/MTNKb23/3A7cv6MXts7DO6mNyThnLL3xkMvmlkBzvQuP483kX ZV7UdZQNKMPsjH7ozNzewULLsjJUTIDOFMNv0ACZU/l4p2xBoS7URpteG+eP88eVv/g+iwjvC6cj xCdHYoo/FFE4LlYYFj1UpZCwGAsGDPVIHG+Kb4mTOPAxe3yTiU2eWWx+Zq0xNx2z2Nx0kCalaB8d qEmY3cbYmMkcdGZ+pd/MR0yZnThlaf74phAOsceFeh4XYo8L0agzkz4uxKRkiBneIUpLTDiHNPrg UN7zF6LP8yJSE4vjIwhTHwApQpT+OEZ/Bf9Bf4zjIm9OAp/L68inLDcTxVlQ2LMkWRLvxDfs/DEH zvpnuo/3ctn0cvXBSTdbLmgF6x+UZxA9jIhNX+9oVrvmdiXcmhnCTt2TF9Q504XumGRLfz6234aJ a6ZH9xbcT1Q/s2DFA0W3vvXY8ztj0y9a8rOOplljVw3mE/ePu+rqpn3bdneXkp9fc9Xg+5/ufoDs uOGGCQ/f2/1RXuf6HPDFi2+xXAInushWo9P4G/eF6yR32iXylOU2AMKsNPCDxhH/MX/Gz0dkt93t dYLOhUWvrup2zV7iZ3qWn+lcNqZt2Zi2ZevRtmyMCGzFrAWdYaZt2Zi2BeffZwFqU3PeuNMWY4c2 ptDZMPzZxvkp0QWp5uU/6SdL/Fv87f79ft7PkRqPl9Hm6Q7TzIVI/h8VLvVHCpfZS+Hic5S433L+ WIEb5zNO916gpVuymRJ2Xi18spunG6gM7tHCvKKpqLIqqZxoJEzRHsIO1ZkDMg02bqVcmEE558Xt BeJ1T173ScsTEwy1o3zhpcue5RMPbBu+pLH6lu5lZO21iy6+751uththWOYEXwpQ1FEAL9zt8dOR uOhqAbMJKEkuo6UAu+CU1IA2UrxUnio2y3PF+bJcawx2DvYO8A83xjjHeIf7pwvTlcuMlDPlvcy/ SFikzDIWORd5Z/mvxx5FFPQruMnCZPUK7RputjBbvUZTfWFeMoFluEtCzPYJMTSg8VBZ20dizpyc IzDvemWFXJRUdvNdLpKKFfZbrpJ4bZWEkWRIEYmT+h8FHkHrR1FXApTtJUizU7OX7fpBzNeIwgy+ zIWQo1rGfxDbe4kseCRlBwT1D1KXQm6LfxZyRmsydTrVK5ykJwKL+nvY2s8kYZJytXC1wlPZRJu4 2MZLlNuG2dsoGvb0Hb/5E/be9Pc7j6a79u5Yt3bHzjXrdhAXLr17Rfov3Yf+/hNciPV33n7n9795 +y3o0Lr0fD4KEHSiQny1dbdm9DUuNMYY/JBIe4QURfposYJqT3XBJQVLIpsi8mDf4NBo3+hQs3yF Nt03PbRAXqjNNxb5Fob2R951f+L/JPhu4XH38cJjkUzEG+OTRtIzgB9sjOBHG9OMz2x/L0gbNtPO ecPUdS56w3YbsgdKjqjYUC21RW1T+QgDYcTKLV9/btnYirY/v5ydV+h6YmSzbnSV4lqMLW0vx64a UuOMI/R/9pjnHeVGL0e5cZ6j/PSPHeVsIQtYJHOUF42s8+PzPOV5R/mP3eTMT27W9/aSu/JM1etx E2rQlppcL+ite3rwffPWH1lw3dGbpt3Tz3xmxQ0vPLt82fb0fOHVDRMnbsw8+FT67J1jB3ef5Z4+ dPDt999+60PKS9cAKb4OMDTRm9YFlS5s8DjG1/JD+Un8HH45LyqmrMiK7jIVHXEytrHJR6pStknG cnHEhV2k2Py/25A9WsV3ltmLpYkM5c+TXVkzUuylTo5zjjz4H2bkcSN1aindNUJnpz6/7R8Zb66z s7Dc1FK66yc7UVnfjQQsac2TF80fcsWVF11yyQVXugv5xBOtlw5+tnTkkJal3e/RWRiSOcFth1mo 4nzWTXyxu3iwMloZVjK1eHbxzcrdyuqSZ1wvVBzgdMUX9PuqxlR84BNCZAohRjVW/dPl6cp0dbpt ujZdXyAvUBaoC2wLtAV6R6Kj1EEDYUr6DCyZpjbbZiVmlS2PLS9pK/mp+qh2X9kDFfdXPa0+pz1V +nTZzsRvEt6yvM5TnC/E8oWSfKEsa4fk2tBCLF8oyRcKaMSqs7B+mlwa11Q+GEl4eFu/giB1EhUH KpgfOzAkMD5wVWBb4HBAdASKAosDRwN8UeCeAAm8CrDxAF4wr6rlps0NGpZt4CNgUmADsx02O93e 2qy31W7WYtxvesE1BaQg7JH47GInM4E/z5u5n1suCmA+3M9WFMTBkoDl8tdW09srmWfQnz1Sugp4 KY4EIvTOQITeFWAmSoB5VgOd5IodUkk53LorXH+kHJfTt9A7yvOxgKxA74DCV2y3dHmQvSpaWl7b Ur2/mgypbqsm1dRDXIL8Wc2KoVwkO8vARGiBdiDC9nTTTkRKHIzUHax7jghzY1F5HGE7xFnkfs6h VXw0b0AF+ufcwKnWxhzRd0EyIFs6LrfImky29tp3mcyuuUA+pKuVLbJSrZmGYNGsZ0+RLyunrdK+ hTHBXZEwDafhMjixWI+EkFImhbDQFw6FbjiN2mMhVBzTNbkPGNFlpYoqJvkQKjIKqETP7iRiBxZM UJ5ctWoV6sWgqKch1fPTC6WJ0n5kQO3Auv8I7YIvjWdlvrYhOxx33HTzDQPiP339ofEXDyq/d9It r04z27Vl829e4PVWhla/9sDU+a/fcvgjfGF44dLZwy6M+ePVo1aNG7myrCh56U1z/ZdNv6wuFi5w qSU1F988fdrjl79I6bQk8w9SLjyEfHS/kUo30SRq2Q8HXQyFtgBGWNNVzCGvoSQdKggJzuYwilEx 1p1xDWckebgyvEVaIrVJmyQegYzeIrVL+6UjkshCo3Mx0qcYFkk0+IstDGY1/1whFzV9hmEHlf5U ylAnQk4JyOov0j6yAPnxwO1zfmQOsR+r6W4wjp9qYKs03Q2UyZs1Ncab2cDQuC+7SEN90GYd++UR Fi1FjODYhquvqVi9eueuXa5kWeETjxsXzX6SzNyIpWvSd23s/mljRZBZksDLjtHfm8Xj96IgXd0A G5FEXF4amHvSqnG6a5MuXCK7vBp2eW3AzE2YJlTjjft9VHENMq3Yx/Rhn5M5gHvCGnyMfft6NGGf O+cKzvkdfcy08VFNWKfzkfHh/T7sGxdklidVgoMng2RJcEuwPZgJ8kEtrvQIDgUjJaIcUY4pvJIX HEqP4Mj5PVXm7aTPZ/JCYVqwwtyOyrjAecYndS/+p7oLEoStQTdkJQcjoiBv2HWHTqO76HZTUHl5 LYR02cw6m8rLV4EIhntz62elCeZw8jGCYM4nbsjN71/51HjD1mEzr5048e4LOh7tuHTR+AHLyH3d O+/qP3LipHvWk/qzHwN0gtRfDNBR8Ve5lWmfICNVFrGoIkGRBUyEErbjojL5ySHjk0OAGlTa0a6G 9gwQMCo261XK33WzXgGDplamBwKcbifkOJer1GhWCqO1qAwOTMNRiuO1yAsHOPvYurWsXy2KwMGh 9UFlSkKtRwPUS9FIdSqeSprlJmUOnkPmy/OVG9D1+HqyUr5BuV5dh9eRtdwd0np5g/Jz9KByr/oi elJ9Fe2Rtqtvot+oH6P31a/R39Sz6JRaAcNR/cirlqGEWqeOR5aqCJbTWysAqtTmPDsKjIcOHVFl zHKwoELEeCidC1rHFCc6K6yWCIJmo6EnnyRhbiAdSh5KokoaqlfPfsJClWQ5rqhuRVERR0g8G3kn qCqoLCyMTpRUhUNYqNSwVixblpX97TEc2mUJbQIRoGQpEWLhYttXf6DY1BUMdKe6U0F/1/FUdoGu vseDZdafvy2IxsTmIl9++KBUcz6szVWD8S/T1/zP8XiRP/n13vS1fKJ79dzFk1eQ9dRri5GIkLAH sMPJF+T3tjnpYgzjPtlwIzGnzb7XoelMxJ6wbLRkRrTshf0d9qz7GUQrLZkWO1dNDiMNtCEsOmA2 dI395IBmYsKrvKnm/CBZRmfSnwQ5ZHxwyHiPbXPLxUKy0dEPJYYQUKAbl/N9VDLavMK82+TMSPZH nnI/V8PnCyZlO0pRtNYIF2Q9pNaeopJaXtQUlxhSAk6BR7xoU2x22WkgF+eWwnLIVgC2Ulwql5P2 WjRAGixfYB/GjRQtqVEeYxvqGGmOdl7huMy5UJolz3WuFG+Ulst7xX2O3c5/iWeVMptZhsr0UnuZ o9RZ6R6E6pzXy2vlB7kHtGfxVrLV9oy2C+0W99l/y38gfqSc4E84vnCeEs8oYRvbM6CxoyFmA8KY SGdHZw5tQ6rdwTuRKUtyXHLE7dRgsEucjrW43pn5wKqjXEoH7CtnVoGO3S5RtZkJNWlO5i9Tp5vX mDebG0zVVHnARQqOLGB+HHZamTxVmQ28No7Tb1b6w1/IcnMsHFUSFFWVbZqmGqYJ/H3MTgE5QWcZ Zc1RHfbIr01Jjkim05kUJLcgSHaAc1y3u3XdLoOVm1RlN9xOY1RzlIIIlpy87DA1u8665wQ+Tve3 U9JxOuieGtV92tAx3UrbpnN6J37WUiPjVbxYvU0laieZYinjTbzYvM2kYcpTLJsh4BbmkeSAuJ7d hU+7Ts9hKlGg8VQq5Qe9Bv4okaX8/+f41BzVmez4X4SnSnajgaZ1uWDIMe1Fk5o69IgWIa9kjoFO ewzZM0c6UJUj4gQc7fmdmOYx7bWT2G7SI9sl+vMxUBGdNKa9hoXEyJlj26VIttaZ2/lHN2cc2Q2q IDwbuNWRHVIVfeIONIjsy76p5+E99/nYfWbm2E41wkfQoFzsa26rx3u7nfWoAhJ1YLuoU7k5byYm sztF2K5AylAYP3H5WJAsV8rhMemX9z03hK95bu/jAy7cvS3d8fJzfT4EBvPIcfMtcm33g28fInPO fkxu3nXuMHAaB8ih/wVOY+A/5+SQx4FtIk8UkYg6YKSDaeSOyiRDSvY7FaE9Did2FAeYv9yaEKif 5tjMb5Yfsj/s2C/sF/dLbzsUh+WtD3IuxaMHjQF4sG0VvtsmVzov55ulZluT/QH8oPqgbQ/p1H5r e8v+jvEx977ye/1PxmeqM09cNg05TYdfB8WC7u6x7LTkEBHRkaoSkW35oygBbCgbljtHFDlJVhQs iorAc6DyOUCe69jh0A0bKBVEt3GaoYoO4lCN19HrCjHiSHEjpHBEf13Helzj3JrGqYrCcUQES0DT kDreiZ2j9Fu1YtUxQ1RutVSQDHsscYLYxn4SZ6hlj3C3kuLxMJejzJuZoZo6lRUWICuMz4xTXWwX 8w/4zKJ0c9iayv28Wb3DsU5mWJo9QkZRt0FuyCFFh91fUG9jOxAL6rViXz0HiZ7viNYbLIbfU4+L o/WKFc5vBUo2M/ccW40AgVPjo6Knjq5DcKXYgVenH/rLU/3CFfGdH6bvxXd+8vHg9JekDKe/H1l1 Sc3ZtNb9Ozy6OZ2CcUXTE7lvAEeC+N85HClQ3Q7OxoUDDqdoE12W0xGxWVokhyuBymTwk6D/UDBg 0IwZ6UxshHY6wthBB7EoXF/mnurYpnKWbgFAImVVtQY9SJri9Op+Z6mtVCvVB2oD9QH2h0xbmbPM dam32dnsavbMd853zfesFFfoK80b3Td61ugbzI3Oja473A+qW22vGC+b+9xfqV+4/6V3G9+7M+HC PEZ5XbZwiHcMc6x2cI5AT/ezTgRnT4h/ncOhGcArQXMIuF2uuFN1w4lDA2YYt6lgBqsuGpxsE+kD UNgIk8rwa2ES7iRDdjlgLix3J5ls2YY4LSe5yvmakzg78SW7HbgYDQ+p9BKbLSuiVWnjNW6CltGI Bi12VjpgbsiQjlDkZmCMMHnd9LeRAInofmS/cep4wDieau0K+o0uVkJ+ajjkMUruvXhGUWodwx/g enbgNn7gNi8jLXMC2TIncG9e4858uruuXi2uq7cDle3y1Ju5zWTNVF9GoMMA+rhKs/EUdSwkP6fC gKgCPfg29wUVDZf6zIRgSy868EmyuCj5t470NReXVN08tTY99zmjrCS00FHAl3U/dN2qm1eQhWd/ u+2S5klUyykD3vMe4JUdb7N0Zyd5UyZOXO300VXU31kKFPBFhWxN9YA1Ggp9SJlSadTjenUUHkFG yKOU8cZ0PJlMlqcpE4xr8EwyU16g3ISXyzcpd+I18h3K9/gUCQXkBO4jJ5V6+Rfyh1ii1LLH8NQS YK8K/TnIGBjSZLCiEllV45iA+COY/lQWmSEkYYjqDB3RXZKWwqR50q6STuzoAGEoiC+TKxBCEnVb Mbdwsb7FjpHdsrfY2+wn7QKLKi+hl+zLkXorxtsQHo8WowziEPupCxRwGMujlG3QVZncKmk3LRxP stglo5s6ARqMz8BE/IyF8eVUTcN+MPdTA60ppo4BNHf1wQmZOmWysyfTuYSzA3voLNKpzP5oSGsz TjHYy8A+HGw3QDY7sSdUr8je0IVUOdvhq2dml+qtJ25IQe8PjKVmABZj2Q0DA2uinjLy9LKm9Hhu VvevFq9cgP9+HyeL913ffeVNyiMUzvchxF/CtcOYkStqRu/j2s9NoIl6/3egO/gYdwbpCIwsXN3r 59gG+ujyUN6xmSALFr+3Ip3evSedXvHe4tQvr/7ggQfev/qX3Jml7y2FOkz2LHt36dgr26984IMP HoAM3vvDs3/0ZLLw2h+edf4T2E/70586Jvese7fwzqscDf+SQzL7xf8n/1ZaTvPXq3ZsOrOte66B ZI391xnM7mD3SRelx6GhBjqz7cyNBsrV93z0AWKuiv6/hlxqJx+iK/llyANplFSArhemoia8Dk0j z6ObaeIKkMW/iJZC2+fh/GLI99F7of0USEchNUCaCimYq2uENAPSJHoObffSe+EZS+hzWL4MTZOL 0GJhaqYb3rdZeAPNgfQYlJ/k/4a2ivVoEZw/Dfe9xiNUR9vAPZvF59GDUP8oXJ8JdY9B3gTnT0B5 OtxXlSsr0l0oQHNIItT3gefcmRtvKfcrNJBflvkLjKUZnjka0lp4xwTIR0AaA21ckF8CaR1+A63H b2SehOuQo9vh/etoPaRhufxSeM4auD4E7iuB89uhHIR+iJA7IEUhlZEXEWAxegXyShj/5dlxQ3oD zaNj7hkT9D/Xp/9M2T6O6Z3gna9CipH6zGeQK7369uN0+4/SKK4GtUG+EFII0kRyCC3ixyIM8/WQ 8BniaALMo/P0KaQL+VloHJxj6OckoQM9TM8hNbK0LNPNP4q2cKfQILh2o7gZxjEL5rs/pNOoknyN +opxdBvg1zB4/ipIj8EzTzB8mIUmw/v7Qf7/tHcm4FUU2R4/vdy+N8GQBQIBktwLCZclQiCIkUVy E5OwRCUQCElkDEJgwKg4E1zGceAqiqDghjKIyjYuSPRxSRRD8HvBwQ1UcHyGmVFHGbd5ynNQRh0R Sb//qa5OLk1CxHG+933vu8Rfn67qqq7qqlNVp5aYEfrHQoeWgZVI64hdTlw2cN+Eep2KtL7nFoH4 JWA86iUIruD8IP1MLnOud6W0ZRTCfoQwMxn49xTg21knOQ7Hx7v6Sz3c3CZpM8KsQrkegtRBIufB RuiZBM9ewnt6AQOkgKHgY7AZVIPRoAgMRNqEdDWhr9AZ1k2hH9AN18soQ+RN6Kz1DetFfVptZpN8 F6fT13iSqiV9+Z3cXlhnkZft9ru5TbHO2FLod7XQ+7/zd7JOtUq0Pf0wjec8iDYI3bIltzvkmdvD Gkz8l0Ougx4vZZ3l/NmSy4V1TZQJ2oSUY8O+dZhoI5DoitOkri+1pV0WrXI+PYJ3zjJmo0/ZSBP0 RTRBu4dm619QvjaIhrqGwQ/fg7Ah9TBN9eymEajLyXA/4JBrGXezcrlrN76zFuXZTA+jTH+hN6v9 9GbF5ao1P3WRstdVqy4W96dIJ8pu6xlLJvzZmfr/GNSDrlr0mbXmZ65m08T33Mttwn1YGQZ8toR/ HQiCwZ4MZa2nWmlwT6c4g+grsFAP0GhXgLL13aifRPTzaAvwn+76KzVpqzB+NZt/VoIUVJtpmTuR LlPXoE9DWupBWsrw+yGvDtOjk3TOqUu2tPXVKbnPlzrlhTTQ/vZLPpJ8A76GHhVBJ3vx2MD9sxgf 0EeDZZa+mt+16udeehTyDls/HXpa7dDPs5x66ZRibEH/brdT5GOF/f3cP3Ifx30k93Pcz9jhnTIs /u3qVugx98OvU4Vs1/0kk5DHD2TbRz+M+p5hmkah+bjxtLlFSzC3GFm4/xNwmY/ju69vHVPLzBY5 ng6yx1LLn7rY46hrBF0p+7NHRH9zlO4T42ipyF+UsY2WuI6j3tEHivxulG0Q5Yl8V+uzUObraCW+ o5d2G9oj/MFMLhNRF0RJPC7wmKjdj3LmsWgVLdXegb3AcUdQvBgvcmgG8r5X+GFMZcl+rhm02ThM Wfp09LW7qYrrir+D88N177mGYjyJ6Ceaabj+BMIkUjTCbRRlEKDHhV5w3GqYVCgL9xxyQ2cvRhh+ 3yYRJ0AJsjweEWUh4sMWYR3mssA7jUSaKuyJw7TBNZ1moA1tcgdpEyxoQrvYgnc8injTOS+I11uM 1/fTJWhfy9E3LUefQ0L/K8zjWi2+53r060ALooxqKckVRBlWi2/P160+9jZuP9pW8rOOGPejH2Z7 4n66Xc+gAqOaVsFvlQv9JNK9A363oP0OQ9tdgfhe2W8T0l4Bf46bw7YM2wjcXtwB6mYEhR1AIg9s pyB97VPapE2i5dDjXM/9KIdbaQhUmo3GVDDcQrgXS1ZaCL84Syp9tTj6DfurI+hNpNCFyOQxdKd+ Ey3QSylLG462G09D9D+grR6jB7VYqtT30YN6A61kt96NBsJiL9aehm3J/geomP3VN+FeSxX6WMRf TlfplVSjbYfuvUXR+jzUNeK57oSepCP+UbxXonxIFVop2tYy3B8zn+RwIo2nzRmMPoGGiHhhiLza OPKsFuGrJqFOkV++Pym/yGtrPu08tpM/8Z38XsTjMPqDNBbl9C7ob8mWKeoqqgUb1bfpAu0i+pWy xWxEuRY6mBDu1kcqN4Kh+kh6FtyE+7Mh/xNss9yw3UbSO+BWvPt5yHpDLPorpObRuSzhtx6sBa/a z8LhdNrzD8fVx2w8yf0MxhqgfGU2Ms7wKOdzkd65+vlmIwNdnMQYS6i7+1rqrg2AfyriOdyuPmhP z1C6RuY/O8vT6cC/YWHlGAj/Rrs+IHv8AN4Nkz6Wcmz40Xn7saB+l4CfifL9OyVaOkRdlYPmu5Cl ykGK066BDgK4h8DdzS5Pu57gv1r4O+oPukJc5k5/p9tZr5251XqqDMfWg1Z9uJfGMXoOwgOn27OX xjHGi3j24qlu/fFOqKDB2jrOE3RwwKluYzINYNR05LU3x0GbA63uA+gjAIcV8WNoPMNtl1GfxnwN tD4fSQVMWLmey+WqrbOe2/Vj14uzfpC/gL6fJkL6IUdBlkBOsmV4m3W2W6ef3Ze0F8bRNoZ19M7/ T6Dt7AMvg5f+3WkpBF0FccB4F3ZIDuzIZtgnl/Cp/BPoS77PBI+hH5oG+Uf4YfRuGQRicB8Pv59D Pkx0/Gvc/xL+zRamqvehjdKu7AW/HTKuR76vxIp//BWi774C26z4x7eCy3H/JcB4fvwvkM9DrkX4 zxDvFsjfW89PVMJ9LXgO7sNwXwHKcH83ZCLk2aAbSED8NQzbI6fMQ39y2f7844dK2CxzkE8vr3lB 3uicQ/xgaddnJ9I517DrvzMZtmbgkFY5YM70Aey+UPjc53RzHFuiPlvC0aebJ2BTnsV2NNuybD8L +1FKMX8TdizSJepuS7ad2X5l25ntV8hNYs3AJfIznef5Il9y3AjvW5WvaD2IA32krEaYY+oAcz/6 nljo99eYGz3CwN0VlFqYBzB2xWKsa0K/+zXk63CnQH5tj2l233pKH9vJmPZTu890jPwRY2qWpNJB R/4250kmMs6x+EzpbOz+0WN5B2N0+Dj9r7rtcd4mahxlMe6A2cg47dJT7IBO3J3ZuWfqdtodZ+x2 2CW228kpz526Z9szval3K452d6bw3EJ/ps32t/PgbMet7U26UUYF4aAfGCjH0M3oL2D/mykAY5R5 L/wWe76nLM9TlAX3MwDjZsvnkFX8DHKDsorXt/mv6bTcDHec/roIWyap6kyfnXrL9rmwD1Fmoh+8 m/NPmWAMSADbwZV2XfMcEmn/WcWoy/NcvcL8Wt8PHDZgp3Ik/QI8BXcs3LHoi7sb8ei3A/Q4r8dD RkNGo3+f0rbGZ54wbhBhJom15UU0Af38VXozr32ZL4g1vRbi/1Mg76MsxRjqtdfp4E7ktSG3j9dL zAa5PjfLOIpxcAbGwygeO5BuqdgTqtZ5Hfco3ad1oXy5htzdXkvm9Sker4yhiMPrGOHryB/ScH0m 5YMc3dqnms7rL9rHYq/mNl531y6m5+T+Vih6K62PepnWe6qo0LNE7Det0R6ipfB7yH0nPWRkiP2V 6fa4ymNiO2t/vJbZu3VNU36z0yYQ+ZtJF/J6THi6djxPIcbSo2IdylrH7MS2wRh/O6iy9ivMb9pf 7zRfk+ue8+UYf23rmO9cp59JU7TFmPfZa7KPQR6kS/VlQJaxMy92WiiXEx3ZQrZtgvsZYq3P2u/h NahuYftwhaKcPxX1NZHrzBWDNhzL9W/u1K39uTz9eoRXqZd+BFhrj2J/jteGeQ2SUdejjV6FtgId 1FeLPbxbJAhrPibiXWHtmxklIAf5mod0tvLekQ3d2ob5kT6dbheIdTVzs9rd3An5S/VVsccYK/cC e+krUc+zxLq0vSeYpA8U69YD9WkA9Q9+BXe6+HYpRVkFEC8W8zr+Rl6bG0qEZx5tjFwjlWHdz1Kh OwB97UKFrnpK1xbCftmNvi4ZdTcJ9RpLS7UPKFU/j+Zo8VTFKIXmfuUwJCx1Rv0M/n+GvEf8HdEK 3hO299Ws9Wk6LtgHWwHIvVxmLqNuVfrKfcJyeZ9i3cNvFO0Q2O/YSo+FgXDmB+C4eh/SzqMqtQFp bERekI4Wh/bnAHFmSwbKdMbrM9DGTuYCJ4jLMtMJ/Fn2dyL9ezuBP8s8J/DPaycfHYXrKB8d+fud wN//E+Sjo/emOYF/2mnyV+QE/kVnkI+OyjndCfzTT5OPi53A/2JnPtA/YR7b8hLmpk9C/kmO959C XggJ7Wt5AfeYX5jzpPtPMtxvAea/5gMAc2UzT4I+z+Q58G2Q/wMwrzantNGyFzLZOodhp2OuBoNB qZUWx23ZZaUtkGm21FvxTzwl8xvmbukBPrHSE2lz39sImQbWyfDLZbohK+8tq9vC83P+RhEv1Iap gal47oUsaaPlGQtzD+R/AF4XfRm8Iu9TZXnwNz/L72rrF+g7sVfEezsYq91bicSY/Wu6UPS5B04a q6w96w9pi+jvTPR9YynLiIEd8jDlsd3Afbhrrgh/h6sKYxPBPikV+3nV+iFy6S9SL9fHVKlfRfna DtjF49HfIg2xL4N3c7/NNoe2gi4CYq9S7Anx3sn1dFv008J+iUOY7vrfkN8HqAlztuW8f8b9uXso 3HfjWzbR9a5f0w2eK6nJ+AJ5baZ5GK+8RiWNct1ME+y5rXElRbnOgl0gZReF5kQlw5/PJnxC+VG3 wa57g4pRZtl22q3l4Kbu8H/MWl9pQcm1oO6/zwAXijwjv7DDdMytu9vnBlw/Q5lUifxcLPacniAd c3RyHcHYPZEGuqNge2XS8qgk2mh8g+8wkFZG2HkB3qffSn73z2m46zby23N34yOU8zSKtiXvx9nr AbDdNunzhb2YIPa15HpAq7TfwfttQVrJZyWcdo1tR7XaFHKNoHXNwf4eSB4/W79fyjB7w1pT2A37 NJEyeB9PrIk4pcyT2MfbDV2S9qy7iSa5NcjHaJ6xjEpcF6FculGJew8luMdTEttnbrew667kMdp1 DLZoCfmh+xfI9n4d4LY0XrbxRfD/I3jSao/cvthftE34nVgn/S8HN4IF1nN+Zi6x7k8csd4vnt1o hT+BdmjyHpwatlbzvoWYh/jC7VR5lmrZKbJt7571p7BT+QPX0LgN85mqdvb4nXI15HzbDTvvfbTR exHXBwzbjnZK3TqfstiSwjZk+aiUv2NdY1vPKZ3nVzo6z3IaO9ZqZ7Y8+dyLLS+V0t96LqcTGX5O pk2apnR3/aFrd3LNrbct2zl/YK3JtUnjlPlTuBR1Qpq0Y9l+nyT2+flszmloPcN1M3TgZEoZPk/Q HgZGEsZ9xclIO79DjLsQD3i8Tsx/MMjzTRbmg5LDks2MpmAuDfR7nJj/ELR/vi7feBjpAs8QC/de C2H/nwaUAbnRgj0JQho8Fp4WWBmM+4jkDhvTZOxyt8vRLhd82yf47vmtebbTl+/9V+vxX62Xn+q7 T5f3cOQZPVvy2T2j3XyjfgT/sBBnabZSN4mBct0FasE+yWoGbaU3n1XS5kKf5orziq1xTtGDVZib MtItz98YBiw7d5LVDvjsjwWVt1c+7rmW/rkHWOUkzu1YttfH+I4YecZ2nuz70qOKaZM8J+vlvgXj LrfzYfrzNO9km88ssebT5maMky6Ej3ctokL1VfN3rhvQJ3xhvuJaAlsAIK1bJHslGy3bz9wmz0Ea 4jzwVnoiHMxtUxkOg/RqwKPS3mY79pcWLX+z/NvyZfe92rf4juPUS5wvDYj5dbG+AHP6BdRLO4zn sBd4v0m7jHJ5zNDOhW3FZ26ul+dlee3hPUiLGJRLsbYlrH3z+Ro+VwPEmRyup5cwBnD4l0R8e34/ UKwvVaMff4e84uwPnokzPXgHn3Viu0jDjMI1GXoxBWGnmH/Q1kJOkHwLrkJ+S2mBegsN0eZhPvwG 7J1E+P8CLMR9EmQsKAcPgWtpuPA/Dj35DuGBpsP9GqQLc3sX/I5JVlrwczHf3kFVsImr8D4rXLOI Y2FQlfJ7kVaVlof3IZyKmZIGi0JLlPcGnt+KeE3W/J3XFTi8eGaHiWoL4/qcCqPnUaHRDawwG125 ZqPyKY3VKygedRoDRqKu98v5A9tRBwBKy1wP9z7VeS7A3ieX0vUULXCdT0NcJ2AfvAs9OERjXd/Q g64cGmgUYxx7kliXxgCe283j88TiLHGzud9e+7Yxyigx6kUajzokPr9hS7WWf3kA3ztdjEfiLL3C 1lutZZGJ89NWWxN2rjuflqIdF4IJ8tz3PGt/DDYo2p5unVMdqD9KKZYdx3OoFpSWye2hBH1D69or Sz7TxrolbUFENZ9U3+R5rZnNexVqMZ/XEnEvsealJq9X3wd4zfKhsP2nNcz/9f6W6tiH6mi/qLOz GZ2d1TjFfYZ7Ks6zG52d5ejU7dhz6Wy/DLrKNnIhxpUmY6vZDPez4B70r48wOpmmWB+17LUVWhe0 7UWYg06kdLkmyuukqei/UvWVYk1/mfU+6oa+Kc9amze/l7/nINZTeW2O7VItSfweRG/5ew38/kly /Vb83kTrOu05NJ37Wu5TxZjBZ7sxT0N/U8V9i7qXRqjfW32Q0iwg7ovEumQe8pgnpLhXB8s+JY+i 1BH4ltUWWqy5V/RJXa0+SyO8r4H7M4y/Vn+VovW2+i/1LasPUt9DGJuvwGe8VyPm089ZY07LE2Js +s7qJ0VfyOuQuBe/j2LNn2K5DfLvwXRmL0nbstYhd9myM7tQxqmVcU4NL/duMJZ0E2PyyzSI1yZa 511EI8TZ6E/EfGUCnrMN0mbn2+vtop5QR9bevuKcF/B+DtetPae31s1a3gqTlRZinOZy/BvssmiM uxeKNNDHif2eGvMrmU+en/SCnt7ROvez53L2XINojL6eHtF+DltoGJ9JEuP9c2Hz20cY1jP5y02D 2+HN9lEw71a+tVBnAdgZGvpLrQLsOxUX3mV8hJ6/0aLLxZ1zFt7d9W4UH+LHw7KPP0iUgDl692Si xH5EPYwwEK4X3tuniih5LVHKegtfNFG/p4nSZhOlL7Pwv9DGQL1jBiO9sxF36HyYdEhz+NtQh6FE I/Gd5/6eKHsH0XkYY8dgDByL949DCwmUEeX1JrrgPYt8fPME5HliiKgI33QRZl9T8N6S74hKUYZl oyNEiBDh30hpB9T9m/ksQoQIESJEiBAhQoQIESJEiBAhQoQIESJEiBAhQoQIESJEiBAhQoQIESJE iBAhQoQIESJE+EEo/Beb6CiNpYfJTSrFUSb/X031+XoKuUjdSdO0gfX+JO8bz2mD6BBQtUF1GSne ndoALaVujDfQoKXVJyRmxeYO0Xx4W6a4+nBdCLaBJqBTpZYK/zhcl4Ag2AaawBvAEL8bxU99YCHY AA7xEy1FS67zeeNyB2i9ELcX8hir9aQjwAQaeXHNBJNBJbgLbACGCMc+C8ES0AS+EE8CWs+6e0cg 7z3r7hCi/vIrsoTzMss582fCWT+j3JIXTbFk/kQr2Ggr2PBzLO+heZYccLYlE/pnBVlGx2Ttzu2h 9cBH9kDGr8ZVUV+gWEUhL23UEikEVM2QPgEtoT7dn7WhSdNJ0VRNoSrymrs1pS4mPis3WjXVI5RA XvXv6ufWE/Xz+q7xWRtyJ6kf0DbQBDT1A/z8Vf0rLVEPcZnjmgM2gCZwABwBhnoIP+/j5z31PYpV /0KZIAdUgg2gCRwBbvUvuMap77K2iCvf5wBVfRfXOPUdfNY7uMaqb+PubfVtZO2/6rJHZe0UNxmZ 8sbbX9707CNvEnpkNahv1h0bBI3yo6ahUbu0fjSORmj96voP9zZoSXVjF3gb1A/rfRnejbnD1Lco BFTk5C2k/Bb5QDGYBa4GBu4O4u4gBcHdYCMIAWgZrnHAp+4Dr4GDNAwEQDHwqG/UIZkG9UCdP8+b 20Pdr75MPVHir6uvCPma+pKQr6ovCrkXMhVyn/pSXaqXcrvgOSFOHGQcZCaeu9Tn69MTvGZuvNqE svPimglywGRQCe4Chtqk9qur8ibgJbton4cQso4+FfIx2uyhwOXegP8CKKCPL/7R5+MOlw2+DX41 4F/zAJx88d95L+744r9lJe744r/hJtzxxX/Ftbjji7/qctzxxV9RiTu++CdPwx0uDer6Z9MHeLMn Vyu+3Fj1OpTSdSil61BK15GuXsc/dEznvD1YN3gwSmxdIGPQYG+wUQk+pwSnKsHNSnCuElysBG9S gmOV4KVKMEMJJivBVCUYUIK7lPNQFEEl8PRJzlGBJCW4Twk+pQRrlKBfCfZXgulK0KdkBxrUvnUT RwhRIER9Ljc6yPPHofeJVfuiRPtC5/uiT2jC9QAwhSuAQL5+VuBeqSz71Q/OsdxDR2ctzJ2g7kHE PaiGPfQ+0FFBe6BGe/CSPXhBLK45oBLsBkeACQyE7oeM3yWusbhmghxQCZaAI8AQ2TkCVFoos7hN ZCxTZnoyu9Q9+OmHn75q30BKXHJcRtwE7a5kJTZVmZxqpqrZ1KMHESXEe+IblJgd/4z59p8xFJUb pd6p3kUpqIi7pbyr7liKt0FZW+ff5c1NVH5LqTq0ThlFfqU/5HlUI9wjKdnD8hxKVmshs+qSSxEt ts5/trdR6cqxdniPJX/k/TS5QcXtfyfv8v7R16Ardd5m+NTu8L6VvMK7N7PBA5/n/A0KRKNPBN2Z fJ73qX0i6E14sK7Ou5jFDu9vksd7q5PFg7nWg0tr4ArEeqf6K7wT8L785NneQA3eucObk3ypd6wV aiTH2eEdhixkWLeDkdlBySLRtFTxwunZDcr8wNnuNe4y92T3ue4s99nuvm6vO8Xdx93dk+CJ83T1 nOWJ9ng8hkf3qB7ydG8wDwUy+C8YdjfEHzLkX1lWSBf3cSpfxf9/gf9StEelSRTqphWpRSV5SlFo 9xwqmu0LfVOS1qBET6kIudLylFBCERVNywudl1HU4DanhrIzikLu4kvKtivKneXwDanLGxSaVtag mOx1a59QwgVlO0lR4m9d1YflwFtXlZdTUo9rc5JyEsbFjyrMb+cyS17D/ux60kn3KaE1RSVloa0p 5aEsvjFTyotCq0t8M8t2KkeVLwrydypfsigv26mNU44WTGV/bVx+eXlRg1IqwpFP+RLhoDFfinAe DMwcjnyeVCvcOitcf8RHuHQWCBcVRf1FuP5RUSKcrnC47TXpBfnb09NFmJ4+qhFhanr6wsPs648w /fuLMD2CtE+E2dcjyGFC40SQ5GQESU0WQZTelCyCJCu9RZDStiCZMsiK1iArREqa0hYm2QoTc8gO E3MIYTJ+6L+5eRkZSv2Y8jkzC+amFcxKK5gLZoXuuHZ+Uig42+fbPqecH/hCmn/W7DnzWV42N1Se Njc/NCct37d9zMx2Hs/kx2PS8rfTzIJpZdtnBubm140JjClIuyy/vH588TnZJ6W1ojWtc4rbeVkx v+wcTmt8djuPs/nxeE4rm9PK5rTGB8aLtEjoeHHZdg/llV8w05L1apdo6OusPn3L83rEXT1OKO+Y vkmL+zTCWtlCXTLKQ2el5YViAD8akjsklx+hTfGjrvCOlY+SFo/p26dR2SIfxcE7Pi2PMhZdU3MN JRUsyLf+q8E/eC26hgvcumbUdPQPzwpCgcvyaxYRFYUGlxSFcqZUlG13u+E7iz8pNNr269KloMHc bXkOhedo9tS01oDsN5b9oqJkwFPr/xopxd+YDaq76pVAqrKIasq1UGrRNBVdwbQKfOvMirJG2FI8 PNSU4wNrlAylxn6HzLb1t85Z8DfbLLpG3smyWCSlFRNRauwiaf3HhZXRWmKL8EL6XyqcN0gKZW5k c3RyZWFtCmVuZG9iago5MgowCm9iago8PAovVHlwZQovRm9udAovU3VidHlwZQovQ0lERm9udFR5 cGUyCi9CYXNlRm9udAovTVVGVVpZK0FyaWFsCi9DSURTeXN0ZW1JbmZvCjw8Ci9SZWdpc3RyeQoo QWRvYmUpCi9PcmRlcmluZwooVUNTKQovU3VwcGxlbWVudAowCj4+Ci9Gb250RGVzY3JpcHRvcgo5 NAowClIKL0NJRFRvR0lETWFwCi9JZGVudGl0eQovRFcKMjIyCi9XClsKMApbCjc1MAowCjAKMjc3 CjAKMzU0Cl0KNgoxMAowCjExCjEyCjMzMwoxMwpbCjAKNTgzCjI3NwozMzMKMjc3CjI3NwpdCjE5 CjIyCjAKMjMKMjUKNTU2CjI2ClsKMAo1NTYKXQoyOAozNQowCjM2CjM3CjY2NgozOAozOQo3MjIK NDAKWwo2NjYKNjEwCjc3Nwo3MjIKMjc3CjAKMAo1NTYKODMzCjcyMgo3NzcKNjY2CjAKNzIyCjY2 Ngo2MTAKNzIyCjAKOTQzCjAKMAo2MTAKXQo2Mgo2NwowCjY4CjY5CjU1Ngo3MApbCjUwMAo1NTYK NTU2CjI3Nwo1NTYKNTU2CjIyMgoyMjIKNTAwCjIyMgo4MzMKXQo4MQo4Mwo1NTYKODQKWwowCjMz Mwo1MDAKMjc3CjU1Ngo1MDAKNzIyCl0KOTEKOTMKNTAwCjk0CjM3MwowCjM3NApbCjYwNApdCjM3 NQozNzkKMAozODAKWwo2MDQKXQozODEKNDAzCjAKNDA0ClsKNjA0Cl0KXQo+PgplbmRvYmoKOTQK MApvYmoKPDwKL1R5cGUKL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZQovTVVGVVpZK0FyaWFsCi9G bGFncwo0Ci9Gb250QkJveApbCi02NjQKLTMyNAoyMDAwCjEwMDUKXQovQXNjZW50CjcyOAovRGVz Y2VudAotMjEwCi9JdGFsaWNBbmdsZQowCi9DYXBIZWlnaHQKNzE2Ci9TdGVtVgo4MAovRm9udEZp bGUyCjk1CjAKUgo+PgplbmRvYmoKOTYKMApvYmoKMzEyCmVuZG9iago5NwowCm9iagoxOTE3MApl bmRvYmoKOTgKMApvYmoKMzYxCmVuZG9iago5OQowCm9iagoyNTYzMgplbmRvYmoKMQowCm9iago8 PAovVHlwZQovUGFnZXMKL0tpZHMKWwo2CjAKUgoxNAowClIKMTkKMApSCjI0CjAKUgoyOQowClIK MzQKMApSCjM5CjAKUgo0NAowClIKNDkKMApSCjU1CjAKUgo2MAowClIKNjUKMApSCjcwCjAKUgo3 NQowClIKODAKMApSCl0KL0NvdW50CjE1Cj4+CmVuZG9iagp4cmVmCjAgMTAwCjAwMDAwMDAwMDIg NjU1MzUgZiAKMDAwMDEyNDgyMSAwMDAwMCBuIAowMDAwMDAwMDAzIDAwMDAwIGYgCjAwMDAwMDAw MDAgMDAwMDAgZiAKMDAwMDAwMDAxNiAwMDAwMCBuIAowMDAwMDAwMTYwIDAwMDAwIG4gCjAwMDAw MDAyMDcgMDAwMDAgbiAKMDAwMDAwMDM3MyAwMDAwMCBuIAowMDAwMDc0NDQxIDAwMDAwIG4gCjAw MDAwMDA3MzUgMDAwMDAgbiAKMDAwMDAwMDc1NCAwMDAwMCBuIAowMDAwMDA5ODg5IDAwMDAwIG4g CjAwMDAwNzcyNDUgMDAwMDAgbiAKMDAwMDA3NzM5MiAwMDAwMCBuIAowMDAwMDAwNzc0IDAwMDAw IG4gCjAwMDAwMDA5NDMgMDAwMDAgbiAKMDAwMDA3NDYyNyAwMDAwMCBuIAowMDAwMDAxMjA5IDAw MDAwIG4gCjAwMDAwMDEyMjkgMDAwMDAgbiAKMDAwMDAwMTI0OSAwMDAwMCBuIAowMDAwMDAxNDE4 IDAwMDAwIG4gCjAwMDAwNzQ4MTQgMDAwMDAgbiAKMDAwMDAwMTg5OCAwMDAwMCBuIAowMDAwMDAx OTE4IDAwMDAwIG4gCjAwMDAwMDE5MzggMDAwMDAgbiAKMDAwMDAwMjEwNyAwMDAwMCBuIAowMDAw MDc1MDAxIDAwMDAwIG4gCjAwMDAwMDI2ODAgMDAwMDAgbiAKMDAwMDAwMjcwMCAwMDAwMCBuIAow MDAwMDAyNzIwIDAwMDAwIG4gCjAwMDAwMDI4ODkgMDAwMDAgbiAKMDAwMDA3NTE4OCAwMDAwMCBu IAowMDAwMDAzNDIzIDAwMDAwIG4gCjAwMDAwMDM0NDMgMDAwMDAgbiAKMDAwMDAwMzQ2MyAwMDAw MCBuIAowMDAwMDAzNjMyIDAwMDAwIG4gCjAwMDAwNzUzNzUgMDAwMDAgbiAKMDAwMDAwMzkwNSAw MDAwMCBuIAowMDAwMDAzOTI1IDAwMDAwIG4gCjAwMDAwMDM5NDUgMDAwMDAgbiAKMDAwMDAwNDEx NCAwMDAwMCBuIAowMDAwMDc1NTYyIDAwMDAwIG4gCjAwMDAwMDQ2ODUgMDAwMDAgbiAKMDAwMDAw NDcwNSAwMDAwMCBuIAowMDAwMDA0NzI1IDAwMDAwIG4gCjAwMDAwMDQ4OTQgMDAwMDAgbiAKMDAw MDA3NTc0OSAwMDAwMCBuIAowMDAwMDA1MTY3IDAwMDAwIG4gCjAwMDAwMDUxODcgMDAwMDAgbiAK MDAwMDAwNTIwNyAwMDAwMCBuIAowMDAwMDA1Mzc2IDAwMDAwIG4gCjAwMDAwNzU5MzYgMDAwMDAg biAKMDAwMDAwNTU5OSAwMDAwMCBuIAowMDAwMDA1NjE5IDAwMDAwIG4gCjAwMDAwMDk5MjcgMDAw MDAgbiAKMDAwMDAwNTYzOSAwMDAwMCBuIAowMDAwMDA1ODA4IDAwMDAwIG4gCjAwMDAwNzYxMjMg MDAwMDAgbiAKMDAwMDAwNjUwNCAwMDAwMCBuIAowMDAwMDA2NTI0IDAwMDAwIG4gCjAwMDAwMDY1 NDQgMDAwMDAgbiAKMDAwMDAwNjcxMyAwMDAwMCBuIAowMDAwMDc2MzEwIDAwMDAwIG4gCjAwMDAw MDczNDggMDAwMDAgbiAKMDAwMDAwNzM2OCAwMDAwMCBuIAowMDAwMDA3Mzg4IDAwMDAwIG4gCjAw MDAwMDc1NTcgMDAwMDAgbiAKMDAwMDA3NjQ5NyAwMDAwMCBuIAowMDAwMDA4MTM0IDAwMDAwIG4g CjAwMDAwMDgxNTQgMDAwMDAgbiAKMDAwMDAwODE3NCAwMDAwMCBuIAowMDAwMDA4MzQzIDAwMDAw IG4gCjAwMDAwNzY2ODQgMDAwMDAgbiAKMDAwMDAwODYxOSAwMDAwMCBuIAowMDAwMDA4NjM5IDAw MDAwIG4gCjAwMDAwMDg2NTkgMDAwMDAgbiAKMDAwMDAwODgyOCAwMDAwMCBuIAowMDAwMDc2ODcx IDAwMDAwIG4gCjAwMDAwMDkzNTUgMDAwMDAgbiAKMDAwMDAwOTM3NSAwMDAwMCBuIAowMDAwMDA5 Mzk1IDAwMDAwIG4gCjAwMDAwMDk1NjQgMDAwMDAgbiAKMDAwMDA3NzA1OCAwMDAwMCBuIAowMDAw MDA5ODQ5IDAwMDAwIG4gCjAwMDAwMDk4NjkgMDAwMDAgbiAKMDAwMDA2Mzg0OCAwMDAwMCBuIAow MDAwMDc0Mzk3IDAwMDAwIG4gCjAwMDAwNzQ0MTkgMDAwMDAgbiAKMDAwMDA5NzE2OCAwMDAwMCBu IAowMDAwMDc3NTM0IDAwMDAwIG4gCjAwMDAwOTc1ODcgMDAwMDAgbiAKMDAwMDA3NzkyMiAwMDAw MCBuIAowMDAwMTIzOTMyIDAwMDAwIG4gCjAwMDAwOTc3ODcgMDAwMDAgbiAKMDAwMDEyNDU0MiAw MDAwMCBuIAowMDAwMDk4MjI0IDAwMDAwIG4gCjAwMDAxMjQ3MzcgMDAwMDAgbiAKMDAwMDEyNDc1 NyAwMDAwMCBuIAowMDAwMTI0Nzc5IDAwMDAwIG4gCjAwMDAxMjQ3OTkgMDAwMDAgbiAKdHJhaWxl cgo8PAovU2l6ZQoxMDAKL1Jvb3QKNAowClIKL0luZm8KNQowClIKPj4Kc3RhcnR4cmVmCjEyNDk3 OQolJUVPRgo= --f46d0446325c16cda404ccf1c9d8-- From lorenzo@google.com Fri Oct 26 01:09:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3521F843A for ; Fri, 26 Oct 2012 01:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6de+PhPM9fO for ; Fri, 26 Oct 2012 01:09:38 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 06CB221F8437 for ; Fri, 26 Oct 2012 01:09:37 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2713331oag.31 for ; Fri, 26 Oct 2012 01:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=702/0/wchbSP8touqghWtAianE3T0Hg6Le3BJlHl5fo=; b=elVeeo4TkIQAKxf0Yja+yAhliBm0pUIxgOiEOc29e2KfxTeFNcB5PpMuHkPGvSLaeM PmgXiJsrpEsY1t27Bgv+zsocT1NSy0LJov6BL1iNUX90UoqMQWtde4E46pWTGgzYH5tK JDKsj5NGpDfLakW7n9pP6DnL4bzjqUL4tkCn4gGz3hJ274XRMjQOrkqEQ3GnN4552Hyb XW0yeRaqxaGkxYXYTlsJix5wQwT+t35svCuN6Rx03JHTxu5sRtb4GtQEUPOLVyRw654/ qnQivMAXE/BPWlrSmvI7PixWOhAdhsiACfiIxOjO1z9Nxze2Kf5dHMO3D8VwBiWoI5Ua n9cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=702/0/wchbSP8touqghWtAianE3T0Hg6Le3BJlHl5fo=; b=O7AHt3GS5+tLzjsay0slgKcOXyFSjDpI27tSsRO1GAOdnBcIfvZVFPXoxpDiuy3DDL /KF3aysOtUxrUusjmYy6DGi7uN1vOMgl1ODW3Yd7UuqZYegnnfsh1Z8HyhlaNWGF+oK8 YVCtSDi4ARPkcmh1y/jHbzdSU1mmsG7R4RnEWdysHdVNB+PsCK4a/eJOLkK7suM3Su6U bMKtPDC/fHoT0Q/OAk6D1UqHwYGTpEL2WAl8J6St6RgdEX2SEnJaeAgEncUxXRHNZLdJ J8O8YYAk1oG8xey3JBD/XInFGjU8SErIGXI/N9QB/qFZ6z6Tn5mjNNVRHhHqxhfQrNeM 0nfw== Received: by 10.60.14.165 with SMTP id q5mr19449259oec.28.1351238977630; Fri, 26 Oct 2012 01:09:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Fri, 26 Oct 2012 01:09:17 -0700 (PDT) In-Reply-To: References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> <8DB04CA5-3A1A-49B3-9E58-4C588CB797B1@inf-net.nl> <788C7E82-54FB-43FB-AF3A-3E0739D8BE41@inf-net.nl> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 17:09:17 +0900 Message-ID: To: Teco Boot Content-Type: multipart/alternative; boundary=e89a8fb1f46844b04304ccf1d759 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn1FxjQCi68tTDAikJOXffAabsCWZMoHQZ4wjicNPDan0n2+dCNk10Joo2AxekH70PG1tTjlym1XgUuH+5xIozYrHab76sDzyYhaI0M8MVOyTive1FGTZarS+DnlHZLWM90iowfFxBPbQZb/0kHw40Zv18C36Epk8SLUPh7NjVXTCvLJyfmQhrWYsK4ba2Vs9gS3El8 Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:09:38 -0000 --e89a8fb1f46844b04304ccf1d759 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 5:05 PM, Lorenzo Colitti wrote: > Using a routing protocol and not using DHCPv6 solves this issue, because a > router is allowed to deprecate a prefix that has gone away even if it was > originally announced by someone else, and NUD will let hosts work around > broken routers in a reasonable amount of time. > Forgot to mention: the presentation I attached (which was given at the homenet meeting in October 2011) tries to do that with RAs and routing protocol only. In many ways it's similar to BRDP. I was going to remove the attachment because I realized that it's already archived - http://www.ietf.org/mail-archive/web/homenet/current/msg00385.html - but I forgot. --e89a8fb1f46844b04304ccf1d759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 26, 2012 at 5:05 PM, Lorenzo Colitti <lorenzo@google.com&= gt; wrote:
Using a routing protocol and not using DHCPv6 solves this= issue, because a router is allowed to deprecate a prefix that has gone awa= y even if it was originally announced by someone else, and NUD will let hos= ts work around broken routers in a reasonable amount of time.

Forgot to mention: the presentation I attached = (which was given at the homenet meeting in October 2011) tries to do that w= ith RAs and routing protocol only. In many ways it's similar to BRDP.

I was going to remove the attachment because I realized= that it's already archived - http://www.ietf.org/mail-archive/web/= homenet/current/msg00385.html - but I forgot.
--e89a8fb1f46844b04304ccf1d759-- From sander@steffann.nl Fri Oct 26 01:18:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8532C21F84DF for ; Fri, 26 Oct 2012 01:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.407 X-Spam-Level: X-Spam-Status: No, score=0.407 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_AT=0.745, MIME_QP_LONG_LINE=1.396, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byYYzoViI7uM for ; Fri, 26 Oct 2012 01:18:08 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 76AAA21F84DE for ; Fri, 26 Oct 2012 01:18:08 -0700 (PDT) Received: from [192.168.1.56] (p83-219-163-40.snwdip.snw.at [83.219.163.40]) by mail.sintact.nl (Postfix) with ESMTP id 556DE2002; Fri, 26 Oct 2012 10:18:06 +0200 (CEST) References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <13C65695-2D64-4987-B744-17C2A6F685A9@steffann.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0F610ED8-74DF-47DC-8D5D-762EE5C7F953@steffann.nl> X-Mailer: iPhone Mail (10A403) From: Sander Steffann Date: Fri, 26 Oct 2012 10:18:06 +0200 To: Lorenzo Colitti Cc: "homenet@ietf.org" , RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:18:09 -0000 > No more than a DHCPv6 server saying "please use this DNS server for everyt= hing". Right? Right.= From teco@inf-net.nl Fri Oct 26 01:43:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C5221F84FA for ; Fri, 26 Oct 2012 01:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNczevNjNPwZ for ; Fri, 26 Oct 2012 01:43:14 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 443A421F84F6 for ; Fri, 26 Oct 2012 01:43:13 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so871938eaa.31 for ; Fri, 26 Oct 2012 01:43:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=02xXFHA01OrDdpZwFDCL57fep6Zfipt2+p6uQRi9NYI=; b=DhRZSrA28S56CL0x2p62DN4TYP8uzcm27vn0HJrKKyPzQc7ev4H9EbhvrSkqqit/qa rFMDswlPnmWMUX4roSdxMmf6AO2qf/BguWfx9W2R/A3YUrDUZfLW9N6ND4jvyB/7o8Cm 3P+Cra+ohUs27Fi2UwEgr/sZCxmhMm6NfxKGZ8CSNP+HyUMYZ/sRTzD7azlLsO0V+ocE SZL82awja+GvZzdxF8mzbzspITxsoZnSZJNUmV1m09Qj8sGEiWQEUG9oDBAMmqk6BX02 Ufsci26csN99ZY2HATEWJM15oYmLqUSkH7+TSKd+xlZxsW53XGMD+GDbooTZuy4TR36p BNIQ== Received: by 10.14.172.195 with SMTP id t43mr30479562eel.17.1351240993231; Fri, 26 Oct 2012 01:43:13 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id e7sm1349218eep.1.2012.10.26.01.43.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 01:43:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FE67667C-839F-4A1A-8561-3E3A86235608" From: Teco Boot In-Reply-To: Date: Fri, 26 Oct 2012 10:43:11 +0200 Message-Id: <53471F69-3004-4BB8-A9CE-0521604C0B29@inf-net.nl> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <93FD58D8-C1E3-49AD-81D1-FFCFDDD7D861@inf-net.nl> <8DB04CA5-3A1A-49B3-9E58-4C588CB797B1@inf-net.nl> <788C7E82-54FB-43FB-AF3A-3E0739D8BE41@inf-net.nl> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlcf0cfs7Cs2dinBYG3XECc8WA+K9jrcDCyM/IGsiVOPeT4YL67mgsK2KH3S4QRB8JE/aqJ Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:43:15 -0000 --Apple-Mail=_FE67667C-839F-4A1A-8561-3E3A86235608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Op 26 okt. 2012, om 10:05 heeft Lorenzo Colitti het volgende geschreven: > On Fri, Oct 26, 2012 at 4:50 PM, Teco Boot wrote: > The question is, does DHCP support the following: The MIF node has = configured a bench of addresses with SLAAC. Now it learns that there is = a DHCP server somewhere that has important info for the provision domain = for one of the addresses. Can the node get this info, with the already = configured address for that provisioning domain, with a unicast? Nodes = will be updated anyway for MIF, so let's go for it. Far better than = merging info from multiple provisioning domains into a single DHCP = server. Not? >=20 > Can we get by without a DHCPv6 server at all? In the Homenet BRDP draft, I removed the BRIO suboptions and emphasized = DHCP. So yes, it can be done, with ND RA options. I'm afraid it is hard to get = it right for existing hosts. >=20 > DHCPv6 servers are stateful and DHCPv6 is a protocol based on promises = that are valid for a predetermined amount of time. In a homenet, DHCPv6 = servers (i.e., CPE routers) may be plugged in and unplugged any time, = and there is no way to invalidate their information, which means the = hosts are stuck. BRDP provides mapping between routers and prefixes. When border router = is not reachable anymore, or prefix gets invalid, routers should inform = hosts with ND PIO. This will work with existing hosts. DHCP info is not = invalidated, it just isn't used anymore. >=20 > Using a routing protocol and not using DHCPv6 solves this issue, = because a router is allowed to deprecate a prefix that has gone away = even if it was originally announced by someone else, and NUD will let = hosts work around broken routers in a reasonable amount of time. > A difference in BRDP and the strawman proposal is default gw route vs. = walled garden more specific. I suggest handling both equivalent. In a = way that is a tiny tweak in forwarding heuristic. Open for discussion. = Many other BRDP functions are exactly as the proposal. I missed the meeting where this was presented. Bad luck. (BTW: BRDP is from far before Homenet, it was parked for a while...) Teco =20= --Apple-Mail=_FE67667C-839F-4A1A-8561-3E3A86235608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, = Oct 26, 2012 at 4:50 PM, Teco Boot <teco@inf-net.nl> wrote:
The question is, does DHCP = support the following: The MIF node has configured a bench of addresses = with SLAAC. Now it learns that there is a DHCP server somewhere that has = important info for the provision domain for one of the addresses. Can = the node get this info, with the already configured address for that = provisioning domain, with a unicast? Nodes will be updated anyway for = MIF, so let's go for it. Far better than merging info from multiple = provisioning domains into a single DHCP server. Not?

Can we get by without a DHCPv6 = server at all?
In the Homenet BRDP draft, I = removed the BRIO suboptions and emphasized DHCP.
So yes, it = can be done, with ND RA options. I'm afraid it is hard to get it right = for existing hosts.


DHCPv6 servers are stateful = and DHCPv6 is a protocol based on promises that are valid for a = predetermined amount of time. In a homenet, DHCPv6 servers (i.e., CPE = routers) may be plugged in and unplugged any time, and there is no way = to invalidate their information, which means the hosts are = stuck.
BRDP provides mapping between = routers and prefixes. When border router is not reachable anymore, or = prefix gets invalid, routers should inform hosts with ND PIO. This will = work with existing hosts. DHCP info is not invalidated, it = just isn't used anymore.


Using a routing protocol and not using DHCPv6 solves = this issue, because a router is allowed to deprecate a prefix that has = gone away even if it was originally announced by someone else, and NUD = will let hosts work around broken routers in a reasonable amount of = time.
<Homenetstrawman.pdf>
A = difference in BRDP and the strawman proposal is default gw route = vs. walled garden more specific. I suggest handling both equivalent. In = a way that is a tiny tweak in forwarding heuristic. Open for = discussion. Many other BRDP functions are exactly as the = proposal.

I missed the meeting where this was = presented. Bad luck.

(BTW: BRDP is from far = before Homenet, it was parked for a = while...)

Teco  
= --Apple-Mail=_FE67667C-839F-4A1A-8561-3E3A86235608-- From gettysjim@gmail.com Fri Oct 26 03:47:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019F121F8530 for ; Fri, 26 Oct 2012 03:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCIPGw61eoSa for ; Fri, 26 Oct 2012 03:47:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9301821F84E7 for ; Fri, 26 Oct 2012 03:47:09 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3085571vcb.31 for ; Fri, 26 Oct 2012 03:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=OXGLRVGPrYzDGX60dpSYTp944pQbBIwv04a5J0Hiskw=; b=DorEPrDb0s+0U0/cQ0qMpjq1CB46Xt9KyVGSHNNixfm0+32e7/T1NubStRthU0k1NV 4EOtt15coOHV4JbEs4rRv07FtwWAPGBltAshD/gfjxvt/vRjNFhyaJRUBm6cwmOs/e9q mILpvxycpZmLr+IVPBML9ygSde5MDdREBjluQSnMNRLHvf2ZfSJ9p3x4eEVUz3wFSe9j UvyLL87HXdEQnNRS+uKXOUCLT5oAphsBO8X1b/mOhZs3r0nF1OQ6PdruHxr+xocq8zp9 hJjLNvjAXQLK0tfTTOxlqcfYle+s4nZCl48KLQpPAy0ed9kUHmVmGpo2n2iybMusxLtq eL0A== MIME-Version: 1.0 Received: by 10.52.30.39 with SMTP id p7mr30957511vdh.16.1351248429000; Fri, 26 Oct 2012 03:47:09 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.58.151.202 with HTTP; Fri, 26 Oct 2012 03:47:08 -0700 (PDT) Date: Fri, 26 Oct 2012 06:47:08 -0400 X-Google-Sender-Auth: QO3Cg3yxIGQQYWwJxJKbwPWmR6c Message-ID: From: Jim Gettys To: RJ Atkinson Content-Type: multipart/alternative; boundary=20cf3079beba9d278e04ccf40a80 Cc: Juliusz Chroboczek , homenet@ietf.org, Dave Taht Subject: [homenet] Look at ahcp: Was: Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 10:47:11 -0000 --20cf3079beba9d278e04ccf40a80 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 12:08 PM, RJ Atkinson wrote: > > On Thu, 25 Oct 2012 09:11:18 +0900, Lorenzo Colitti wrote, in part: > > ...from the border router which discovered the DNS entries > > for tvservice.jp, inject those DNS servers into the mesh > > with a tag that they only be used for tvservice.jp, > > and pass that around in the routing protocol. No? > > I'm not comfortable with overloading a routing > protocol for use as a DNS transport mechanism. > > I'm also nervous about both DNS authorisation > and DNS authentication. Who is allowed to make > which DNS advertisements and how do I authenticate > the received DNS advertisement as both valid and > authorised ? > > (NB: With ordinary DNS, the answer is DNSsec. > With mDNS, DNSsec also probably can work.) > > Surely there is some alternative approach that > doesn't require such overloading and complexity. > > > May I suggest the group look at using ahcp for this (and other) uses? It is also suitable for prefix delegation distribution, ntp distribution as well as DNS. In short, it solves pretty cleanly a number of problems this group has been struggling with. http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ Juliusz has recently added authentication to ahcp; probably not yet reflected in the document, looking at the date on it. It also avoids use of multicast, which is problematic on some networks we'll be seeing in the home. It's also running code (we use it in CeroWrt). Regards, - Jim --20cf3079beba9d278e04ccf40a80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2012 at 12:08 PM, RJ Atk= inson <rja.lists@gmail.com> wrote:

On Thu, 25 Oct 2012 09:11:18 +0900, Lorenzo Colitti wrote, in part:
> ...from the border router which discovered the DNS entries
> for tvservice.jp= , inject those DNS servers into the mesh
> with a tag that they only be used for tvservice.jp,
> and pass that around in the routing protocol. No?

I'm not comfortable with overloading a routing
protocol for use as a DNS transport mechanism.

I'm also nervous about both DNS authorisation
and DNS authentication. =A0Who is allowed to make
which DNS advertisements and how do I authenticate
the received DNS advertisement as both valid and
authorised ?

=A0 (NB: With ordinary DNS, the answer is DNSsec.
=A0 =A0With mDNS, DNSsec also probably can work.)

Surely there is some alternative approach that
doesn't require such overloading and complexity.



May I suggest the group look at us= ing ahcp for this (and other) uses?

It is also sui= table for prefix delegation distribution, ntp distribution as well as DNS. = =A0In short, it solves pretty cleanly a number of problems this group has b= een struggling with.

http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/<= /div>

Juliusz has recently added authentication to ahcp;= probably not yet reflected in the document, looking at the date on it. =A0= It also avoids use of multicast, which is problematic on some networks we&#= 39;ll be seeing in the home.

It's also running code (we use it in CeroWrt).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim


--20cf3079beba9d278e04ccf40a80-- From acee.lindem@ericsson.com Fri Oct 26 04:54:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C17A21F8453 for ; Fri, 26 Oct 2012 04:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 M3bSeQsrCnu7 for ; Fri, 26 Oct 2012 04:54:35 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37D21F8501 for ; Fri, 26 Oct 2012 04:54:35 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q9QBsVZR011581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 06:54:32 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 26 Oct 2012 07:54:31 -0400 From: Acee Lindem To: Jim Gettys Date: Fri, 26 Oct 2012 07:54:26 -0400 Thread-Topic: [homenet] Look at ahcp: Was: Mixing DNS in with routing information Thread-Index: Ac2zcKiAffdtDlShQxOdAMCKFJQEpw== Message-ID: <8D5DC78C-E3C3-4509-B61A-0FD55138B0C8@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-14--716888046"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Juliusz Chroboczek , RJ Atkinson , "homenet@ietf.org" , Dave Taht Subject: Re: [homenet] Look at ahcp: Was: Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 11:54:36 -0000 --Apple-Mail-14--716888046 Content-Type: multipart/alternative; boundary=Apple-Mail-13--716888185 --Apple-Mail-13--716888185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 26, 2012, at 6:47 AM, Jim Gettys wrote: >=20 >=20 > On Thu, Oct 25, 2012 at 12:08 PM, RJ Atkinson = wrote: >=20 > On Thu, 25 Oct 2012 09:11:18 +0900, Lorenzo Colitti wrote, in part: > > ...from the border router which discovered the DNS entries > > for tvservice.jp, inject those DNS servers into the mesh > > with a tag that they only be used for tvservice.jp, > > and pass that around in the routing protocol. No? >=20 > I'm not comfortable with overloading a routing > protocol for use as a DNS transport mechanism. Advertising the DNS servers and supporting DNS are two very different = functions. The mechanisms to do the former are DHCPv6 and Neighbor = Discovery RA (there may be others). It wouldn't be too much of a stretch = to use a routing protocol to distribute this information amongst routers = in the homenet routing domain so that it could be distributed to the = hosts via ND or DHCPv6.=20 Thanks, Acee=20 >=20 > I'm also nervous about both DNS authorisation > and DNS authentication. Who is allowed to make > which DNS advertisements and how do I authenticate > the received DNS advertisement as both valid and > authorised ? >=20 > (NB: With ordinary DNS, the answer is DNSsec. > With mDNS, DNSsec also probably can work.) >=20 > Surely there is some alternative approach that > doesn't require such overloading and complexity. >=20 >=20 >=20 > May I suggest the group look at using ahcp for this (and other) uses? >=20 > It is also suitable for prefix delegation distribution, ntp = distribution as well as DNS. In short, it solves pretty cleanly a = number of problems this group has been struggling with. >=20 > http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ >=20 > Juliusz has recently added authentication to ahcp; probably not yet = reflected in the document, looking at the date on it. It also avoids = use of multicast, which is problematic on some networks we'll be seeing = in the home. >=20 > It's also running code (we use it in CeroWrt). > Regards, > - Jim >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-13--716888185 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 26, 2012, at 6:47 AM, Jim Gettys wrote:



On Thu, Oct 25, 2012 at 12:08 PM, RJ Atkinson <rja.lists@gmail.com> wrote:

On Thu, 25 Oct 2012 09:11:18 +0900, Lorenzo Colitti wrote, in part:
> ...from the border router which discovered the DNS entries
> for tvservice.jp, inject those DNS servers into the mesh
> with a tag that they only be used for tvservice.jp,
> and pass that around in the routing protocol. No?

I'm not comfortable with overloading a routing
protocol for use as a DNS transport mechanism.

Advertising the DNS servers and supporting DNS are two very different functions. The mechanisms to do the former are DHCPv6 and Neighbor Discovery RA (there may be others). It wouldn't be too much of a stretch to use a routing protocol to distribute this information amongst routers in the homenet routing domain so that it could be distributed to the hosts via ND or DHCPv6. 

Thanks,
Acee 



I'm also nervous about both DNS authorisation
and DNS authentication.  Who is allowed to make
which DNS advertisements and how do I authenticate
the received DNS advertisement as both valid and
authorised ?

  (NB: With ordinary DNS, the answer is DNSsec.
   With mDNS, DNSsec also probably can work.)

Surely there is some alternative approach that
doesn't require such overloading and complexity.



May I suggest the group look at using ahcp for this (and other) uses?

It is also suitable for prefix delegation distribution, ntp distribution as well as DNS.  In short, it solves pretty cleanly a number of problems this group has been struggling with.


Juliusz has recently added authentication to ahcp; probably not yet reflected in the document, looking at the date on it.  It also avoids use of multicast, which is problematic on some networks we'll be seeing in the home.

It's also running code (we use it in CeroWrt).
                         Regards,
                                 - Jim


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

--Apple-Mail-13--716888185-- --Apple-Mail-14--716888046 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyNjExNTQyN1owIwYJKoZI hvcNAQkEMRYEFMQTVl9sTMpGLUlvmaWHdkjQZXpdMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFo0zMYwGpdjA+CUS/jC8IqowkKKEvQA5MkZODnV35o5K0pX3GScK/9bk7doQq/c y7ajwao8qcrJBWwJzoQkcue2NumzFzcCWq++3AR/6E2BJmoFiqgH8RMERF7auRXmGzA8mDDOGyTj VgVwX2niYvmJNa5WV5VHpicc+1o6dBc/AAAAAAAA --Apple-Mail-14--716888046-- From rja.lists@gmail.com Fri Oct 26 08:59:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8010421F85F5 for ; Fri, 26 Oct 2012 08:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 xqZN4fZ0A1Fm for ; Fri, 26 Oct 2012 08:59:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC921F8456 for ; Fri, 26 Oct 2012 08:59:55 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3435576vcb.31 for ; Fri, 26 Oct 2012 08:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=9pE7+q0CUgN04DJLqFEzQC+SCpBC9XJqelcrhQN8VPc=; b=f9fn6Cc4gqnCLQx8YRv38SDVEt1muGXGHCa3wBEisH8s00YtMErw4yLZPDrK8cvI4A WMrBuFn6gDj+hK1F+T5YRSBTo2qVJQmOjecQjWSGYQliRbp7W+f/wyuErWFv2tGHTlVb xA0MnzJ1R0BQmuN5V5Jc59P8oaEkljYi4mBLMnFjLbv7nq4xhOfiP80AMEtCGBu4FsuP 1zTepZdpeclJ3roJfq55uYt9D9OYFuZInq6lJj39IfSuqBCnOu9pxCJPDfC+gTZhkh0T JyOycbMoFWdwWgQYbXZtojuojyvvS678OMzTFb1FEWDbuKmxekvOvv2coWmNcWEaaT0x i+yQ== Received: by 10.220.153.15 with SMTP id i15mr37353789vcw.6.1351267195359; Fri, 26 Oct 2012 08:59:55 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id o17sm1004061vdf.7.2012.10.26.08.59.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 08:59:54 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: Date: Fri, 26 Oct 2012 11:59:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 15:59:56 -0000 On 25 Oct 2012, at 20:33 , Lorenzo Colitti wrote: >> I'm also nervous about both DNS authorisation >> and DNS authentication. Who is allowed to make >> which DNS advertisements and how do I authenticate >> the received DNS advertisement as both valid and >> authorised ? >> > > I don't see a difference. There is no authorisation or > authentication today. When you get a DNS server via DHCP, > you believe it, or choose not to believe it, > based on no information at all. 1) DHCP Authentication is standardised. [RFC 3118] Multiple implementations of DHCP Authentication exist. So this can be deployed/used in environments where DHCP Authentication is deemed sensible. 2) DNS Security is standardised. [RFC 4033 et alia]. Multiple implementations of DNSsec exist. Deployment of DNSsec is growing much faster than initially expected. So this can be deployed/used in environments where DNS Authentication is deemed sensible. 3) It appears that DNSsec still can be used with mDNS. So again, this can be deployed/used in environments where DNS authentication is deemed sensible. So, a proposal with no capability to authenticate information, or address authorisation issues, seems very much like a non-starter. At the very least, authentication needs to be specified/available, and the authorisation issues need to be addressed. > If there's a rogue DHCP server on the link that hands you > a rogue DNS server, then guess what, you lose. This is not true if DHCP Authentication has been deployed. Instead, the quote above is a very good supporting justification for comments that we need to specify mechanisms both that can provide authentication and do address authorisation issues. (From a different, purely practical, perspective) I would guess that any proposal with less security capability than we have today (i.e. with DHCP Authentication, DNSsec) would be rejected by the IETF Security Area when they perform their Area Review (which is usual prior to IESG approval of any IETF track document). Yours, Ran From ajs@anvilwalrusden.com Fri Oct 26 09:10:22 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C1D21F861A for ; Fri, 26 Oct 2012 09:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDVdU5efoSWN for ; Fri, 26 Oct 2012 09:10:21 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BD4DB21F8644 for ; Fri, 26 Oct 2012 09:10:21 -0700 (PDT) Received: from mx1.yitter.info (dhcp-222-230.meetings.nanog.org [199.187.222.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 499BE8A031 for ; Fri, 26 Oct 2012 16:10:19 +0000 (UTC) Date: Fri, 26 Oct 2012 12:09:48 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20121026160947.GE56484@mx1.yitter.info> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:10:22 -0000 On Fri, Oct 26, 2012 at 11:59:52AM -0400, RJ Atkinson wrote: > > 3) It appears that DNSsec still can be used with mDNS. > So again, this can be deployed/used in environments > where DNS authentication is deemed sensible. Let us be perfectly clear on this: mDNS is a completely different protocol, on a different port. Moreover, DNSSEC cannot be used for validation with mDNS because the actual mDNS name is [some string].local., and local. is not signed (and if it were, everything would fail validation, unless you install a special trust anchor). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From stephen.farrell@cs.tcd.ie Fri Oct 26 09:25:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC621F8559 for ; Fri, 26 Oct 2012 09:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 t05q+Ek+8YgK for ; Fri, 26 Oct 2012 09:25:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 51EDE21F852A for ; Fri, 26 Oct 2012 09:25:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2C010C79A; Fri, 26 Oct 2012 17:24:41 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeCTk3jphRwM; Fri, 26 Oct 2012 17:24:40 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.191.229]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4B8EC790; Fri, 26 Oct 2012 17:24:40 +0100 (IST) Message-ID: <508AB948.305@cs.tcd.ie> Date: Fri, 26 Oct 2012 17:24:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> In-Reply-To: <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:25:04 -0000 Not trying to get into the argument here, but just one point: On 10/26/2012 04:59 PM, RJ Atkinson wrote: > This is not true if DHCP Authentication has been deployed. My understanding is that 3118 is fictional, i.e. is never deployed, ever. As an AD, I generally push back on any draft where the security considerations say "use 3118 and you'll be fine." If I'm wrong, I'd be interested in knowing that and about when/where 3118 is being used. Ta, S. From rja.lists@gmail.com Fri Oct 26 09:46:33 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5B421F8644 for ; Fri, 26 Oct 2012 09:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 6vAtYFrFVRgu for ; Fri, 26 Oct 2012 09:46:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 375C421F85B8 for ; Fri, 26 Oct 2012 09:46:33 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3567625vbb.31 for ; Fri, 26 Oct 2012 09:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+mjC9YGDZE59gktWnWYksB+HuvMDFJCudmekCcc03dQ=; b=sFer7KJQRkGZqmdMbOZNZKbGFOF9gGy6j2qIOyfHsWoljBruEbmRCArhui3mSiQEtx ejOL/V58mJzzG3yyMkaSzCEPOeiHxPkT1OuaMjGopUWzUPAiV5xOFRQtug4wUzEYG/WU bwZroFq8/13usAB747Cx/S8VvcnOKLxPmoBEoOLZh9XP2H7Plx9WCu6ZmON+WSilhTiV eFPrqrTZ0p7ewIzJrgHTF87cdJnVeNiNyObkATeCLh2B+L/X/z2h2rr9haxTbeLY5pLh Mt+R2+7SCTEDwjw6xT2Ns8ZIqTYKpPMdGUpKcAE3db5uIu5/qzKgClEupjprCvYF846O hg9A== Received: by 10.220.150.10 with SMTP id w10mr19848306vcv.16.1351269992454; Fri, 26 Oct 2012 09:46:32 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id y7sm1073020vdt.1.2012.10.26.09.46.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 09:46:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: <508AB948.305@cs.tcd.ie> Date: Fri, 26 Oct 2012 12:46:29 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0F5F4A16-90EC-4E46-893A-DFCD76FCD08B@gmail.com> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> <508AB948.305@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1283) Cc: homenet@ietf.org Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:46:33 -0000 On 26 Oct 2012, at 12:24 , Stephen Farrell wrote: > My understanding is that 3118 is fictional, > i.e. is never deployed, ever. As an AD, I generally > push back on any draft where the security considerations > say "use 3118 and you'll be fine." > > If I'm wrong, I'd be interested in knowing that > and about when/where 3118 is being used. I've been told about deployments within certain governmental networks in more than one country. So my understanding is that it is not "fictional". Yours, Ran From mike@mtcc.com Fri Oct 26 09:51:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9822A21F862A for ; Fri, 26 Oct 2012 09:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 G8BYGQzDVyCY for ; Fri, 26 Oct 2012 09:51:13 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id E0C8D21F860B for ; Fri, 26 Oct 2012 09:51:12 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9QGp0JH017778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 26 Oct 2012 09:51:01 -0700 Message-ID: <508ABF74.9000901@mtcc.com> Date: Fri, 26 Oct 2012 09:51:00 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: RJ Atkinson References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> <508AB948.305@cs.tcd.ie> <0F5F4A16-90EC-4E46-893A-DFCD76FCD08B@gmail.com> In-Reply-To: <0F5F4A16-90EC-4E46-893A-DFCD76FCD08B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=916; t=1351270264; x=1352134264; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Mixing=20DNS=20in=20with=20 routing=20information |Sender:=20 |To:=20RJ=20Atkinson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=mlF9z5a/cPNunBpBgL3sOGUetN8mk+AC4AB5a19dT+c=; b=XtDWh7L5UlbXU4qAdmfCkWTPCsDaAVN6QkU0o3WzNXMFByiCpT3NMiVlmh X+NKM7ZLHwdL6pHMuQxwF35TlAciDthMfPBlURwCk5m9DP/O9q/Gw+xyKMO1 9UOVUHeKAnrLI3Vn6vluk6SErRwOSdzOQvSHHaqoy/OrLYWt9cbc0=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org, Stephen Farrell Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:51:13 -0000 On 10/26/2012 09:46 AM, RJ Atkinson wrote: > On 26 Oct 2012, at 12:24 , Stephen Farrell wrote: >> My understanding is that 3118 is fictional, >> i.e. is never deployed, ever. As an AD, I generally >> push back on any draft where the security considerations >> say "use 3118 and you'll be fine." >> >> If I'm wrong, I'd be interested in knowing that >> and about when/where 3118 is being used. > I've been told about deployments within certain > governmental networks in more than one country. > > So my understanding is that it is not "fictional". > I think the larger question is whether "just use secure-X" is a fiction within a homenet environment. Given that "secure-X" is often a fiction within networks with nominal clue, I think we should be skeptical of just about anything that requires any clue at all. DNSSec, for example: what does that even mean in the face of zero clue? Mike From rja.lists@gmail.com Fri Oct 26 11:12:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32E021F862D for ; Fri, 26 Oct 2012 11:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 KOgkVbB90S-a for ; Fri, 26 Oct 2012 11:12:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1808F21F8632 for ; Fri, 26 Oct 2012 11:12:04 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3583551vcb.31 for ; Fri, 26 Oct 2012 11:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=ck2lJ+nHEltx88s/nEW//HyiMC5zHSIZ9Fa75q5uI7c=; b=T7KitQiWuHM51FRrzWMWgWSSDuBraoonXBoJJ/OxYOWqYzpiIAMvkln9LrDRQp0L7M to/IKePdlyCvqM7tfdK+ebRWbKvpaIDdTJ3rMq3hlVeVzUUbQQukN+B0PC1LwF9Cnq9Z 2KV0oW3qJawxEmmGBTy+tuYpG0iK6GOWyA4+OBwtZ4CfrsBQyrtpIzoasUHLRNhr85cp UDtB0ZGG8obf86gaLTzGkjuliJz0BuNLD7D1lYkGtwc66ttE55rvlF627ZT2UYuXHJHZ dtvTLM3Lnbk2CxZaeKtFQJjPzczNG4BK1A8bnKO3ztn2SNbM2PK+q+Hv5FLW7p64gqKi yjbA== Received: by 10.58.95.65 with SMTP id di1mr41875163veb.55.1351275123562; Fri, 26 Oct 2012 11:12:03 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id q7sm1175834vdw.22.2012.10.26.11.12.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 11:12:02 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Oct 2012 14:12:01 -0400 Message-Id: <55AC86D5-F9A1-43B6-9ECD-1EB7AB8C84C2@gmail.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 18:12:04 -0000 Earlier, Andrew Sullivan wrote: > ...DNSSEC cannot be used for validation with mDNS because > the actual mDNS name is [some string].local., ... mDNS can, and regularly is, also used to transport DNS information outside the ".local" pseudo-TLD. The mDNS specification explicitly says that mDNS also can be used to carry foo.bar. records. Whether mDNS happens to be used in that way in a particular deployment appears to depend on local deployment considerations. For example, I have heard about deployments where information about foo.bar. is carried by mDNS, for a variety of deployment-specific reasons. When mDNS is being used to transport DNS information that uses an official TLD (either ccTLD or gTLD), rather than "foo.bar.local", then DNSsec can be used to protect that information. My apologies for being insufficiently precise earlier. Yours, Ran From lorenzo@google.com Mon Oct 29 01:02:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCE221F867B for ; Mon, 29 Oct 2012 01:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 f7Bl-qpNcZx1 for ; Mon, 29 Oct 2012 01:02:14 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF121F867A for ; Mon, 29 Oct 2012 01:02:05 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so4951417oag.31 for ; Mon, 29 Oct 2012 01:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=k38GhhMLDhfLtUMqmwxwWZGNtPtOvvUzAqjV3Szf/F0=; b=XbLdxC0+Be6lApNmHN0iyIbswR7Pfsy2I1/QLlqa78CmVbkGFPbiB5Slt//nY6ac87 szHHr0uXsd34CBLUYrE++i1ze2Skjbu3f6hbTa1zxlqTzB2Ol8yriX0a0PqAsJISP7ns Gj3bD6CNUjJm2vN9X8Cz5Bdu+rrN5VSBfofRxFvrRqAcOnZhhgLCnRerxqyWDVgHjM0k 4VRB8ZLK5IyGai2Jp5Bj5pwpYsgHRKyhhJz34HL6KaKYKkOM4DJtFxAkYE+JG1/Ijcqx fg1Rbu3lQ4U+EYW/0htQhif+x0T7BH2GuNYNRArwVRdSXy904yXuZoGx7u78H8bhfBwS x/yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=k38GhhMLDhfLtUMqmwxwWZGNtPtOvvUzAqjV3Szf/F0=; b=LgFjDfT98lu9Y/AsZWI37atKxLgnClRTPU6PLFja28EXfQIEYO9ZkJbka6IzVmjffG ndCB14FF4zm5ER1H+i1TgMB5iDwxE2dmO0KqOtAzVYPubon4wG96tRnbH/IoHBbAvT0D 14nP19jgq9PZiXcxyLuiWgEcK8NWcw1ZCGjE/nGRRu4mF2FqrvJfu5ZVfjGMkVArMht1 HHICqcIsx4lu1lZth1fBP4LHdqDfp8iYxisj0Sqk1baMgHpp+kRP/Z1/Fs+jnXqSd37j 76WVzvvRsbS9bb3s5HNDprCE9Ug5chemGYBxH9Qnw6Xst6BNesVO9LlbLnGpIVi5DrWS 0VFA== Received: by 10.60.14.165 with SMTP id q5mr26012785oec.28.1351497724717; Mon, 29 Oct 2012 01:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 29 Oct 2012 01:01:44 -0700 (PDT) In-Reply-To: <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> From: Lorenzo Colitti Date: Mon, 29 Oct 2012 17:01:44 +0900 Message-ID: To: RJ Atkinson Content-Type: multipart/alternative; boundary=e89a8fb1f468cbe98a04cd2e1548 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlNe+a//IIPweUhUVV9xTSCCTU/PHDP+bzvH81NSVVECGfxs2loBr8AnrW0EKikH5gxx1GstAkv5oDqCUdnRxO1c0R/4F2k43MHFiQ4KU96zS5nI5wA7ylicuegxpsxfch/EHnkoMWDzXN14rMNue9jsRfKN6RTFI4CyBAokQHFYO9O+SgxmZDKKwZ6jMg+sGP5J2sX Cc: homenet@ietf.org Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:02:14 -0000 --e89a8fb1f468cbe98a04cd2e1548 Content-Type: text/plain; charset=ISO-8859-1 Ran, I think you're missing the point. What I am suggesting is that the routers, which learn DNS servers via DHCPv6 or RDNSS, can pass around those DNS servers inside the routing protocol that runs in the homenet. The hosts would then get the information from the routers using DHCPv6 or RDNSS, just like they do today. The routing protocol can be secured in the usual ways that routing protocols are secured (e.g., using MD5 secrets). I really don't see what security issues this introduces. Cheers, Lorenzo On Sat, Oct 27, 2012 at 12:59 AM, RJ Atkinson wrote: > > On 25 Oct 2012, at 20:33 , Lorenzo Colitti wrote: > >> I'm also nervous about both DNS authorisation > >> and DNS authentication. Who is allowed to make > >> which DNS advertisements and how do I authenticate > >> the received DNS advertisement as both valid and > >> authorised ? > >> > > > > I don't see a difference. There is no authorisation or > > authentication today. When you get a DNS server via DHCP, > > you believe it, or choose not to believe it, > > based on no information at all. > > 1) DHCP Authentication is standardised. [RFC 3118] > Multiple implementations of DHCP Authentication exist. > So this can be deployed/used in environments where > DHCP Authentication is deemed sensible. > > 2) DNS Security is standardised. [RFC 4033 et alia]. > Multiple implementations of DNSsec exist. Deployment > of DNSsec is growing much faster than initially > expected. So this can be deployed/used in environments > where DNS Authentication is deemed sensible. > > 3) It appears that DNSsec still can be used with mDNS. > So again, this can be deployed/used in environments > where DNS authentication is deemed sensible. > > So, a proposal with no capability to authenticate > information, or address authorisation issues, seems > very much like a non-starter. At the very least, > authentication needs to be specified/available, > and the authorisation issues need to be addressed. > > > If there's a rogue DHCP server on the link that hands you > > a rogue DNS server, then guess what, you lose. > > This is not true if DHCP Authentication has been deployed. > Instead, the quote above is a very good supporting justification > for comments that we need to specify mechanisms both that > can provide authentication and do address authorisation issues. > > > (From a different, purely practical, perspective) > > I would guess that any proposal with less security capability > than we have today (i.e. with DHCP Authentication, DNSsec) > would be rejected by the IETF Security Area when they perform > their Area Review (which is usual prior to IESG approval > of any IETF track document). > > Yours, > > Ran > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --e89a8fb1f468cbe98a04cd2e1548 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ran,

I think you're missing the point. Wh= at I am suggesting is that the routers, which learn DNS servers via DHCPv6 = or RDNSS, can pass around those DNS servers inside the routing protocol tha= t runs in the homenet.=A0The hosts would then get the information from the = routers using DHCPv6 or RDNSS, just like they do today.

The routing protocol can be secured in the usual ways t= hat routing protocols are secured (e.g., using MD5 secrets).

=
I really don't see what security issues this introduces.

Cheers,
Lorenzo

On S= at, Oct 27, 2012 at 12:59 AM, RJ Atkinson <rja.lists@gmail.com> wrote:

On 25 =A0Oct 2012, at 20:33 , Lorenzo Colitti wrote:
>> I'm also nervous about both DNS authorisation
>> and DNS authentication. =A0Who is allowed to make
>> which DNS advertisements and how do I authenticate
>> the received DNS advertisement as both valid and
>> authorised ?
>>
>
> I don't see a difference. There is no authorisation or
> authentication today. When you get a DNS server via = DHCP,
> you believe it, or choose not to believe it,
> based on no information at all.

1) DHCP Authentication is standardised. [RFC 3118]
=A0 Multiple implementations of DHCP Authentication exist.
=A0 So this can be deployed/used in environments where
=A0 DHCP Authentication is deemed sensible.

2) DNS Security is standardised. [RFC 4033 et alia].
=A0 =A0Multiple implementations of DNSsec exist. =A0Deployment
=A0 =A0of DNSsec is growing much faster than initially
=A0 =A0expected. =A0So this can be deployed/used in environments
=A0 =A0where DNS Authentication is deemed sensible.

3) It appears that DNSsec still can be used with mDNS.
=A0 =A0So again, this can be deployed/used in environments
=A0 =A0where DNS authentication is deemed sensible.

So, a proposal with no capability to authenticate
information, or address authorisation issues, seems
very much like a non-starter. =A0At the very least,
authentication needs to be specified/available,
and the authorisation issues need to be addressed.

> If there's a rogue DHCP server on the link that hands you
> a rogue DNS server, then guess what, you lose.

This is not true if DHCP Authentication has been deployed.
Instead, the quote above is a very good supporting justification
for comments that we need to specify mechanisms both that
can provide authentication and do address authorisation issues.


(From a different, purely practical, perspective)

I would guess that any proposal with less security capability
than we have today (i.e. with DHCP Authentication, DNSsec)
would be rejected by the IETF Security Area when they perform
their Area Review (which is usual prior to IESG approval
of any IETF track document).

Yours,

Ran

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

--e89a8fb1f468cbe98a04cd2e1548-- From fujiwara@jprs.co.jp Mon Oct 29 03:20:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D658621F85B2 for ; Mon, 29 Oct 2012 03:20:51 -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 f9TCAsUeCsk9 for ; Mon, 29 Oct 2012 03:20:51 -0700 (PDT) Received: from off-send02.tyo.jprs.co.jp (off-send02.tyo.jprs.co.jp [IPv6:2001:df0:8:17::20]) by ietfa.amsl.com (Postfix) with ESMTP id D89F921F85B1 for ; Mon, 29 Oct 2012 03:20:50 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send02.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q9TAKlOR030689; Mon, 29 Oct 2012 19:20:48 +0900 X-AuditID: ac120820-b7fd46d0000058b8-80-508e587fbe61 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id D5.E3.22712.F785E805; Mon, 29 Oct 2012 19:20:47 +0900 (JST) Date: Mon, 29 Oct 2012 19:20:47 +0900 (JST) Message-Id: <20121029.192047.258110609.fujiwara@jprs.co.jp> To: mcr+ietf@sandelman.ca From: fujiwara@jprs.co.jp In-Reply-To: <23679.1351011484@obiwan.sandelman.ca> References: <20121023.194755.229760265.fujiwara@jprs.co.jp> <23679.1351011484@obiwan.sandelman.ca> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsWyRoiFT7c+oi/AYPVDTYv3iw6xWPQc6md3 YPJYsuQnk0fLnD3MAUxRXDYpqTmZZalF+nYJXBlvv4oWfOOuOHTtGUsD43rOLkZODgkBE4lv cxYwQdhiEhfurWcDsYUETjJKnFrtBmKzCGhLbJ2xhRnE5hWwlljT0wpUz8EhIiAp8WZpFUiY WUBEYuvH02BjhAUsJZbdWwpWzgZUsvlzK5jNKWAssfHGT0aI8SkS37u6odbaSZx4voIVZCSv gKDE3x3CECO1JHpmPGaHsOUltr+dwzyBkX8WQtUsJFWzkFQtYGRexSiTn5amW5yal1Kcm25g qFdSma+XVVBUrJcMojcxgkOQQ2EH44xTBocYBTgYlXh4XX/0BgixJpYVV+YeYpTkYFIS5b0S 3hcgxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3KTdQOW9KYmVValE+TEqag0VJnPf42R1+QgLp iSWp2ampBalFMFl1Dg6B37u2Gkux5OXnpSpJ8EaBzBcsSk1PrUjLzClBqGTi4ATZwwO0JzgM qIa3uCAxtzgzHSJ/ilGV40z3vIeMQmCDpMR5uUCKBECKMkrz4Oa8YhQH+kyYNxhkDQ8w+cBN eAU0nAlouA4fyBPFJYkIKakGxrWJYhxvvk+bpO3osKJolYvxj603e94vNKm3nbx17Ub7qbNk o1TvTm1yPchdspVdO+iWsl3cnvQ/e0+Ype1LrC8yWZ+5+4XHnmZBgwW+QquX5f+MfiByZ7uW XH+Rx96Jvy0+Xiy+Uvck6Ng9P4vluzPnLDjT+zr32NbEKxOt1KU4fE0cG5IUmZVYijMSDbWY i4oTAe/n6lT7AgAA Cc: homenet@ietf.org Subject: Re: [homenet] draft-fujiwara-smallest-homenet-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:20:52 -0000 > From: Michael Richardson > fujiwara> I submitted draft-fujiwara-smallest-homenet-01 > fujiwara> http://www.ietf.org/internet-drafts/draft-fujiwara-smallest-homenet-01.txt > > fujiwara> Although access control for home servers is very important, > fujiwara> managements and setups of access controls are difficult for most of > fujiwara> users. "Connecting a new node to the same link" is > fujiwara> easiest way of > fujiwara> access control. One of solutions is to use link-local > fujiwara> addresses for > fujiwara> communications of clients and servers. > > fujiwara> Is it in a scope of homenet WG ? > fujiwara> Does anyone have interests for the idea ? > > It seems to me like it's already an accepted part of the homenet arch. > There will be ULAs and GUAs, and ULAs will be preferred for local > communication. Thanks. What I would like to say is that - Access control in homenet servers is important - There are no/few experts in many homenets. - Easy configuration is required for homenet servers. # For example, link based access control. My idea is that by using Link-local address positively, the communication in a link and the communication to the Internet can be separated, and a design becomes easy. (We don't need new protocols.) After submitting this draft, I considered new idea to set default ACL as the same net (/64) of servers. -- Kazunori Fujiwara, JPRS From rdroms.ietf@gmail.com Mon Oct 29 06:37:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E922A21F85A5 for ; Mon, 29 Oct 2012 06:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SaQ-vgxh-y7 for ; Mon, 29 Oct 2012 06:37:45 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48D8221F8647 for ; Mon, 29 Oct 2012 06:37:45 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so1448517qao.10 for ; Mon, 29 Oct 2012 06:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0YiivvRZ/92tq/7hb1qPlh0+31N/55ufznsLiWkJOxw=; b=Aw75dRvg0lHP5J0w5O9+ymrs3XWKrrPKG9BakSjtIwZbIO54CnftEYMWres62YF4pl GCN7Pml8TBmKCrqQueyzQOQa5Xrv78Cug8BX3rDgzreH0qORnUHEpgNn2mGu/qAgz/Q9 gJSMkGYKxSgtZe6K9n8RK3wHCWsv1ND6SuDy6Zg3u1wVxNHIx2CboNT45VJTlEokwylt yG7Za1d5QtTQcJno0sG1FguLwCupuz4FfUt2TsKZ+9x2497NmzMIVXPr1uoXyMRS3IDt OVFKPWuFPGe8iKuEdyVs8hFf2tJT/TWyk+hOqF+8rLXlu3Jjiz73lFPhTx7MbR/Dizod ycFA== Received: by 10.49.58.212 with SMTP id t20mr6013113qeq.26.1351517864579; Mon, 29 Oct 2012 06:37:44 -0700 (PDT) Received: from [192.168.1.116] (c-24-62-106-121.hsd1.ma.comcast.net. [24.62.106.121]) by mx.google.com with ESMTPS id g9sm5953082qaj.18.2012.10.29.06.37.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 06:37:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <0F5F4A16-90EC-4E46-893A-DFCD76FCD08B@gmail.com> Date: Mon, 29 Oct 2012 09:37:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F6B677D-0009-4EE1-BB7A-1BEBDA194F1B@gmail.com> References: <68440DB2-3AD0-41E3-970E-9E86706EA870@gmail.com> <44FB0349-1082-4C9D-AAF6-45A97CF483C5@gmail.com> <508AB948.305@cs.tcd.ie> <0F5F4A16-90EC-4E46-893A-DFCD76FCD08B@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" , Farrell Stephen Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 13:37:46 -0000 On Oct 26, 2012, at 12:46 PM 10/26/12, RJ Atkinson wrote: >=20 > On 26 Oct 2012, at 12:24 , Stephen Farrell wrote: >> My understanding is that 3118 is fictional, >> i.e. is never deployed, ever. As an AD, I generally >> push back on any draft where the security considerations >> say "use 3118 and you'll be fine." >>=20 >> If I'm wrong, I'd be interested in knowing that >> and about when/where 3118 is being used. >=20 > I've been told about deployments within certain=20 > governmental networks in more than one country. =20 >=20 > So my understanding is that it is not "fictional". Interesting...I've not heard of this deployment before. I'd be = interested to know how they manage the shared keys. - Ralph >=20 > Yours, >=20 > Ran >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Mon Oct 29 07:03:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CC021F85C0 for ; Mon, 29 Oct 2012 07:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b5nNZ9iAUuO for ; Mon, 29 Oct 2012 07:03:28 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id A638A21F85B8 for ; Mon, 29 Oct 2012 07:03:27 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TE3MRo017710 for ; Mon, 29 Oct 2012 14:03:22 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9TE3MRo017710 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1351519403; bh=wlbxxBSy0AOaqDFn/8gXeOR5Nlc=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=JeIUc73bpfewmoudirVpCJfQDZ6lrNOqagJ/8Bi61aNtYuGL/ZtMMe5l8I9GpOnuI WDNk6pZxHhceWOLbxj2xyH8csh7a2lzgSbB5xL59o1Pu6Sy0VA/ZpAKqYYtKBdKNO/ XDQHSsdKH0ZpgJ+64QBgXxL2PsLKUUO3FdNSclPs= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9SE3M0430601577dG ret-id none; Mon, 29 Oct 2012 14:03:23 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TE3LYV014588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 14:03:21 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <20121029.192047.258110609.fujiwara@jprs.co.jp> Date: Mon, 29 Oct 2012 14:03:28 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20121023.194755.229760265.fujiwara@jprs.co.jp> <23679.1351011484@obiwan.sandelman.ca> <20121029.192047.258110609.fujiwara@jprs.co.jp> <3133C308-ADE9-41C9-BFD8-1BAA822DCC21@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9SE3M043060157700; tid=o9SE3M0430601577dG; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9TE3MRo017710 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] draft-fujiwara-smallest-homenet-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:03:29 -0000 On 29 Oct 2012, at 10:20, fujiwara@jprs.co.jp wrote: >> From: Michael Richardson >> fujiwara> I submitted draft-fujiwara-smallest-homenet-01 >> fujiwara> = http://www.ietf.org/internet-drafts/draft-fujiwara-smallest-homenet-01.txt= >>=20 >> fujiwara> Although access control for home servers is very = important, >> fujiwara> managements and setups of access controls are difficult = for most of >> fujiwara> users. "Connecting a new node to the same link" is >> fujiwara> easiest way of=20 >> fujiwara> access control. One of solutions is to use link-local >> fujiwara> addresses for=20 >> fujiwara> communications of clients and servers. >>=20 >> fujiwara> Is it in a scope of homenet WG ? >> fujiwara> Does anyone have interests for the idea ? >>=20 >> It seems to me like it's already an accepted part of the homenet = arch. >> There will be ULAs and GUAs, and ULAs will be preferred for local >> communication.=20 >=20 > Thanks. >=20 > What I would like to say is that > - Access control in homenet servers is important > - There are no/few experts in many homenets. > - Easy configuration is required for homenet servers. > # For example, link based access control. >=20 > My idea is that by using Link-local address positively, the > communication in a link and the communication to the Internet can be > separated, and a design becomes easy. (We don't need new protocols.) >=20 > After submitting this draft, I considered new idea to set default ACL > as the same net (/64) of servers. There is some text in the homenet architecture draft that says similar = things, but on the basis of using ULAs rather than link-locals. The other aspect from the homenet draft is the realm and border aspect. = The homenet should be able to discover borders, both internal and = external, between realms and apply appropriate policy between those = realms. The assumption is that a subnet is the smallest realm. The latest version added a note that it is desirable that hosts/nodes = can determine the realm they are in.=20 Tim From ajs@anvilwalrusden.com Mon Oct 29 08:14:31 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392D721F8707 for ; Mon, 29 Oct 2012 08:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvilprVPQTBO for ; Mon, 29 Oct 2012 08:14:30 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7321F8703 for ; Mon, 29 Oct 2012 08:14:30 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 13D248A031 for ; Mon, 29 Oct 2012 15:14:27 +0000 (UTC) Date: Mon, 29 Oct 2012 11:14:28 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20121029151427.GC59713@mx1.yitter.info> References: <55AC86D5-F9A1-43B6-9ECD-1EB7AB8C84C2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AC86D5-F9A1-43B6-9ECD-1EB7AB8C84C2@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] Mixing DNS in with routing information X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:14:31 -0000 On Fri, Oct 26, 2012 at 02:12:01PM -0400, RJ Atkinson wrote: > Earlier, Andrew Sullivan wrote: > > ...DNSSEC cannot be used for validation with mDNS because > > the actual mDNS name is [some string].local., ... > > mDNS can, and regularly is, also used to transport > DNS information outside the ".local" pseudo-TLD. Draft-cheshire-dnsext-multicastdns-15 notes that this is a contentious issue. (I also think it's a stupid idea, but I don't run the circus, of course.) But you're right: in that case, you probably can do DNSSEC on it. I'd be delighted to learn that there's a resolver out there that knows how to do this. Do you know of one? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From Ray.Bellis@nominet.org.uk Mon Oct 29 08:28:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B272D21F86E7 for ; Mon, 29 Oct 2012 08:28:18 -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 sMdYrZKqxlRO for ; Mon, 29 Oct 2012 08:28:17 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 873A021F86E5 for ; Mon, 29 Oct 2012 08:28:16 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=FI3CheDROi+iIgMXHFHJ8S+21CLn8pOmWJ/B/9XFNTxjCHfXHVhNq776 YI2dgJ4NQUKtegj+tINu87iYrepAVdSH/kPpxgL940hnifW5yr1K/cFlH U7LjjoFLvPhiwME; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1351524497; x=1383060497; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20IETF85=20session=20agenda|Date:=20Mon,=2029 =20Oct=202012=2015:28:13=20+0000|Message-ID:=20<1F8F6EE7- BD99-4E30-84A0-D1EAB9470F8A@nominet.org.uk>|To:=20"homene t@ietf.org=20Group"=20|MIME-Version:=20 1.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<264deb5d-0f49-4c0b-b3f8-84e76d2c28ac>; bh=Fr/u/hk65XuWOMsENT6Pol0+l6LQnjoeb1Q47JgYde4=; b=Wci2KN3MenGrw+s7EBdFE4qPJagj1ZWDoYejREYcMS69v3vIDlWG72fh I2vHYzlQLdZ2PceD+bHMm9qjaXt55CW/k5PpiQYjoyIMClsTAGcQVQQ9t 1hj2Ws/rufxSFlR; X-IronPort-AV: E=Sophos;i="4.80,673,1344207600"; d="scan'208";a="44252078" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 29 Oct 2012 15:28:15 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi; Mon, 29 Oct 2012 15:28:13 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: IETF85 session agenda Thread-Index: AQHNteoCzBI7++pQ5Uu4OouiuskmjQ== Date: Mon, 29 Oct 2012 15:28:13 +0000 Message-ID: <1F8F6EE7-BD99-4E30-84A0-D1EAB9470F8A@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <264deb5d-0f49-4c0b-b3f8-84e76d2c28ac> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] IETF85 session agenda X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:28:18 -0000 The IETF85 draft session agenda for Homenet is now online at: and shown below: --8<--8<-- Homenet Working Group 7th November 2012 09:00 - 09:10 Note Well, Jabber Relay, Note taker(s) 09:10 - 09:25 Homenet Architecture Update draft-chown-homenet-arch-06 (Tim Chown - 15m) 09:25 - 09:45 Naming and Service Discovery update from MDNSEXT BoF (TBC) 09:45 - 10:40 Routing and Prefix Assignment draft-arkko-homenet-prefix-assignment-03 (Jari Arkko - 15m) draft-haddad-homenet-multihomed (Damien Saucez - 15m) wider discussion on source + dest based routing (Jari / Lorenzo - 25m) 10:40 - 11:25 Security draft-kline-default-perimeter-01 (Erik Kline - 15m) draft-boot-homenet-brdp-00 (Teco Boot - 15m) draft-behringer-homenet-trust-bootstrap-00 (Michael Behringer - 15m) 11:25 Wrap-up 11:30 Close --8<--8<-- See you then! Ray From jhw@apple.com Mon Oct 29 10:41:30 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B88E21F86F3 for ; Mon, 29 Oct 2012 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayVVTVy7dJmd for ; Mon, 29 Oct 2012 10:41:27 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id D0E2721F86E8 for ; Mon, 29 Oct 2012 10:41:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MCO00K2Z141G9W1@mail-out.apple.com> for homenet@ietf.org; Mon, 29 Oct 2012 10:41:06 -0700 (PDT) X-AuditID: 11807137-b7fd26d000001104-d7-508ebfafad93 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id D3.7B.04356.2BFBE805; Mon, 29 Oct 2012 10:41:06 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by cilantro.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MCO00D9C1482G30@cilantro.apple.com> for homenet@ietf.org; Mon, 29 Oct 2012 10:41:03 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: <994FBBCB-0844-4182-927B-6ED5A7B19986@inf-net.nl> Date: Mon, 29 Oct 2012 10:40:55 -0700 Message-id: References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <0435F886-1E8B-4302-832F-C9D0269981A4@apple!.com> <5@apple.com> To: Teco Boot X-Mailer: Apple Mail (2.1625) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAspLtpf1+AweY9uhbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrJzZ9gK+pgqVk/9wdTAeJmxi5GTQ0LAROLc+TvMELaYxIV7 69m6GLk4hASmMUlMbX7AApIQEpjDJNH01hjEFhYIkPjUuA8sziygJbF+53EmEJtXQE/i/9Ez TBA1rhInDi4Fq2ETUJH4dvkuWJxTwE7i1PFzrF2MHBwsAqoSk2fwQYzRl+jd85ANwtaWePLu AlgJr4CNxO27IhDn9HJIvPr3GmyMiIC8xPQj/1ggbpaV+LFgBcsERsFZSC6aheSiWUjGLmBk XsUoWJSak1hpaKaXWFCQk6qXnJ+7iREckIXmOxi3/5U7xCjAwajEw7txTV+AEGtiWXFl7iFG CQ5mJRFe5fVAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryOgkApgfTEktTs1NSC1CKYLBMHp1QD Ywij68m6aNZDRplpd/7d03/wQv6E50OnJRvMdgplOB2IjAkUKzA8q8uy4KXDhk4F1dXl+qu2 sO3K7TP6uDb1yO3cT2ERtzNC1qse/ZX20LZ5X+aeroJJloz7vadJuFjW5Bq8XP7l2ZWNChsr lgt/0Xj/y99jzspbXQHPH3DujbmcHx77nblDT4mlOCPRUIu5qDgRADa4a4hEAgAA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 17:41:30 -0000 On Oct 26, 2012, at 24:29 , Teco Boot wrote: > > Opinions? Seems like a straight-up job for IPsec, which is why RFC 6092 has section 3.2.4 IPsec and Internet Key Exchange (IKE). -- james woodyatt core os networking From mark@townsley.net Mon Oct 29 11:25:03 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA921F86EE for ; Mon, 29 Oct 2012 11:25:03 -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 c7A7LzpsEPuY for ; Mon, 29 Oct 2012 11:25:03 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6B8521F86E8 for ; Mon, 29 Oct 2012 11:25:02 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2111673eaa.31 for ; Mon, 29 Oct 2012 11:25:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=efx2W95PtC3+DhMQee82dD7n1DP/hvAY+TS9NjqXkmU=; b=oyYNtqNIPsbLOCuI+Ck+pnrgV4R6iNrykZ38FLvgOyR13/rm9mFQqTAElN69Yombrr MK8PPdqwQrIuiaZPFGUqSOVMHnZmmTcbOmDQZy/y/2SIbWCKD1A2x8vw9YraIieIlGR6 yUipXp1ZbQ9dGQqrHZBFMZLkwGODV0zIR6Cmm8SmLxsBUmqCSMM/SNhaqF6NDmwkMDxj u4mzotNT/RL1IL3iCbrS83YWzwq+Wz4ZGMXxhIoB15Rt5bN3n6YxBsVmn5H1nCsd1L3L 09/XmCyN1+SfNp+ZlqLjN09crS272ckIzY6J7TTWhCocPEME4O6+Sra1m1ztCC/EdPA8 Artw== Received: by 10.14.216.193 with SMTP id g41mr55028207eep.37.1351535101896; Mon, 29 Oct 2012 11:25:01 -0700 (PDT) Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 42sm24262153eee.0.2012.10.29.11.25.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 11:25:01 -0700 (PDT) From: Mark Townsley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Oct 2012 19:24:59 +0100 Message-Id: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmVhHFxIxlkiKn08loiW2WrHcq/OlwcE+mz0j1u8c+cQNzXanvdQj6zPCfRYeRsL8FqxhJh Subject: [homenet] Service discovery scope in homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:25:04 -0000 There has been some discussion on where homenet's scope is with respect = to service discovery. My recollection of the scope discussion with respect to service = discovery in the home is that homenet would not try to pick any single = service discovery mechanisms as the one and only one for homenet, but = that would it aim to enable existing mechanisms to work with in a = multi-segment, IPv6-enabled, home. The mechanism cited most often has = been mDNS/DNS-SD (a.k.a. "Bonjour") which also seems to be the primary = subject of the mdnsext BoF, however that does not preclude advacing a = recommendation for LLMNR, SLP, or any other mechanism, as long as there = is someone who will do the work and that work is limited to taking a = protocol already defined for IPv4 and making sure it works in a = multi-segment, IPv6, home network.=20 - Mark= From Efrain.Fino@videotron.com Mon Oct 29 13:03:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03221F85A5 for ; Mon, 29 Oct 2012 13:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv0OJJ+aD+Ff for ; Mon, 29 Oct 2012 13:03:40 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id E8DF421F8599 for ; Mon, 29 Oct 2012 13:03:39 -0700 (PDT) Auto-Submitted: auto-generated From: Efrain.Fino@videotron.com To: homenet@ietf.org Message-ID: Date: Mon, 29 Oct 2012 16:03:27 -0400 X-MIMETrack: Serialize by Router on DOMSMTP01/SRV/Videotron(Release 8.5.3FP1|March 07, 2012) at 2012-10-29 16:03:29 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Received-SPF: none Subject: [homenet] Efrain Fino est absent(e) / is out of the office X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:03:40 -0000 Je serai absent(e) du 2012-10-29 au 2012-10-30. I will be out of the office from Oct 29th returning on Oct 30th. From teco@inf-net.nl Mon Oct 29 13:37:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E6321F86F0 for ; Mon, 29 Oct 2012 13:37:27 -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 QmCIdJkWF9yL for ; Mon, 29 Oct 2012 13:37:26 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 301ED21F86EE for ; Mon, 29 Oct 2012 13:37:26 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2160480eaa.31 for ; Mon, 29 Oct 2012 13:37:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=I1D5wBxu4Twp+UCRZrtCik7B/IUB6i+SM2Nz4VMg0xY=; b=P+2P6Q7qHHkbv69c9UIJW7+vuiQDErahIFC4X8+YJdJ/lD09va8yCUWxeHhtr9ox7c smq1S+e6+gFCkKFfqg4pdsFuaGDpssq5ZA7wcAkERWgKDqAE/cOGo61gwFbYofOGZzqO jPjZDmW8znvvdRyN7nHfFHFOGTppqhdxBimYJ7eDNZZPWGBMnGgJf+bvQl3zSj0uUF/V 6uaPhmU74Hjuc6G001HzVA6JmgB6qg7XPutwQpcnWr1yXuP7WtOkw8wVAd5Y+0YstXzi wfnCHi4/E2UAINfRzEX7OkQkEKYN2stgUPsl5MKl0vzk1pecvrkEC7elAT4zEBWYzEui A6Iw== Received: by 10.14.200.194 with SMTP id z42mr56864228een.13.1351543045322; Mon, 29 Oct 2012 13:37:25 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id s1sm24962586eem.9.2012.10.29.13.37.24 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 13:37:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7399.1351531305@obiwan.sandelman.ca> Date: Mon, 29 Oct 2012 21:37:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EFC7FC6-EC0F-4FDA-B4F5-4877538E9647@inf-net.nl> References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <5086B5A7.3040706@mtcc.com> <0435F886-1E8B-4302-832F-C9D0269981A4@apple! .com> < 50896915.6080404@mtcc.com> <994FBBCB-0844-4182-927B-6ED5A7B19986@inf-net.nl> <7399.1351531305@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmWI+eKfHga0EDv23OmsHvToti/KUjem8gcmNfvZZnfViB4iwfZ03ErGUPjtNJT76nYAnr+ Cc: homenet@ietf.org, Michael Thomas Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:37:27 -0000 Op 29 okt. 2012, om 18:21 heeft Michael Richardson het volgende = geschreven: >=20 >>>>>> "Teco" =3D=3D Teco Boot writes: > Teco> More thoughts on this scenario. Assume the company has many = branch=20 > Teco> offices (e.g. 1000 small sites, with 2001:xxxx::/48 from = ISP),=20 > Teco> where main office has 2000::/48. Each branch office is = equipped as=20 > Teco> a homenet, the gear is cheap and just acts as the = requirements. It > Teco> provides Internet access and VPN to main office and indirect = to all=20 > Teco> other branches. Branch office managers set up their homenet > Teco> equivalent =20 > Teco> to the branch offices. This doubles the number of VPN > Teco> tunnels.=20 >=20 > A question for clarification: the branch office managers setup the > homenet at their *HOME* to talk to their office. (The fact that the > branch office may or may not be a homenet is not relevant) Ack >=20 > Lest anyone think that the Branch Officer Manager won't know how to do > this, work in ipsecme right now attempts to automate this kind of > on-demand partial mesh, and make it work cross-vendor. I'm not so sure ipsecme and our wg products are compatible. Teco >=20 > --=20 > Michael Richardson , Sandelman Software Works=20= >=20 >=20 From mark@townsley.net Tue Oct 30 10:16:17 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354BC21F86F4 for ; Tue, 30 Oct 2012 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 ZAfI5Q1DefhH for ; Tue, 30 Oct 2012 10:16:15 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56E5F21F867C for ; Tue, 30 Oct 2012 10:16:15 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so243782eaa.31 for ; Tue, 30 Oct 2012 10:16:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer:x-gm-message-state; bh=tofLoz7RGlYjcyMq7old0aAehFKOKzM39/koRBiP8pI=; b=jtn0dlBnOKvwhZM13HM4/TrImT7L3STEofneRXnkZvY9rsS31Bk9t+h0pGe0+EPKGe jxhHs1AA/M1zvFi/LpgylcVgxfz+3E7/A735dg9z/n+n6jnBCZNv8gCZ0sKssSr8vpIp 9SPdDZS9WOwNw+1/jLk5GaoAihhJJLFbumdJXFWY09JT8yHwQnfoJeyh4lIFScDYI5AT azToSCD62/+WhJggD2v8oHgvCBnK7Ure7WUora7ohvWFJyuom+KjJJoMmew2KppwLkR4 Ssw/MhOnqXLvd72PcYHVEEVEF26cNB7+Ef7rjTM9qngC/nLY6COLg3uh3VqQ5uc0TAnm RtVA== Received: by 10.14.216.193 with SMTP id g41mr66766879eep.37.1351617374358; Tue, 30 Oct 2012 10:16:14 -0700 (PDT) Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e7sm2612811eep.1.2012.10.30.10.16.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 10:16:13 -0700 (PDT) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_1C82B0E7-F066-4727-8D89-3C9E9D03D312" Date: Tue, 30 Oct 2012 18:16:11 +0100 Message-Id: <53D63104-623F-4F61-854C-30AF7DC40294@townsley.net> To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmbetiUNZyW5jqGRnllx2spIaGHxgKe0V4jKV3GAbIYJDLUxTm1zJl7LJBGrTkecxDGL1oG Cc: Markus Stenberg , Jari Arkko Subject: [homenet] Interop for OSPF-based homenet solution at IETF 85 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:16:17 -0000 --Apple-Mail=_1C82B0E7-F066-4727-8D89-3C9E9D03D312 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Group, When we created the homenet WG, we identified that open source code was = a critical component in the consumer home router marketplace. As such, I = thought I'd let the group know that there will be open source coders in = our midst next week carrying around some OpenWRT routers and = implementations of homenet-targeted drafts. Their work is based on the = work Jari has been leading. Jari is one of the coders, the other is = Markus Stenberg, whose company is being supported via a Cisco = "Technology Fund" project that I was a co-sponsor of within Cisco. Two = compilier-wielding Finns. =20 The implementations are based on these drafts: http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02 http://www.ietf.org/id/draft-acee-ospf-ospfv3-autoconfig-03.txt The IPSO folks have been nice enough to offer them a corner of a table = to work on, and I suspect that's where you will be able to find them = during the week when they are not doing other things. They have also = been generously offered a corner of a table at bits-n-bites in case you = miss them during the week and want to look at what they have over food = and beer.=20 I've been cc'd on some of the emails between Jari and Markus, and = believe they will have a presentation ready showing what they hope to = have working, not working, etc. by the time we meet next week if not = before. My understanding is that Jari and Markus both consider their = work "Experimental" at this stage, and the aim is simply to learn as = much as possible this week. Assuming they get things up and running, = please come by with every kind of IPv6-enabled device you can think of = to plug into their network. Try your best to break it, and capture what = happened when the breakage occurred. If you're really bored, hack up = your own implementation and plug in ;-) Organization of this has all been very last minute and informal thus = far. For future IETFs, the ADs have offered to work with homenet to have = our own space rather than having to camp out with others. So - if you = have some running code, let us know and we'll make sure we have some = place for you to work together.=20 See "y'all" in Georgia next week, - Mark --Apple-Mail=_1C82B0E7-F066-4727-8D89-3C9E9D03D312 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The implementations are based on these = drafts:


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

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

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

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

- = Mark




= --Apple-Mail=_1C82B0E7-F066-4727-8D89-3C9E9D03D312-- From simon@thekelleys.org.uk Tue Oct 30 14:18:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312A321F85FD for ; Tue, 30 Oct 2012 14:18:48 -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 6yzJwaeHE7IH for ; Tue, 30 Oct 2012 14:18:47 -0700 (PDT) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 9901721F85FC for ; Tue, 30 Oct 2012 14:18:46 -0700 (PDT) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:36134 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TTJCs-0005bV-4P for homenet@ietf.org; Tue, 30 Oct 2012 21:18:42 +0000 Received: from spike.thekelleys.org.uk ([192.168.0.193]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TTJCr-0006Pn-JR for homenet@ietf.org; Tue, 30 Oct 2012 21:18:41 +0000 Message-ID: <50904431.1000608@thekelleys.org.uk> Date: Tue, 30 Oct 2012 21:18:41 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11 MIME-Version: 1.0 To: homenet@ietf.org References: <53D63104-623F-4F61-854C-30AF7DC40294@townsley.net> In-Reply-To: <53D63104-623F-4F61-854C-30AF7DC40294@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Interop for OSPF-based homenet solution at IETF 85 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 21:18:48 -0000 On 30/10/12 17:16, Mark Townsley wrote: > > Group, > > When we created the homenet WG, we identified that open source code > was a critical component in the consumer home router marketplace. As > such, I thought I'd let the group know that there will be open source > coders in our midst next week ........ This may be an opportune moment to note that I too will be attending IETF, thanks to the tireless efforts and sponsorship of Dave Taht. I'm the main author and developer of dnsmasq, which is the open-source DNS forwarder and DHCP server component used in many home routers. Recent releases of dnsmasq have added DHCPv6 support, and future releases are slated to add DNSSEC validation. I'm keen to talk to anyone who has ideas and requests for further work on dnsmasq which will advance the homenet cause, and to anyone who can help provide resources to support that work. Cheers, Simon.