Subject: Re: Enforcing unreachability of site local addresses

From: Dan Lanciani <[email-masked]>
Date: Sat, 1 Feb 2003 02:27:52 -0500 (EST)

David Conrad <[email-masked]> wrote:

|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?.

Sure, this has been proposed before, but I think the main complaint was
that 64 bits is no longer enough for the wasteful allocation policies we
have adopted.  I used 128 bits in my original proposal just to avoid the
objection that we would be giving anything up in that respect.

|> 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.

You have to translate somewhere, if not at the bottom of the host's stack
then at what you are calling edge routers.

|> With a little care, multi-homing could be supported.
|
|Multi-homing would be trivial.

Some care would be required to get failover to work.  This isn't completely
trivial, but it need not be a big deal.

|The lower 64 bits of the destination would be put into an 
|in-addr.arpa-like tree,

I like my specialized mapping service, but sure...

|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.

I proposed to short-circuit the timeout by having nodes try where possible
to give a hint to known peers that a renumbering event had occurred.  This
can also be handled either at the end points or at the edge routers.

There is an infinite variety of these mapping schemes, most any one of which
would solve the portable identifier problem.  Unfortunately, proposing one
always provokes someone to claim that: (a) solving the portable identifier
problem is equivalent to solving the non-aggregated routing problem and (b)
we do not know how to solve the non-aggregated routing problem therefore (c)
the portable identifier problem cannot be solved so easily.  Of course (a) is
likely true in the sense that the solutions are isomorphic in some abstract way.
We are really talking about source routing with an extra level of indirection
to make the route look more like an address.  That's not entirely unreasonable
given that the locator addresses we use in a hierarchical allocation system are
really close to being routes.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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: David Conrad <[email-masked]>
Date: Sat, 1 Feb 2003 00:41:00 -0800

Dan,

On Friday, January 31, 2003, at 11:27  PM, Dan Lanciani wrote:
> have adopted.

Given there is no need for hierarchy, there is no need for wasteful 
allocation policies (the end point addresses could be allocated 
sequentially FCFS or even randomly).  I have a bit of trouble believing 
18,446,744,073,709,551,616 sequentially assigned addresses would be 
insufficient for "the foreseeable future".

> then at what you are calling edge routers.

I guess it is a question of terminology:  there is no translation done 
on the end point identifiers, thus they can be encoded into higher 
layer protocols (e.g., ftp) without need of NAT gymnastics.  The only 
"translation" done would be the zeroing out of the high order 8 bytes 
on reception at the destination edge router which would presumably be 
faster than a table lookup.

> trivial, but it need not be a big deal.

I would assume the edge router would 'know' the reachability of the 
prefixes returned by the DNS query allowing for failover to be handled 
the same way it is handled today (more or less).  Simple AS hop games 
can be played to pick the 'best'.

> I like my specialized mapping service, but sure...

I'd honestly be happy with either.  The advantage I see in the DNS is 
that it exists, is relatively well understood, and has the necessary 
attributes (global scalability, security (if you believe  DNSSEC will 
ever be deployed), and caching).  However, we have learned a lot about 
what the DNS got wrong and a new mapping service could allow us to 
finally put a bullet in DNS's head...

> can also be handled either at the end points or at the edge routers.

Right (I think -- I had suggested the edge routers act as forwarding 
agents for a TTL, is this what you mean by short-circuiting?)

In any event, from my perspective the big problem with this approach, 
regardless of whether the DNS is used or not, is the need for edge 
routers at both ends to be involved.  This results in a chicken and egg 
problem that I'm not sure how to get around.  Oh yeah, and traceroute 
from the end points would be useless.

However, this (and similar) approaches have the advantage that we 
continue to use known technology (CIDR,BGP4+,etc) in the core where it 
matters...

Rgds,
-drc