[src/trunk]: src/sys/net update comment (analysis on 04 draft)

[itojun <itojun%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/5dbbe11f1992
branches:  trunk
changeset: 485159:5dbbe11f1992
user:      itojun <itojun%NetBSD.org@localhost>
date:      Fri Apr 21 02:40:53 2000 +0000

description:
update comment (analysis on 04 draft)

diffstat:

 sys/net/if_stf.c |  10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diffs (31 lines):

diff -r 9f484ded96ad -r 5dbbe11f1992 sys/net/if_stf.c
--- a/sys/net/if_stf.c  Fri Apr 21 02:39:55 2000 +0000
+++ b/sys/net/if_stf.c  Fri Apr 21 02:40:53 2000 +0000
@@ -1,5 +1,5 @@
-/*     $NetBSD: if_stf.c,v 1.1 2000/04/19 06:30:53 itojun Exp $        */
-/*     $KAME: if_stf.c,v 1.31 2000/04/19 05:51:20 itojun Exp $ */
+/*     $NetBSD: if_stf.c,v 1.2 2000/04/21 02:40:53 itojun Exp $        */
+/*     $KAME: if_stf.c,v 1.32 2000/04/21 02:39:43 itojun Exp $ */
 
 /*
  * Copyright (C) 2000 WIDE Project.
@@ -44,7 +44,7 @@
  * Here are interesting symptoms due to the lack of link-local address:
  *
  * Unicast routing exchange:
- * - RIPng: Impossible.  Uses link-local multicast packet toward ff02::2,
+ * - RIPng: Impossible.  Uses link-local multicast packet toward ff02::9,
  *   and link-local addresses as nexthop.
  * - OSPFv6: Impossible.  OSPFv6 assumes that there's link-local address
  *   assigned to the link, and makes use of them.  Also, HELLO packets use
@@ -62,7 +62,9 @@
  *
  * 04 draft suggests to have link-local address onto 6to4 interface.
  * However, it seems to have no real use and does not help the above symptom
- * much.
+ * much.  Even if we assign link-locals to interface, we cannot really
+ * use link-local unicast/multicast on top of 6to4 cloud, and the above
+ * analysis does not change.
  *
  * 6to4 interface has security issues.  Refer to
  * http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt