Subject: RE: [Fwd: [Saad] Some initiating thoughts...]

From: "Michel Py" <[email-masked]>
Date: Thu, 16 Oct 2003 22:16:46 -0700

Leslie,

> Leslie Daigle wrote:
> I posted this a few days ago -- before, I think, people had
> a chance to get subscribed

IMHO, this text is a good short assessment of the situation. Needs some
more work, but a good base.

> [draft-iab-addressing-2003815.txt]
> Although it is not strictly required, the IPv4 address
> architecture largely assumed a unique binding of a device
> interface to an IP address. Essentially this means a
> device interface existed as a member of a single
> addressing realm.

With IPv6, a large number of issues with SLs and scoping are a direct
consequence of the disappearance of this unique binding. Save for LLs
which are a different kind of animal because they are not routable, the
very assumption of multiple addresses per host has caused us a lot of
trouble.

IMHO the only way we could make any kind of scoping architecture work is
to accept the following restriction:

If scope is to be used, a host can have only two IPv6 addresses per
interface: a link-local and another one, which would be routable but
with possibly a have limited reachability depending on the scope. It
would then be a design element to decide to use either multiaddressing
or scoping.

The idea behind scoping is that it should be a largely-automatic access
control system, likely as a fail-safe for explicit filtering or
firewalling. This means that hosts would not need to be aware of the
scope except to make the distinction between LL and routable.

Note that, for a many enterprise operators, the "restriction" of having
only two addresses per host per interface which is very similar to the
existing IPv4 situation is a feature, not a bug. Regardless of issues
with scoping, multiple routable addresses per interface simply are too
much complication. I am not saying that multiadressing is bad, what I am
saying is that multiaddressing does not work in certain situations.

This list is focused on scoping. I am aware that some identifier/locator
solutions propose that the IPv6 address is used only as a locator, the
identifier being a different type of animal.

In the situations where scoping is desired, the way out IMHO is that the
host's routable address is the identifier (the reason being it would be
a lot simpler to scope than a flexible-shape identifier) and that there
is a shim layer between Transport and Network that does the identifier /
locator mapping.

Michel.

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

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 17 Oct 2003 19:03:22 -0400

> From: Leslie Daigle <[email-masked]>

    > I'm attaching a pre-draft that was prepared by IAB member Mark Handley

I have a number of comments, but this one is important enough that I thought
I'd send it along separately - it makes a point about IP addresses that I'm
not sure people are keeping in mind.

    > 2.  Background
 
    > IP addresses have served both as a means of uniquely identifying a
    > device interface that is attached to a network (an endpoint
    > identifier)

This is broken terminology. The term "endpoint identifier" identifies it an
*end-end* entity - i.e. something that is the termination of an end-end
communication (see:

    http://users.exis.net/~jnc/tech/endpoints.txt

for more). An "interface" is obviously not such an entity. (And in MIPv6 this
is clear, because the end-end entity keeps its identity even when it has a
new name for its interface.)

IP addresses also do identify interfaces - but that's a separate function
(see the next comment).

    > and as a means of identifying where a device is located
    > within the network (a forwarding or routing identifier).

Actually, IP addresses have *three* roles (actually there are several more,
but let me torque peoples' brains incrementally :-), and the last clause here
("where a device ... forwarding") conflates two of them.

I have described a functionality which I call a "forwarding tag", which is
"the bits in a packet header that a switch looks at to tell it how to forward
the packet". Now, in IPvN, the "address" field(s) in the header are the
forwarding tag, so people tend to think of the "address" namespace as having
forwarding functionality. However, this is not necessarily so - e.g. in pure
circuit ATM the forwarding tag is *not* an address, and addresses have no
forwarding function.

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.

Identifying an interface (previous comment) is a fourth, less important one
(that's kind of mixed up with number 2 above). That this is a separate
function is easy to see - IEEE 48-bit numbers identify interfaces, but don't
tell you where in the Internet they are.

	Noel