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

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 17:45:29 +0300 (EEST)

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

---

From: Tim Chown <[email-masked]>
Date: Sun, 1 Aug 2004 19:52:37 +0100

> out how to automate properly?

Nice idea.  The list is one we're building as part of a deeper look into
IPv6 renumbering issues, on the basis that (rightly or wrongly) people will
put v6 addresses in the same config files as they do today in v4.   But
it's also a good cue for what needs to be looked at in the transition 
process.   If names are used, there may be some problems, e.g. we found
with the Nagios monitoring tool we wanted to monitor v4 and v6 services
on dual-stack hosts, and so needed to configure v4 and v6 addresses
explicitly in the monitoring tool, which is not ideal - rather the monitoring
tool should be given some option to probe v4 and v6 addresses from a given
name and report on both/all in some meaningful way.

> issues (like lacking v6 support in vendor X's product).

Again, a very good suggestion.   So there's 
 - IETF standardisation issues
 - implementation specific tools
 - "political" or policy issues
 - other standardisation issues (if there are any, e.g. GGF or W3C?)
 - missing vendor support (should this/any I-D even mention vendors??)

At least the first 3 are a useful split.

> editorial/semi-editorial

Maybe.  We should add that, and maybe it went into ent-scenarios after I
last looked it at, I'll diff the last two and check.  In our case we run
backups either locally (on big RAID systems) or over ssh (smaller service
system) so that's not an issue for v6 for us.

> transport to outside users, AAAA in added in glue?

Will add, thanks.
 
> all the subnets, or whether you are thinking of having DHCP-only

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.   

There's a lot here that is about "thinking the IPv4 way", be it DHCP in this
example or, as another example, use of private addresses and NAT as a
standard site policy.

> (or lack thereof), or challenges faced could be useful here?

It is v00 :)   
 
> ==> MLDv1 snooping either...

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

My wget for xml2rfc broke, sorry, and didn't notice until after the doc
went in.  Will be correct in v01.

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?

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.

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.

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.

Tim

---

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 22:24:27 +0300 (EEST)

On Sun, 1 Aug 2004, Tim Chown wrote:
[...]
> 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.

[...]
> 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..)

> we use now will become obsolete as the L2/L3 switch-router equipment begins

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..)
 
> 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.)