Subject: [Saad] About forwarding tags

From: Pekka Nikander <[email-masked]>
Date: Tue, 28 Oct 2003 11:27:14 +0200

> So in the Internet architecture, IP addresses serve at least these three
> functions:
> 
> 1 - Identify an end-end entity
> 2 - Describe where its interface(s) is in the network (location)
> 3 - Serve as a forwarding tag for packets.

I think this is a very important point, and worth pursuing much more.
(I am also looking forward to more brain torque with more functions
of IP addresses...)  To start with, a small observation:

- In a vanilla IP-layer router, the forwarding tag is the
   destination address.

- In a QoS-enabled router, the forwarding tag is something more,
   e.g. <dst addr, flow label>

- In a NAT box, the forwarding tag depends on the direction of the
   traffic, and for inbound traffic it is typically <dst, proto, dport>
   but may be even smaller (e.g  <proto, dport>) or larger
   (<src, dst, proto, sport, dport>), depending on implementation.
   [I hope I got it right, I am not a NATologist.]

And the maybe more important one:

- If IPsec is used, or if a new "session ID" is introduced (as in SIM),
   the <dst addr, SPI> or <dst addr, session ID> could be used as a
   forwarding tag, thereby enabling cross-realm communication.

Hence, the important question is whether we want to limit our
considerations to solutions where the forwarding tag is solely
the IP address or whether we want to consider the cases where
it actually is or can be something more.  A related question is
whether it is acceptable to rewrite forwarding tags on the fly.

--Pekka Nikander

_______________________________________________
Saad mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/saad

---

From: Dave Crocker <[email-masked]>
Date: Fri, 31 Oct 2003 08:13:35 -0800

Folks,

>> 3 - Serve as a forwarding tag for packets.

PN> I think this is a very important point, and worth pursuing much more.

Normally, this sort of careful distinction sits quite well with me, too.
However in this case, I suspect it is creating a difference that is not as
real as it seems.

Here's my thought:

A reference string must balance between the needs of higher functionality and
lower functionality. (In some cases, the altitude of the functionality is not
a different layer. For example, we have quite a few different things going on
inside IP. For this discussion, I am postulating some sort of internal
hierarchy for them.)

We need to describe how the reference string is used, in relation to those
higher and lower functions.

For example, note the change in perspective for the above list. The first two
entries describe informational roles, while the third describes a functional
role. I think the reason for this disparity is that the _purpose_ of a locator
(#2 on the list) is to serve as a forwarding tag (or, at least, as part of
one.) Take that purpose away and we really do not need locators.

An identifier serves to uniquely distinguish one component from another. The
"higher" functionality for an identifier only needs the uniqueness. The
"lower" functionality needs to be able to map the identifier to another
reference, such as a locator. Any information aggregation (hierarchy) built
into an identifier is typically based on administrative relationships.

A locator enables routing. The "higher" functionality for a locator needs
unique identification. The "lower" functionality for a locator needs to
perform routing. Any information aggregation build into a locator needs to
facilitate routing table efficiencies. Given the nature of routing, this means
that aggregation needs to be based on topology, or something related to
topology. (I'm trying to leave room for geographic addresses.)

The danger in having the list of 3 labels is that it will lead to thinking
that we really do need 3 labels.

We don't.  We need two.

Making specific choices for the two labels requires looking at when, where and
how they need to be used. For example, as NOID notes, it is ok to use a public
key if its computational overhead is used only occasionally. Similarly, a
reference used in every datagram needs to be as short as feasible.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>