Subject: Re: The internet architecture

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Dec 2008 14:59:15 +0100

On 30 nov 2008, at 17:30, Keith Moore wrote:

> DNS names as
> currently used with A, AAAA, MX, and SRV records don't have the right
> semantics.  Part of the reason is that we don't distinguish between  
> DNS
> names that are used to name services (which may be implemented on
> multiple hosts, each of which has one or more A/AAAA records) and DNS
> names that are used to name single hosts (which may have multiple A/ 
> AAAA
> records for other reasons).  And the same DNS name may be used  
> sometimes
> as a host name (via A or AAAA records, say when using ssh) and  
> sometimes
> as a service name (via MX or SRV records).

Who cares?

Identification is a different problem from classification.

The same ambiguity exists with IP addresses, anyway. Or did you really  
think 74.125.77.99 is a single machine?
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Seery <[email-masked]>
Date: Sun, 30 Nov 2008 07:38:11 -0800 (PST)

Some questions have also risen WRT identity:

http://www.potaroo.net/presentations/2006-11-30-whoareyou.pdf

Is identity a network level thing or an application level thing?

----- Original Message ----
From: Noel Chiappa <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Sunday, November 30, 2008 7:11:59 AM
Subject: Re: The internet architecture

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

    > while it's true that IP addresses don't have the right semantics,
    > neither do DNS names.

What aspects of DNS semantics makes them inappropriate for this function?
If you could specify an 'ideal' endpoint name, what semantics and syntax
would it have? (Serious query, in case it wasn't obvious.)

    Noel

---

From: Christian Vogt <[email-masked]>
Date: Thu, 4 Dec 2008 10:35:58 +0200

Keith -

thanks for the careful elaboration.  I agree with you that it is very
important to consider the DNS-related issues that you identified when
designing methods that make new use of the DNS.  But note that the
hostname-oriented network protocol stack architecture, as proposed in
[1], does not change the semantics of DNS hostnames.  It continues using
DNS hostnames as an alias for a set of IP addresses.  And as today, for
this is does not matter whether the IP addresses in a set are from a
single host or from multiple hosts.  I therefore do consider the use of
the DNS in [1] feasible.

In a nutshell, the hostname-oriented stack architecture functions like
this:  It provides a new, backwards-compatible API through which
applications can initiate connections by specifying a pair of service
name and DNS hostname.  The service name is a well-known string
replacing the overloading of port numbers for the same purpose, and the
hostname maps to the set of IP addresses through which the service is
currently reachable. (There are further arguments to connection
initiation, but those are not relevant to this discussion.) Similarly, a
DNS hostname can be specified to filter incoming connections based on
the IP addresses that this hostname currently maps to. IP-address-
specific functions are centrally performed further down the stack so
that applications do not (necessarily) have to deal with them. This
includes hostname resolution, address translator traversal and
connectivity verification, address selection, as well as potentially
mobility and multi-homing support.

So the hostname-oriented stack architecture continues with the semantics
of DNS hostnames that we use today:  The IP addresses to which a
hostname points do not necessarily have to be of the same physical
machine, even though the terminology "hostname" may suggest that they
do.  This flexibility regarding the physical counterpart of a hostname
is actually an attractive feature:  It provides a convenient tool for
abstracting from the implementation of a particular service, which
generally is irrelevant to the host connecting to a service.  You are
right in that some applications may need to obtain a handle to a
specific service instance in order to be able to resume an intermitted
session.  And yes, a hostname-oriented stack architecture should permit
obtaining such a handle, just as it should support legacy applications
that want to know which IP address they are communicating with.

The three main benefits of the hostname-oriented stack architecture are
consequently as follows:

- Application programming becomes potentially easier.

- IP address changes, such as for mobility or multi-homing, do not
   disrupt ongoing sessions.  (This is the same advantage that
   identifier-locator split solutions provide.  Yet in the case of a
   hostname-oriented stack architecture, this is achieved without the
   extra complexity that a new level of indirection requires for
   mapping and security purposes, and which e.g. Mobile IP introduces
   through its concept of a "stable IP home address".)

- Transition to IPv6 no longer affects applications.

The reason for all of these benefits is that applications use DNS
hostnames exclusively and do not have to deal with IP-address-related
functions.  And still, the semantics and the use of DNS hostnames remain
as they are today.  And I hope this resolves your concerns.

- Christian

[1] Christian Vogt:  Towards A Hostname-Oriented Network Protocol
     Stack for Flexible Addressing in a Dynamic Internet,
     http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf

On Nov 30, 2008, Keith Moore wrote:

> I could have been a bit more precise and said that DNS names as
> In practice DNS names are often sufficient for establishing an initial
> association with a service instance (where we don't care which  
> instance
> we're associate with, as long as the name associates us with one
> instance of that service), but they're not sufficient for referral
> (where it actually matters which instance of a service we associate
> with, and talk to).
>
> Another part of the problem is that DNS names are not used  
> consistently
> from one protocol/service to another.  A DNS name can be a host, a
> service, a collection of email addresses, a collection of resources,  
> and
> several other things.  Some protocols use A or AAAA records and a  
> port #
> which is implicitly part of the name, other protocols have a "default
> port" which can be overridden if explicitly specified, and in other
> protocols the port number must be explicitly specified.  A few  
> protocols
> and services use SRV records.  Some services want to be zero
> configuration so they don't even have names, or the names that they  
> use
> are supposed to resolve differently depending on, say, network  
> location.
>
> It might seem like SRV records would provide an adequate mechanism for
> implementing endpoint names, but many protocols aren't specified to  
> use
> them (or specify a different mechanism for associating a name with an
> address).   SRV records are also awkward in that they constrain the
> names that can be associated with them, and they require port # and
> address to be specified in different places in the DNS hierarchy -  
> or at
> least, in different RRs.
>
> I'm often saying that DNS is often out of sync with reality.  There  
> are
> lots of reasons why this can happen.  One reason is that old  
> information
> which is cached can obscure the fact that the information is changed.
> This may happen because TTL was not well chosen.  It also happens
> because most things that use DNS records don't keep track of TTL, and
> the APIs that are usually used don't facilitate doing so.  More
> generally, TTL isn't always sufficient because often you don't know  
> when
> data will need to be changed.  And DNS doesn't have any way of  
> shooting
> down cached entries other than TTL expiration.
>
> Other reasons that DNS is often out of sync with reality are:  DNS
> servers tend to be managed by parties with a distant relationship to
> those managing hosts and services; configuration errors of several
> different types can cause queries to be routed to servers that are no
> longer being maintained; dynamic update is not universally used, etc.
>
> Could you use DNS names and protocols to build an adequate endpoint
> naming and resolution service?  Maybe, but I think it would be  
> necessary
> or at least appropriate to (a) define new RRs for this purpose, (b)
> define a new naming convention for use by endpoint names that puts  
> them
> in separate zones than for other names (similar to that done with  
> SRV),
> and do that in such a way that it's convenient for those zones to be
> managed by the same parties that manage the endpoints themselves, (c)
> provision servers for use in answering queries for endpoint names,
> differently than for "normal" DNS names, (d) define new APIs for  
> coining
> new endpoint/instance names that can be used by applications to define
> new instances on the fly and to maintain their name to location
> mappings, and which generate and distribute dynamic update credentials
> for use with those endpoint/instance names to whatever application
> coined the names, (e) set TTL to a very low value and define a way of
> replicating the data that ensures it's always current (and if a  
> replica
> can't be sure that it's current it stops answering queries).  etc.
>
> as we discovered during the URN discussions, ideal naming is very
> difficult to pin down.
>
> I actually think that some profile of DNS _names_ could be "good  
> enough"
> and that it might not be worth the tremendous effort required to
> establish a completely separate naming system and hierarchy for  
> endpoint
> names.
>
> The bigger problem is that we have a large investment in  
> infrastructure
> and (even more importantly) in mindshare that says that DNS servers  
> are
> configured in such a way, provisioned in such a way, replicated in  
> such
> a way, maintained in such a way (and who maintains them), etc.  There
> are well-entrenched ideas about the granularity of zones and how they
> are delegated, and so forth.  There is a variety of practice about how
> to keep DNS in sync with reality regarding IP addresses (e.g. does the
> DHCP server update DNS or does the host?).  There is also split DNS to
> contend with.  All of this practice is adapted (if poorly) to dealing
> with DNS names as they are currently used, and using DNS names as
> endpoint ids would be a significant departure from this.
>
> I also think that if people in general haven't yet figured out how to
> make DNS as it is work reliably and be in sync with reality, they're
> going to have an even more difficult time making DNS service work well
> enough for endpoint ids.  But it might be that this is less of a
> protocol issue and more of a human interface issue.

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Dec 2008 14:48:17 -0500

> single host or from multiple hosts.  I therefore do consider the use of

Perhaps I wasn't "careful" enough in my elaboration, because in my mind
the problem with an API that tries to make all endpoint names be DNS
names is NOT a problem with some "new use of DNS", but rather with DNS,
and DNS names, as they are currently used.

> name and DNS hostname.  [...]

Yes, I did read the document before labeling that approach as naive.

> The service name is a well-known string replacing the overloading of
> port numbers for the same purpose, and the hostname maps to the set
> of IP addresses through which the service is currently reachable.

I'll never forget the time, back when I ran a mail server for a few
thousand users, that mail started dropping on the floor because a call
to getservbyname ("smtp", "tcp") inside sendmail started failing.

The call failed not just because some dim bulb at Sun decided that it
would be a good idea to take an API that originally did a flat file
lookup and reimplement it with an RPC to an NIS server that didn't share
fate with the caller (not to mention several other fragilities
associated with NIS).   On a deeper and more important level, the
failure happened because the whole idea of getservbyname (and similar
things, including the service name parameter to getaddrinfo) is
brain-damaged [*].  "smtp" is not better than 25, and adding an extra
layer of indirection just to make the port number be human readable is
not an improvement.  The SMTP protocol specification says that
connections are to be made to port 25, not to the port returned by some
indirection layer.

When a protocol specification says that a connection is to be made to
port 25, the correct way to write code to implement that specification
is to tell it to connect to port 25.  htons(25) doesn't fail nearly as
often as getservbyname("smtp", "tcp").

So I have to really wonder what you mean by "overloading" ports when
they're being used exactly for their intended purpose.

The right time to start insisting on use of ASCII endpoint names in APIs
(and this includes ports) is when destination hosts start using ASCII
endpoint names to demultiplex traffic.  Doing it anytime sooner is just
asking for more failures in a network that's already inexcusably fragile.

> Similarly, a
> the IP addresses that this hostname currently maps to. 

And that way, if someone can spoof the DNS response, or compromise the
DNS server, it becomes possible to bypass the filter.  nice.

I am not a big fan of using a source IP address as an authentication
token.  But if people are going to use them, they should do it right.  A
network admin who believes that all sources of traffic coming from
prefix X/Y are benign (or hostile), should specify specify his filters
in terms of permit (or deny) prefix X/Y and NOT in terms of some DNS
name which might or might not equate to prefix X/Y at some point in time
(depending on whether the network is up, the servers are up and
reachable and correctly configured, nobody is spoofing DNS or you have
all of your DNSsec configuration right, etc.)

And yeah, everybody complains about renumbering pain these days because
nobody has yet figured out how to make core routing scale without
renumbering from time to time.  But trying to make it easy to renumber
everything might just be optimizing for the wrong case, especially if
doing so compromises the reliability and security of enterprise networks.

> - Application programming becomes potentially easier.

only if (a) the application can reasonably avoid dealing with that
complexity (some can, some cannot) and (b) setting up a network
connection is the one of the more difficult thing the app has to do.
these days, in my experience, it's really far down on the list.

>   disrupt ongoing sessions.

uh, no.  not unless you're changing a lot more than the API (like the
transport protocols), and you're also providing a way to do secure
signaling of changes to endpoint addresses (consider that the endpoints
are often the last to know about such changes, and once their addresses
are changed they have no way of reaching their peers), and you're also
providing a way to make all referrals work in terms of the DNS - another
significant challenge, BTW.

solve these problems first and then your API might deserve serious
consideration.

> - Transition to IPv6 no longer affects applications.

wrong again, because (among other reasons) IPv4 only hosts will still
not be able to talk to IPv6 only hosts.

> as they are today.  And I hope this resolves your concerns.

I'm afraid you've made me even more concerned.

Keith

---

From: Christian Vogt <[email-masked]>
Date: Sat, 6 Dec 2008 22:46:55 +0200

Keith -

Up front:  Many of your arguments are based on the assumption that the
name-oriented stack architecture proposed in [1] is limited to a new API
between applications and the stack.  If that was so, then the benefits
of the new stack architecture would undoubtedly be limited.  But the
name-oriented stack architecture goes beyond providing a new API.  It
also comprises changes further down the stack to take maximum benefit of
the proposed new naming concepts.  A new API alone would only provide a
new layer of abstraction, which (here I agree with you) would fail to
yield a substantial improvement.  Therefore, please keep in mind when
reading my further responses below, that the proposed name-oriented
stack architecture is more than a new API.

And another general comment up front, regarding your arguments related
to DNS reliability:  Yes, I agree with you that this is important.  For
sure it must be keep in mind when transitioning towards an architecture
that implies a stronger dependency on name-to-address mapping.  The
reason why I am convinced that we will get this right is that (i) the
tools to ensure various levels of DNS reliability and security already
exist due to existing dependencies on the DNS, and (ii) which level of
DNS reliability and security to provide for, in each particular
deployment scenario, will continue to be under the control of the
respective name owners.  I.e., as today, the name owners will be able to
select a hosting provider with sufficient trustworthiness, or to set up
the necessary DNS infrastructure themselves, or even to use hard-coded
name-to-address mappings in hosts.

Of course, a name-oriented stack architecture does not /have/ to use the
DNS as its name-to-address mapping system.  As Stephane said earlier in
this email thread: There are alternatives.  Still, I have two reasons to
believe that the DNS would be appropriate in this regard:

(1) The DNS protocol enables exactly the flexibility in name-to-address
    mapping that we need:  It enables an abstraction from the physical
    implementation of a service -- i.e., from the details of which hosts
    run the service and where these hosts are located.

    Note that the term "hostname", which is common in the DNS realm, is
    misleading due to exactly this abstraction.  And I think it has led
    to misunderstandings also in our discussion.  This is why I am now
    using the term "name" instead.

(2) The DNS has very attractive operational and security properties:
    Since resolution is along administrative relationships,  the right
    incentives are in place for DNS to work correctly.  Of course, this
    doesn't mean that there is no room for improvement.  Certain
    existing administrative procedures may be inappropriate, as you say.
    And clearly there would be benefit to additional cryptographic
    protection such as through DNSSEC.  But the DNS provides a certain
    level of faithfulness already without such improvements, and this is
    in my opinion very attractive.

>> of
>> IP addresses through which the service is currently reachable.
>
> not an improvement.

There won't be a new indirection layer.  Instead, there will be a
separate name space for services, which will be distinct from the name
space for session identification.  Nowadays, port numbers are overloaded
for both, service identification and session identification.

And the separation of service identification and session identification
is going to have value.  An example is in IPv4 NAT'ing:  Here, the
overloading of port numbers limits the efficiency with which sessions
can be multiplexed onto the same IP address because the overloading
requires one of the two port numbers of a session to take a certain,
well-known value.  This problem is coming up nowadays in the discussions
around IPv6 transition, for which many techniques require aggressive
multiplexing of sessions onto the same IPv4 address.  You may argue that
this alone is not sufficient to motivate a change, but this would be a
separate topic for discussion.  Point in fact, the overloading of port
numbers does create problems, and eliminating the overloading would be
beneficial.

> often as getservbyname("smtp", "tcp").

The comparison between htons() and getservbyname() is inappropriate
here.  Again, the reason is that the proposed name-oriented stack
architecture uses service names directly to identify a service.  It does
not map the service name onto an overloaded port number, which is what
getservbyname does.  Therefore, there is no additional layer of
indirection that would constitute an additional risk for failure.

> asking for more failures in a network that's already inexcusably

Right, and again, this is exactly what the proposed name-oriented stack
architecture does.

>> Similarly, a DNS hostname can be specified to filter incoming
>> connections based on the IP addresses that this hostname currently  
>> maps
>> to.
>

So you are preferring to use IP addresses for identification?  In the
presence of mobility, multi-homing, privacy addressing, and renumbering?
Come on...

Be assured that the proposed stack architecture will come with
appropriate security measures to protect the binding between names and
IP addresses.  And as described in the paper [1], there is more than one
option:  DNSSEC is one option.  Manual configuration of the filtering
host with name-to-address mappings is another option.  The latter is
equivalent to the existing practice of configuring hosts with IP
addresses.

> doing so compromises the reliability and security of enterprise

While I wouldn't go as far as to say that the proposed name-oriented
stack architecture is /optimized/ for simplifying renumbering,
simplifying any form of re-addressing event is certainly an advantage of
the architecture, and simplified renumbering is included in that.
Re-addressing events are nowadays common, so considering them in the
stack architecture design is going to be a benefit.

> complexity [...]

... which it will.  This is explained in the paper, Keith.

> significant challenge, BTW.

Of course.  Were you seriously assuming that we would not consider these
things?  They are all addressed in the paper, and they will continue to
be considered very carefully as we work the conceptual ideas of the  
paper
into more and more detailed architecture and protocol specifications.

> not be able to talk to IPv6 only hosts.

To clarify:  Transition to IPv6 requires changes in three places -- in
the network, in host stacks, and in applications.  My statement above
relates to the fact that the proposed name-oriented stack architecture
would be an appropriate host stack change, which in turn would eliminate
the need for compliant applications to distinguish between IP versions.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Wed, 17 Dec 2008 14:06:48 -0500

> Is identity a network level thing or an application level thing?

Whatever.  All of the above.  There are many possible ways to use
identifiers, particularly for "session" (whatever that is, at whatever
layer) authentication and re-authentication.  The point to
locator/identifier separation is primarily to get identification-related
functions to stop depending on location-dependent tokens, i.e. locators.
 Once that's done, they can use anything they like -- and they do :-).

Scott

---

From: Dick Hardt <[email-masked]>
Date: Thu, 18 Dec 2008 09:10:38 -0800

> Once that's done, they can use anything they like -- and they do :-).

Agreed. They do.

That does not mean that identity should not be an important part of  
the internet architecture.

Note also that the paper above mixes identity with identifiers. They  
are not the same thing

-- Dick

---

From: macbroadcast <[email-masked]>
Date: Sun, 21 Dec 2008 22:25:00 +0100

> Note also that the paper above mixes identity with identifiers. They  

ok try this paper and tell me what you think ;)

http://pdos.csail.mit.edu/papers/uip:hotnets03.pdf

-Marc

--
Les Enfants Terribles - WWW.LET.DE
Marc Manthey 50672 Köln - Germany
Hildeboldplatz 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: [email-masked]
jabber :[email-masked]
IRC: #opencu  freenode.net
twitter: http://twitter.com/macbroadcast
web: http://www.let.de

Opinions expressed may not even be mine by the time you read them, and  
certainly don't reflect those of any other entity (legal or otherwise).

Please note that according to the German law on data retention,  
information on every electronic information exchange with me is  
retained for a period of six months.

---

From: macbroadcast <[email-masked]>
Date: Mon, 22 Dec 2008 02:48:46 +0100

hello,

thanks for your  reply, i prefer answering questions to the list, hope  
thats ok  for you.
Let me try  to answer your question with one sentence:

i believe that  "Kademlia "  [ 1 ] for example and the technologies   
mentioned in the  linked paper [ 2 ]
would fit the needs and requirements for a future proof internet.

meery christmas

Marc Manthey

[ 1 ] http://en.wikipedia.org/wiki/Kademlia
[ 2 ] http://pdos.csail.mit.edu/papers/uip:hotnets03.pdf
--
Les Enfants Terribles - WWW.LET.DE
Marc Manthey 50672 Köln - Germany
Hildeboldplatz 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: [email-masked]
jabber :[email-masked]
IRC: #opencu  freenode.net
twitter: http://twitter.com/macbroadcast
web: http://www.let.de

---

From: Bryan Ford <[email-masked]>
Date: Wed, 24 Dec 2008 19:50:00 +0100

On Dec 22, 2008, at 10:51 PM, macbroadcast wrote:
>> IP does not presume hierarchical addresses and worked quite well  
>> without it for nearly 20 years.
>> IP addresses are topologically independent. Although since CIDR,  
>> there has been an attempt to make them align with aspects of the  
>> graph.
>> Ford's paper does not really get to the fundamentals of the problem.
>>
>> I would suggest that deeper thought is required.
>
> would like to know bryans  opinion

I think I missed some intermediate messages in this discussion thread,  
but I'll try. :)

IP addresses are just an address format (two, actually, one for IPv4  
and another for IPv6); their usefulness and effectiveness depends on  
exactly how they are assigned and used.  CIDR prescribes a way to  
assign and use IP addresses that in theory facilitates aggregation of  
route table entries to make the network scalable, _IF_ those addresses  
are assigned in a hierarchical fashion that directly corresponds to  
the network's topology, which must also be strictly hierarchical in  
order for that aggregation to be possible.  That is, if an edge  
network has only one upstream provider and uses in its network only IP  
addresses handed out from that provider's block, then nobody else in  
the Internet needs to have a routing table entry for that particular  
edge network; only for the provider.  But that whole model breaks down  
as soon as that edge network wants (god forbid!) a bit of reliability  
by having two redundant links to two different upstream providers -  
i.e., "the multihoming problem", and hence all the concern over the  
fact that BGP routing tables are ballooning out of control because  
_everybody_ wants to be multihomed and thus wants their own public,  
non-aggregable IP address range, thus completely defeating the  
scalability goals of CIDR.

For some nice theoretical and practical analysis indicating that any  
hierarchical CIDR-like addressing scheme is fundamentally a poor match  
to a well-connected network topology like that of the Internet, see  
Krioukov et al., "On Compact Routing for the Internet", CCR '07.  They  
also cast some pretty dark clouds over some alternative schemes as  
well, but that's another story. :)

But to get back to the original issue, CIDR-based IP addressing isn't  
scalable unless the network topology is hierarchical and address  
assignment is done according to network topology: i.e., IP addresses  
MUST be dependent on topology in order for CIDR-based addressing to  
scale.  But in practice, at least up to this point, other concerns  
have substantially trumped this scalability concern: edge networks  
want fault tolerance via multihoming and administrative independence  
from their upstream ISPs, so they get their own provider-independent  
IP address blocks for their edge networks, which are indeed topology- 
independent (at least in terms of the assignment of the whole block),  
meaning practically every core router in the world will subsequently  
have to have a separate routing table entry for that edge network.   
But this only works for edge networks whose owners have sufficient  
size and clout and financial resources; we're long past the time when  
an individual could easily get his own private Class C address block  
for his own home network, like I remember doing a long time ago. :)   
So small edge networks and individual devices still have to use IP  
addresses assigned to them topologically out of some upstream  
provider's block, which means they have to change whenever the device  
moves to a different attachment point.

So in effect we've gotten ourselves in a situation where IP addresses  
are too topology-independent to provide good scalability, but too  
topology-dependent to provide real location-independence at least for  
individual devices, because of equally strong forces pulling the IP  
assignment process in both directions at once.  Hence the reason we  
desperately need locator/identity separation: so that "locators" can  
be assigned topologically so as to make routing scalable without  
having to cater to conflicting concerns about stability or location- 
independence, and so that "identifiers" can be stable and location- 
independent without having to cater to conflicting concerns about  
routing efficiency.

As far as specific forms these "locators" or "identifiers" should  
take, or specific routing protocols for the "locator" layer, or  
specific resolution or overlay routing protocols for the "identity"  
layer, I think there are a lot of pretty reasonable options; my paper  
suggested one, but there are others.

Cheers,
Bryan

> merry christmas
> Marc

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 28 Dec 2008 11:42:07 -0800

It depends on what level you are looking at the problem from

In my opinion, application layer systems should not make assumptions that have functional (as opposed to performance) implications on the inner semantics of IP addresses. From the functionality point of view an IP address should be considered by the application to be no more than an opaque identifier.

The reason for that is precisely to allow the routing layer to make architectural decisions that do apply semantics to the address and which change over periods of time that are relevant to routing layer deployment cycles (there are plenty of pre-1995 Internet hosts still in service, I will wager a rather smaller percentage of backbone routers from 1995 are still in service :-).

Which is why I want to see ad-hoc semantics that applications attempt to apply to IP addresses being replaced by DNS level (ie reverse DNS) facilities that achieve the same effect in a fashion that does not result in applications breaking if those assumptions are broken.

On the geographic nature of IP addresses, clearly some level of aggregation is essential but it is equally clear that 100% clean aggregation is never going to be achievable either. The longer a block is in service the more it gets 'bashed about'. Entropy increases.

At the moment the Internet architecture has a built in assumption that the system is going to grow. And that keeps the chaos factor in check because the new blocks are a significant proportion of the whole and have nice regular assignments at issue. But what when the system stops growing? How do we keep the chaos to an acceptable fraction?

This leads me to consider an IP address block assignment as being an inherently term limited affair, with the sole exception being root DNS where perpetual assignments are going to be necessary. The terms need to be long, years, probably decades at minimum. But there needs to be a built in assumption that over time there will be a 'recycling' of broken down, atomized address blocks into larger clumps that aggregate nicely. Which in turn is only possible if nobody (apart from core DNS) cares about their IP address having a specific value.

-----Original Message-----
From: [email-masked] on behalf of Bryan Ford
Sent: Wed 12/24/2008 1:50 PM
To: macbroadcast
Cc: [email-masked]
Subject: Re: The internet architecture

Cheers,
Bryan

---

From: TSG <[email-masked]>
Date: Sun, 28 Dec 2008 13:17:55 -0800

Hallam-Baker, Phillip wrote:
> In my opinion, application layer systems should not make assumptions 
> that have functional (as opposed to performance) implications on the 
> inner semantics of IP addresses. From the functionality point of view 
> an IP address should be considered by the application to be no more 
> than an opaque identifier.
>
> The reason for that is precisely to allow the routing layer to make 
> architectural decisions that do apply semantics to the address and 
> which change over periods of time that are relevant to routing layer 
> deployment cycles (there are plenty of pre-1995 Internet hosts still 
> in service, I will wager a rather smaller percentage of backbone 
> routers from 1995 are still in service :-).
>
> Which is why I want to see ad-hoc semantics that applications attempt 
> to apply to IP addresses being replaced by DNS level (ie reverse DNS) 
> facilities that achieve the same effect in a fashion that does not 
> result in applications breaking if those assumptions are broken.
>
>
> On the geographic nature of IP addresses, clearly some level of 
> aggregation is essential but it is equally clear that 100% clean 
> aggregation is never going to be achievable either. The longer a block 
> is in service the more it gets 'bashed about'. Entropy increases.
>
Only if they are used as reliable network monuments. And yes that is the 
proper term for it and one we should start using as a particular form of 
trust anchor.

When we did the Controlling access patent, this was part of the control 
and reporting model we built for it.

>
> At the moment the Internet architecture has a built in assumption that 
> the system is going to grow. And that keeps the chaos factor in check 
> because the new blocks are a significant proportion of the whole and 
> have nice regular assignments at issue. But what when the system stops 
> growing? How do we keep the chaos to an acceptable fraction?
>
> This leads me to consider an IP address block assignment as being an 
> inherently term limited affair, with the sole exception being root DNS 
> where perpetual assignments are going to be necessary. The terms need 
> to be long, years, probably decades at minimum. But there needs to be 
> a built in assumption that over time there will be a 'recycling' of 
> broken down, atomized address blocks into larger clumps that aggregate 
> nicely. Which in turn is only possible if nobody (apart from core DNS) 
> cares about their IP address having a specific value.
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.19/1859 - Release Date: 12/20/2008 2:34 PM
>
>

---

From: John Day <[email-masked]>
Date: Sun, 28 Dec 2008 16:22:37 -0500

Why should an application ever see an IP address?

Applications manipulating IP addresses is like a Java program 
manipulating absolute memory pointers. A recipe for problems, but 
then you already know that.

At 11:42 -0800 2008/12/28, Hallam-Baker, Phillip wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01C96924.5DF45235"
>
>inner semantics of IP addresses. From the functionality point of 
>view an IP address should be considered by the application to be no 
>more than an opaque identifier.
>
>Which is why I want to see ad-hoc semantics that applications 
>attempt to apply to IP addresses being replaced by DNS level (ie 
>reverse DNS) facilities that achieve the same effect in a fashion 
>that does not result in applications breaking if those assumptions 
>are broken.
>
>
>aggregation is never going to be achievable either. The longer a 
>block is in service the more it gets 'bashed about'. Entropy 
>increases.
>
>At the moment the Internet architecture has a built in assumption 
>that the system is going to grow. And that keeps the chaos factor in 
>check because the new blocks are a significant proportion of the 
>whole and have nice regular assignments at issue. But what when the 
>system stops growing? How do we keep the chaos to an acceptable 
>fraction?
>
>inherently term limited affair, with the sole exception being root 
>DNS where perpetual assignments are going to be necessary. The terms 
>need to be long, years, probably decades at minimum. But there needs 
>to be a built in assumption that over time there will be a 
>'recycling' of broken down, atomized address blocks into larger 
>clumps that aggregate nicely. Which in turn is only possible if 
>nobody (apart from core DNS) cares about their IP address having a 
>specific value.
>
>
>
>>>>>>  [ 1 ] 
>>>>>><http://en.wikipedia.org/wiki/Kademlia>http://en.wikipedia.org/wiki/Kademlia
>>>>>>  [ 2 ] 
>>>>>><http://pdos.csail.mit.edu/papers/uip:hotnets03.pdf>http://pdos.csail.mit.edu/papers/uip:hotnets03.pdf
>>>>>>  --
>
><https://www.ietf.org/mailman/listinfo/ietf>https://www.ietf.org/mailman/listinfo/ietf
>
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Dec 2008 07:56:37 -0500

--On Sunday, 28 December, 2008 16:22 -0500 John Day
<[email-masked]> wrote:

> manipulating absolute memory pointers. A recipe for problems,
> but then you already know that.

John,

Let me try to explain, in a slightly different way, what I
believe some others have tried to say.

Suppose we all agree with the above as a principle and even
accept your analogy (agreement isn't nearly that general, but
skip that for the moment).  Now consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name.   One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is more or
less the same as one DNS name per address.

Now the application has to pick which interface to use in, e.g.,
opening a connection to another system.  Doing that optimally,
or even effectively, requires that it know routing information.
But requiring the application to obtain and process routing
information is worse than whatever you think about its using IP
addresses -- the latter may be just a convenient handle ("blob")
to identify what we have historically called an interface, but
having the application process and interpret routing information
is completely novel as far as the applications layer is
concerned (as well as being a layer violation, etc., etc.) and
requires skills and knowledge that application writers rarely
have and still more rarely should need to use.

At least to me, that is the key architectural problem here, not
whatever nasty analogies one can draw about IP addresses.

    john

---

From: Rémi Després <[email-masked]>
Date: Mon, 29 Dec 2008 14:22:51 +0100

John,

To pick a local interface for an outgoing connection isn't the
transport layer, e.g. SCTP, well placed to do the job (or some
intermediate layer function like Shim6)?

Thus, ordinary applications wouldn't need to be concerned.

RD

Actually SCTP is  it to some extent.

John C Klensin  -  le (m/j/a) 12/29/08 1:56 PM:

John,

Now the application has to pick which interface to use in, e.g.,
opening a connection to another system.

See above

Doing that optimally,

john

---

From: John Day <[email-masked]>
Date: Mon, 29 Dec 2008 10:24:59 -0500

No it isn't Transport's job.  Transport has one 
and only one purpose: end-to-end reliability and 
flow control.

"Managing" the resources of the network is the network layer's job.

Although, these distinctions of Network and 
Transport Layer are . . . shall we say, quaint.

Multihoming is fundamentally a routing problem. 
SCTP tries to claim to solve it by changing the 
definition, an old trick. Sort of like medieval 
medicine's response to a disease it can't cure: 
give you a disease I can cure and hope it works. 
Multihoming has nothing to do with what has 
traditionally been called the "Transport Layer."

It is a problem of routing not be able to 
recognize that two points of attachment go to the 
same place.  Portraying it as anything else is 
just deluding yourself.

At 14:22 +0100 2008/12/29, Rémi Després wrote:
>John,
>
>To pick a local interface for an outgoing 
>connection isn't the transport layer, e.g. SCTP, 
>well placed to do the job (or some intermediate 
>layer function like Shim6)?
>><mailto:[email-masked]><[email-masked]> wrote:
>>
>>
>>
>><mailto:[email-masked]>[email-masked]

---

From: John Day <[email-masked]>
Date: Mon, 29 Dec 2008 10:32:10 -0500

Let me get this straight.  You are saying that there are other 
reasons why an application should never see an IP address? And you 
feel that your reason is more important than simply getting level of 
abstractions wrong. So you agree?

Yes, of course.  There are lots of ugly things that can happen.  You 
don't have to go very far to run into why.  The question is why have 
we insisted on not doing it right for so long?

Take care,
John

---

From: macbroadcast <[email-masked]>
Date: Mon, 29 Dec 2008 16:54:11 +0100

dear john day

would you please reply just to the list , sorry it was not my  
intention to make such a fuzz when i involved brians opinion about  
u.i.a.

Thanks for the other opinions aswell.

regards

and happy new year

Marc

<https://sourceforge.net/project/screenshots.php?group_id=122388&ssid=96693

---

From: Rémi Després <[email-masked]>
Date: Mon, 29 Dec 2008 17:04:41 +0100

John Day  -  le (m/j/a) 12/29/08 4:24 PM:

No it isn't Transport's job.  Transport has one and only one
purpose: end-to-end reliability and flow control.

"Managing" the resources of the network is the network
layer's job.

Reliably... and also efficiently.

To transmit as fast as possible, including with load sharing among
several parallel paths, the flow control function (i.e. the transport
layer, right?) has, in my understanding, to know how many address
couples
it uses.

Whether the transport layer can delegate some of its flow control
function to an intermediate layer is IMO a terminology question.

Although, these distinctions of Network and Transport Layer are
.
. . shall we say, quaint.

Yes, indeed.

Multihoming is fundamentally a routing problem.  SCTP tries
to claim to solve it by changing the definition, an old trick.

I am not sure what the two definitions are.

Being more specific would be helpful.

... Multihoming has
nothing to do with what has traditionally been called the
"Transport Layer."

It is a problem of routing not be able to recognize that two
points of attachment go to the same place. ...

In my understanding, knowing that two locators are those of  a common
destination is  the normal result from getting these locators by
translation of an identifier, e.g. a domain name.

RD

John,

RD

---

From: John Leslie <[email-masked]>
Date: Mon, 29 Dec 2008 11:34:56 -0500

John Day <[email-masked]> wrote:
> At 14:22 +0100 2008/12/29, R?mi Despr?s wrote:
>>
>> To pick a local interface for an outgoing connection[,]
>> isn't the transport layer, e.g. SCTP, well placed to do the job
>> (or some intermediate layer function like Shim6)?
> 
> No it isn't Transport's job.  Transport has one and only one purpose:
> end-to-end reliability and flow control.

   I must disagree with John Day.

   I accept "reliability and flow control" as the transport layer's
primary function, but denying it access to multiple interfaces cripples
its ability to perform those functions in a mobility environment.

   And, IMHO, from an architectural viewpoint, multi-homing and mobility
are the same problem.

> "Managing" the resources of the network is the network layer's job.

   That's only partly true, and completely irrelevant.

> Although, these distinctions of Network and Transport Layer are . . .
> shall we say, quaint.

   True, we can't seem to agree to a distinction and stick with it,
but "quaint" is hardly the right word -- it's more like "deja-vu all
over again."

> Multihoming is fundamentally a routing problem. 

   Absolutely not.

   Routing is a function of discovering connectivity and propagating
information about routes to routers that may want to use them.

   Multihoming is a funtion of maintaining alternate paths in order
to avoid interruptions of connectivity when a primary path hiccups or
becomes congested. (Just like mobility...)

   Multihoming _should_not_ wait for connectivity to fail altogether;
least of all should it wait for connectivity failure to propagate
through an internet.

   We have pretty good routing algorithms for _stable_ networks. We
have to kludge those algorithms to work _at_all_ in unstable networks.
Mobility by its nature _cannot_ be stable. (Multi-homing is most
often done as protection against occasional instability.)

> SCTP tries to claim to solve it by changing the definition, an old
> trick.

   Unfair! SCTP was designed for a specific function: it's quite honest
about the design choices. Don't blame its design for other things folks
are trying to use it for.

> Multihoming has nothing to do with what has traditionally been called
> the "Transport Layer."

   If so, perhaps it's time to refine those "definitions" of "Transport
Layer."

> It is a problem of routing not be able to recognize that two points
> of attachment go to the same place.

   Hardly!

   Routing finds paths between "nodes" using "links". These "nodes"
_are_ points of attachment, not computers (whatever those may be).
Routing _must_ deal in topology, not physical proximity.

> Portraying it as anything else is just deluding yourself.

   Again, hardly!

   We have been punting entirely too much to "routing" for decades.
There are other perfectly valid ways to divide the problem. And IMHO,
any way that makes the realm of "routing" reside in a "stable" space
is a _better_ paradigm.

--
John Leslie <[email-masked]>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Day <[email-masked]>
Date: Mon, 29 Dec 2008 12:05:20 -0500

At 17:04 +0100 2008/12/29, Rémi Després wrote:
>>Re: The internet architecture
>>and only one purpose: end-to-end reliability 
>>and flow control.
>>

Definitely.

>To transmit as fast as possible, including with 
>load sharing among several parallel paths, the 
>flow control function (i.e. the transport layer, 
>right?) has, in my understanding, to know how 
>many address couples it uses.

Strictly speaking, no, I would disagree that 
these are transport functions. Transport has no 
need to know any address couples.  That is why it 
has a connection id, i.e. concatenated port-ids. 
But then as I said, there really is no distinct 
transport or network layer.

This is where things get involved. because really 
the boundary between network and transport is a 
false boundary.  The last remnant of 
"beads-on-a-string" thinking.  One sign of this 
is the need for a protocol-id field in IP.  If we 
hadn't gotten into a battle with the PTTs over 
whether or not we needed a Transport Layer at 
all, I think we would have seen this a lot 
sooner.  But the battle caused lines to be drawn 
and forces to dig in.  ;-)

>
>Whether the transport layer can delegate some of 
>its flow control function to an intermediate 
>layer is IMO a terminology question.

Somewhat.  There is a fair amount of science on 
this topic under the heading of process control. 
The only purpose flow control should have in a 
transport protocol is to keep the sender from 
overrunning the receiver. <full stop>  Getting 
the terminology right can go along way to solving 
the problem.

>>definition, an old trick.
>>

See below, but you did.  ;-)

>
>>... Multihoming has nothing to do with what has 
>>recognize that two points of attachment go to 
>>the same place. ...
>>
>In my understanding, knowing that two locators 
>are those of a common destination is the normal 
>result from getting these locators by 

I don't believe the routing algorithms translate 
many domain names.  But you are right that a 
domain name is a synonym for a set of IP 
addresses.

Take care,
John

>>>connection isn't the transport layer, e.g. 
>>>SCTP, well placed to do the job (or some

---

From: <[email-masked]>
Date: Mon, 29 Dec 2008 18:24:41 -0000

> Yes, of course.  There are lots of ugly things that can 
> happen.  You don't have to go very far to run into why.  The 
> question is why have we insisted on not doing it right for so long?

Perhaps because others were working on the problems of application
communication without IP addresses. AMQP is one such <http://amqp.org/>
as are all the other protocols that call themselves "message queuing".
XMPP might fall into the same category (RFC refs here
<http://xmpp.org/rfcs/>)
but I'm not familiar enough with the details to be sure that it meets
the criteria for unbroken end-to-end communication through IP addressing
change events.

In many ways, this is all a problem of language and history. At the
time many RFCs were written, the world of networking was very different
and very undeveloped. Getting the bareboned basics of networking right
was very, very important. But it was less important to make things
easy for application developers or application users because the very 
fact of a network delivered such great benefits over what came before,
that other problems seemed unworthy of attention. As all of this recedes
into history, the language that we use to speak about technology has
changed
so that terminology which was historically concise, is now a bit vague
and can be interpreted in more than one way. That's because lots of
other
people now use the same language and apply it to their designs,
architectures,
etc.

I think the only way to resolve the question is to publish an Internet 
architecture description in today's context, that explains what the
Internet architecture is, what it isn't, and why it has succeeded in
being what it is. At the same time, one could point to other work
outside
the IETF that has worked on other problems which are related and
intertwined
with Internet architecture, yet separate from it. And if AMQP really
meets
all the requirements of an IP address free protocol, perhaps it should
be
taken under the IETF's wing.

--Michael Dillon

---

From: John Day <[email-masked]>
Date: Mon, 29 Dec 2008 13:24:04 -0500

>its ability to perform those functions in a mobility environment.

Transport has nothing to do with mobility.

>    And, IMHO, from an architectural viewpoint, multi-homing and mobility

You are absolutely right.  Mobility is nothing more than dynamic multihoming.

Trying to guess where you are coming from, don't blame Transport for 
TCP's faults.

>    That's only partly true, and completely irrelevant.

Highly relevant.  Since only the network layer can manage the network layer.

>but "quaint" is hardly the right word -- it's more like "deja-vu all

No, quaint. As in "isn't it quaint how people saw things in olden times"

>information about routes to routers that may want to use them.

Boy, if discovering routes and propagating routing information isn't 
a routing  problem, then what is?

>becomes congested. (Just like mobility...)

Right.  Routing.

>least of all should it wait for connectivity failure to propagate

That is a policy decision that routing is free to make and does.

>often done as protection against occasional instability.)

Of course it can.  You just aren't asking the right question.

>are trying to use it for.

Only blame ti for things its spec claims it does.

>    If so, perhaps it's time to refine those "definitions" of "Transport

Eliminate the transport layer is probably the best thing to do.

>Routing _must_ deal in topology, not physical proximity.

Nodes are not points of attachments.  Well, not to the same routing algorithm.

>any way that makes the realm of "routing" reside in a "stable" space

O, and BTW, did I say we don't solve multihoming in routers either?
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 29 Dec 2008 10:58:01 -0800

Hi -

> From: "John Day" <[email-masked]>
> To: "Rémi Després" <[email-masked]>; "John C Klensin" <[email-masked]>
> Cc: "Bryan Ford" <[email-masked]>; <[email-masked]>
> Sent: Monday, December 29, 2008 7:24 AM

Depends on what one is routing *to* - application,
host, or attachment point.

...
> same place.  Portraying it as anything else is

The multiple-entrance, multiple exit problem could also
be attacked with a variation on good ol' multi-link
procedure, but done just below (or as a sublayer of)
transport, but above (connectionless) network, and
not restrict it to datalink.

Randy

---

From: John Leslie <[email-masked]>
Date: Mon, 29 Dec 2008 17:50:12 -0500

> Transport has nothing to do with mobility.

   To whatever extent we accept the existence of "transport" for
stationary computers, we must allow it for mobile computers.

   I think we're arguing semantics here, without agreeing on what we
mean by "transport". I'd much rather continue that argument on a different
mailing-list.

> Trying to guess where you are coming from, don't blame Transport for 

   TCP has many faults, only some of which are related to its "transport
layer" functions.

   Where I'm coming from, BTW, is a long series of primal screams when
I hear someone proposing how to deal with transport issues in a
routing protocol.

> No, quaint. As in "isn't it quaint how people saw things in olden times"

   But, IMHO, we _never_have_ seen network-vs-transport in a consistent
way.

> a routing  problem, then what is?

   Multihoming (or mobility, if you prefer) isn't about "discovering"
alternate connectivity: it's about verifying that something arriving
via a different path is in fact controlled by the same process as
something we're already communicating with. That is _not_ a routing
issue -- routing merely attempts to deliver packets.

>> becomes congested. (Just like mobility...)

   Even if we were to accept a flooding paradigm for routing (and send
every packet out every interface), multihoming would still require
sorting out which packets to trust.

> That is a policy decision that routing is free to make and does.

   Although routing _does_ make such decisions, architecturally that's
noise, not a native "network layer" function. Network-layer is about
getting packets through a network of networks _at_all_ -- not about
managing everyone's Quality-of-Service wishlists. "Efficiency" issues
in routing are there to keep routing from breaking, for example by
routing packets in a loop until TTL is exhausted.

> Of course it can.  You just aren't asking the right question.

   Feel free to correct me -- what question should I be asking?

> Eliminate the transport layer is probably the best thing to do.

   I'd be happy to talk about that -- on the <[email-masked]> list.

> Nodes are not points of attachments. Well, not to the same routing 

   To a routing algorithm, "nodes" are "nodes", period. True.

   But in the Internet, IP addresses _are_ points of attachment, and
network-layer routing finds paths between "points of attachment".

> O, and BTW, did I say we don't solve multihoming in routers either?

   Not this week... ;^)

---

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 10:20:57 +1100

Short version:   Please contribute to the IRTF Routing Research Group
                 discussions on how to devise a new Internet
                 architecture (including by adding to the current
                 architecture) to solve the routing scaling problem.

Hi John and All,

This discussion includes debate about whether in a new Internet
architecture, the responsibility for handling network-centric
problems should in future be handled by hosts.  These network-centric
 real-time events, problems and responsibilities include:

 1 - Multihoming.

 2 - Traffic engineering.

 3 - Portability of address space - or some other, yet to be
     invented, approach which has the same effect of making it easy
     to choose another ISP without the disruption, cost etc.

Please take a look at the current discussions in the IRTF Routing
Research Group.  The RRG has been charged with the responsibility of
recommending to the IESG what sort of architectural changes should be
made to the Internet (really, the IPv4 Internet and the IPv6
Internet) to solve the routing scaling problem.  The deadline is
March 2009.

RRG mailing list archives, wiki and charter:

 http://www.irtf.org/pipermail/rrg/
 http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
 http://www.irtf.org/charter?gtype=rg&group=rrg

The RAWS workshop (Amsterdam October 2006):

 http://tools.ietf.org/html/rfc4984
 http://www.iab.org/about/workshops/routingandaddressing/

I wrote a critique of any solution which pushes new responsibilities
onto hosts which concern things which occur in the network:

 Fundamental objections to a host-based scalable routing solution
 http://www.irtf.org/pipermail/rrg/2008-November/000271.html

Bill Herrin has a page which attempts to list the various approaches
to solving the routing scaling problem:

 http://bill.herrin.us/network/rrgarchitectures.html

I think the problem definition there is biased towards the notion
that the solution is to have hosts take on new functions, including
with changes to stacks, APIs and applications.  I wrote some
additional text which I think provides a more complete problem
description:

 http://www.irtf.org/pipermail/rrg/2008-December/000525.html

Also of interest is a recent paper contrasting network centric
core-edge separation schemes with host-centric "elimination" schemes:

  Towards a Future Internet Architecture: Arguments for Separating
  Edges from Transit Core

  Dan Jen (UCLA), Lixia Zhang (UCLA), Lan Wang (University of
  Memphis), Beichuan Zhang (University of Arizona)

  (HotNets-VII) Calgary, Alberta, Canada October 6-7, 2008
  http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

Bill is currently calling for RRG members to form strong consensus on
rejecting one or more solution strategies.  (Msg 000554.)  The types
of strategy are (with my descriptions for A, B and C):

Strategy A:

  Network-based core-edge separation schemes, including LISP, APT
  Ivip, TRRP and Six-One Router.  (See the RRG wiki page for links.)

Strategy B:

  Host-centric elimination schemes.  "Elimination" means all end-user
  network addresses are subsets of ISP prefixes.  Only ISP prefixes
  are advertised in the interdomain routing system.

  See Brian Carpenter's message on how this is "unworkable for IPv4
  and very close to the plan of record for IPv6" - except that
  IPv6 doesn't provide multihoming (session survival when the
  currently used ISP-provided address becomes unusable).

   http://www.irtf.org/pipermail/rrg/2008-December/000577.html

Strategy C:

  New interdomain routing system arrangements, including for
  instance: geographical aggregation or compact routing.
  (A critique of compact routing: http://arxiv.org/abs/0708.2309.)

Strategy D:

  "Use plain old BGP for the RIB. Algorithmically compress the FIB in
  each router."

Strategy E:

  "Make no routing architecture changes. Instead, create a billing
  system through which the folks running core routers are paid by the
  folks announcing each prefix to carry those prefixes. Let economics
  suppress growth to a survivable level."

Strategy F:

  "Do nothing. (RFC 1887 § 4.4.1)"

My message calling for strong consensus in rejecting Strategies B, C,
D, E and F:

  http://www.irtf.org/pipermail/rrg/2008-December/000565.html

  - Robin            http://www.firstpr.com.au/ip/ivip/
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: macbroadcast <[email-masked]>
Date: Wed, 31 Dec 2008 14:04:12 +0100

Am 24.12.2008 um 19:50 schrieb Bryan Ford:
>
> So in effect we've gotten ourselves in a situation where IP  
> addresses are too topology-independent to provide good scalability,  
> but too topology-dependent to provide real location-independence at  
> least for individual devices, because of equally strong forces  
> pulling the IP assignment process in both directions at once.  Hence  
> the reason we desperately need locator/identity separation: so that  
> "locators" can be assigned topologically so as to make routing  
> scalable without having to cater to conflicting concerns about  
> stability or location-independence, and so that "identifiers" can be  
> stable and location-independent without having to cater to  
> conflicting concerns about routing efficiency.
>
> layer, I think there are a lot of pretty reasonable options; my  
> paper suggested one, but there are others.
>
> Cheers,
> Bryan

thanks brian for your great explanation  , something came to my mind  
imediatly,

.........i remember these days when i connect to the internet using my  
1 und 1 - 14,4kb modem in the 90th

there was no NAT,

  i connected with a little programm to a specific ip adress,

there was not even DNS involed at that time. for the programm i was  
talking about ;)

So there were no caches und buffers with information about my usage  
exept  on the server where i was connected to.

Just one question because i am reading a lot about all these routing  
ptotocols in the past , is uia / uip  more usefull in sparse or dense  
networks or both ?

bright new 2009

cheers from cologne

Marc