Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt

[Alain Durand <Alain.Durand@Sun.COM>]

On May 12, 2004, at 8:20 AM, Jonne Soininen wrote:

> Hi everybody,
>
> this is a WG Last Call for comments on sending
> draft-ietf-v6ops-ent-scenarios-02.txt, "IPv6 Enterprise Network
> Scenarios" to the IESG for consideration as Informational:
>
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios 
> -02.txt

I think that the document has matured a lot, however
I'm a bit puzzled by section  4, and specially 4.2 & 4.3 that I found  
not very well
articulated.

4.2  IPv6 Tunnels to Encapsulate IPv4


   An IPv6 capable node, on an IPv6 link within an IPv6 routing domain,
   wants to communicate with a legacy IPv4 application.


==> I'm not sure how an IPv6 over IPv4 tunnel by itself is going to  
solve this,
        unless you assume a model like DSTM where the v6 node and  
applications
        are v4 aware,  but the infrastructure is not.... This is not  
spelled out in the scenario.

        In other words, I think 4.2 is not describing a scenario but  
showing a solution.



4.3  IPv6 only communicating with IPv4


   An IPv6 capable node wants to communicate with an IPv4 service, but
   the node is operating as IPv6 only.  In order to continue support for
   communications with IPv4 services an IPv6 to IPv4 translator or IPv6
   proxy is required.  Introduction of such software may prevent usage
   of end-to-end security trust models and applications carrying
   embedded IP addressing information.  Bi-directional establishment of
   connections might be difficult to achieve.


==> somehow similar comment, this is solution space, not scenario space.

So I believe that section 4 is not quiet ready and should describe the  
problem more,
that is, from what I understand, how to interoperate between v4 & v6  
services (not nodes),
or more specifically, how to access legacy v4 service.

the 3 sub-cases are IMHO:

a) v4 only or dual stack client app on dual stack node in dual protocol  
network accessing a v4-only service
  (solution hint: use the v4 stack.)

b) v4 only or dual stack client app on dual stack node on mono protocol  
v6 network accessing a v4-only service
    i.e. the network on which the client sits has no IPv4 native routing
  ( solution hint: use the v4 stack, but tunnel v4 over v6 to regain  
IPv4 connectivity)

c) v6 only client app accessing a v4-only service
   (solution hint: failure or translation or relay)


There is of course the reverse scenario, of legacy v4 clients accessing  
new v6 services.

The real challenge of this document is now to explain in each of the  
example scenarios which of those cases
really apply and thus MUST be solved, versus saying everything MUST be  
solved.

So, as a conclusion, I think that section 4 is not ready for  
publication.
Note: I think the rest of the document is. Would removing section 4  
entirely be an option?

	 Alain.