Re: draft-chown-v6ops-campus-transition-00 comments

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 1 Aug 2004, Tim Chown wrote:
[...]
> > 3.3  Configuration of Hosts
> > 
> >    IPv4 clients use DHCP for address and other configuration options.
> >    We expect to use Dynamic Host Configuration Protocol for IPv6
> >    (DHCPv6) [4] for IPv6 clients.  This will require analysis of the
> >    IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [10].  We expect some
> >    clients, especially in wireless LANs, to use IPv6 Stateless
> >    Autoconfiguration [1],
> > 
> > ==> it might be interesting to describe the particular reason for running
> > DHCP.. as the justifications for DHCPv4 (compared to the alternative of
> > manual assignments) vs DHCPv6 could be quite a bit different.  Would you be
> > satisfied with stateless DHCPv6, for example -- or are there client nodes
> > which need a different kind of address -- why?
> > It might also be interesting to know whether you plan to support SLAAC in
> >
> > all the subnets, or whether you are thinking of having DHCP-only
> > subnets/links.
> 
> Will do.  One of the reasons is that we like to have some chance to trace
> systems to users in the event of, for example, some virus/worm event or 
> other unusual activity, which implies a managed database driven address
> assignment approach.    However, we are now experimenting with 802.1x for
> our WLAN, so we can authenticate at Layer 2 and then we could argue that
> SAA is OK for Layer 3 in WLANs.   

Remember that if you keep track of MAC addresses, SLAAC is actually 
easier to track than DHCPv6, right?

That is, shouldn't a database of MAC addresses, e.g., also generating 
filters to the Ethernet switch ports, give quite a high amount of 
manageability even without DHCPv6.

[...]
> My general question is how useful this document is, and if the WG thinks it
> is useful work then how to approach making an Informational document from it.
> Some of my concerns are over level of detail required or of interest, others
> are more "procedural", e.g. should specific apps or vendors be mentioned in
> an I-D, or should we abstract those references?

These are good topics to discuss at the meeting..

(Typically the vendors, etc. are not described, but in this particular
case it might make sense to do so; I don't think there is a hard rule
here..)

> The material in the document may also date in time, e.g. the VLAN mathod
> we use now will become obsolete as the L2/L3 switch-router equipment begins
> to support IPv6 fully.

True, but at that point v6 transition is also a bit further along.

(FWIW, our site started with manual tunnels and VLANs, now VLANs are
mostly gone as the support is offered through the same boxes as v4..)
 
> We also do not consider new IPv6 features, e.g. MIPv6.  We take the view of
> transitioning from a v4-only site.   In the case of MIPv6 there will be
> implications for the site of course.

As MIPv6 was not a goal for you in the transition, it doesn't need to 
be mentioned.  If you wish, you can of course describe how you've 
deployed new v6 features as well..
 
> My view is that the document could become a useful specific example
> of the ent-scenarios draft, with analysis for the specific exmaple
> included, and text that helps other enterprise administrators plan
> and implement their transition.

Yes, I think personally think it's useful -- the question is just what 
would be the appropriate channel(s) to disseminate that information 
(e.g., keep as I-D, publish as Info through RFC-editor, Info through 
RFC-ed process, etc.)

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