Subject: Re: Enforcing unreachability of site local addresses

From: David Conrad <[email-masked]>
Date: Fri, 31 Jan 2003 22:16:45 -0800

Hi,

Again, in the vein of willing suspension of disbelief...

On Friday, January 31, 2003, at 04:55  PM, Dan Lanciani wrote:
> Using name strings may be no more difficult with respect to the 
> implementation
> of the name service, but it leverages far less existing code than 
> would a fixed-
> length binary identifier.

Right.

> Consider the advantages of using an identifier that
> has exactly the same format as what we currently call an address, 
> i.e., 128
> bits.

Or, better yet, 64 bits.  Say, the lower 64 bits of a 128 bit value?.

> With translation happening near the bottom of the IP layer, no changes
> would be necessary in tcp or in applications.

No translation would be necessary.

> The problem of tcp connections
> (not) surviving renumbering would disappear.  The DNS would work just 
> the way
> it is, so no duplicate effort would be required.

Yup.

> With a little care, multi-homing could be supported.

Multi-homing would be trivial.

Assume at the end point an address consists of a 64 bit value stuffed 
into the lower 8 bytes of an IPv6 address with the upper 64 bits 0.

The lower 64 bits of the destination would be put into an 
in-addr.arpa-like tree, mapping that end point into multiple AAAAs 
(which have their lower 64 bits set to 0) that correspond to the edge 
routers associated with the multiple paths to the destination.

Packet hits the source edge router for the first time, a DNS lookup 
occurs fetching the multiple locators and caching them.  The edge 
router then bitwise ORs one of the locators (how the locator is chosen 
is left to the reader as an exercise) with the end point address, 
forming a full 128 bit address.  Obviously, you'd want to have the 
source edge router keep the cache entry up to date as long as packets 
are flowing to the destination (e.g., re-fetch at TTL/2 or whatever).

On the receiving end, the destination edge router receives the packet, 
zeros out the top 64 bits of the destination address (thereby avoiding 
NAT nightmares) and forwards the packet on to the destination.

Renumbering thereby becomes merely an exercise in modifying the end 
point 64 bit in-addr.arpa-like entry and waiting for the cache entry to 
time out.

End point identifiers would be non-topologically sensitive and could be 
permanently assigned with absolutely no hierarchy (if desired).  
Locators would still be topologically sensitive, but end users would 
never see them or know about them, thus topology changes can be done 
transparently.

Even more fun:  assume that the first four bytes of the end point 
address aren't used during a transition period and the last four bytes 
encodes (say) an IPv4 address....

> I suspect that mobile IP would be a lot easier as well.

Mobility is a bit trickier due to the DNS security and caching model.  
However, I believe it may be possible with the use of SIG(0) and having 
destination edge routers act as forwarding agents for a TTL.  This bit 
needs more thought...

> In contrast, if we fix the DNS to track the topology, names would have
> to replace addresses in tcp control blocks (and packets and many other 
> places)
> before we would start to see the aforementioned benefits.

Ick.

Rgds,
-drc

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 3 Feb 2003 13:23:29 -0800

Dan Lanciani wrote:
> "Tony Hain" <[email-masked]> wrote:
> 
> |Suspend disbelief for a moment, and consider a name 
> resolution service 
> |where the consumer edge widget was responsible for both tracking 
> |topology changes, and updating a branch of the name tree to keep it 
> |aligned. Said widget would need a secure mechanism to graft 
> itself to 
> |the name tree after an address change, but otherwise might 
> look like a 
> |typical DNS server. [...]
> 
> It's not much of a suspension.  I've been saying for years 
> that exactly such a mechanism is necessary to push the 
> routing task out to the end nodes where ample resources will 
> be available.  If it isn't done at some other level it will 
> have to happen in the DNS.  However, I believe that the DNS 
> is the wrong place for it.

There is an important difference between pushing all the way to the end
system, vs. the edge router. While architecturally there is little
difference, when the mapping function is in the end system the level of
churn on the registration infrastructure is substantially higher. Moving
that to the consumer edge/set top provides both a platform that is
generally more stable in its availablity, as well as an aggregation
point for the bulk of the device churn.

> 
> |Given that as a
> |starting point, there is no obvious reason that using name 
> strings as 
> |the identifier is more difficult than any other approach.
> 
> Using name strings may be no more difficult with respect to 
> the implementation of the name service, but it leverages far 
> less existing code than would a fixed- length binary 
> identifier.

Existing code is not a reasonable argument to justify the architectural
change of inserting an additional name service into the system. 

> Consider the advantages of using an identifier 
> that has exactly the same format as what we currently call an 
> address, i.e., 128 bits.  With translation happening near the 
> bottom of the IP layer, no changes would be necessary in tcp 
> or in applications.  

Unless the application was trying to associate the source address of the
packet with something it knows about. If there is a 'transparent'
mapping function in the system, apps that expect that service will
break. If such a mapping service is to work with said apps, there needs
to be a mechanism to distribute the mapping table with some level of
authenticity. If you are talking about essentially in-line encaps like
8+8, every routing edge would need to map the source locator as well as
destination. 

> (not) surviving renumbering would disappear.  The DNS would 
> work just the way it is, so no duplicate effort would be 
> required.  

Wait, a string to string translation happens in the DNS, then you claim
another string to string translation is not a duplicate effort !?!?! 

> With a little care, multi- homing could be 
> supported.  I suspect that mobile IP would be a lot easier as 
> well.  In contrast, if we fix the DNS to track the topology, 
> names would have to replace addresses in tcp control blocks 
> (and packets and many other places) before we would start to 
> see the aforementioned benefits.
> 
> I have proposed a simple, scalable mapping service that is 
> vaguely like the DNS in structure but whose purpose is to map 
> 128-bit identifiers into 128-bit locators (where these 
> locators correspond to what we currently use as addresses and 
> treat more as routes) in a flexible way. A request to the 
> root of this mapping service would be of the form, ``tell me 
> about this 128-bit identifier.'' A response would either be a 
> referal to other servers along with a mask to indicate what 
> other requests should go to that same set of servers or an 
> answer in the form of a mapping from identifier (with 
> possible wildcard bits indicated by a mask) to locator (also 
> with possible wildcards to be filled in from the identifier). 

The request/response is not the problem. Explain how it handles a
scalable, secure update as nodes move between 802.11 hotspots of
different providers. If that problem is solved, there is no reason for
such a mapping system be limited to 16B fixed length strings.

>  The latter final response is assumed to come from a server 
> under the control of the owner of the identifier.  

Basically what I was suggesting by pushing the service to the customer
edge.

> Obviously, 
> responses would also include the usual TTL values and such 
> much as a DNS response does.  The mapping service actually 
> scales a lot better than the DNS because it can increase the 
> depth of the tree as necessary by splitting on arbitrary bit 
> fields in the identifier.  This should be transparent (think 
> unix DBM).

The only thing that limits DNS is the assumption that the branching is
limited. If name strings were device.customer.aol.cc... there is no real
difference to parsing on a bit boundary.

Tony

> 				Dan Lanciani
> 				ddl@danlan.*com

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 3 Feb 2003 13:55:27 -0800

David Conrad wrote:
> ...

The problem that needs to be solved is how this is done in a secure,
scalable way as said node moves between something like 802.11 hotspots.

> are flowing to the destination (e.g., re-fetch at TTL/2 or whatever).

I don't follow these steps. How does the origin get from AAAA records
with only locators for the provider edge router, to a 128 bit entry? The
only way I can figure this out is for 1) src looks up AAAA for name
string, receives low 64 bits; 2) looks up in-addr of low 64 bits,
receives name strings for current service provider edge routers; 3)
looks up name strings of current service provider edge routers, receives
set of upper 64 bit values that could be appended. All those steps only
minimize churn on the forward tree. There is still a need to churn the
reverse tree as the node moves.

> NAT nightmares) and forwards the packet on to the destination.

This would not really be necessary as the dst could just as easily
ignore the upper 64 bits. The real question is where such a system ends
up pushing the complexity to. Take the example of simple spam filtering
in a mail server (since I happened to be working on that this morning).
A simple filter might look like 66.154.0.0/18 because I know I have no
valid reason to receive mail from CONEPUPPY-COM or its customers. If we
change the system to remove any indication of routing infrastructure
from the bits an application sees, there will be an increase in traffic
that is trying to figure out where a random 64 bit identifier string
came from. 

> point 64 bit in-addr.arpa-like entry and waiting for the 

For mobile devices those cache entries will need to be on the order of
minutes, and there is a missing discussion of how the update is
authenticated, and its impact on overall network traffic.

> never see them or know about them, thus topology changes can be done 

We are squeezing a balloon here. The more we optimize the routing
infrastructure, the more we will end up complicating another area (see
above discussion about spam filters). 

> > before we would start to see the aforementioned benefits.

This depends on the frequency of topology change. If the topology change
period is significantly longer than the duration of an application
stream, no change is necessary. On the other hand, we know that mobile
devices exist (specifically consider a suspended laptop) so from the
application perspective topology changes happen much more frequently
than they are ready to deal with. 

In terms of return on investment, I would argue that we should be
insisting that apps start using name strings in control blocks, and that
all the arcane cruft that we now call DNS get replaced by a distributed
database with minimal replication, and strong authentication of dynamic
bindings.

Tony