Enterprise Scenarios WG Last Call Input Alaii Durand - Section 4

["Bound, Jim" <jim.bound@hp.com>]

Alain,

I think we should just remove Section 4 and it does not really affect
the specs objective.  We can discuss solution space for this space in
the analysis for sure.

I will send you offline mail on your diatribe below as we both have a
client that completely disagrees with your assumptions below on Ipv6
dominant networks for multiple reasons.  No point in using up IETF
cycles and will send you private mail.

Thanks for Your Input,
/jim

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