Subject: [RRG] Evolutionary Possibilities

From: Randall Atkinson <[email-masked]>
Date: Thu, 14 Feb 2008 15:11:16 -0800

Earlier, David Conrad suggested:
% We already have to change host stacks and applications to support
% IPv6.  Given the minimal deployment of IPv6 to date, particularly
% within the application space, this doesn't seem like a non-starter
% to me.

Agreed.

Let me go farther, and in a bit of a different direction...hence
the updated subject line.  (I'd be greatly obliged if everyone
would update subject lines when the topic/focus of a thread
changes. :-)

I don't think that it is too late to be enhancing IPv6.  For example,
one could easily imagine taking some of the ideas originating back
with ddc and mo and applying them now to IPv6.  The functional
requirement would be that the enhanced IPv6 remain backwards
compatible with existing IPv6 -- for the near term.  Even today,
most companies have actively disabled the IPv6 stacks inside
their Windows systems (because of security concerns with TEREDO).

A trivial way to deploy this would be to include a new IPv6 Destination
Option ONLY for the first packets of those sessions originating in systems
that have support for "enhanced IPv6".  The option would not be
needed once TCP hit "established" state or SCTP hit its equivalent
or after the first few UDP packets in a flow.  This option could
be an indication, for example, that the transport-layer pseudo-header
checksum only included the lower 64-bits (ID) and not the upper
64-bits (Locator -- or if one prefers 'Routing Prefix').

Old systems would drop the new packets because of either the
unknown Destination Option OR because the transport-layer
pseudo-header check failed at input time.  The updated originating
host would then fall back to "classic IPv6" using the existing
all-128-bits pseudo-header calculation and omitting the new
Destination Option.

Then, to create pull for this new IPv6 enhancement, use that
to enable host mobility, network mobility, node multi-homing,
site multi-homing, and so forth.

Mind, this would do zero for the RIB/FIB tables in the deployed
IPv4 Internet -- but it could do a great deal to reduce/manage
RIB/FIB table sizes in a future IPv6 Internet -- and could also
do a great deal towards scalable, widely used, widely deployed
mobility/multi-homing solutions.

It might sound wacky to some, but this would be a very reasonable
evolutionary path forwards -- and it would address a broader
set of routing architectural issues than just the RIB/FIB size.
(Kindly keep the IPv4 caveat above in mind. :-)

Yours,

Ran
[email-masked]

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 15 Feb 2008 23:20:45 -0800

> site multi-homing, and so forth.

And you use shim6 to negotiate Routing Locators?

Your suggestion solves the checksumming problem, which is a good  
problem to solve, but are you assuming middle boxes are modifying the  
Routing Locator or is the host ala shim6 or HIP or whatever deciding  
on Routing Locators?

Dino

---

From: Randall Atkinson <[email-masked]>
Date: Sat, 16 Feb 2008 06:40:11 -0800

> site multi-homing, and so forth.

More recently, Dino Farinacci asked:
% And you use shim6 to negotiate Routing Locators?
%
% Your suggestion solves the checksumming problem, which is a good
% problem to solve, but are you assuming middle boxes are modifying the
% Routing Locator or is the host ala shim6 or HIP or whatever deciding
% on Routing Locators?

I am not assuming SHIM6.

My guess is that if one went down this path, individuals and organisations
would choose not to use SHIM6, but it isn't obvious to me that it would be
precluded from use in such an event.

I am not making any assumptions about whether routers/middleboxes
do or do not modify the Locators.  I think the best design would not
require them to do so -- but also not prohibit them from doing so
(provided that any such rewrite moves the packet closer to the
destination -- a constraint suggested solely to avoid routing loops).

Purely as an example, and without intending any limitation on
possible approaches, let us look at tools that are already on the
table  (RFCs published and running code available today) for IPv6:

- We have ways to perform Secure Dynamic DNS Updates and
  these are implemented in freely available software.  I'm told
  that MS Windows includes this capability also, which means
  this is *widely* available if that report is accurate.  (I don't
  have access to a Windows system to test this myself.)  I am
  separately told that BIND supports this capability.

- DNS is a way that one can advertise addresses.  It seems pretty
  straight forward to continue to use that -- either concatenate
  the set of (Locators, Identifiers) an put those into AAAA/A6
  records or add (L, I) records.  The latter is a trivial exercise.

- We have DNS Security, if one thinks that one needs to authenticate
  DNS.  The risks of non-authenticated DNS are not higher with
  this approach than with current deployments.  If someone can
  forge an A/AAAA/A6 record today, one can cause various mischief.
  Similarly, if one could forge (I,L) records one could cause various
  mischief.  I am told that there are at least 2 different DNS server
  implementations (one is BIND) that support this.[1]

- I believe existing IPv6 Neighbour Discovery provides ways for a host
  to learn automatically the full set of routing prefixes that it might
  use.

- Some existing IP multi-homed deployments have 1 routing prefix
  supplied by each upstream, with each host inside the site having
  (at least) 1 IP address per upstream.  This sort of multi-homing
  approach avoids placing burden upon the Routing System
  (e.g. RIB/FIB de-aggregation is avoided).

- We have ways to cryptographically authenticate control traffic
  (the best approach for this is AH, which is widely available in
  IPv6-capable systems).

- We probably need a way to non-cryptographically protect control
  traffic against off-path attacks.  (I know of ways to do this.)
  The reason this is needed is that existing IPv6 is vulnerable to
  on-path attacks if AH is not used to protect the traffic, but is
  somewhat protected against off-path attacks even without AH.
  So one wants to provide (optional to use) equivalent protections
  without requiring cryptography on each packet.  (Cryptography
  might seem "sexy" to some, but it is mostly a pain and has
  repeatedly proven problematic in real deployments, so it is
  best not to require it in ordinary lower-risk environments.)

CAVEAT:
   As I have said here before, it isn't obvious to me how one
could implement a true I/L split scheme in IPv4.  The challenge
is where to put the Identifier values if one can't use IPv4
options.  (Using IPv4 options is a non-starter because it forces
the packet to be slow-path forwarded in nearly all current
implementations.) [2] [3]

Cheers,

Ran Atkinson
[email-masked]

[1] Although some have claimed that "DNS Security" is undeployable,
this seems to be disproved by at least one large-scale DNSsec
deployment that I am aware of.  DNS Security does seem to be
more complicated to configure correctly.  However, the critical datum
for this disucssion is that the DNS risks for an I/L split scenario
don't significantly vary from the risks for the deployed IPv4 Internet.

[2] It isn't obvious to me what practical alternatives might exist within
the IPv4 universe to some form of map-and-encapsulate/tunnel scheme.
So I strongly suspect that the Routing RG will end up recommending
something in that class of solutions for IPv4.  Such a recommendation
would not automatically imply using the same techniques for IPv6,
however.

[3] Maybe I have missed something somewhere (certainly I am
behind in my reading of various proposals), but it also is not
obvious to me that the map-and-encapsulate solution class
is helpful for things beyond site multi-homing -- for example
(a) host  multi-homing, (b) host mobility, (c) network mobility.
A question in my mind is whether the Routing RG is trying to
solve just the narrow near-term issue of RIB/FIB scaling issues
caused by site multi-homing XOR the Routing RG is trying to
create an enhanced architecture that solves a much broader
set of current/future issues.

---

From: Tony Li <[email-masked]>
Date: Sat, 16 Feb 2008 09:13:46 -0800

> implementations.) [2] [3]

One way would be to use a new transport protocol code point, hide  
data within that, and then run traditional transports on top of that.

There are always going to be encoding tricks that we can play.  The  
real question is more about the correct conceptual result.

Tony

---

From: Randall Atkinson <[email-masked]>
Date: Sat, 16 Feb 2008 09:37:48 -0800

Earlier, Tony Li suggested:
% One way [to handle IDs in IPv4 without IP options] would be to use a
% new transport protocol code point, hide data within that, and then run
% traditional transports on top of that.

That could work -- but would cause the packets to get dropped at virtually
every firewall/NAT/NAPT box on the planet (due to unrecognised transport
protocol number).   So I am not sure that I'd call that "practical".  :-(

By contrast, the IPv6 engineering approach I suggested won't have that
failure mode...

Cheers,

Ran
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Feb 2008 00:28:48 -0800

Thanks for the response Ran. Just one brief comment below.

> implementations.) [2] [3]

This is why LISP for IPv4 chose encapsulation. There really was no  
other choice.

Dino

---

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Feb 2008 14:24:29 -0800

Ran,

> The functional
> compatible with existing IPv6 -- for the near term.

Right -- things like this should indeed be possible. Just to confirm
from my IETF perspective: if needed, we can add new features or
functions to IPv6 if the backwards compatibility is retained. Or even to
IPv4. We do it all the time...

(But I am not quite sure what your exact proposal is, maybe there will
be a draft on this later? And note that, quite obviously, there has to
be incentives for people to add those things in their networks and hosts
or else none of this will get deployed.)

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Feb 2008 13:08:35 +1300

> or else none of this will get deployed.)

I can't help pointing out that shim6 *is* evolutionary in exactly the
sense Ran suggests - bog standard RFC2460 hosts will just not be able
to play, and shim6 hosts will understand this and stop trying to
use the shim. I see no reason personally why we shouldn't use a
similar approach for enhanced hosts to interact with a loc/id system.
To provide the incentive, there has to be enhanced connectivity
as a reward.

   Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Feb 2008 16:49:27 -0800

Brian,

> To provide the incentive, there has to be enhanced connectivity

Shim6, like many other specifications around IPv6 (various mobility
features, SEND, DNA, RFC 3041, etc) are optional. You can communicate
with other hosts without them, but if you want the feature then
obviously you have to support it at least on your end and in some cases
even in the other end. However, all of these features have been
developed with the idea that you must be able to communicate with peers
that do not support the feature. So, where the same conditions are
fulfilled we could create new host functionality to support something
that a new routing architecture needs.

However, this by itself is not enough for Ran to succeed in his effort.
Obviously he needs to convince the host folks to support such new
functionality. The incentives for doing that relate to things that will
directly benefit the host and end user experience. As Brian mentions,
enhanced connectivity is one such reason. Ability to work in large
networks (where Shim6 is not as applicable as in small and medium size
networks) would be another one. And so on. But words of warning -- we
have been surprised by what people want to and do not want to implement.
In any case, there will be some amount of implementations that change
very late if at all. So you have to be able to run the Internet while
you still have a significant fraction of hosts that don't support the
new things. If you can do that -- fine. If not, you better find a new
incentive model or a different solution.

Jari