Subject: Re: Why?

From: [email-masked] (Noel Chiappa)
Date: Mon, 14 Mar 2005 19:37:28 -0500 (EST)

> From: Keith Moore <[email-masked]>

    >> yeah, it *is* easier to deploy first and then later make incremental
    >> modifications for scalability - if you like NAT.

    > You do have to build upgrade paths into the architecture if you want it
    > to last ... Making an architecture last is all about .. creating
    > interfaces for the rest of the system that can be stable across drastic
    > changes in technology.

But that's exactly what support of multiple addresses is - the key
architectural feature needed to make large-scale multi-homing work (within the
existing routing/entity-naming architecture, i.e. the one that IPv6 shares
with IPv4). I.e. it's the thing we need to have in the architecture to allow
the upgrade path you mention.

In thinking about this whole point of acceptance of the use of multiple
addresses, I came upon an interesting way to look at it all. It starts with
the supposition that it seems likely that one way people will do multi-homing
is to use a NAT box, and thereby restrict the knowledge of the multiple
different addresses (i.e. location-dependent "routing-names") to the border
of their system.

However, another way to look at this is to say that what they really want is
to configure their machines with only one identifier, one which is (mostly)
location-indepedent, and therefore serves mostly to identify them. They are
quite happy to then have those machines depend on another device, at the edge
of their network, to provide the location-dependent routing-names for their
machines.

At an architectural level, this is obviously basically the same as saying
that one configures machines with identities, and the machines pick up their
routing-names from devices within their network, which provide this data.
(This was pretty much exactly Mo O'Dell's enhancement on Dave Clark's basic
8+8 idea.)

So why people were and are so resistant to doing the latter is a more than a
little puzzling to me, because they are clearly happy to do effectively
exactly the same thing when a NAT box is involved.

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 Mar 2005 07:37:29 -0500

> architectural feature needed to make large-scale multi-homing work 
> (within the existing routing/entity-naming architecture, i.e. the one 
> that IPv6 shares with IPv4). I.e. it's the thing we need to have in 
> the architecture to allow the upgrade path you mention.

no, it's not - at least, not in anything resembling its current form.  
that stable interface that allows the apps to transparently survive 
changes in technology (much less ordinary changes in addressing or 
connectivity) is missing.

> In thinking about this whole point of acceptance of the use of 
> multiple addresses, I came upon an interesting way to look at it all. 
> It starts with the supposition that it seems likely that one way 
> people will do multi-homing is to use a NAT box, and thereby restrict 
> the knowledge of the multiple different addresses (i.e. 
> location-dependent "routing-names") to the border of their system.
>
> However, another way to look at this is to say that what they really 
> want is to configure their machines with only one identifier, one 
> which is (mostly) location-indepedent, and therefore serves mostly to 
> identify them. They are quite happy to then have those machines depend 
> on another device, at the edge of their network, to provide the 
> location-dependent routing-names for their
> machines.

I think that's a useful avenue of inquiry.  part of the problem is that 
the choice between addresses really does affect quality of service, and 
the requirements for QoS vary from one app to another.  so you need to 
push those preferences from the apps through the hosts to the edge of 
the network.  another part of the problem is the emerging tendency for 
mobile hosts to have multiple network interfaces and participate in 
multiple networks.  such devices resist the "one identifier" model.

> At an architectural level, this is obviously basically the same as 
> saying that one configures machines with identities, and the machines 
> pick up their routing-names from devices within their network, which 
> provide this data. (This was pretty much exactly Mo O'Dell's 
> enhancement on Dave Clark's basic 8+8 idea.)
>
> So why people were and are so resistant to doing the latter is a more 
> than a little puzzling to me, because they are clearly happy to do 
> effectively exactly the same thing when a NAT box is involved.

I'm not sure they're the same people in both cases.  but here's a 
litmus test - if there's not a token for any host A that host B can 
hand to host C at some arbitrary location in the network and have C use 
that token to quickly and reliably establish a connection to A (modulo 
access control) then the architecture is dysfunctional.  or to put it 
another way - if DNS or a similar name-to-locator (or 
name-to-identifier+locator) translation mechanism requires special 
knowledge to make it work, that isn't available to "ordinary" apps, the 
architecture is dysfunctional.

Keith

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 15 Mar 2005 08:44:47 -0500

> architecture is dysfunctional.

While I would agree with you, I think that horse has left then barn so
long ago that the door has rotted and fallen apart.  Just to give one
example beyond that of NAT's and RFC 1918 addresses --- consider
internal/external split DNS arrangements.  They are occasionally used
as a hack to get around the problem that we don't have a reliable
(location-specific) service location service that all applications can
be trusted to use.  (I.e., when you are attached to the home network,
use this set of MX records, but if your laptop is connected to the
IETF conference wireless network, use this *other* set of MX records.)
So given that the only tool network administrators have is the DNS,
there are tools which effectively use internal DNS views as a crowbar
to effectively turn (some) URL's into URN's.

It's ugly, and gross, and everyone who uses such a hack should be
ashamed --- including myself, since I found it was easier to use an
hacked split DNS setup for my home network instead of going around and
changing all of the applications I cared about.  

Does that mean that the Internet Architecture is dysfunctional?
Perhaps, but then again, I'm beginning to have a lot more sympathy
with the point of view that we all come from dysfunctional familieis;
the only question is how dysfunctional.

The real problem though is that because of limitations in the Internet
architecture that have been with us for decades --- and this goes
beyond whether or not addresses are 4 bytes or 8 bytes or 16 bytes,
and whether we have a host identifier and routing component in the
address --- we have this huge installed base of applications,
conceptual maps of how to solve problems in network administrators,
security policies at corporations that effectively dictate things like
NAT's, private address spaces, and split DNS setups, which is
extremely hard to overcome.  And we really expected IPv6, which after
all really only increased the number of addressing bits, to address
all of these issues?  How much like an engineering organization....

						- Ted

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 Mar 2005 09:31:36 -0500

>> hand to host C at some arbitrary location in the network and have C 
>> use that token to quickly and reliably establish a connection to A 
>> (modulo  access control) then the architecture is dysfunctional.  or 
>> to put it  another way - if DNS or a similar name-to-locator (or 
>> knowledge to make it work, that isn't available to "ordinary" apps, 
>> the architecture is dysfunctional.
>
> long ago that the door has rotted and fallen apart.

I think everybody will acknowledge that the existing IPv4+NAT+hacks 
network is a huge mess.  what I don't accept is that the existing mess 
will be incorporated into any possible future network architecture.  
people do abandon obsolete technologies - slowly at first, more quickly 
after the early adopters see the benefits.  I don't know many people 
cooking with wood stoves, using steam engines to power machinery, or 
cleaning clothes with a washboard these days.

(I wonder if anybody told Edison, when he started to sell electricity, 
that that horse had already left the barn?  or maybe this is a 
marketing problem in that people implicitly expect the network of 
tomorrow to look a lot like the one today?  to me it seems that the 
Internet has drastically changed every two years or so since it began, 
so I expect it to keep changing for awhile.  for instance, I don't 
expect the general-purpose PC to be the dominant kind of terminal on 
the network for much longer.)

> Just to give one example beyond that of NAT's and RFC 1918 addresses 
> --- consider internal/external split DNS arrangements.  They are 
> occasionally used as a hack to get around the problem that we don't 
> have a reliable (location-specific) service location service that all 
> applications can be trusted to use.

one of the many problems with this is that DNS isn't in that category 
either.  actually I don't think it will ever be reasonable to expect 
all apps to use any particular service location service, whether or not 
it's location-specific.  (or maybe even especially if it's 
location-specific).  different apps have different needs.

>  (I.e., when you are attached to the home network, use this set of MX 
> records, but if your laptop is connected to the IETF conference 
> wireless network, use this *other* set of MX records.) So given that 
> the only tool network administrators have is the DNS, there are tools 
> which effectively use internal DNS views as a crowbar to effectively 
> turn (some) URL's into URN's.
>

without knowing why your laptop needs different MX records in different 
situations, I can't tell.

as for using split DNS, the only reason this appears to work at all is 
because you're only expecting to get a small number of apps on a small 
number of hosts to work in this scenario.

> the only question is how dysfunctional.

as you say, the question is how dysfunctional.  there's an important 
difference between limited hacks that are useful in isolated corner 
cases that only affect a few hosts, and expecting those hacks to be 
generally useful and widely deployed.

> all of these issues?  How much like an engineering organization....

well, at the time the IPng work was started, most of these problems 
were not nearly so obvious or widespread.    so I don't know how many 
of us expected it to address all of these issues.  clearly it does not. 
  on the other hand, these issues need to be addressed anyway, and it's 
easier to address these issues in an IPv6 world than in an IPv4 world.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2005 17:44:17 +0100

I think that the point this thread has got to is one that
the multi6 WG got to a couple of years ago, and has since
moved past: hence the shim6 proposal, which actually tries
to deal with deployed reality (BGP, and applications that treat
addresses as identifiers, for example), admits that some state
is needed to deal with multihoming, and intends to ensure
that this state is consistent at the two ends.

Perfect? No. Better than doing nothing? I think so. Looks
rather like double-ended NAT? Yes.

    Brian