Subject: (IPng 6776) IPv6 link local address

From: Yixin Jin <[email-masked]>
Date: Tue, 24 Nov 1998 12:47:23 -0800 (PST)

Hi folks,

In IPv6 spec, it only says that link local address should be unique on a
single link. There is the possiblity that we can assign the same
link-local address to 2 different interfaces in the same node. 

It really makes some porting work very hard since in IPv4 world, you can
use IP address to identify an interface. 

In IPv6, since link local address is always assigned, it makes prefect
sense to use link local address to identify the interface, just like IPv4
does. But if the same link local address is assigned to different
interfaces, we have to choose other thing, like interface index/name, to
identify the interface.

Is there any reason not to force link local address be unqiue in the same
node?

Thanks a lot

Yixin Jin
UCLA, Computer Science Dept.

--------------------------------------------------------------------
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: Wed, 25 Nov 1998 09:52:37 +0100

In your previous mail you wrote:

   

=> even one can answer that with the new sin6_scope_id a sockaddr_in6
structure in the link-local scope is not ambiguous there are some places
where an address alone (ie a struct in6_addr) is used, for instance
in the DHCPv6 I-D. Then I agree: we should ban all usages of link local
addresses without the interface (then the interface is enough) or
make the use of the same link local address on more than one interface
"not recommended" (or stronger negative statement).

[email-masked]

---

From: Jun-ichiro itojun Itoh <[email-masked]>
Date: Wed, 25 Nov 1998 18:16:18 +0900

>"not recommended" (or stronger negative statement).

	Even if we make sure the above, we're in the trap if your node has
	two interfaces and incidentally same interface ID appears on the
	both side.  We can't prevent this from happening by the above
	restriction.
		somehost1
		  | fe80::x	<--- oops
		==+=== 
		  | fe80::y
		your host
		  | fe80::z
		==+===
		  | fe80::x	<--- oops
		somehost2

	KAME implementation annotates link-local addresses by interface index,
	in the kernel structures only (such as routing tables), like:
		if ne0 interface has interface index of 3, then fe80::x on ne0
		interface will appear as fe80:3::x on routing table.
	In this way there is no ambiguity in the addresses visible to the
	kernel code.
		somehost1
		  | fe80:1::x
		==+=== 
		  | fe80:1::y	ifindex=1
		your host
		  | fe80:2::z	ifindex=2
		==+===
		  | fe80:2::x
		somehost2

	Userland program sees standard link-local address (fe80::x) only.
	If userland program needs interface index, the program should use
	advanced API.  Also, the embedded interface index will never appear
	on the wire.

	It is too hard to use sockaddr_in6 structure throughout the kernel,
	due to the following reasons:
	- It requires too many changes in the kernel...
	- We usually do not pass source and destination address to ip6_output()
	  as separate argument.  They are in the IPv6 header part, and there's
	  no place to embed sockaddr_in6 structure in struct ip6_hdr.
	  Interface index must be embedded somewhere in ip6->ip6_src.

[email-masked]
jun-ichiro itoh

---

From: Jun-ichiro itojun Itoh <[email-masked]>
Date: Wed, 25 Nov 1998 18:43:36 +0900

>>"not recommended" (or stronger negative statement).

	Oops, forgot to mention this:
	You can safely guess the interface index for link-local address in
	dhcpv6 packet, by interface index for inbound interface.  dhcpv6
	server must use advanced API.
	(sorry if I'm mistaking something)

itojun

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Nov 1998 15:57:55 +0100

=> the problem is in the relay (but the address is "a non-link-local
address of its interface" where the client is then it is not exactly
the same problem (but still "an address gives not an interface" issue).

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Nov 1998 15:24:02 -0800 (PST)

> 	advanced API.  Also, the embedded interface index will never appear

Presumably the userland program can use sin6_scope_id as well and you can
have the kernel use the internal representation of your own choice.
My point is that the advanced API shouldn't be required.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Nov 1998 15:19:50 -0800 (PST)

> use IP address to identify an interface. 

That isn't really true in the IPv4 world since many implementations support
the notion of unnumbered pt-pt links. For example this is what I can
have on Solaris:
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 index 1
	inet 127.0.0.1 netmask ff000000 
le0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 index 2
	inet 129.146.86.131 netmask ffffff00 broadcast 129.146.86.255
ipdptp0: flags=10028d1<UP,POINTOPOINT,RUNNING,MULTICAST,UNNUMBERED> mtu 8232
index 5
	inet 129.146.86.131 --> 1.2.3.4 netmask ffff0000 
ipdptp1: flags=10028d1<UP,POINTOPOINT,RUNNING,MULTICAST,UNNUMBERED> mtu 8232
index 6
	inet 129.146.86.131 --> 2.3.4.5 netmask ffff0000 

This is part of the reason the IPv6 API is using interface indicies to identify
interfaces (for IPV6_MULTICAST_IF etc) since those are always unique.

> interfaces, we have to choose other thing, like interface index/name, to

Which is what the API already requires.

Do you have an example of applications where this becomes terribly hard to
do?

> Is there any reason not to force link local address be unqiue in the same

That would require that all Ethernet cards on a machine have a unique 
MAC address which has not been true for all implementations.
For instance, it is not until recently that Sun has started supplying
unique MAC addresses for each card. Without rat-holing into the historical
discussion, this is due to the Ethernet spec talking about "stations" having
a unique Ethernet address and some early protocols (XNS I believe) assumed
that all cards on a station had the same MAC address.

Thus we don't want to require unique Ethernet addresses for all cards.

   Erik

---

From: Yixin Jin <[email-masked]>
Date: Wed, 25 Nov 1998 17:19:51 -0800 (PST)

> 	inet 129.146.86.131 --> 2.3.4.5 netmask ffff0000 

OK, it is a good example. Actually, gated with dvmrp is another example.
Then it is dealing with physical interface, it uses IP address. But when
it is dealing with tunnels, it uses index.

> Do you have an example of applications where this becomes terribly hard to

gated.

I think the reason that there are many applications in IPv4 world using IP
address identifying interface is that it works most of the time. But it
won't be true in IPv6 world. Anyway, it just makes porting work harder,
not for brand new applications.

Thanks

Yixin

---

From: Jun-ichiro itojun Itoh <[email-masked]>
Date: Thu, 26 Nov 1998 10:37:20 +0900

>My point is that the advanced API shouldn't be required.

	sin6_scope_id will be filled by our kernel too.  sorry for many
	mistakes in the previous email.

itojun