Subject: [homenet] Thoughts about routing

From: Fred Baker <[email-masked]>
Date: Fri, 7 Oct 2011 03:48:13 -0400

Slides from the talk today are at http://trac.tools.ietf.org/wg/homenet/trac/attachment/wiki/WikiStart/Homenet%20Routing.pdf. I used them to lead a structured discussion of routing technologies appropriate in Home and small Office (SOHO) networks, with a view to requirements for selection of a routing protocol to "RECEOMMEND" (RFC 2119 language) that Homenet router vendors implement. This is in part to document a discussion we had in the room and in part to lead it into list discussion.

As one might expect, a lot of the discussion was non-controversial. Points that raised discussion started with the issue of multihoming as shown on slide 9. A question arose on how multi-address interfaces work on typical operating systems including Windows, MacOSX, and various Linux variants. It was observed that rather than actually forming an address in each prefix as one would expect in a multi-prefix network, Linux sees the various prefixes advertised in an RA and selects one, forms an address in it, and uses that address until it expires. Per RFC 4861, the lifetime on such a prefix is the same as the lifetime on the IA_PD granted by the upstream network, which is generally on the order of weeks. In the event that we have multiple routers to multiple upstream networks each advertising a prefix and one fails - not just the link, but the router and therefore the DHCPv6 server in it - the host will continue using that prefix until it is actively rescinded.

A number of folks in the room had a discussion during a break about a related scenario, and concocted the idea of an "RA Server"; if there are multiple routers to multiple upstream networks and therefore advertising prefixes, one of them should advertise all of the prefixes, and if the route to any given prefix fails (including if the RA Server fails and another takes over the function) should remove the prefix from use. In a network using OSPF/IS-IS, the obvious router to perform this function might be the Designated Router.

After completing the slides, I made the following statement and opened it for discussion: "If I were to make a call today, given the facts in evidence, I would want a routing protocol with a high quality open source implementation that was proven and documented interoperable with other implementations, and which had the necessary characteristics to recover from failures in a period on the order of tens of seconds to minutes as opposed to tens of minutes. I would recommend either RIPng or OSPFv3, and recommend RPL for 802.15.4 interfaces."

Four comments/discussions came out quickly, and as near as I can tell represented viewpoints common in the room.

1) why recommend a routing protocol at all?

I suggested that the probability of use of each of the scenarios on slide 4 were
     single router network: 90th percentile
     tree network:          unusual
     multi-router:          perhaps 5th percentile
     multihomed:            unusual

The discussion in the room elevated the multi-homed case, due to corporate information security requirements that required an employee's home office to use a given network, the presence of TV-bearing and mobile telephone networks, and so on. The argument for recommending any protocol at all has to do with the zeroconf requirement and the interoperation requirement; if you actually have multiple routers in the home, it would be nice if they could exchange routes.

2) Networks calling for other protocols

The room found the requirements of the Smart Grid HAN unconvincing. In summary, the sense of the room was that one might sell a router that interfaced a RPL network to an OSPF network in the rest of the home; ths might be in a special purpose "interior" router, a function of the ESI, or on the CPE Router itself.

3) Why even bring up RIPng?

I bring it up because it is RIPv2 warmed over, and the majority of residential routers I surveyed some months back support RIPv2; I expect it is an image match to the expectations of companies that make consumer-grade routers, and for simple scenarios works "well enough". That said, documents such as RFC 1812 recommend implementation of OSPF due to its characteristics with respect to timing. The sense of the room favored implementation of OSPFv3 over RIPng, and suggested that someone look hard at http://tools.ietf.org/html/draft-dimitri-zospf with respect to prefix management; one wants a well tested and proven-interoperable OSPFv3 implementation (with OSPFv3 itself at Draft Standard with respect to the requirements of RFC 2026) that can also perform subnet prefix management.

There was discussion of a protocol profile; not only place all interfaces into area zero by default, but remove the capability for multiple areas and advertise the /64 allocated to RPL (if present) in an OSPFv3 type 9 record along with the other prefixes on the router. How much of the implementation could disappear (the LSDB would now only contain Router LSAs, Network LSAs, and Prefix LSAs, and would only need to process those types) was indeterminate. Using address families, this could also subsume IPv4 routing, although it seems likely that since routers already support RIPv2, that routing would continue to use RIPv2.

4) The use of OLSR in mesh network scenarios 

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.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Oct 2011 05:25:45 -0400

Fred,

Thanks for the excellent summary!

I'm in the camp that believes we do need an automatic routing mechanism. Maybe it is because I'm in the 5% percentile, maybe it is because I believe we'll see more guest/private and non-bridgeable subnets. (At the end of the day, I think an open Internet model for all devices will win, and we may be able to get rid of guest/private. But at the same time I think we need an answer on how to do current network models in IPv6 when the IPv4 answer is adding another NAT. If we do not have an answer, a copy of the IPv4 network model will emerge for IPv6.)

In any case, I think the choice of a routing mechanism is a practical question. What can we realistically expect devices to do. Your data points to RIP, but one significant point from yesterday's discussions was that it might be easier to do internal network prefix assignment in general topologies with a link state routing mechanism. I still worry that we try to optimize too much or aim too high with our expectations of functionality. Perhaps something simpler would work for prefix assignment and we could just do what most devices already have in their code, i.e., RIP. The IETF is often in a danger of inventing new solutions as we are protocol engineers, and then failing to get the new stuff deployed. But I also like OSPF a lot, and I think it would be a very elegant solution. I'm going to see if I can put it into my network, with some prefix assignment solution.

I would like to see a recommendation for one protocol though. Something that we would expect most home routers to support in the future. I think that recommendation needs to be for a general purpose routing protocol that we have years and years of experience with.

(We'll of course see some additional things in many networks, too. One topic that has been raised often is LLN and ad hoc routing protocols. These can naturally be accommodated where needed, as the current models in RPL, for instance, call for a border router that can do the necessary per-packet encap and speak RPL. Such a border router should also be a homenet router and be capable of participating in the routing and prefix allocation tasks with the rest of the home network. But I think it would be a mistake to adopt one of the ad hoc network protocols as the basic protocol to run in all home networks. Speaking personally, I would at least like to stick with more traditional solutions and skip the special encap and other things that may come with other designs. For the record, I'm probably as sensor networked as you can be, but I do not use ad hoc routing protocols because I happen to do all my sensor networking with link types -- WLAN, wired, cellular -- that do not call 
for anything special. I know there are other types of situations, but wanted to provide an example of LLN networking that runs in a more traditional architecture.)

Question: Yesterday we talked a little bit about what it means for the routing to be turned on automatically. Prefix assignment based on your delegation from the ISP is one part of it. What else do we need? Is this just a matter of making our home router devices have OSPF on by default, and as soon as the device gets its prefix it will start advertising it in the routing protocol?

Jari

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Oct 2011 06:28:56 -0400

> Question: Yesterday we talked a little bit about what it means for the routing to be turned on automatically. Prefix assignment based on your delegation from the ISP is one part of it. What else do…

For the most part, yes. Most of the parameters that OSPF requires have defaults specified in the RFC, and while they may or may not be perfect they're not bad. In managed configurations (SP, Enterprise, etc) folks twiddle the frequency of Hello messages, with a view to quickly detecting a failure; IIRC, OSPF by default determines that a neighbor is lost after 4 missed hellos or a link-down event, so in the worst case this is 50 seconds from the receipt of the previous successful message. I doubt that's a real issue in residential/SOHO networks.

The other parameters in question include 
  - the interface prefix itself, which could be derived as in zospf, 
  - the area number (I'd suggest it default to zero), 
  - the router ID (a random 32 bit number), and 
  - security information. 

I'd suggest that security information be akin to security on an SSID - pester the user until he gives you something. zospf may have a comment on security, I don't recall. The Router ID in IPv4 networks is often one of the IPv4 addresses; for IPv6, it could be derived from a MAC address, a serial number, or anything else as long as it is unique within the routing domain.

From my perspective, turning on OSPF by default means that the router will not start actually routing until 40 seconds after it is turned on (OSPF start-up), and will otherwise mean that it beeps on the LAN every ten seconds; the message is in the multicast group ALL-OSPF-ROUTERS, which only other routers should be listening to. By comparison, your favorite 802.1 switch beeps a BPDU on every interface once per second.

I personally have no issue with OSPF given a rational set of defaults and an acceptable implementation.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Oct 2011 06:35:48 -0400

Thanks. Makes sense.

Jari

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Oct 2011 08:08:53 -0400

> As one might expect, a lot of the discussion was non-controversial. Points that raised discussion started with the issue of multihoming as shown on slide 9. A question arose on how multi-address in…

Speaking strictly for myself, here, this seems actively broken in several ways. First, if the design of IPv6 calls for an address in each prefix advertised in an RA, what would it take to get Windows, MacOSX, FreeBSD, Linux, Linux, Linux, and Linux to do that? All discussion of RFC 3484 seems wasted if the device has exactly one address.

But also, the notion of tying the lifetime of a prefix on the LAN with the lifetime of the prefix grant seems ill-considered. The purpose of the lifetime on the prefix grant (RFC 3363) is to enable an upstream to not need to be asked every 30 seconds for something it wants to leave unchanged for a long period of time and yet make "a long time" not be "forever". That's reasonable. But in the case called out here, it seems like the lifetime of the prefix in an RA should be long enough that a host can miss an RA refresh and not lose the address, and short enough that we don't have to call in the national guard if someone trips over a cable or a power supply goes spitzensparken.

What do we need to do to change that RFC 4861 requirement? If what is required is an Internet Draft in 6man (and I would expect it is), I'd be willing to write that draft.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 07 Oct 2011 08:31:24 -0400

Fred Baker <[email-masked]> writes:

> It was observed that rather than actually forming an address in each
> prefix as one would expect in a multi-prefix network, Linux sees the
> various prefixes advertised in an RA and selects one, forms an
> address in it, and uses that address until it expires.

I'd be surprised if this was in fact what Linux did. This would be a
complete violation of existing specs.

And, I'm sure that the the IPv6 Ready Logo/USGv6 tests would flag such
an implementation as broken.

But indeed, a number of linux implementations have tested successfully
for USGv6 at UNH.

E.g., if you look at
http://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php

It shows SUSE and RHE as having passed the IPv6 tests.

Why do people think that Linux doesn't follow the specs when it comes
to forming addresses via stateless autoconfiguration?

Thomas

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Oct 2011 08:32:42 -0400

I'll let those who raised the concern respond.

On Oct 7, 2011, at 8:31 AM, Thomas Narten wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Oct 2011 08:41:55 -0400

Fred,

> Speaking strictly for myself, here, this seems actively broken in several ways. First, if the design of IPv6 calls for an address in each prefix advertised in an RA, what would it take to get Windo…

Linux actually does configure multiple addresses, and seems capable of using them in different situations. Maybe yesterday's comment about Linux behavior was more about what it does when a set of addresses has no clear preference (RFC 3484 or otherwise. My experience is that it does then use one address/router unless something changes. (Indeed, this is often problem as an earlier version had a bug that old networks didn't go down despite moving to a new network, and if I happened to use the old router's address I was having a bad day.)

> What do we need to do to change that RFC 4861 requirement? If what is required is an Internet Draft in 6man (and I would expect it is), I'd be willing to write that draft.

I was scanning RFC 4861 and did not see anything about IA_PD or delegation, just saw a 30 day default value for the valid lifetime. Where is the text that you would like to change?

Jari

---

From: Ralph Droms <[email-masked]>
Date: Fri, 7 Oct 2011 09:02:32 -0400

On Oct 7, 2011, at 8:41 AM, Jari Arkko <[email-masked]> wrote:

> I was scanning RFC 4861 and did not see anything about IA_PD or delegation, just saw a 30 day default value for the valid lifetime. Where is the text that you would like to

The text in question may be in RFC 3633, section 12.1, which requires that the valid lifetime for the prefix in the RA must be no later than the valid lifetime in the IA_PD. 

- Ralph

> change?

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Oct 2011 09:11:40 -0400

> A number of folks in the room had a discussion during a break about a related scenario, and concocted the idea of an "RA Server"; if there are multiple routers to multiple upstream networks and the…

I think as a general principle addressing is independent of routing. and that we should not as a result of loss of reachability deprecate an address. every address, global or not has different reachability and a host has to handle it.

cheers,
Ole

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Oct 2011 09:49:35 -0400

Ralph,

> The text in question may be in RFC 3633, section 12.1, which requires that the valid lifetime for the prefix in the RA must be no later than the valid lifetime in the IA_PD.

Ah. The full text says:

    ... the requesting router MUST
    set the valid lifetime in those advertisements to be no later than
    the valid lifetime specified in the IA_PD Prefix option.  A
    requesting router MAY use the preferred lifetime specified in the
    IA_PD Prefix option.

I think this is fine, and allows the implementation to do the sensible thing. You can put in a smaller time. You can use the exact lease time. You would only get into trouble if the PD lease times where insanely small. Fixing that requires the operator to notice, and cannot be fixed in IETF specifications. In any case, we don't have a huge amount of PD deployment yet, so additional practical guidance on what kind of values to use within the rules specified above can be useful and might have an impact on what people actually do. Personally, I think its rather obvious, but I could of course be missing something.

(I'm walking to the meeting site now. I had a day job conference call in the morning... Hope you solved all the problems in the morning session already :-)

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 07 Oct 2011 15:52:12 -0700

Fred,

are the above numbers based on any survey data?

Reason I'm asking is that I have two consumer devices with IPv4 NAT in 
my home (a VoIP box and a backup device) where the instructions said:
1. Insert between or existing router (or PC if you have no router) and 
the DSL/cable modem
2. Insert between your PC and your existing router (or modem if you have 
no router)

Those consumer instructions naturally result in a daisy-chain of IPv4 
RGs/NATs, which is a subset of a tree topology.

I can't be the only person who have a VoIP box or a Time Capsule.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 07 Oct 2011 15:55:36 -0700

Fred,

Do existing OSPF implementations have the ability to pick a random 
router ID, and detect when there is a router ID collision?

One benefit of using IS-IS is that the router ID is longer and based on 
a factory-assigned IEEE MAC address.

The zospf appears to have an approach for router ID collisions, but that 
probably isn't (widely) implemented.

(In any case, we'd need to figure out what it means to have stable 
prefixes allocated - to interfaces or to links - but that is the prefix 
autoconfig part of the problem as opposed to the router config part of 
the problem.)

    Erik

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Oct 2011 22:15:41 -0400

> are the above numbers based on any survey data?

They are as scientific as the end of my thumb :-)

> Reason I'm asking is that I have two consumer devices with IPv4 NAT in my home (a VoIP box and a backup device) where the instructions said:
> 1. Insert between or existing router (or PC if you have no router) and the DSL/cable modem
> 2. Insert between your PC and your existing router (or modem if you have no router)
> 
> Those consumer instructions naturally result in a daisy-chain of IPv4 RGs/NATs, which is a subset of a tree topology.
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Oct 2011 22:17:05 -0400

On Oct 7, 2011, at 6:55 PM, Erik Nordmark wrote:

> Do existing OSPF implementations have the ability to pick a random router ID, and detect when there is a router ID collision?

OSPFv2 implementations generally pick one of the IPv4 addresses of the system. Not sure I can make a general comment on OSPFv3.

> One benefit of using IS-IS is that the router ID is longer and based on a factory-assigned IEEE MAC address.

> The zospf appears to have an approach for router ID collisions, but that probably isn't (widely) implemented.

ZOSPF is, AFAIK, an internet draft that has never been implemented.

> (In any case, we'd need to figure out what it means to have stable prefixes allocated - to interfaces or to links - but that is the prefix autoconfig part of the problem as opposed to the router config part of the problem.)
> 
>   Erik
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Oct 2011 11:33:37 -0400

>>>>> "Erik" == Erik Nordmark <[email-masked]> writes:
    Erik> Reason I'm asking is that I have two consumer devices with
    Erik> IPv4 NAT in my home (a VoIP box and a backup device) where the
    Erik> instructions said: 1. Insert between or existing router (or PC
    Erik> if you have no router) and the DSL/cable modem 2. Insert
    Erik> between your PC and your existing router (or modem if you have
    Erik> no router)

    Erik> Those consumer instructions naturally result in a daisy-chain
    Erik> of IPv4 RGs/NATs, which is a subset of a tree topology.

That's a good point:  many VoIP ATAs want to be the first device so that
they can control the QoS, and ideally get the public IP address.

Does your VoIP box do PPPoE as well?  
Or did I misunderstand.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Oct 2011 12:07:52 -0400

Fred, I've changed the subject, I hope to shed more light.

>>>>> "Fred" == Fred Baker <[email-masked]> wrote:
    Fred> But also, the notion of tying the lifetime of a prefix on the
    Fred> LAN with the lifetime of the prefix grant seems
    Fred> ill-considered. The purpose of the lifetime on the prefix
    Fred> grant (RFC 3363) is to enable an upstream to not need to be

I think you meant RFC3633 here right? (DHCP-PD)
I think that we clarified in discussion that the lifetime of prefix
advertised was limited to be no more than the lifetime in the PD.
It could be much lower.

    Fred> asked every 30 seconds for something it wants to leave
    Fred> unchanged for a long period of time and yet make "a long time"
    Fred> not be "forever". That's reasonable. But in the case called
    Fred> out here, it seems like the lifetime of the prefix in an RA
    Fred> should be long enough that a host can miss an RA refresh and
    Fred> not lose the address, and short enough that we don't have to
    Fred> call in the national guard if someone trips over a cable or a
    Fred> power supply goes spitzensparken.

    Fred> What do we need to do to change that RFC 4861 requirement? If
    Fred> what is required is an Internet Draft in 6man (and I would
    Fred> expect it is), I'd be willing to write that draft.

I'm trying to understand things here.
We have, I think four lifes times around a homenet:
   1) DHCPv6 PD
   2) Router Lifetime.
   3) Prefix Valid Lifetime
   4) Prefix Preferred Lifetime

We expect #1 to be large, on the order of weeks in most cases, lowered
only to minutes in the cases where operators expect to move users around
(such as rebalancing the load on the CMTS).

I expect the router lifetime to be on the order of minutes so that a
host stops using a route sooner.  We could modify this more if a host
follows the rules of RFC4191 Type C.  I'm unaware of any Linux machines
being Type C, and I haven't seen *BSD do this, although maybe OSX does.

Except for being limited by #1, it seems that we want to have a
Preferred Lifetime rather low only in the multi-router case.  

Maybe the right answer is dynamic: as soon a router, see another LSA,
they lower their Preferred Lifetime so that if there is a chance to
survive a topology change, then the host has a better chance of doing so
without having the wrong address for that link for too long.

I admit that I still don't really understand how I should set my valid
lifetimes.  It seems that they can be quite high in general.

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Oct 2011 16:16:14 -0400

> I think you meant RFC3633 here right? (DHCP-PD)

yes; typo...

> advertised was limited to be no more than the lifetime in the PD.

Yes. One would hope that it would be on the order of two announcement cycles; allow for losing one RA announcement, but call foul if two are lost in succession.

>    Fred> expect it is), I'd be willing to write that draft.

Going back to my previous note, the issue was that Lorenzo stated that Linux (and he presumed all other implementations)
  - considered only the RA most recently received
  - developed an address in that prefix ONLY
  - used it until the prefix announcement expired.

That is of course not per RFC 4861. 4861 instructs that an address is calculated in every prefix received and held for possible use until it expires. RFC 3484 goes on to give instructions about the choice among such addresses. Thomas, later in that thread, asserts that Linux' correct operation per RFC 4861 has been tested and shown in various certification tests including USG.

At this point, I think the ball is in Lorenzo's court. If Linux in fact does something different (and therefore the certification is voided), that needs to be shown.

---

From: Ole Troan <[email-masked]>
Date: Sun, 9 Oct 2011 23:59:20 +0200

[...]

> Yes. One would hope that it would be on the order of two announcement cycles; allow for losing one RA announcement, but call foul if two are lost in succession.

please no. this makes for unstable addresses. addresses != routing.

>>   Fred> power supply goes spitzensparken.

a host should verify that its address is valid triggered by an L2 event.

I think we need some new work with regards to 'flash renumbering'.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Oct 2011 00:04:29 +0200

Erik,

> The zospf appears to have an approach for router ID collisions, but that probably isn't (widely) implemented.

indeed. zospf or whatever combination of zeroconf OSPF plus OSPF prefix assignment is new work.

> (In any case, we'd need to figure out what it means to have stable prefixes allocated - to interfaces or to links - but that is the prefix autoconfig part of the problem as opposed to the router co…

right. we should aim for a stable prefix given no topology changes. if a link partitions and merges there will have to be renumbering.
I think this will require stable storage, regardless of this being done via DHCP and a God server or via an autonomous approach like zOSPF.

cheers,
Ole

---

From: Acee Lindem <[email-masked]>
Date: Sun, 9 Oct 2011 20:01:35 -0400

> OSPFv2 implementations generally pick one of the IPv4 addresses of the system. Not sure I can make a general comment on OSPFv3.

Since OSPFv3 also uses a 4 byte router ID, our implementation will use the same algorithm for picking a router ID as OSPFv2. 

> ZOSPF is, AFAIK, an internet draft that has never been implemented.

Agreed. The 2002 draft died with its expiration in 2003. 

Acee

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Oct 2011 20:41:36 -0400

> Since OSPFv3 also uses a 4 byte router ID, our implementation will use the same algorithm for picking a router ID as OSPFv2. 

which is to say "any old thing it wants, quite often an IPv4 address"?

---

From: Acee Lindem <[email-masked]>
Date: Sun, 9 Oct 2011 20:53:15 -0400

> which is to say "any old thing it wants, quite often an IPv4 address"?

Correct, it uses the best or only configured IPv4 address in the context (aka, virtual router). Of course, we'd want to use something else for true auto-configuration. 

Thanks,
Acee

---

From: Mark Townsley <[email-masked]>
Date: Mon, 10 Oct 2011 00:48:55 -0400

> Correct, it uses the best or only configured IPv4 address in the context (aka, virtual router). Of course, we'd want to use something else for true auto-configuration. 

And, homenet is of course required to be able to operate in absence of IPv4 as well as dual-stack....

- Mark

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Oct 2011 05:02:19 -0400

> Correct, it uses the best or only configured IPv4 address in the context (aka, virtual router). Of course, we'd want to use something else for true auto-configuration. 

Yes. For my money, in the absence of an IPv4 configuration, that's probably derived from a MAC Address, a serial number, or something else that is an attribute of the bit of equipment. But apart from observing on possible sources, Jon Moy would probably put on an animated look and observe that the router id is a 32 bit number unique in the routing domain, not necessarily an address of any kind.

A tiny bit of history here. Back in 1991 when we were doing the testing that resulted in RFC 1246, we (the implementers of 23 different implementations, many of which were derivative from the Maryland Prototype, e.g. Rob Coltun's code) had a discussion about where the router id should come from, and I commented that I had doctored my implementation to select one of the IPv4 addresses in the area. What I just described was the discussion that followed. Maybe everyone else had already made the same choice, or maybe they changed their code soon after, but using one of the IPv4 addresses in the area was suddenly a pretty common solution. :-)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 10 Oct 2011 10:18:56 -0400

The subset of tree topology where a consumer places ones router behind
another router is *extremely* common. Statistics I saw several years ago
suggested that probably about 60% of ADSL customers in the US use this
topology. The most common cause for this topology is where the service
provider supplies a free ADSL router with a single port to a subscriber,
and the subscriber then puts their own multi-port router behind that
router. The ADSL router is configured to do the PPPoE, and is also
configured to automatically provide whatever public IP address it gets
to whatever is behind it (via DHCPv4, as a sort of automatic DMZ
function -- the ADSL router also uses that public IP address for its
needs). The ADSL router is often set to provide only that one address,
and not to support a full network of devices. Which is why consumers are
forced to use their own router. This also tends to be how VoIP router +
consumer's wireless router topology works.

I'm sure some people would like to argue as to why this is bad, or it
shouldn't be done. I'm not going to get into that argument. That
argument is irrelevant. The fact is that it's very, very common. 

I agree with those who say that we *don't* need to make sure IPv4 works
everywhere that IPv6 works.
But I think it's an absolute requirement that IPv6 MUST work everywhere
that IPv4 works.

And this is a very common case where IPv4 works. When going to IPv6, the
ADSL router will also be the device that establishes the IPv6
connection. Because the credentials are the same as for IPv4, and the
secondary router doesn't have those credentials. And the consumer forgot
the credentials long ago, and doesn't remember how to configure this
stuff anyway.

IMO, I believe that the best approach would be to solve tree
generically. Which means that the probability of "tree network" would
actually be "common, perhaps 30th percentile" (dividing my "60% in ADSL
networks" by 2).
Barbara

> -----Original Message-----

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Oct 2011 18:10:30 +0300

Barbara,

Thank you very much for providing a concrete data point! I also agree with what you say below:

> I agree with those who say that we*don't*  need to make sure IPv4 works

Jari

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Oct 2011 13:18:25 -0400

Thanks. That is a big update to my numbers, but one that is important here.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Oct 2011 11:24:33 -0700

On 10/9/11 8:33 AM, Michael Richardson wrote:
>
>>>>>> "Erik" == Erik Nordmark<[email-masked]>  writes:

Yes.

It is basically a home gateway (without WiFi - wired Ethernet only) with 
a SIM slot and a phone connector added. Thus it has all the usual 
protocols and knobs for Internet connectivity.

The backup device takes the same approach - start with a home gateway 
and add something (in that case a disk plus file sharing software) but 
don't remove anything.

   Erik

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 14:16:45 -0700

In message <[email-masked]>
Fred Baker writes:
 
> > Since OSPFv3 also uses a 4 byte router ID, our implementation will
> > use the same algorithm for picking a router ID as OSPFv2.
>  

A practical solution (of days past) using OSPF was to configure an
address that was not a link address, and then configure it as an alias
to the loopback and also advertise it as a /32 stub, and then tweak
applications to bind to that address.  This loopback address was
reachable even if an Ethernet subnet was partitioned (common).

Providers have all done this on their IPv4-only routers, allocating
the router-id from one or more small prefix which within the network
was all host routes.  That was fine for small number of routers
(hundreds or thousands) and lots of global prefixes (hundreds of
thousand) [note: "or" in the first case; "of" in the second case].

In the absense of this configuration or in an IPv6 network, the
assumption that the router-id is a reachable address is not a good
one.  It is also discouraged by the standards.

An IPv6 /64 has 2 sets of 4 bytes in every address even after tossing
out the top 64 bits.  So picking an address won't work.

What is really needed is a means to recover from a router-id
collision.  One router can detect another using the same router-id
easily enough.  An extension is needed to indicate a collision (there
is a denial of service potential with this).  The behaviour could be
for each router using that router-id (and supporting the extension) to
make another pick and readvertise.  It means taking down adjacencies
and bringing them back up, but perhaps a graceful restart extension
could smooth this.

This is putting lots of code in the little homenet router,
particularly if graceful restart is used.

Random number selection for router-id and this sort of recovery would
solve the zero config OSPF issue related to router-id selection.

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

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 14:18:18 -0700

In message <[email-masked]>
Acee Lindem writes:

On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
 
> Correct, it uses the best or only configured IPv4 address in the
> context (aka, virtual router). Of course, we'd want to use something
> else for true auto-configuration.
>  
> Thanks,
> Acee 

And on an IPv6 only homenet with no configured addresses it does what?

Curtis

---

From: Acee Lindem <[email-masked]>
Date: Mon, 10 Oct 2011 17:49:38 -0400

> And on an IPv6 only homenet with no configured addresses it does what?

Our Ericsson SmartEdge routers were never meant to be deployed in the home or to support complete auto-configuration - I was just responding to Fred's query as to what OSPFv3 implementations do today. 
If there is no IPv4 address available and no OSPFv3 Router-ID is explicitly configured, we'll log an error and shut the OSPFv3 instance down until such time as an IPv4 address or explicit router-id are configured.
A new draft is required for OSPFv3 auto-configuration. 
Thanks,
Acee

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 19:07:01 -0700

In message <[email-masked]>
Acee Lindem writes:
 
> >>> which is to say "any old thing it wants, quite often an IPv4 > address"?
> >> 
> >> 
> Our Ericsson SmartEdge routers were never meant to be deployed in the > home or to support complete auto-configuration - I was just responding > to Fred's query as to what OSPFv3 implementations do today. 
> If there is no IPv4 address available and no OSPFv3 Router-ID is > explicitly configured, we'll log an error and shut the OSPFv3 instance > down until such time as an IPv4 address or explicit router-id are > configured.

Acee,

I'll have to confess that my most recent employer's equipement was
also not intended for the home.  :-)

I'm sure you saw the suggestions I made in another response.  The fix
for autoconfig may be to pick a random number and create an OSPF
extension to advertise the detection of a collision on a given
router-id, then respond to the collision.  Any device using autoconfig
would have to support this extension.  If colliding with a router that
did not support the extension, that other router would do nothing, but
the autoconfig router would pick a new router-id.

The point is you can't make a unique 32 bit number out of a 48 bit
number or a 64 bit number or an 80 bit number (for a /48).  So you
might as well accept low probability of collision and define a way to
fix the situation.

The absolute worst case is a stomped on LSA that an old router doesn't
update until maxage expires.  That would be bad so maybe we need to
figure out what a legacy OSPF router would do on such a collision
where it got from a neighbor something it did not send as its own LSA.
Hopefully it would readvertise the right stuff and try to withdraw the
bad stuff.  The autoconfig router would just pick a new router-id.

It all sounds fine except maybe the backwards compatibility with no
changes.  Your the OSPF expert so ...

Curtis

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Oct 2011 07:05:09 +0300

Home routers would also have MAC addresses, but again, if we need a 32-bit quantity then shortened 48/64 bit identifiers may (theoretically) have collisions.

That being said, if the home routers have to discover their IPv6 prefix through a protocol and store it in flash, they could probably do so also for a router ID. Unless there was some chicken and egg problem that required the router ID for all this discovery to work...

Jari

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Oct 2011 08:26:23 -0400

> 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 e…

(z)ospf requires the router to have a router id in order to join the network, which it has to do before it can receive the LSAs from other routers in the area to inspect their subnet prefixes. So making the router id dependent on the prefix doesn't make a lot of sense to me.

While a MAC Address is not guaranteed to be globally unique, it is intended to be; places where duplicates have been seen tend to be manufacturing errors. From that perspective, grabbing the least significant 32 bits from a MAC address as a first guess seems reasonable. What one would then need to do is 

1) receive the LS Database
2) inspect for other instances of the same router id
3a) if found, attempt to flush the LSA (it might be an old LSA from the same router)
3b) if flushed and it is then re-advertised back, there is a collision and the other router is asserting ownership; pick a random number

One obviously doesn't actually announce any LSAs using the router ID until a unique router id is established.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 10:27:26 -0400

>>>>> "Fred" == Fred Baker <[email-masked]> writes:
    Fred> On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote:

    >> That being said, if the home routers have to discover their IPv6
    >> prefix through a protocol and store it in flash, they could
    >> probably do so also for a router ID. Unless there was some
    >> chicken and egg problem that required the router ID for all this
    >> discovery to work...

    Fred> (z)ospf requires the router to have a router id in order to
    Fred> join the network, which it has to do before it can receive the
    Fred> LSAs from other routers in the area to inspect their subnet
    Fred> prefixes. So making the router id dependent on the prefix
    Fred> doesn't make a lot of sense to me.

    Fred> While a MAC Address is not guaranteed to be globally unique,
    Fred> it is intended to be; places where duplicates have been seen
    Fred> tend to be manufacturing errors. From that perspective,
    Fred> grabbing the least significant 32 bits from a MAC address as a
    Fred> first guess seems reasonable. What one would then need to do
    Fred> is

What do we do in that rare case where the bottom 32 of the MAC are
duplicated?   

Also consider that virtual switches (VMware, XEN, etc.) all pretty much
use the same set of MAC addresses.  VMware has a 50:  prefix that they
use, XEN has another, and did you know that 10:00:00 (curisously like
10/8) is reserved for private use... 

So, it would be good for zospf text to say something about this.
I think that we can use 32-bits of MAC address in most cases.

    Fred> One obviously doesn't actually announce any LSAs using the
    Fred> router ID until a unique router id is established.

okay.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 11 Oct 2011 11:02:07 -0400

> What do we do in that rare case where the bottom 32 of the MAC are

The conflict must be resolved with one router selecting a different Router-ID. That is a problem that would need to be handled in any OSPFv3 auto-configuration draft.
You cannot have two routers in the same routing domain with the same OSPFv3 Router ID since their LSAs cannot be differentiated from one another and the two routers with the same Router-ID will get into a flooding war.  
Thanks,
Acee

> <ATT00001>_______________________________________________
> homenet mailing list
> [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Oct 2011 11:56:53 -0400

> What do we do in that rare case where the bottom 32 of the MAC are

Pick a random number. Note that we agree it is a rare case. If it's a router, it probably has more than one MAC Address...

> 10/8) is reserved for private use... 

Yes, and homes frequently use virtual switches.

To be really honest, yes, it would be good for zospf - if we recommend that - to make some suggestions. That said, there is no reason for the suggestions to be normative. What OSPF requires is that the RID is unique in the area. It does not require that it be derived from any given datum.

---

From: Russ White <[email-masked]>
Date: Tue, 11 Oct 2011 14:50:17 -0400

>     Fred> router ID until a unique router id is established.

You need a unique identifier at the equipment level for anything you
intend to auto-configure --autoconfiguring uniqueness is a very hard,
probably impossible, problem on a global scale. So we need to count on
this one thing, no matter what else we might need to back in to.

Now, it might be possible to some hash over a GPS location for a "base,"
and then add on MAC addresses, or some such, but IMHO, homenet should
start with the assumption of having some sort of "unique id" in every
device deployed, available through some sort of local API, and work from
there.

Let's solve problems that can actually be solved... :-)

:-)

Russ

---

From: Jim Gettys <[email-masked]>
Date: Tue, 11 Oct 2011 15:10:33 -0400

> 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 res…
Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my
area of expertise. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Oct 2011 12:17:33 -0700

On 10/10/2011 7:18 AM, STARK, BARBARA H wrote:
> forced to use their own router.
...

They also do this commonly to introduce or upgrade their WiFi service at 
home without needing to reconfigure the subscriber access box.

To a lot of consumers, IF things can be plugged together, then they WILL BE.

> This also tends to be how VoIP router +

That too...

Joe

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 20:38:59 -0400

>>>>> "Russ" == Russ White <[email-masked]> writes:
    Russ> You need a unique identifier at the equipment level for
    Russ> anything you intend to auto-configure --autoconfiguring
    Russ> uniqueness is a very hard, probably impossible, problem on a
    Russ> global scale. So we need to count on this one thing, no matter
    Russ> what else we might need to back in to.

    Russ> Now, it might be possible to some hash over a GPS location for
    Russ> a "base," and then add on MAC addresses, or some such, but

We've assumed a unique MAC, which is 48 bits long. 
But OSPF router-id is 32 bits.    What is the likelyhood of a collision 
in the bottom 32-bits of the MAC?

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 12 Oct 2011 11:01:44 +0800

Hi Jim,

I fully agree with you. Declaring OLSRv2 etc. out of scope just because
"a home is not a mesh network" seems simplistic to me. As you explained
in your mail, many of the problems that mesh networks already solve
successfully today, can be very similar in a home: dynamic topology, no
skilled network operator centrally managing the devices, wireless and
wired devices, limited resources on the routers etc. These were exactly
the motivation for developing such protocols in MANET.

Best regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 12 Oct 2011 11:14:36 +0800

Hi,

> in the bottom 32-bits of the MAC? 
It seems to me that this discussion about duplicate addresses / unique
MAC tool already place in the IETF a number of years ago, e.g. as
reflected in RFC 4862 (IPv6 Stateless Autoconfiguration, section 5.4),
where duplicate address detection is mandatory. It wouldn't have to be
if the assumption holds that all MAC addresses are unique.

Even though the probability of collisions may be low, because of
manufacturer errors / virtual interfaces and virtual machines /
reduction from 48bits to 32bits, there could be collisions. I am not
convinced that we can make Russ' assumption that we need unique
identifiers at equipment level (or at least that seems inconsistent with
previous IETF decisions, so we would need to make a strong case what has
changed since then). I do agree with Russ, though, that verifying
uniqueness is hard.

Regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 12 Oct 2011 11:28:46 +0800

Jari,

On 10/11/11 12:05 PM, Jari Arkko wrote:
> Home routers would also have MAC addresses, but again, if we need a
> 32-bit quantity then shortened 48/64 bit identifiers may
> (theoretically) have collisions.
>
> prefix through a protocol and store it in flash, they could probably
> do so also for a router ID. Unless there was some chicken and egg
> problem that required the router ID for all this discovery to work...
I agree. Since we need to configure unique prefixes to each router in
the home anyway, it should not be any problem to do the same for a
router ID (or even just use an address from the configured prefix as
router ID, which should then be unique). A while ago, there were some
plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop
network for configuring prefixes in the network. As in a home network, I
assume there is always at least one border router with the global
prefix, specifying something like that seems to be reasonable for me (in
a MANET, that can be more difficult, because there is not necessarily
such a central entity as the border router).

Regards
Ulrich

---

From: C Chauvenet <[email-masked]>
Date: Wed, 12 Oct 2011 00:44:02 -0700

Hi Jim, 

I agree with you.

Let me just add a few words on #2 : 

You are absolutely right that pulling cable is hard and expensive.
That is the rationale of PLC : Using existing wires.

PLC is already used reliabily for high speed networking, but you are correct that it is
not as popular as Wireless. Mostly because networking devices already embed a Wifi and/Or Ethernet
interface, rather than a PLC interface. 
So people don't see the need of buying additional material for a connectivity they already have…

Though people use PLC because they feel surrounded by RF, or they cannot reach some point of the network with wireless, 
or the PLC device is provided by their ISP (like in France).
(There are others reasons for using PLC outside the home, but I think it is out of the scope of Homenet).

PLC also suffers from a lack of standardization, and different technologies/Standards are often non-interoperable, or simply cannot coexist on the same electrical grid.

An effort is ongoing in IEEE P1901.2 to create a standard for low frequency narrowband PLC.

Just my 2 cts,
Cédric.

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Oct 2011 04:50:34 -0400

> You are absolutely right that pulling cable is hard and expensive.

Pulling cable is indeed hard and expensive. In my experience, it is the right thing for some applications, such as TV and my home office. Personally, I have both wired and wireless throughout the house; my personal rule is that I use the shared wireless network for activities that move around, to provide convenience at the expense of consistency and bandwidth, and wired for things that stand still, to provide stable bandwidth at the price of a one-time wiring effort.

---

From: Russ White <[email-masked]>
Date: Wed, 12 Oct 2011 07:51:31 -0400

> Pulling cable is indeed hard and expensive. In my experience, it is the right thing for some applications, such as TV and my home office. Personally, I have both wired and wireless throughout the h…

I do the same --I pull cable for televisions, and even for locations
where a desktop or laptop is going to be sitting on a regular basis. So
I think we should expect wired and wireless as the norm, rather than
expecting wireless all the time.

While I wouldn't want to rule OLSRv2 completely out, I think it should
compete head to head with an extended OSPF and an extended IS-IS, or
even other efforts afoot. I'd rather see requirements first, and a good
solid evaluation of what's available against those requirements, rather
than choosing technologies out of the gate.

:-)

Russ

---

From: C Chauvenet <[email-masked]>
Date: Wed, 12 Oct 2011 04:57:32 -0700

> expecting wireless all the time.

I agree.
I may have precised "pulling *NEW* cable is hard and expensive" in my sentence.

> than choosing technologies out of the gate.

I think it is a good process, for each competing protocol.

Cédric.

---

From: Russ White <[email-masked]>
Date: Wed, 12 Oct 2011 08:09:17 -0400

> in the bottom 32-bits of the MAC? 

Ah, I see the problem... There is a pretty high likelihood of a
collision, actually, at least as long as you use multiple vendors in
your home network. It's bound to happen to someone, someplace.

So, a suggestion to resolve this:

1. Use the lower 32 bits of one of the mac addresses on the box as the
initial id.

2. Add a new field to the router capabilities that carries the full 48
bit mac address, or even some munged together "longer id," based on
multiple mac addresses on the device, or some such.

3. During initial setup, if you receive a capability that appears to be
from yourself, you open this secondary id section to find out if it's
really you, or someone else who happens to have the same 32 bit id.

4. If it's really you, discard the packet.

5. If it's not really you, and if the other router's "large id" is lower
than yours, choose another mac address from which to take your local id,
and restart your ospf process.

6. If it's not really you, and the other router's "large id" is higher
than yours, then send a router capabilities LSA unicast to this "other
router," so the "other router" knows to change its id.

I don't think IS-IS would have this problem.

:-)

Russ

---

From: Jim Gettys <[email-masked]>
Date: Wed, 12 Oct 2011 12:11:42 -0400

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

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

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

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

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

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

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

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

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

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

---

From: Jim Gettys <[email-masked]>
Date: Wed, 12 Oct 2011 12:37:05 -0400

> problem that required the router ID for all this discovery to work...
As to storing in flash, since most in homenet have not typically worked
on embedded systems, worse luck...

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

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

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

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

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

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

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

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

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

                    - Jim

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 14:38:31 -0700

> techniques (which is why journaling file systems such as jffs2 are so

Jim,

Nice reminder on the limitations of flash and some of the workarounds.
Some neat hardware does erase on write and buffers the write itself,
and can store enough energy in a small battery to flush the writes on
power down.  Its faster and maximized flash life.  Its essentially a
RAM front ended flash.  I think it was expensive for consumer use.
For provider equipement it makes logging to flash feasible thereby
avoiding spinning media which may object to a 65 C ambient.

Routing protocols are even less stateful than DHCP in this regard.
There is no "lease" to be preserved between boots.  The configuration
(today in non-zero-config situations) is not sufficiently immuatable
to put in a squashfs but may not be changed for months or years.  Any
old filesystem over bare flash is OK for that.

Everthing else in a routing protocol is acquired at run time and
therefore should be in RAM (ramfs or in application space RAM).

With a zero config routing protocol at worst there would be a small
amount of information that would generally be updated only once if at
all on a reboot.  Using a random number for router ID and remembering
it across reboots and supporting a router ID collision repair would
support this, since the collision on reboot would be rare even if the
router was moved within the topology.  If the router ID was not tied
to an address it would not have to change when moved within the
topology.

Even the interesting problem of moving a router wire by wire would
work.  The adjacency and any address allocation acquired over it would
be lost with each wire pulled.  When plugged in elsewhere, new
addressing would be needed and it would bring up a new adjacency or
set of adjacencies (or more correctly participate in DR election and
adjacency with the DR and BDR if there was a dumb switch in there and
it were a true BCAST subnet).

An interesting observation is that two addresses can be requested if
the DR election is among two parties and after election it is apparent
that they are the only two.  If a third is added it is not a point to
point link and a larger block can be requested.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 16:29:40 -0700

> diversity is one of the concerns, and interference (of various sorts).

Very good points.  Much of the discussion has been focused on the
single home in isolation.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 17:04:30 -0700

In message <[email-masked]>
Michael Richardson writes:
 
> >>>>> "Russ" =3D=3D Russ White <[email-masked]> writes:
> We've assumed a unique MAC, which is 48 bits long.=20
> But OSPF router-id is 32 bits.    What is the likelyhood of a collision=20
> in the bottom 32-bits of the MAC?=20

Each organization has one or more unique OUI which includes one of the
bottom four bytes.  The next three (of those four) are unique only
within the OUI which is the top three bytes (but with two bits given
special meaning).

So what are the chances that two organization start numbering the
bottom bits at zero and work their way up until the bottom three bits
are filled.  Since there are way more than 256 organizations that have
an OUI, collisions, while rare, can happen.

If there is a way to recover from a collision, then its a complete
non-issue and a random number can be used.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 18:01:08 -0700

In message <[email-masked]>
 
> such a central entity as the border router).

Ulrich,

Whatever ends up being specified should require no configuration and
work when there are:

  zero border routers providing a prefix (outage and/or partition)

  one border router providing a prefix (the easy case)

  multiple border routers providing a prefix

For the large apartment building example that Jim gave, we really
should consider scaling behavior when there are a large number of
border routers providing a prefix within a given mesh.

Curtis

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Oct 2011 12:19:29 +1100

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: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Oct 2011 12:27:31 +1100

In message <[email-masked]>, Jim Gettys writes:
> Or you solve the time problem some other way...
> 
> Batteries die too...
>       Jim

Indeed.  It should be a user servicable part.

As to solving it other way, "leap of faith" springs to mind.

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 13 Oct 2011 09:44:11 +0800

> than choosing technologies out of the gate.

Hi Russ,

I fully agree. There should be an evaluation against the requirements.
My point was just not to rule out OLSRv2 (or other protocols) based on
the fact that a protocol is used, amongst other, in mesh network
deployments.

Ulrich

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 19:28:34 -0700

In message <[email-masked]>
Russ White writes:
 
> > Pulling cable is indeed hard and expensive. In my experience, it is
> > the right thing for some applications, such as TV and my home
> > office. Personally, I have both wired and wireless throughout the
> > house; my personal rule is that I use the shared wireless network
> > for activities that move around, to provide convenience at the
> > expense of consistency and bandwidth, and wired for things that
> > stand still, to provide stable bandwidth at the price of a one-time
> > wiring effort.
>  
> where a desktop or laptop is going to be sitting on a regular
> basis. So I think we should expect wired and wireless as the norm,
> rather than expecting wireless all the time.
>  
> even other efforts afoot. I'd rather see requirements first, and a
> good solid evaluation of what's available against those requirements,
> rather than choosing technologies out of the gate.
>  
> :-)
>  
> Russ

Russ,

At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted
pair.  [Well someone pulled it, but not me.]  Anyone remember vampire
taps in 10base2?  What a reliability headache!

I pulled 10base5 coax at home before I pulled twisted pair and before
trying the early DEC Wavlan stuff that preceeded WiFi (again, at
home).  Too bad I moved and had to pull wire again (but I like the
result).

Back on topic: I do think we should consider OSPF (not so keen on
ISIS, but OK) and should not rule out OLSRv2 or other LLN related work
and MANET work (though I'm far from an expert on LLN or MANET).

We will have to extend OSPF to make zero config possible.  The
extensions should be completely backwards compatible if at all
possible.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 19:46:58 -0700

> multiple mac addresses on the device, or some such.

Not backwards compatible.  The older OSPF routers will see only the
non-unique 32 bits and the network won't work.

> I don't think IS-IS would have this problem.

If the other router doesn't implement the extension you've described,
the network is hosed forever.

If you have more than one link you should receive the LSA (or LSPDU)
that you advertised.  If you have one link, you won't.

If you receive a LSA (or LSPDU) that clearly you didn't advertise,
then you have a collision.  *Both* routers should pick a new router-id
if this condition is detected and they implement this extension.

Don't even bother using a MAC address for the router-id.  Use a random
number.  If a collision occurs, use a different random number.  This
should also work for interfaces without a MAC (not that many homes run
POS today, but maybe some layer-2 in the future).

Here is where it if fuzzy if one router is a legacy router.  It may
not look at LSA (or LSPDU) apparently from itself or may just log a
problem and continue.  When backing off, the bogus advertisements need
to be withdrawn.  A possible backward compatibility wrinkle exists if
the legacy router does not readvertise (being legacy it will not pick
a new router-id).  The problem could persist for maxage.  Better than
forever but still not good.

Don't use a non-configured router-id if you don't support this ability
to back off.  (Routers today don't pick a random router-id and they
shouldn't unless they can backoff).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 21:08:22 -0700

> backed clock or all the crypto will be broken.

Having a clock is not hard but I don't think your statement is true.

Some crypto does not require time, but rather just entropy (a nonce or
challenge).  For crypto that does require time the former can be a
bootstrap of sorts, possibly to get ntp going if very accurate time is
needed (for some reason).

For example ssh with rsa or dsa does not require time.  You need to
know what month and year it is to be good enough as far as checking
certificates.

A lot of the KARP work does require knowing the time to prevent
replay attack.

Curtis

---

From: Russ White <[email-masked]>
Date: Wed, 12 Oct 2011 08:20:27 -0400

> such a central entity as the border router).

I think there will be, by default, multiple "border routers." In my
house I currently have 6 devices that provide internet connectivity, and
I assume that number is going nowhere but up. Each of these devices
could, in theory, be a "border router," in some way.

What saves the day is that I don't allow 4 of them to "talk" on the
internal network, and the other two are carefully segregated. But
there's no reason for any of this --there's no reason I shouldn't be
able to use all of them, especially as some of them might be able to
reach outside networks in addition to the Internet at large that others
might not be able to.

:-)

Russ

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 13 Oct 2011 01:52:26 -0400

Curtis,

At about same time you were moving/re-wiring your new house, I've started to use Ethernet over power and have been using it since then :)

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Wednesday, October 12, 2011 19:29
To: Russ White
Cc: [email-masked]
Subject: Re: [homenet] Thoughts about routing - trends

Russ,

Curtis

---

From: Acee Lindem <[email-masked]>
Date: Thu, 13 Oct 2011 05:55:07 -0400

One assumption could be that a legacy router would not support auto-config and, if deployed, would have to be configured with a unique Router ID (as they are today).  
Thanks,
Acee

---

From: Russ White <[email-masked]>
Date: Thu, 13 Oct 2011 07:53:41 -0400

> taps in 10base2?  What a reliability headache!

Pulled from cable hanging in a "plenum" in a secure building... Because
there was no way to get cable floor to floor other than through that
single shaft. For a Xerox Star system. Then there was the token bus for
the little Novell network over in legal --another disaster. <blech>

> and MANET work (though I'm far from an expert on LLN or MANET).

IS-IS is easier to get to "zero config," and it's actually simpler in
operation... Which is why I brought it up. :-)

> extensions should be completely backwards compatible if at all

Yes, I agree... Or we need w new wired/wireless protocol that jumps both
worlds, and would actually be acceptable and implemented by a large
number of vendors. But that's another entire problem space...

:-)

Russ

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Oct 2011 09:49:32 -0400

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:
    >> Batteries die too...  Jim

    Mark> Indeed.  It should be a user servicable part.

    Mark> As to solving it other way, "leap of faith" springs to mind.

DHCP has an NTP server option.  Does IP6CP?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Oct 2011 09:55:04 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    >> 2. Add a new field to the router capabilities that carries the
    >> full 48 bit mac address, or even some munged together "longer
    >> id," based on multiple mac addresses on the device, or some such.

    Curtis> Not backwards compatible.  The older OSPF routers will see
    Curtis> only the non-unique 32 bits and the network won't work.

There are no zOSPF routers today.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Oct 2011 10:05:42 -0400

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

---

From: Jim Gettys <[email-masked]>
Date: Thu, 13 Oct 2011 10:40:19 -0400

> Bootstraping time enough to get DNSSEC to work is important.
Yup. And DNSSEC does not require precise time as you note.

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

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

---

From: Jim Gettys <[email-masked]>
Date: Wed, 12 Oct 2011 21:22:51 -0400

Batteries die too...
      Jim

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 11:11:14 -0700

In message <[email-masked]>
Acee Lindem writes:
 
> One assumption could be that a legacy router would not support
> auto-config and, if deployed, would have to be configured with a
> unique Router ID (as they are today).

Got that.

   Don't use a non-configured router-id if you don't support this
   ability to back off.  (Routers today don't pick a random router-id
   and they shouldn't unless they can backoff).

> Acee

The key uncertainty is the effect of a collision on a legacy router.

This looks like it is covered.  (indentation changed)

  [RFC2328]  13.4.  Receiving self-originated LSAs

    It is a common occurrence for a router to receive self- originated
    LSAs via the flooding procedure. A self-originated LSA is detected
    when either 1) the LSA's Advertising Router is equal to the
    router's own Router ID or 2) the LSA is a network- LSA and its
    Link State ID is equal to one of the router's own IP interface
    addresses.

    However, if the received self-originated LSA is newer than the
    last instance that the router actually originated, the router must
    take special action.  The reception of such an LSA indicates that
    there are LSAs in the routing domain that were originated by the
    router before the last time it was restarted.  In most cases, the
    router must then advance the LSA's LS sequence number one past the
    received LS sequence number, and originate a new instance of the
    LSA.

    [...] In all these cases, instead of updating the LSA, the LSA
    should be flushed from the routing domain by incrementing the
    received LSA's LS age to MaxAge and reflooding (see Section 14.1).

  [RFC5340]  4.5.1.  Receiving Link State Update Packets

    [...]  In IPv4, eight steps are executed for each LSA, as
    described in Section 13 of [OSPFV2].  For IPv6, all the steps are
    the same, except that Steps 2 and 3 are modified as follows:

      [stub or nssa or reserved scope changes]

It seems then that if the auto-config router picks a new router-id,
the legacy router will correct any damage.  Perhaps the legacy router
will do this for the wrong reasons (collisions, not stale leftovers
from a restart elsewhere), but it seems like it will take action to
fix it.

Acee - should this move to OSPF?  Others - No cross posting please.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 11:42:36 -0700

In message <[email-masked]>
 
> There are no zOSPF routers today.

Yes and there are/were ATM switches that implement RFC1577, LANE,
MPOA, and NHRP.  None of that worked very well and it all is
essentially abandoned work now.  Pre-existence alone is not a worth
while evaluation criteria.

If zOSPF works perfectly, including in the presence of legacy routers
which don't look at a new 48 bit mac address router-id extension, we
have no reason to continue the discussion.  We just indicate "use
zOSPF" and we're done.

There seems to be consensus that we're not done.

Curtis

---

From: Jim Gettys <[email-masked]>
Date: Thu, 13 Oct 2011 15:03:33 -0400

> There seems to be consensus that we're not done.
On my part, I'm interested in understanding the following:
    o scaling properties: I worry about the apartment building case, and
related dense mesh case.
    o behaviour when routing both wired and wireless networks.
    o multicast behaviour and impact on wireless networks.
    o running code
And I'll ask the same about any other routing protocol you wish to
name.  I'm an equal opportunity parade rainer...
                - Jim

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 13:18:45 -0700

Off list.

> the little Novell network over in legal --another disaster. <blech>

I managed to avoid token ring and novell.

> operation... Which is why I brought it up. :-)

I've used both.  Why do you think ISIS is simpler in operation?
Because people love to deal with NSAPs?

> number of vendors. But that's another entire problem space...

We agree on something.  That's good.  :-)

The clueless vendor problem space is a tough one.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 13:30:48 -0700

In message <[email-masked]>
 
> DHCP has an NTP server option.  Does IP6CP?

If you are trying to validate keys or certificates or proteocol
extensions that require knowing the time of day, then using the DHCP
supplied NTP server might not be a great idea.

I'm not fond of protocols that rely on time or monotonically
increasing reboot counts and have no fallback.  I advocated in OSPF
discussions relevant to KARP (to no avail) having at least a fallback
to a mechanism in which time of day or reboot count was not
significant.

This means no certificate expiration check is possible for the
fallback but its better than no connectivity.  The lack of certificate
expiration can be compensated for by creating an explicit revokation
after the key expires and storing that.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 13:41:52 -0700

In message <[email-masked]>
Michael Richardson writes:
 
> 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.
>  

I was thinking routing protocols and KARP.

We are talking about routers and relying on DNS to get routing up is
always a really bad idea.  Relying on NTP to get routing up is also a
bad idea.

Neither KARP, as defined, or DNSSEC, are candidates for zero
configuration.  If the user can configure KARP and DNSSEC they are
perfectly capable of using a backdoor, like ssh, to set the time of
day after a reboot that lost time-of-day.

Sorry, but I lost track of why this is an issue for homenet.  What
zero config crypto are we talking about that may care if it loses time
of day?

Curtis

---

From: Jim Gettys <[email-masked]>
Date: Thu, 13 Oct 2011 16:44:05 -0400

> zero config crypto are we talking about that may care if it loses time
DNSSEC.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 14:40:34 -0700

>     o scaling properties: I worry about the apartment building case, and

Yep.  OSPF as is may not be appropriate for wireless mesh.  WG needs
to consider this.

>     o multicast behaviour and impact on wireless networks.

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.

> name.  I'm an equal opportunity parade rainer...

I haven't checked cerowrt to see how much configuration is required of
OSPF.  If it is quagga, then a router-id has to be configured and each
interface has to have OSPF explicitly enabled all with a Cisco style
line oriented config.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 15:15:33 -0700

> end-to-end seems like the right strategy.

Trimmed response.

I don't follow the logic here.

I don't see any relationship between "routers are already being
attacked" and DNSSEC.

The homenet user is not going to get DNS or DNSSEC configured for the
LAN addresses on their network so I'm not sure why the topic is even
relevant to homenet.

Back in the days when I was involved in big-I Internet operations
routers purposely didn't run rely on DNS to avoid a chicken and egg
problem (router can't reach DNS therefore routing is down).  Even logs
used IP addresses and could be translated after the fact if need be.

I'm quite knowledgeable in routers getting attacked.  The homenet
routing protocol would be wise to use GTSM on things like OSPF.  Open
routing on wireless might still be a bad idea.  Maybe keys or shared
secret has to be added for wireless making it non-zero config.

Curtis

---

From: Jim Gettys <[email-masked]>
Date: Thu, 13 Oct 2011 19:15:08 -0400

> LAN addresses on their network so I'm not sure why the topic is even

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

> secret has to be added for wireless making it non-zero config.

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Oct 2011 16:37:45 -0700

On Oct 13, 2011, at 1:30 PM, Curtis Villamizar <[email-masked]> wrote:
> increasing reboot counts and have no fallback.

+1

Let's not add time as an attack vector. 

Joe

---

From: Jim Gettys <[email-masked]>
Date: Thu, 13 Oct 2011 19:50:06 -0400

> 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.
> 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
Quagga has been packaged.  You can build other  stuff and packaged it
too, and the code is available to be modified.
                - Jim

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Oct 2011 18:09:33 -0700

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

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

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

Are there any cases this does not cover?

As to what to do if there is a collision, I'm not sure. zOSPF says what you
and your neighbours should do if the colliding router is on your link, but I
don't know if that's enough if the colliding router is elsewhere. Any OSPF
experts know the answer to this?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Oct 2011 22:27:58 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    Curtis> Neither KARP, as defined, or DNSSEC, are candidates for zero
    Curtis> configuration.  If the user can configure KARP and DNSSEC
    Curtis> they are perfectly capable of using a backdoor, like ssh, to
    Curtis> set the time of day after a reboot that lost time-of-day.

huh?
DNSSEC just requires the . key be distributed in the router's firmware.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Oct 2011 22:43:12 -0400

>>>>> "Joe" == Joe Touch <[email-masked]> writes:
    Joe> On Oct 13, 2011, at 1:30 PM, Curtis Villamizar
    >> increasing reboot counts and have no fallback.

    Joe> +1

    Joe> Let's not add time as an attack vector.

So, hypothetical attacks via DHCP, which require access to impersonate
the DHCP or PPP server of the ISP are more important than getting a
notion about time so you can prevent DNS attacks?

Tet's talk about what other things you can do if you can hijack the
network connection like that... and how many of them are resolved if
DNSSEC can be used.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 20:28:09 -0700

In message <[email-masked]>
 
> DNSSEC just requires the . key be distributed in the router's firmware.

duh.

I'm thinking about acting as a NS and signing the zone.  Never mind.
For DNSSEC resolver no configuration is needed.

For that purpose getting time of day through NTP or even timed (not
suggesting timed) would be fine.

Curtis

---

From: Acee Lindem <[email-masked]>
Date: Fri, 14 Oct 2011 12:45:12 -0400

On Oct 13, 2011, at 9:09 PM, Lorenzo Colitti wrote:

On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar <[email-masked]<mailto:[email-masked]>> wrote:
Random number selection for router-id and this sort of recovery would
solve the zero config OSPF issue related to router-id selection.

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

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

As to what to do if there is a collision, I'm not sure. zOSPF says what you and your neighbours should do if the colliding router is on your link, but I don't know if that's enough if the colliding router is elsewhere. Any OSPF experts know the answer to this?

A new OSPFv3 mechanism is required in support of this. Today, any LSA received with the OSPFv3 router's Router-ID is considered to be a stale self-originated LSA.

Thanks,
Acee

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Oct 2011 09:48:00 -0700

> Are there any cases this does not cover?

On number 3, there is a race condition. If the router took some time to boot, this takes care of itself; if this is a flash restart (OSPF started up within one or two HELLO intervals of going down) there is some possibility that the neighbor simply has some old state. Note that the OSPF Spec has the router initially send a HELLO and then start looking for HELLOs from peers that announce it; it would be good for OSPF to instead wait for one HELLO interval so that it sees the HELLOs from other routers on the LAN before announcing itself if it's not sure about the uniqueness of its RID.

On number 4, that would be a Router LSA or Network LSA; in a LAN subnet, the RIDs of the routers in the subnet are in the Network LSA.

> As to what to do if there is a collision, I'm not sure. zOSPF says what you and your neighbours should do if the colliding router is on your link, but I don't know if that's enough if the colliding…

What the router needs to do is 

(1) NOT send an LSA using the RID into the LS database, as this will confuse everyone else 
(2) it would be good etiquette to announce one more HELLO in which it lists no neighbors so that all of its neighbors, and especially the DR, think it's going down. That way it doesn't get into the Network LSA, or if it already did, it will be removed.
(3) It has to change its RID and start from the beginning.

The good news is that it now has some subset of the LSA Database, so the second exchange will be somewhat quicker, and it already knows who the DR is in at least that subnet.

"Random number" is a good description of the source for the RID. MAC Addresses and equipment serial numbers tend to be reasonable seeds, and a router will usually have more than one such. If it used one MAC address and that didn't play, it might try another. If push comes to shove, a call to random() is probably in order.

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 15 Oct 2011 18:35:08 -0700

In message <[email-masked]>
Fred Baker writes:
 
> > zOSPF says what do do in the case of collisions if the router with
> > duplicate ID is on the same link, but not if it is
> > elsewhere. However, I think it can be made to work like this:
> > 
> > 3. If you see a hello packet from a neighbour with your own router
> > ID, you have a collision on the local link. Change it and back off.
> > 4. If you see a router LSA listing you as a neighbour, but the
> > router ID that originated this LSA is not a neighbour of yours, you
> > have a duplicate router ID. Change it and back off.
> > 
> On number 3, there is a race condition. If the router took some time
> to boot, this takes care of itself; if this is a flash restart (OSPF
> started up within one or two HELLO intervals of going down) there is
> some possibility that the neighbor simply has some old state. Note
> that the OSPF Spec has the router initially send a HELLO and then
> start looking for HELLOs from peers that announce it; it would be good
> for OSPF to instead wait for one HELLO interval so that it sees the
> HELLOs from other routers on the LAN before announcing itself if it's
> not sure about the uniqueness of its RID.
>  
> On number 4, that would be a Router LSA or Network LSA; in a LAN
> subnet, the RIDs of the routers in the subnet are in the Network LSA.

An ISIS LSPDU fragment is *really big*.  To avoid having to check the
whole thing to see if it changed, ISIS routers checksum relevant parts
of the LSPDU and compare to the checksum to the prior advertisements.
That is how they tell if they might have a new LSPDU fragement and
might have to reflood it and update the LSDB.  Brute force compare
works too but just takes a lot longer.

OSPF LSA are smaller but more numerous, but there is no reason that
the LSA can't be checksumed.  Any OSPF router should know what LSA it
originated.  If an LSA doesn't resemble anything it originated, pick
another router-id.  If it was a stale LSA, it does no long term harm
to pick a new LSA after a reboot.

Every LSA has "Advertising Router" starting at byte 8 for both OSPFv2
or OSPFv3.  The packet formats are in Appendix A in both rfc2328 and
rfc5340.  If "Advertising Router" equals "me" and this LSA looks
bogus, there is likely to be a router-id collision.  Or it could be a
stale LSA from a fast reboot, but so what, just pick another router-id
and start over.

> > As to what to do if there is a collision, I'm not sure. zOSPF says
> > what you and your neighbours should do if the colliding router is on
> > your link, but I don't know if that's enough if the colliding router
> > is elsewhere. Any OSPF experts know the answer to this?
>  
> (2) it would be good etiquette to announce one more HELLO in which it
> lists no neighbors so that all of its neighbors, and especially the
> DR, think it's going down. That way it doesn't get into the Network
> LSA, or if it already did, it will be removed.

All adjacencies have to go down to change router-id.  The other end of
the adjacency will withdraw its side of the adjacency.

If the other user of the router-id is not adjacent, the problem will
be discovered after the initial hello handshake and during the
database exchange, but it should occur before the first adjacency is
completely up.  The adjacency isn't up until the database exchange is
complete.

Any LSA that were advertised will be seen as stale by the former user
of that router-id.  They will be withdrawn.

> The good news is that it now has some subset of the LSA Database, so
> the second exchange will be somewhat quicker, and it already knows who
> the DR is in at least that subnet.
>  
> "Random number" is a good description of the source for the RID. MAC
> Addresses and equipment serial numbers tend to be reasonable seeds,
> and a router will usually have more than one such. If it used one MAC
> address and that didn't play, it might try another. If push comes to
> shove, a call to random() is probably in order.

Did anyone read my prior email in which I cited the RFCs and section
numbers and quoted the relevant text?

If not, look for:

  Message-Id: <[email-masked]>
  To: Acee Lindem <[email-masked]>
  cc: "[email-masked]" <[email-masked]>, Russ White <[email-masked]>,
      "[email-masked]" <[email-masked]>
  Reply-To: [email-masked]
  From: Curtis Villamizar <[email-masked]>
  Subject: Re: [homenet] Thoughts about routing
  In-reply-to: Your message of "Thu, 13 Oct 2011 05:55:07 EDT."
             <[email-masked]>
  Date: Thu, 13 Oct 2011 11:11:14 -0700

We should probably pick up this thread from that message (which had
relevant detail, but no one replied to it).

Curtis

---

From: Fred Baker <[email-masked]>
Date: Sat, 15 Oct 2011 21:27:57 -0700

> the adjacency will withdraw its side of the adjacency.

well, yes, and if I change my routerid, all adjacencies will go down. Not sure what the point here is...

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 16 Oct 2011 07:06:31 +0200

Hi Fred,

 > (3) It has to change its RID and start from the beginning.

I would say (perhaps in line with Curtis comment) that this step is 
unrealistic. RID for many reasons (for example mpls-te) is hard 
configured in link state IGPs.

Worse - some vendors - do base on this their very cool hack to forward 
v6 traffic over v4 TE LSPs.

So I think statement that router has to change it's RID is operationally 
non starter.

Cheers,
R.

---

From: David Täht <[email-masked]>
Date: Sun, 16 Oct 2011 09:47:33 +0200

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

Just as a data point, the babel and AHCP protocols creates a router-id
from a EUI-64. problem solved, there.

-- 
Dave Täht

---

From: David Täht <[email-masked]>
Date: Sun, 16 Oct 2011 12:47:29 +0200

In reviewing this enormous thread it appears to have got off-track
again, discussing esoterica of various routing protocols and not focused
on the big picture.

There's been too many comments for me to comment individually on the
messages.

However, overall trends on this list are discouraging.

1) Getting IPv6 working well inside the home is a hard problem! It helps
to actually try to make something work, to see the relevant details. I'd
like it very much if at an upcomin

I've built 3 such networks, and am in the process of building several
more - as well as making available code on a cheap, 120 dollar, platform
to make it possible to actually go and set one up yourself to play with,
so the more devilish, detailed problems become apparent. I've done my
best to make sure 6to4, at least, works right out of the box. Native (no
PD yet!) works pretty well, too - but getting the 6to4/ipv6 native to
co-exist better is going to take slightly more work.

http://www.bufferbloat.net/projects/cerowrt/wiki/OCEAN_CITY_INSTALLATION_GUIDE

There's babel, batman, rip, radvd, ospf, ospfv6, is-is, and bgp all
available. Go play.

I'd like it very much if at an upcoming meeting or event someone or
someones were to demonstrate working code...

2) Now, in reviewing this thread, I was disappointed to see that my ipv6
routing protocol of choice (babel) has not been discussed so far to any
extent. While this protocol is somewhat new, an rfc and working code
both exist, and working code has existed for several years.

http://tools.ietf.org/html/rfc6126
http://www.pps.jussieu.fr/~jch/software/babel/

Of late there has been a great deal of work on creating a metric that
does diversity routing - accounting for the differences in performance
between contested wireless channels and ethernet to some extent.

It seems to me that that babel has got lumped in a mental catagory of
'mesh networking protocol' - which it is - but it is better described as
'rip on speed' as it works across normal wired, wireless, AND mesh
networks - something no other routing protocol does well (IMHO!). Things
like 802.11s are targetted at wireless only.

The future inside the home is mostly wireless, not wired... and as many
of the assumptions built into ipv6, dhcp, dhcpv6, ra announcements, etc
completely predate the rise of wireless everywhere, they tend to be,
well... wrong.

Here are the current routing tables from bloatlab #1

http://www.bufferbloat.net/projects/cerowrt/wiki/BloatLab_1

http://www.teklibre.com/~d/labroutes/

I am using CIDR networks (/27 netmasks) on the ipv4 side to reduce the
broadcast/multicast problem that wireless-n has, and a variety of IP
address distribution mechanisms on the ipv6 side - autoconfig/ra and ahcp.

Some notes:

0) It took me multiple years of fiddling with the ipv6 routing protocols
available to settle on babel. Babel is definitely not finished or
perfect, but thankfully it has a pluggable metric.

1) Babel treats IPv6 as a first class object - ipv4 and ipv6 routes are
distributed in the same message - and within the same daemon and
configuration files. I had used olsr in an earlier attempt at convincing
ipv6 to work well on a previously pure ipv4 - the size of the 2 daemons
required, the doubling of packets sent, and the complexity of the conf
files all deterred me.

2) Setup is devestatingly simple compared to any other routing protocol
I've tried. For example, it uses a EUI-64 equivalent as a router-id, no
setup required.

Now I actually use, in the home, a setup that dumps dhcp, dhcpv6, and ra
entirely, replacing them with a combination of AHCP and babel - AHCP
also distributes ipv4 and ipv6 in the same message, and also (when done
right) gives the ability to transparently move between wired and
multiple wireless links without dropping connections. Stepping back into
what others think as the real world... in the office -  is often a shock
- I unplug and... "oh damn, I just lost 20+ windows and the movie I was
streaming..." where that *doesn't happen* when using the above two
protocols at home....

AHCP uses /128 netmasks which makes subnetting a single ipv6/64
allocation a breeze.

I can think of a few more compelling advantages for considering new
ideas such as these protocols inside the home, but this is almost enough
for today.

I'll talk to the more generic problems with prefix based routing in a
mixed 6to4 and native scenario, the dns naming problem, and the ip
address expiry problem some other day...

but you can see those for yourself with a little investment of time and
hardware in trying to actually make something - anything! - actually work.

-- 
Dave Täht

---

From: Fred Baker <[email-masked]>
Date: Sun, 16 Oct 2011 17:36:46 -0700

On Oct 15, 2011, at 10:06 PM, Robert Raszuk wrote:
> RID for many reasons (for example mpls-te) is hard configured in link state IGPs.
> 
> Worse - some vendors - do base on this their very cool hack to forward v6 traffic over v4 TE LSPs.

We appear to have a fundamental "you're on a misconfigured wavelength" problem. How many routers do you find using traffic-engineered MPLS LSPs within people's homes? How much do you find "hard configured" in a "zero configuration" environment?

Earth to Robert...

> So I think statement that router has to change it's RID is operationally non starter.

If the router, operating in a zero configuration environment and concocting its RID from some form of random process starting from an equipment differentiable seed, finds that its RID duplicates another router's RID, it has three choices. It can

  - not change it and screw up the network, which creates an unhappy customer and probably blows the entire margin in the router on a customer support call. 

  - not change it and effectively brick itself, which creates an unhappy customer and probably blows the entire margin in the router on a customer support call. 

  - change the router id, making the network work as the customer expects, resulting in a happy customer and the margin staying in the vendor's pocket. 

Pick one.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Oct 2011 11:44:31 +0900

> from a EUI-64. problem solved, there.

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

Note that I say "when" there is a collision and not "if" because:

- MAC addresses are supposed to be unique, but in practice, there are
duplicates.
- If a home router supports MAC address cloning, then there are more
duplicates.
- When you try to fit a 64-bit EUI-64 into 32 bits, sooner or later there
will be a collision, because, as my mother used to say, "you can't fit a
quart into a pint pot".

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 17 Oct 2011 06:21:58 +0200

Fred and Curtis,

Many thx for your emails. Indeed perhaps my example of MPLS-TE hack was 
a bit unreal for this alias - you are right. However I intended 
(apparently quite poorly) to express two points which while following 
from time to time this group I keep struggle myself with.

Point #1:

If we are dealing with "zero configuration" network why do I need 
routing protocols ? Why do I need in fact more then one gateway or two 
in the case of multi-homed Grandma ? If I want to build some subnets 
inside I will get an extra router or two, but I see no magic how those 
routers even if coming from the most brilliant vendor will be able to 
guess out of the box my intentions.

Point #2:

If I need more then reliable exit to the internet and need to have few 
subnets at home (like I do today) Fred can call me UFO, but I fail to 
see how difficult is to type two lines to establish a loopback address 
(which I will use from time to time to ssh to the box to check why it is 
not working) or to type 4 more lines to enable any IGP - if ever needed.

So if there is any document already written which I may have missed 
which has the answer to the above I appreciate sharing a pointer.

Automation is great we should have it where needed .. it is just that I 
am completely not convinced that it is needed here.

Best regards,
R.

> In message<[email-masked]>
> Robert Raszuk writes:
>
>> Hi Fred,
>>
> If it is hard configured, then is has to be configured correctly.
> Otherwise you have a conflict among two configured RID, then you have
> a persistent non-working network.
>
> If a autoconfig guy comes along and stomps on it, then only the
> autoconfig guy backs off.
>
> So you are saying that a vendor has a hack (private undocumented
> extension might be the market-speak) that is not backwards compatible
> to other implementations *of a full standard* and we can't create a
> backwards compatible extension because it would interfere with the
> hack?  (which you think is a very cool extension?)
>
>> Cheers,
>> R.
>>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 16 Oct 2011 20:03:04 -0700

> from a EUI-64. problem solved, there.

When using a 64 bit value to create a unique 32 bit value there is a
finite but small probability of a collision with OSPF.

Babel is experimental and AHCP is a draft and we aren't going to drop
a full standard because of a router-id issue.  Not that I don't think
Babel and AHCP are promising work.  Certainly flooding in a dense
wireless mesh is not a good thing as Jim pointed out but example so
there are cases where OSPF or ISIS is not applicable.

The topic at the moment is OSPF (and ISIS) so problem not solved by
EUI-64.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 16 Oct 2011 21:23:54 -0700

> hardware in trying to actually make something - anything! - actually work.

All very impressive.  You still have quite a few routes for a network
with very few hosts.  

At some point you have to wonder whether it might be better to arrange
a OSPF style bcast network for mesh that turns out to be a cluster of
many routers within a given very close range.  IF the AP style
(infrastructure bss) is used rather than mesh (MBSS) then this is a
natural fit.  DR election isn't all that painful and as long as the DR
remains stable (hint: give the AP a high number in the DR election)
then adding is fine.  Multicast from the DR would be nice rather than
multiple unicast.

For now we have OSPF and ISIS (and BGP) running the global Internet on
the one hand.  They are well proven, but these may or may not be
applicable to the homenet.  On the other hand we (or you) have lots of
promising work and some running code that isn't quite a mature and
isn't (afaik) widely deployed.  I don't think we should rule out
either one.

Protocols that are only applicable to specific circumstances tend to
go away.  I'm not yet convinced either way on the staying power of
babel and AHCP.

Perhaps I have a bias for link state protocols that has set in over
the last nearly 20 years of using them.

But it is hard to argue with running code once a lot of people are
running with it.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 16 Oct 2011 19:24:17 -0700

> down. Not sure what the point here is...

If you've just booted up and there is a one in a few million chance
that you'll get half way on the database load on the first adjacency
to come up and have to start over, then I don't think it is a big
deal.

If the point is what if you've been up and running for a while, then
perhaps we need a holdup timer to see if the problem clear if one or
more adjacencies has previously completed a full database load.  This
means that on a power up of everything, there will be merged islands
with conflicts and the conflicts won't resolve until the holdup timer
expires.  Some advice on being slow to correct "staleness" in this
situation would prevent the current OSPF staleness correction wars
(each corrects the other as fast as it can if you manage to configure
a conflict today - apparently common when people clone and edit
configs but occasionally forget to change the router-id - I wouldn't
know since we machine generated the configs where I used to play).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 16 Oct 2011 19:32:41 -0700

In message <[email-masked]>

Curtis

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Oct 2011 09:43:59 +0200

> co-exist better is going to take slightly more work.

you aren't helping things work better by doing 6to4.
please disabled by default, if you absolutely want to support it at all, hide it somewhere under the Wizard menus.

cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Oct 2011 15:01:23 +0200

Hello David

[David>] Now, in reviewing this thread, I was disappointed to see that my ipv6 routing protocol of choice (babel) has not been discussed so far to any extent. While this protocol is somewhat new, an rfc and working code both exist, and working code has existed for several years.

[Pascal >] I can only confirm from almost 10 years of implementing and experimenting the principles used in Babel that they are very sound (I started using them with nested networks of mobile routers, see http://tools.ietf.org/html/draft-thubert-tree-discovery )

And if you look at it, you'll find that BABEL builds its routing tree towards a destination using the same base principles as RPL builds its DODAG towards its root, DV operations with the same feasibility conditions and sequenced updates.

After that RPL provides a number of optimizations:

- RPL recognizes that most traffic goes through a limited number of gateways and only builds DODAGs off these gateways. This fits the classical wiring in a house, which is mostly hub/spoke and in any case a tree, simply because that's what electricians learn at school. From there, the default route can be heavily used, which saves states and more importantly states updates. 

- RPL has triggered updates dampening for large / dense configs (based on trickle); you'll note that there is no global triggered update (RPL looks more like DSDV than BABEL for that matter), only local. These local updates allow quick local repairs that avoid impacting the whole network when the use plays with the wireless settings in its stereo gear.

- RPL has tunable elasticity on the feasibility conditions, which, when used, may create loops. This is compensated by an in-band packet validation. This adaptation is specialized for operations such as WSN where there are very few packets and battery conservation is critical, which is true for home automation, and can be turned off for more classical operations.

- RPL has another inheritance from DUAL which allows poisoning a sub-DODAG by detaching it and then later reattaching it to the main DODAG. The shape of the sub DODAG can be retained and routing is maintained within, a feature that users might appreciate should a home gateway reboot, which in my experience happens quite often.

- With RPL, all routing inside the DODAG that is built for a given root (gateway, backbone router) exploits the DODAG topology so there is only one topology to maintain for all nodes in the DODAG as opposed to one topology per destination. Routing might be stretched as packets have to go up to the common parent and then down, but this allows a heavy utilization of the default route which in turn saves states maintenance and improves mobility. Users actually wear devices, move through the house, and expect that we maintain enough connectivity to stream media. 

- Instead of having different topologies per destination, RPL allows multiple instances that build their own topologies for their goals and constraints, and enables routing along those topologies. This solves in particular the walled garden problem we already discussed in this list, for instance for routing Utility packets from/to the Utility gateway which happens naturally if the utility packets are placed onto the RPL topology that is associated to the Utility. 

- RPL is partially autonomic, in that it distributes its own configuration as the DODAG builds off the root. If configuration is required to indicate a certain optimization, then that configuration can be pushed by the service provider onto the gateway, and it will be passed on by the protocol. But I'd think that being autonomic is quite critical. Interestingly, there's also intense research around that subject in Europe, see for instance AFI at ETSI.

- RPL is designed for multilink subnets, and in particular it distributes the information that routers will need of they need to form RAs, though the exact operation for doing it was taken off the spec. MLSN is quite useful to avoid renumbering devices that move inside the house, and it is seen as a MUST in industrial environments.

- RPL is designed to be complemented by a task-specific plug-in called objective function, which understands and adapts the operations to the metrics and constraints. Built-in OFs are quite abstract because they are very generic, but this group and others are free to define their own OF to map their needs. 

I have yet to understand which of the points above are required as opposed to nice-to-have for the HOMENET as the groups sees it.

[David>]  The future inside the home is mostly wireless, not wired... and as many of the assumptions built into ipv6, dhcp, dhcpv6, ra announcements, etc completely predate the rise of wireless everywhere, they tend to be, well... wrong.

[Pascal >]  I agree, with a twist that IPv6 is provenly quite capable to adapt and survive. The work at 6LoWPAN on ND is ample demonstration of that, isn't it? HOMENET might be a good place to evangelize that kind of work and promote implementation in the major stacks. The most difficult piece may be to change the mental image that we have of a network, from a set of well managed wires to probabilistic connectivity, with unpredictable interferences, movements, per-packet propagation behaviors, and hard constraints like energy savings and bandwidth limitations.

Cheers,

Pascal

---

From: Jim Gettys <[email-masked]>
Date: Wed, 19 Oct 2011 09:34:26 -0400

> please disabled by default, if you absolutely want to support it at all, hide it somewhere under the Wizard menus.
Actually, 6to4 works really well on Comcast since they installed
production 6to4 relays that are geographically dispersed.

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

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

                        - Jim

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Oct 2011 21:22:37 +0900

On Wed, Oct 19, 2011 at 22:34, Jim Gettys <[email-masked]> wrote:

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

---

From: Jim Gettys <[email-masked]>
Date: Thu, 20 Oct 2011 08:48:27 -0400

On 10/20/2011 08:22 AM, Lorenzo Colitti wrote:
> On Wed, Oct 19, 2011 at 22:34, Jim Gettys <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > please disabled by default, if you absolutely want to support it
>     at all, hide it somewhere under the Wizard menus.
>
>
> +1. Please read Geoff Huston's data that shows the 12-20% failure rate
> of 6to4, and then please disable it. :-)

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

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

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Oct 2011 14:59:29 +0200

Jim,

> from an address range where we have some evidence of decent relays being

from a 6to4 router perspective you have no idea. the return relays are not under your control.
nor are they under your ISPs control.

in the homenet context you also need border discovery for this function. as you really do not want to
enable it on all internal routers. (in the case of global v4 addressing).

but seriously, just remove it from the build.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Oct 2011 22:00:03 +0900

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

---

From: Jim Gettys <[email-masked]>
Date: Thu, 20 Oct 2011 09:23:33 -0400

On 10/20/2011 09:00 AM, Lorenzo Colitti wrote:
> On Thu, Oct 20, 2011 at 21:59, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Yep. Overlay networks will never match native performance. Please
> don't do 6to4, please implement RFC 6204 instead.

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

---

From: Jim Gettys <[email-masked]>
Date: Thu, 20 Oct 2011 09:26:24 -0400

> nor are they under your ISPs control.

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

> but seriously, just remove it from the build.
This I disagree with; 6to4 is seriously useful in certain environments
(like mine).  Having it present can be useful, having it on by default,
is problematic. Unless/until we can fully automate something else I want
it available.

                    - Jim

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Oct 2011 16:22:55 +0200

> is problematic. Unless/until we can fully automate something else I want

yes, I'm fine with that.

cheers,
Ole

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Oct 2011 21:33:13 -0700

In message <[email-masked]>
 
> don't do 6to4, please implement RFC 6204 instead.

For tunnels RFC4213 is preferred over 6to4, but I do think that both
should be implemented.  Comcast has done a good job with 6to4, and
other providers might as well.  RFC6204 does specify that the WAN side
can be a tunnel, but doesn't recommend any type of tunnel (I don't
think having not looked just now).

Curtis