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