Subject: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing

From: Roger Jørgensen <[email-masked]>
Date: Mon, 17 Oct 2011 12:33:34 +0200

<snip alot of text from ongoing discussion>

I've been on my way to write this, most of all for myself,  for a
while so here we go...
This is how _I_ understand most of the ongoing discussions and where
we are going, our goal. It is not at all technical on the protocol
level, it is a high-level view/design/scenario...

I'll try to summarize how I understand homenet with breaking it down
to three part/layers.
1.) uplink towards "internet"
2.) internal routing/mesh/something
3.) end-user facing connection (wireless/wired)

about #1 - uplink towards "internet"

I believe we can quite safely assume we have to support more than two
uplinks from our homenet device, at least we need to support it.
Probably a mix of wired and wireless, any mix really and any way.
Those links need some protocol to make connection to it's other side
(ISP/provider). That part is covered afaik but we might want to make
them more advance on the "routing" side but not our biggest
concern....

I would assume it would be useful in the zeroconf mindset for the
uplink(s) to know if it's alone or not. One could be wired and one
wireless toward the same provider. There are already providers selling
that type of connection as a product, ADSL combined with a backup 3G
link.... work like a charm. But of course, they've hidden the routing
and linknet part behind a VPN/MPLS-alike system :)

What should happen if the in-use uplink goes down, I guess it should
back-off, tell the other "hi, my uplink(s) are down", then pull back
all of the prefixes it use and let the other uplink take over...
somehow through some magic/undefined system:-)
... or maybe the uplink just tell layer #2, "hi I'm down" and let that
part solve it?

And another scenario, maybe not all of the uplinks are towards what we
call Internet, maybe only one of them have the full view of Internet
while the other two are toward other closed network? So we need some
sort of routing here to...

about #2 - internal routing

Can be the same box, or another, but a bit different tasks to be
executed. The same here as for uplinks, there are quite likely to be
more than one LAN. Guest network vs normal network are the two most
common...

Combined with two uplinks we are talking about the possibilities to
have more than two prefixes in use (IPv6) and more than one NAT
segments (LAN). Somehow this layer need to know where to send the
traffic, or where not to send it. And if said uplink 1 goes down, then
maybe that prefix need to be revoked and instead use the prefix from
uplink 2 ?

Not to forget the network some of us have, more than two LAN with
routing and not NAT, three uplink (2 IPv6 and one IPv4), wireless,
wired, wireless-bridge between wired network etc... we need to be able
to manual overrule some options and add custom configuration.

Tons of other problems here to but it's "just" routing :-)

...  there is also the problem of any end-user equipment having both
wired and wireless connection, multihoming really :-) But that really
is for the next part to handle.

about #3 - end-user connection

Users can have both wired and wireless connection. Which one should
the device (end user facing part) prefer? I'm quite sure we should
rule out letting the end-user choice :-) Not that it will be easy to
detect a device being connected both on the wire and over wireless...

What happen if the in-use prefix change? Like if we move from one
uplink to another but from different ISP. How do we even pick an ISP
in the beginning when we have two or more?! Use prefixes (IPv6) from
all of them and announce several default gateways or?
Either this layer, or layer 2 - routing has to make a decision on
which prefix that should be announced to the user.

Not to forget that wired behave different than wireless in a number of
ways as mention by others...

And to make matter a bit more complex, I believe the user, you're
average Joe or you're grandma, should be able to connect the homenet
device pretty much anyway the equipment fits together and the devices
should just figure out the rest between them self.
Guess we need some sort of way to mark ports on the devices as uplink
or downlink, but  preferable they should be able to sort it out
between them....

Not to forget we need some sort of bootstrap system to get things
up'n'running when we're connecting the homenet device for the first
time.
Todays system where you connect to the device on a given and clearly
visible (well, sometimes at least) address to make some very basic
configuration are probably doable in the future to.
As other have mention, the use of 192.168.0.1 or similar cannot
continue, we should use the DHCP/DNS options and let The Device you
are connected to always by default have the name router.local or
anything along the same line. That will remove the confusion I can
quite clearly imagine when a user are asked to type in an IPv6
address.....
(and if there are more than one device in your network the System It
Self will give them a name since it already know about all other
devices in the network, let local DHCP/DNS give them names like
uplink1.local, uplink2.local,routing1.local etc... )

and probably quite a few other issues I haven't mention on just the
high level...

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Oct 2011 11:21:55 -0700

In message <[email-masked]>
 
> 3.) end-user facing connection (wireless/wired)

See below.  Added a few.

> sort of routing here to...

I do not except #1 as stated.

1. No built in assumptions about whether a router has an uplink port
   and if so, which port it is.

   a.  there may temporarily be no uplink in the internal network.

   b.  the router may be used as an internal router with one of more
       uplink elsewhere.

   c.  the router may have one or more uplink, which does not rule out
       an uplink attached elsewhere in the same internal network.

   d.  assumptions about uplinks may be learned (zero config) or
       configured.

	Note: a good rule would be if you are not sure you have an
	IPv6 uplink never give out a PD longer than /65.  If a prefix
	is handed out (to you) that is /64 or shorter and globally
	routeable, assume it is an uplink to a provider.

Note: at this point, no assumptions as to how this is accomplish.  It
is doable (my assertion, echoed by others, disputed by some, ... or
maybe I'm echoing).

> is for the next part to handle.

No product sold as a router should do only bridging and NAT.  That is
a NAT appliance with bridging on the NATed side.  We should be very
clear about that.  If it does not route, and it just does NAT, it is
not a router.  **That needs to be in an RFC.**

Change from "routing" to "allocation".  Keep routing separate.

#2  internal address allocation

  a.  temporary addressing

      For both IPv4 and IPv6, a means is needed to start out with a
      globally non-routable prefix and subdelegate addressing, then
      establish temporary routing.  For IPv6 a means of doing this is
      defined in IA_PD requests in DHCP6, but maybe not meeting all
      requirements.

      Ask neighbors for addresses and then delay with randomization in
      the delay before creating a fresh allocation.  Hopefully except
      in the case of bridging long time islands, the network will
      settle on a single base allocation.

  b.  addressing based on uplink allocation

      For both IPv4 and IPv6 a means is needed to suballocate the
      prefix provided by an uplink.  For DHCP{4,6} this is challenging
      in that there is no way to quickly remove a prior temporary
      prefix and replace it *except* giving short lease times to
      temporary prefixes.  Global addresses must only originate from
      configured routers (usually the provider routers).  Global
      prefixes must never be temporarily assigned by a provider.

  c.  NAT based on temporary addressing

      An interim solution during the transition from (a) above to (b)
      above, is to offer NAT to users of the temporary addresses.  For
      some hosts that cannot tolerate an address changing, it may be
      better to leave the NAT in place.  If connections are open, the
      NAT and temporary allocation should remain in place.

  d.  multihoming and allocation

      For IPv6 which explicitly supports DHCP aliasing of addresses,
      this is less of an issue.  An address can be assigned for every
      uplink though it would be better to prune the addresses.

  e.  prune addressing

      After one or more uplink has been established, prune addressing
      by allowing temporary addressing to expire.  Prune global
      addresses such that the subnet allocation is based on where the
      default route (or least specific route) comes from.

  f.  disappearing uplink

      Two cases exist regarding provider response.  In one case the
      multihoming (generally for a business) is coordinated among
      providers and in the other case it is not.

      i.  coordinated

      	  Prefix allocation and routing can be coordinated, such that
	  regardless of who allocated the prefix (or both allocated a
	  prefix and there are two of them) there is a globally
	  advertised specific route to the address allocated by the
	  other provider.  This case must be configured.

      ii. uncoordinated

      	  If one uplink goes away, the network must temporarily NAT
      	  for that prefix.  If not, the other provider will not route
      	  the return packets correctly.  Any UDP or TCP connections
      	  that were already open when the uplink goes down will be
      	  lost.  Using the pruning rule in (e) where pruning is based
      	  on route to default, prefixes assigned to the lost uplink
      	  will disappear as leases expire.

  g.  too small an allocation

      In IPv4, the block is likely to be too small.  It may be one
      host address.  If so, a default can be advertised into routing
      and PI address space can be allocated.

  h.  mix of configured addresses

      Both host addresses and a subset of prefixes may need to be
      configured.  Once anything is configured, the uplinks need to be
      configured to avoid dynamic allocation of any of the fixed parts
      of the address block that has been assigned.  This also means
      they can allocate routeable prefixes when the uplink is down,
      advertising a non-usable default (infinity minus one and a link
      cost of one makes it unusable).

  i.  routing

      See #5 below.  This gets complicated if routing types (DV and
      LS) and metric types are mixed.

  j.  security

      See #4 below.

> ways as mention by others...

We have to get rid of long lease times.  If a connection goes up, its
OK if NAT is used for a while.  If a lease goes down, same is true.
An extension to DHCP (or other allocation mechanism) that provides an
immediate allocation withdrawl would be good.  A refusal on the
grounds of "in use" would also be good.  A capability can identify
legacy hosts which need to get one prefix and use it forever.  It may
be best to IPv4 NAT for legacy hosts and give them IPv6 real addresses
when available.

Note that legacy hosts which "listen" for connections are often
confused if interfaces get renumbered.  This would normally be a
headache to enterprise users with services on internal servers.  These
applications would have to be smarter or the addresses configured.

> or downlink, but  preferable they should be able to sort it out

We agree on the first point.  On the second point, there should be no
designated uplink on a device.  Any port can become an uplink.  More
than one port can become an uplink.  It is also possible that none
will be an uplink.

> uplink1.local, uplink2.local,routing1.local etc... )

Some [NAT boxes masquerading as routers] already do this by offering
themselves as DNS forwarder and providing a fake hostname in a fake
TLD that is mapped to 192.168.1.1.  That's OK for IPv4.  It a little
problematic when there are two uplinks and they both want to be
192.168.1.1.  That is why the "ask first, then allocate" rule.
Someone gets 192.168.1.1 but not both.  A better method of locating
and identifying these not yet configured routers is needed.

> and probably quite a few other issues I haven't mention on just the

Security is easier than routing (really!) so I gave it #4.  Until the
controversy of point (a) rears its ugly head.

#4.  security

  a.  No filtering should be done on a link that is not identified as
      an uplink.

  b.  By default strong filtering should be enabled on any uplink.

  c.  Filtering can be weakenned, holes punched through, or disabled
      by configuration.

  d.  [I would like to see any document that attempts to standardize
      the type of filtering clearly separated from the addressing and
      routing work.  I don't think that is too much to ask.]

#5  routing

  a.  DV and LS routing can mixed within a domain.  DV routes can be
      injected into LS routing (for example as OSPF ASE).  LS prefixes
      can be injected into DV.  Within a LS or DV region, a mechanism
      to prefer internal routes to the LS domain or DV domain is
      needed.  (OSPF already prefers internal prefixes to ASE).

  b.  For Ethernet or other wired media, LS is preferable.

  c.  For wireless with an AP (infrastructure bss), further discussion
      is needed.  Constrained DV has been proposed.  OSPF with AP as
      the DR has been proposed.  (Who gets to be the BDR or should the
      AP also fake another host and call it the BDR?).

  d.  For wireless mesh (MBSS), further discussion is needed.  This
      may be the domain of MANET and they have not converged (AFAIK)
      on a one best protocol.

For (a) we should recommend one.  OSPF is full standard and is cleaner
but we have v2 for IPv4 and v3 for IPv6.  ISIS has NSAPs as router ID
(even uglier than IPv6 addresses or MACs and must be unique), sends
around really big packets even for small changes, but supports both
IPv4 and IPv6 in one instance and is (strongly) prefered by some.

btw- I took some notes (as diffs) on draft-chown-homenet-arch-00 but
have not had time to annotate the diffs and send them out.  That
document should be the base of discussions unless we decide it would
be better to start over for some reason.

Curtis

---

From: Russ White <[email-masked]>
Date: Wed, 19 Oct 2011 07:48:13 -0400

>    d.  assumptions about uplinks may be learned (zero config) or

The biggest problem with determining what's an "uplink" and what's not
is simply what the word "uplink" actually means. One of the things we've
been thinking about here is "walled gardens," networks which serve a
special purpose, and hence don't have connectivity to the "world at
large." There are probably only two solutions here:

1. The provider's device needs to tell you this information.
2. You need a set of "magic destinations," that the internal devices can
use to orient themselves to the network topology around them.

> We have to get rid of long lease times.  If a connection goes up, its

The problem here is that you're working against the rest of the world,
which assumes an IP address is pretty much a permanent feature of a
device, like a MAC address. I don't know how to change that mentality.

>   a.  No filtering should be done on a link that is not identified as

As long as you're okay with multiple layered devices each filtering on
their uplinks (not necessarily a bad thing, by the way). I tend to think
more in terms of domains, which included possible vertical divides as
well as horizontal ones.

>   c.  Filtering can be weakenned, holes punched through, or disabled

Agreed.

>   a.  DV and LS routing can mixed within a domain.  DV routes can be

In fact, OSPF already does this... What I hate is this entire idea of
"redistribution." A single protocol that does both DV and LS in the
right places would be ideal --but I also think the existing DV protocols
can be modified to provide this sort of thing.

> IPv4 and IPv6 in one instance and is (strongly) prefered by some.

I would argue that the router ID situation in IS-IS is actually easier
to deal with than the one in OSPF. With fragmented LSPs, I don't think
the packet size in IS-IS is any worse than OSPF, either (?).

:-)

Russ

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Oct 2011 18:56:16 -0700

> use to orient themselves to the network topology around them.

Its easy to detect a walled garden if you are expecting a default
route from a full uplink.

Use the route to the whole Internet if one is available.  Otherwise,
use the walled garden connection if that is all you have.

Walled gardens really suck.  They suck even worse when they are sold
as having access to the Internet when they don't.

> device, like a MAC address. I don't know how to change that mentality.

Yes.  If plugging things arbitrarily and rearranging them without
powering any of it down is going to work, handing out long leases to
legacy devices can't be done.  If a device supports taking back a
lease, then that is better.

Note that I had a perfectly fine workaround, which was to NAT for any
device that wouldn't give up on using an old address if that address
became stale.

> more in terms of domains, which included possible vertical divides as

An uplink is a connection to the provider.  It is discovered, not
identified as the port with the yellow connector.

Reread the very first sentence you quoted:

  No built in assumptions about whether a router has an uplink port
  and if so, which port it is.

> >   c.  Filtering can be weakenned, holes punched through, or disabled

OK

> can be modified to provide this sort of thing.

I was trying to help come to a compromise on the "grand unified
routing protocol problem" by stating that we don't need a one size
fits all routing protocol.  We can have one for wired, one for
AP style wireless, one for mesh wireless.

> the packet size in IS-IS is any worse than OSPF, either (?).

On packet size: OSPF doesn't have a requirement to round every hello
packet up MTU which ISIS does.  OSPF can send only the LSA that
changed.  ISIS has to send the whole LSPDU fragment which contains the
change and then the receiver has to check every TLV in the packet that
didn't change and find the one that did change.

Perhaps there can be a negociation with the zero config default being
"a slight preference for X" where each vendor gets to pick X and the
slight preference could be overridden by a configured (strong)
preference.  Perhaps distance to any router with a configured
preference can be a tie breaker to switch over (with *lots* of
hysteresis on the switch over).  If we can't "pick one" then we have
to make a network interoperate in a zero config situation with vendors
that had different "slight preference" choices.  It means two routing
protocols with the increase in executable image and memory footprint.

Curtis

---

From: Russ White <[email-masked]>
Date: Thu, 20 Oct 2011 14:10:53 -0400

> route from a full uplink.

Unless every uplink gives you a default route...

> device that wouldn't give up on using an old address if that address

Then you might as well NAT all the addresses on the subnet. :-)

> AP style wireless, one for mesh wireless.

I would prefer one...

> didn't change and find the one that did change.

How many destinations do you think there will be in a home network? My
guess is that we'll end up with one or two LSPs anyway.

As for "rounding up," is it really that big of a deal? It's just a
different solution for the same problem.

:-)

Russ

---

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

> Unless every uplink gives you a default route...

In which case you pick the closest one.

Its only where the walled garden claims to have a default route but
blackholes or tries to do web only and replaces content that you have
trouble.

> Then you might as well NAT all the addresses on the subnet. :-)

No.  You NAT at the border only for the hosts on the subnet that are
legacy and cannot replace a DHCP assigned address with a new one.  In
affect you NAT the old subnet becuase the homenet hosts and routers
accepted a new address.  You then have more than one subnet address
(aliases in ifconfig speak).

> > AP style wireless, one for mesh wireless.

There is at least an assertion that some DV protocols may be better
for mesh wireless.

There need not be one "grand unified routing protocol".

In the provider world, BGP allowed the IGP to be picked per AS and
allowed OSPF and ISIS (and EIGRP) to exist in different providers.  As
it turns out only the LS protocols endured.

> guess is that we'll end up with one or two LSPs anyway.

Depends on where this stuff is deployed.  Think public library for
example.  Multiple consumer grade APs.  Real wires connecting them.
No wizards to help out (except maybe some volunteer with some
knowledge of PCs and absolutely no clue about networking).

> different solution for the same problem.

A full MTU sized hello might be a big deal on a wireless mesh.  Jim's
comments seem to imply that and he was rather emphatical about routing
protocols keeping the noise level down.

Curtis

---

From: Russ White <[email-masked]>
Date: Fri, 21 Oct 2011 09:09:32 -0400

> In which case you pick the closest one.

So you would argue that if there is a walled garden, it should always
advertise full routes? I don't know how realistic that is all the time.
Network failures are one example of this being problematic.

> (aliases in ifconfig speak).

If you're already doing NAT, then...

> There is at least an assertion that some DV protocols may be better

But why should a single protocol not be link state and d-v? OSPF already is.

> it turns out only the LS protocols endured.

I would say that EIGRP has endured, as well. Not in the provider market,
but certainly in other markets. For all the bad press EIGRP gets, it's
actually a very interesting and useful protocol.

> knowledge of PCs and absolutely no clue about networking).

So you'd argue for a much more complex protocol because it's cheaper on
the wire? I don't think "wire costs" mean much any longer, honestly.

What's needed is an open evaluation of all the available protocols,
rather than assuming OSPF is "the answer," etc. And we shouldn't leave
out the option of extending an existing protocol, either --and I don't
want routing information in opaque LSAs. :-)

> protocols keeping the noise level down.

Chattiness and packet size are two different problems. If you want the
least chatty protocol, go to EIGRP. :-) It's the least chatty for
several reasons. In fact, distance vector can always be made to be less
chatty than any link state protocol, if that's really your goal.

But again, there's no reason a single protocol can't act both ways in
different environments. OSPF already does.

:-)

Russ

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 07:04:27 -0700

> Network failures are one example of this being problematic.

No.  A walled garden should never advertise full routes.

With all the email its easy to lose track of what is being suggested.
Take address allocation from the source which is also providing the
least specific route.  If there is a tie for least specific, then pick
the closest.

If there is a walled gardenner, they can advertise a prefix that they
have been assigned, but no more.  If there is also a router with a
default, pick that one for the address allocation.  Use *routing* and
forward to the more specific route to talk through the walled garden
router to the walled garden.  Use the default route to talk to
anything else.

> If you're already doing NAT, then...

Only for legacy devices.  Never devices might want to have the ability
to have connections from the outside which you can't have with a NAT.

> But why should a single protocol not be link state and d-v? OSPF already is.

Please read:

  Message-Id: <[email-masked]>

I'll make it easy for you on the point above.

  #5  routing

The rest of the message is also worth reading and you wouldn't be
asking quite so many questions if you read this.

> actually a very interesting and useful protocol.

Not in the provider market.  No major provider uses it.

BTW- ANS used it in their regional routers (each region had a separate
AS) for a while but replaced it when Cisco's OSPF became stable (which
took a *very* long time to happen, but did happen mid-1990s).

It was also the "Cisco-only-ness" that assured no one would use it.

> want routing information in opaque LSAs. :-)

LS is not much more complicated.  It has properties that DV can't
touch, like ability to carry very useful other information about the
topology.

We want protocols that will work not only in Grandma's house but her
grandkids too.

Opaque LSAs are no different from ISIS TLVs that are not defined in
the base spec.  They are a proven extension with backwards
compatibility back to routers of the 1980s.  In case Grandma is still
still hasn't tossed out that old Proteon.

> different environments. OSPF already does.

See point #5a above.  No grand unified routing protocol.  We will
waste too much time arguing over which is the one best protocol.

Curtis