Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Ray Hunter <[e-mail]>]

Andrew Yourtchenko wrote:
> Hello all,
>
> Finally I managed to comb a little bit and finally submit the doc that
> aims to compare RAs with DHCPv6 which emerged from the discussion on
> this list a few weeks ago.
>
> I'll be very happy to hear any comments, suggestions, flames, etc.
>
> --a
I think the draft will be useful if

1) it allows an operator to make an informed choice

2) it identifies areas for future work

With that in mind

for 1) As a general remark after reading the comments to the list so
far, there seems to be an underlying assumption that there's only one
way to run a network, and that the infrastructure stack of Hosts/ LAN /
MAN/ WAN/ DHCPv6/ DNS/ IPAM / Printers are all run by a single
authority, and thus integration and change costs are effectively zero.

IMHO "all combinations are possible" as used in an advert by a local
supermarket. These infrastructure elements are usually run on behalf of
a single authority in my experience, but if your LAN routers are not run
by the same people as your IPAM and DNS, you might well want to make
different trade offs with respect to what information is communicated by
RA and what by DHCPv6, and what requests are relayed to a central
instance and what is configured in a distributed manner on the local boxes.

I think the pure technical discussions miss the impact on the management
model mentioned in 2.10.

I'd like to see an addition of some sample management models, where the
infrastructure is run by different parties (this is v6ops after all).
e.g. if you can set up your LAN routers to set up their interfaces using
PD (with all information loaded from IPAM) plus a couple of DHCPv6 relay
commands for the rest (also potentially loaded/learned from IPAM) I
could imagine considerable costs savings in large environments. Whereas
in a highly distributed environment, IPAM may not even make any sense at
all, and local configuration via RA and local config files only might be
extremely useful and cost effective. Provisioning is a major network cost.

However that choice in turn is likely to impact the ease of renumbering
in the future (a major bugbear of IPv4). It will also impact what
protocols a travelling end node will have to support (code bloat).

2) I also think the areas of future work would be filled quicker if we
examine the alternative approaches, and filled in the complete picture.

So I'd suggest we look at the complete end to end picture needed to roll
out and support the following combinations

a) Central model: everything configured centrally as far as possible,
with zero configuration information that is likely to change stored
locally (configure local LAN switch once and forget, plus central IPAM
DNS etc. for changes)
You'll then hit the "How does an end node learn a default route?" and
thus "how does the RA daemon learn it's prefix information?" type questions
Think Meraki cloud controlled devices.

b) Distributed model: everything configured locally on the local LAN
switch or router (no IPAM required)
You'll then hit the "how is DNS updated?" type questions.

c) download model: hosts actively grab an XML file via HTTP for their
"extended" configuration (or use AD).

d) stand alone (disconnected) model: there is no router.
You'll then hit the "How do I elect a DNS server?" and "why not use
zeroconf?" type questions

There is considerable overlap here with Homenet....... although the
focus could be specifically on address assignment and the interactions
between end nodes and routers.

-- 
Regards,
RayH