RE: Review of draft-ietf-v6ops-nap-02.txt

["Margaret Wasserman" <margaret@thingmagic.com>]

Hi Tony,

> I had done some updating before the last IESG call & round of 
> comments. The working draft is attached along with a diff to 
> the -02 version. As always comments are welcome. I am not 
> sure this needs a WG slot, but if someone really wants one I 
> am sure we can figure out which one of us can lead the 
> discussion. Below are the comments I sent to the authors 
> about the IESG discuss items.

I think it might be useful to discuss the IESG comments in more depth,
either on the list or in the WG meeting.  I realize that you have made
changes to address some of the comments, but I think that the WG has to
decide what to do (if anything) about the substantive issues that you have
not yet addressed.

> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_comment&id=5
> 2102
> I put in an arbitrary 50k number as a scale reference. 

50K is an order of magnitude higher than the analysis in Alex Zinin's
presentation would seem to indicate.  His presentation indicates that flat
routing will only scale to something on the order of 1K nodes.  Please feel
free to check with Alex, though, as he certainly has more understanding of
IGP scaling than I do.

> That 
> text could be expanded to discuss protocol specifics, 
> topology, and churn rate as hinted by the reference, but that 
> somewhat misses the point. "The technology does work with 
> scale limitations", is the bullet that the IESG appears to be 
> missing by essentially asking for a tutorial on igp 
> engineering. It might be better to put in a range of 
> something like 5k-50k to highlight the point that this is not 
> a hard limit without having to discuss the details of why.

If this document is going to recommend doing flat routing for topology
hiding, I think that the WG needs to do the analysis to determine that this
is a valid and scalable technique.  I would prefer that we just took it out
(perhaps considering a separate document to describe this technique if we
really think it is worthwhile), because this is an informational document
and I don't think it is the best place to specify a new operational
recommendation.  BUt,  if we do decide to leave it in, then we need to
document it in enough detail for readers to know when it is (and is not)
applcable.

> I did not expand on renumbering as Thomas requested. It is 
> not clear to me what he wants beyond referencing rfc 4192. 
> The second paragraph of 2.5 could be expanded, but that is 
> not the focus of the section. The second paragraph of 2.7 
> could be expanded, but would seem to loose context. It sounds 
> like he wants a statement like 'renumbering is hard in IPv4' 
> as justification for nat. 

NAT has real (not just perceived ormarketing-invented) advantages in the
area of address portability.  At this point, we do not have mechanisms in
IPv6 that provide a similar function although SHIM6 may help.

> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_comment&id=5
> 1234
> This was covered by the edits, and additional background 
> explanation was in the message I sent to the IESG on 5/26. 

Did you cc: the WG on that message?  I don't seem to have received it.

You made several changes based on my review comments that look good to me.
Thank you!

However, you don't seem to have addressed some of the concerns that were
raised in my review.  I realize that you don't agree with all of my review
comments, but some people did agree with them on the list.  I guess I'd like
to see some further discussion before we simply decided that no changes are
warranted based on these comments.

In particular, I am still concerned about the following comments:

(1) Thomas' comments on renumbering, combined with my comments on providing
a more balanced view of the real benefits of NAT:

> There are at least three other _real_ benefits of NAT boxes.  
> While I hold with this document's position that these benefits 
> can and should be realized in other ways in IPv6, I do not think 
> it is factual or helpful to argue that they don't exist.  Those 
> benefits are:
>
> (1) Avoiding the reliance of internal network number on externally 
> allocated numbers.  AKA not having to renumber when you change ISPs 
> or when ISPs change address allocation strategies.
>
> (2) Hiding internal topology from external communicants.
> 
> (3) Avoiding the establishment of unauthorized inbound connections.
> While this NAT side effect can also cause problems, it does provide 
> the real benefits of a stateful firewall.

(2) I think that this portion (in section 4.1) still needs some work.  Let
me know if I am missing something here:

>    It should be
>    noted that the address selection policy table in end-systems needs to
>    be correctly set up so that true global prefixes are distinguished
>    from ULAs and will be used for the source address in preference when
>    the destination is not a ULA.
>
> Unless one takes steps to actively screw this up, a globally routable 
> destination address will always have a longest-prefix match with a 
> globally routable source and a ULA will always have a longest-prefix 
> match with a ULA.  So, the last sentence is unnecessary and somewhat 
> misleading.
>
> The tricky part is making sure that the node uses the right destination 
> address -- a ULA for local traffic and global address for non-local 
> traffic.  This will generally require the use of some type of split DNS, 
> with ULAs returned internally but not externally.

(3) Although you made changes based on my comments on section 4.1, bullet 3,
you have not completely addressed by comment.  We are essentially declaring
that something will not be a problem if the IIDs are randomly distributed
while ignoring the fact that they won't be.  If we are trying to indicate
that administrators should override the default mechanisms for IID
autoconfiguration to provide random IIDs, I guess we should say that.
Otherwise, we should understand that the IIDs will not be randomly
distributed, so the math later in this section does not apply.  

(4) Section 4.6 has been updated based on discussion, but it now says:

   IPv6 provides sufficient space to completely avoid the need for
   overlapping address space with the total possible addresses being
   340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38).
   Since allocations in IPv6 are based on subnets rather than hosts a
   more reasonable way to look at the pool is that there are about
   17,293,822,569,102,704,640 (17*10^18) unique subnet values where
   sparse allocation practice within those provdes for new opportunities
   such as .

The last sentence above is apparently truncated.

(5) I still don't see any justification for this statement:

>   o  On a local network, any user will have more security awareness.
>
> IPv6 will make users more security-aware?  What does this mean?