-----Original Message-----
From: Margaret Wasserman [mailto:margaret@thingmagic.com]
Sent: Wednesday, June 28, 2006 12:40 PM
To: 'Tony Hain'; 'Fred Baker'; 'Tim Chown'
Cc: v6ops@ops.ietf.org
Subject: RE: Review of draft-ietf-v6ops-nap-02.txt
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?