Re: [homenet] A poll

[Jim Gettys]

On Fri, Feb 20, 2015 at 11:50 AM, Dave Taht  wrote:

> The homenet working group has been laboring for several years now to
> find ways to make ipv6 more deployable to home (and presumably small
> business) users.
>
> In addition to multiple specification documents some code has been
> produced to try and make things easier. At least in the USA, comcast
> has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on
> their router, and/or is willing to install a custom firmware on their
> router to get that, and of course tunneling ipv6 is possible if the
> ISP does not support it.
>
> So a quick poll:
>
> 0) Have you managed to get ipv6 working at all? If so, how? What sort
> of problems did you encounter?
>

​Yes.  Both hurricane electric tunnel​

​and Comcast native IPv6.

Getting the HE tunnel configured properly is somewhat a pain, as the
terminology on OpenWrt is slightly different than that used by HE.

The native IPv6 from Comcast has been fine.​

>
> 1) Have you attempted to deploy a routing protocol in your home? Which
> one, and why?
>

​Babel.  Out of the box in CeroWrt.​


>
> 2) Have you attempted to get hnetd's prefix distribution system
> working? (it supports linux mainline and openwrt presently)
>
> 3) Do you use ethernet? How many clients in your home are ethernet
> connected?
>

​Dunno exactly.  Probably around 8-10 devices.​


>
> 4) Do you use wifi?

​Yes.​


> How many clients are wifi connected?


​maybe 8-10 devices.​



> Do you use
> range extenders?
>

​No
​


>
> 5) How many devices do you think you will have connected to the
> network in your home in 5 years?


​25.​



> How many now?
>

​Maybe 16.​


>
> 6) Do you use any other network connected technologies (homeplug,
> 802.14, LTE, etc). If so, which ones, and why?
>

​No.
​


>
> 7) Do you use mdns service discovery?
>

​Yes.
​


>
> 8) Why are you here? (especially, if your answers to 0-2, are "no")
>
>
> --
> Dave Täht
>
> http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>
> ___
> 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

Re: [homenet] Routing protocol comparison document

[Jim Gettys]

On Wed, Feb 18, 2015 at 11:13 AM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> >> create blackholes; IS-IS will collapse during reconvergence;
>
> > Collapse?
>
> Okay.  I'll reformulate that.
>
> I am not aware of any results in the open litterature that describe the
> behaviour of single-area IS-IS during reconvergence.
>
> I am not aware of any results in the open litterature that describe the
> performance of IS-IS's reliable flooding, and hence its convergence speed,
> over the 802.11 MAC in the presence of marginal links.
>
>
​Note that it is exactly collapse that ​
​worries me most (having seen it first hand, in the most extreme possible
way, in the 802.11s mesh we used at OLPC).​  In that case, there was (maybe
still is) an N squared algorithmic issue in a "dense mesh", so scaling the
network up failed entirely at dismayingly few number of nodes.
  - Jim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Jim Gettys]

On Thu, Dec 18, 2014 at 7:19 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
>
> On 19/12/2014 11:22, Juliusz Chroboczek wrote:
> > Shouldn't we reduce the amount of cross-posting at some point?
> >
> >>> mptcp, I'm told, is likely to show up in Apple and Google products and
> >>> infrastructure, and my idea (and many others) is that you don't always
> have
> >>> to pick the perfect address for the SYN, just one that works, but
> rather one
> >>> can add better addresses as one discovers them.
> >
> >> But bad luck if you need UDP.
> >
> >> Some form of intelligent probing does seem to be the answer,
> >
> > I'd like to attract your attention to the work that Matthieu Boutier has
> > been doing on mosh, Keith Winstein's UDP-based ssh replacement:
> >
> >   http://comments.gmane.org/gmane.network.mosh.devel/749
> >
> > Boutier's version of mosh builds connections across all
> source/destination
> > pairs, and picks the one with lowest RTT.
>
> Sounds interesting. In the ideal world, that would be a pluggable
> policy algorithm. Lowest RTT may not always be the best choice.
> NAROS* suggested distributing policy from a single source, for
> example.
>
> The point about shim6, of course, is that allows you to change
> horses in midstream without bothering the transport layer.
> It's a real shame we don't know how to deploy it, especially
> for homenets where nobody manages the routing policy.
>

​
What were the problems with getting shim6 deployed?

There appear to have been
​a Linux implementation, and if the idea now has merit, that is enough of
the market (which is very responsive) ​
​to get significant deployment, and to do so quickly. (codel/fq_codel went
from concept to shipping code is under 3 months, with wide test deployment
in a year, and now becoming default).  We aren't talking about 5 year
product cycles any more.

As to policy, the home routers themselves give us a place to enable people
to state the policy they want (e.g. only use the LTE upstream if the cheap
broadband service is unavailable...).
- Jim


>Brian
>
> * C. Launois, O. Bonaventure, and M. Lobelle. The NAROS approach for IPv6
> multihoming with traffic engineering. volume 2811 of Lecture Notes in
> Computer
> Science, pages 112–121. Springer Berlin Heidelberg, 2003.
>
> > It's a work in progress --
> > there are multiple versions, and Matthieu has yet to decide which
> > implementation he's going to submit for inclusion in mainline mosh.
> >
> > We hope to write that stuff down when Matthieu has decided which is the
> > "right" version, but I'm not promising any hard deadlines -- we have a
> lot
> > of stuff that we want to write down.
> >
> >> but certainly that needs to be generic because we cannot expect
> >> all apps developers to reinvent it.
> >
> > Uh-huh.  But there's only one thing that's worse than generalising from
> > one example -- it's generalising from zero eexamples.
> >
> >> http://tools.ietf.org/html/draft-naderi-ipv6-probing recently.
> >
> > I'll have a look, thanks for the pointer.
> >
> > -- Juliusz
> >
>
> ___
> 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

Re: [homenet] Scaling and standards committees.

[Jim Gettys]

On Sun, Nov 23, 2014 at 4:27 PM, Michael Richardson 
wrote:

>
> Jim Gettys  wrote:
> > At the time, we identified three problems; 1) 802.11s had N squared
> > behavior in a dense mesh (where all 802.11 nodes can hear each
> other),
> > and by the time N was of order 15-20 laptops, disaster ensued.  This
> > could be so bad that it entirely defeated carrier sense and all
>
> Aside from the standards process and scope issue, and the lack of, I guess,
> running-code; I also wonder if part of the major difficulty is that 802.11s
> has to be implemented in a place (the wifi MAC firmware) which is usually
> closed to innovation, and almost impossible to apply patches.
>

​Actually, there is also a non-firmware version of 802.11s for Linux.  OLPC
used a firmware version as we suspended the CPU and let the mesh run
autonomously in the WiFi module, for better power consumption.

But the real point was that the 802.11s committee had ruled scaling it as
"out of scope", and ​

​people do what they will do without paying attention to the pious claims
that it was not "in scope" for the standard.  In short, homenet is creating
an attractive nuisance, and people will try to apply it in ways we don't
anticipate. Once burned, twice shy.
   - Jim



> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Scaling and standards committees.

[Jim Gettys]

At the IETF meeting, I made a fuss about scaling and ensuring we can
transition between protocols. Not only do protocols need to work in small
scale testing, they need to work at sufficient scale for the environment of
use. This concern applies both to HNCP and for Babel vs. ISIS decision the
working group is struggling with.

Here's why I was a PITA:

At One Laptop Per Child we made the attempt to use the 802.11s
not-yet-standard mesh networking (this was about 2006).  We failed
*disastrously*. At some scale between 15-30 laptops, our network "melted"
and became totally unusable, even though our software worked fine "in the
small" when testing at scale 5-10 laptops. As a result we had wonderful
demoware, which could not be deployed

At the time, we identified three problems;
1) 802.11s had N squared behavior in a dense mesh (where all 802.11
nodes can hear each other), and by the time N was of order 15-20 laptops,
disaster ensued.  This could be so bad that it entirely defeated carrier
sense and all laptop's WiFi would attempt to access the air simultaneously.
When we looked at the WiFi channel with a signal analyzer, all high
frequencies were gone, and a WiFi packet analyzer showed us that at most 14
bits of the wireless preamble were intact before a different laptop would
attempt to transmit. This was induce-able just by opening the laptops at
the same time, with the ensuing DHCP requests and other initial "chatter"
of the laptops.
   2) we were transmitting keys when hashes would do, causing our secure
distributed state protocol used for our collaborative applications to use
many more bytes than necessary.
3) Even worse, our collaboration software, in the absence of a server,
used a "reliable" multicast protocol for collaboration, dropping the
effective bandwidth of 802.11 to basic rate. A little multicast can ruin
your whole day on WiFi.

But we completely missed bufferbloat.:

   4) a few years later I ran into bufferbloat at home and started to
understand what we had been seeing.  The OLPC's had 1027 packets of
buffering in the WiFi stack, and I know today how disastrous that was to
performance on the air. You can do the math of how many seconds of
buffering that represents on a network, particularly a busy WiFi network.
Without queue management, you get congestion collapse and an absolute
performance cliff when the link saturates

How does this apply to homenet?


o The IEEE 802.11s committee had decided that it wanted to rule > 32 nodes
as "out of bounds" for the design of 802.11s, ignoring the use case of a
room full of kids with laptops in a school entirely (not to mention, a room
full of people in a  conference room). As a result, they did not think
about the fact that their layer 2 mesh protocol ended up transmitting N^2
packets to discover the mesh exits.

*Moral*: once it becomes possible, people *will* attempt to use something
in ways that a committee may not have considered, or ruled as "out of
scope" and use it at higher scale than it considered.  But reality has this
nasty way of intervening as things scale up. If it *is possible*, people
*will* try to do it, even if the designers think it is a "bad idea" or "out
of scope".

This is why worrying about scale, and whether there is a viable protocol
transition strategy is so important.

o bufferbloat is well on its way to being solved, though it will take a few
more years to drain the wifi driver swamp.  Dave Taht and I, however, have
successful teleconferences over 5 hop Babel based mesh networks (he in CA,
me in MA), so time has moved on since homenet was started.  Meshes can and
will be over WiFi, despite the working group having ruled it out of scope
when homenet was formed.

o performance over mixed networks of WiFi and ethernet and other
technologies (e.g. power, trickle) will be commonplace, once we make it
easy to plug things in without configuration.

So details like whether it takes one message rather than two to distribute
routing information, and how often such messages must be exchanged, over
how much of the network is key to understanding the scaling of the network.

Transition strategy
-
Since I do not believe the world is static, and that there is much more to
learn in mesh networking, it seems likely we may face transition from one
generation of protocol to another, possibly sooner than we would like.
Similarly, HNCP may need a revision, for similar reasons. If we ignore such
protocol transitions, it is entirely possible homenet's work will be wasted.

Protocol evaluation
--
Therefore I think we need to dig into HNCP, and into Babel and ISIS to
understand the scaling and transition issues as we try to finish this up.
Both believed theoretical scaling of the protocols, along with as much real
data as we can get would be ideal.

A "zero configuration" system *will* get plugged together in unexpected
ways.  Making a syst

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Jim Gettys]

On Wed, Oct 29, 2014 at 8:05 AM, Ray Hunter  wrote:

>
>
> Fred Baker (fred) wrote:
>
>> On Oct 28, 2014, at 11:28 PM, David Lamparter  wrote:
>>
>>  What I'm personally wondering most in this regard is: to what extent
>>> will larger networks deploy multiple prefixes to the hosts?
>>>
>>
>> Well, define “larger”. Any network that gets a PI prefix is unlikely to
>> deploy multiple prefixes. The question is at what size network is makes
>> sense to obtain an AS number and a PI prefix, and use BGP to talk with
>> one’s upstream.
>>
> I don't agree with this statement for the following reasons.
>
> Availability: There are many enterprises that have very numerous far-flung
> sales-office type locations which do not host any critical data or
> applications, but which could benefit from higher availability than that
> provided by a single ISP provider (some of which are currently served by a
> specialised box offering a Very Small Office Service running dual IPSec
> tunnels to a central site, which then performs the break out to the
> corporate intranet/Internet)
>

​
​
​And we are now deploying home networks that are being used for home health
medical monitoring; having full fail-over to another ISP is in the process
of becoming a "life" issue​.
​
​


>
> Latency: There are many sites which could benefit from local Internet
> breakout to regional cloud services, where you don't want to suffer the
> latency associated with a back haul from an office in Australia to a
> regional hub in Hong Kong, or even East coast US to West coast US and back.
> You'd still also want some back up via the central breakout if the local
> breakout failed.
>
> Cost: There are cost savings to be made in many countries where private
> network services are still many orders of magnitude more expensive than
> plain old Internet. So Internet offload for non-mission-critical traffic
> can be very attractive. If you could achieve this via direct host-server
> connections using address selection rules or multipath TCP; rather than via
> PBR, GRE tunnels + NAT, that would be a lot simpler.

​

>
>
>Wherever that boundary is, below that networks will use PA prefixes.
>> The question then becomes: will they multi home?
>>
>> And I think the answer today is that we don’t know the answer.
>>
> This I agree with.


​Ditto.  Though I have a personal opinion that they will... How else can
you be able to test that things are actually going to "work" in the face of
loss of one ISP? Anything not being tested on an ongoing basis is unlikely
to work in the case of failure.  If availability really matters, you care...

Jim

​


>
>
>
> --
> Regards,
> RayH
>
>
> ___
> 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

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Wed, Aug 14, 2013 at 11:20 AM, Michael Thomas  wrote:

> On 08/14/2013 08:03 AM, Jim Gettys wrote:
>
>>
>> The one I've measured consumes of order 5W, IIRC (WNRD3700v2).  As noted,
>> this is a 600Mhz SOC MIPS architecture (Atheros).  This is now about 2
>> years old: more recent routers are yet higher performance. Relative to what
>> you are used to on a desktop, the biggest performance differences are
>> caused by having a small cache (making many interpreted languages
>> relatively slow).  Even so, it's much faster than most desktops/servers
>> were not all that long ago, for integer codes.
>>
>> I believe the power consumption is often dominated by the 1G ethernet
>> ports; a 1ghz SOC is only around 1W power consumption.  Each ethernet port
>> can consume significant power.  If you use a USB port, it can also consume
>> power (up to 2W).
>>
>> The WiFi may account for a watt or so of the consumption (it turns out
>> that transmit and receive typically consume comparable amounts of power;
>> the transmit power isn't significant relative to the power consumed by the
>> signal processing that is done on receive).  The WiFi devices in handheld
>> devices may be somewhat more efficient (but also poorer performance: it
>> pays to have a good radio in the router, where power is easy to come by.).
>>
>>
> Thanks for the stats, Jim. Having worked on both iphone and android apps,
> it is
> *maddeningly* difficult to be a good battery citizen. There is no
> instrumentation
> last I looked to determine things like "If you transmit n bytes, typical
> battery use
> will be m mw at distance X" or "if you turn on this sensor at rate x, you
> can expect
> it to consume y mw", etc. I wish the Google and Apple would do something
> more
> than just being a scold ("don't use those features!") and forcing
> developers to put
> inane disclaimers in their product descriptions. If they really wanted good
> battery performance, they'd provide the OS level reporting that is
> necessary to
> make good decisions. Like, oh say, "Golly it takes a lot of juice to get
> to that tower,
> maybe I'll back off!"
>
> And of course this isn't just phones, it's anything with a battery.
>
>
My knowledge of power consumption is a bit dated on WiFi: I had to live and
breathe power consumption on battery devices when working on OLPC 5-6 years
ago.  It may be considerably lower at this date (probably is) on WiFi
devices used primarily for handhelds. Someone with current data would be
helpful to chime in here.

On the OLPC, we had a autonomous processor (a very low power ARM 9, IIRC),
four packet buffers, and the device could forward packets in the mesh
network without requiring the main processor to be involved at all. That
module consumed somewhere between .5 and 1W, IIRC.  Actual numbers are
someplace in the OLPC Wiki...  Transmit & receive power were roughly
comparable.

The big headache about WiFi is the current need to leave the receiver
powered up (taking the signal processing power hit).  And, of course,
most handhelds don't have another CPU to do the packet forwarding (so you'd
need to wake up the CPU to forward any packets).  It ought to be the case
that you'd not have to listen at all times (and I think there are
unimplemented 802.11 features to do so), but in practice, the last I knew,
you had to always be listening, so the power consumption was continuous.

The other major headache is trying to reduce unnecessary wakeups to the
main CPU (and when you do, take care of as much business as you can).
 IIRC, we got the wakeup rate down to order of 10's/second. I know Linux
has improved quite a bit in this area over this period; dunno what the
current state of the art is.
 - Jim





> __**_
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Mon, Aug 12, 2013 at 5:40 AM, Mikael Abrahamsson wrote:

> On Mon, 12 Aug 2013, Teco Boot wrote:
>
>  Joel Jaeggli mentioned the forwarding performance. Today's homenets are
>> mainly single subnet with link-speed forwarding between (gig) ethernet
>> ports, in hardware. L3 forwarding in software with single uplink or WiFi
>> port at near to gig speed is doable. Forwarding in software on all ports
>> require a new generation of low power and cheap CPU, I think. So probably
>> use hardware forwarding as much as possible?
>>
>
> Hardware assisted forwarding might be problematic due to us deciding on
> new functionality (source based routing for instance). I've read that in
> some routers the forwarding is done by microcode implemented by the
> hardware manufacturer, hindering the integrator (who buys the SoC in bulk)
> from doing what might be needed.
>
> So yes, forwarding performance is a concern, at least when we're talking
> above 100 megabit/s.
>

Actually, I think (Dave Taht can tell us with data), that forwarding
performance is fine even on today's routers up to 300-400Mbps on the
WNDR3800 running CeroWrt (which routes, rather than bridging between
interfaces)..  The 600Mhz MIPS can't saturate a gigabit ethernet, however
(at least not without using lots of hardware offload on the ethernet
controller, which hurts latency and creates
other problems (packet bursts).

But as SOC's are increasing in speed while the price goes down...

>
> I also think it would be beneficial if we could figure out as soon as
> possible what the requirements are on the forwarding plane, writing this
> down, so that hardware designers can avoid putting functionality into
> hardware that won't do what we need going fo
> r
> ward.


Hardware "assists", e.g. TSO, and GSO, are a problem, particularly in the
home.  You don't want line rate bursts going onto your WiFi (though
fq_codel helps that quite a bit, it's still evil).


>
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
> __**_
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Mon, Aug 12, 2013 at 10:44 AM, Howard, Lee wrote:

>
>
> On 8/12/13 7:03 AM, "Henning Rogge" 
> wrote:
>
> >On 08/12/2013 11:40 AM, Mikael Abrahamsson wrote:
> >> On Mon, 12 Aug 2013, Teco Boot wrote:
> >>
> >>> Joel Jaeggli mentioned the forwarding performance. Today's homenets
> >>> are mainly single subnet with link-speed forwarding between (gig)
> >>> ethernet ports, in hardware. L3 forwarding in software with single
> >>> uplink or WiFi port at near to gig speed is doable. Forwarding in
> >>> software on all ports require a new generation of low power and cheap
> >>> CPU, I think. So probably use hardware forwarding as much as possible?
> >>
> >> Hardware assisted forwarding might be problematic due to us deciding on
> >> new functionality (source based routing for instance). I've read that in
> >> some routers the forwarding is done by microcode implemented by the
> >> hardware manufacturer, hindering the integrator (who buys the SoC in
> >> bulk) from doing what might be needed.
> >>
> >> So yes, forwarding performance is a concern, at least when we're talking
> >> above 100 megabit/s.
> >>
> >> I also think it would be beneficial if we could figure out as soon as
> >> possible what the requirements are on the forwarding plane, writing this
> >> down, so that hardware designers can avoid putting functionality into
> >> hardware that won't do what we need going forward.
> >
> >I agree, software forwarding should be the standard way. That makes it
> >also more easy to adapt different routing protocols to HOMENET.
>
>
> You guys are trying to hard to engineer products.  Figure out what it
> should do and how, and let implementers implement it.  If you need
> implementers to tell you how to do it, let's get more of them in here.
>

Yup.  People here should have a bit of faith in Moore's law.   These are
real computers, and nothing I've seen is very difficult.

 And most of this stuff is already running fine in OpenWrt/CeroWrt as
existence proof of viability.

I do urge everyone to get their hands dirty, of course.

Then you'd be discovering things like:
   1) to deploy DNSSEC, you need to securely get time at boot time from the
network.
   2) to deploy DNSSEC, you need enough randomness in the entropy pool to
generate the self-signed certs when you do the initial installation.

(both these examples are very real, and Homenet should ensure these get
fixed).

Rather than worrying so much about whether the routers can do what you
need, you'll be finding the real issues that need to be solved.
- Jim


> Lee
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Mon, Aug 12, 2013 at 4:44 AM, Mikael Abrahamsson wrote:

> On Mon, 12 Aug 2013, Henning Rogge wrote:
>
>  Personally I like the way CODEC WG approached this, by making a
>>> reference implementation available in source code in the standard. This
>>> is probably not practical for a complete homenet router,
>>>
>>
>> Why? A "homenet" package (most likely multiple packages) for OpenWRT as a
>> reference implementation would be a great thing.
>>
>
> Well, I meant publishing the source code in the RFC text. I believe *WRT
> style implementation freely available is a great idea of course.
>
>
>  And it might give consumers the chance to get a router with a reasonable
>> modern linux.
>>
>
> Exactly. I'm running CeroWRT on a WNDR3800 that I bought refurbished for
> 70USD. My hope is that in a few years when homenet is "done" this kind of
> device will be generally available at a lower price point new and available
> to everyone.
> 
>
>
The 3800 costs what it does in part due to having two radios (2.4 and
5ghz).  A single radio router would be cheaper (but not interesting for a
mesh network, due to 1/N performance with number of hops).


> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
> __**_
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Thu, Aug 8, 2013 at 4:54 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 09/08/2013 01:21, Olafur Gudmundsson wrote:
>
> > Moral: do not constrain homenet requirements by yesterdays devices.
>
> Fair enough (after all, the IPv6 design is great for an end-of-era
> minicomputer).
>
> However, today's devices are overwhelmingly battery-powered, so even
> if compute power and memory are not the issues, electricity matters.
>

Your home router is not battery powered (except for if you run it off a
battery back up system).

The one I've measured consumes of order 5W, IIRC (WNRD3700v2).  As noted,
this is a 600Mhz SOC MIPS architecture (Atheros).  This is now about 2
years old: more recent routers are yet higher performance. Relative to what
you are used to on a desktop, the biggest performance differences are
caused by having a small cache (making many interpreted languages
relatively slow).  Even so, it's much faster than most desktops/servers
were not all that long ago, for integer codes.

I believe the power consumption is often dominated by the 1G ethernet
ports; a 1ghz SOC is only around 1W power consumption.  Each ethernet port
can consume significant power.  If you use a USB port, it can also consume
power (up to 2W).

The WiFi may account for a watt or so of the consumption (it turns out that
transmit and receive typically consume comparable amounts of power; the
transmit power isn't significant relative to the power consumed by the
signal processing that is done on receive).  The WiFi devices in handheld
devices may be somewhat more efficient (but also poorer performance: it
pays to have a good radio in the router, where power is easy to come by.).

- Jim





>Brian
> ___
> 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

Re: [homenet] draft-chroboczek-homenet-configuration-separate-00

[Jim Gettys]

On Tue, Jul 2, 2013 at 10:46 PM, Joel M. Halpern wrote:

> Actually, it seems to me that if we even want to be able to consider other
> routing protocols, our job will be much easier, and the architecture much
> cleaner, if we do not couple the configuration distribution problem to the
> routing protocol problem.
>
> If we are sure we will pick the right answer to the routing problem, then
> sure, use that for all our needs.
>
> I know how much confidence I have in my ability to make this call.
>


I will note that I raised my concerns about coupling configuration to
routing (since I foresee routing needing to evolve) last year (or was it
the year before?), and it fell on deaf ears.

This concern about coupling configuration and routing is an *architectural*
issue, and the time to capture architectural concerns is *now* as work on
that is finishing up.  As to what routing or configuration protocol, I have
no horse in either race.
  - Jim


> Yours,
> Joel
>
>
> On 7/2/2013 10:39 PM, Ted Lemon wrote:
>
>> On Jul 2, 2013, at 10:14 PM, Ted Lemon  wrote:
>>
>>> Normally we just discuss the arguments for and against on the
>>> mailing list, rather than publishing drafts. The points you make in
>>> favor of your position are vacuous—essentially, they are just your
>>> opinions, stated in an organized manner.   As a working group
>>> participant, not an AD, I don't think this draft contributes
>>> anything to the discussion.
>>>
>>
>> Sorry, I realized when I read this back that it was really harsh.   I
>> think the work you guys have done on Babel is good work—the point of
>> saying this is not to say that Babel is a bad idea, or shouldn't be
>> considered.   It's that the way we should consider it is by comparing
>> it point by point against the alternatives on a technical basis.
>>
>> The considerations you've raised here are not inconsequential—they're
>> just not what I would consider to be first-order considerations.
>> They are more considerations that we might use in choosing between
>> two solutions that were otherwise equally good.
>>
>> __**_ 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

Re: [homenet] draft-chroboczek-homenet-configuration-separate-00

[Jim Gettys]

On Wed, Jul 3, 2013 at 9:43 AM, Ted Lemon  wrote:

> On Jul 3, 2013, at 9:22 AM, Juliusz Chroboczek <
> j...@pps.univ-paris-diderot.fr> wrote:
> > May I assume that you and other interested parties have read
> > draft-chroboczek-ahcp-00?
>
> I found the description of the architecture frustratingly brief, and I
> have not read the document in detail because of that.
>
> > What I fear is that if I present AHCP, people will think that I'm
> > pushing AHCP in its current form rather than as a basis for future
> > work, and positions will cristallise prematurely.
>
> I think that's a reasonable fear, but you don't have to present AHCP—you
> can just present an architecture.  The difference between this and the
> current architecture document would be that yours would be really specific.
>   This sort of thing is a really useful exercise, because when you try to
> clearly express what it is that you think should be done, you are forced to
> think through the details, and suddenly things that weren't fleshed out in
> previous versions of the protocol become clear.
>
> I've never seen an IETF working group shy about "improving" a protocol
being worked on in that group; rather the reverse, particularly if
shortcomings of an existing protocol are pointed out.

Generally, it's designs done *without* existence proofs that go wrong, go
wrong, go wrong...
 - Jim

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

Re: [homenet] Configuration must not be carried by the routing protocol

[Jim Gettys]

On Wed, Jun 26, 2013 at 2:24 PM, Michael Thomas  wrote:

> On 06/26/2013 11:22 AM, David R Oran wrote:
>
>> On Jun 26, 2013, at 1:46 PM, Michael Thomas  wrote:
>>
>>  On 06/26/2013 10:42 AM, Mark Townsley wrote:
>>>
 On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote:

  On Jun 26, 2013, at 4:08 AM, Mark Townsley  wrote:
>
>> That explicit statement went away in RFC 3315, though the terminology
>> section makes it very clear that a Host is not a Router.
>>
> DHCPv6 PD is explicitly for configuring routers, so I think this
> assertion is wrong.
>
 This was linked back to the assertion that "the IETF has a
 configuration protocol, it is DHCP" or some such. I was simply trying to
 point out what "the IETF" has on record in this regard.

 Certainly, we often use protocols beyond their original intent. RFC
 5218 calls this "Wild Success", with plenty of examples.

 DHCPv6 PD has been referred to by one of its co-authors as "a Fax
 replacement", so that the user doesn't have to type in his prefix sent to
 him in printed form from his ISP. I think that analogy was given to sway
 anyone away from trying to rely on it for more than a very long-lived,
 essentially static, value from an ISP.

  Isn't a Somebody's-Law that states that "every successful protocol
>>> will become a
>>> transport protocol for something else”?Yup. I claim
>>>
>>>  Yup - I claim to have coined that one.
>>
>>
> Heh -- I definitely heard it from you first :)
>
>
>
And it's s true, though I managed to discourage using X protocol as an
RPC framework, back in the day.

Unfortunately, no success with HTTP :-(.
   - Jim

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

Re: [homenet] draft-ietf-homenet-arch comments

[Jim Gettys]

On Mon, Jun 24, 2013 at 3:58 PM, Henning Rogge wrote:

> On Mon, Jun 24, 2013 at 8:11 PM, Juliusz Chroboczek
>  wrote:
> > Please use "throughput" rather than "bandwidth".  The latter has
> > a precise technical meaning.
>
> I agree... as soon as you meet someone specialized in radio
> technology, Bandwidth will be something measured in Hertz.
>

I'm happy with that correction and will try to do likewise when I write
other items.

We have to get away from conflating "speed", with throughput or bandwidth,
however: that is where we've gone wrong in the past.

Speed is how "fast" something is for a user; for most applications, latency
rather than throughput dominates performance in today's Internet.  Unless
all you care about is downloading your next episode of "Game of Thrones"
;-)
- Jim


>
> Henning Rogge
>
>
> --
> We began as wanderers, and we are wanderers still. We have lingered
> long enough on the shores of the cosmic ocean. We are ready at last to
> set sail for the stars - Carl Sagan
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch

[Jim Gettys]

On Mon, Jun 24, 2013 at 11:30 AM, Acee Lindem wrote:

>
>  On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote:
>
>
>
>
> On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon  wrote:
>
>> On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek <
>> j...@pps.univ-paris-diderot.fr> wrote:
>> > Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the
>> > same link, but the normal nodes need to renumber (and hence lose all
>> > TCP sessions) when they switch links.  If you prefer, your network can
>> > evolve: you can use unmodified ("homenet-compatible") nodes on the
>> > homenet, but using modified ("homenet-aware") nodes you get extra
>> > functionality.
>>
>>  I don't think this is the right direction to go.   Requiring some kind
>> of mobility stack on the host isn't something that I can see getting any
>> significant market penetration in the general-purpose host environment.
>> It's fine for service provider environments where the service provider has
>> some leverage to make special requirements on the host, and it's fine for
>> environments like public metropolitan wireless where there's a strong
>> incentive for adventurous people to install the software, but the homenet
>> environment isn't that.
>>
>
>  Ted,
>
>  Right now, we have a  much bigger problem getting shipment of updated
> routers with anything that homenet may recommend at all; getting code on
> host operating systems is easier to do than getting router support
> deployed.  I wish this weren't true, but it is.  If we aren't being
> slightly optimistic, what are we doing spending our time on this mailing
> list?
>
>
>
>  Jim - I'm not going to debate with you what is harder ;^) However, a
> requirement from the start of the Homenet WG is that we minimize changes to
> host software with the goal being none.
>

>  Thanks,
> Acee
>

As I currently run a small mesh (of two nodes) in my house, using Juliusz's
babel protocol, and have not bothered to install the daemon that would be
required for me to roam between them (ahcpd, IIRC), I will note that in
practice, in a real home network, no upgrade is *required*.  The web's
abuse of TCP has assured most people won't notice.

That it would be better if I bothered to install the code, I do not doubt.

   - Jim


>
>
>  So if an approach has real value (and doesn't require a lot of kernel
> dependent changes to support; we ain't going to do IPv8!), by the time the
> routers ship, we can arrange to have host support.
>
>  I must therefore disagree (given that Juliusz has running code which is
> not kernel intrusive today).
>
>  Dismissing such options out of hand even before any analysis is done is
> therefore a mistake.
> - Jim
>
>
>
>
>> ___
>> 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

Re: [homenet] draft-ietf-homenet-arch comments

[Jim Gettys]

On Fri, Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> > if it turns out to be multicast specific it could go in 3.5.1.
> > if there are more general issues to consider then perhaps a new
> sub-section?
>
> No, I think it's more general.  What about something like the following:
>
>
> 
> Homenets tend to grow organically over many years, and a homenet
>   will typically be built over link-layer technologies from different
>   generations.  Current homenets typically use links ranging from
>   1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed
>   discrepancy.  We expect this discrepancy to get worse as both
>   high-speed and low-power technogies are deployed.
>
>   Homenet protocols should be designed to deal well with
>   interconnecting links of very different speeds.  In particular,
>   flows local to a link should not be flooded throughout the homenet,
>   even when sent over multicast, and, whenever possible, the homenet
>   protocols should be able to choose the faster links and avoid the
>   slower ones.
>

Here's a version derived from Juliusz's try.  I also substitute
"bandwidth" for "speed", as
being sloppy about the language has tended to get us into the bufferbloat
mess.
   - Jim


Homenets tend to grow organically over many years, and a homenet
will typically be built over link-layer technologies from different
generations.  Current homenets typically use links ranging from
1Mbit/s up to 1Gbit/s, which is a three orders of magnitude bandwidth
discrepancy.  We expect this discrepancy to widen further as both
high-speed and low-power technologies are deployed.

Homenet protocols should be designed to deal well with interconnecting
links of very different bandwidths.  In particular, flows local to a link
should
not be flooded throughout the homenet, even when sent over multicast,
and, whenever possible, the homenet protocols should be able to choose the
faster links and avoid the slower ones.

Links (particularly wireless links) may also have limited numbers of
transmit opportunities
(txops), and there is a clear trend driven by both power and downward
compatibility constraints
toward aggregation of packets into these limited txops while increasing
bandwidth.
Transmit opportunities may be your scarcest resource and therefore also
strongly limit
actual bandwidth available.

Therefore protocols that avoid being "chatty", do not require flooding, and
enable isolation
of traffic between subnets are preferable to those which burn scarce
resources.


>
> If you wish, I can add a sentence saying "This implies that a link-state
> protocol must be used in the homenet" ;-)
>
> -- Juliusz
> ___
> 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

Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch

[Jim Gettys]

On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon  wrote:

> On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek <
> j...@pps.univ-paris-diderot.fr> wrote:
> > Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the
> > same link, but the normal nodes need to renumber (and hence lose all
> > TCP sessions) when they switch links.  If you prefer, your network can
> > evolve: you can use unmodified ("homenet-compatible") nodes on the
> > homenet, but using modified ("homenet-aware") nodes you get extra
> > functionality.
>
> I don't think this is the right direction to go.   Requiring some kind of
> mobility stack on the host isn't something that I can see getting any
> significant market penetration in the general-purpose host environment.
> It's fine for service provider environments where the service provider has
> some leverage to make special requirements on the host, and it's fine for
> environments like public metropolitan wireless where there's a strong
> incentive for adventurous people to install the software, but the homenet
> environment isn't that.
>

Ted,

Right now, we have a  much bigger problem getting shipment of updated
routers with anything that homenet may recommend at all; getting code on
host operating systems is easier to do than getting router support
deployed.  I wish this weren't true, but it is.  If we aren't being
slightly optimistic, what are we doing spending our time on this mailing
list?

So if an approach has real value (and doesn't require a lot of kernel
dependent changes to support; we ain't going to do IPv8!), by the time the
routers ship, we can arrange to have host support.

I must therefore disagree (given that Juliusz has running code which is not
kernel intrusive today).

Dismissing such options out of hand even before any analysis is done is
therefore a mistake.
- Jim





>
> ___
> 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

Re: [homenet] draft-ietf-homenet-arch comments

[Jim Gettys]

On Fri, Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> > if it turns out to be multicast specific it could go in 3.5.1.
> > if there are more general issues to consider then perhaps a new
> sub-section?
>
> No, I think it's more general.  What about something like the following:
>
>   Homenets tend to grow organically over many years, and a homenet
>   will typically be built over link-layer technologies from different
>   generations.  Current homenets typically use links ranging from
>   1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed
>   discrepancy.  We expect this discrepancy to get worse as both
>   high-speed and low-power technogies are deployed.
>
>   Homenet protocols should be designed to deal well with
>   interconnecting links of very different speeds.  In particular,
>   flows local to a link should not be flooded throughout the homenet,
>   even when sent over multicast, and, whenever possible, the homenet
>   protocols should be able to choose the faster links and avoid the
>   slower ones.
>
> If you wish, I can add a sentence saying "This implies that a link-state
> protocol must be used in the homenet" ;-)
>

I'll stay out of the routing discussion

But I'd like to point out that the problems we're already facing are not
just multicast, as Dave Taht has educated me recently  The scarcest
resource can often now be "transmit-opportunities", or txopts; certainly
this is true for WiFi (you get around 1000/second, and that's it...).

So anything that causes packets to require their own txopt for
transmission makes them very expensive.  So, for example, whether it is
even wise to use the hardware priority queues WiFi nominally has (even if
they work correctly) at all is questionable; under a loaded network,
bundling your voip traffic into the first available transmit opportunity
along with other traffic you have queued is clearly better than having to
burn an extra txopt to use the "feature" of the hardware queue, if no
further delay will be incurred by doing so.

Multicast is evil not only due to its inefficient use of the available
bandwidth, but because it forces use of a separate txopt for transmission.

The real point is we have several technological drivers toward wanting to
avoid the network being "chatty", and liking protocols that allow for
aggregation of packets when transmissions do occur.

I'm not sure I can easily express this in RFCese, however.
  - Jim


> -- Juliusz
> ___
> 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

Re: [homenet] elaboration on mdns difficulties

[Jim Gettys]

On Fri, Mar 29, 2013 at 2:35 PM, Michael Thomas  wrote:

> In the implementation slot there was a line item and a very brief
> description of the difficulties they were having with mdns. I don't
> know which drafts they were dealing with (I don't recall the slides
> mentioning it), so it's sort of a mystery to me about what they were
> seeing.
>
> Can somebody please elaborate more?
>

There are really two independent issues:


1) making mdns safe for a routed environment.  Avahi (the common open
source mdns implementation) is happy to bridge/vorward between networks,
but right now, the current implementation/protocol has issues with
topologies with loops.  So we have problems in CeroWrt today when running
3 routers in a mesh caused by loops.
2) bridging mdns properly to the global dns name space: you really don't
want grandma to be handing out .local addresses when that can/should be
avoided (and I guarantee that typing IPv6 literal addresses is something we
really all must avoid.

I think both problems are soluble, but believe we should demonstrate this
by running code rather than hand waving.
  And written spec's may be helpful, but running code is much more
important, I believe.
- Jim


>
>
> __**_
> 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

Re: [homenet] Why do homenets need SD?

[Jim Gettys]

On Tue, Mar 19, 2013 at 4:49 PM, Joe Touch  wrote:

>
>
> On 3/19/2013 1:25 PM, Michael Thomas wrote:
> ...
>
>  What I find most telling is that after 25 years, printers are still
>> the canonical example of the "need" for SD. But printers have entire
>> programs/wizards that support their existence, so they're really
>> lousy as a canonical example. It would be nice for things to attach
>> themselves to my net and not require their awful apps to be
>> installed.
>>
>
> Not much else has popped up widely yet as a "shared device that needs to
> be discovered". Network-attached storage held promise to be another
> example, until "the cloud" overtook the idea.
>
> There are plenty of other devices that are - or soon will be - useful to
> discover. E.g., thermostats, car chargers, etc. - the 'smart grid' stuff.


In my house, the inventory includes today:
 o two printers
 o TV set (via apple TV and Roku)
 o HiFi equipment (my new HiFi can be controlled via phone/tablet
applications; it also does streaming audio from various services)
 o I think my Blu-Ray player is also, but I've never tried.
 o Home routers (a mesh)
 o NAS box (clouds don't provide enough performance for most people, at
least yet).
 o web server on home router gateway
 o ssh services on a number of our laptops and the home server.

The following are also in the network, but are using remote web sites,
which I'm not very happy about; I'd prefer to keep these under my personal
control.
 o thermostats
 o scale

Most of these are Linux boxes under the covers (Linux dominates the CE
device space at this point); advertising a service is a trivial Avahi
configuration that it appears the mass market is already capable already of
usually doing the right thing to make services discoverable.

To make it concrete; some of the above devices are powered off atm, but
mdns-scan reports:
jg@jg-thinkpad:/var/log$ mdns-scan
+ jg-thinkpad [08:11:96:75:1d:94]._workstation._tcp.local
+ jg-thinkpad._udisks-ssh._tcp.local
+ andi-laptop [00:13:02:46:01:75]._workstation._tcp.local
+ Secure Shell on cerowrt._ssh._tcp.local
+ Web Server on cerowrt._http._tcp.local
+ Apple TV._airplay._tcp.local
+ 5855CA4A3092@Apple TV._raop._tcp.local
+ atom [90:fb:a6:85:d1:6c]._workstation._tcp.local
+ Officejet Pro L7590 [9D5AB9]._printer._tcp.local
+ Officejet Pro L7590 [9D5AB9]._http._tcp.local
+ Officejet Pro L7590 [9D5AB9]._pdl-datastream._tcp.local
Browsing ... /

What is more, it's pretty easy to configure avahi to announce services for
other devices if they don't themselves, not that I'm happy to have lots of
multicast traffic going forward.  *That* we need to tackle head-on, anyway.
 - Jim


>
>
> Joe
>
> __**_
> 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

Re: [homenet] prefix assignment on home networks

[Jim Gettys]

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

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

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

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

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







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

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

Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).

[Jim Gettys]

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

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


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

  - Jim





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

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

[homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).

[Jim Gettys]

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

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

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

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


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

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

We should judge alternative proposals by this touchstone.
  - Jim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Look at ahcp: Was: Mixing DNS in with routing information

[Jim Gettys]

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-ietf-homenet-arch-04

[Jim Gettys]

On 09/24/2012 08:11 PM, Curtis Villamizar wrote:
> In message <5060bdc7.6020...@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.

It did dhcp on my network; evil.  Only had one ethernet port, IIRC.

>
>> 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.

My point is I don't like to depend on DHCP to get my addresses, as it
seems lots of people add them as a "feature" to this or that home
device, setting up for unhappy broken networks.

And it's really painful to debug when you can't even access the network
at all (which is the failure mode that was happening to me).
- Jim

>
> 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 i

Re: [homenet] draft-ietf-homenet-arch-04

[Jim Gettys]

On 09/24/2012 06:36 PM, Ted Lemon wrote:
> On Sep 24, 2012, at 4:08 PM, Jim Gettys  wrote:
>> This was by far the hardest debugging I've had to do in my home network
>> in normal operation.
> In all fairness, the exact same kind of brokenness can happen with rogue RA 
> messages, and a non-geek will have an equally hard time diagnosing it.

The worst of this was that the little box was much slower than my
regular dhcp server, so it was like a 20% failure rate.

Sigh.

Be that as it may, relying on dhcp to get addresses strikes me as much
more error prone.

- Jim

>
> ___
> 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

Re: [homenet] draft-ietf-homenet-arch-04

[Jim Gettys]

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).
>
> 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.

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.

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



- Jim

>
> 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.3030...@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.

Re: [homenet] tunnels as way to disambiguate .local

[Jim Gettys]

On 08/07/2012 03:54 PM, Michael Richardson wrote:
>> "Michael" == Michael Thomas  writes:
> Michael> Just checking, but we all think that naming is a separate
> Michael> issue from reachability, right?
>
> It's separate.
>
> The question is: does the set of names you can resolve depend upon the
> connectivity that you have? (the "reachability")  
Yes.

>
> I think that this is a form of security through obscurity, and I'd
> rather that the various carriers who want to impose walled gardens on their
> video-over-3G-to-smartphone systems (causing changes up to the
> application layers) would do something different.
>
> I overheard a snippit of conversation last week from Lorenzo about what
> Android will be doing to "support" walled garden DNS.  I can't repeat
> it, because I didn't hear the answer...

Many corporations also hide internal names from the global DNS.  This
isn't just a carrier "thing".

It is possible to configure bind to "do the right thing" to query
different name servers in different part of the name space.  So it is
technically possible to set up name resolution to work when tunnels come
and go.

I take no position as to whether these corporations are sane about their
security policies, however.
- Jim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] #4: Use of ULAs - issues with RFC4193

[Jim Gettys]

I'd like to drag this back to Dave's points 1-4.  There are real
implementation issues with RFC4193.  The questions are:
a) do these problems matter?
b) if so, what do we do about them?

Note that true random bits are really hard to come by right now in
current home routers.  Sigh...  Anyone who knows any chip architects,
please beat them bloody until they provide a hardware RNG

So long as the addresses don't leak from the home network, and each home
router settles on unique addresses (maybe derived from their MAC
addresses), I'm not sure it matters.  But someone who has thought longer
and harder about ULA's should think about the issues Dave's raising.
- Jim


On 03/27/2012 04:21 PM, Dave Taht wrote:
>
>
> On Tue, Mar 27, 2012 at 1:01 PM, Jari Arkko  > wrote:
>
> I fully agree with these comments from Ray. Basically, when
> hardware changes on some router it is pretty much given that some
> address will change somewhere. And I don't think fully stable
> addressing is a good goal to begin with. Make the devices survive
> addressing changes, and we'll be fine.
>
> Initial ULA generation before any connectivity with the Internet
> can be reached is fine, however.
>
>
> While I agree that having a ULA at the getgo is a goodness, following
> RFC4193 to the letter is very difficult.
>
> 1) You need time. If you do not have a battery backed up clock in the
> device (set to an appropriate value), you need to get time from the
> internet, which you can't do until you are on the internet.
>
> Or you could mandate time come from a gps.
>
> If you are getting time from the internet, you need sntp, ntp, or
> equivalent. From gps, something like chronyd.
>
> Without this, generating the ULA is generally going to come from 'time
> since the epoch or build date', and other sorts of randomness would be
> useful.
>
> 2) The infrastructure mandated by that RFC requires a sha-1 digest.
> Many devices (at least at present) do not come with a SSL based
> infrastructure from which that is a single function thereof.
>
> 3) It is my hope that hardware based RNGs start showing up soon in
> many more devices. But thus far, no luck, so finding an essential
> source of randomness would be good.
>
> 4) Lastly, without a solid means of getting the ULA and a human usable
> name out to the users's dns system (be that mdns, normal dns, etc),
> there is no way to map the idea of that number to a presentation that
> a user can 'just use'. I could be humorous about this (As april 1st is
> coming up) - flashing the blinking lights on a switch or router in
> baudot code might suffice for some, but...
>  
>
> Jari
>
>
> On 22.03.2012 14:49, Ray Hunter wrote:
>
> As requested by Tim: My comments on ULA use in Homenet posted
> in consolidated manner to the issue tracker.
>
> I think Homenet still has a lot of work to do, especially due
> to the autoconfig requirements.
>
> Everyone wants autoconfig.
>
> Concurrent ULA + PA + both with autoconfig + invariant
> addresses is likely going to be tough, if not downright
> impossible.
>
> So why do we think we really need concurrent ULA+PA in Homenet
> as a base requirement? I'm not entirely convinced yet.
>
>
> Issue 1: One reason ULA seems to be mentioned is
> "time-invariance of addressing for use by sensor networks."
>
> Using the example of an electrician setting up a sensor
> network in a home before an ISP is present, and expecting
> time-invariant ULA addresses. Firstly, the electrician would
> have to generate a Global ID for ULA when the lights are
> installed. The electrician can generate a  unique Global ID
> (and hence the /48 prefix of ULA) using the procedure in RFC4193.
>
> Problems with this are:
> 1) The /48 ULA prefix is tied to a time (when the electrician
> pressed the "generate ULA" button)
> If a user regenerates the ULA prefix later, the algorithm will
> generate a different /48 prefix: all addresses in the house
> will change
>
> 2) The /48 ULA prefix is tied to a MAC address (of the router
> or device used to seed the ULA prefix generation algorithm)
> If a user changes router hardware, the /48 prefix will change.
> Or else the seed stored in non-volatile memory will be lost
> when hardware is replaced. Again all addresses in the house
> will change
>
> 3) The Global ID portion of the ULA has to be manually
> assigned to each of the routers (if there's more than one) as
> there's no mechanism to distribute Global IDs today.
> Homenet needs autoconfiguration.
>
> 4) Even if the /48 prefix is made invariant, the /64 LAN
> prefix generated from it probably won't be invariant as
> hardware is ad

Re: [homenet] Security goals

[Jim Gettys]

I'd like to get away from the worshipping of end-to-end (which I
genuflect at that altar as much as anyone), and bring it back to reality
slightly, amplifying a bit on some bits I've seen in parts of this long
thread.  I think Stuart Chesire pointed out remotely in the Philadelphia
ftf meeting that attack surface is a real issue, and I think it is a
rapidly growing issue.

Here's reality:

o the number of devices has been growing exponentially in people's
houses: first it was one machine, then one/person, and now it's the
TV(s), BluRay player(s) phones, NAS boxes, TiVO, Roku Box, Apple TV, and
often more than one computer/person, IP camera(s), thermostat(s) (I just
ordered a Nest to play with), printers, etc. This is the concrete
example of my house, but even the grandparent's house I visit isn't that
far behind, with around 3 laptops and a TiVO and a printer.

More and more of these devices are "legacy" devices already that sit and
rot without software updates (concrete example: the NAS box I have which
hasn't seen a software update now in about 3 years).  This is a huge
problem, but not one this working group can undertake.  Certainly the
consumer electronics Linux efforts are trying to help this problem via
the Linux foundation efforts.

But I don't think this problem is going to go away, and certainly not in
my lifetime.  Even if rotting hardware didn't exist, and it all had the
right UI's to let you control its access, you're asking the poor home
manager to learn the management UI on all devices just to ensure the
right policies are in case: this means there is essentially *zero*
chance of succeeding.

o there are certain policies I really want to enforce: the one that Dave
Taht and I ran into last week installing the latest CeroWrt was the
following: to ensure that Microsoft file services were *not* accessible
by default to the outside; we had a bug that it was accessible via IPv6.

My reasoning is the following:  the RIAA would like me to legally liable
for accidental sharing of my CD collection that I've digitised.  So I
really want to prevent this accidental sharing of a misconfigured laptop
or NAS box; I really, really want to make sure it fails, so that my door
is not left "unlocked" by accident.  And there is lots of other personal
data I'd also not like to share.  So despite the fact that this is at
best a half-measure, when we detected that via IPv6 the default firewall
rules allowed such access on CeroWrt, Dave set it to deny, and I expect
that that is what most people will want/need.  In fact, for my NAS
device, I really want to ensure that *all* ports are blocked from
outside, since it's OS has been rotting and its attack surface grows
with almost every passing day.

So I'm not interested in default-deny in general; but I sure want to be
able to easily do deny-all or deny a particular service to particular
devices, or particularly insecure protocols to everyone (e.g. microsoft
file sharing).  For our general laptops, which are kept decently up to
date, I probably *do* want almost all ports open (with the exception
again of things like file sharing services, for the reason given above).

This is yet another example of the *primary* utility of firewalls;
reduce the attack surface, particularly to vulnerable systems, and  to
try to prevent things getting *out*, rather then coming in.  In my
example, I just want to be able to appear in court and say to the judge:
"my door was locked".  As a way of keeping things out: we know that
doesn't work in general; at most firewalls can reduce the attack surface
from the outside.

Ok, what have I been thinking about doing for CeroWrt, that is more nuanced?
==

I've been thinking about this problem a lot this week, as I need to put
time based controls to help my son control his game playing, have been
thinking about visibility of internal names to the global internet, and
how to ensure diffserv is handled properly (if the home gateway has no
controls over diffserv for users, then it will be gamed to uselessness
by applications/devices).  I'm writing this lengthy message in part as
it's helping me to make my thinking concrete.

I'm really not worried about someone using my printer from outside: I
suppose that they can waste some paper and toner, and if that becomes a
problem, I'll put other (per person) access control on it.  But for
printer devices, I'll want a policy that opens my IPv6 capable printer
to the world on some protocol, so I can easily print from anywhere. 
Since it's firmware is not frequently updated by HP, I probably want all
other ports "closed", just to reduce it's attack surface.  I don't know
if the printer has an internal firewall or not...

For actively maintained laptops/phones, I'll want a policy that allows
pretty much full access, with the exception of file sharing, where I'll
want my kids and wife to have to come see me to do anything out of the
ordinary (until we have file sharing pro

Re: [homenet] Name resolution in the homenet architecture document

[Jim Gettys]

On Mar 14, 2012, at 6:31 PM, Brian E Carpenter
 wrote:

> On 2012-03-15 10:36, Dave Taht wrote:
> ...
>> For reference, this is how to configure bind9 to not leak a private
>> .lan or .whatever to the roots.
>
> .lan isn't a very good choice IMHO, since it does not imply multiple
> segments and routing.

It doesn't have that binding in my mind.

We could try .han if you like: home area   network

Jim

>
> .whatever would be a good choice in so many ways :-)
>
> If we want something fairly neutral which isn't Anglocentric,
> how about .ici ("here" in French)?
>
>   Brian
>
>
> ___
> 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

Re: [homenet] Name resolution in the homenet architecture document

[Jim Gettys]

On 03/11/2012 01:25 PM, Ralph Droms wrote:
> Suppose that view is on a per-device basis rather than per server?
>
> With something like environment variables in front of "classic" DNS 
> resolution in the host resolver...

What's the use case for such complexity?  Otherwise, my answer is KISS...
- Jim


>
> - Ralph
>
> On Mar 11, 2012, at 11:43 AM 3/11/12, Jim Gettys wrote:
>
>> On 03/11/2012 11:25 AM, Ted Lemon wrote:
>>> On Mar 11, 2012, at 11:03 AM, Jim Gettys >> <mailto:j...@freedesktop.org>> wrote:
>>>> I think there is an interesting question of whether interior *names*
>>>> should be automatically published into the global DNS by default or
>>>> not,  which will depend on the security of the devices and systems and
>>>> the users' expertise, if only to make it a bit harder for attackers to
>>>> discover interior systems to attack (since with IPv6 finding them by
>>>> brute force address space search is relatively hard).
>>> Doesn't making the zone non-enumerable and disabling zone transfers
>>> address this problem?   I guess you could still do a dictionary attack
>>> on the zone and decrease the cost of the search somewhat in the usual
>>> case, but it's a pretty sketchy way to try to start an attack.  
>>> Having said that, I think it's probably fine to disable propagation of
>>> the zone by default, except that then we have to figure out what to
>>> name the non-propagated zone, and how to deal with the transition from
>>> non-propagated to propagated.
>>>
>> Had been thinking more along the line of the multiple "view" stuff in
>> bind; there would be/is already a public view, and then a private view
>> only visible internally.
>>- Jim
>>

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

Re: [homenet] Name resolution in the homenet architecture document

[Jim Gettys]

On 03/11/2012 11:25 AM, Ted Lemon wrote:
> On Mar 11, 2012, at 11:03 AM, Jim Gettys  <mailto:j...@freedesktop.org>> wrote:
>> I think there is an interesting question of whether interior *names*
>> should be automatically published into the global DNS by default or
>> not,  which will depend on the security of the devices and systems and
>> the users' expertise, if only to make it a bit harder for attackers to
>> discover interior systems to attack (since with IPv6 finding them by
>> brute force address space search is relatively hard).
>
> Doesn't making the zone non-enumerable and disabling zone transfers
> address this problem?   I guess you could still do a dictionary attack
> on the zone and decrease the cost of the search somewhat in the usual
> case, but it's a pretty sketchy way to try to start an attack.  
> Having said that, I think it's probably fine to disable propagation of
> the zone by default, except that then we have to figure out what to
> name the non-propagated zone, and how to deal with the transition from
> non-propagated to propagated.
>

Had been thinking more along the line of the multiple "view" stuff in
bind; there would be/is already a public view, and then a private view
only visible internally.
- Jim

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

Re: [homenet] Name resolution in the homenet architecture document

[Jim Gettys]

On 03/11/2012 09:53 AM, Ted Lemon wrote:
> On Mar 11, 2012, at 8:02 AM, Ralph Droms  > wrote:
>> This point is what I was trying to get at with my second bullet.
>>  Ted, who is the "you" in the "where you connected": the homenet, the
>> device, ???
>
> IOW, when a device is configured locally, how does that configuration
> propagate through the homenet gateway to the real world, when the
> gateway isn't necessarily connected when the device configures?
>
> My preferred answer is that the homenet gateway is authoritative for
> the zone that's being updated, and can process updates even when
> disconnected.   I realize that MDNS-style solutions are in some sense
> easier, but they don't give you a consistent name, so you wind up with
> the search list problem Ray is talking about.


That's exactly what we're trying to achieve with CeroWrt, with its use
of Bind (with both interior and exterior views).  (See bind a as a place
holder for "real fully featured DNS server" if you have some other
favourite; it's just that dnsmasq can't support this kind of vision at
the moment). Again, "running code" rather than assertion is what we'd
like here, though I think we're far enough along to be able to claim
this is feasible and desirable.  I see/hope that mDNS and uPNP become
legacy protocols in the long run; my previous mail on this topic is that
I am always concerned that there are transition strategies that really work.


>
> Of course, in this scenario, if the homenet is disconnected, a roaming
> device would be unable to update it until it reconnected.   I think
> this is probably okay.
As do I...
>
> I realize this is a bit more heavyweight than what some people have
> been talking about, and I'm not claiming they're wrong and I'm right;
> I'm just saying that this is how I would want my homenet to work, and
> I think it ties into the idea of end-to-end functionality for
> homenets, both internally and externally.
>
Exactly.  Care to help with the final piece of the CeroWrt demonstration
of this?  What's needed are two things:
1) some dhcp handshake with the upstream ISP provider to provide
the domain keys so that the domain can be delegated and the home router
become the authoritative for the delegated domain.
2) GUI work so that if the user has a domain of their own (or
the ISP does not/is incapable of delegation), you can get it hooked up
with your DNS provider; while we have bind all running fine, the GUI
work for configuring bind has lagged (I've been intending to do it, but
have been somewhat ill of late). Right now, the CeroWrt GUI is still for
configuring dnsmasq, which we don't use.

I think there is an interesting question of whether interior *names*
should be automatically published into the global DNS by default or
not,  which will depend on the security of the devices and systems and
the users' expertise, if only to make it a bit harder for attackers to
discover interior systems to attack (since with IPv6 finding them by
brute force address space search is relatively hard).

I suspect that it should default to "off", myself, if only because I
know I have boxes in my house that the vendors seldom if ever update the
firmware for, and I don't want them exposed.  Clearly, we have the
reality of many insecure devices mouldering in home environments, and
can't ignore this problem.
 Jim

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

Re: [homenet] Discovery [snmp for monitoring home network]

[Jim Gettys]

On 03/10/2012 06:53 PM, Brian E Carpenter wrote:
> Cutting to the chase (and this answers Don too):
>
>> There may be good reasons to consider SLP, but I'd
>> like to see how these line up against the home net goals.
> Exactly. It's perfectly fine by me if SLP is not the right
> answer for future homenets, but this should be a goal-based
> decision, not based on what happens to be deployed on
> single-subnet homenets today.

I agree Brian.

My concern is just figuring out if there are any practical issues in
already deployed discovery protocols (e.g. mDNS, uPnP) or wiggling
things we don't know about in a corner that will stand in the way of
making *real* home *networks*, that are actually networks, rather than
our current bridged disasters that people call home routers, but really
aren't... 

When there were discussions about routing versus bridging in homenet
early on, there was quite a bit of scepticism that routing can be made
to work without unforseen practical problems: we're trying to answer
that along the way in our CeroWrt work.  So far, thinks look ok. But I
believe first all in "running code", much more than hand-waving
- Jim
>
> Regards
>Brian
>
> On 2012-03-11 11:02, Kerry Lynn wrote:
>> On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter
>>  wrote:
>>> On 2012-03-10 08:42, Paul Duffy wrote:
>>>> On 3/9/2012 1:55 PM, Brian E Carpenter wrote:
>>>>> On 2012-03-10 05:00, Jim Gettys wrote:
>>>>> ...
>>>>>> I was just observing comments I came across in code being used for
>>>>>> printer discovery.
>>>>> Why would we consider anything other than SLP for service discovery?
>>>> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more
>>>> traction in the consumer space than SLP.
>>>>
>>>> Please do correct if I'm wrong.
>>> Aren't we trying to influence the future rather than document the
>>> past?
>>>
>> Brian,
>>
>> I'm not sure of your point; mDNS and DNS-SD are Standards Track
>> drafts currently in the RFC-Editor queue and there are tens of millions
>> of deployed mDNS responders.  If SLP is running in my home, I'm
>> not aware of it.
>>
>>> We need a name-based service discovery solution. That's also a
>>> requirement emerging from 6renum. I think we should decide what's
>>> the best recommendation; it may end up being DNS-based, but this
>>> is what SLP was designed for, so IMHO it should be considered.
>>>
>> Just as homenet has "Largest Possible Subnets", "Fewest Topology
>> Assumptions", and "Self Organizing" principles, perhaps we should
>> also consider "Fewest Protocols" as well.  To my mind, using DNS for
>> both service discovery and name resolution has many advantages.
>> These are documented in the above mentioned drafts, but I would
>> just point out three: simple DNS-based discovery is trivial to add to
>> an existing resolver, mDNS has been demonstrated in constrained
>> environments (e.g. it places limits on name length and character
>> set), and it is based on a well-understood (and well-supported)
>> protocol.  There may be good reasons to consider SLP, but I'd
>> like to see how these line up against the home net goals.
>>
>> I will add that I've co-authored a draft that considers extending mDNS
>> to site scope and would like to receive any comments people have:
>> https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/
>>
>> Thanks, -K-
>>
>>> This is clearly *not* what SNMP was designed for.
>>>
>>>   Brian
>>> ___
>>> 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

Re: [homenet] snmp for monitoring home network

[Jim Gettys]

On 03/09/2012 10:27 AM, David Harrington wrote:
> Hi,
>
> I am not sure what proposal you are referring to.
> I know multicast SNMP for discovery was proposed quite a few years ago,
> but multicast SNMP would depend on the non-secure nature of SNMPv1 and a
> well-known community string. This is at odds with the IETF declaring
> SNMPv1 Historic and not recommended.
>
> The multicast approach won't work with the built-in SNMPv3 security, and
> to my knowledge all effort to do this (at least in IETF) was dropped
> precipitously.
> Hopefully, nobody is seriously considering this approach again, if it
> builds on SNMPv1.

I was just observing comments I came across in code being used for
printer discovery. 

That doesn't mean SNMP multicast is actually used significantly; it's
mostly an example of another protocol that *could* cause trouble when we
route rather than bridge everything inside the home.  Having
(apparently) demonstrated (we hope) that mDNS doesn't really present a
major problem by implementation, I still have concerns if there are
other protocols that matter that we'll have to worry about to get rid of
the bridging horror we face today.

I have *no* information that makes me think it's a *real* problem as
yet, and see no way to do so before having running code in the hands of
probably thousands of testers.  At the moment, we have code in the
hands  of testers of the fingers on one or two hands More testers
would be welcome

I am encouraging everyone to think about potential problems that might
be caused by other multicast protocols that may be in use; knowing
sooner rather than later would be nice ;-).

And thanks for the details about SNMP, they are indeed reassuring.
- Jim

On 3/9/12 9:38 AM, "Jim Gettys"  wrote:
>> On 03/08/2012 11:42 PM, Livingood, Jason wrote:
>>> I think that E2E into the home for SNMP is perhaps one of the
>>> things that would motivate an ISP to support homenet.
>>>
>>>
>>> E2E network management and/or monitoring, yes. SNMP, at least on a
>>> public interface, maybe not so much. We may be entering a phase where
>>> ISPs consider blocking TCP/UDP 161.
>>>
>>> The reason is that SNMP is becoming more and more widely abused. I
>>> still have no idea why for example (1) some gear ships with public as
>>> the default string and the daemon running by default as such, (2) some
>>> gear does not present the user with an interface to turn off SNMP or
>>> change the community string at all (so you may be stuck with
>>> on/public). 
>>>
>>> So maybe on SNMP, tread carefully. ;-)
>>>
>> Just to make it clear, I was worrying about the possible use of
>> multicast to *discover* SNMP devices, and routing versus bridging where
>> the multicast packet might need forwarding to other networks in the
>> hime, not SNMP in general.  I had noted its possible use to *discover*
>> printers to initially configure them.
>>- Jim
>>
>> ___
>> 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

Re: [homenet] snmp for monitoring home network

[Jim Gettys]

On 03/08/2012 11:42 PM, Livingood, Jason wrote:
>
> I think that E2E into the home for SNMP is perhaps one of the
> things that would motivate an ISP to support homenet.
>
>
> E2E network management and/or monitoring, yes. SNMP, at least on a
> public interface, maybe not so much. We may be entering a phase where
> ISPs consider blocking TCP/UDP 161.  
>
> The reason is that SNMP is becoming more and more widely abused. I
> still have no idea why for example (1) some gear ships with public as
> the default string and the daemon running by default as such, (2) some
> gear does not present the user with an interface to turn off SNMP or
> change the community string at all (so you may be stuck with on/public). 
>
> So maybe on SNMP, tread carefully. ;-)
>
Just to make it clear, I was worrying about the possible use of
multicast to *discover* SNMP devices, and routing versus bridging where
the multicast packet might need forwarding to other networks in the
hime, not SNMP in general.  I had noted its possible use to *discover*
printers to initially configure them.
- Jim

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

Re: [homenet] snmp for monitoring home network

[Jim Gettys]

On 03/08/2012 03:34 PM, Michael Richardson wrote:
>> "Dave" == Dave Taht  writes:
> >> 
> >>Jim> I don't think that is the only place where we may have such
> >>Jim> issues; SNMP comes to mind, but I don't know how commonly that
> >>Jim> is used in home environments.  - Jim
> >> 
> >> SNMP is unused in home networks.
> >> I don't know why there is any issue with SNMP though.
> >> 
>
>

The specific worry is that when investigating why I couldn't see my home
printer, I came across a reference to the use of multicast SNMP possibly
being used for printer discovery.

I also remember there being a IPP multicast discovery "feature".

Again, I don't know if either of these are used much in practice,
whereas we know mDNS is used quite a lot.

It is wiggling worms like these that make me so convinced that "running
code" is the only way to find out what can actually be deployed.
- Jim

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

Re: [homenet] Home DNS server for homenet

[Jim Gettys]

On 03/07/2012 08:46 AM, Michael Richardson wrote:
>> "Mark" == Mark Andrews  writes:
> Mark> In message <19226.1331046...@marajade.sandelman.ca>, Michael 
> Richardson writes:
> >> > "Mark" == Mark Andrews  writes:
> Mark> A significant percentage of home machines will roam and those
> Mark> machines will need to be able to register their current
> Mark> address in the DNS.  I do this today when my Mac roams.  TSIG
> Mark> is unavoidable and cheap.  UPDATE itself is relatively cheap.
>
> >> Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith
> >> way to do key establishment so that TSIG can be initialized?
>
> Mark> For homes a shared key is fine or if you want a small database of
> Mark> keys.
>
> You didn't answer my question!  I wasn't asking for justification, I was
> asking for clarification of what you are proposing.
>
> I imagine a situation where one plugs into the homenet with your laptop.
> Some application/agent on the laptop realizes (via mDNS/Bonjour? via
> DCHP? TBD) that this network supports IPv6, and supports persistent
> names.  It asks you if you'd like to persist your name into the local
> zone.  It has an option to say, "make this name follow me"(%).
>
> There is a protocol exchange (TBD) with the designated homenet DNS
> server(s), and this establishes a TSIG for later use.  
> Same TSIG could also be used to update the reverse map, but as you
> indicate, TCP from the address you want to update is probably good
> enough for addresses considered "local".
>
> While this might seems bit out of scope for homenet (to provide names for
> laptops which are not at home), it's actually not.   Depending upon how
> the protocol works, it might be another way to deal with the
> mDNS/Bonjour-does-not-cross-link problem.   If the TSIG setup protocol
> can be mediated(proxied) in a link-layer attached way, then it might be
> that we do not need to make Bonjour cross links, as we can just use DNS.
>
> (%)-one need not have a globally reachable name.  One might be
> registering into .homenet/.lan/.local.  This may be for the
> benefit of machines which are still at home, and which need to
> find your laptop.  Or the home user might have a global DNS
> name. The difference is really just a matter of NS/DS records.
>
>

BTW, it appears Dave Taht has mDNS forwarding working between networks
in CeroWrt using Avah; but we need to do more testing.

I don't think that is the only place where we may have such issues; SNMP
comes to mind, but I don't know how commonly that is used in home
environments.
- Jim

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

Re: [homenet] Home DNS server for homenet

[Jim Gettys]

On 03/06/2012 01:49 PM, Dave Taht wrote:
>
>
> On Tue, Mar 6, 2012 at 10:23 AM, james woodyatt  > wrote:
>
> On Mar 6, 2012, at 07:15 , Michael Richardson  > wrote:
> > "Mark" == Mark Andrews mailto:ma...@isc.org>>
> writes:
> >Mark> A significant percentage of home machines will roam and
> those
> >Mark> machines will need to be able to register their current
> >Mark> address in the DNS.  I do this today when my Mac roams.
>  TSIG
> >Mark> is unavoidable and cheap.  UPDATE itself is relatively
> cheap.
> >
> > Are you asking for a link-local/mDNS-across-the-homenet
> leap-of-faith
> > way to do key establishment so that TSIG can be initialized?
>
>
> The alternative is to delegate all that business to 3rd parties
> with big data centers in the proverbial cloud.  Yes, that means
> that you're relying on Internet service to be constantly available
> to resolve service locations on your local home network, but it
> does seem to work reasonably well today.
>
>
> In some parts of the world, maybe, like california.
>
> Elsewhere, say in Nicaragua... not so much. I would personally prefer
> that those designing this stuff with *any* dependencies on centralized
> services spend some time doing research in south america, Libya,
> africa, eastern europe, the australian outback, and places like that...
>
>

Or Peru, or Uruguay, or Uganda, or (given my OLPC experience).

I have to emphasise what Dave's saying here: requiring centralised
services to work at all is really a non-starter, not to mention what
happens when things break in the developed world. 

What's more, in those parts of the world, they can't afford either the
reliable connectivity or expensive kit in schools/houses and often use
off the shelf commodity home routers even in places we'd probably do
something much better.  My point of view is to do it right in the home,
so everyone benefits at the low end.
- Jim

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

Re: [homenet] Home DNS server for homenet

[Jim Gettys]

On 03/02/2012 06:21 AM, fujiw...@jprs.co.jp wrote:
> Hello,
>
> I have an idea of home DNS server written in section 3.4.9 of
> homenet-arch-01.
>
> Home gateways (CPE) have a DNS proxy function,
> and all nodes in the network usually send DNS queries via the DNS proxy.
>
> My idea is to add authoritative DNS server function of local zone to
> home gateways.
>
> A home gateway serves one forward local zone and local reverse zones
> which the home gateway manage/offer by RA or DHCP.
>
> The authoritative DNS server function accepts DNS dynamic updates
> whose owner name is within the forward local zone and whose IP adress
> is within the IP addresses which the home gateway manages.
>
> When An end node starts, It gets IP/IPv6 address and DNS server
> information, DNS domain name prefix information from the home gateway.
> (option domain-name-servers and option domain-name in ISC dhcpd)
> option domain-name can be used to provide the local forward zone name.
>
> If the end node wants to register its name into home DNS server,
> it sends DNS dynamic update to the DNS servers which it got by DHCP.
>
> Clients can access the registered hostname using normal DNS lookup via
> the DNS proxy.
>
> There are many points to be cleared. But the idea may work well and
> it does not require new protocol and rewriting clients.
>
> It requires new home gateway (DNS proxy) and new dynamic update
> program used by home servers.
>
> If there are multiple subnets and multiple home gateways,
> DNS protocol has enough functions
> (relaying dynamic updates, zone transfers,...).
>
> I think the idea works for both IPv4 with NAT and IPv6.
>
> Does the idea work for homenet WG?
> Or already discussed ?
>
> If the idea is valuable, I will write a draft and sample DNS server.
>
>
Note that CeroWrt (a derivative of OpenWrt in which we are doing our
bufferbloat work) has a full Bind 9.9 implementation you can experiment
with today, and that this has been our intent from the beginning, both
to simplify naming for users, and to get a DNSSEC implementation.

A dnsmasq implementation would be welcome, for a couple reasons:
competition is good, and it would likely be a lot smaller than ISC Bind
is.  But code that exists and runs trumps code not yet ready for
primetime

We'd love to have some help to flesh this out properly; it needs
scripting support to get fully implemented the way we've envisioned it.

We don't currently use ISC DHCP, as it's currently (due to an
implementation crock being worked on) too big; there is a dibbler
implementation being shaken down.

See http://www.bufferbloat.net/projects/cerowrt
- Jim

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

Re: [homenet] Next steps

[Jim Gettys]

On 12/30/2011 09:23 AM, Michael Richardson wrote:
> It's not simpler. It just looks that way because layer-2 bridging
> seems ubiquitous and trivial to layer-3 people. The recent TRILL work
> at the IETF demonstrates the limitations of layer-2. The idea is to
> make things simpler, and layer-2+MSTP doesn't seem at all simpler to
> me. (and I've both designed such networks and written the code) But,
> you have simply replaced one routing table (layer-3, that includes
> source routing and loop detection) with another routing table
> (layer-2, that is flood with pruning, and no loop detection). 

And you really don't want random multicast traffic to pollute a wireless
network for which it is not intended (given the way 802.11 works, this
is a real headache).  A little multicast can ruin your whole day on
802.11; as the bandwidths have gone up, this problem has become
increasingly acute (since the transmission rate at which broadcast is
constrained hasn't).

Better to route than bridge; though the remaining question (which much
be answered) is if there are unintended dependencies on multicast that
cause grief.  The simple cases (e.g. mdns) aren't a problem; we have the
mdns forwarder code available.
- Jim


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

Re: [homenet] other routing options

[Jim Gettys]

On 12/01/2011 03:27 PM, Lorenzo Colitti wrote:
> On Mon, Nov 28, 2011 at 13:35, Brian E Carpenter
> mailto:brian.e.carpen...@gmail.com>> wrote:
>
> But I'm not sure I really understand the need for it. There's no
> shortage
> of IPv4 address space in homenets, because they are small and in
> RFC 1918 space. So if you are routing IPv6 in a home net, why not
> also route IPv4?
>
>
> Because the primitives that are available to you in IPv4 (essentially,
> NAT and DHCPv4) are different to the primitives available to you in
> IPv6. IPv6 allows you to do stuff like deprecate your default gateway
> and prefix, and to have multiple default gateways. IPv4 does not. So I
> suspect that when you look at things, you're not going to be able to
> route IPv4 reliably.
>
This mail serves as "running code" counter example.  CeroWrt routes IPv4
today, and I've been happy for months.

The questions around routing versus bridging are completely different
than that alleged: the issue is whether you can discover the services
you may need that are present on other networks on the home, e.g.
available via MDNS, or SMB, etc. There are implicit assumptions that
various gear has that everything may be in the same broadcast domain,
and that is exactly what we're trying to avoid by routing everything (as
wireless broadcast is an offence against humanity).  So we're still
shaking down problems that surface (e.g. by using mdnsresponder, and
seeing if we can get a wins server properly configured and the like. 
Whether there are any show-stoppers lurking, I do not yet know.

Since CeroWrt traffic was cluttering up the more general discussions on
bufferbloat, we just split those off. If you are interested, join the
mailing lists on CeroWrt.  See the attached mail.

Fundamentally, I personally believe anything this working group does
should be tested in running code before going anywhere in the standards
process.  Without running code, consensus will be hard to achieve.
Best regards,
Jim Gettys

--- Begin Message ---
I have created cerowrt-users, cerowrt-devel, and cerowrt-commits

mailing lists  on http://lists.bufferbloat.net

Please subscribe to one or more of those if the cerowrt test router subproject
 is your interest. I note also you can submit bug reports and comments directly
into the 'cerowrt' user on lists.bufferbloat.net and they will
automagically enter
the bug system there.

For now I plan to keep using the #bufferbloat channel for cerowrt support
unless that gets out of hand too.

I will periodically point out news of import regarding cerowrt and as relating
to bufferbloat to multiple lists here, but let's keep stuff that
mostly cerowrt and
not bloat related over there, ok?

If anyone has any other suggestions for useful lists to create, now is
the time to ask.

One of my thoughts was to resurrect the old lartc list, which
discussed user issues with
traffic shaping and control in particular. It was useful in it's
heyday and there seems
to be some market for the idea re-occurring.

There has been some talk of doing that
instead over on vger.kernel.org, and I'm cool with that, if it happens.

comments?

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
Bloat-devel mailing list
bloat-de...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat-devel
--- End Message ---
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] pervasive v4

[Jim Gettys]

On Nov 15, 2011, at 3:10 AM, Hans Liu  wrote:

> On Tue, Nov 15, 2011 at 1:42 PM, Lorenzo Colitti  wrote:
>> On Tue, Nov 15, 2011 at 09:42, Brian E Carpenter
>>  wrote:
>>> 
>>> If homenet is going to support arbitrary self-configuring topologies,
>>> and pervasive legacy IPv4 is required, we'd surely end up recommending
>>> NAT444-within-the-home as the only remotely practicable approach.
>> 
>> Hans from D-Link suggests that another option is simply to bridge IPv4
>> packets and route IPv6 packets.
> 
> To be very honest, if you have two D-Link router at home, you put one
> after another, it won't work today. I believe the problem is quite
> general a case to many NAT boxes today since they all share
> 192.168.0.0/24 or 192.168.1.0/24.  So what I told Lorenzo is that, in
> that case I would like to disable NAT and route IPv6.
> 

Some automatically switch addresses in this case.

Jim

> Regards,
> Hans
> ___
> 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

Re: [homenet] routing requirements

[Jim Gettys]

On 10/21/2011 02:53 PM, Don Sturek wrote:
> Hi Lee,
>
> I like this list of requirements!
>
> One thing:  if the requirements on routing to the internet using the 
> alternate prefix proves too complicated on a firewalled interface we should 
> defer that feature.
>
> Don
>
> Sent from T-Mobile G2 with Google
>
> "Howard, Lee"  wrote:
>
>> I've caught up on some 300 messages about routing.  Here are the 
>> requirements I've gleaned.  Question marks are unclear to me, please help.
>>
>>
>>
>> 1.  Homenet router requirements
>>
>> 2.  When evaluating a solution, discuss whether it provides for:
>>
>> 3.  Reachability between all nodes in the home network.
>>
>> a.   Links may be Ethernet, WiFi, MoCA, or any other; test all solutions 
>> against mutliple L2 types.
>>
>> 4.  Border detection.
>>
>> a.   Border may be upstream ISP, or may be a device that is a gateway to 
>> SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to 
>> home net.  Or there may be no border, if no external connection has been 
>> established.
>>
>> b.  Must be able to find "up" (a path to the Internet), but must not be 
>> dependent on "up" (Internet connectivity) existing for intra-home 
>> reachability.
>>
>> c.   May be discovered by routing protocol, or other means.
>>
>> 5.  Robust to routers being moved/added/removed/renumbered
>>
>> a.   Convergence time a few minutes or less.
>>
>> 6.  No configuration required.
>>
>> a.   We might tolerate? a single password being entered on each device.  
>> Discuss.
>>
>> 7.  Best-path is a non-requirement.
>>
>> 8.  Support for multiple upstream networks is a requirement.
>>
>> a.   Including wireless offload, video-only, and split-tunnel VPN 
>> scenarios.
>>
>> b.  With separate routers to each.  Not multihomed off the same router.
>>
>> c.   Prefix delegated from all ISPs (upstreams).
>>
>> d.  ISP A is default.
>>
>> e.   With only traffic destined to ISP B's prefix using that link.
>>
>> f.   With a backup default to ISP B, if desired.  What is default 
>> condition?
>>
>> g.  Source address selection is out of scope.  And should be solved by 
>> rfc3484, with longest prefix match (whether ULA or walled garden).  Choosing 
>> which address to use to look up the destination address is out of scope.
>>
>> 9.  Cannot assume hierarchical prefix delegation in the home (at least, 
>> not unless the WG develops such a solution).
>>
>> 10.  A host with mutliple upstream paths to the same destination should be 
>> able to use another in case on fails.
>>
>> 11.  Prevent looping.
>>
>> 12.  Prefix stability?
>>
>> 13.  Lightweight (cheap) implementation.
>>
>> Let me know if I've missed, or mistated, anything.

A couple missed: reference the scars on my back I discussed earlier:

Scalability analysis, both for the dense mesh case, and the non-dense case,

Behaviour/scaling when run on wireless, and its ability to handle both
wired and wireless links.

Robustness in the face of unintentional joining of networks.
- Jim


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

Re: [homenet] Thoughts about ipv6 routing (babel & AHCP)

[Jim Gettys]

On 10/20/2011 08:59 AM, Ole Troan wrote:
> Jim,
>
>> Yes, his data was taken just before/as Comcast put its relays into
>> production; it's not what we see on that network.  Before then, almost
>> all traffic went through some poor server in Wisconsin, as I remember. 
>> It sucked.
>>
>> There is a self fulfilling prophesy here: if no one has decentr elays,
>> then 6to4 is never usable, and then we should deprecate it.  If it is
>> deprecated, why should anyone put in 6to4 relays?
>>
>> Be that as it may, I suspect we should be more clever about whether it
>> gets turned on automatically or not, maybe by whether the address is
>> from an address range where we have some evidence of decent relays being
>> available.
> from a 6to4 router perspective you have no idea. the return relays are not 
> under your control.
> nor are they under your ISPs control.

Ah, point made (as far as I'm concerned).  Dave?

> in the homenet context you also need border discovery for this function. as 
> you really do not want to
> enable it on all internal routers. (in the case of global v4 addressing).
>
> but seriously, just remove it from the build.
>
This I disagree with; 6to4 is seriously useful in certain environments
(like mine).  Having it present can be useful, having it on by default,
is problematic. Unless/until we can fully automate something else I want
it available.

- Jim

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

Re: [homenet] Thoughts about ipv6 routing (babel & AHCP)

[Jim Gettys]

On 10/20/2011 09:00 AM, Lorenzo Colitti wrote:
> On Thu, Oct 20, 2011 at 21:59, Ole Troan  > wrote:
>
> but seriously, just remove it from the build.
>
>
> Yep. Overlay networks will never match native performance. Please
> don't do 6to4, please implement RFC 6204 instead.

Yes, please do.  Contributions of all sorts to CeroWrt/OpenWrt
gratefully accepted.  Things happen way faster if you do them yourself. ;-)
- Jim

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

Re: [homenet] Thoughts about ipv6 routing (babel & AHCP)

[Jim Gettys]

On 10/20/2011 08:22 AM, Lorenzo Colitti wrote:
> On Wed, Oct 19, 2011 at 22:34, Jim Gettys  <mailto:j...@freedesktop.org>> wrote:
>
> On 10/19/2011 03:43 AM, Ole Troan wrote:
> > you aren't helping things work better by doing 6to4.
> > please disabled by default, if you absolutely want to support it
> at all, hide it somewhere under the Wizard menus.
>
>
> +1. Please read Geoff Huston's data that shows the 12-20% failure rate
> of 6to4, and then please disable it. :-)

Yes, his data was taken just before/as Comcast put its relays into
production; it's not what we see on that network.  Before then, almost
all traffic went through some poor server in Wisconsin, as I remember. 
It sucked.

There is a self fulfilling prophesy here: if no one has decentr elays,
then 6to4 is never usable, and then we should deprecate it.  If it is
deprecated, why should anyone put in 6to4 relays?

Be that as it may, I suspect we should be more clever about whether it
gets turned on automatically or not, maybe by whether the address is
from an address range where we have some evidence of decent relays being
available.
- Jim

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

Re: [homenet] Thoughts about ipv6 routing (babel & AHCP)

[Jim Gettys]

On 10/19/2011 03:43 AM, Ole Troan wrote:
> you aren't helping things work better by doing 6to4.
> please disabled by default, if you absolutely want to support it at all, hide 
> it somewhere under the Wizard menus.
>
>
Actually, 6to4 works really well on Comcast since they installed
production 6to4 relays that are geographically dispersed.

Whether 6to4 should be on by default, given the lack of decent relays in
many parts of the world is a different question we can discuss.  I don't
think hiding it entirely is a good idea, given that this is the largest
ISP in the U.S. (world?).

This is, of course soluble by ISP's; not having much IPv6 traffic is a
self fulfilling prophesy if it doesn't get tested, and it won't get
tested unless there is traffic, etc  And without relays, 6to4 sucks,
and so on...

- Jim

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

Re: [homenet] Thoughts about routing

[Jim Gettys]

On 10/13/2011 05:40 PM, Curtis Villamizar wrote:
> In message <4e973605.50...@freedesktop.org>
> Jim Gettys writes:
>  
>> On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
>>> Yes and there are/were ATM switches that implement RFC1577, LANE,
>>> MPOA, and NHRP.  None of that worked very well and it all is
>>> essentially abandoned work now.  Pre-existence alone is not a worth
>>> while evaluation criteria.
>>>
>>> If zOSPF works perfectly, including in the presence of legacy routers
>>> which don't look at a new 48 bit mac address router-id extension, we
>>> have no reason to continue the discussion.  We just indicate "use
>>> zOSPF" and we're done.
>>>
>>> There seems to be consensus that we're not done.
>>>
>> On my part, I'm interested in understanding the following:
>> o scaling properties: I worry about the apartment building case, and
>>   related dense mesh case.
> Yep.  OSPF as is may not be appropriate for wireless mesh.  WG needs
> to consider this.
>
>> o behaviour when routing both wired and wireless networks.
>> o multicast behaviour and impact on wireless networks.
>> o running code
> Running code is too seldom available when the IETF rushes forward
> these days.  A reference implementation would be great.  I know which
> code base you have in mind.

I've been badly burned by standards committees in the past on this
topic.  Happens to be the IEEE folks, however.  Ergo my belief in both
running code and testing in diverse environments outside of laboratories
and meeting rooms.

And, in the case of the home router market, code has to come from some
place. Advocating something that has to be built from scratch seems like
a losing strategy.
>
>> And I'll ask the same about any other routing protocol you wish to
>> name.  I'm an equal opportunity parade rainer...
>> - Jim
> I haven't checked cerowrt to see how much configuration is required of
> OSPF.  
All Dave did was build and package quagga so that others could
conveniently start to play.

> If it is quagga, then a router-id has to be configured and each
> interface has to have OSPF explicitly enabled all with a Cisco style
> line oriented config.
Quagga has been packaged.  You can build other  stuff and packaged it
too, and the code is available to be modified.
- Jim


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

Re: [homenet] time service and DNSSEC

[Jim Gettys]

On 10/13/2011 06:15 PM, Curtis Villamizar wrote:
> In message <4e974d95.3000...@freedesktop.org>
> Jim Gettys writes:
>>> Sorry, but I lost track of why this is an issue for homenet.  What
>>> zero config crypto are we talking about that may care if it loses time
>>> of day?
>>>
>> DNSSEC.
>>  
>> And as routers are already being attacked, getting DNSSEC secure
>> end-to-end seems like the right strategy.
>> - Jim
>
> Trimmed response.
>
> I don't follow the logic here.
>
> I don't see any relationship between "routers are already being
> attacked" and DNSSEC.
>
> The homenet user is not going to get DNS or DNSSEC configured for the
> LAN addresses on their network so I'm not sure why the topic is even
> relevant to homenet.

Why not? Plug in a named computer, and publish it's name into the global
DNS... Proof of principle was demonstrated by Dave Taht and Evan Hunt
when they brought up
bind on CeroWrt even if it isn't in today's CeroWrt build.  It isn't
that hard...


>
> Back in the days when I was involved in big-I Internet operations
> routers purposely didn't run rely on DNS to avoid a chicken and egg
> problem (router can't reach DNS therefore routing is down).  Even logs
> used IP addresses and could be translated after the fact if need be.
>
> I'm quite knowledgeable in routers getting attacked.  The homenet
> routing protocol would be wise to use GTSM on things like OSPF.  Open
> routing on wireless might still be a bad idea.  Maybe keys or shared
> secret has to be added for wireless making it non-zero config.

Could be.  I have no clue what the community networking people are doing
about routing protocol security in OLSR or other protocols.  I certainly
*hope* they are doing something, as some of their networks are now in
the hundreds or even thousands of nodes...
- Jim


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

Re: [homenet] time service and DNSSEC

[Jim Gettys]

On 10/13/2011 04:41 PM, Curtis Villamizar wrote:
> In message <17165.1318514...@marajade.sandelman.ca>
> Michael Richardson writes:
>  
>>> "Curtis" == Curtis Villamizar  writes:
>> >> While talking about hardware.  These these devices all need a
>> >> battery backed clock or all the crypto will be broken.
>>  
>>  
>> Curtis> Having a clock is not hard but I don't think your statement
>> Curtis> is true.
>>  
>> Curtis> Some crypto does not require time, but rather just entropy
>> Curtis> (a nonce or challenge).  For crypto that does require time
>> Curtis> the former can be a bootstrap of sorts, possibly to get ntp
>> Curtis> going if very accurate time is needed (for some reason).
>>  
>> Curtis, Mark, as a DNSSEC implementer knows of what he speaks.  DNSSEC
>> requires time.  Not to the second or even minute, but at least hour.
>>  
>> DNSSEC is a core protocol at this point, and we need to be aware of
>> it.  It doesn't matter today, because we have a broken home DNS
>> system, but that's within homenet to fix.
>>  
>> Bootstraping time enough to get DNSSEC to work is important.
>
> I was thinking routing protocols and KARP.
>
> We are talking about routers and relying on DNS to get routing up is
> always a really bad idea.  Relying on NTP to get routing up is also a
> bad idea.
>
> Neither KARP, as defined, or DNSSEC, are candidates for zero
> configuration.  If the user can configure KARP and DNSSEC they are
> perfectly capable of using a backdoor, like ssh, to set the time of
> day after a reboot that lost time-of-day.
>
> Sorry, but I lost track of why this is an issue for homenet.  What
> zero config crypto are we talking about that may care if it loses time
> of day?
>
DNSSEC.

And as routers are already being attacked, getting DNSSEC secure
end-to-end seems like the right strategy.
- Jim

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

Re: [homenet] Thoughts about routing

[Jim Gettys]

On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
>
> Yes and there are/were ATM switches that implement RFC1577, LANE,
> MPOA, and NHRP.  None of that worked very well and it all is
> essentially abandoned work now.  Pre-existence alone is not a worth
> while evaluation criteria.
>
> If zOSPF works perfectly, including in the presence of legacy routers
> which don't look at a new 48 bit mac address router-id extension, we
> have no reason to continue the discussion.  We just indicate "use
> zOSPF" and we're done.
>
> There seems to be consensus that we're not done.
>
On my part, I'm interested in understanding the following:
o scaling properties: I worry about the apartment building case, and
related dense mesh case.
o behaviour when routing both wired and wireless networks.
o multicast behaviour and impact on wireless networks.
o running code
And I'll ask the same about any other routing protocol you wish to
name.  I'm an equal opportunity parade rainer...
- Jim


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

Re: [homenet] Thoughts about routing

[Jim Gettys]

Or you solve the time problem some other way...

Batteries die too...
  Jim




On Oct 12, 2011, at 9:19 PM, Mark Andrews  wrote:

> 
> While talking about hardware.  These these devices all need a battery
> backed clock or all the crypto will be broken.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
> 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

Re: [homenet] time service and DNSSEC

[Jim Gettys]

On 10/13/2011 10:05 AM, Michael Richardson wrote:
>> "Curtis" == Curtis Villamizar  writes:
> >> While talking about hardware.  These these devices all need a
> >> battery backed clock or all the crypto will be broken.
>
>
> Curtis> Having a clock is not hard but I don't think your statement
> Curtis> is true.
>
> Curtis> Some crypto does not require time, but rather just entropy
> Curtis> (a nonce or challenge).  For crypto that does require time
> Curtis> the former can be a bootstrap of sorts, possibly to get ntp
> Curtis> going if very accurate time is needed (for some reason).
>
> Curtis, Mark, as a DNSSEC implementer knows of what he speaks.
> DNSSEC requires time.  Not to the second or even minute, but at least
> hour.
>
> DNSSEC is a core protocol at this point, and we need to be aware of it.
> It doesn't matter today, because we have a broken home DNS system, but
> that's within homenet to fix.
>
> Bootstraping time enough to get DNSSEC to work is important.
>
Yup. And DNSSEC does not require precise time as you note.

In the short term, in CeroWrt, which has running DNSSEC, Dave plans to
do insecure lookups initially to resolve NTP server addresses to get the
time, and then switch over to secure once time has been established.

There may be other options possible.  Ideally, something like a well
known anycast address we can get approximate time on would suffice, for
some high velocity hand waving.
- Jim

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

Re: [homenet] Thoughts about routing - flash/stable storage constraints

[Jim Gettys]

On 10/11/2011 12:05 AM, Jari Arkko wrote:
> Home routers would also have MAC addresses, but again, if we need a
> 32-bit quantity then shortened 48/64 bit identifiers may
> (theoretically) have collisions.
>
> That being said, if the home routers have to discover their IPv6
> prefix through a protocol and store it in flash, they could probably
> do so also for a router ID. Unless there was some chicken and egg
> problem that required the router ID for all this discovery to work...
As to storing in flash, since most in homenet have not typically worked
on embedded systems, worse luck...

There is typically a read/write file system that can store state on a
current Linux home router (e.g. OpenWrt); it may or may not mapped over
the entire flash (which is desirable, as you'd like wear levelling to
use all blocks on the flash).

The bulk of the firmware is likely contained in a read-only file system
called Squashfs, which does LZW compression on a per file basis;
overlayed on top may be a read/write file system.

Most commonly the read/write file system has been a file system called
jffs2 over bare flash, originally implemented on the Compaq iPAQ
handheld, a project I helped lead after I got sick of HTTP.  And OLPC
had a gigabyte of flash (which pushes jffs2 to/beyond it's design
limits). There are later flash file systems under development, but I
don't have first hand experience with any of them.

Flash has the characteristic that write is relatively slow, and erase is
generally glacial.  Most interesting flash file systems try to do lazy
erasure (erase freed blocks when they have a chance later, rather than
at the time you may free a file).

Since you don't want to wear out the flash, the jffs2 does journaling;
one write will commit (potentially) a bunch of changes to multiple
files, rather than each write generating one write.

How many writes you get depends on the flash technology, whether the
flash is "bare" or has some "smart" controller, and the wear levelling
technology (if any) in use, along with whether all blocks participate in
the wear levelling or not (jffs2 does good wear levelling; but using a
big squashfs file system + a very small jffs2 file system will reduce
the effectiveness; some cheap USB storage devices only do wear levelling
on the free blocks, and try to hide the fact it is flash from the system
above.  I put "smart" in quotes, because they've often been hideously
stupid, with their smarts limited to looking like IDE with a very lame
flash translation layer.  The most recent "smart" flash disks for
laptops are actually getting very smart, with some help from the OS to
help with the erasure problem.  But they still cost substantially more,
I suspect.

I think most home routers currently use bare flash, though it's not
clear to me if this will continue or not since the volume market may
make the economics change.

In any case, with flash of any sort, you don't want to sit there and
demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime,
for example). 

All this being said, storing state at the rate of machines/routers
appearing or disappearing on a home network, or your ISP going down,
isn't likely to cause a problem.  You just have to be careful enough to
not do anything really stupid; e.g. you map daemons with chatty logs to
run their logs to /dev/null, or to tempfs in RAM. And you might take a
big latency hit if you have to guarantee the write is stable before
continuing an algorithm (if you run into needing to erase a block for
some reason).  And obviously you don't write tons of data when you don't
half to. And update in place may be a bad idea relative to other
techniques (which is why journaling file systems such as jffs2 are so
desirable).

- Jim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - scaling

[Jim Gettys]

I've alluded to having suffered from routing problems in the past, and
urged people to be very careful about scaling, and interacting with
unexpected/unintended neighbours, something that seldom happens in wired
networking.

I thought I'd elaborate slightly to help people focus on the problems.

Both of these experiences come from my tenure at OLPC, which attempted
to deploy mesh networking, where I worried about the base system
software (but not the networking, in particular; Michailis Bletsas was
in charge of that).  Both added grey hair to my head and scars to our
backs.

1) we had a situation, in which one of our machines tickled a bug in
existing routers being used in an apartment building causing most all of
the home networks in the apartment building to crash, to the point of
needing reboot.  It wasn't our bug; but it was sure our problem :-(.
This is about all I can say on an open list about what happened here.

The moral: lots of people can hear the packets you transmit; ensuring
nothing bad will happen is "interesting".  The packets escape into the
"ether" and may have consequences you don't anticipate.  And just
because you think that there are only a few participants in a
conversation doesn't make it so.

2) The 802.11s committee, in their infinite wisdom, specified a routing
protocol at layer 2. At least in the draft standard we were working
from, the properties of this routing algorithm had the consequence of
N^2 messages where N was determined by the number of machines that could
hear each other simultaneously (each machine that heard you looking for
the exit to the mesh would each turn around and send another message). I
don't know if the current version of the standard is so brain-dead or
not: the committee had ruled the scaling problem "out of scope" for the
group: after all, no one would ever think of running a mesh in such a
circumstance.  Reality is that kids show up at school at the same time,
(or people enter a conference room at the same time), and it happens.
Let us not suffer from the attitude the IEEE did with 802.11s.

 It doesn't take many machines (somewhere between 15 and 30), that can
hear each other to fry your channel entirely.  It was so bad that we
could only get about 14-16 bits into the preamble of the message before
someone else would transmit and step on the attempted transmission:
another words, the network completely collapsed with scale.

We called this the "dense mesh" problem. Any routing protocol used on
wireless should be evaluated for its scaling properties carefully.

Your first ARP would, of course, trigger this melt down.

The third problem we had in networking we didn't figure out at all: that
awaited my personal encounter with bufferbloat to understand.
- Jim

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

Re: [homenet] Thoughts about routing - trends

[Jim Gettys]

On 10/07/2011 03:48 AM, Fred Baker wrote:
> 4) The use of OLSR in mesh network scenarios 
>
> Jim Gettys commented on the fact of OLSR use. The general sense of the room 
> was that OLSRv2 is interesting but out of scope for this discussion as mesh 
> networks are quite different from typical residential and SOHO networks.
>  
Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my
area of expertise. 

Babel/BabelZ is appearing in CeroWrt today as the people who are
interested in such things are doing the work (we don't need a routing
protocol in the simple single home router case), and it provided the
functionality we needed.

For those who want something else, quagga is in the CeroWrt build for
your hacking pleasure.

And I'm not advocating the homenet working group do anything unusual
about routing at this date; as I said, it's not my area of expertise.

Having said this, I do note the following technological trends:

1) As soon as we get real "plug and play" routers that don't need manual
configuration that work, we'll see a lot more routers in a home
environment.  Other radio technologies (e.g. zigbee) may encourage this
trend.  It seemed like the working group agreed that getting to the
point that just hooking things together would really "just worked" was a
fundamental requirement (and I agree entirely with this sentiment, as it
reflects reality of what already happens in the homes of hackers and
non-hackers alike).

2) wireless is much cheaper to implement than wired networking,
particularly in most houses where pulling cable is hard.  I know this
first hand, where I've pulled a lot of cat 6 and wish I could get it to
places I don't have it.

Unless power line networking really works, I believe that this trend
isn't going to change.  Is there any progress in this area?  I've seen
many promises, and few reliable working products.

3) As soon as you have two routers, you have at least two paths; the
wired connection between them and the wireless.  You may have 3 paths,
if you have both 2.4 and 5ghz radios. Frequency diversity routing
becomes immediately interesting, along with using your ethernet when
it's available in preference to wireless.

4) an apartment building look like a mesh, and possibly with multiple
backhauls possibly with multiple ISP's. One should at least think about
what happens when you have "homes", in such a building, and make sure
nothing breaks. Wireless is messy: it isn't limited to where a wire
goes.  Taking down an entire apartment building/blocks/city would not be
fun.  I know, I've been there (at least to the point of taking down
buildings, and came within a week of a much larger scale disaster).

If you believe 1 + 2 + 3 +4  (as I do), then if you look a few years
out, you end up with something in the "home" that begins to resemble
very strongly what the community mesh networking folks are doing at a
higher scale geographically and in terms of # of nodes today, with
many/most of the same concerns and solutions. Understanding the problems
they've faced/are facing is therefore worth a bit of investment; Radio
diversity is one of the concerns, and interference (of various sorts).

Julius' talk about why frequency diversity is an issue is here:

http://www.youtube.com/watch?v=1VNzm0shSA8

While the issues outlined above are not where home networking is today,
my gut feel is they will be in five years.

If there is *anything* I can urge on the group, is to respect the
scaling problems that can/will occur, and to internalise wireless
!=wired: wireless goes where wireless goes and does not behave like
ethernet. The group needs to ensure nothing "bad" happens when people
start building systems in ways you don't expect, particularly in an
apartment building.  The challenge is balancing the reality of how
wireless works, with "just works" automatic configuration, with "fail
safe" behaviour.
- Jim







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

Re: [homenet] Question for you

[Jim Gettys]

On 10/03/2011 03:32 PM, Tony Li wrote:
> On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote:
>
>> My point was just that wireless has a set of challenges that all may not
>> be familiar with; knowing that may help point the discussion in fruitful
>> ways.  Routing isn't my area of expertise (though I have scars on my
>> back from it in wireless...).
>
> Understood.
>
> Yes, wireless has some challenges and I've spent some time in that area.  
> Certainly our standard protocols are not optimal for a purely wireless 
> environment.  
>
> However, for the generic, heterogenous networks that I would expect in the 
> home, I would expect that the generic protocols would be the better overall 
> approach.

Having been seriously scarred by presuming that wireless was similar to
wired, I'm a believer in careful testing, rather than "expecting" that
something should work.  Without "running code", demonstrably working,
I'll take nothing on faith in this area.

Wireless != wired, is what I took away from that (painful) experience.
- Jim

>
> Tony
>

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

Re: [homenet] Question for you

[Jim Gettys]

On 10/03/2011 02:35 PM, Tony Li wrote:
> LS protocols give every router a full picture of the topology, so the 
> diversity is apparent to all nodes.

My point was just that wireless has a set of challenges that all may not
be familiar with; knowing that may help point the discussion in fruitful
ways.  Routing isn't my area of expertise (though I have scars on my
back from it in wireless...).
- Jim

>
> Tony
>
>
> On Oct 3, 2011, at 11:28 AM, Jim Gettys wrote:
>
>> I think there is another set of routing issues that most have not
>> thought about unless they have had experience with wireless networking;
>> that is the possible need for diversity aware routing.
>>
>> See:
>>
>> http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf
>> <http://www.pps.jussieu.fr/%7Ejch/software/babel/wbmv4.pdf>
>>
>> For an introduction to the topic, and some work in the area (e.g. babelz).
>>
>> In my house, for example, I have great trouble getting wires where all I
>> need them, and I need multiple access points.  I'd like to put one out
>> in the pool shed, and I really can't get wires out there (without digging).
>>
>> This may or may not be orthogonal to the routing requirements to support
>> multi-homing and multiple providers, but is something that many/most
>> routing protocols have not dealt with in the past.
>>- Jim
>>
>> ___
>> rtgwg mailing list
>> rt...@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg

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

Re: [homenet] Question for you

[Jim Gettys]

I think there is another set of routing issues that most have not
thought about unless they have had experience with wireless networking;
that is the possible need for diversity aware routing.

See:

http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf


For an introduction to the topic, and some work in the area (e.g. babelz).

In my house, for example, I have great trouble getting wires where all I
need them, and I need multiple access points.  I'd like to put one out
in the pool shed, and I really can't get wires out there (without digging).

This may or may not be orthogonal to the routing requirements to support
multi-homing and multiple providers, but is something that many/most
routing protocols have not dealt with in the past.
- Jim

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

[homenet] CeroWrt RC6 (beta 2) announced.

[Jim Gettys]

I promised last week I'd say more about my allusion to sending mail from a 
routed rather 
bridged home network.  The following announcement went out last week, and I now 
draw it to this
mailing list's attention.

I'll be attending the Homenet meeting next week.  Note that Dave Taht and I 
started working
on CeroWrt well before the approval of the charter of the homenet working 
group, and while our goals are
roughly in align with the working group, we are not constrained to its charter
nor was work inspired by homenet at all.

In fact, our primary goal is to have a test platform to deal with bufferbloat, 
but also one
we want to run ourselves (and be useful enough to others to help test 
bufferbloat solutions
in environments where we cannot explicitly test). Given technological trends, 
we decided it was
best to not feel constrained to run on badly flash constrained devices such as 
stock OpenWrt, 
and that we needed a modern dual radio router. It's directly a result of what 
we want in our 
own homes, and can't buy today. The classic "scratch your itch" project.

We do hope it may help settle by demonstration some of the less productive 
discussions we've seen go by
on the homenet list and meeting, including:
   o whether to bridge or route between networks
   o whether mesh networking is feasible at this date
   o whether Bind/DNSSEC is reasonable to put in such devices due to size
"Rough Consensus and Running Code...".  Have some running code; hopefully we'll 
see some
consensus form

Here's a synopsis of the announcement:

CeroWrt 1.0-RC6 (beta 2) is now available. It now runs Linux 3.0.4,
ISC-Bind 9.8.1, babel 1.2, and has a preliminary minimum defaults
for many bufferbloat related issues. Performance testing has begun -
and shows that some of those defaults need to be changed. Please
help!

CeroWrt is a build of the OpenWrt routing platform intended for use by 
individuals, 
network engineers, researchers, teachers and students interested
in advancing the state of the art on the Internet, and in particular 
investigating the problems of latency under load, bufferbloat, wireless-n, 
and the interrelationships between various TCP & QoS algorithms

CeroWrt RC6 (beta 2) includes:
   o extensive network diagnostic, performance measurement, and simulation tools
   o comprehensive IPv6 support
   o integral web server
   o rsync server
   o advanced Bind DNS server with DNSSEC validation and signing
   o support for mesh networking
   o a web proxy server
   o and most importantly, extensive debloating
   o ethernet, 2.4 ghz and 5gkh wireless networks are all routed, not bridged

CeroWrt is aimed at (currently) a single hardware platform for which
fully open drivers are available: the Netgear WNDR3700v2, a current
802.11abgn router using the Atheros AR7161 rev 2 with gigabit
Ethernet ports. Last we looked, these cost $120 quantity one.

Our great thanks to Felix Fietkau and Andrew McGregor for their work
on the ath9k driver to greatly improve 802.11n aggregation behaviour
(which also reduces required buffering in the driver by about a
factor of three).

For lots more information about CeroWrt, look at: 
http://cero2.bufferbloat.net/cerowrt/

This is running on a CeroWrt router, of course.

The full release announcement can be found at: 
http://www.bufferbloat.net/news/19

Dave Taht's taking some well deserved vacation right now: I'll answer questions 
as
best I can, but he's the real router wizard between us.

Happy hacking.  Please come help. Plenty of rough edges to file off yet, and 
I'm sure 
you have features you may want (and can make happen); remember, running code...
- Jim Gettys



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

Re: [homenet] Homenet Architecture & Interim Meeting

[Jim Gettys]

On 09/21/2011 04:19 PM, Ray Hunter wrote:
> Thanks very much for producing this draft.
>
> I realise the WG is in a hurry, but I think there's some fundamental
> issues to solve here on sharpening up requirements if the architecture
> is going to last more than a couple of years. I really miss a
> discussion on requirements.
>
> I'm probably going to push forward some things you'll say are not
> typical user requirements and will therefore push back. That's
> healthy, and we should be very clear about the problem homenet is
> trying to solve, and what is, and what is not in scope.
>
> If I think of my own house network, I don't think it fits in any of
> the scenarios in the document today in terms of complexity. That's a
> bit scary. I have IPv4 from one provider, IPv6 from another, DMZ's for
> inbound services, multiple firewalls, wireless extenders.. being
> honest, would your home network fit in with any of the architecture
> pictures? Or is this wishful thinking of what you think your parents /
> friends could realistically manage?
>
> Some major trends in home networking have been hidden from view of the
> network providers and network equipment prociders, (and perhaps the
> IETF too) by large scale use of NAT. If you want to get rid of NAT
> you're going to have to address the following IMVHO. The focus has
> been largely on the number of devices (address depletion), but the
> real challenge is likely to be complexity of requirements (IP becomes
> ubiquitous).
>
> 1) I contend that multi-homing is probably going to become the "norm"
> in Europe by 2022, due to The European Electricity and Gas Directive.
> That corresponds at least to picture 4, if not more.
>
> But that picture seems to presume a single isolation LAN to connect
> two ISP providers of equal worth. I think that reachability, and cost,
> and the services provided by the various networks, may be radically
> different. One may be your entertainment ISP. Another your telephony
> ISP. Another your electricity provider ISP. Your car may connect to
> the electricity network ISP to register charging. Your phone may
> connect to 4G whilst not at home and then to WiFi whilst you are at
> home, and to hard wired cable when it is connected to its charger. Or
> perhaps to homenet for controlling the lights and the 4G for voice
> calls
>
> We should be clear about what (if any) interaction, provider
> preference / selection, and fall back scenarios will be implemented as
> part of the homenet providing an ISP selection function; or whether
> the service providers should be seen as providing 3 or more logically
> separate home networks, and where the end device itself has to chose
> the outbound path independently of the ISP's and homenet(s) routing.
>
> 2) Wireless is exploding. I contend that the single layer LAN in the
> picture is a non-starter. There is almost certainly going to be at
> least two short range radio system technologies in home networks: one
> wifi and one LoWPAN type network for device control. There may be more
> technologies given the rate electronics is moving at the moment e.g.
> NFC, networking via LED lighting. So there may also be a requirement
> for interconnection of multiple ultra-short range networks via a house
> backbone: e.g. lights on top floor pool to form a mesh network, and
> lights in the basement form a mesh network, but the reinforced
> concrete floor partitions the two wireless meshes, so you need a
> routed connection between them. The various radio and lightwave
> standards are unlikely to be L2 bridgeable IMHO. That may add another
> layer of routing to your picture.

Bridging a gigabit ethernet and even today's wireless is asking for
tremendous trouble; a tiny amount of multicast on ethernet can already
ruin your whole day on wireless (since it is transmitted at 1Mbit).  And
some of the future wireless technology puts the disparity of bandwidth
even higher.

Many home routers now have 2 radios (2.4 and 5ghz) and guest networks
are also the "norm".  So we're already at 6 networks in a single home
router box (wan, local ethernet, 802.11@2.4, 802.11@5, 802.11guest@2.4,
802.11guest@5ghz), and need also a DMZ network, much less dealing with
VPN's, and more complex home network topologiesk.

This message brought to you via a home router which routes, not bridges,
these networks.  More about this topic next week
- Jim



>
> 3) Virtual machines are exploding. I run 4 VM's on my workstation.
> With the various upcoming application stores and multiple application
> developers running on one system, I could easily imagine that each
> application eventually runs in its own mini-VM, so each IPv6 host
> becomes the equivalent of an old style mainframe with multiple
> prefixes and intra-machine routing. That may add another layer of
> routing to your picture. There may also be virtual firewalls between
> those VM's, which adds another layer.
>
> 4) IPv4 NAT allows limitless layers of sta