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,How a delegator has to allocate address space is a key point IHMO.
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!
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.
Finding a delegator is different from retrieving a prefix. Like finding the authority and the resource.- 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.
I think is interesting to dissociate the 2 tasks,
for example to be able to retrieve prefixes from 2 different delegators.
I see in HPD a simple way to have unique and global subnet values based on a global initial prefix.- 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.
And when link numbering is well done, resulting propagated routes can be minimized.
I think the approach is good,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..
even using another link-local messaging,
we thought of course about using ND and SEND to secure the Delegator claimed role.
I think a first step could be to find a trusted Delegator,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:
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: +33 (0)1 69 63 18 34
Route de Nozay Fax : +33 (0)1 69 63 13 59
91460 Marcoussis mailto:[EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
