update comments:

  - RFC2292bis -> RFC3542
  - typo fixes

Submitted by:	Keiichi SHIMA <keiichi__at__iijlab.net>
Obtained from:	KAME

1 files changed, 11 insertions, 11 deletions

diff --git a/sys/netinet6/ip6_output.c b/sys/netinet6/ip6_output.c
index 1d8459b..110d203 100644
--- a/sys/netinet6/ip6_output.c
+++ b/sys/netinet6/ip6_output.c
@@ -1701,7 +1701,7 @@ do { \
 					/*
 					 * We ignore this option for TCP
 					 * sockets.
-					 * (rfc2292bis leaves this case
+					 * (RFC3542 leaves this case
 					 * unspecified.)
 					 */
 					if (uproto != IPPROTO_TCP)
@@ -1810,7 +1810,7 @@ do { \
 			case IPV6_RTHDRDSTOPTS:
 			case IPV6_NEXTHOP:
 			{
-				/* new advanced API (2292bis) */
+				/* new advanced API (RFC3542) */
 				u_char *optbuf;
 				int optlen;
 				struct ip6_pktopts **optp;
@@ -2269,9 +2269,9 @@ ip6_raw_ctloutput(so, sopt)
 		 * For ICMPv6 sockets, no modification allowed for checksum
 		 * offset, permit "no change" values to help existing apps.
 		 *
-		 * XXX 2292bis says: "An attempt to set IPV6_CHECKSUM
+		 * RFC3542 says: "An attempt to set IPV6_CHECKSUM
 		 * for an ICMPv6 socket will fail."
-		 * The current behavior does not meet 2292bis.
+		 * The current behavior does not meet RFC3542.
 		 */
 		switch (op) {
 		case SOPT_SET:
@@ -3060,8 +3060,8 @@ ip6_setpktoptions(control, opt, stickyopt, priv, needcopy, uproto)
  * item.  "len" can be 0 only when it's a sticky option.
  * We have 4 cases of combination of "sticky" and "cmsg":
  * "sticky=0, cmsg=0": impossible
- * "sticky=0, cmsg=1": RFC2292 or rfc2292bis ancillary data
- * "sticky=1, cmsg=0": rfc2292bis socket option
+ * "sticky=0, cmsg=1": RFC2292 or RFC3542 ancillary data
+ * "sticky=1, cmsg=0": RFC3542 socket option
  * "sticky=1, cmsg=1": RFC2292 socket option
  */
 static int
@@ -3081,8 +3081,8 @@ ip6_setpktoption(optname, buf, len, opt, priv, sticky, cmsg, uproto)
 
 	/*
 	 * IPV6_2292xxx is for backward compatibility to RFC2292, and should
-	 * not be specified in the context of rfc2292bis.  Conversely,
-	 * rfc2292bis types should not be specified in the context of RFC2292.
+	 * not be specified in the context of RFC3542.  Conversely,
+	 * RFC3542 types should not be specified in the context of RFC2292.
 	 */
 	if (!cmsg) {
 		switch (optname) {
@@ -3108,7 +3108,7 @@ ip6_setpktoption(optname, buf, len, opt, priv, sticky, cmsg, uproto)
 		case IPV6_USE_MIN_MTU:
 		case IPV6_DONTFRAG:
 		case IPV6_TCLASS:
-		case IPV6_PREFER_TEMPADDR: /* XXX: not an rfc2292bis option */
+		case IPV6_PREFER_TEMPADDR: /* XXX: not an RFC3542 option */
 			return (ENOPROTOOPT);
 		}
 	}
@@ -3339,7 +3339,7 @@ ip6_setpktoption(optname, buf, len, opt, priv, sticky, cmsg, uproto)
 			 * part of the destination options header must appear
 			 * before the routing header in the ancillary data,
 			 * too.
-			 * RFC2292bis solved the ambiguity by introducing
+			 * RFC3542 solved the ambiguity by introducing
 			 * separate ancillary data or option types.
 			 */
 			if (opt->ip6po_rthdr == NULL)
@@ -3428,7 +3428,7 @@ ip6_setpktoption(optname, buf, len, opt, priv, sticky, cmsg, uproto)
 		if (uproto == IPPROTO_TCP || *(int *)buf == 0) {
 			/*
 			 * we ignore this option for TCP sockets.
-			 * (rfc2292bis leaves this case unspecified.)
+			 * (RFC3542 leaves this case unspecified.)
 			 */
 			opt->ip6po_flags &= ~IP6PO_DONTFRAG;
 		} else