Comments on draft-aoun-v6ops-natpt-deprecate-00

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

Hi,

I think this draft is a very good summary of the NAT-PT issues, and thus 
we are at a stage where we can discuss what action to take based on the
limitations of NAT-PT as described in the document.   

The key argument for proponents of NAT-PT seems to be that there are valid
"last resort" corner cases for which NAT-PT is the only solution.  It 
would be interesting to see a "usage of NAT-PT" text to make a case for
the defence, so to speak.  Interaction with legacy hardware is one example
of such a corner case.

Minor suggestions for the draft:

- I think the issues in Section 5 should be emphasised more strongly,
  and I recall others have expressed this view on the list.

- Privacy addresses might add an extra complexity for NAT-PT, if each
  node may have a number of active privacy addresses, and may need 
  to still receive communications to non-current privacy addresses that
  have been used in the past, e.g. where the node generates a new 
  privacy address each 24 hours, but still listens on "past" addresses.o
  (I think the NAT-PT + RFC3041 issues need to be thought out, and
  included in this text.)

- Also cite RFC2993 (Architectural NAT Issues) ?

- The NAT-PT issue list is interesting in that it can also be used to
  measure transport or application layer proxying limitations (which
  may also differ in aspects such as raw performance/throughput, but
  that I think is not in scope here).   Some issues are generic with
  any layer translation, e.g. single point of failure.

- There has been some usage of NAT-PT back-to-back to connect IPv6
  only islands across IPv4 only networks.

- A typo "appplied" in the Introduction

Cheers,
-- 
Tim