Subject: [v6ops] Tsinghua work on source/destination routing

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:45:06 +0000

I'd like to draw your attention to a talk that will be given this morning in homenet. The context is:

http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cases
http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases
  "Requirements and Use Cases for Source/Destination Routing", Fred Baker,
  2013-08-13

http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class
http://tools.ietf.org/html/draft-xu-homenet-traffic-class
  "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang,
  Jianping Wu, Fred Baker, 2013-10-21

http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing
http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
  "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
  Yang, Jianping Wu, Dan Wang, 2013-08-22

http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing
http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28

http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend
http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend
  "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
  Baker, 2013-10-15

I had breakfast this morning with Shu Yang, who has been writing Quagga code for several years in the course of his PHd. He first implemented a source/destination model, reported on in draft-xu-homenet-twod-ip-routing, which was an MTR scheme. He tells me he found that very complex. He also listened to my talk in homenet around draft-baker-fun-routing-class, and has now implemented (if I understand him correctly) draft-ietf-ospf-ospfv3-lsa-extend and draft-baker-ipv6-ospf-dst-src-routing. The FIB implementation has a limitation: the source prefixes must be disjoint. However, given that, he has two FIB implementations, one of which has separate FIBs for each source prefix in play including ::/0 (so if there are M prefixes in the network, M+1 FIBs), and one of which is a single hierarchical M-Trie that looks up the destination and then the source. He has tested the code in simulation; the next step is testing in live networks.

Examples of use cases are generally around multi-prefix campus networks. There is a security use case that could be of value; at IETF 87, George Michaelson of APNIC reported on ULAs seen in his darknet. The short report is that he sees a fair bit of traffic with a ULA source address on the backbone. An interesting potential use of source/destination routing would counter that, and perhaps mitigate the need for ISP BCP 38 if generally deployed; in a case where a network is using a ULA and a global prefix (e.g., is not multihomed but has two prefixes, one of which is intended to only be used within its network), the default route to the network egress would use the global prefix as a source, and as a result traffic sent outside the network with a ULA source prefix would in effect have no route. The network could literally only emit traffic from its correct prefix.

I think this is relevant to the discussion of 
	draft-baker-rtgwg-src-dst-routing-use-cases
	draft-ietf-ospf-ospfv3-lsa-extend
	draft-baker-ipv6-ospf-dst-src-routing
	draft-baker-ipv6-isis-dst-src-routing

---

From: Jen Linkova <[email-masked]>
Date: Thu, 7 Nov 2013 17:58:56 +0100

> Examples of use cases are generally around multi-prefix campus networks. There is a security use case that could be of value; at IETF 87, George Michaelson of APNIC reported on ULAs seen in his dar…

Looks like we (finally) have a chance to enforce the requirement from
RFC4007, Section9:

"If transmitting the packet on the chosen next-hop interface
would cause the packet to leave the zone of the source
address, i.e.,
cross a zone boundary of the scope of the
source address, then the packet is discarded. "

I'm seeing plenty of packets from link-local sources to global
destinations which means that:
1) there are hosts with broken default address selection
AND
2) routers on the Internet do forward such packets (violating the rule
mentioned above).
Fixing #2 actually requires making forwarding decision based on src
and dst (which is not happening now).

More data (sorry, shameless plug :))
https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf

-- 
SY, Jen Linkova aka Furry

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Nov 2013 17:07:34 +0000

Hi Fred,

It is good to see this discussion, but an alternative approach that should
also be considered is tunneling. In the IRON approach at least, the end
user network gets a stable IPv6 prefix that is independent of the access
network IP addresses it gets from its ISPs. So, there is no need for source
address-based forwarding to ensure that packets sent via ISP A will not
have a source address from ISP B.

The use cases for tunneling are very broad, and probably overlap with the
ones you are considering in this approach. The relevant documents are here:

http://tools.ietf.org/html/draft-templin-ironbis
http://tools.ietf.org/html/draft-templin-intarea-vet
http://tools.ietf.org/html/draft-templin-intarea-seal
  
Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
> Sent: Thursday, November 07, 2013 8:45 AM
> To: Routing WG; [email-masked]; [email-masked]
> Cc: [email-masked] Group; [email-masked] WG
> Subject: [v6ops] Tsinghua work on source/destination routing
> 
> I had breakfast this morning with Shu Yang, who has been writing Quagga code for several years in the
> course of his PHd. He first implemented a source/destination model, reported on in draft-xu-homenet-
> twod-ip-routing, which was an MTR scheme. He tells me he found that very complex. He also listened to
> my talk in homenet around draft-baker-fun-routing-class, and has now implemented (if I understand him
> correctly) draft-ietf-ospf-ospfv3-lsa-extend and draft-baker-ipv6-ospf-dst-src-routing. The FIB
> implementation has a limitation: the source prefixes must be disjoint. However, given that, he has two
> FIB implementations, one of which has separate FIBs for each source prefix in play including ::/0 (so
> if there are M prefixes in the network, M+1 FIBs), and one of which is a single hierarchical M-Trie
> that looks up the destination and then the source. He has tested the code in simulation; the next step
> is testing in live networks.
> 
> Examples of use cases are generally around multi-prefix campus networks. There is a security use case
> that could be of value; at IETF 87, George Michaelson of APNIC reported on ULAs seen in his darknet.
> The short report is that he sees a fair bit of traffic with a ULA source address on the backbone. An
> interesting potential use of source/destination routing would counter that, and perhaps mitigate the
> need for ISP BCP 38 if generally deployed; in a case where a network is using a ULA and a global
> prefix (e.g., is not multihomed but has two prefixes, one of which is intended to only be used within
> its network), the default route to the network egress would use the global prefix as a source, and as
> a result traffic sent outside the network with a ULA source prefix would in effect have no route. The
> network could literally only emit traffic from its correct prefix.
>

---

From: Hermin Anggawijaya <[email-masked]>
Date: Thu, 7 Nov 2013 10:40:08 -0800

> I'm seeing plenty of packets from link-local sources to global
destinations
> .....
mentioned above).
> and dst (which is not happening now).

To fix the above issue, wouldn't address scope checking be enough, rather
than the [src,dst] based routing
discussed ?

On Thu, Nov 7, 2013 at 8:58 AM, Jen Linkova <[email-masked]> wrote:

> > Examples of use cases are generally around multi-prefix campus networks.
> There is a security use case that could be of value; at IETF 87, George
> Michaelson of APNIC reported on ULAs seen in his darknet. The short report
> is that he sees a fair bit of traffic with a ULA source address on the
> backbone. An interesting potential use of source/destination routing would
> counter that, and perhaps mitigate the need for ISP BCP 38 if generally
> deployed; in a case where a network is using a ULA and a global prefix
> (e.g., is not multihomed but has two prefixes, one of which is intended to
> only be used within its network), the default route to the network egress
> would use the global prefix as a source, and as a result traffic sent
> outside the network with a ULA source prefix would in effect have no route.
> The network could literally only emit traffic from its correct prefix.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Nov 2013 10:42:52 -0800

At Thu, 7 Nov 2013 17:58:56 +0100,

> 1) there are hosts with broken default address selection

(Probably an off-topic in this context but) this is not necessarily
accurate.  If a host only has a link-local address but somehow knows
the interface to send packets to a global destination, it would be
able to send packets with source being link-local and destination
being global, and validly (not breaking RFC 6724) so.  I believe it's
more likely to be a broken network configuration than a broken host
implementation.

--
JINMEI, Tatuya

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 Nov 2013 18:56:12 +0000

> more likely to be a broken network configuration than a broken host

I suspect it's some of each. The host should, I should think, set the hop limit to one on any packet that is to a link-local address, to ensure that the packet is not repeated by a broken router (apart from protocols that ask to have it set to 255 and have the receiving host check for that value). Also, upstream network's BCP 38 implementation sounds suspect, and I'm with Jen in wondering why a router forwarded the packet in the first place.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Nov 2013 08:21:50 +1300

> I suspect it's some of each. The host should, I should think, set the hop limit to one on any packet that is to a link-local address, to ensure that the packet is not repeated by a broken router (a…

Are you sure these packets come from hosts? There is a known case
which is a router generating ICMP reply packets that has no GUA
configured since all its peers are link-local.

   Brian

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Nov 2013 00:27:04 +0100

> than the [src,dst] based routing

My point is that to do verify the scope, the router need to check
*source* address while making forwarding decision.
It looks like it is not happening now but it might get changed by
[src, dst] based routing.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Nov 2013 00:33:40 +0100

> configured since all its peers are link-local.

I saw packets with link-local source/GUA destination coming from hosts
and from routers (I analyzed EUI-64-based IIDs) back in 2011. Now
majority of such traffic is TCP to our services and, again, IID checks
shows that these packets are from hosts.

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Nov 2013 23:47:30 +0000

> shows that these packets are from hosts.

Any specifc clues by vendor?

Tim

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Nov 2013 00:58:22 +0100

> Any specifc clues by vendor?

I decided not to put any names on the slides but I identified ~20
vendors (see slide #8 at
https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf )

P.S. One more reason for me to like EUI-64-based IID ;-))

---

From: Hermin Anggawijaya <[email-masked]>
Date: Thu, 7 Nov 2013 16:13:39 -0800

> [src, dst] based routing.

scope checking does not need to look up any fib though whereas [src,dst]
forwarding does. I think scope checking feature is standard even on
switching silicons *today*.

But I think I understand what you are trying to say, we just have different
interpretation of the phrase [src,dst] forwarding. Thanks.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Nov 2013 17:57:39 -0800

At Thu, 7 Nov 2013 18:56:12 +0000,
"Fred Baker (fred)" <[email-masked]> wrote:

> I suspect it's some of each. The host should, I should think, set
> the hop limit to one on any packet that is to a link-local address,

To make it sure: this is about the case of packets "from" a link-local
address.

> to ensure that the packet is not repeated by a broken router (apart
> from protocols that ask to have it set to 255 and have the receiving
> host check for that value). Also, upstream network's BCP 38

I'd note, from purely architectural point of view, that it's totally
valid a packet that has a link-local address is forwarded, as long as
the packet remains in the originating link zone.  That would be a very
unlikely case in practice, but can still happen, e.g., when a host
sends all packets to a router, expecting the router to forward it back
to the same link toward the destination.  RFC 4007 mentions such
cases.

That said, I see it should be a very rare case except for
implementation or operational errors.  So it may make sense to
introduce something similar to the IPV6_MULTICAST_HOPS socket option
defined in RFC 3493 and define its default value to be 1 for narrower
scopes.

> implementation sounds suspect, and I'm with Jen in wondering why a
> router forwarded the packet in the first place.

It's not surprising to me since the source address is not needed as
long as routing decision is only made based on the destination
address.  I noticed one popular router vendor didn't implement this
restriction of RFC 4007 correctly many years ago and even reported it
to the vendor, but (assuming it's still not fixed) just being "non
compliant" is probably not convincing enough for them to introduce
additional overhead in their forwarding logic.

--
JINMEI, Tatuya

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Nov 2013 18:42:02 -0800

> to the same link toward the destination.  RFC 4007 mentions such

That is not correct…

RFC 4291 says:

2.5.6.  Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

It is quite clear that a packet with a link-local address in either field MUST not be forwarded.

> additional overhead in their forwarding logic.

It's surprising to me and it means that the router is, by definition, not compliant with RFC 4291, ergo, the router is broken.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Nov 2013 18:38:46 -0800

> shows that these packets are from hosts.

It is not wrong for a node {host, router} to emit a packet with a link-local source and a destination in another scope.

It is wrong for a router to forward a packet containing a link-local scope address (source or destination). It is wrong to do so regardless of whether the outgoing link is the same as the incoming link or not.

Owen

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Nov 2013 23:17:35 -0800

At Thu, 7 Nov 2013 18:42:02 -0800,
Owen DeLong <[email-masked]> wrote:

> > the packet remains in the originating link zone. [...]
>
> That is not correct…
>
> RFC 4291 says:
[...]
> field MUST not be forwarded.

Don't forget the "to other links" part.  This make it valid, e.g.,
that a router forwards a packet with a link-local source address back
to the receiving link.  A stubborn person might still argue that
"other" can include the receiving link itself, and in a sense I admit
it might confuse readers.  In fact, such confusion is one of the
things RFC 4007 tried to clarify.  At the very least, I'm 100% sure
this is what Steve (Deering) intended when he co-authored the IPv6
addressing architecture spec and what he tried to clarify in RFC 4007
as a co-author of it.

> It's surprising to me and it means that the router is, by definition, not compliant with RFC 4291, ergo, the router is broken.

Of course it's broken.  But the existence of broken implementations is
not uncommon in general, so simply because something is broken doesn't
mean (to me) it's surprising there's such a thing.  And, in this
particular case, I can even see the incentive of being broken, so it's
not surprising to me at all.  But "surprising" is a subjective concept
anyway, so it's not surprising different people have different sense
of it:-)

--
JINMEI, Tatuya

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 08 Nov 2013 13:23:54 +0100

> The context is:

A pity you didn't cite any of the previous work on the subject:

  http://tools.ietf.org/html/draft-troan-homenet-sadr-01  

  https://github.com/fingon/hnet-core

  http://tools.ietf.org/html/draft-boutier-homenet-source-specific-routing
  http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git  
  
> I had breakfast this morning with Shu Yang, who has been writing
> Quagga code for several years in the course of his PHd.  [...]  and
> has now implemented (if I understand him correctly)
> draft-ietf-ospf-ospfv3-lsa-extend and
> draft-baker-ipv6-ospf-dst-src-routing.

Excellent.  Could we please have a look at the source code ?  (It was
already promised in Berlin, if memory serves.)

Regards,

-- Juliusz

---

From: Shu Yang <[email-masked]>
Date: Fri, 8 Nov 2013 20:51:44 +0800

> already promised in Berlin, if memory serves.)
We will make it public after testing it in live networks (we are still
implementing the Click code, and combining quagga and click
together).

If you want, I can send you the current version privately at this moment.

Shu Yang
Tsinghua University

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 10 Nov 2013 14:37:02 +0100

> We will make it public after testing it in live networks

Ah, I see.

> If you want, I can send you the current version privately at this moment.

I'd much prefer a public repository, something I can discuss freely
with people (and eventually cite) without worrying whether I'm disclosing
anything confidential.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Sun, 10 Nov 2013 15:24:15 +0100

> with people (and eventually cite) without worrying whether I'm disclosing

I agree with Juliusz, a public repository would be much better, even
if it only contains "in development" code.

If the code will be open sourced in the end anyways I don't see any drawbacks.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Hermin Anggawijaya <[email-masked]>
Date: Sun, 10 Nov 2013 10:09:28 -0800

I too would be interested in seeing the code if it's available in a public
repo.

cheers

Angga

---

From: Shu Yang <[email-masked]>
Date: Mon, 11 Nov 2013 15:06:05 +0800

> If the code will be open sourced in the end anyways I don't see any drawbacks.

Ok, we will make it public in this week.

Shu Yang

---

From: Shu Yang <[email-masked]>
Date: Tue, 19 Nov 2013 16:10:18 +0800

> Ok, we will make it public in this week.
The page for the project is here:
https://github.com/t-routing/traffic-class-routing-system-based-on-OSPFv3
It's still in development status, and we will keep improving it.

Shu Yang

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 19 Nov 2013 11:22:34 +0100

> The page for the project is here: https://github.com/t-routing/
> traffic-class-routing-system-based-on-OSPFv3

Thanks, but could you please point us at your code?  That's a full
Quagga tree merged with a full Click tree, with no development history.

(I've quickly checked the Quagga-FIB interface, and haven't found
anything new in there, but then perhaps I haven't looked hard enough.)

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 19 Nov 2013 12:30:59 +0200

On 19.11.2013, at 12.22, Juliusz Chroboczek <[email-masked]> wrote:

> anything new in there, but then perhaps I haven’t looked hard enough.)

Looks like the integration with click is done right from ospf6d and it never even goes to zebra. 

Two tips for next github export:

- save history so it’s more convenient to compare with baseline (now I needed to do fairly arcane diff due to non-clean tree + no history)

- put cleaned tree (no *~, no binaries such as *.o)

Kind of sad, I was hoping for general src+dst aware Quagga code :)

Cheers,

-Markus