Re: stable addressing

[Iljitsch van Beijnum <iljitsch@muada.com>]

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.