[ietf-v6ops-nap-01.txt] Proposed Resolution of Issues [1 - 10]

["Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>]

Issue list to be found at: http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm

Issue 1:

The idea is that the NAP draft will be Informational and hence i would not
like to see it as Normative reference. It would however be good to see
the draft from Tim published.

Issue 2:

 Precisely *not*. A commodity boundary box can be configured to
do all this without NAT - that is exactly why we have always said
that the longest allocation by an ISP should be a /64

Isssue 3:

Firewalls can do more as explained in the section, however the intention
of s2.2 is to speak on the NAT vector as when used on a firewall and not to
analyze all functions of the firewall.

Issue 4:

I'm unsure on how to interpret this issue so i could potentially integrate 
in the
text if relevant.

Issue 5:

A solution without a NAT can provide indeed user/application tracking and
that is amongst other concepts what the draft is about.

Issue 6:

from the issue

<snip>
I am not sure why port mapping makes things more difficult - the
mappings may be *finer* grained allowing *better* tracking
<end snip>

I don't completely agree that the mappings are *finer* grained or allow 
*better*
tracking. My believe is that in both instances the available tracking 
information
is identical as in both cases there is similar information.
The difference is in the translations-slot and how the mapping list is 
constructed.
One uses a mapping (assume traffic being sent from inside to outside the 
local network)
purely based on IP addresses and keeping the source-port# unchanged, while
the NAPT has in addition the source-port# changed. Hence i believe that the
creation of a mapping list where two variables change (source IP address 
and source
port numbers) is more difficult to achieve then one where the only one 
variable
changes (source-IP address), so looking at this the text seems correct as 
it is.

Any other opinions?

Issue 7:

The comment mentioned is correct, however i don't feel that s2.5 is the right
place to mention this issue, as it is already mentioned in s2.7 and would
potentially create additional repetitiveness.

Issue 8:

This item was discussed on the v6ops alias. My understanding of consensus
was that it is widely used. Hence the text should remain unchanged for this 
issue.
(if there are stats out there available, then we could potentially add some 
if that
provides a stranger result?)

Issue 9:

Add context around the motivation on why multihoming:

s/highly desirable to be/highly desirable due to resiliency and 
load-balancing to be/

I believe the 2th para of the issue is covered by:
<snip>
to be connected to more than one Internet Service Provider (ISP) and to be 
able
to change ISPs at will.
<end snip>

Issue 10:

propose the following change of the text:

Original:
 Similarly, if two enterprise IPv4 networks need to be merged, it may
   well be that installing a NAT box between them will avoid the need to
   renumber one or both.  For any enterprise, this can be a short term
   financial saving, and allow more time to renumber the network
   components.  The long term solution is a single network without usage
   of NAT to avoid the ongoing operational complexity of overlapping
   addresses.

Revised:
 Similarly, if two enterprise IPv4 networks need to be merged
   and RFC1918 addresses are used, there is a probability to have
   address overlaps. In those situations it may well be that installing
   a NAT box between them will avoid the need to
   renumber one or both.  For any enterprise, this can be a short term
   financial saving, and allow more time to renumber the network
   components.  The long term solution is a single network without usage
   of NAT to avoid the ongoing operational complexity of overlapping
   addresses.


Kind Regards,
G/