Subject: Re: FW: Review of draft-ietf-v6ops-nap-02.txt

From: Tim Chown <[email-masked]>
Date: Mon, 12 Jun 2006 13:39:36 +0100

On Fri, May 26, 2006 at 09:05:56AM -0700, Fred Baker wrote:
> FYI. Margaret's original message seems to have not made it to v6ops,  
> or at least through it to me and reportedly several of you.
> 
> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] On Behalf Of
> Margaret Wasserman
> Sent: Wednesday, May 24, 2006 7:06 PM
> To: [email-masked]'; [email-masked]'
> Subject: Review of draft-ietf-v6ops-nap-02.txt
> 
> Hi All,
> 
> I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number of serious
> issues with the document.  I realize that the Last Calls have already
> completed and that this document is on the agenda for this week's IESG
> telechat, but I consider these issues to be serious enough that they are
> worth raising as late objections.

Hi,

I think Margaret's objections boil down into four areas:

1) Some 'overenthusiastic' language.  Maybe some words can be toned down,
   I don't see a huge issue there, but it's a fair point if you want to
   get NAT advocates to read it all.

2) Renumbering.  This should get an extra section I agree.  Note there
   are now movements towards IPv6 PI swamp space.  There are different
   classes of network for which renumbering varies in complexity.

3) Untraceable addresses and host routes - I agreed at the time that these
   seemed impractical to use.

My own feeling is to progress the document, toning down some words, adding
some clarification on renumbering, and pushing (3) to a theoretical appendix.
There's been general consensus on the messages of the draft, and I have seen
good feedback on it.  A major overhaul isn't needed.

tim

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Jun 2006 10:15:54 -0700

On Jun 12, 2006, at 5:39 AM, Tim Chown wrote:
> A major overhaul isn't needed.

I agree. Can we get the discuss comments and other review comments  
addressed by the 26 Jun cut-off date?

Do we nee to discuss this in the coming meeting? I would guess not,  
but I'm willing to give you a slot if you want one. I'm supposed to  
post an agenda by next Monday.

Still looking for the update port-scanning document to put it into  
WGLC...

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 13 Jun 2006 19:49:22 -0700

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.

Tony

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=5
2102
I put in an arbitrary 50k number as a scale reference. 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.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=5
2051
This one is somewhat all over the place. Lack of understanding of the
technology by an IESG member should not override a working group consensus.
2.2 has already been reworked. 
3.4 does not oversell if you understand how MIPv6 really works. 
4.2 -2 does not oversell IPsec, it simply states the real situation. 
4.3 has additional text, though this is one where the IESG has lost the
context of this being wrt a nat deployment. 
4.7 the comments here are just wrong because it already did cover the points
and there was already a forward reference, it just didn't specify 6.4 as the
section number.
I did not buy all of Margaret's personal views though clarifications were
added. 
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. 

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_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. 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fred Baker
> Sent: Monday, June 12, 2006 10:16 AM
> To: Tim Chown
> Cc: [email-masked]
> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt
>

---

From: "Margaret Wasserman" <[email-masked]>
Date: Wed, 28 Jun 2006 15:40:02 -0400

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.

> 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.

> 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?

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Jun 2006 13:00:26 -0700

Radia and Dave:

There is a dispute going on regarding the scalability of topology  
hiding by what amounts to IS-IS level 1 routing (identifying hosts in  
a multi-LAN network by their host identifier and using a common  
subnet ID for the domain). Do you know of available documentation of  
IS-IS level 1 routing and its tested scalability?

As Radia knows, this question is also being looked at in IEEE 802.1,  
which presumes that there is only a single multi-LAN-LAN, and that  
MAC addresses are used to route within it.

Fred

On Jun 28, 2006, at 12:40 PM, Margaret Wasserman wrote:

> [snip]
> is a valid and scalable technique.

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Jun 2006 13:28:41 -0700

Tony, do you have any comment on this?

My initial thought is to identify the things that impact scalability,  
and make recommendations - perhaps in a separate document or in an  
appendix to this one. This comes from Dave's comments regarding "a  
gigabyte of more of memory, gigE's for interfaces, and multi-CPU  
route processors." While routers most certainly exist that have this,  
such routers are not found on the shelf at Fry's...

On Jun 28, 2006, at 1:19 PM, David R Oran wrote:
> On Jun 28, 2006, at 4:00 PM, Fred Baker wrote:
>> Radia and Dave:
>>
>> hiding by what amounts to IS-IS level 1 routing (identifying hosts  
>> in a multi-LAN network by their host identifier and using a common  
>> subnet ID for the domain). Do you know of available documentation  
>> of IS-IS level 1 routing and its tested scalability?
>
> Nothing recent. Tony Li did some testing with IOS ISIS and host  
> routes about 10 years ago which as I recall scaled to about 10**4  
> as opposed to 10**3. This was on much wimpier boxes than we have  
> today and the details are lost to me in the mists of time.
>
> My intuition is that 10**3 is very low, even with moderately high  
> updates rates due to host movement (Tony was looking into host  
> routes as a host mobility solution). It would be useful to add him  
> to this thread.
>
> I'm not close to this stuff anymore so appropriately de-rate my  
> opinion, but 50K host routes in an ISIS area does not sound the  
> least bit scary to me on today's boxes with a gigabyte of more of  
> memory, gigE's for interfaces, and multi-CPU route processors.
>
>> As Radia knows, this question is also being looked at in IEEE  
>> 802.1, which presumes that there is only a single multi-LAN-LAN,  
>> and that MAC addresses are used to route within it.
>>
>> Fred
>>
>>> 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.
>>> [snip]
>>> 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.
>>

---

From: "Margaret Wasserman" <[email-masked]>
Date: Wed, 28 Jun 2006 17:17:16 -0400

Hi All,

As I understand it, there is a current proposal in the v6ops WG (in
draft-ietf-v6ops-nap-03-draft0.txt) to publish the following recommendation:

   There are other possible scenarios for the extreme situation when a
   network manager also wishes to fully conceal the internal IPv6
   topology.  In these cases the goal in replacing the IPv4 NAT approach
   is to make all of the topology hidden nodes appear from the outside
   to exist at the edge of the network, just as they would when behind a
   NAT.

   o  One could use explicit host routes and remove the correlation
      between location and IPv6 address.  In the figure below the hosts
      would be allocated prefixes from one or more logical subnets, and
      would inject host routes to internally identify their real
      attachment point.  This solution does however show severe
      scalability issues and should be limited to uses with
      substantially fewer than the maximum number of routes that the IGP
      can support (generally about 50,000).

[...snip...]

                             Internet
                                 |
                                 \
                                 |
                       +------------------+
                       | Simple Gateway   |  Logical subnet
                       | or Home Agent    |-+-+-+-+-+-+-+-+--
                       +------------------+  for topology
                                 |           hidden nodes
                                 |
               Real internal  -------------+-
               topology       |            |
                              |           -+----------
                   -----------+--------+
                                       |

The more I think about this proposal, the more questions arise, such as:

(1) Do we really mean that the router in this picture would be a "simple
gateway or home agent"?  I don't think that is consistent with the idea that
it could handle 50,000 routes.  Or that it would run an IGP, for that
matter.

(2) What mechanism would hosts use to inject host routes into the IGP?  How
is that secured?

(3) How will local nodes know to use topology-specific ULA addresses for
local communication?  What happens if they don't?  Could this result in a
large amount of internal traffic bouncing off of the "simple gateway or home
agent"?

(4) How does this interact with multicast traffic and ND.  Can a node on the
"logical subnet" send a link-local multicast packet on the logical subnet
and safely assume that it will reach all of the nodes on that subnet and no
one else?  If not, how does this interact with ND?  

(5) Would autoconfiguration be used on the logical subnet, or would hosts be
expected to get those addresses through other means?

(6) What advantages (if any) does this approach have over using a single
subnet internally and using L2 switches and VLANs to handle internal packet
delivery?  What disadvantages does it have when compared to that approach?

(7) How does this proposal relate to the work currently underway in the
TRILL WG?

If we decide that we actually want to make this recommendation, I'd prefer
that we remove it from this document and make this recommendation in a
separate document that covers the scalability issues, the answers my
questions above, and any other factors that may affect the applicability of
this solution.

Margaret

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Wednesday, June 28, 2006 4:00 PM
> To: Margaret Wasserman; Dave Oran; [email-masked]
> Cc: 'Tony Hain'; 'Tim Chown'; [email-masked]
> There is a dispute going on regarding the scalability of 
> topology hiding by what amounts to IS-IS level 1 routing 
> (identifying hosts in a multi-LAN network by their host 
> identifier and using a common subnet ID for the domain). Do 
> you know of available documentation of IS-IS level 1 routing 
> and its tested scalability?
> 
> 802.1, which presumes that there is only a single 
> multi-LAN-LAN, and that MAC addresses are used to route within it.
> 
> Fred
> 
> > presentation would seem to indicate.  His presentation 
> indicates that 
> > flat
> > free to check with Alex, though, as he certainly has more 
> > understanding of IGP scaling than I do.
> > [snip]
> > hiding, I think that the WG needs to do the analysis to 
> determine that

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 30 Jun 2006 12:37:16 -0700

Margaret, 

The text sent out on 6/13 was mid-edit session, basically looking to get
comments about the tone changes wrt marketing. The completed edit is
attached with the diff, though I have not passed this by the other authors
yet. I had planned to do that when I finished today, but your note appeared
to need a prompt response so you all get it at once.  

I made a number of grammatical changes and reordered some areas to make the
points clearer. Most of the marketing comments are gone, but in their place
is a statement that points out that most users of nat do not evaluate the
technical trade-offs and are not even made aware of the problems they will
encounter. I also changed the tone in some areas from one of offering a
choice between approaches to one that explains how those approaches work.
The 'offer' tone appears to have left the IESG with the perception that the
approaches were speculative.

One thing to highlight here though is that there appears to be an
expectation that this document is a BCP, when all along it has been
informational. If a BCP is the goal then substantial changes will be
required. As information, it covers the range of approaches that people need
to be aware of. 

The portability you reference below is not a nat feature. The only 'real'
advantage to nat is the expansion of the address space. The reduction of
impact on the routing system has more to do with insistence on ISP based
aggregates that would go away with other aggregation units. Unfortunately
people prefer a challenge and would rather engineer a non-deployable
work-around to a problem-of-choice than discuss the fundamental issues or
alternatives. 

I expect there will need to be some discussion in the WG to make sure it
covers the issues before we present this to the IESG again, though I do
believe it addresses all the comments.

Tony

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2006 12:40 PM
> To: 'Tony Hain'; 'Fred Baker'; 'Tim Chown'
> Cc: [email-masked]
> Subject: RE: Review of draft-ietf-v6ops-nap-02.txt
> 
> 
> 
> Hi Tony,
>