Re: simpler prefix delegation

[[e-mail]]

Hi,

We are working on the subject since last year
and have a first prototype that does prefix delegation and global 
address configuration
on a simple IPv6 network.

Here follows some thoughts that could help, I hope.


Pekka Savola wrote:

>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!
>
>  
>
How a delegator has to allocate address space is a key point IHMO.
A Delegator has to split a unique and large address space into several 
smaller ones.

And this address small can be used in two ways:
- link numbering
- sub-delegation

the right to sub-delegate a given prefix could be allowed by a delegator 
to a requetor, or not: only for link-numbering.
to avoid the usage of all the address space of delegated prefix very 
quickly.

> - Similarly, PrefixDiff doesn't seem to be all that useful.
>
>  
>
how the prefix length is raising represents how fast the address space 
is used  from the root router to leaf routers.

> - 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.
>
>  
>
Finding a delegator is different from retrieving a prefix. Like finding 
the authority and the resource.
I think is interesting to dissociate the 2 tasks,
for example to be able to retrieve prefixes from 2 different delegators.

> - 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.
>
>  
>
I see in HPD a simple way to have unique and global subnet values based 
on a global initial prefix.
And when link numbering is well done, resulting propagated  routes can 
be minimized.

>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..
>
>  
>
I think the approach is good,
even using another link-local messaging,
we thought of course about using ND and SEND to secure the Delegator 
claimed role.

>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:
>
>  
>
I think a first step could be to find a trusted Delegator,
to avoid abuse of a malicious prefix provider node (using SEND and 
signature ND option).

> 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.
>
>  
>
to go further until link numebering,
and to avoid to much prefixes usage on the same link,
our experiment showed that a link prefix "negociation" is useful.



Hope the propositions above could help.


I'm adding a big Thanks to APD and HPD authors for their work on the 
problem.


Regards,

Laurent Clévy

-- 
Laurent Clévy                
Alcatel CIT, R&I             Voice: [phone]
Route de Nozay               Fax  : [phone]
91460 Marcoussis             mailto:[e-mail]



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