In message <cakfn1sffxaa9snrc21lq8ltybrhn_1cmeo+euz7xr+oc3df...@mail.gmail.com>
Roger Jørgensen writes:
> <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)
See below. Added a few.
> 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...
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).
> 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.
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.
> 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...
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.
> 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....
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.
> 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... )
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
> high level...
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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
