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

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Sun, Aug 01, 2004 at 05:45:29PM +0300, Pekka Savola wrote:
> 
> 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?

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.

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

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

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.

> 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?

Will add, thanks.
 
> 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.   

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.

> 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?

It is v00 :)   
 
>    o  Lack of MLDv2 snooping in Ethernet switch equipment (thus IPv6
>       Multicast will flood subnets);
> 
> ==> MLDv1 snooping either...

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

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