[PATCH] IPv6: (1/5) Fix bugs in ip6_tunnel.c ICMP error handler

[PATCH] IPv6: (1/5) Fix bugs in ip6_tunnel.c ICMP error handler

[Ville Nuorvala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 251 bytes --]

Hi,

this patch fixes two byte order bugs in ip6ip6_err(). Please apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1330 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1276.1.15 -> 1.1276.28.1
#	net/ipv6/ip6_tunnel.c	1.6     -> 1.7    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/01	vnuorval@dsl-hkigw1a8b.dial.inet.fi	1.1276.28.1
# Fix byte order of info parameter in ip6ip6_err()
# --------------------------------------------
#
diff -Nru a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
--- a/net/ipv6/ip6_tunnel.c	Mon Sep  1 02:02:59 2003
+++ b/net/ipv6/ip6_tunnel.c	Mon Sep  1 02:02:59 2003
@@ -421,7 +421,7 @@
 		}
 		teli = parse_tlv_tnl_enc_lim(skb, skb->data);
 
-		if (teli && teli == info - 2) {
+		if (teli && teli == ntohl(info) - 2) {
 			tel = (struct ipv6_tlv_tnl_enc_lim *) &skb->data[teli];
 			if (tel->encap_limit == 0) {
 				if (net_ratelimit())
@@ -434,10 +434,9 @@
 		}
 		break;
 	case ICMPV6_PKT_TOOBIG:
-		mtu = info - offset;
-		if (mtu <= IPV6_MIN_MTU) {
+		mtu = ntohl(info) - offset;
+		if (mtu < IPV6_MIN_MTU)
 			mtu = IPV6_MIN_MTU;
-		}
 		t->dev->mtu = mtu;
 
 		if ((len = sizeof (*ipv6h) + ipv6h->payload_len) > mtu) {

[PATCH] IPv6: (2/5) Use free_netdev() as destructor in ip6_tunnel.c

[Ville Nuorvala]

Hi,

this patch sets free_netdev() as the destructor for ip6_tnl dev. Please
apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH] IPv6: (2/5) Use free_netdev() as destructor in ip6_tunnel.c

[Ville Nuorvala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 245 bytes --]

Oops,
forgot to attach the patch in the original mail...

Sorry about that,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1055 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1276.28.1 -> 1.1276.28.2
#	net/ipv6/ip6_tunnel.c	1.7     -> 1.8    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/01	vnuorval@dsl-hkigw1a8b.dial.inet.fi	1.1276.28.2
# Use free_netdev as ip6_tunnel device destructor
# --------------------------------------------
#
diff -Nru a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
--- a/net/ipv6/ip6_tunnel.c	Mon Sep  1 01:57:37 2003
+++ b/net/ipv6/ip6_tunnel.c	Mon Sep  1 01:57:37 2003
@@ -1082,7 +1082,7 @@
 {
 	SET_MODULE_OWNER(dev);
 	dev->uninit = ip6ip6_tnl_dev_uninit;
-	dev->destructor = (void (*)(struct net_device *))kfree;
+	dev->destructor = free_netdev;
 	dev->hard_start_xmit = ip6ip6_tnl_xmit;
 	dev->get_stats = ip6ip6_tnl_get_stats;
 	dev->do_ioctl = ip6ip6_tnl_ioctl;

[PATCH] IPv6: (3/5) Set dev->dev_addr and dev->broadcast in ip6_tnls

[Ville Nuorvala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 426 bytes --]

Hi,

I just only recently noticed MAX_ADDR_LEN had beed increased to 32. This
means the IPv6 addresses can now be copied into the dev->dev_addr and
dev->broadcast fields, just like the IPv4 addresses are for the other
tunnel drivers. Please apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1520 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1276.28.2 -> 1.1276.28.3
#	net/ipv6/ip6_tunnel.c	1.8     -> 1.9    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/01	vnuorval@dsl-hkigw1a8b.dial.inet.fi	1.1276.28.3
# Copy tunnel addresses to dev->dev_addr and dev->broadcast like in the
# other tunnel drivers.
# --------------------------------------------
#
diff -Nru a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
--- a/net/ipv6/ip6_tunnel.c	Mon Sep  1 01:57:58 2003
+++ b/net/ipv6/ip6_tunnel.c	Mon Sep  1 01:57:58 2003
@@ -851,6 +851,10 @@
 	struct net_device *dev = t->dev;
 	struct ip6_tnl_parm *p = &t->parms;
 	struct flowi *fl;
+
+	memcpy(&dev->dev_addr, &p->laddr, sizeof(struct in6_addr));
+	memcpy(&dev->broadcast, &p->raddr, sizeof(struct in6_addr));
+
 	/* Set up flowi template */
 	fl = &t->fl;
 	ipv6_addr_copy(&fl->fl6_src, &p->laddr);
@@ -1093,10 +1097,7 @@
 	dev->mtu = ETH_DATA_LEN - sizeof (struct ipv6hdr);
 	dev->flags |= IFF_NOARP;
 	dev->iflink = 0;
-	/* Hmm... MAX_ADDR_LEN is 8, so the ipv6 addresses can't be
-	   copied to dev->dev_addr and dev->broadcast, like the ipv4
-	   addresses were in ipip.c, ip_gre.c and sit.c. */
-	dev->addr_len = 0;
+	dev->addr_len = sizeof(struct in6_addr);
 }
 
 

[PATCH] IPv6: (4/5) Remove sockets from ip6_tunnel.c

[Ville Nuorvala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 433 bytes --]

Hi,

this patch removes all sockets from ip6_tunnel.c. It also allows nested
IPv6 encapsulations through different devices in the IPv6 tunnel
entry-point node, since the old restrictions caused by the sockets don't
apply any more. Please apply the patch!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

[-- Attachment #2: Type: TEXT/PLAIN, Size: 15878 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1276.28.3 -> 1.1276.28.4
#	net/ipv6/ip6_tunnel.c	1.9     -> 1.10   
#	include/net/ip6_tunnel.h	1.1     -> 1.2    
#	net/ipv6/ipv6_syms.c	1.17    -> 1.18   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/01	vnuorval@dsl-hkigw1a8b.dial.inet.fi	1.1276.28.4
# Since the IPv6-in-IPv6 tunnels don't need sockets anymore, nested 
# IPv6 encapsulations through different tunnel devices on the same node
# are now possible.
# --------------------------------------------
#
diff -Nru a/include/net/ip6_tunnel.h b/include/net/ip6_tunnel.h
--- a/include/net/ip6_tunnel.h	Mon Sep  1 01:58:23 2003
+++ b/include/net/ip6_tunnel.h	Mon Sep  1 01:58:23 2003
@@ -25,6 +25,8 @@
 	int recursion;		/* depth of hard_start_xmit recursion */
 	struct ip6_tnl_parm parms;	/* tunnel configuration paramters */
 	struct flowi fl;	/* flowi template for xmit */
+	struct dst_entry *dst_cache;    /* cached dst */
+	u32 dst_cookie;
 };
 
 /* Tunnel encapsulation limit destination sub-option */
diff -Nru a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
--- a/net/ipv6/ip6_tunnel.c	Mon Sep  1 01:58:23 2003
+++ b/net/ipv6/ip6_tunnel.c	Mon Sep  1 01:58:23 2003
@@ -23,7 +23,6 @@
 #include <linux/module.h>
 #include <linux/errno.h>
 #include <linux/types.h>
-#include <linux/socket.h>
 #include <linux/sockios.h>
 #include <linux/if.h>
 #include <linux/in.h>
@@ -37,12 +36,12 @@
 #include <linux/init.h>
 #include <linux/route.h>
 #include <linux/rtnetlink.h>
+#include <linux/netfilter_ipv6.h>
 
 #include <asm/uaccess.h>
 #include <asm/atomic.h>
 
 #include <net/ip.h>
-#include <net/sock.h>
 #include <net/ipv6.h>
 #include <net/protocol.h>
 #include <net/ip6_route.h>
@@ -63,22 +62,6 @@
 
 #define IPV6_TCLASS_MASK (IPV6_FLOWINFO_MASK & ~IPV6_FLOWLABEL_MASK)
 
-/* socket(s) used by ip6ip6_tnl_xmit() for resending packets */
-static struct socket *__ip6_socket[NR_CPUS];
-#define ip6_socket __ip6_socket[smp_processor_id()]
-
-static void ip6_xmit_lock(void)
-{
-	local_bh_disable();
-	if (unlikely(!spin_trylock(&ip6_socket->sk->sk_lock.slock)))
-		BUG();
-}
-
-static void ip6_xmit_unlock(void)
-{
-	spin_unlock_bh(&ip6_socket->sk->sk_lock.slock);
-}
-
 #define HASH_SIZE  32
 
 #define HASH(addr) (((addr)->s6_addr32[0] ^ (addr)->s6_addr32[1] ^ \
@@ -101,6 +84,33 @@
 /* lock for the tunnel lists */
 static rwlock_t ip6ip6_lock = RW_LOCK_UNLOCKED;
 
+static inline struct dst_entry *ip6_tnl_dst_check(struct ip6_tnl *t)
+{
+	struct dst_entry *dst = t->dst_cache;
+
+	if (dst && dst->obsolete && 
+	    dst->ops->check(dst, t->dst_cookie) == NULL) {
+		t->dst_cache = NULL;
+		return NULL;
+	}
+
+	return dst;
+}
+
+static inline void ip6_tnl_dst_reset(struct ip6_tnl *t)
+{
+	dst_release(t->dst_cache);
+	t->dst_cache = NULL;
+}
+
+static inline void ip6_tnl_dst_store(struct ip6_tnl *t, struct dst_entry *dst)
+{
+	struct rt6_info *rt = (struct rt6_info *) dst;
+	t->dst_cookie = rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
+	dst_release(t->dst_cache);
+	t->dst_cache = dst;
+}
+
 /**
  * ip6ip6_tnl_lookup - fetch tunnel matching the end-point addresses
  *   @remote: the address of the tunnel exit-point 
@@ -294,13 +304,16 @@
 static void
 ip6ip6_tnl_dev_uninit(struct net_device *dev)
 {
+	struct ip6_tnl *t = dev->priv;
+
 	if (dev == ip6ip6_fb_tnl_dev) {
 		write_lock_bh(&ip6ip6_lock);
 		tnls_wc[0] = NULL;
 		write_unlock_bh(&ip6ip6_lock);
 	} else {
-		ip6ip6_tnl_unlink((struct ip6_tnl *) dev->priv);
+		ip6ip6_tnl_unlink(t);
 	}
+	ip6_tnl_dst_reset(t);
 	dev_put(dev);
 }
 
@@ -522,112 +535,34 @@
 	return 0;
 }
 
-/**
- * txopt_len - get necessary size for new &struct ipv6_txoptions
- *   @orig_opt: old options
- *
- * Return:
- *   Size of old one plus size of tunnel encapsulation limit option
- **/
-
-static inline int
-txopt_len(struct ipv6_txoptions *orig_opt)
-{
-	int len = sizeof (*orig_opt) + 8;
-
-	if (orig_opt && orig_opt->dst0opt)
-		len += ipv6_optlen(orig_opt->dst0opt);
-	return len;
-}
-
-/**
- * merge_options - add encapsulation limit to original options
- *   @encap_limit: number of allowed encapsulation limits
- *   @orig_opt: original options
- * 
- * Return:
- *   Pointer to new &struct ipv6_txoptions containing the tunnel
- *   encapsulation limit
- **/
-
-static struct ipv6_txoptions *
-merge_options(struct sock *sk, __u8 encap_limit,
-	      struct ipv6_txoptions *orig_opt)
+static inline struct ipv6_txoptions *create_tel(__u8 encap_limit)
 {
 	struct ipv6_tlv_tnl_enc_lim *tel;
 	struct ipv6_txoptions *opt;
 	__u8 *raw;
-	__u8 pad_to = 8;
-	int opt_len = txopt_len(orig_opt);
 
-	if (!(opt = sock_kmalloc(sk, opt_len, GFP_ATOMIC))) {
+	int opt_len = sizeof(*opt) + 8;
+
+	if (!(opt = kmalloc(opt_len, GFP_ATOMIC))) {
 		return NULL;
 	}
-
 	memset(opt, 0, opt_len);
 	opt->tot_len = opt_len;
 	opt->dst0opt = (struct ipv6_opt_hdr *) (opt + 1);
 	opt->opt_nflen = 8;
 
-	raw = (__u8 *) opt->dst0opt;
-
 	tel = (struct ipv6_tlv_tnl_enc_lim *) (opt->dst0opt + 1);
 	tel->type = IPV6_TLV_TNL_ENCAP_LIMIT;
 	tel->length = 1;
 	tel->encap_limit = encap_limit;
 
-	if (orig_opt) {
-		__u8 *orig_raw;
-
-		opt->hopopt = orig_opt->hopopt;
-
-		/* Keep the original destination options properly
-		   aligned and merge possible old paddings to the
-		   new padding option */
-		if ((orig_raw = (__u8 *) orig_opt->dst0opt) != NULL) {
-			__u8 type;
-			int i = sizeof (struct ipv6_opt_hdr);
-			pad_to += sizeof (struct ipv6_opt_hdr);
-			while (i < ipv6_optlen(orig_opt->dst0opt)) {
-				type = orig_raw[i++];
-				if (type == IPV6_TLV_PAD0)
-					pad_to++;
-				else if (type == IPV6_TLV_PADN) {
-					int len = orig_raw[i++];
-					i += len;
-					pad_to += len + 2;
-				} else {
-					break;
-				}
-			}
-			opt->dst0opt->hdrlen = orig_opt->dst0opt->hdrlen + 1;
-			memcpy(raw + pad_to, orig_raw + pad_to - 8,
-			       opt_len - sizeof (*opt) - pad_to);
-		}
-		opt->srcrt = orig_opt->srcrt;
-		opt->opt_nflen += orig_opt->opt_nflen;
-
-		opt->dst1opt = orig_opt->dst1opt;
-		opt->auth = orig_opt->auth;
-		opt->opt_flen = orig_opt->opt_flen;
-	}
+	raw = (__u8 *) opt->dst0opt;
 	raw[5] = IPV6_TLV_PADN;
-
-	/* subtract lengths of destination suboption header,
-	   tunnel encapsulation limit and pad N header */
-	raw[6] = pad_to - 7;
+	raw[6] = 1;
 
 	return opt;
 }
 
-static int 
-ip6ip6_getfrag(void *from, char *to, int offset, int len, int odd, 
-		struct sk_buff *skb)
-{
-	memcpy(to, (char *) from + offset, len);
-	return 0;
-}
-
 /**
  * ip6ip6_tnl_addr_conflict - compare packet addresses to tunnel's own
  *   @t: the outgoing tunnel device
@@ -655,7 +590,7 @@
  *
  * Description:
  *   Build new header and do some sanity checks on the packet before sending
- *   it to ip6_build_xmit().
+ *   it.
  *
  * Return: 
  *   0
@@ -666,18 +601,17 @@
 	struct ip6_tnl *t = (struct ip6_tnl *) dev->priv;
 	struct net_device_stats *stats = &t->stat;
 	struct ipv6hdr *ipv6h = skb->nh.ipv6h;
-	struct ipv6_txoptions *orig_opt = NULL;
 	struct ipv6_txoptions *opt = NULL;
 	int encap_limit = -1;
 	__u16 offset;
 	struct flowi fl;
-	struct ip6_flowlabel *fl_lbl = NULL;
-	int err = 0;
 	struct dst_entry *dst;
-	int link_failure = 0;
-	struct sock *sk = ip6_socket->sk;
-	struct ipv6_pinfo *np = inet6_sk(sk);
+	struct net_device *tdev;
 	int mtu;
+	int max_headroom = sizeof(struct ipv6hdr);
+	u8 proto;
+	int err;
+	int pkt_len;
 
 	if (t->recursion++) {
 		stats->collisions++;
@@ -700,58 +634,39 @@
 	} else if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT)) {
 		encap_limit = t->parms.encap_limit;
 	}
-	ip6_xmit_lock();
-
 	memcpy(&fl, &t->fl, sizeof (fl));
+	proto = fl.proto;
 
 	if ((t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS))
 		fl.fl6_flowlabel |= (*(__u32 *) ipv6h & IPV6_TCLASS_MASK);
 	if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FLOWLABEL))
 		fl.fl6_flowlabel |= (*(__u32 *) ipv6h & IPV6_FLOWLABEL_MASK);
 
-	if (fl.fl6_flowlabel) {
-		fl_lbl = fl6_sock_lookup(sk, fl.fl6_flowlabel);
-		if (fl_lbl)
-			orig_opt = fl_lbl->opt;
-	}
-	if (encap_limit >= 0) {
-		if (!(opt = merge_options(sk, encap_limit, orig_opt))) {
-			goto tx_err_free_fl_lbl;
-		}
-	} else {
-		opt = orig_opt;
-	}
-	dst = __sk_dst_check(sk, np->dst_cookie);
+	if (encap_limit >= 0 && (opt = create_tel(encap_limit)) == NULL)
+		goto tx_err;
 
-	if (dst) {
-		if (np->daddr_cache == NULL ||
-		    ipv6_addr_cmp(&fl.fl6_dst, np->daddr_cache) ||
-		    (fl.oif && fl.oif != dst->dev->ifindex)) {
-			dst = NULL;
-		}
-	}
-	if (dst == NULL) {
-		dst = ip6_route_output(sk, &fl);
-		if (dst->error) {
-			stats->tx_carrier_errors++;
-			link_failure = 1;
-			goto tx_err_dst_release;
-		}
-		/* local routing loop */
-		if (dst->dev == dev) {
-			stats->collisions++;
-			if (net_ratelimit())
-				printk(KERN_WARNING 
-				       "%s: Local routing loop detected!\n",
-				       t->parms.name);
-			goto tx_err_dst_release;
-		}
-		ipv6_addr_copy(&np->daddr, &fl.fl6_dst);
-		ipv6_addr_copy(&np->saddr, &fl.fl6_src);
+	if ((dst = ip6_tnl_dst_check(t)) != NULL)
+		dst_hold(dst);
+	else
+		dst = ip6_route_output(NULL, &fl);
+
+	if (dst->error || xfrm_lookup(&dst, &fl, NULL, 0) < 0)
+		goto tx_err_link_failure;
+
+	tdev = dst->dev;
+
+	if (tdev == dev) {
+		stats->collisions++;
+		if (net_ratelimit())
+			printk(KERN_WARNING 
+			       "%s: Local routing loop detected!\n",
+			       t->parms.name);
+		goto tx_err_dst_release;
 	}
 	mtu = dst_pmtu(dst) - sizeof (*ipv6h);
 	if (opt) {
-		mtu -= (opt->opt_nflen + opt->opt_flen);
+		max_headroom += 8;
+		mtu -= 8;
 	}
 	if (mtu < IPV6_MIN_MTU)
 		mtu = IPV6_MIN_MTU;
@@ -764,41 +679,71 @@
 		icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, dev);
 		goto tx_err_dst_release;
 	}
-	err = ip6_append_data(sk, ip6ip6_getfrag, skb->nh.raw, skb->len, 0,
-			      t->parms.hop_limit, opt, &fl, 
-			      (struct rt6_info *)dst, MSG_DONTWAIT);
+	skb->h.raw = skb->nh.raw;
 
-	if (err) {
-		ip6_flush_pending_frames(sk);
-	} else {
-		err = ip6_push_pending_frames(sk);
-		err = (err < 0 ? err : 0);
+	/*
+	 * Okay, now see if we can stuff it in the buffer as-is.
+	 */
+	max_headroom += LL_RESERVED_SPACE(tdev);
+	
+	if (skb_headroom(skb) < max_headroom || 
+	    skb_cloned(skb) || skb_shared(skb)) {
+		struct sk_buff *new_skb;
+		
+		if (!(new_skb = skb_realloc_headroom(skb, max_headroom)))
+			goto tx_err_dst_release;
+
+		if (skb->sk)
+			skb_set_owner_w(new_skb, skb->sk);
+		kfree_skb(skb);
+		skb = new_skb;
 	}
-	if (!err) {
-		stats->tx_bytes += skb->len;
+	dst_release(skb->dst);
+	skb->dst = dst_clone(dst);
+
+	if (opt)
+		ipv6_push_nfrag_opts(skb, opt, &proto, NULL);
+
+	skb->nh.raw = skb_push(skb, sizeof(struct ipv6hdr));
+	ipv6h = skb->nh.ipv6h;
+	*(u32*)ipv6h = fl.fl6_flowlabel | htonl(0x60000000);
+	ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr));
+	ipv6h->hop_limit = t->parms.hop_limit;
+	ipv6h->nexthdr = proto;
+	ipv6_addr_copy(&ipv6h->saddr, &fl.fl6_src);
+	ipv6_addr_copy(&ipv6h->daddr, &fl.fl6_dst);
+#ifdef CONFIG_NETFILTER
+	nf_conntrack_put(skb->nfct);
+	skb->nfct = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+	skb->nf_debug = 0;
+#endif
+#endif
+	pkt_len = skb->len;
+	err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, 
+		      skb->dst->dev, dst_output);
+
+	if (err == NET_XMIT_SUCCESS || err == NET_XMIT_CN) {
+		stats->tx_bytes += pkt_len;
 		stats->tx_packets++;
 	} else {
 		stats->tx_errors++;
 		stats->tx_aborted_errors++;
 	}
-	if (opt && opt != orig_opt)
-		sock_kfree_s(sk, opt, opt->tot_len);
+	ip6_tnl_dst_store(t, dst);
+
+	if (opt)
+		kfree(opt);
 
-	fl6_sock_release(fl_lbl);
-	ip6_dst_store(sk, dst, &np->daddr);
-	ip6_xmit_unlock();
-	kfree_skb(skb);
 	t->recursion--;
 	return 0;
+tx_err_link_failure:
+	stats->tx_carrier_errors++;
+	dst_link_failure(skb);
 tx_err_dst_release:
 	dst_release(dst);
-	if (opt && opt != orig_opt)
-		sock_kfree_s(sk, opt, opt->tot_len);
-tx_err_free_fl_lbl:
-	fl6_sock_release(fl_lbl);
-	ip6_xmit_unlock();
-	if (link_failure)
-		dst_link_failure(skb);
+	if (opt)
+		kfree(opt);
 tx_err:
 	stats->tx_errors++;
 	stats->tx_dropped++;
@@ -850,13 +795,12 @@
 {
 	struct net_device *dev = t->dev;
 	struct ip6_tnl_parm *p = &t->parms;
-	struct flowi *fl;
+	struct flowi *fl = &t->fl;
 
 	memcpy(&dev->dev_addr, &p->laddr, sizeof(struct in6_addr));
 	memcpy(&dev->broadcast, &p->raddr, sizeof(struct in6_addr));
 
 	/* Set up flowi template */
-	fl = &t->fl;
 	ipv6_addr_copy(&fl->fl6_src, &p->laddr);
 	ipv6_addr_copy(&fl->fl6_dst, &p->raddr);
 	fl->oif = p->link;
@@ -881,10 +825,7 @@
 		if (rt == NULL)
 			return;
 
-		/* as long as tunnels use the same socket for transmission,
-		   locally nested tunnels won't work */
-		
-		if (rt->rt6i_dev && rt->rt6i_dev->type != ARPHRD_TUNNEL6) {
+		if (rt->rt6i_dev) {
 			dev->iflink = rt->rt6i_dev->ifindex;
 
 			dev->hard_header_len = rt->rt6i_dev->hard_header_len +
@@ -1139,7 +1080,7 @@
 int ip6ip6_fb_tnl_dev_init(struct net_device *dev)
 {
 	struct ip6_tnl *t = dev->priv;
-	ip6ip6_tnl_dev_init_gen(dev); 
+	ip6ip6_tnl_dev_init_gen(dev);
 	dev_hold(dev);
 	tnls_wc[0] = t;
 	return 0;
@@ -1159,61 +1100,28 @@
 
 int __init ip6_tunnel_init(void)
 {
-	int i, j, err;
-	struct sock *sk;
-	struct ipv6_pinfo *np;
-
-	for (i = 0; i < NR_CPUS; i++) {
-		if (!cpu_possible(i))
-			continue;
-
-		err = sock_create(PF_INET6, SOCK_RAW, IPPROTO_IPV6, 
-				  &__ip6_socket[i]);
-		if (err < 0) {
-			printk(KERN_ERR 
-			       "Failed to create the IPv6 tunnel socket "
-			       "(err %d).\n", 
-			       err);
-			goto fail;
-		}
-		sk = __ip6_socket[i]->sk;
-		sk->sk_allocation = GFP_ATOMIC;
-
-		np = inet6_sk(sk);
-		np->hop_limit = 255;
-		np->mc_loop = 0;
+	int  err;
 
-		sk->sk_prot->unhash(sk);
-	}
 	if ((err = inet6_add_protocol(&ip6ip6_protocol, IPPROTO_IPV6)) < 0) {
 		printk(KERN_ERR "Failed to register IPv6 protocol\n");
-		goto fail;
+		return err;
 	}
-
-	
 	ip6ip6_fb_tnl_dev = alloc_netdev(sizeof(struct ip6_tnl), "ip6tnl0",
 					 ip6ip6_tnl_dev_setup);
 
 	if (!ip6ip6_fb_tnl_dev) {
 		err = -ENOMEM;
-		goto tnl_fail;
+		goto fail;
 	}
 	ip6ip6_fb_tnl_dev->init = ip6ip6_fb_tnl_dev_init;
 
 	if ((err = register_netdev(ip6ip6_fb_tnl_dev))) {
 		kfree(ip6ip6_fb_tnl_dev);
-		goto tnl_fail;
+		goto fail;
 	}
 	return 0;
-tnl_fail:
-	inet6_del_protocol(&ip6ip6_protocol, IPPROTO_IPV6);
 fail:
-	for (j = 0; j < i; j++) {
-		if (!cpu_possible(j))
-			continue;
-		sock_release(__ip6_socket[j]);
-		__ip6_socket[j] = NULL;
-	}
+	inet6_del_protocol(&ip6ip6_protocol, IPPROTO_IPV6);
 	return err;
 }
 
@@ -1223,18 +1131,8 @@
 
 void ip6_tunnel_cleanup(void)
 {
-	int i;
-
 	unregister_netdev(ip6ip6_fb_tnl_dev);
-
 	inet6_del_protocol(&ip6ip6_protocol, IPPROTO_IPV6);
-
-	for (i = 0; i < NR_CPUS; i++) {
-		if (!cpu_possible(i))
-			continue;
-		sock_release(__ip6_socket[i]);
-		__ip6_socket[i] = NULL;
-	}
 }
 
 #ifdef MODULE
diff -Nru a/net/ipv6/ipv6_syms.c b/net/ipv6/ipv6_syms.c
--- a/net/ipv6/ipv6_syms.c	Mon Sep  1 01:58:23 2003
+++ b/net/ipv6/ipv6_syms.c	Mon Sep  1 01:58:23 2003
@@ -45,3 +45,4 @@
 EXPORT_SYMBOL(ip6_append_data);
 EXPORT_SYMBOL(ip6_flush_pending_frames);
 EXPORT_SYMBOL(ip6_push_pending_frames);
+EXPORT_SYMBOL(ipv6_push_nfrag_opts);

[PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address

[Ville Nuorvala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 599 bytes --]

Hi,

unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
link formed by IPv6 tunnels, the net_devices representing the tunnels
don't necessarily need to have an IPv6 address configured specifically to
them.

The inet6_dev structure of the device must however be configured for
neighbor discovery to work properly, even for IFF_NOARP devices like
ip6_tnls. This patch fixes that issue. Please apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1559 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1276.28.4 -> 1.1276.28.5
#	 net/ipv6/addrconf.c	1.63    -> 1.64   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/01	vnuorval@dsl-hkigw1a8b.dial.inet.fi	1.1276.28.5
# Allow an IPv6-IPv6 tunnel device to send packets without configuring
# a separate IPv6 address to it.
# --------------------------------------------
#
diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
--- a/net/ipv6/addrconf.c	Mon Sep  1 01:58:45 2003
+++ b/net/ipv6/addrconf.c	Mon Sep  1 01:58:45 2003
@@ -1819,6 +1819,20 @@
 }
 
 
+#if defined(CONFIG_IPV6_TUNNEL) || defined(CONFIG_IPV6_TUNNEL_MODULE)
+static void addrconf_ip6_tnl_config(struct net_device *dev)
+{
+	struct inet6_dev *idev;
+
+	ASSERT_RTNL();
+
+	if ((idev = ipv6_find_idev(dev)) == NULL) {
+		printk(KERN_DEBUG "init ip6-ip6: find_dev failed\n");
+		return;
+	}
+}
+#endif
+
 int addrconf_notify(struct notifier_block *this, unsigned long event, 
 		    void * data)
 {
@@ -1831,7 +1845,11 @@
 		case ARPHRD_SIT:
 			addrconf_sit_config(dev);
 			break;
-
+#if defined(CONFIG_IPV6_TUNNEL) || defined(CONFIG_IPV6_TUNNEL_MODULE)
+		case ARPHRD_TUNNEL6:
+			addrconf_ip6_tnl_config(dev);
+			break;
+#endif
 		case ARPHRD_LOOPBACK:
 			init_loopback(dev);
 			break;

Re: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0309010257390.26242-200000@rhea.tcs.hut.fi> (at Mon, 1 Sep 2003 03:11:58 +0300 (EEST)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:

> unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
> link formed by IPv6 tunnels, the net_devices representing the tunnels
> don't necessarily need to have an IPv6 address configured specifically to
> them.

Wrong. All interfaces have a link-local address. (RFC2462)

--yoshfuji

Re: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address

[Ville Nuorvala]

On Mon, 1 Sep 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:

> In article <Pine.LNX.4.44.0309010257390.26242-200000@rhea.tcs.hut.fi> (at Mon, 1 Sep 2003 03:11:58 +0300 (EEST)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:
>
> > unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
> > link formed by IPv6 tunnels, the net_devices representing the tunnels
> > don't necessarily need to have an IPv6 address configured specifically to
> > them.
>
> Wrong. All interfaces have a link-local address. (RFC2462)

Unfortunately the IPv6 tunneling spec (RFC2473) is broken on this point :(
I should probably raise this issue on the IETF ipv6 WG mailing list.

The first problem is, that the way to generate the interface-identifier
isn't currently specified in the tunnel spec.

The IPv6 over PPP spec (RFC2472) section 4.1 has some ideas:

1) if available, reuse any IEEE EUI-48 or EUI-64 identifiers on the node
2) use link-layer addresses, machine serial numbers, et cetera
3) if none of these can be found, use random bits

The second problem is, that this method alone doesn't yet guarantee
unique identifiers to the two tunnel endpoints.

In RFC2472 the IPv6 Control Protocol negotiates the identifiers between
the two peers beforehand, but unfortunately we don't have a similar
protocol in RFC2473.

Like the other tunnels (ipip, ip_gre, sit) ip6_tunnel is fundamentally a
IFF_NOARP device so you can't even use DAD to detect a duplicate address
on the virtual link. (Besides, the link doesn't even exist before both
devices have been brought up on the two separate nodes.)

This is something for the ipv6 WG to think about, I guess.

In the mean time, do we accept the in theory 1/2^64 (in practice of course
bigger) chance of duplicate addresses occurring on the link?

If yes, then I could (probably still later today) send a patch where the
interface-identifiers for the IPv6 tunnels are generated like in the IPv6
over PPP case above.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH] IPv6: (1/5) Fix bugs in ip6_tunnel.c ICMP error handler

[David S. Miller]

On Mon, 1 Sep 2003 02:34:55 +0300 (EEST)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> this patch fixes two byte order bugs in ip6ip6_err(). Please apply!

Applied, thanks Ville.

Re: [PATCH] IPv6: (2/5) Use free_netdev() as destructor in ip6_tunnel.c

[David S. Miller]

On Mon, 1 Sep 2003 02:46:45 +0300 (EEST)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> Oops,
> forgot to attach the patch in the original mail...
> 
> Sorry about that,

That's ok :-)

Applied, thanks Ville.

Re: [PATCH] IPv6: (3/5) Set dev->dev_addr and dev->broadcast in ip6_tnls

[David S. Miller]

On Mon, 1 Sep 2003 02:48:55 +0300 (EEST)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> I just only recently noticed MAX_ADDR_LEN had beed increased to 32. This
> means the IPv6 addresses can now be copied into the dev->dev_addr and
> dev->broadcast fields, just like the IPv4 addresses are for the other
> tunnel drivers. Please apply!

Applied, thanks Ville.

Re: [PATCH] IPv6: (4/5) Remove sockets from ip6_tunnel.c

[David S. Miller]

On Mon, 1 Sep 2003 02:57:03 +0300 (EEST)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> this patch removes all sockets from ip6_tunnel.c. It also allows nested
> IPv6 encapsulations through different devices in the IPv6 tunnel
> entry-point node, since the old restrictions caused by the sockets don't
> apply any more. Please apply the patch!

Thank you very much for finishing this work.

Applied, thanks.

Re: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address

[David S. Miller]

On Mon, 01 Sep 2003 11:24:09 +0900 (JST)
YOSHIFUJI Hideaki / _$B5HF#1QL@ <yoshfuji@linux-ipv6.org> wrote:

> In article <Pine.LNX.4.44.0309010257390.26242-200000@rhea.tcs.hut.fi> (at Mon, 1 Sep 2003 03:11:58 +0300 (EEST)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:
> 
> > unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
> > link formed by IPv6 tunnels, the net_devices representing the tunnels
> > don't necessarily need to have an IPv6 address configured specifically to
> > them.
> 
> Wrong. All interfaces have a link-local address. (RFC2462)

Are you sure there isn't an exception in the ip6ip6 tunnel
RFC?

Re: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address

[David S. Miller]

On Mon, 1 Sep 2003 11:18:30 +0300 (EEST)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> Unfortunately the IPv6 tunneling spec (RFC2473) is broken on this point :(
> I should probably raise this issue on the IETF ipv6 WG mailing list.
 ...
> The first problem is, that the way to generate the interface-identifier
> isn't currently specified in the tunnel spec.
 ...
> The second problem is, that this method alone doesn't yet guarantee
> unique identifiers to the two tunnel endpoints.

This is exactly what I was thinking.  I really don't think link-
local addresses make any sense on a software device such as the
ipip6 tunnels.

Re: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address

[Pekka Savola]

On Mon, 1 Sep 2003, David S. Miller wrote:
> On Mon, 1 Sep 2003 11:18:30 +0300 (EEST)
> Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> 
> > Unfortunately the IPv6 tunneling spec (RFC2473) is broken on this point :(
> > I should probably raise this issue on the IETF ipv6 WG mailing list.
>  ...
> > The first problem is, that the way to generate the interface-identifier
> > isn't currently specified in the tunnel spec.
>  ...
> > The second problem is, that this method alone doesn't yet guarantee
> > unique identifiers to the two tunnel endpoints.
> 
> This is exactly what I was thinking.  I really don't think link-
> local addresses make any sense on a software device such as the
> ipip6 tunnels.

Well, link-local addresses are used e.g. by routing protocols and such, so 
having one is probably rather important..

FWIW, on FreeBSD platform they take the link-local address of the first
physical interface, and give the exact same link-local address on all of
the tunnels, disambiuating them with the scope identifier.  Seems like an
OK appaorach too, and guarantees (to the degree of unique MAC addresses)  
that the addresses of the endpoints do not clash.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address

[David S. Miller]

On Mon, 1 Sep 2003 13:48:44 +0300 (EEST)
Pekka Savola <pekkas@netcore.fi> wrote:

> Well, link-local addresses are used e.g. by routing protocols and such, so 
> having one is probably rather important..

Ok.

> FWIW, on FreeBSD platform they take the link-local address of the first
> physical interface, and give the exact same link-local address on all of
> the tunnels, disambiuating them with the scope identifier.  Seems like an
> OK appaorach too, and guarantees (to the degree of unique MAC addresses)  
> that the addresses of the endpoints do not clash.

Interesting approach...  I'm not particularly picky about how this
uniqueness issue is solved.

[PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Ville Nuorvala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1132 bytes --]

On Mon, 1 Sep 2003, David S. Miller wrote:

> On Mon, 1 Sep 2003 13:48:44 +0300 (EEST)
> Pekka Savola <pekkas@netcore.fi> wrote:
>
> > Well, link-local addresses are used e.g. by routing protocols and such, so
> > having one is probably rather important..
>
> Ok.
>
> > FWIW, on FreeBSD platform they take the link-local address of the first
> > physical interface, and give the exact same link-local address on all of
> > the tunnels, disambiuating them with the scope identifier.  Seems like an
> > OK appaorach too, and guarantees (to the degree of unique MAC addresses)
> > that the addresses of the endpoints do not clash.
>
> Interesting approach...  I'm not particularly picky about how this
> uniqueness issue is solved.

Ok, this incremental patch to my previous addrconf.c patch generates a
link-local address to the IPv6 tunnel device. It first tries to inherit
the EUI64 identifier of some other device and if this fails, uses a
random interface id.

Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2242 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1291  -> 1.1292 
#	 net/ipv6/addrconf.c	1.64    -> 1.65   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/09/01	vnuorval@amber.hut.mediapoli.com	1.1292
# Autoconfigure a link-local address to all IPv6 tunnel devices
# --------------------------------------------
#
diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
--- a/net/ipv6/addrconf.c	Mon Sep  1 16:56:39 2003
+++ b/net/ipv6/addrconf.c	Mon Sep  1 16:56:39 2003
@@ -1820,6 +1820,39 @@
 
 
 #if defined(CONFIG_IPV6_TUNNEL) || defined(CONFIG_IPV6_TUNNEL_MODULE)
+
+/* 
+ * Autoconfigure tunnel with a link-local address so routing protocols,
+ * DHCPv6, MLD etc. can be run over the virtual link 
+ */
+
+static void ip6_tnl_add_linklocal(struct inet6_dev *idev)
+{
+	struct in6_addr addr;
+	struct net_device *dev; 
+	ASSERT_RTNL();
+
+	memset(&addr, 0, sizeof(struct in6_addr));
+	addr.s6_addr32[0] = htonl(0xFE800000);
+
+	/* try to inherit EUI64 from another device */
+	for (dev = dev_base; dev; dev = dev->next) {
+		if (!ipv6_generate_eui64(addr.s6_addr + 8, dev)) {
+			addrconf_add_linklocal(idev, &addr);
+			return;
+		}
+	}
+#ifdef CONFIG_IPV6_PRIVACY
+	/* else try to generate a random identifier */
+	if (!__ipv6_regen_rndid(idev)) {
+		memcpy(addr.s6_addr + 8, idev->rndid, 8);
+		addrconf_add_linklocal(idev, &addr);
+		return;
+	}
+#endif
+	printk(KERN_DEBUG "init ip6-ip6: add_linklocal failed\n");
+}
+
 static void addrconf_ip6_tnl_config(struct net_device *dev)
 {
 	struct inet6_dev *idev;
@@ -1830,6 +1863,8 @@
 		printk(KERN_DEBUG "init ip6-ip6: find_dev failed\n");
 		return;
 	}
+	ip6_tnl_add_linklocal(idev);
+	addrconf_add_mroute(dev);
 }
 #endif
 
@@ -2135,6 +2170,7 @@
 
 	if (ifp->idev->cnf.forwarding == 0 &&
 	    (dev->flags&IFF_LOOPBACK) == 0 &&
+	    dev->type != ARPHRD_TUNNEL6 &&
 	    (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
 		struct in6_addr all_routers;
 

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[David S. Miller]

On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> Ok, this incremental patch to my previous addrconf.c patch generates a
> link-local address to the IPv6 tunnel device. It first tries to inherit
> the EUI64 identifier of some other device and if this fails, uses a
> random interface id.

Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Pekka Savola]

On Mon, 1 Sep 2003, Ville Nuorvala wrote:
> On Mon, 1 Sep 2003, David S. Miller wrote:
> > On Mon, 1 Sep 2003 13:48:44 +0300 (EEST)
> > Pekka Savola <pekkas@netcore.fi> wrote:
> >
> > > Well, link-local addresses are used e.g. by routing protocols and such, so
> > > having one is probably rather important..
> >
> > Ok.
> >
> > > FWIW, on FreeBSD platform they take the link-local address of the first
> > > physical interface, and give the exact same link-local address on all of
> > > the tunnels, disambiuating them with the scope identifier.  Seems like an
> > > OK appaorach too, and guarantees (to the degree of unique MAC addresses)
> > > that the addresses of the endpoints do not clash.
> >
> > Interesting approach...  I'm not particularly picky about how this
> > uniqueness issue is solved.
> 
> Ok, this incremental patch to my previous addrconf.c patch generates a
> link-local address to the IPv6 tunnel device. It first tries to inherit
> the EUI64 identifier of some other device and if this fails, uses a
> random interface id.

Two comments:

+       /* try to inherit EUI64 from another device */
+       for (dev = dev_base; dev; dev = dev->next) {
+               if (!ipv6_generate_eui64(addr.s6_addr + 8, dev)) {
+                       addrconf_add_linklocal(idev, &addr);
+                       return;
+

==> does this really inherit _EUI64_, *or* MAC address (or something like
it) to derive an EUI64?  Note that there is a significant difference when
you've configured manually e.g. 3ffe:ffff:f00:ba::1 on a device, and the
case when you've auto-configured the interface identifier from the MAC
address of the device.

The latter is probably always unique.  The former is not necessarily
sufficiently unique (but better than nothing, of course).

+#ifdef CONFIG_IPV6_PRIVACY
+       /* else try to generate a random identifier */
+       if (!__ipv6_regen_rndid(idev)) {
+               memcpy(addr.s6_addr + 8, idev->rndid, 8);
+               addrconf_add_linklocal(idev, &addr);
+               return;
+

==> my question is: as the former method to steal an EUI64 should succeed
pretty much always, is it useful to add basically dead code which never
gets executed here?  I certainly can't think of any scenario where you'd
have no interface to steal the MAC address/EUI64 from and you'd have to
fall back to random identifiers?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Ville Nuorvala]

On Tue, 2 Sep 2003, Pekka Savola wrote:

> Two comments:
>
> +       /* try to inherit EUI64 from another device */
> +       for (dev = dev_base; dev; dev = dev->next) {
> +               if (!ipv6_generate_eui64(addr.s6_addr + 8, dev)) {
> +                       addrconf_add_linklocal(idev, &addr);
> +                       return;
> +
>
> ==> does this really inherit _EUI64_, *or* MAC address (or something like
> it) to derive an EUI64?  Note that there is a significant difference when
> you've configured manually e.g. 3ffe:ffff:f00:ba::1 on a device, and the
> case when you've auto-configured the interface identifier from the MAC
> address of the device.

ipv6_generate_eui64() derives the interface identifier from the MAC
address on ARPHRD_{ETHER,FDDI,IEEE802_TR,ARCNET} interfaces, but doesn't
do anything for other types of devices

> ==> my question is: as the former method to steal an EUI64 should succeed
> pretty much always, is it useful to add basically dead code which never
> gets executed here?  I certainly can't think of any scenario where you'd
> have no interface to steal the MAC address/EUI64 from and you'd have to
> fall back to random identifiers?

If the node doesn't have an Ethernet (etc.) NIC it won't get a valid
identifier from ipv6_generate_eui64() and has to resort to something
else, for example generating a random address.

An alternative would be to use ipv6_inherit_eui64(), which just copies the
64-bit suffix from the first link-local address it can find. This includes
both manually and auto-configured addresses, which means the risk of
duplicate addresses might be (I assume) greater than in the random address
case.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20030902043534.05fc6586.davem@redhat.com> (at Tue, 2 Sep 2003 04:35:34 -0700), "David S. Miller" <davem@redhat.com> says:

> On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
> Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> 
> > Ok, this incremental patch to my previous addrconf.c patch generates a
> > link-local address to the IPv6 tunnel device. It first tries to inherit
> > the EUI64 identifier of some other device and if this fails, uses a
> > random interface id.
> 
> Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?

Well, I have a question and a comment.

        if (ifp->idev->cnf.forwarding == 0 &&
            (dev->flags&IFF_LOOPBACK) == 0 &&
+           dev->type != ARPHRD_TUNNEL6 &&
            (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
                struct in6_addr all_routers;

Why?

Comment: this strategy is the "default."  
We can (or even should) do this stretegy whenever we failed to 
ipv6_generate_eui64() in addrconf_dev_config().

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Pekka Savola]

On Tue, 2 Sep 2003, Ville Nuorvala wrote:
> On Tue, 2 Sep 2003, Pekka Savola wrote:
> 
> > Two comments:
> >
> > +       /* try to inherit EUI64 from another device */
> > +       for (dev = dev_base; dev; dev = dev->next) {
> > +               if (!ipv6_generate_eui64(addr.s6_addr + 8, dev)) {
> > +                       addrconf_add_linklocal(idev, &addr);
> > +                       return;
> > +
> >
> > ==> does this really inherit _EUI64_, *or* MAC address (or something like
> > it) to derive an EUI64?  Note that there is a significant difference when
> > you've configured manually e.g. 3ffe:ffff:f00:ba::1 on a device, and the
> > case when you've auto-configured the interface identifier from the MAC
> > address of the device.
> 
> ipv6_generate_eui64() derives the interface identifier from the MAC
> address on ARPHRD_{ETHER,FDDI,IEEE802_TR,ARCNET} interfaces, but doesn't
> do anything for other types of devices

Ok, but then the command should be:

/* try to inherit MAC address from another device, to build an EUI64 */

> > ==> my question is: as the former method to steal an EUI64 should succeed
> > pretty much always, is it useful to add basically dead code which never
> > gets executed here?  I certainly can't think of any scenario where you'd
> > have no interface to steal the MAC address/EUI64 from and you'd have to
> > fall back to random identifiers?
> 
> If the node doesn't have an Ethernet (etc.) NIC it won't get a valid
> identifier from ipv6_generate_eui64() and has to resort to something
> else, for example generating a random address.

And exactly how often does this happen? Eth (all variants), FDDI, TR, 
ARCnet.. what's missing?  Does IPv6 even work with any other physical 
interfaces? :-)
 
> An alternative would be to use ipv6_inherit_eui64(), which just copies the
> 64-bit suffix from the first link-local address it can find. This includes
> both manually and auto-configured addresses, which means the risk of
> duplicate addresses might be (I assume) greater than in the random address
> case.

A possible twist here could be to copy only those whose universal/local 
bits indicate that that address was NOT manually configured, i.e..:

2001:708:10:40:207:e9ff:fe7b:259
               ^
            this one

.. but as stated, I'm not sure this is really necessary anyway either.

Note: it is desirable to have link-local addresses reasonably stable.  
Randomizing them may not be the right choice.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Ville Nuorvala]

On Wed, 3 Sep 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:

> In article <20030902043534.05fc6586.davem@redhat.com> (at Tue, 2 Sep 2003 04:35:34 -0700), "David S. Miller" <davem@redhat.com> says:
>
> > On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
> > Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> >
> > > Ok, this incremental patch to my previous addrconf.c patch generates a
> > > link-local address to the IPv6 tunnel device. It first tries to inherit
> > > the EUI64 identifier of some other device and if this fails, uses a
> > > random interface id.
> >
> > Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?
>
> Well, I have a question and a comment.
>
>         if (ifp->idev->cnf.forwarding == 0 &&
>             (dev->flags&IFF_LOOPBACK) == 0 &&
> +           dev->type != ARPHRD_TUNNEL6 &&
>             (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
>                 struct in6_addr all_routers;
>
> Why?

The other end of the tunnel might not yet be set up to receive the packet,
which causes an ICMP error message to be sent back to the sender.

Besides, RS and RA over a ipv6-in-ipv6 tunnel is a _bad_ idea. A default
route through a tunnel without more advanced (policy/flow/srcaddr/? based)
routing schemes can lead to local routing loops.

Come to think of it a more elegant solution might be:

        if (ifp->idev->cnf.forwarding == 0 &&
            (dev->flags&IFF_LOOPBACK) == 0 &&
+           ifp->idev->cnf.rtr_solicits > 0 &&
            (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
                struct in6_addr all_routers;

and set both idev->cnf.rtr_solicits = 0 and idev->cnf.accept_ra = 0 for
ARPHRD_TUNNEL6 devices

> Comment: this strategy is the "default."
> We can (or even should) do this stretegy whenever we failed to
> ipv6_generate_eui64() in addrconf_dev_config().

Should I send a separate patch to enable the random interface ids in
addrconf_dev_config()?

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0309031232010.5039-100000@rhea.tcs.hut.fi> (at Wed, 3 Sep 2003 13:17:56 +0300 (EEST)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:

> Come to think of it a more elegant solution might be:
> 
>         if (ifp->idev->cnf.forwarding == 0 &&
>             (dev->flags&IFF_LOOPBACK) == 0 &&
> +           ifp->idev->cnf.rtr_solicits > 0 &&
>             (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
>                 struct in6_addr all_routers;
> 
> and set both idev->cnf.rtr_solicits = 0 and idev->cnf.accept_ra = 0 for
> ARPHRD_TUNNEL6 devices

Yes, something like that.


> > Comment: this strategy is the "default."
> > We can (or even should) do this stretegy whenever we failed to
> > ipv6_generate_eui64() in addrconf_dev_config().
> 
> Should I send a separate patch to enable the random interface ids in
> addrconf_dev_config()?

No, just move them to addrconf_dev_config().

--yoshfuji

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Pekka Savola]

On Wed, 3 Sep 2003, Ville Nuorvala wrote:
> On Wed, 3 Sep 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> > In article <20030902043534.05fc6586.davem@redhat.com> (at Tue, 2 Sep 2003 04:35:34 -0700), "David S. Miller" <davem@redhat.com> says:
> >
> > > On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
> > > Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> > >
> > > > Ok, this incremental patch to my previous addrconf.c patch generates a
> > > > link-local address to the IPv6 tunnel device. It first tries to inherit
> > > > the EUI64 identifier of some other device and if this fails, uses a
> > > > random interface id.
> > >
> > > Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?
> >
> > Well, I have a question and a comment.
> >
> >         if (ifp->idev->cnf.forwarding == 0 &&
> >             (dev->flags&IFF_LOOPBACK) == 0 &&
> > +           dev->type != ARPHRD_TUNNEL6 &&
> >             (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
> >                 struct in6_addr all_routers;
> >
> > Why?
> 
> The other end of the tunnel might not yet be set up to receive the packet,
> which causes an ICMP error message to be sent back to the sender.
> 
> Besides, RS and RA over a ipv6-in-ipv6 tunnel is a _bad_ idea. A default
> route through a tunnel without more advanced (policy/flow/srcaddr/? based)
> routing schemes can lead to local routing loops.

Who are you to say it's a bad idea?  Users may have a lot of ideas, which 
some may think are bad but are OK.

There is nothing wrong with RS/RA over an IPv6-over-IPv6 tunnel.  I'd 
probably be concerned myself if it wasn't possible.  _However_, that 
doesn't make sense unless you have a more specific route to the 
destination IPv6 tunnel endpoint.

At the moment, I don't know who'd like to get a default IPv6 route over an
IPv6 tunnel, though.. IPv6 VPN users?  MIPv6 users who restrict themselves 
to bidirectional tunneling through the home agent, maybe?

just my 2 cents.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Ville Nuorvala]

On Wed, 3 Sep 2003, Pekka Savola wrote:

> On Tue, 2 Sep 2003, Ville Nuorvala wrote:
> >
> > ipv6_generate_eui64() derives the interface identifier from the MAC
> > address on ARPHRD_{ETHER,FDDI,IEEE802_TR,ARCNET} interfaces, but doesn't
> > do anything for other types of devices
>
> Ok, but then the command should be:
>
> /* try to inherit MAC address from another device, to build an EUI64 */

Ok, I'll update the comment :)

> > If the node doesn't have an Ethernet (etc.) NIC it won't get a valid
> > identifier from ipv6_generate_eui64() and has to resort to something
> > else, for example generating a random address.
>
> And exactly how often does this happen? Eth (all variants), FDDI, TR,
> ARCnet.. what's missing?  Does IPv6 even work with any other physical
> interfaces? :-)

Not perhaps physical, but PPP for example. Can we assume _all_ devices
have an Eth, FDDI, TR or ARCnet NIC? I would say no.

> Note: it is desirable to have link-local addresses reasonably stable.
> Randomizing them may not be the right choice.

They will of course be configured only once when the interface is brought
up :)

-Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[Ville Nuorvala]

On Wed, 3 Sep 2003, Pekka Savola wrote:

> On Wed, 3 Sep 2003, Ville Nuorvala wrote:
> >
> > The other end of the tunnel might not yet be set up to receive the packet,
> > which causes an ICMP error message to be sent back to the sender.
> >
> > Besides, RS and RA over a ipv6-in-ipv6 tunnel is a _bad_ idea. A default
> > route through a tunnel without more advanced (policy/flow/srcaddr/? based)
> > routing schemes can lead to local routing loops.
>
> Who are you to say it's a bad idea?

Someone who has been tackling with the issue of default routes through
tunnel interfaces in MIPL (our MIPv6 for Linux implementation) for quite
some time now ;)

> Users may have a lot of ideas, which some may think are bad but are OK.

Well, I did already mention routing loops (and ICMP errors caused by IPv6
encapsulated RSs on a virtual link that isn't up yet). I think that
qualifies as bad enough :(

> There is nothing wrong with RS/RA over an IPv6-over-IPv6 tunnel.  I'd
> probably be concerned myself if it wasn't possible.

Who says it isn't possible? The user who thinks he knows better can change
the accept_ra (and rtr_solicits) flag for the tunnel dev and start
receiving RAs through it.

> _However_, that doesn't make sense unless you have a more specific route
> to the destination IPv6 tunnel endpoint.

Yes, exactly. And what should the node do if it just has two default
routes, one through a tunnel and one through an ethernet interface? This
will be the case if a normal host receives RAs through both interfaces.

At least two things can go wrong:
1) A packet intended to the tunnel is sent straight through the ethernet
   device
2) A packet already encapsulated by the tunnel is rerouted through it and
   is thus dropped

Based on my own experiences, I can say things like this do happen.

> At the moment, I don't know who'd like to get a default IPv6 route over an
> IPv6 tunnel, though.. IPv6 VPN users?  MIPv6 users who restrict themselves
> to bidirectional tunneling through the home agent, maybe?

In MIPL, the MN uses a "default" ::/0 route through the IPv6 tunnel, but
it is only used for packets using the MN's home address as source. All
other traffic (including packets already encapsulated by the IPv6 tunnel,
thus having the care-of address as source) is routed normally through the
physical device.

Things like this aren't possible in the current IPv6 routing code, so I
had to modify the route lookup so it first checks the source address of
the packet, then the destination.

I sent a patch for this source address based routing, but it didn't make
it into the kernel, partly because the USAGI team has plans to introduce
IPv6 policy routing, which should also fix the problems.


-Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH] IPv6: (5/5+1) Autoconfig link-local addr to IPv6 tunnels

[David S. Miller]

On Wed, 3 Sep 2003 19:57:56 +0300 (EEST)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> In MIPL, the MN uses a "default" ::/0 route through the IPv6 tunnel, but
> it is only used for packets using the MN's home address as source. All
> other traffic (including packets already encapsulated by the IPv6 tunnel,
> thus having the care-of address as source) is routed normally through the
> physical device.
> 
> Things like this aren't possible in the current IPv6 routing code, so I
> had to modify the route lookup so it first checks the source address of
> the packet, then the destination.
> 
> I sent a patch for this source address based routing, but it didn't make
> it into the kernel, partly because the USAGI team has plans to introduce
> IPv6 policy routing, which should also fix the problems.

Well, it was rejected for another reason :-)

Doing route selection in the way you propose is completely backwards.

Routing engine is asked only where one would like to go, and in
response we are told how to get there and who to advertise ourselves
as (ie. source address selection).

That is, source address selection is a product of the routing lookup
not an input.

The whole engine works this way.  When TCP connects, unless user has
specified a specific source address when bind()'ing the socket, we
take source address from the route.  Source address selection is
routing task.

I do not see what it is about MIPV6 which changes this.  So you either
have to show me this thing, or accept what I say :-)