simpler prefix delegation

[Pekka Savola <[e-mail]>]

Hi,

This started from me looking at draft-bykim-ipv6-hpd-01.txt, what it
was before that, DHCPv6 + PD, a few proposals at v6ops for integrated
prefix delegation, etc.. -- I couldn't help thinking, "there must be
an easier way to delegate an IPv6 prefix in the simplest setups (e.g.,
when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way
too heavy-weight".

This is where I got.  Thoughts appreciated.

Problems with the spec (draft-bykim-ipv6-hpd-01.txt)
----------------------

I think this is a useful continuation of Brian/Jim's Automatic Prefix
Delegation work.  All the problems in the world are not necessarily solved
by DHCPv6... so I think developing an extremely simple PD protocol could be
very useful.  The applicability area I see for this are the cases where
DHCPv6 is not being used, especially when the ISP wants to offer IPv6
support very simply, using a tunnel.

However, this document goes into a bit too complex direction.  There are
multiple problems with the approach as-is:

 - Why use PrefixCnt, and not PrefixLen when sending the Delegator Query? 
The most important thing is the length of the desired prefix, not the number
of them, after all.  The whole PrefixCnt thing seems fishy to me, all in all
-- the same information can be obtained by using an appropriate PrefixLen!

 - Similarly, PrefixDiff doesn't seem to be all that useful.

 - CGA security does not work unless you use Signature options from SEND as
well, so that can be scrapped.

 - 2 roundtrips are needed, with 4 different messages to get a prefix: a bit
too many for my taste.

 - The draft makes confusion about "built-in routing".  That sort of thing
is integrated with prefix delegation in any case: you can't have it without
-- as static routes are set in any case.  This seems unnecessary to mention
here.

 - The scope is not clear; why would one need hierarchical prefix
delegation where one would not use routing?  That is, if one gets a /64, it
cannot be delegated (in a meaningful way) forward.  If one gets a /48 (e.g.,
on a home network), why would one need to delegate it forward -- are there
routers there, requesting smaller prefixes -- I hope not!  And in an
Enterprise, you want to set this up manually in any case.  So the whole
hierarchical part appears to be really fishy, and should be removed unless
clear justification is found.

So -- I think think the spec has suffered from a serious feature creep, with
little regard to the actual user needs.

But, I'd still propose to go forward with this (or another document, started
from scratch), in an entirely different format and design tradeoffs, as
described below. 

I could write it, but I would prefer if someone else wanted to work on
this (too many things in progress at the moment.)

Current model is basically like:
--------------------------------

 1. Delegator Query, looking up the delegators and signalling the number of
    prefixes solicited (no prefix length?).
 2. Response w/ nmber of prefixes and prefix len difference (how?)
 3. Prefix Request to request prefixes (not telling which)
 4. Response w/ prefix delegated 

Return: prefix returned message -- replied with prefix returned.

Renewal: renewal message.

As you see, there are a lot of different messages, with different subcodes:
really difficult to understand..

Proposal
--------

Instead, use Neighbor Discovery messages rather than directly putting them
on top of ICMPv6.  This gives the benefit of being able to use all the
functions of SEND without any specification, as SEND only protects neighbor
discovery messages (and all of them, if you just plug in the signatures etc!).

[[ the features in double brackets are ones that could be easily 
added, but IMHO I'm not sure whether that is worth the effort. ]]

Now, the messages could be like:

 Prefix Solicitation: sent to "all-prefix-delegators" link-local multicast
address or a unicast address (learned using means outside the scope of this
memo; but link local)
   * addresses checked to be link-local, TTL=255. (same for all the
messages.)
   * Includes PrefixLen field, indicating the preference for the prefix
     length
   * Includes a "Test" flag: if given, the routers does not
     actually delegate the prefix, only show which prefix they would have
     given. (This can be used to pick among the routers, as well as learn
     which kind of prefixes/lengths they would be giving.  But the point is
     that if there are multiple routers which are willing to give you a prefix,
     why not get prefix from each unless explicitly desiring otherwise?)
   * Includes a "No Refresh" flag: if given, do not refresh the existing
     prefixes, but allocate new ones; the old ones continue to be used.  If
     not given, refresh the old prefixes (if delegated) or allocate new ones
     (if no existing delegation).
   * [[ no PrefixCnt field, as this seems unnecessary -- just use 
     PrefixLen or ask again -- but could be plugged
     in later if deemed necessary ]]
   * [[ no authentication/user identification options; authentication 
     is assumed to be obtained
     on the link layer.  However, it is possible to include Authentication
     type and length fields (1 octet each) which can be used to piggyback
     different kinds of authentication information, later on if needed.
     Authentication could also be done with SEND. ]]
   * [[ one could have "reverse DNS delegation requested" flag here as well,
     with an option which could encode DNS server address(es), but I don't
     think that's really important for mainstream use.]]

 Prefix Delegation: sent to the unicast link-local address of solicitor
   * includes Test flag, to indicate whether delegation was really done
   * [[ could also have reverse DNS delegated flag, as described above, but
     IMHO doesn't seem to be really important for now.]]
   * includes the prefix(es) delegated to the user.

     [[  each prefix could have a
     lifetime as well; lifetime of zero means "not specified" -- no
     refreshing is needed as long as NUD works.  If lifetime not
     specified, the lifetime of RAs on downstream interfaces SHOULD NOT be
     greater than 7200 seconds. ]]

[[ Prefix Maintenance: miscellaneous messages
   * code 0: return the prefix; used by the solicitor to give back a prefix,
       either when ceasing to use it or when refusing the prefix delegation.
]] -- could be used for serious DoS unless authenticated.

The solicititor SHOULD run NUD on the interface.  If NUD fails to the
routers which have delegated prefix(es), MAY send a Prefix
Solicitation message with "No Refresh" not set (to know whether the
delegation exists; if it doesn't, to get a new one).  If some other
indication has been received that the interface has went up/down, may
similarly re-initiate the procedure.

Would this seem to make sense?  This also fulfills the prefix delegation
requirements draft's requirements pretty well AFAICS.

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


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------