Subject: [homenet] more comments on draft-arkko-homenet-prefix-assignment

From: "Howard, Lee" <[email-masked]>
Date: Fri, 4 Nov 2011 16:44:12 -0400

This requirement requires justification:
 o  The assignments must be stable across reboots, power cycling,
      router software updates, and preferably, should be stable across
      simple network changes such as adding a new device on the stub
      network segments.

*Why* is that an RFC2119 MUST?
Why is that an RFC2219 SHOULD?  When I see a "should" I like to see an explanation, since the definition is "Do this unless you have a good reason not to," and implementers need guidance about when they might violate that.
I think the reason (as discussed on list a couple of weeks ago) is that when a router reboots, if it gets renumbered, the hosts attached to it still have DHCP leases that haven't expired but won't be able to use those addresses.

   The generation
   of ULAs in this manner -- and indeed even the question of whether
   ULAs are needed -- is outside the scope of this memo, however.

Why is this out of scope?  Will we have a separate document to describe this?  No addressing or routing solution is complete until it can handle ULA (unless we find a way to do away with ULA).

  The lifetime of the prefix SHOULD be advertised as a
   reasonably long period, at least 48 hours or the lifetime of the
   assigned prefixes, whichever is smaller.

Why?

   To support a variety of
   IPv6-only hosts in these networks, the router needs to ensure that
   sufficient DNS discovery mechanisms are enabled.

What kind of variety do you mean?  By "DNS discovery" you mean
methods to advertise resolvers to hosts, not methods to discover
name-address mappings.

   When an OSPFv3 Router receives a global prefix through DHCPv6 prefix
   delegation, manual configuration, or other means, it will advertise
   this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA.
   This will trigger prefix assignment for auto-configured OSPFv3
   routers within the routing domain including the originating OSPFv3
   router.

If a subtended router is manually configured with a subnet of the /48
assigned to the border router, will both be advertsied as Usable Prefixes?
If so, will other routers try to make Assigned Prefixes from both?

  When an OSPFv3 Router receives a global prefix through DHCPv6 prefix
   delegation, manual configuration, or other means, it will advertise
   this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA.

Shouldn't the border router assign its local prefix before sending the full
/48 Usable Prefix?  I suppose it doesn't have to be, but that means that
the border sends the Usable Prefix, and all attached routers fight over
who has the highest Router ID; then that router provides the Assigned
Prefix to the link.  It works, it just seems funny to me.

1.  The OSPFv3 Router will determine whether there are any other
       OSPFv3 Routers connected to the same link by examining its list
       of neighbors.

There's at least one, since this algorithm was triggered by receiving an
AC LSA.

Lee

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 05 Nov 2011 20:43:20 +0200

Lee,

> I think the reason (as discussed on list a couple of weeks ago) is that when a router reboots, if it gets renumbered, the hosts attached to it still have DHCP leases that haven't expired but won't…

(I did not use RFC 2119 keywords, by the way.)

The reason that you give is the valid reason. If a router is power-cycled and the hosts still have old prefix values, this may result in some breakage. Power cycling may be frequent, e.g., many people regularly turn off their devices. (Not me, how else would I heat my house?)

Real network changes are less frequent, so handling them is not so critical.

But these should be stated in the draft, not just here on the mailing list. I will add them.

> Why is this out of scope?  Will we have a separate document to describe this?  No addressing or routing solution is complete until it can handle ULA (unless we find a way to do away with ULA).

It was simply outside the scope because I think the mechanisms of distributing prefixes around are separable from the question of what prefix types are used.

I was thinking that we need another document on the use of ULAs, and it would of course reference this spec for the actual distribution within the network.

(But I confess there may be a small personal bias in this decision about the scope as well. I don't seem to be quite as convinced about the blessings of ULAs as some other people in the working group :-)

>     assigned prefixes, whichever is smaller.

Because it would be harmful to have different hosts in the home add/remove prefixes. Sufficiently long lifetimes ensure that a temporary radio glitch or packet loss does not remove your prefixes.

But maybe this should be outside the scope of this document, it is more of an operational consideration. Or not... since there is no operator in the homes the defaults need to be reasonable. Your thoughts?

> What kind of variety do you mean?

For instance, hosts that support only DHCPv6-based DNS discovery. Hosts that support only RFC 5006 based DNS discovery.

>    By "DNS discovery" you mean

Yes.

> If so, will other routers try to make Assigned Prefixes from both?

Good question. This probably needs further elaboration in the spec.

> Prefix to the link.  It works, it just seems funny to me.

Good point. Maybe we need to think about this in a more fundamental way as well, not sure if there are some boot order issues where this might happen later, too. Or maybe not. On a stable network the routers remember what prefixes they ended up using, and attempt to reuse those upon reboots.

> There's at least one, since this algorithm was triggered by receiving an

Ok. Need to look at that.

Thanks again for the feedback. There is certainly material here for updating the draft.

Jari

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Nov 2011 10:39:53 -0500

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:
    Jari> It was simply outside the scope because I think the mechanisms
    Jari> of distributing prefixes around are separable from the
    Jari> question of what prefix types are used.

    Jari> I was thinking that we need another document on the use of
    Jari> ULAs, and it would of course reference this spec for the
    Jari> actual distribution within the network.

I wonder, given that we don't need to be as conservative with ULAs as we
do with GUA, if we should perhaps do something to allow ULAs to be even
more stable.

In particular, should the ULA used for my PersonalAreaNetwork change,
ever, regardless of whose house/office I'm in?  I think that my personal
gateway should simply use zospf to announce it into my home cloud.

Or, is my PAN actually a kind of walled-garden?

-- 
]       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: "Howard, Lee" <[email-masked]>
Date: Mon, 7 Nov 2011 11:35:04 -0500

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Saturday, November 05, 2011 2:43 PM
> To: Howard, Lee
> Cc: [email-masked] Group
> Subject: Re: [homenet] more comments on draft-arkko-homenet-prefix-assignment
>
> Lee,
>
> > Why is that an RFC2219 SHOULD?  When I see a "should" I like to see an explanation,
> since the definition is "Do this unless you have a good reason not to," and implementers
> need guidance about when they might violate that.
> > I think the reason (as discussed on list a couple of weeks ago) is that when a router
> reboots, if it gets renumbered, the hosts attached to it still have DHCP leases that haven't
> expired but won't be able to use those addresses.
>

Section 2 says you're using RFC 2119, so I assumed use of those words was intended to
imply those definitions.  You didn't capitalize, but that's not required.

> The reason that you give is the valid reason. If a router is power-cycled and the hosts still
> have old prefix values, this may result in some breakage. Power cycling may be frequent,
> e.g., many people regularly turn off their devices. (Not me, how else would I heat my
> house?)

Another way to handle that problem is to have a predictable alogrithm for prefix
assignment, so any router plugged into a given point in the network will always
acquire the same prefix.  That is not true here--if you replace your den router, the
new router will have a different rouer ID, and may well get a new prefix.  That's
a tolerable limitation, though.
(Surely there are more potent heaters than home gateways.  Minicomputers, for
instance.  I had to describe tape storage to my son yesterday--he'd never seen a
tape).

> I was thinking that we need another document on the use of ULAs, and it would of course
> reference this spec for the actual distribution within the network.
>
> (But I confess there may be a small personal bias in this decision about the scope as well. I
> don't seem to be quite as convinced about the blessings of ULAs as some other people in the
> working group :-)

James has interesting arguments here, which I'm still thinking about.
I do think we as a WG need to expose the requirements for ULAs, and either say our
solutions won't support ULA, or require our solutions to describe ULA functioning.

> Because it would be harmful to have different hosts in the home add/remove prefixes.
> Sufficiently long lifetimes ensure that a temporary radio glitch or packet loss does not
> remove your prefixes.
>
> But maybe this should be outside the scope of this document, it is more of an operational
> consideration. Or not... since there is no operator in the homes the defaults need to be
> reasonable. Your thoughts?

I'm fine with SHOULD or RECOMMENDED, as long as we explain why.
A shorter lifetime would give the hosts a faster recovery time to prefix changes.
I don't want to suggest that we should have 30 second DHCP lease times, but
this is the tradeoff we're making.

> > methods to advertise resolvers to hosts, not methods to discover

Thanks for clarifying.  I wasn't sure whether you meant PCs and Macs, or
computers, tablets and game consoles, or Ethernet, MoCA and Wi-Fi.

> Good point. Maybe we need to think about this in a more fundamental way as well, not sure
> if there are some boot order issues where this might happen later, too. Or maybe not. On a
> stable network the routers remember what prefixes they ended up using, and attempt to
> reuse those upon reboots.

Similar to the ULA question: where do you start?

Lee

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Nov 2011 12:17:56 +0100

Michael:

If you want your PAN network to be reachable from the rest of the world,
you still need some mobility solution.
For instance you could use NEMO. Get a PAN delegated from your home
network and then move around with it.

For local communications, yes you'll want to inject the PAN network
prefix into the local topology. 
If the local topology trusts you to inject anything which is not a
given.

The combination of the 2 is basically what MANEMO tried to achieve a few
years ago, using what became RPL as the underlying routing protocol.
Maybe the times are getting ripe.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Richardson
Sent: lundi 7 novembre 2011 16:40
To: [email-masked] Group
Subject: Re: [homenet] more comments on
draft-arkko-homenet-prefix-assignment

-- 
]       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. 
_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: Guillaume Habault <[email-masked]>
Date: Mon, 14 Nov 2011 17:26:26 +0100

Hi,

I would like to add some additional comments/thoughts regarding the draft
and especially on the multihoming part.
It is unclear to me whether you recommend to use the routing protocol or
the host to manage the multihoming, because it is first mentionned in the
section 3.3 that :

      multi-addressed hosts selecting the right source address to avoid
      falling foul of ingress filtering on upstream ISP connections
      [I-D.baker-fun-multi-router].

Maybe i'm wrong but it seems that in this sentence the address selection in
the host will avoid the ingress filtering. But according to me, even though
the host select the appropriate address, the routing protocol may route the
message to the wrong Customer Edge Router (especially if we are in the case
where there is more than one Customer Edge Router in the home network.
However, it could work if Customer Edge Router can talk to each other)...
And in the section 3.4, it is mentionned that :

      To Support multihoming within a homenet, a routing protocol that
      can make routing decisions based on source and destination
      addresses is desirable, to avoid upstream ISP ingress filtering
      problems.

Do you plan to use both solution? or does it depend on the topology? Or
does the aim is to be generic and let implementer decide about the solution
to use ?

In fact, the way i see multihoming in future home network (please correct
me if i'm wrong) is that there would be several CPE Router. And I think
that the ISP behind these CPE will try to differantiate themselves by
offering specific services to their customers. We will then have two cases:

   1. For common services (services that can be found on all ISP), the
   packet could be routed to any CPE in the network;
   2. For specific services offered from one ISP only, the packet will have
   to be routed to this particular CPE. So the host which want to use this
   service will have to select the appropriate address (the one received from
   the CPE) and the routing protocol will have to route the packet to the CPE.

Thus, the host has to be aware of the services available on each CPE. And
the routing protocol should route the packet using both source and
destination address.

Talking about providing different services per ISP, I think that the ISP
could provide different prefixes to the CPE depending on these services. It
could be a method for the ISP to differentiate the flow depending on the
services. Whereas in the draft you stated that:

      a single prefix should be received on the border CPE from the
      upstream ISP

Regards,

2011/11/9 Pascal Thubert (pthubert) <[email-masked]>

-- 
Guillaume HABAULT
PhD Student
Institut TELECOM / TELECOM Bretagne

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2011 19:41:04 -0500

>>>>> "Guillaume" == Guillaume Habault <[email-masked]> writes:
    Guillaume> the host select the appropriate address, the routing
    Guillaume> protocol may route the 
    Guillaume> message to the wrong Customer Edge Router (especially if
    Guillaume> we are in the case 
    Guillaume> where there is more than one Customer Edge Router in the
    Guillaume> home network. 

We have assumed that the home gateways will cooperate and provide source
address routing, making sure that packets are routed out the link which
can accept that source address.

    Guillaume> However, it could work if Customer Edge Router can talk to each other)...
    Guillaume> And in the section 3.4, it is mentionned that :

    Guillaume> To Support multihoming within a homenet, a routing protocol that
    Guillaume> can make routing decisions based on source and destination
    Guillaume> addresses is desirable, to avoid upstream ISP ingress filtering
    Guillaume> problems.

    Guillaume> Do you plan to use both solution? or does it depend on
    Guillaume> the topology? Or 
    Guillaume> does the aim is to be generic and let implementer decide
    Guillaume> about the solution 
    Guillaume> to use ?

You need both pieces.
(Please consider a quoting mechanism that is more robust)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Nov 2011 19:46:35 -0500

Maybe I am missing something basic, but there seems to be a bit of a 
disconnect on our assumption about what we need to have in in-home rotuers.

On the one hand, earlier discussion emphasized that we need to use 
protocols and implementations that are well tested, robust, and simple 
to use.
On the other hand, we have an expectation that these same boxes are 
going to perform source address based forwarding selection, something 
with which there is very little experience anywhere?

Yours,
Joel

On 11/14/2011 7:41 PM, Michael Richardson wrote:
>
>>>>>> "Guillaume" == Guillaume Habault<[email-masked]>  writes:

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2011 20:05:07 -0500

>> network and then move around with it.

I want my PAN network reachable (and able to reach) the Home network of

    >> Maybe the times are getting ripe.

Yes....  Perhaps you see why I care little about Zigbee in my RPL work ;-)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2011 22:15:45 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:
    Joel> On the one hand, earlier discussion emphasized that we need to
    Joel> use protocols 
    Joel> and implementations that are well tested, robust, and simple
    Joel> to use. 

    Joel> On the other hand, we have an expectation that these same
    Joel> boxes are going to  perform source address based forwarding
    Joel> selection, something with which there 
    Joel> is very little experience anywhere?

I'm not sure what would count as experience here.

Selecting a destination address routing table to use by source address
is relatively common, done regularly in Linux and Cisco and Brocade and
Juniper... for more than a decade.

If you mean that we don't have a protocol to explain the source
addresses required, then I disagree: the information is already all
there in the RAs, and would also be in the zOSPF for a solution that
uses that.

---

From: Guillaume Habault <[email-masked]>
Date: Wed, 16 Nov 2011 11:05:19 +0100

2011/11/15 Michael Richardson <[email-masked]>

> can accept that source address.

To summarize and to be sure I get what you are planning to do, you will use
a "normal" routing in the home network. Then, home gateways will check the
source address of any packet coming and redirect it to the right home
gateways if the source address is not the good one (just to be sure on what
you mean by cooperate), is that right?
If so, do you planned to have tunnels between home gateways ? Are we sure
that ISPs behind the home gateway will accept to cooperate with each other
(I said that because in France, home gateways are mainly given/lend by
ISPs, and i'm not sure they will be willing to share something with another
ISP)?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Nov 2011 12:15:34 -0500

Guillaume> the host select the appropriate address, the routing
    Guillaume> protocol may route the message to the wrong Customer Edge
    Guillaume> Router (especially if we are in the case where there is
    Guillaume> more than one Customer Edge Router in the home network.

    >> We have assumed that the home gateways will cooperate and provide
    >> source address routing, making sure that packets are routed out
    >> the link which can accept that source address.

    Guillaume> To summarize and to be sure I get what you are planning
    Guillaume> to do, you will use a "normal" routing in the home
    Guillaume> network. Then, home gateways will check the source
    Guillaume> address of any packet coming and redirect it to the right
    Guillaume> home gateways if the source address is not the good one
    Guillaume> (just to be sure on what you mean by cooperate), is that
    Guillaume> right?  If so, do you planned to have tunnels between

So, go to Fred Baker's slides from yesterday:
    http://www.ietf.org/proceedings/82/slides/homenet-8.pptx
(and http://junk.sandelman.ca/junk/ietf82/homenet-8.pdf)
slide "Multihoming"

I think that it's called case 4 in the documents....
    draft-chown-homenet-arch-01
    figure 4 on page 11.

If CPERouter 2 (the right hand-one), receives a packet with a source
address which it knows (due to watching RAs and/or zOSPF) actually 
belongs to Server Provider A, then instead of handing the packet
up to Service Provider B (where it likely gets dropped), it will
instead forward the packet to Router 1.  

This forward is easy to do if Router 1 and Router 2 are on the same
layer-2 link.  I don't think we've considered the case where they are
not on the same link.

We have said that for cases where there are multiple layers of routers,
that the other layers of router MUST pick the right exit router based
upon source IP, so I think that as long as Router 2 can find a path to
Router 1, it can work even when Router 1 and Router 2 are not on the
same link.

The source-address redirect is necessary only so that we can avoid
imposing a new requirement on the hosts which might be on that layer-2
link.

    Guillaume> If so, do you planned to have tunnels between
    Guillaume> home gateways ? Are we sure that ISPs behind the home
    Guillaume> gateway will accept to cooperate with each other (I said
    Guillaume> that because in France, home gateways are mainly
    Guillaume> given/lend by ISPs, and i'm not sure they will be willing
    Guillaume> to share something with another ISP)?

No, there are no tunnels across the Internet.
The traffic is redirected within the home.

If the ISP provided home router can't speak homenet, then I guess it
won't get the right logo on it.

---

From: Guillaume Habault <[email-masked]>
Date: Fri, 18 Nov 2011 11:49:20 +0100

2011/11/16 Michael Richardson <[email-masked]>

> won't get the right logo on it.
Ok, I understand now. I did not get that you assumed that both home
gateways were on the same link. It is true that if they are on the same
link you can forward the packet to the other one. However, if it's not the
case and that you need to send back a packet to the right CPE, you somehow
will have to encapsulate this packet so that it can be routed to the other
CPE (that why I was talking about tunnel between CPE previously).

According to me, but maybe i'm wrong, it's a bit late to do the source
address routing in the CPE, especially if we are in a complex topology (I
was assuming that there would be other router inside the home network
(other than the CPE, like in the figure 3 of the
draft-chown-homenet-arch-01)). In fact, if I have a home network with the
following topology:

----------    ---------------------       ------           -----
------       ---------------------    ----------
| ISP A | - | CPE Router A | --- | R1 | ------ | R2 | ------ | R3 | --- |
CPE Router B | - | ISP B |
----------    ---------------------       ------           -----
------       ---------------------    ----------

                      |

                      -------

                   | Host |

                -------

   1. Case 1: CPE Routers are the only one doing the source address routing
   (I assume it's what you were describing)
   If the Host sends a packet, and that this packet, which actually belongs
   to CPE Router B, is routed to the CPE Router A. CPE Router A will have to
   forward it all the way back to CPE Router B.

   2. Case 2: Some Interior Routers are doing the source address routing (I
   think that not all the interior router should do it though)
   If the Host sends the same packet, R3 will directly see that to avoid
   ingress filtering it has to send it to CPE Router B.

As long as the topology is simple (no interior router) or that CPEs are on
the same link, case 1 is fine. However, if we are in a more complex
topology, i think case 2 is the most appropriate. And if interior routers
are doing the source address routing there is no need for the CPE to do it,
unless it had Hosts directly connected to it.

---

From: Teco Boot <[email-masked]>
Date: Fri, 18 Nov 2011 12:08:05 +0100

Op 18 nov. 2011, om 11:49 heeft Guillaume Habault het volgende geschreven:

> Ok, I understand now. I did not get that you assumed that both home gateways were on the same link. It is true that if they are on the same link you can forward the packet to the other one. However, if it's not the case and that you need to send back a packet to the right CPE, you somehow will have to encapsulate this packet so that it can be routed to the other CPE (that why I was talking about tunnel between CPE previously). 
> 
> According to me, but maybe i'm wrong, it's a bit late to do the source address routing in the CPE, especially if we are in a complex topology (I was assuming that there would be other router inside the home network (other than the CPE, like in the figure 3 of the draft-chown-homenet-arch-01)). In fact, if I have a home network with the following topology:
> 
> ----------    ---------------------       ------           -----           ------       ---------------------    ----------
> | ISP A | - | CPE Router A | --- | R1 | ------ | R2 | ------ | R3 | --- | CPE Router B | - | ISP B |
> ----------    ---------------------       ------           -----           ------       ---------------------    ----------
>                                                                                        |
>                                                                                    -------
>                                                                                   | Host |
>                                                                                    -------
> Case 1: CPE Routers are the only one doing the source address routing (I assume it's what you were describing)
> If the Host sends a packet, and that this packet, which actually belongs to CPE Router B, is routed to the CPE Router A. CPE Router A will have to forward it all the way back to CPE Router B.
> 
> Case 2: Some Interior Routers are doing the source address routing (I think that not all the interior router should do it though)
> If the Host sends the same packet, R3 will directly see that to avoid ingress filtering it has to send it to CPE Router B.
> As long as the topology is simple (no interior router) or that CPEs are on the same link, case 1 is fine. However, if we are in a more complex topology, i think case 2 is the most appropriate. And if interior routers are doing the source address routing there is no need for the CPE to do it, unless it had Hosts directly connected to it.

If part of the routers do SA routing, doensn't that look loopy?

I say all routers have the same forwarding algorithm.
Two methods: CPE redirects packets to right "other CPE" with tunnel (or RH). Or all routers send packets to correct CPE in the first place. Latter looks better to me. Time to resubmit draft-boot-brdp-based-routing, I think.

Teco

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2011 13:45:41 -0500

>>>>> "Guillaume" == Guillaume Habault <[email-masked]> writes:
    Guillaume> If so, do you planned to have tunnels between home
    Guillaume> gateways ? Are we sure that ISPs behind the home gateway
    Guillaume> will accept to cooperate with each other (I said that
    Guillaume> because in France, home gateways are mainly given/lend by
    Guillaume> ISPs, and i'm not sure they will be willing to share
    Guillaume> something with another ISP)?
    >> No, there are no tunnels across the Internet.  The traffic is
    >> redirected within the home.
    >> 
    >> If the ISP provided home router can't speak homenet, then I guess
    >> it won't get the right logo on it.

    Guillaume> Ok, I understand now. I did not get that you assumed that
    Guillaume> both home gateways were on the same link. It is true that
    Guillaume> if they are on the same link you can forward the packet
    Guillaume> to the other one. However, if it's not the case and that
    Guillaume> you need to send back a packet to the right CPE, you
    Guillaume> somehow will have to encapsulate this packet so that it
    Guillaume> can be routed to the other CPE (that why I was talking
    Guillaume> about tunnel between CPE previously).

If the two links are not on the same link, then the problem we have is
finding the right router that can send the traffic out.  

We only have to do this for traffic originating on the local link from
hosts on that local link.  We likely also have to do this for traffic to
other links in the homenet as well, as the hosts on the local link won't
have the complete routing table.

For traffic within the homenet, we do normal destination address
routing, and our routing protocol tells us how to do this.   For traffic
out to the other ISP, we have to figure out which is the correct exit
router, and find a route to that CPE router's inside address in our
routing table, and then we can pick the correct direction to forward.

As all homenet routers are expected to do this same source address
routing, I don't think we a tunnel to the exit router.   

However, it might be more resilient to pop the packet into an IPIP
header and address the ULA of the inside of the correct CPE router.
I think that we will need keep this option open as a MAY pending
implementation experience.  That means that we need to write a MUST
about decapsulating things to your ULA address in IPIP.

---

From: Teco Boot <[email-masked]>
Date: Sat, 19 Nov 2011 08:21:37 +0100

> about decapsulating things to your ULA address in IPIP.

Some basic stuff for this is implemented in olsrd (olsr.org), in the Smart Gateway facility.
I can't see why inside address of border needs to be ULA.
Since when might tunnels be "more resilient"? :-)

Teco

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Nov 2011 20:51:23 -0500

>>>>> "Teco" == Teco Boot <[email-masked]> writes:
    >> If the two links are not on the same link, then the problem we
    >> have is finding the right router that can send the traffic out.
    >> 
    >> We only have to do this for traffic originating on the local link
    >> from hosts on that local link.  We likely also have to do this
    >> for traffic to other links in the homenet as well, as the hosts
    >> on the local link won't have the complete routing table.
    >> 
    >> routing, and our routing protocol tells us how to do this.  For
    >> traffic out to the other ISP, we have to figure out which is the
    >> correct exit router, and find a route to that CPE router's inside
    >> address in our routing table, and then we can pick the correct
    >> direction to forward.
    >> 
    >> As all homenet routers are expected to do this same source
    >> address routing, I don't think we a tunnel to the exit router.
    >> 
    >> However, it might be more resilient to pop the packet into an
    >> IPIP header and address the ULA of the inside of the correct CPE
    >> router.  I think that we will need keep this option open as a MAY
    >> pending implementation experience.  That means that we need to
    >> write a MUST about decapsulating things to your ULA address in
    >> IPIP.

    Teco> Some basic stuff for this is implemented in olsrd (olsr.org),
    Teco> in the Smart Gateway facility.  I can't see why inside address
    Teco> of border needs to be ULA.  Since when might tunnels be "more
    Teco> resilient"? :-)

When the number of internal LANs exceeds the number of subnets available
from a particular ISP.