Subject: RE: stable addressing

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 20 Apr 2004 09:35:25 -0700

>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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 Apr 2004 01:50:48 +0200

On 20-apr-04, at 18:35, Fleischman, Eric wrote:

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

Which assumptions in particular?

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

[...]
   "In any case, end users today are not (in the general case) dependent
    upon the Internet to support their business processes."
[...]

:-)

I agree that the assumption that we all share a big, happy, fully 
connected address space has little to do with today's reality. I doubt 
that many people consciously subscribe to this view, but it's so 
permeated through the IETF's collective subconsciousness that we still 
act on this assumption a good deal. (The fact that a decent alternative 
architecture isn't apparent doesn't help of course.)

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

This is a very complex problem. Just a few random notes:

- It takes a good deal of magic to make interdomain routing work at the 
best of times. Without aggregation this magic is going to be very black 
indeed.
- If we allow deaggregation for fortune 1000 companies, what do we tell 
company 1001?
- Readdressing 300k devices is entirely trivial if DNS names and 
address filters aren't an issue.
- Address filters aren't an issue if we can use different addresses for 
internal and external use.
- Selecting the "right" address when more than one is available is an 
unsolved problem.

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

Owning some address space isn't the problem. Having the rest of the 
world make their packets find it is. Suppose you got a portable /32 
worth of IPv6 address space. Would that solve your problem? Or would 
you want/need to announce more specifics throughout the world for 
different offices?

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

Current wisdom is that the security that NAT offers can also be gained 
through the use of a stateful firewall. However, IPv4 security issues 
don't automatically translate into IPv6 security issues. The continuous 
scanning and probing background noise that is present in IPv4 won't be 
much of an issue in IPv6 because the likelihood of hitting a live 
address is too small to even bother for an attacker.

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

This means you must effectively hide the use of NAT from the people you 
communicate with, as it is unlikely that your buying power also extends 
to them. This will severely limit the number of applications you can 
use behind such an IPv6 NAT box.

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

Despite the fact that NAT is as good as ubiquitous in IPv4, including 
both the networks of the largest companies in the world and something 
like half the residential internet users, it still manages to break 
applications. This can only be worse in IPv6 as much fewer people will 
be running NAT so the demand for workarounds will be less.

But we're getting ahead of ourselves. There are many proposals on the 
table, and a good number of them make NAT unnecessary.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 27 Apr 2004 07:29:48 -0700 (PDT)

Eric,

Some clarifying questions about this to helpme understand what you see
as the requirements:

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

The example shows hiding an individual IP address which I understand
(and is easy to do using the larger IPv6 address space).
Do you also care significantly about hiding the subnet numbers i.e.
prevent an external entity from comparing bit 49 through 64 in two
of your IPv6 addresses to see if they are located on the same subnet?

Some multihoming proposals (such as NOID) use the DNS to provide the
mapping between the set of IPv6 addresses assigned to a node.
Would such an approach cause a problem for hiding the Oracle server
in your example? Couldn't the Oracle server be assigned an obfuscated
domain name (<very long string of random digits/characters>.example.com)
and only your partners would be told the domain name to use?

   Erik

---

From: [email-masked]
Date: Tue, 27 Apr 2004 14:36:10 -0400

On Tue, Apr 27, 2004 at 07:29:48AM -0700, Erik Nordmark wrote:
> 
> Couldn't the Oracle server be assigned an obfuscated

I don't think this would fly since anyone (with sufficient 
motivation, boredom, whatever) on the path along which DNS
queries traveled (partner --> root servers and back, partner
--> example.com public dns server and back) would see the
obfuscated name travelling on the wire.

If hiding a particular server is required, why not give it
a site-local address, and then just forward the particular
TCP port that it uses using an application layer proxy? UDP
services are of course trickier...

But I don't quite understand what NAT has to do with multihoming.
Multihoming has to do with making addresses directly reachable
via multiple paths. NAT has to do with hiding unreachable
addresses behind reachable ones. Aren't these two things 
orthogonal?

-w
-- 
One day, a student asked a master, "Master, there is conflict between the
suits and the sysadmins. Which group has the Zen nature, and which group is
grieviously disturbing the stillness of the Tao?" And the master said nothing,
but installed an operating system. And the student was enlightened.
    - A.S.R. quote (Anthony DeBoer)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Apr 2004 11:48:24 +0200

> addresses behind reachable ones. Aren't these two things 

Speaking as a well-known NAT hater, I have to say that if a site
is hidden behind a NAT router that has connectivity to two
ISPs, site multihoming (without session survival) is clearly
straightforward. The router simply starts NATting to the other
ISP, which breaks existing sessions but moves new sessions to
the new ISP. No host inside the site knows that anything has changed.

     Brian

---

From: Geoff Huston <[email-masked]>
Date: Wed, 28 Apr 2004 20:58:50 +1000

At 07:48 PM 28/04/2004, Brian E Carpenter wrote:
>>addresses behind reachable ones. Aren't these two things orthogonal?
>

I'm not sure how we are so far down this alleyway. I understand the issue to be
"If you are going to base an endpoint identity on a locator, then this is a
restatement of the PI / PA problem, but perhaps in a more complex fashion
as you are now attempting to NIT rather than NAT at the edge." The take I get
from this is that there is a sector out there that would be more comfortable
in drawing identity tokens from a pool that is not aligned with network 
topology.
This may point to a preference from this sector to use of identity token values
that are opportunistic (a la HIP), DNS FQDN related, or a separately
allocated token space. In such a space its not even clear to me that you need
to align individual identity tokens values within an administrative structure
(i.e. would you necessarily need all the identity tokens values to share
a common prefix? The question posed in the HIPRG BOF in Seoul pointed
to distributed hash trees as a means of reverse resolving unstructured
identity spaces, as I recall).

thanks,

  Geoff