RE: [RRG] Evolutionary Possibilities

[Randall Atkinson <rja@extremenetworks.com>]

Much earlier, RJ Atkinson suggested:
> 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.

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
rja@extremenetworks.com

[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.


--
to unsubscribe send a message to rrg-request@psg.com 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