Hello!
This patch supports standard default source address selection
algorithm. It takes status, address/prefix itself (prefer same address,
prefer longest matching prefix) into consideration.
Note: Even though matching label is not implemented yet,
this is better than current one.
Following patch is against linux-2.4.19.
Thank you in advance.
-------------------------------------------------------------------
Patch-Name: Improvement of Source Address Selection
Patch-Id: FIX_2_4_19_SADDRSELECT-20020906
Patch-Author: YOSHIFUJI Hideaki / USAGI Project <[email protected]>
Credit: YOSHIFUJI Hideaki / USAGI Project <[email protected]>
Reference: draft-ietf-ipv6-default-addr-select-09.txt
-------------------------------------------------------------------
Index: include/net/addrconf.h
===================================================================
RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/addrconf.h,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.6.1
diff -u -r1.1.1.1 -r1.1.1.1.6.1
--- include/net/addrconf.h 2002/08/20 09:46:45 1.1.1.1
+++ include/net/addrconf.h 2002/09/26 19:15:15 1.1.1.1.6.1
@@ -55,6 +55,9 @@
struct net_device *dev);
extern struct inet6_ifaddr * ipv6_get_ifaddr(struct in6_addr *addr,
struct net_device *dev);
+extern int ipv6_dev_get_saddr(struct net_device *ddev,
+ struct in6_addr *daddr,
+ struct in6_addr *saddr);
extern int ipv6_get_saddr(struct dst_entry *dst,
struct in6_addr *daddr,
struct in6_addr *saddr);
Index: net/ipv6/addrconf.c
===================================================================
RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.6.4
diff -u -r1.1.1.1 -r1.1.1.1.6.4
--- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1
+++ net/ipv6/addrconf.c 2002/09/26 19:28:13 1.1.1.1.6.4
@@ -26,6 +26,10 @@
* packets.
* yoshfuji@USAGI : Fixed interval between DAD
* packets.
+ * YOSHIFUJI Hideaki @USAGI : improved source address
+ * selection; consider scope,
+ * status etc.
+ *
*/
#include <linux/config.h>
@@ -188,6 +192,99 @@
return IPV6_ADDR_RESERVED;
}
+#ifndef IPV6_ADDR_MC_SCOPE
+#define IPV6_ADDR_MC_SCOPE(a) \
+ ((a)->s6_addr[1] & 0x0f) /* XXX nonstandard */
+#define __IPV6_ADDR_SCOPE_RESERVED -2
+#define __IPV6_ADDR_SCOPE_ANY -1
+#define IPV6_ADDR_SCOPE_NODELOCAL 0x01
+#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02
+#define IPV6_ADDR_SCOPE_SITELOCAL 0x05
+#define IPV6_ADDR_SCOPE_ORGLOCAL 0x08
+#define IPV6_ADDR_SCOPE_GLOBAL 0x0e
+#endif
+
+int ipv6_addrselect_scope(const struct in6_addr *addr)
+{
+ u32 st;
+
+ st = addr->s6_addr32[0];
+
+ if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) &&
+ (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000))
+ return IPV6_ADDR_SCOPE_GLOBAL;
+
+ if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000))
+ return IPV6_ADDR_MC_SCOPE(addr);
+
+ if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000))
+ return IPV6_ADDR_SCOPE_LINKLOCAL;
+
+ if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000))
+ return IPV6_ADDR_SCOPE_SITELOCAL;
+
+ if ((st | addr->s6_addr32[1]) == 0) {
+ if (addr->s6_addr32[2] == 0) {
+ if (addr->s6_addr32[3] == 0)
+ return __IPV6_ADDR_SCOPE_ANY;
+
+ if (addr->s6_addr32[3] == __constant_htonl(0x00000001))
+ return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.4 */
+
+ return IPV6_ADDR_SCOPE_GLOBAL; /* section 2.3 */
+ }
+
+ if (addr->s6_addr32[2] == __constant_htonl(0x0000FFFF)) {
+ if (addr->s6_addr32[3] == __constant_htonl(0xA9FF0000))
+ return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */
+ if (addr->s6_addr32[3] == __constant_htonl(0xAC000000)) {
+ if (addr->s6_addr32[3] == __constant_htonl(0xAC100000))
+ return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */
+
+ return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */
+ }
+ if (addr->s6_addr32[3] == __constant_htonl(0x0A000000))
+ return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */
+ if (addr->s6_addr32[3] == __constant_htonl(0xC0A80000))
+ return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */
+
+ return IPV6_ADDR_SCOPE_GLOBAL; /* section 2.2 */
+ }
+ }
+
+ return __IPV6_ADDR_SCOPE_RESERVED;
+}
+
+/* find 1st bit in difference between the 2 addrs */
+static inline int addr_diff(const void *__a1, const void *__a2, int addrlen)
+{
+ /* find 1st bit in difference between the 2 addrs.
+ * bit may be an invalid value,
+ * but if it is >= plen, the value is ignored in any case.
+ */
+ const u32 *a1 = __a1;
+ const u32 *a2 = __a2;
+ int i;
+
+ addrlen >>= 2;
+ for (i = 0; i < addrlen; i++) {
+ u32 xb = a1[i] ^ a2[i];
+ if (xb) {
+ int j = 31;
+ xb = ntohl(xb);
+ while ((xb & (1 << j)) == 0)
+ j--;
+ return (i * 32 + 31 - j);
+ }
+ }
+ return addrlen<<5;
+}
+
+static inline int ipv6_addr_diff(const struct in6_addr *a1, const struct in6_addr *a2)
+{
+ return addr_diff(a1->s6_addr, a2->s6_addr, sizeof(struct in6_addr));
+}
+
static void addrconf_del_timer(struct inet6_ifaddr *ifp)
{
if (del_timer(&ifp->timer))
@@ -449,120 +546,137 @@
/*
* Choose an apropriate source address
- * should do:
- * i) get an address with an apropriate scope
- * ii) see if there is a specific route for the destination and use
- * an address of the attached interface
- * iii) don't use deprecated addresses
+ * draft-ietf-ipngwg-default-addr-select-09.txt
*/
-int ipv6_get_saddr(struct dst_entry *dst,
- struct in6_addr *daddr, struct in6_addr *saddr)
+struct addrselect_attrs {
+ struct inet6_ifaddr *ifp;
+ int match;
+ int deprecated;
+ int home;
+ int temporary;
+ int device;
+ int scope;
+ int label;
+ int matchlen;
+};
+
+int ipv6_dev_get_saddr(struct net_device *daddr_dev,
+ struct in6_addr *daddr, struct in6_addr *saddr)
{
- int scope;
- struct inet6_ifaddr *ifp = NULL;
- struct inet6_ifaddr *match = NULL;
- struct net_device *dev = NULL;
+ int daddr_scope;
+ struct inet6_ifaddr *ifp0, *ifp = NULL;
+ struct net_device *dev;
struct inet6_dev *idev;
- struct rt6_info *rt;
- int err;
- rt = (struct rt6_info *) dst;
- if (rt)
- dev = rt->rt6i_dev;
-
- scope = ipv6_addr_scope(daddr);
- if (rt && (rt->rt6i_flags & RTF_ALLONLINK)) {
- /*
- * route for the "all destinations on link" rule
- * when no routers are present
- */
- scope = IFA_LINK;
- }
-
- /*
- * known dev
- * search dev and walk through dev addresses
- */
+ int err;
+ int update;
+ struct addrselect_attrs candidate = {NULL,0,0,0,0,0,0,0,0};
- if (dev) {
- if (dev->flags & IFF_LOOPBACK)
- scope = IFA_HOST;
+ daddr_scope = ipv6_addrselect_scope(daddr);
- read_lock(&addrconf_lock);
+ read_lock(&dev_base_lock);
+ read_lock(&addrconf_lock);
+ for (dev = dev_base; dev; dev=dev->next) {
idev = __in6_dev_get(dev);
- if (idev) {
- read_lock_bh(&idev->lock);
- for (ifp=idev->addr_list; ifp; ifp=ifp->if_next) {
- if (ifp->scope == scope) {
- if (!(ifp->flags & (IFA_F_DEPRECATED|IFA_F_TENTATIVE))) {
- in6_ifa_hold(ifp);
- read_unlock_bh(&idev->lock);
- read_unlock(&addrconf_lock);
- goto out;
- }
-
- if (!match && !(ifp->flags & IFA_F_TENTATIVE)) {
- match = ifp;
- in6_ifa_hold(ifp);
- }
+
+ if (!idev)
+ continue;
+
+ read_lock_bh(&idev->lock);
+ ifp0 = idev->addr_list;
+ for (ifp=ifp0; ifp; ifp=ifp->if_next) {
+ struct addrselect_attrs temp = {NULL,0,0,0,0,0,0,0,0};
+ update = 0;
+
+ /* Rule 1: Prefer same address */
+ temp.match = ipv6_addr_cmp(&ifp->addr, daddr) == 0;
+ if (!update)
+ update = temp.match - candidate.match;
+ if (update < 0) {
+ continue;
+ }
+
+ /* Rule 2: Prefer appropriate scope */
+ temp.scope = ipv6_addrselect_scope(&ifp->addr);
+ if (!update) {
+ update = temp.scope - candidate.scope;
+ if (update > 0) {
+ update = candidate.scope < daddr_scope ? 1 : -1;
+ } else if (update < 0) {
+ update = temp.scope < daddr_scope ? -1 : 1;
}
}
- read_unlock_bh(&idev->lock);
- }
- read_unlock(&addrconf_lock);
- }
+ if (update < 0) {
+ continue;
+ }
- if (scope == IFA_LINK)
- goto out;
+ /* Rule 3: Avoid deprecated address */
+ temp.deprecated = ifp->flags & IFA_F_DEPRECATED;
+ if (!update)
+ update = candidate.deprecated - temp.deprecated;
+ if (update < 0) {
+ continue;
+ }
- /*
- * dev == NULL or search failed for specified dev
- */
+ /* XXX: Rule 4: Prefer home address */
- read_lock(&dev_base_lock);
- read_lock(&addrconf_lock);
- for (dev = dev_base; dev; dev=dev->next) {
- idev = __in6_dev_get(dev);
- if (idev) {
- read_lock_bh(&idev->lock);
- for (ifp=idev->addr_list; ifp; ifp=ifp->if_next) {
- if (ifp->scope == scope) {
- if (!(ifp->flags&(IFA_F_DEPRECATED|IFA_F_TENTATIVE))) {
- in6_ifa_hold(ifp);
- read_unlock_bh(&idev->lock);
- goto out_unlock_base;
- }
-
- if (!match && !(ifp->flags&IFA_F_TENTATIVE)) {
- match = ifp;
- in6_ifa_hold(ifp);
- }
- }
+ /* Rule 5: Prefer outgoing interface */
+ temp.device = daddr_dev ? daddr_dev == (ifp->idev ? ifp->idev->dev : daddr_dev) : 0;
+ if (!update)
+ update = temp.device - candidate.device;
+ if (update < 0) {
+ continue;
+ }
+
+ /* XXX: Rule 6: Prefer matching label */
+ temp.label = 0;
+ if (!update)
+ update = temp.label - candidate.label;
+ if (update < 0) {
+ continue;
}
- read_unlock_bh(&idev->lock);
+
+ /* XXX: Rule 7: Prefer public address */
+
+ /* Rule 8: Use longest matching prefix */
+ temp.matchlen = ipv6_addr_diff(&ifp->addr, daddr);
+ if (!update)
+ update = temp.matchlen - candidate.matchlen;
+ if (update < 0) {
+ continue;
+ }
+
+ /* Final Rule */
+ if (update <= 0)
+ continue;
+
+ /* update candidate */
+ temp.ifp = ifp;
+ in6_ifa_hold(ifp);
+ if (candidate.ifp)
+ in6_ifa_put(candidate.ifp);
+ candidate = temp;
}
+ read_unlock_bh(&idev->lock);
}
-
-out_unlock_base:
read_unlock(&addrconf_lock);
read_unlock(&dev_base_lock);
-
-out:
- if (ifp == NULL) {
- ifp = match;
- match = NULL;
- }
- err = -EADDRNOTAVAIL;
- if (ifp) {
- ipv6_addr_copy(saddr, &ifp->addr);
+ if (candidate.ifp) {
+ ipv6_addr_copy(saddr, &candidate.ifp->addr);
+ in6_ifa_put(candidate.ifp);
err = 0;
- in6_ifa_put(ifp);
+ } else {
+ err = -EADDRNOTAVAIL;
}
- if (match)
- in6_ifa_put(match);
-
return err;
+}
+
+int ipv6_get_saddr(struct dst_entry *dst,
+ struct in6_addr *daddr, struct in6_addr *saddr)
+{
+ return ipv6_dev_get_saddr(dst ? ((struct rt6_info *)dst)->rt6i_dev : NULL,
+ daddr, saddr);
}
int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr)
From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Sat, 28 Sep 2002 00:17:42 +0900 (JST)
Please redesign this structure.
+struct addrselect_attrs {
+ struct inet6_ifaddr *ifp;
+ int match;
+ int deprecated;
+ int home;
+ int temporary;
+ int device;
+ int scope;
+ int label;
+ int matchlen;
+};
This is much larger than it needs to be. Please replace these "int"
binary states with single "u32 flags;" and appropriate bit
definitions.
This structure sits on the stack, so it is important to be
as small as we can easily make it.
Otherwise I have no problems with the patch, Alexey?
Hello!
> Otherwise I have no problems with the patch, Alexey?
I have... The implementation is bad. Source address must be retieved
from route, not running this elephant function each packet.
Alexey
On Sat, Sep 28, 2002 at 06:28:29AM +0400, A.N.Kuznetsov wrote:
> Hello!
>
> > Otherwise I have no problems with the patch, Alexey?
>
> I have... The implementation is bad. Source address must be retieved
> from route, not running this elephant function each packet.
So it just needs to be moved into ip_route_output, right ?
-Andi
From: [email protected]
Date: Sat, 28 Sep 2002 06:28:29 +0400 (MSD)
> Otherwise I have no problems with the patch, Alexey?
I have... The implementation is bad. Source address must be retieved
from route, not running this elephant function each packet.
This only runs at connect time, and when NULL fl->fl6_src is seen
by ip6_build_xmit() (this means RAW,UDP,ICMP which must make these
decisions anyways).
Is there really so much computation to be saved by moving this
to ipv6 route?
Hello!
> This only runs at connect time
... and also at ip6_build_xmit(). Connected dgram sockets are marginal.
Alexey
From: [email protected]
Date: Sat, 28 Sep 2002 06:58:22 +0400 (MSD)
> This only runs at connect time
... and also at ip6_build_xmit(). Connected dgram sockets are marginal.
I said UDP/RAW. At least believe that I am this smart :-)
Point is that current function is not tiny either, so improvement you
suggest applies both to current code and code after Yoshi's change.
Hello!
> suggest applies both to current code and code after Yoshi's change.
This is wrong, unfortunately. The elimination of ipv6_get_saddr()
was trivial before this patch (because of independance of preferred source
on real destination, only on scope), the corresponding fix was withdrawn
from 2.4 only for sake of this feature, pending as a well-known patch.
Now I see retransmission of practicllay the same patch, which was deferred
for improvement that time.
Citing myself two years younger:
> The first priority task is to eliminate address selection function.
>
> Without this odd feature it was easy and, in fact, address selection
> patches forced me to withdraw the solution from kernel, because
> it makes these hacks much more difficult.
Alexey
From: [email protected]
Date: Sat, 28 Sep 2002 07:38:09 +0400 (MSD)
Now I see retransmission of practicllay the same patch, which was deferred
for improvement that time.
Ok, Yoshi please work Alexey to put source address selection into the
right place and remove ipv6_get_saddr().
Alexey, I still am not clear, this belongs in the output routing logic
right? You dance in circles talking about this patch, that patch,
but what I cannot decode this into an answer to question of where
source address selection belongs.
Hello!
> Alexey, I still am not clear, this belongs in the output routing logic
> right?
...
> where source address selection belongs.
Yes, it naturally belongs to the time when route is created.
This is just extending ipv6 routing entry with a field to hold
source address and, generally, making the same work as IPv4 does,
with all the advantages, particularily capability to select preferred
source address via routes set up by admin (RTA_PREFSRC attribute,
"src" in "ip route add").
Alexey
In article <[email protected]> (at Sat, 28 Sep 2002 08:19:29 +0400 (MSD)), [email protected] says:
> This is just extending ipv6 routing entry with a field to hold
> source address and, generally, making the same work as IPv4 does,
> with all the advantages, particularily capability to select preferred
> source address via routes set up by admin (RTA_PREFSRC attribute,
> "src" in "ip route add").
we need per socket preference.
can we do that with this?
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
Hello!
> we need per socket preference.
What kind of? Some matching rules loaded to socket by user?
Anyway, rules established by a particular client should be separate,
it is just a generalization of bind()/IP{V6}_PKTINFO.
I am not sure that it is really interesting though. Just now I cannot
imagine what user can invent which is not covered by system-wide rules,
bind() and IP{V6}_PKTINFO. Well, if you think more hairy scheme is interesting,
feel free to implement this.
Alexey
On Sat, 28 Sep 2002 [email protected] wrote:
> Hello!
>
> > Alexey, I still am not clear, this belongs in the output routing logic
> > right?
> ...
> > where source address selection belongs.
>
> Yes, it naturally belongs to the time when route is created.
>
> This is just extending ipv6 routing entry with a field to hold
> source address and, generally, making the same work as IPv4 does,
> with all the advantages, particularily capability to select preferred
> source address via routes set up by admin (RTA_PREFSRC attribute,
> "src" in "ip route add").
Umm.. you sure?
Isn't putting this logic to routes an oversimplification?
Consider e.g. a dummy host which only have a few address (link-local,
site-local, global; the last two /64's) and, basically, a default route
(plus of course an interface routes for those /64's).
When talking to other subnets within the site (ie. those not on the /64)
one would have difficulties parsing the source address from the default
route, as there would have to be at least two candidates there.
Am I missing something obvious here?
Alexey's approach should work in some simpler cases, but maybe not all
(stuff that's network prefix -independent like home addresses, privacy
addresses etc. would be different).
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hello!
> Isn't putting this logic to routes an oversimplification?
Hmmm... I believed this logic is more complicated yet. :-)
> route, as there would have to be at least two candidates there.
...
> Am I missing something obvious here?
Yes. You select some one of the candidates eventually, do not you? :-)
And when you have some special preference for a subnet you create
a route for it.
> (stuff that's network prefix -independent
I am sorry, I feel I do not understand what you mean.
Alexey
In article <[email protected]> (at Sat, 28 Sep 2002 08:44:29 +0400 (MSD)), [email protected] says:
> I am not sure that it is really interesting though. Just now I cannot
> imagine what user can invent which is not covered by system-wide rules,
> bind() and IP{V6}_PKTINFO. Well, if you think more hairy scheme is interesting,
> feel free to implement this.
we need per application (per socket) interface
for privacy extension (public address vs temporary address) and
mobile ip (home address vs care-of address).
--
yoshfuji
On Sat, 28 Sep 2002 [email protected] wrote:
> > route, as there would have to be at least two candidates there.
> ...
> > Am I missing something obvious here?
>
> Yes. You select some one of the candidates eventually, do not you? :-)
But can there be more candidates for one route, in which case one would
run something similar to this algorithm then?
Or would you have an already-sorted list of possible candidate addresses
for each route in the order of preference? And recalculate always when
address changes?
Or..?
> And when you have some special preference for a subnet you create
> a route for it.
This is IMO a wrong approach from user's perspective. Perhaps not if the
algorithm was run and e.g. additional, temporary "address selection"
routes were created by kernel.
> > (stuff that's network prefix -independent
>
> I am sorry, I feel I do not understand what you mean.
Hmm.. this depends on the interpretation of the concept above. If the
list is refreshed always when addresses change or change state, this could
perhaps work..
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hello!
> we need per application (per socket) interface
> for privacy extension (public address vs temporary address) and
> mobile ip (home address vs care-of address).
OK. It is natural user-friendly generalization of bind(). I do not see
problems.
Though, please, explain, to avoid misunderstanding. Let's take the second
case for simplicity. Is that true that it is supposed to add
to each application a switch "home or care-of"? This sound strange enough,
taking into account that only a few of applications have switch sort of -b
in openssh despite of age of plain bind() is equal to age of internet. :-)
Alexey
Hello!
> Or would you have an already-sorted list of possible candidate addresses
> for each route in the order of preference?
I am not mad yet. :-)
What preference? You must select _one_ address, you do not need lost
candidates.
> And recalculate always when address changes?
What address? Interface address? Routing tables used to be synchronized
to this.
> This is IMO a wrong approach from user's perspective. Perhaps not if the
> algorithm was run and e.g. additional, temporary "address selection"
> routes were created by kernel.
>
> > > (stuff that's network prefix -independent
> >
> > I am sorry, I feel I do not understand what you mean.
>
> Hmm.. this depends on the interpretation of the concept above. If the
> list is refreshed always when addresses change or change state, this could
> perhaps work..
I am afraid I do not understand what "address", "state", "temporary" routes
etc you mean. It remained in your brains. :-)
Pekka, are you not going to sleep? (I am.) I bet when you reread this tomorrow,
you will not blame that my brains eventually falled to "parse error" loop. :-)
Alexey
On Sat, 28 Sep 2002 [email protected] wrote:
> > Or would you have an already-sorted list of possible candidate addresses
> > for each route in the order of preference?
>
> I am not mad yet. :-)
>
> What preference? You must select _one_ address, you do not need lost
> candidates.
In the case the first entry goes away, having a list could help being able
to the next one to use very easily. But this probably just an
implementation detail.
> > And recalculate always when address changes?
>
> What address? Interface address? Routing tables used to be synchronized
> to this.
Any address.
One notable case is that the outgoing interface has only link/site-local
addresses and the destination is global. There are other cases too.
> > This is IMO a wrong approach from user's perspective. Perhaps not if the
> > algorithm was run and e.g. additional, temporary "address selection"
> > routes were created by kernel.
> >
> > > > (stuff that's network prefix -independent
> > >
> > > I am sorry, I feel I do not understand what you mean.
> >
> > Hmm.. this depends on the interpretation of the concept above. If the
> > list is refreshed always when addresses change or change state, this could
> > perhaps work..
>
> I am afraid I do not understand what "address", "state", "temporary" routes
> etc you mean. It remained in your brains. :-)
>
> Pekka, are you not going to sleep? (I am.) I bet when you reread this tomorrow,
> you will not blame that my brains eventually falled to "parse error" loop. :-)
I had already woken up :-).
At least BSD and I think Linux create ad-hoc, "cloned" routes e.g. in Path
MTU discovery process to hold some different values. I don't remember the
details. I was wondering if this would be done the same or not.
change state = move to deprecated, move to non-deprecated.
Hope this clarifies.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords