RE: stable addressing

["Fleischman, Eric" <eric.fleischman@boeing.com>]

>I'm disappointed that you bring up the N-word in the very same thread I 
>started in order to find a way to make it possible to use stable 
>addressing in a clean way.

Ilijitsch,

I am truly sorry to disappoint you and many other esteemed people that I deeply admire and appreciate by my posting. Fortunately, your thoughtful response is characteristic of the quality of your many other postings, providing important technical insights despite your disappointment. Thank you.

However, my own posting was not random but was rather due to an attempt to address the very large schism between the society in which I operate (Fortune 1000 companies) and the assumptions of the IETF leadership. Back in 1993 I described to the IETF the view from my knothole concerning IPv6 (then called IPng) in RFC 1687 (see http://www.ietf.org/rfc/rfc1687.txt). Our 1993 view has not materially changed in the intervening decade (except concerning the importance of OSI, which is today relegated to only a few specific environments (e.g., ATN)).

I personally understand, appreciate, and value why IETF leadership wants to aggregate routes in order to simplify global routing tables. However, the mechanism by which this is done must leave the Fortune 1000 companies with total control over our own address space otherwise our community will actively resist whatever approach you come up with. That's just a fact of life. (Readdressing 300,000+ devices is not trivial even using dynamic addressing -- it's just not going to happen for something as unimportant as switching ISPs.)

One reason I argued so strongly for stateless IPv6 autoconfiguration during the early '90s (i.e., a primary reason why we influenced IPng's address space grow from 8 bytes to 16) was to diminish the difficulty of massive readdressing. Therefore, we are currently uncertain as a community what the many changes found in IPv6 really means to us. Only recently have we begun to consider these issues. It is certainly possible to educate us as to why our historic IPv4 concerns are no longer appropriate for IPv6 -- indeed, we value learning from your wisdom and experience. However, such arguments need to be framed to address our own parochial concerns (i.e., the approach needs to be good for us, not just esoterically good for the community as a whole, since "IETF community" today is primarily ISPs and vendors, few of whom are intimately cognizant of the needs of either the Fortune 1000 or Governments).

There are two issues that the Multi6 community needs to understand about us and factor into its considerations:

1) We view ourselves to be much bigger than ISPs and we are the customer. We will *not* readdress our environment when we switch ISPs (unless the readdressing can be limited to the DMZ only -- readdressing small numbers of devices is not a problem for us: it happens all the time). That is, we will *own* our own IP addresses. 

2) Our security people are currently enamored by NATs as a security mechanism. I am aware of what the IETF's security people think about this and I myself have worked in the real time multimedia arena since the mid-90s, so you know what I think about it (i.e., NATs hinder real time communications). But there you have it: a community that currently plans to deploy NATs regardless. What would help people like me to educate our security people would be if the IETF came up with an Informational RFC for how we can do NAT-like things without NATs within IPv6. That is, our security people use NATs as a part of a larger defense-in-depth strategy to completely hide our internal networking environment from anybody on the "outside". E.g., we don't want people on the "outside" to be able to learn the IP address of an Oracle server in a data center. You may say, "Well, then just use local addresses for the vast majority of your population." Ah, but there is the rub, because there are compelling business reasons why select external people need to be able to access that Oracle server from the outside in a highly controlled manner (i.e., only authenticated users are given access to specific NAT-provided addresses). This is why our security people like NATs.

>Expect things to break if you do [use NATs]. In IPv4 software vendors are forced 
>to add NAT workarounds to their products because NAT is very widespread 
>in v4, but it's unlikely it will be in v6 as well, so I imagine there 
>won't be many NAT workarounds for IPv6.

As the vendors on this list could readily attest, we in the Fortune 1000 have a very long history of refusing to buy vendor products unless they alter them to be able to work within our environments. That is, if the Fortune 1000 continues to deploy NATs as a security mechanism, then IPv6 vendors *will* build NAT work arounds, just like they do today for IPv4. Again, that's just a fact of life.

Thank you for considering these issues as seen from my knothole.

--Eric