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

[Pekka Savola <pekkas@netcore.fi>]

Overall, a very good doc.

semi-substantial
----------------

4.6  Hard-coded address points

==> if one could think of a good way to categorize these, it might be
useful.  For example, which ones are internal-only?  Which hard-codings
occur on other sites?  Which hard-codings are done on network equipment
(such as routers or servers), or using mechanisms one could feasible figure
out how to automate properly?

6.  Summary

   In this document we will analyse the specific campus transition
   scenario for the author's site, and report the analysis for the
   benefit of others who may be in a similar scenario, or for whom parts
   of the scenario are relevant.  The basic IPv6 deployment is doable
   now, but there are still missing components that prevent a full
   dual-stack deployment.

==> it could be useful to try to identify which of these components are
something the IETF can do something about (e.g., something we need to
standardize, something we need to document, etc.), or implementation-only
issues (like lacking v6 support in vendor X's product).

editorial/semi-editorial
------------------------

   o  The preferred mechanism for interoperation with legacy nodes is to
      use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6
      to communicate to IPv6 nodes.  We have not identified any
      in-house, non-upgradeable legacy applications.

==> what about the backup systems?  I think it was added in the latest
ent-scenarios draft.. this is where I've seen probably most legacy apps...

3.1  DNS

   BIND9 is used for our three internal name servers.  The servers will
   be made dual stack, to be available for IPv6 transport for local
   dual-stack or IPv6-only nodes.

==> you mention internal-only transport/services, but what about the rest? 
transport to outside users, AAAA in added in glue?

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.

4.1.4  Intrusion Detection System

   o  Snort

==> short and to the point ;-).  Maybe a few words about snort's v6 support
(or lack thereof), or challenges faced could be useful here?


   o  Lack of MLDv2 snooping in Ethernet switch equipment (thus IPv6
      Multicast will flood subnets);

==> MLDv1 snooping either...


9  Informative References

==> for some reason, many of the refs appear to be quite badly out of
date...

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