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"
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: ietf-bounces@xxxxxxxx on behalf of Bryan Ford
Sent: Wed 12/24/2008 1:50 PM
To: macbroadcast
Cc: ietf@xxxxxxxx
Subject: Re: The internet architecture
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
>
>
>>>>> 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.
>>>>>
>>>>>
>>>>> [ 1 ] http://en.wikipedia.org/wiki/Kademlia
>>>>> [ 2 ] http://pdos.csail.mit.edu/papers/uip:hotnets03.pdf
>>>>> --
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf