Subject: RE: stable addressing

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 20 Apr 2004 11:26:06 -0700

>If an organisation wishes to continue with NAT, it might as well stick with
>IPv4 though?   What's the gain then from having IPv6?

Tim,

This is an excellent question. An organization may indeed strive to continue using IPv4, as I stated would probably be the case in RFC 1687 (see http://www.ietf.org/rfc/rfc1687.txt). However, there are many factors that also war against that position such as:

1) Apple has made IPv6 be its default deployment setting. Microsoft plans to do so in a future O/S release. Other vendors are expressing similar intentions. $$ is an important factor in influencing networking decisions.

2) Some governments (e.g., USA's DoD) are apparently enamored with IPv6. Should they eventually require that IPv6 be used to communicate with them, then those needing to communicate with them will comply.

3) As I mentioned in RFC 1687, should a "killer app" be deployed requiring IPv6, then the Fortune 1000 *will* deploy it. Having said this, I personally believe that virtually all of today's articulated advantages of IPv6 over IPv4 are either theoretically-true-but-not-operationally-true or else pure marketing hype. However, should this change, then the whole deployment algorithm changes. There is a lot of positive potential within IPv6 that hopefully will be leveraged (e.g., QoS, IPSec, the issues the Multi6 WG are addressing).

4) Dual stacks are a pain. It pains users, it pains ISPs, and it pains vendors. There are many reasons why the world as a whole will seek to simplify its computer and network deployments. If IPv6 flies then the world will probably standardize upon it. If it doesn't, then a modified IPv4 will probably remain king. It is currently too early to know how things will turn out. When I imagine what each alternative would probably look like in 2020, I hope that IPv6 will pan out.

--Eric

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 21 Apr 2004 17:44:59 -0400 (EDT)

> From: "Fleischman, Eric" <[email-masked]>

    > 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 .. in RFC 1687
    > .. Our 1993 view has not materially changed in the intervening decade

Thanks for reminding us of that. Reading it again was still educational.

    > we will *own* our own IP addresses.

Just out of curiousity, when you move an installation, do you demand to take
your street address with you, too?

Look, I understand that you have real issues and operational requirements
from your networking infrastructure. However, it would be useful if you could
explain what those are at a high level, rather than resort to what some
people (e.g. me) perceive to be inflammatory language (e.g. the above) about
engineering details (which are somewhat in the nature of symptoms, not
causes).

(I should point out that if small businesses - which have the *exact* same
characteristic that you point out in RFC 1687 - that their *business* is
usually something other than networking/computers - took the same attitude as
you display above, we'd be stuck. Fortune 1000 companies may we worthy of
portable addresses, but not every small company can have them *if the network
is going to work*.)

E.g. when you said: "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" that was more useful - although still not what
I'm really after. What I'm looking for are things like "we don't want to have
to reconfigure individual machines when we switch ISP's, because we have so
many, it would be an O+M nightmare".

So, I imagine that you have issues with security (e.g. you don't want people
to be able to figure out your internal topology), configuration, etc.
But it would be really helpful if we could find out more about what the roots
of your concerns are ("we can't reconigure 300,000+ machines"), rather than
the eventual impact given a particular design ("we own our addresses").

E.g. I'd like to hear more about what you can configure in each machine (can
you do any configuration at all, and if so, how often), what you feel you
need to configure (a machine name, a business unit connection, a physical
network location, whatever). I think people are starting to accept that the
architecture does not have enough name-spaces, but when it comes to figuring
out which ones you should have, and *what characteristics they should have*,
that kind of insight into *what the users need and can accept* is very
important.

Or, to use another example, your concerns ("we want to hide our networking")
rather than what you perceive as what you need to do it ("give us IPv6
NAT's").

Tell us what high-level goal you're trying to meet - not what low-level
engineering feature you're currently using to do it.

	Noel

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 22 Apr 2004 08:56:27 -0700

>Not that this question is really on-topic for multi6 but it would be 
>interesting to better understand what the requirements for companies 
>that insist on their own address space are. "Not being hostage by the 
>ISP" is one argument, but that often boils down to readdressing scare. 
>However, with many of the id/loc ideas that have been presented here, 
>readressing is becomes another issue to what we are used to today. 
>Anyone like to bite on this? Perhaps we should take this off-list 
>though.

Kurtis,

There are doubtlessly many metrics that can be used to determine whether a corporation or government should own its own IP addresses or whether they should be leased from some ISP. Some have suggested that this could be based on the address block size (e.g. /32 or /48 or some other number). Another metric could be business based: what is the size of an organization such that an ISP would be willing to contractually handle the routing to that corporation using IP addresses from another ISP?

Concerning readdressing, only a very small part of the problem with readdressing is the actual changing of a computer's address. The much larger problem is finding and modifying all of the other systems which are keyed to the old address. DDNS does this for DNS for dynamically addressed systems. However, most key services are statically addressed. Yet this misses the true point: how about the proxies, firewalls, gateways, and many other systems which may also need to be modified? As the IP Layer becomes fatter, the problem with readdressing grows substantially. 

Also, the identity problem again rears its ugly head here. If an entity has been so short sighted as to use IP addresses as computer identifiers, then a whole constellation of databases and directories will need to be modified.

--Eric

---

From: <[email-masked]>
Date: Fri, 23 Apr 2004 10:55:43 +0300

Noel,

> your street address with you, too?

Just a small comment on this.  One of the problems is that companies
already think that they own their address space; they don't want to
'lease' it from a service provider.  Prior to wide-scale use of IP inside
of companies, most corporate / enterprise networks used purely local
addressing based on Netware or whatever networking software they were using.
This is one of the reasons, IMO, that NATs are prevelent inside of 
enterprises - network admins did not need to apply a new paradigm
when designing intranets.  If we are suggesting that we take away
the percieved address-space ownership, then we should make a good case
for the benefits of doing so, otherwise the tendancy will be to use
some sort of private addressing with IPv6.

John

---

From: "Grovesteen, Harold" <[email-masked]>
Date: Fri, 23 Apr 2004 08:08:20 -0500

No, I don't take my street address when I move, but I do take my identity and identity has been eliminated in IPv6.  That is the problem.

My organization fits into Mr. Fleischman's description of those IPv4 multihomed organizations which can not ignore IPv6.  I see the schism too.  Thank you for your succinct observations.

Harold Grovesteen

-----Original Message-----
From: Noel Chiappa [mailto:[email-masked]]
Sent: Wednesday, April 21, 2004 4:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: stable addressing

	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 23 Apr 2004 11:54:00 -0400

You don't need NAT just a good firewall which you will need with NAT
anyway.
/jim 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fleischman, Eric
> Sent: Monday, April 19, 2004 7:35 PM
> To: Brian E Carpenter; Iljitsch van Beijnum
> Cc: Multi6 List
> Brian,
> For whatever it's worth, my Boeing coworkers and I currently 
> expect to maintain a Boeing-unique address space in IPv6 
> (such as we currently have for IPv4) which will not change 
> regardless of who our ISP may or may not be. I would be very 
> surprised if other Fortune 100 companies do not take a 
> similar stance since we view this stance to be entirely 
> logical: i.e., it is a refusal to be "taken hostage" by ISPs.
> 
> On the other hand, in support of your posting, we also don't 
> want outsiders to know about our internal networks. We 
> currently plan to handle this by deploying NATs for IPv6, 
> such as we currently do for IPv4 (i.e., like many other 
> Fortune 100 companies, we use NATs for security, not for 
> addresses). While I doubt if our security people are willing 
> to discard the use of NATs as a security mechanism, perhaps a 
> heavy dose of the logic found within your posting below would 
> cure them of that position (but I somehow doubt it)? 
> 
> --Eric
> 
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, April 16, 2004 7:26 AM
> To: Iljitsch van Beijnum
> Cc: Multi6 List
> Subject: Re: stable addressing
> 
> 
> Iljitsch,
> 
> > Things are different however for class 4. Here, renumbering 
> is not a 
> > realistic option. Even if renumbering the actual network 
> > infrastructure were to be doable, changing the associated 
> filters and 
> > related security setups is too much work to undertake at 
> regular intervals.
> 
> I would dispute this. All that changes is the /48 prefix, and 
> the normal case in IPv6 is to be running with several of 
> those simultaneously on any large site. Actually the filters 
> and internal routing setup will need to treat the top 48 bits 
> as don't care bits. So it seems to me that relatively simple 
> operational procedures can deal with prefix changes.
> 
> Nevertheless, I assume that all large enterprises will choose 
> to use a draft-ietf-ipv6-unique-local-addr-03.txt prefix for 
> internal traffic and some VPN uses. For external traffic I 
> assume they will use ISP-delegated prefxes, which is where 
> multi6 comes in. 
> 
>    Brian
> 
> Iljitsch van Beijnum wrote:
> > 
> > As a result of discussions elsewhere, my concern about lack 
> of stable 
> > addresses in IPv6 has increased once again. Let me first 
> define four 
> > fairly typical classes of future IPv6 users:
> > 
> > 1. single homed users
> > 2. "basement multihomers": (very) small networks with two 
> uplinks 3. 
> > content providers: lots of traffic, but not very many network 
> > components 4. enterprises: lots of subnets, lots of network 
> components
> > 
> > If we consider NOID-like solutions with DNS names and PA addresses 
> > only and no longer-lived identifiers or addresses, this should work 
> > quite well for classes 1, 2 and 3, as the amount of equipment that 
> > must be reconfigured when a new ISP is connected is 
> relatively small.
> > 
> > Things are different however for class 4. Here, renumbering 
> is not a 
> > realistic option. Even if renumbering the actual network 
> > infrastructure were to be doable, changing the associated 
> filters and 
> > related security setups is too much work to undertake at 
> regular intervals.
> > 
> > So how do we solve this? I'm assuming NAT is not an option. One way 
> > would be to create address space that isn't regularly routable, but 
> > can be automatically tunneled/aliased over regular PA space. The 
> > disadvantage here is that tunnel/aliasing setup must happen 
> prior to 
> > session establishement, which isn't all that great for incoming 
> > sessions towards these types of addresses, but presumably most 
> > sessions will either be outgoing or part of a longer-term 
> > meta-sessions so this shouldn't be as big a problem as with 
> classes 2 
> > and 3. Another problem here would be that even if the correspondent 
> > for the class 4 user doesn't actually multihome, they must still 
> > support the mechanisms in order to set up and use the 
> tunnel. Again, 
> > this might be a disadvantage we're willing to swallow as 
> the type of 
> > communication for class 4 is presumably limited to a subset 
> of the full internet.
> > 
> > (Obviously an enterprise with lots of internal stuff but 
> also highly 
> > visible stuff (think Cisco with their huge internal nework and also 
> > huge web presence) could use stable addressing for most of 
> its network 
> > and PA/NOID for the most visible parts.)
> > 
> > Another side effect would be the need for a registry of some kind 
> > where the initial mapping information can be found in order 
> to create 
> > tunneling/aliasing state.
> 
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - Brian E Carpenter Distinguished Engineer, Internet 
> Standards & Technology, IBM
> 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 23 Apr 2004 12:01:11 -0400

also there are three firewalls we are testing now on moonv6
www.moonv6.org and the DOD is testing it too.  Checkpoint, Netscreen,
and Cisco IOS firewall.  We have also tested E2E IPsec native IPv6
across the U.S. peerings and it works.  So products are appearing now.
IPv6 permits you to have E2E trust models or filters ones choice.  And I
speak with many Fortune 100 people and many of them want NAT gone and
prefer firewalls with global addresses which are optimized for
performance and implementation.  We will be soon adding to those tests
nets in China and Korea. 

My last mail on this as I don't get what this topic adds to the
multihome problem?  At least for me?

Regards,
/jim 

> Sent: Tuesday, April 20, 2004 12:49 PM
> To: Pekka Savola
> Cc: Brian E Carpenter; Iljitsch van Beijnum; Multi6 List
> >Why don't you just deploy proxy servers at the edge of your 
> network?  
> >It allows you to talk to the outside using local addresses, while 
> >disguising the internal topology as only the proxy servers' 
> addresses 
> >are known?
> 
> >Much better than deploying v6 NAT.
> 
> Pekka,
> 
> Thank you for your helpful posting. The use of proxy servers 
> is a good suggestion, since they can also be part of a larger 
> authenticated firewall solution. However, due to the sheer 
> number of the internal devices that need to be exposed in a 
> highly controlled manner (e.g., hundreds if not low-thousands 
> of devices), proxy servers aren't likely to be able to scale 
> to handle the job -- hence the use of authenticated NATs that 
> are associated with the firewall.
> 
> --Eric
> 
> 
> 
>

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 23 Apr 2004 09:19:25 -0700

It may be just me, but I think that the opacity (or lack thereof) of global addresses is directly relevant to the multihoming problem.

-----Original Message-----
From: Bound, Jim [mailto:[email-masked]]
Sent: Friday, April 23, 2004 9:01 AM
To: Fleischman, Eric; Pekka Savola
Cc: Brian E Carpenter; Iljitsch van Beijnum; Multi6 List
Subject: RE: stable addressing

Regards,
/jim

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 23 Apr 2004 09:57:05 -0700

> No, I don't take my street address when I move, but I do take my
identity
> and identity has been eliminated in IPv6.  That is the problem.

Actually, I know of at least one organization who might very well take
its street address if it moved, as long as it remains within the same
city. Just try to find a street plate numbered "One Microsoft Way"...

The point that Eric made is very real. Renumbering an organization has a
cost. Similarly, using multiple address prefixes inside an organization
has a cost. We may debate how large these costs are, but we cannot
assume that they are null. It is quite clear that these costs grow with
the size of the organization: it is definitely more expensive to
renumber 300,000 computers than 299,999. We may debate whether the cost
increase is sub-linear, linear or super-linear with the size of the
organization, but we cannot deny that everything else being the same, it
is monotonically increasing.

Using a single "portable" address eliminates the renumbering and
multi-addressing costs for the organization, but passes them to the
network. The cost for the network is the cost of maintaining an
additional prefix in the routing tables. In first approximation, this
cost is independent of the size of the organization. 

At that point, we should get a clear picture. Above a certain size, the
cost for the organization is larger than the cost for the network. It
turns out that large organizations are also large customers, which give
them some negotiating power. So, if we just let market forces act their
own way, we can indeed expect that very large organizations will acquire
a single portable prefix.

-- Christian Huitema

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 23 Apr 2004 12:14:08 -0400

The DOD has required the goal that all operations must be fully
transitioned to IPv6 operational by 2008.  New systems should begin to
be IPv6 capable today, unless a waiver is supplied with rationale. I can
send pointers to the public briefings with IPv6 from various processes
in place now to make this happen.  Attached is the memorandum from the
DOD.  The memoranda can speak for themselves attached.

It is not a matter of being enamored Eric it is a matter of superior
opearational capabilities to support the warfighter and save lives and
further support the efforts for net-centricity, which I assume as DOD
contractor your familiar with and the JFCOM directives too.

Again this really has nothing to do with Multihoming.

If any are interested I am doing a brief in June at the annual Army IT
conference on the benefits of IPv6 to DOD Net-Centricity and selected as
one of the speakers or I can provide you with my brief at Joint
Interoperability Test Command 14th Annual Interoperability Conference
this past March and pointer to public briefings where IPv6 is part of
all programs I saw presented.  So the DOD is bit more than the word
enamored with IPv6 as Eric stated.

Also Asia will be IPv6 operational extensively by 2005 and already has 9
million IPv6 production subscribers in Japan.  Not test beds.

What we have to do here is fix the multihoming problem or forces in the
market will fix it for us.  As is the case with the transition
mechanisms in deployment now not waiting any longer on v6ops.

Regards,
/jim 

> Sent: Tuesday, April 20, 2004 2:26 PM
> To: Tim Chown; Multi6 List
> This is an excellent question. An organization may indeed 
> strive to continue using IPv4, as I stated would probably be 
> the case in RFC 1687 (see 
> http://www.ietf.org/rfc/rfc1687.txt). However, there are many 
> factors that also war against that position such as:
> 
> 1) Apple has made IPv6 be its default deployment setting. 
> Microsoft plans to do so in a future O/S release. Other 
> vendors are expressing similar intentions. $$ is an important 
> factor in influencing networking decisions.
> 
> 2) Some governments (e.g., USA's DoD) are apparently enamored 
> with IPv6. Should they eventually require that IPv6 be used 
> to communicate with them, then those needing to communicate 
> with them will comply.
> 
> 3) As I mentioned in RFC 1687, should a "killer app" be 
> deployed requiring IPv6, then the Fortune 1000 *will* deploy 
> it. Having said this, I personally believe that virtually all 
> of today's articulated advantages of IPv6 over IPv4 are 
> either theoretically-true-but-not-operationally-true or else 
> pure marketing hype. However, should this change, then the 
> whole deployment algorithm changes. There is a lot of 
> positive potential within IPv6 that hopefully will be 
> leveraged (e.g., QoS, IPSec, the issues the Multi6 WG are addressing).
> 
> 4) Dual stacks are a pain. It pains users, it pains ISPs, and 
> it pains vendors. There are many reasons why the world as a 
> whole will seek to simplify its computer and network 
> deployments. If IPv6 flies then the world will probably 
> standardize upon it. If it doesn't, then a modified IPv4 will 
> probably remain king. It is currently too early to know how 
> things will turn out. When I imagine what each alternative 
> would probably look like in 2020, I hope that IPv6 will pan out.
> 
> --Eric
> 
> 
>

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 23 Apr 2004 13:21:21 -0400 (EDT)

> From: "Bound, Jim" <[email-masked]>

    > transitioned to IPv6 operational by 2008. ... So the DOD is bit more
    > than the word enamored with IPv6 as Eric stated.

Jim, I have an entire file full of projections from you (and other IPv6
proponents, to be fair) explaining how IPv6 was going to take over by time T
- almost all T now long ago history.

If you have some useful technical point to make, please make it. But let's
skip the IPv6 propoganda, OK?

    > market will fix it for us.

Do you have any information on how the market will "fix the multihoming
problem", if things here don't happen quickly enough? I'm very interested as
to what technical approaches you see happening in that case.

	Noel

---

From: "Grovesteen, Harold" <[email-masked]>
Date: Fri, 23 Apr 2004 12:46:17 -0500

Jim,

Having seen these documents before their public publication, I am well aware of this position.  While the DOD's adoption may have nothing the do with multihoming, as a multihomed organization that must communicate with DOD via the public Internet, it has everything to do with multihoming for us.  It was this very policy that caused my organization to start tracking multi6.

Harold Grovesteen,
Army and Air Force Exchange Service

-----Original Message-----
From: Bound, Jim [mailto:[email-masked]]
Sent: Friday, April 23, 2004 11:14 AM
To: Fleischman, Eric; Tim Chown; Multi6 List
Subject: RE: stable addressing

Regards,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 23 Apr 2004 17:08:02 -0400

Just responding to the peanut gallery like everyone else send the others
your bogus mail too and what I stated was not theory but what exists
today.  
/jim 

> Sent: Friday, April 23, 2004 1:21 PM
> To: [email-masked]
> Jim, I have an entire file full of projections from you (and 
> other IPv6 proponents, to be fair) explaining how IPv6 was 
> going to take over by time T
> If you have some useful technical point to make, please make 
> it. But let's skip the IPv6 propoganda, OK?
> 
> 
> Do you have any information on how the market will "fix the 
> multihoming problem", if things here don't happen quickly 
> enough? I'm very interested as to what technical approaches 
> you see happening in that case.
> 
> 	Noel
> 
>

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 23 Apr 2004 17:31:59 -0400 (EDT)

> what I stated was not theory but what exists today. 

I'm still interested in hearing whatever information you have on how the
market will "fix the multihoming problem", as you put it, if things here don't
happen quickly enough? I'm still truly interested as to what technical
approaches you see happening in that case.

	Noel