Subject: (ngtrans) About Tunnel Addressing in IPv6 Practice

From: Maoke Chen <[email-masked]>
Date: Tue, 23 Nov 1999 17:14:51 +0800 (CST)

Hi, folks,

I'm one of the staff members of the CERNET IPv6 Testbed (p-TLA 
3ffe:3200::/24). I have some questions about the tunnel addressing
in our practice.

It seems to me that IPv6 implementors have their own understanding 
towards the tunnel concept, various from each to another. In the result,
tunnel addressing in different implementations are different. 
We have experienced with KAME/FreeBSD, INRIA/FreeBSD, Linux and some
router vendors' beta-version products. It appears to me that RFC2473 and
draft-ietf-ngtrans-mech-04.txt are not adequate to clarify the conceptions
of tunnel. The main questions are as follows.

1. Tunnel interface addresses' prefix length

   INRIA stack provides a rc.ipv6 example where a /128 prefix was 
   suggested for a configureable tunnel interface (cti). KAME's default 
   prefix length is 64. I have seen some one using /126 prefix. All the 
   things above are working. But I'm not sure about the interconnectivities.

2. Tunnel interface's link-local addressing

   In KAME stack (I'm using version on 19990131), a specific link-local 
   prefix is assigned to each interface, physical or virtual (tunnel).
   e.g. fe80:1::/64 to the ethernet interface and fe80:2::/64 to the first
   tunnel interface. 

   I'm not clear about the thought of KAME behind the implementation. 
   On one hand, this makes each interface in different link-local block 
   from any others and this is clear in routing conception. To contrast,
   the fe80::<v4 addr>/64 addressing style (draft-ietf-ngtrans-mech-04.txt,
   Section 3.7)  has some disadvantages when more than one tunnel made over 
   a same IPv4 interface. Logically, two tunnels is two different links 
   (though virtual), but they have the same entry address. 

   On the other hand, KAME tunnel addressing confuses the uni- and bi-
   directional tunnel conceptions. E.g., I use fe80:7::/64 to tunnelling 
   with you, while you have ever used this prefix with another one and 
   have to use e.g. fe80:8::/64, then is this tunnel uni-directional 
   or bi-directional? Furthermore, what if your implementation doesn't 
   allow non-fe80::/64 prefix at all? 

   This will have impact to the routing protocols. E.g., can RIPng
   work well in the case above that two adjacent tunnelled point see the 
   tunnel in different ways?

What is my comments to tunnel addressing?

1. A link-local must be assigned to a tunnel end point. (This is 
   consistant with draft-ietf-ngtrans-mech-04.txt.)
   Must the logical interfaces be configured with link-local prefixes, 
   different from each interface to another? The answer depends on the
   link-local address logic!

2. For a tunnel, indicate the IPv6 address of the remote endpoint only when 
   assigning the link-local address. After that, a tunnel must treated as 
   same as a real interface. Thus, when configuring a global address, it is
   not needed to provide any information about the remote endpoint.

3. ( More amazing ) can we recommend that all next-hops in a IPv6 routing 
   table must be link-local?

I'd like to ask you if we need an internet-draft to clarify all the 
questions above. If so, I'm willing to take the job.

Just my own opinions. If I'm confusing something, please indicate. 
Comments and recommendation can be sent to the list or to my mailbox
(mailto: [email-masked]).

Thanks,
Maoke

---

From: Francis Dupont <[email-masked]>
Date: Tue, 23 Nov 1999 19:19:17 +0100

In your previous mail you wrote:

   It seems to me that IPv6 implementors have their own understanding 
   towards the tunnel concept, various from each to another.

=> I agree!

      INRIA stack provides a rc.ipv6 example where a /128 prefix was 
      suggested for a configureable tunnel interface (cti).

=> for me only 64 and 128 are valid prefix length. 64 should be the default
and 128 was for tunnels without ND, RIPng, ...
Today I believe 64 prefix length and link-local addresses only is the best
answer to the "unnumbered interface" case but we had some problems with
scope IDs before RFC 2553.

=> interface implies link-local addressing!

   1. A link-local must be assigned to a tunnel end point.

=> I agree.

=> unfortunately this is not possible for all implementations and
there still are some cases where a global address of the peer is needed.
I have changed the behevior of my ifconfig in order to copy the interface
ID of the peer in the case the user doesn't provide it. Usually nothing
fails when a global peer address is wrong (squared low probability :-).

=> this should work but:
 - MUST is obviously too strong
 - in fact for point-to-point interfaces the only useful information
   is the interface to use
 - is your purpose to fill your mail-box in some hours (:-)?

   questions above.

=> draft-ietf-ngtrans-mech-04.txt is supposed to clarify this but
perhaps the authors will accept some help?

Regards

[email-masked]

PS: a case where a global peer address is needed is for mobility:
if you'd like to communicate with the peer system you don't need
its address when the tunnel is available but when it is not you need
a global address which is not always sent in router advertisements...
This is an issue for any kind of point-to-point links where the
"other end" is too easy!

---

From: [email-masked]
Date: Wed, 24 Nov 1999 06:30:08 +0900

>   I'm not clear about the thought of KAME behind the implementation. 

	If you are talking about 4th octet, please check IMPLEMENTATION
	document contained in the kit (noone seem to go through those
	documents...).  The 4th octet is just for kernel internal use and
	will not appear on the wire.

	Or, upgrade to more recent version which hides those detail
	on ifconfig output.

itojun

---

From: [email-masked]
Date: Wed, 24 Nov 1999 10:23:55 +0900

>   table must be link-local?

	This is correct, as ICMPv6 redirect works only when nexthop is
	linklocal.  We should not put IPv6 global addres into nexthop field
	of the routing table.

itojun

---

From: Maoke Chen <[email-masked]>
Date: Wed, 24 Nov 1999 10:00:00 +0800 (CST)

> From [email-masked] Wed Nov 24 05:32:17 1999
> To: Maoke Chen <[email-masked]>
> cc: [email-masked]
> Subject: Re: (ngtrans) About Tunnel Addressing in IPv6 Practice 
> From: [email-masked]
> Date: Wed, 24 Nov 1999 06:30:08 +0900
>
>

This time I understood. I had read the documents earlier but I had no 
feelings about KAME stack at that time.  

Thanks!

> 	Or, upgrade to more recent version which hides those detail

Hmm...then the excellent kernel-used interface index would be hidden.:-)

> itojun

Best,
maoke

---

From: Maoke Chen <[email-masked]>
Date: Wed, 24 Nov 1999 10:30:44 +0800 (CST)

> From [email-masked] Wed Nov 24 02:21:26 1999
>

Will you please explain the concepts for the /128 prefix, i.e. why 
it is should be ( or could be ) used when there was no ND nor RIPng?

  (If I have missed some information in INRIA stack docs, I have to say
   sorry.)

> scope IDs before RFC 2553.

Could you give me some imformation about what you said "had some problems"?
Thanks!

best,
Maoke

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Nov 1999 09:32:46 +0100

=> /128 prefixes are not fully legal and can give trouble when
a legal prefix (ie. a /64 prefix) is needed, but they are cheap
(they don't waste any address space :-) and can give a good abstraction
of "don't matter with the other end address, it is just simply the
other end" idea. ND and RIPng use link-local addresses which must
be in the link-local prefix, ie. fe80::/64 (some of them say fe80::/10
but all defined interface ID formats have 64 bits).

=> a link-local address without a scope ID (ie. an interface index) is
useless, for instance you can give the same link-local address to many
possibly different nodes on different links. Before RFC 2553 the only
solution was to use in6_pktinfo in every applications using link-local
addresses, now a scope ID is included in the sockaddr_in6 structure
(this is simpler even some issue remains).

Regards

[email-masked]

PS: this is my last answer with a copy to the ngtrans list.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Nov 1999 15:31:32 -0800 (PST)

> perhaps the authors will accept some help?

I wouldn't mind help with some clear concise text once we have rough consensus
on what to say.

But the draft is currently on IESGs plate (we've been iterating and I'm 
preparing an update to address their concerns and clarifications).
So if we are going to add more clarification regarding configured tunnels
we need to do it sooner rather than later.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Nov 1999 15:36:17 -0800 (PST)

>    e.g. fe80:1::/64 to the ethernet interface and fe80:2::/64 to the first

The above issues is not tied to tunneling.
I suspect that even with two Ethernets KAME will assign :1::/64 and :2::/64
for the link-locals.
This has been discussed on the ipng list.

>    link-local address logic!

I'd agree with both.

>    not needed to provide any information about the remote endpoint.

Do you mean the non-link-local address of the remote endpoint?

When configuring a bidirectional tunnel which is used by routing
protocols like RIPng and OSPF you need link-local addresses for
both ends since these protocols communicate using link-locals.
I don't know what types of addresses are needed when
running e.g. BGP4+ over the tunnel.

>    table must be link-local?

This will be the case if you use RIPng and OSPF.
But I assume e.g. BGP4+ will use other next-hops. Is my assumption correct?

   Erik

---

From: [email-masked]
Date: Mon, 29 Nov 1999 11:48:04 +0900

>But I assume e.g. BGP4+ will use other next-hops. Is my assumption correct?

	You can establish EBGP using link-local only, if the BGP4+
	implementation is clever enough about handling nexthops in BGP4+
	packet (I do this everywhere with zebra implementation).
	For IBGP we need to use globals (or site-local, if you would like to
	allow router renumbering).

	IIRC there are some trikcy issues in BGP4+ nexthop handling.  I hope
	some KAME/zebra guy remembers the detail...

itojun