Subject: Re: Enforcing unreachability of site local addresses

From: Dan Lanciani <[email-masked]>
Date: Sat, 1 Feb 2003 12:35:17 -0500 (EST)

David Conrad <[email-masked]> wrote:

|On Friday, January 31, 2003, at 11:27  PM, Dan Lanciani wrote:
|> |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.
|
|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".

I was actually referring to the practice of inserting 48-bit (or even 64-bit)
hardware identifiers into the address in the name of easy configuration.

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

Even if you don't consider the zeroing a translation (and I would probably
debate this if it made any difference), the mapping of (0, 64-bit identifier)
to (64-bit locator, 64-bit identifier) is certainly a translation as much
as the mapping of (128-bit identifier) to (128-bit locator).  The property
of being able to encode the identifier into higher-layer protocols without
the need for NAT gymnastics is a function of hiding the translation from
all the higher layers, not of the simplicity of the translation function.
My proposal also hides the locator and thus has the same property.

|> |> 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.
|
|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 would not want to depend on the edge router's having that kind of knowledge
of the locator routing system just to make multi-homing work for other sites.
(It would be one thing to require multi-homed sites to do this, but you are
talking about making everybody do it.)  I think it would be better to explicitly
track only those targets that are being used.  Hopefully icmp messages could do
most of the work along with something akin to stale route discovery.

|> 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.
|
|Right (I think -- I had suggested the edge routers act as forwarding 
|agents for a TTL, is this what you mean by short-circuiting?)

I'm not sure what you meant by forwarding.  I simply meant that a node
or edge router that is renumbered can send an alert to its known peers
suggesting that they dump their cached data even though its TTL has not
expired.

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

My proposal can definitely work (and was originally intended to work) directly
on end nodes.  It can be pushed into edge routers as well, but it doesn't have
to be.  But it isn't obvious to me why your version can't work on an end node
too.

|Oh yeah, and traceroute 
|from the end points would be useless.

If the translation happens at the end nodes I would obviously propose an
escape mechanism in the API to deal with locators instead of identifiers.
Obviously we would want to discourage use of this escape by other than
debugging programs. :)

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

That advantage makes for a good thought experiment, i.e., to show anyone with
an open mind that it can be done.  Whether we really want to help perpetuate
the current archaic routing system by building a layer like this is still open
to debate.  Clearly adding a layer is better than doing nothing; however, I'd
like to think that we can ascertain a pure routing solution that is isomorphic
to the split solution.  Again, we are really talking about source routing and
there are quite a few ways to implement source routing.

				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 11:54:27 -0800

Dan,

> hardware identifiers into the address in the name of easy 

One allocation mechanism is pretty much as good as any other.  Doesn't 
matter how those 48  or 64 bit numbers are allocated, the EUI registry 
would be fine.  What matters is there is a separation and a mapping 
between those identifiers and locators.

> as the mapping of (128-bit identifier) to (128-bit locator).

I agree that the terminology doesn't matter (I actually viewed it more 
along the lines of pushing a locator onto the address at ingress, 
popping it off at egress -- I liked the x-kernel work of long ago).  
What is important is the separation of the locator from the end point 
and the ability to map between the two.

> My proposal also hides the locator and thus has the same property.

Yup.  I was merely making the assumption that zero'ing would be faster 
than table lookup and copying.  However, given this is an edge 
function, it probably doesn't matter all that much.

> of the locator routing system just to make multi-homing work for other 

Hmmm.  Multiple ways to solve this, of course.   E.g.: the source edge 
router does a lookup, gets back a bunch of locators.  A naive 
implementation could simply pick one and forward to the core via 
default.  Getting back a network unreachable could trigger the naive 
implementation to pick a different locator.  The more elaborate the 
edge router gets in terms of routing system knowledge, the more 
effective the multi-homing would be.

> I'm not sure what you meant by forwarding.

The old destination edge router gets a packet for an end point 
identifier that has left the network the old edge router is responsible 
for.  The old edge router does a lookup of the destination identifier, 
gets the new locator (if it doesn't already have it), and forwards to 
the new edge router.  It would need to do this for the TTL of the old 
locator.  This is why I believe this approach would work with mobility 
-- in this context, mobility is just a more dynamic form of 
renumbering.  Yes there may be security issues here in the general case 
-- need to think about it more.

> to be.  But it isn't obvious to me why your version can't work on an 

It would.  The reason I favor the edge router approach is that I wanted 
something that would work with IPv4 as a transition aide...

> Whether we really want to help perpetuate
> to the split solution.

Baby steps...

Rgds,
-drc