Subject: PPP and VLAN link-local addresses

From: "Sean Lin" <[email-masked]>
Date: Fri, 15 Feb 2002 11:53:24 +1300 (NZDST)

Hi,
	I was wondering if this has been mentioned before. Will there be 
adverse effects( is this allowed in the first place?) from modifying the 
link-local address from

16    16    16    16    16    16    16    16 bits
fe80   0     0     0   <-------eui-64 id--->

to
16    16    16    16    16    16    16    16 bits
fe80   0   <--vlan-->  <-------eui-64 id--->
		or ppp ID

so as to have the last 32 bits of the hgiher 64 bits of the link-local
address to represent the interface ID or the VLAN or PPP ID. Or is this 32-
bits reserved for something else?
	Also, I take it that the global bit in the eui-64 identifier will 
still be set if the above format is allowed?

Regards,
Sean

-------------------------------------------------------------
Sean Lin                 27 Nazareth Avenue
Software Engineer        PO Box 8011
Allied Telesyn Research  Christchurch
phone +64 3 339 3000     New Zealand
fax   +64 3 339 3002     email: [email-masked]
                         web: http://www.alliedtelesyn.co.nz/
-------------------------------------------------------------

--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Fri, 15 Feb 2002 15:34:17 +0100

In your previous mail you wrote:

   	I was wondering if this has been mentioned before. Will there be 
   adverse effects( is this allowed in the first place?)

=> this is NOT allowed and is not useful (link-local addresses are
bound to a link, there is no need to say which link inside the address).

   so as to have the last 32 bits of the hgiher 64 bits of the link-local
   address to represent the interface ID

=> I believe you mean the interface index. Was proposed and rejected.
IMHO this is a very bad idea because the interface index is local to
the node.

   or the VLAN

=> a VLAN is a link.

   or PPP ID.

=> what is a PPP ID?

=> the "g" bit of the modified EUI-64 format is a property of the
interface ID, not of the address. The only relation between addresses
and interface ID format is the modified EUI-64 is mandatory for interface
IDs which are part of unicast (anycast too) addresses which are not
in the ::/3 prefix.

Regards

[email-masked]

---

From: "Sean Lin" <[email-masked]>
Date: Thu, 21 Feb 2002 12:41:50 +1300

>
>   | I was wondering if this has been mentioned before.
>
> It has been discussed before.   It is a truly wonderful idea...
>
> If it could be done, there'd be no adverse effects, the problem
> is how the extra identifier gets distributed to the nodes.   Your
> average system has no idea what its vlan-id might happen to be (not
> that there's any reason to restrict the usage that way).

it doesn't matter i reckon. I mean from the other nodes point of view it's
just another link-local address ( well, as long as
when it determines what the address type is, it matches for fe80::/10 and
not
fe80::/64

>
> It cannot use the net to discover the id, as at the stage it is
> configuring its link local address, it has no way to use the net.
>
> The earlier suggestion kept the 0's in the format on the wire, and
> just used the id for local internal identification (within the node).
> That means that each node cinvent its own numbers, they don't need to
> be consistent with those chosen by anyone else.   But having the
> address the node uses different from the one passed to other nodes
> complicates any protocol that actually uses the value of the address
> (the node has to know to use the address with the ID in it for addressing,
> but the address with 0's replacing the ID for all other purposes, which is
> messy).
>
> In any case, this suggestion went nowhere.

as long as the node continues to use,e.g. fe80::1:2c0:dfff:fe07:6d62 for the
specified
interface i don't see why this would be a problem to other nodes. Only when
implementations start matching
to the /64 boundary instead of the /10 boundary this may be a problem.

using the format fe80::<id>:<interface-id>, would allow a single link-local
addresses
to be shared among various interfaces on the node and will also enable the
node to determine
which interface a destination link-local address is going out of. Also, why
not fe80:<zone-id>::<interface-id>
instead of address%<zone-id>? Then you wouldn't have problems described in
draft-ietf-ipngwg-scoping-arch-03.txt for URLs

but then again it would be difficult to say fe80:eth0::<interface-id> or
fe80:vlan0::<interface-id>
unless you can map eth0 and vlan0 or vlan1 to a standardised numerical index
or value.

Regards,
Sean

---

From: Robert Elz <[email-masked]>
Date: Thu, 21 Feb 2002 10:59:31 +0700

Date:        Thu, 21 Feb 2002 12:41:50 +1300
    From:        "Sean Lin" <[email-masked]>
    Message-ID:  <005d01c1ba68$2b360450$4e07a8c0@tukia>

I don't think there is a lot of point having this discussion again, so
this will be my last message about it, but ...

  | I mean from the other nodes point of view it's
  | just another link-local address ( well, as long as
  | when it determines what the address type is, it matches for fe80::/10 and
  | not fe80::/64

But that, and ...

  | using the format fe80::<id>:<interface-id>, would allow a single link-local
  | addresses
  | to be shared among various interfaces on the node and will also enable the
  | node to determine
  | which interface a destination link-local address is going out of.

that are incompatible.   Either the <id> specifies the interface (and thus
is a part of the prefix, not the per link identifier), or it does not, you
can't really have it both ways.

You also need to consider what happens when the address reaches another
node, consider A which has 5 interfaces (1, 2, 3, 4, 5 are the id's we'll
assign to those), and B which also has 5 interfaces (and big surprise,
since it comes from the same vendor, it also calls them 1 2 3 4 5).  Then
know that the link from interface 2 on A connects to interface 4 on B.

Now A sends a packet from its LL addr   fe80::2:wwww:xxxx:yyyy:zzzz
B gets that packet and wants to reply to that address, the '2' in there
was A's interface number, means nothing to B at all (certainly sending
out interface 2 won't work).

It is possible to make all of this work (B would see the packet arrived on
the interface it calls 4, and rewrite the address to fe80::4:wwww:xxxx:yyyy:zzzz
but now the nodes need to be aware that the <id> part of the
address is volatile.

The other approach, and the one that was actually suggested when this
was proposed, is for A to actually put fe80::wwww:xxxx:yyyy:zzzz in the
packets it sends.  This allows B to just use current methods if it
prefers, and means that everyone can predict what the address on the wire
will be, which simplifies (a little) the protocol implications.  That
is, the id in the LL address would be used only in the API, not on the wire.

  | Also, why
  | not fe80:<zone-id>::<interface-id>
  | instead of address%<zone-id>? Then you wouldn't have problems described in
  | draft-ietf-ipngwg-scoping-arch-03.txt for URLs

Yes, that was the attraction of this approach, it would simplify the user
interface (and API)_, at the expense of complicating the protocols.

I suspect that the decision is mostly based upon the observation that
the human interface to link local addresses is very rarely ever used,
most applications will be told to use other addresses, most of the time.
Only net manager type people are likely to manually ever use LL addresses
(especially when there is more than one active link to cause confusion).

And most of the API details can be buried inside library routines, so
applications mostly don't have to care wither way.

On the other hand, all protocols have to deal with the possibility that
they might be told to use LL addresses, and so everything is going to have
to deal with the implications of that if the addressses suddenly started
to contain volatile components (something different on the wire, or at
the remote node, from what the application sees).

In any case, you can rest assured that this was all considered in the
past (5-6 years ago now I think) - it isn't just something that no-one
considered.

kre