Re: Comments on draft-ietf-v6ops-ent-scenarios-00

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

On Wed, Oct 22, 2003 at 09:41:41PM -0400, Bound, Jim wrote:
> 
> But does IPv6 only mean that the node simply does not have an IPv4 stack
> at all.  I don't see that happening for a long time.  I suggest we
> assume dual stack for this work and not IPv6 only.  That for IPv6 ONLY a
> future addendum to this spec be written?

[Comments on the open replies - everything you say looks fine to me Jim]

The way many enterprises will add IPv6 functionality is to put dual-stack
on the network and enable as many devices and applications as they can/need.

The common method in universities at present is to inject Router Advertisements
into existing IPv4 VLANs, such that the IPv4/IPv6 subnets are congruent.

The nice property of IPv6 here is that you can add devices that communicate
only over IPv6 (IPv4 may be in the stack but not enabled), keeping the same
IPv4 subnet plan.  So small, IPv6-enabled devices that support "ambience"
can be introduced into the enterprise while keeping the existing addressing
plan, and dual stack devices and proxies provide the communication to the
new devices.   It's one quite reasonable path for introduction of IPv6(-only)
devices.

The question is how this fits into the v6ops-ent-scenarios document - I think
the introduction of such devices has to be in here somewhere or at worst 
referenced as a future work later.   I would hope/expect this is realistic 
inside 4 years for example.

> >      - If not upgradeable, can an equivalent upgradeable 
> > software function 
> >        be substituted for the one that is not upgradeable? 
> > (e.g. a different
> >        directory service mechanism)
> 
> This I think is to be done in the analysis spec??????????

I think it's again implementation specific (e.g. one directory service has
no IPv6 support while another does) and thus should probably be treated in
the same way (whatever that is :) as certain host or router platforms that
as yet lack certain IPv6 functionality.   I think we have to just use terms
like "legacy IPv4-only devices" in a generic way and the analysis for 
introducing IPv6 has to determine if/how to interact with such devices (or 
applications, as we can have "legacy IPv4-only applications" on dual-stack 
devices).

> > This is an important area the WG needs to take on board.
> 
> Yep.  I think Management Scenarios could be its own spec?

Agree.

> > Does this affect the transition tool analysis, e.g. if 
> > RFC3041 means that IP-based authentication is no longer 
> > possible?  I guess it may affect a 
> > specific implementation of a security policy?
> 
> Yep. But what I was thinking here is what new problems does transition
> introduce onto the network of the enterprise?  That list would be useful
> I think.  Esp. in Ent Scenarios to feed Ent Analysis doc.

OK, this is a good question but as you suggest maybe a separate doc.
 
> > You could say the translator may be at the network, transport 
> > or application layer.
> 
> We can add that but for this "reference" model document I don't think it
> matters?

OK.
 
> > There are three categories of issues I think, i.e.
> > 
> >   - standards: dns resolver discovery, 512-byte response format, 
> >     reverse zone managemnt and dynamic dns
> > 
> >   - transport: root servsers, OS supporting native lookup, 
> > and whether the
> >     upstream ISPs filter the root space /48's
> > 
> >   - registry: registering domains with IPv6 DNS servers
> 
> Agree but is Enterprise Scenarios the only spec that needs to address
> that what about Umanaged, 3GPP, or ISP docs?  

There are many commonalities between the scenerio documents, but I think it's 
been very useful for each of the four to use its own approach as each is then
taking a different view of a similar problem to get best insight.  

The standards issues need analysis by dnsop (e.g. I think Alain has a draft
on reverse zone population for autoconf networks) while the transport and
registry issues are "implementation specific" issues that will (have to be :) 
fixed one day, but not by the IETF.
 
> This is true for all scenario documents, is Enterprise work the only
> spec that has to do this or do we need a generic DNS transition document
> as Management etc...

It's maybe beginning to look that way... we need some vertical analysis
(or horizontal, depending on which way you look at it!) across the scenarios
on some specific items.   So far it looks like we have network management,
maybe transition management as part of that, and DNS.
 
> > Will it need DHCPv6 forwarding?
> 
> Do you mean relaying?

Yes, sorry.
 
> > Would IPv4 and IPv6 subnets be congruent?
> 
> I think parallel is more correct?

OK. (Congruent when I look it up says "coinciding exactly when superimposed",
by which I mean the IPv4 and IPv6 subnets are laid onto the same set of 
devices).
 
> > An advantage of IPv6 is that you are unlikely to ever need to 
> > resize the subnets (up or down).
> 
> ERRRRRRRRRRRRRRRRR.  Need to think about that.  One could blow the bits
> to the left on a site boundary with sensors :--).

OK, maybe when we get into really big networks :):)  What I mean is that now
an enterprise will slice up its IPv4 address space into the smallest subnets
that it can, to conserve address space (and to be able to go back to ask
for more IPv4 address space).   So you'll quite commonly need to fiddle with
those subnet sizes as the number of workstations or whatever in an existing 
subnet grows or shrinks.   In IPv6 you have (relative) flexibility there.
 
> > Do we have address space independence from provider?
> 
> I don't believe this is true at all?  We do not even more so with IPv6
> and I don't like that quite frankly ...................

OK.
 
> > What about preference of use of IPv4 or IPv6?
> 
> Ouch. I fear a 1000 mail message debate.  I suggest we avoid this and
> leave scenarios for the enterprise to have that debate when they deploy.
> OK.

Yes :)   
 
Tim