Re: draft-pouffary-v6ops-ent-v6net-01

[Brian E Carpenter <brian@hursley.ibm.com>]

Tim Chown wrote:
> 
> A few casual comments on v6ops-ent from the European 6NET perspective
> (international academic IPv6 testbed)

Actually, not all of us in 6NET would agree that it's "academic".
One of the objectives is to pilot e-business oriented apps,
i.e. enterprise type apps.

...
> 6.3 M3: IPv6 NAT to Communicate with IPv4
> 
>       1. A DSN wants to communicate with a legacy ENAD IPv4 ONLY service
>          or node.  EN policy is that IPv6 NAT should be used for this
>          communications.
> 
> - It would be nice not to use the phrase "IPv6 NAT" :)  Some general translation
> - mechanism is required, it may be at the network, transport or application
> - layer (i.e. NAT-PT, TRT or ALG when we discuss solutions).  To me, IPv6 NAT
> - suggests something else entirely, that we want to avoid.

Well, what is really wrong with the text is the choice of the word
"policy". Such a decision isn't policy, it's a specific technology
choice: use a network level solution rather than an application
level solution.

> 
>       4. Others ????
> 
> - IPv4 nodes inside or outside the enterprise may wish to initiate connections
> - to IPv6 services inside the enterprise.
> 
>    ***IMPORTANT Discussion for Design Team and Working Group*** Should
>    we recommend the following to the working group in the next draft and
>    discuss at the IETF Atlanta meeting with the working group the
>    following:
> 
>       1. The EN Design Team highly recommends that ENs not adopt the policy
>          in reference "1" above.
> 
> - When we come to solutions, yes, probably, but the scenarios document isn't
> - the place to push policy recommendations, imo.

Indeed, especially if you don't recommend an alternative solution. What we should
do here is simply describe solutions with their advantages and disadvantages.

While I'm talking, one thing I miss in the document is an analysis of
current scenarios (IPv4 scenarios) where enterprises have significant
problems and difficulties that more address space will solve. That
might suggest additional deployment scenarios.

...
> 
> 6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4
> 
>    This ENPT is a method to deploy IPv6 and a method for transition.  An
>    EN that deploys DSNs as they adopt IPv6 are more assured that IPv6
>    and IPv4 interoperation will be possible between the two nodes or
>    services.  It also means for many legacy IPv4 nodes that they can be
>    upgraded to support IPv4 and IPv6, but not turn on IPv6 until the
>    IPv6 operational network has been verified to be interoperable and
>    secure.  It also means that both IPv4 and IPv6 can be supported by
>    the nodes that transition to IPv6 and then will be able to
>    communicate with IPv4 nodes using an IPv4 network infrastructure.
> 
> - the big problem of course is then assumptions about which services are
> - available via which IP versions (just look at the SMTP MX considerations
> - draft for example).

Well, in general there is the question of what to do when
only some applications have been ported. Is it better to
wait, to use application proxies, to use BIA, or what? We need the 
advantages & disadvantages for each of these approaches - these
are just as important as network level approaches.

...
> 7.5 Applications and APIs
> 
> This will be discussed in the next draft.

Good, but this should not be separated from the network level
mechanisms; the application level techniques need to be considered
in parallel with mechanisms M1 through M7.

    Brian