Subject: RFC3484 and ORCHID addresses (fwd)

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Mar 2008 01:43:15 +0200 (EET)

FYI,

While we're considering RFC3484 changes, here's one additional 
proposed modification to RFC3484 for Linux with ORCHID (RFC 4843) that 
is worth serious consideration.  (Discussion on the best 
implementation choice(s) and glibc changes is still going on.)

One may debate whether ORCHID addresses should be dealt with the 
policy table or in the spec.

---------- Forwarded message ----------
Date: Thu, 21 Feb 2008 12:08:42 +0200
From: Juha-Matti Tapio <[email-masked]>
To: [email-masked]
Subject: [PATCH 2/2] [IPV6]: Fix source address selection for ORCHID addresses

Skip the prefix length matching in source address selection for
orchid -> non-orchid addresses.

Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
2001:10::/28) are currenty not globally reachable. Without this
check a host with an ORCHID address can end up preferring those over
regular addresses when talking to other regular hosts in the 2001::/16
range thus breaking non-orchid connections.

Signed-off-by: Juha-Matti Tapio <[email-masked]>
---
  include/net/ipv6.h  |   10 ++++++++++
  net/ipv6/addrconf.c |    5 +++++
  2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index c0c019f..67e024a 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -384,6 +384,16 @@ static inline int ipv6_addr_v4mapped(const struct in6_addr *a)
  }

  /*
+ * Check for a RFC 4843 ORCHID address
+ * (Overlay Routable Cryptographic Hash Identifiers)
+ */
+static inline int ipv6_addr_orchid(const struct in6_addr *a)
+{
+	return ((a->s6_addr32[0] & htonl(0xfffffff0))
+		== htonl(0x20010010));
+}
+
+/*
   * find the first different bit between two addresses
   * length of address must be a multiple of 32bits
   */
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e40213d..2474d20 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1125,6 +1125,11 @@ int ipv6_dev_get_saddr(struct net_device *daddr_dev,
  			if (hiscore.rule < 7)
  				hiscore.rule++;
  #endif
+
+			/* Skip rule 8 for orchid -> non-orchid address pairs. */
+			if (ipv6_addr_orchid(&ifa->addr) && !ipv6_addr_orchid(daddr))
+				continue;
+
  			/* Rule 8: Use longest matching prefix */
  			if (hiscore.rule < 8) {
  				hiscore.matchlen = ipv6_addr_diff(&ifa_result->addr, daddr);
--
1.5.3.8

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [email-masked]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: David Malone <[email-masked]>
Date: Fri, 14 Mar 2008 11:14:30 +0000

> implementation choice(s) and glibc changes is still going on.)

The default rules also have an entry for 6to4, which is intended
to prefer native IPv6 addresses over 6to4. This should probably be
generalised to include not just 6to4, but also Teredo and any other
similar mechanism that the platform supports.

	David.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2008 12:47:12 +1300

> policy table or in the spec.

Don't you mean: whether ORCHID address should be listed
in the default policy table? One possible approach is
to argue that standards-track formats should be in
the default policy table (6to4, Teredo in) and
others should be left to local policy (ORCHID out).
An alternative is to say that anything that's assigned
by IANA should be in (6to4, Teredo, ORCHID in).

BTW it's not so easy as all that. Prefer 6to4 to Teredo
and sometimes 6to4 will black-hole. Prefer Teredo to
6to4 and Teredo may be used when 6to4 is more efficient.
Longest-match won't help you there.

    Brian