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

From: Guillaume Habault <[email-masked]>
Date: Fri, 2 Dec 2011 17:22:30 +0100

I've attached a draft made from some research that had been performed here
to solve the ingress filtering issue in IPv6 multihomed network. That may
be interesting for homenet WG.

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

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

-- 
Guillaume HABAULT
PhD Student
Institut TELECOM / TELECOM Bretagne

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Dec 2011 11:03:44 +1300

Guillaume,

> It checks the destination address and compares to all known routes
> (except the default route). If the destination address matches an
> entry, the packet is sent to the next hop and the algorithm ends. If
> not, the source address is checked and compared to the list of
> delegated prefixes. If a match is found in this list, the packet is
> sent to the associated next hop. If there is no match, the packet is
> dropped, considered as a trial of address spoofing. With this
> process, a packet whom destination is unknown, is routed to the ISP
> edge router which has delegated the source address prefix.

How will this help with failover in multihomed sites? It guarantees
that the packet will be sent towards the failed path, I think.

Regards
   Brian Carpenter

P.S. draft-habault-gallet-homenet-sdsa doesn't seem to be on the
IETF server.

---

From: Teco Boot <[email-masked]>
Date: Sat, 3 Dec 2011 13:24:33 +0100

> that the packet will be sent towards the failed path, I think.

The sdsa mechanism is very similar to what I propose with BRDP / 
BRDP-based routing (draft-boot-brdp-framework).

This is how BRDP works: In a multi-homed-in-transit scenario, nodes 
learn new prefixes and may use these for new connections. The question 
is: how can the network take prefixes out of service, without loosing 
connections? This requires some configuration, e.g. remove prefix from 
router advertisement. In BRDP, I suggest making the nodes aware of the 
metric of the prefix. So hosts are guided to use the preferred prefix.
The alternate prefix can be used for multi-path or happy eyeballs type 
of connections.

If the transport can make use of the alternate prefix (like MPTCP), some 
packets are lost but the connection survives. Short lived connections 
(like DNS) should not have problems.

Teco

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Dec 2011 08:59:28 -0500

Guillaume Habault <[email-masked]> sends the draft 
draft-habault-gallet-homenet-sdsa-00:

>                                       The construction and
>maintenance of such tables is time-consuming and all routes to site
>destinations are duplicate on each table.

Really?   I agree that it increases the number of routes from 1 default
route to n-default routes, but given that n is generally <<100,
typically less than 10, I don't see this as a consideration.

I guess I'm confused.  Perhaps you are comparing the situation without
SDSA to a situation where an edge had a complete routing table?

Your algorithm is a bit to much of a design document, rather than a
functional requirements on what must occur.  Your implementation (look
up specific routes first, then look up prefixes to select a default
route) isn't the only way to implement things.  

It is the downside that it's a significant change from existing longest
prefix fast paths, while the method of selecting a routing table (which
may have repeated routes to local destinations) by source address ("ip
rule from" in Linux, VRF in IOS) results in more memory in the big, it
is also already widely implemented, and if someone puts it in hardware
($50 Gigabit ethernet capable home routers are not commonly wirespeed
today, but could be tomorrow), then they can reuse a ASIC design.

-- 
]       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: Guillaume Habault <[email-masked]>
Date: Tue, 6 Dec 2011 11:39:04 +0100

2011/12/2 Brian E Carpenter <[email-masked]>

> that the packet will be sent towards the failed path, I think.
You are right! We were thinking that in case of a failover the host would
have to detect it and not choose the source address linked to that ISP
using Shim6 for example (the draft is based on research performed in 2009).
SDSA is only to route packets to the correct ISP in order to avoid ingress
filtering issue.
I'm not clear whether an homenet network has to only route packet or should
it be able to manipulate them (i.e. modifying, encapsulating...) if it's
needed. Because if a packet is sent towards the failed path, it means that
the host use the source address linked to that ISP. And if the network has
to redirect to the other ISP, it would need to change the source address of
the packet in order to avoid having that the ISP drop this packet.
For instance, in a network where we have two ISP, ISP A and B. In a case of
a failover of one of the ISP (let's say ISP A). If the host sends a packet
with its ISP A source address, the routing protocol, that will have
detected the failover, will forward the packet to the border router of the
ISP B. It could be:

   1. a layer2 forwarding if border router are on the same link;
   2. and if not, a encapsulation of the packet toward the border router B.

In both case, when the packet arrives to the border router B, the source
address of this packet is still the one made from the prefix of ISP A. So,
ISP B will drop the packet.

So, according to me, the possible solutions in case of failover are:

   1. modifying the source address of the packet if the host choose the
   wrong source address, "and so" the prefix assuming that the SID is always
   the same for one host (which may not be the case though...);
   2. let the host detects the failover and chooses its source address
   accordingly (if so, it's out of the scope of homenet I think)

For the first case, as long as, it's only for one packet it could be fine
but if there are several packets, it may not be the best. I think the best
is to avoid as much as possible to manipulate the packets in the network.

And so, let the host detects the failover (that could be helped by the
network). Sure there will be some packet loss (but in a case of failover i
don't think we can avoid to have some packet loss) but there will be less
manipulation from the network.

2011/12/3 Teco Boot <[email-masked]>

> BRDP-based routing (draft-boot-brdp-framework).

They are similar indeed. In SDSA, routers use a prefix table whereas in
BRDP they use the BRIO cache, right?

2011/12/4 Michael Richardson <[email-masked]>

Guillaume Habault <[email-masked]> sends the draft
draft-habault-gallet-homenet-

> SDSA to a situation where an edge had a complete routing table?

In the part you quoted, we were actually talking about SAD routing
mechanism not SDSA.

> It sure is not the only way to do it (it helps me discover DBRP), but I
just wanted to share this as it could be interesting. I'm trying to
understand what is the position of homenet regarding multihoming, and how
(and what) they planned to manage in the network, as it's what I'm
currently working on :-)

Regards,