Re: IPv6 RA vs DHCPv6 - The chosen one?

[Owen DeLong <owen () delong com>]

I had some trouble parsing what Glen was saying, so, I'll provide some
clarification of how things actually work today and what I think would be
desirable in future development:


1.      In IPv6, it is not uncommon for certain types of routers to be DHCP clients.
        DHCPv6-PD is relatively useless except when talking to a router.

2.      Routers rarely listen to RAs and mostly generate them. There's no
        reason for router A to listen to RAs from router B on the same link.
        Router A doesn't care that Router B can be a default gateway. If
        Router A needs a default gateway, router A shouldn't be advertising
        himself with RAs and should know about Router B from a static
        route or some routing protocol.

        RAs are only useful (as far as routing is concerned) for routers to
        announce themselves as default gateways. They do not provide
        any mechanism for advertising more specific routes.

3.      As it currently stands, RAs can provide the following information:

        +       Default Router (anything sending an RA should be a valid
                default router).
        +       Router Priority (High/Medium/Low)
        +       Prefixes (must be /64) for SLAAC
                *       Desired Lifetime
                *       Valid Lifetime
        +       DHCP Server Address
        +       DNS Resolver Address[1]
        +       M-Bit (Network is managed, host should ask DHCP server for
                some configuration information)
        +       A-Bit (DHCP server is authoritative for addressing, do not use
                SLAAC to generate unicast addresses from prefixes)

[1]     Requires recent extensions to SLAAC and RA. Not available in all
        implementations.

4.      As it currently stands, a DHCPv6 server can provide most of the things
        you're used to a DHCP server providing.

        It cannot provide any information about routing whatsoever.

        There is currently no mechanism for a host to ask a DHCPv6 server
        for configuration information unless and until it receives an RA with
        at least the M-Bit set. (You currently can't use DHCP without RA).

        Currently, many clients support only SLAAC and Static for configuring
        IPv6 information. If you have such clients in your environment, setting
        the A-bit is generally self-destructive.

        Short of some form of NAC[2], there is currently no mechanism for
        preventing a host which uses SLAAC in spite of the A-bit being
        present (nefariously or erroneously) from making use of the network
        with that address. (i.e. you can't force a host to use DHCPv6 if it
        is not well behaved).

[2]     Network Admission Control -- A process which does not place clients
        into functional VLANs on the switch until certain policy defined
        criteria have been met.

5.      What I'd like to see:

        1.      A mechanism for DHCP to be used without requiring RA at all.
        2.      A mechanism for DHCP to provide zero or more copies of an
                optional attribute called "Routing Information". Said attribute's
                value would be a structure containing:
                        Prefix (128 bits)
                        Masklen (8 bits)
                        Next-Hop (128 bits)
                        Metric (16 bits)

                A default router would be specified as:
                        Prefix                  0::0/128
                        Masklen                 0
                        Next-Hop                pfx::gateway

                A static routing table with specific routes could be built as:

                        Prefix                  2001:0db8:0:32::
                        Masklen                 64
                        Next-Hop                2001:0db8:0:7::1

                        Prefix                  2001:0db8:0:64:
                        Masklen                 60
                        Next-Hop                2001:0db8:0:7::5

                        Prefix                  ::
                        Masklen                 0
                        Next-Hop                2001:0db8:0:7:feed:beef:cafe:babe

        3.      Extensions to SLAAC to provide for NTP, "next-server", "boot-file",
                and certain other key elements available from DHCP, but, not possible
                in the current specification for SLAAC.

Yes, this will annoy those purists who believe there should be one true way
to do each thing. That's OK, they're entitled to their opinion, but, this is mine.
DIfferent operators have different preferences and different environments
sometimes work better or adapt better to different solutions.

Currently, most significant environments have to cobble together a complete
solution from remnants of SLAAC and DHCP. This is far from ideal.
Far better for organizations to look at 2 complete solutions and pick the
solution that works best for them in their environment.

Owen

On Dec 20, 2011, at 1:58 AM, Glen Kent wrote:

> When a router needs to learn information from another router it will
> *usually* use the RA messages and not DHCPv6, as the latter is
> *usually* meant for Router - Host communication. However, it is NOT
> uncommon to see hosts also learning the information using RA messages.
> Router's afaik dont usually act as DHCP clients and thus information
> that can only be passed in DHCPv6 may not be available to the routers,
> and you may need an alternate mechanism.
>
> Glen
>
> On Tue, Dec 20, 2011 at 11:57 AM, Ravi Duggal <raviduggal2906 () gmail com> wrote:
> > Hi,
> >
> > IPv6 devices (routers and hosts) can obtain configuration information
> > about default routers, on-link prefixes and addresses from Router
> > Advertisements as defined in   Neighbor Discovery.  I have been told
> > that in some deployments, there is a strong desire not to use Router
> > Advertisements at all and to perform all configuration via DHCPv6.
> > There are thus similar IETF standards to get everything that you can
> > get from RAs, by using DHCPv6 instead.
> >
> > As a result of this we see new proposals in IETF that try to do
> > similar things by either extending RA mechanisms or by introducing new
> > options in DHCPv6.
> >
> > We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends
> > DHCPv6 to do what RA does. And now, we have
> > draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise
> > the NTP information that is currently done via DHCPv6.
> >
> > My question is, that which then is the more preferred option for the
> > operators? Do they prefer extending RA so that the new information
> > loaded on top of the RA messages gets known in the single shot when
> > routers do neighbor discovery. Or do they prefer all the extra
> > information to be learnt via DHCPv6? What are the pros and cons in
> > each approach and when would people favor one over the other?
> >
> > I can see some advantages with the loading information to RA since
> > then one is not dependent on the DHCPv6 server. However, the latter
> > provides its own benefits.
> >
> > Regards,
> > Ravi D.