Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/sys/netinet6 sync with reality in netbsd-current.
details: https://anonhg.NetBSD.org/src/rev/836c7d64db67
branches: trunk
changeset: 486803:836c7d64db67
user: itojun <itojun%NetBSD.org@localhost>
date: Sun May 28 23:44:30 2000 +0000
description:
sync with reality in netbsd-current.
- pcb layer changes
- officially supported net interfaces
- minor typo
- draft # updates
diffstat:
sys/netinet6/IMPLEMENTATION | 195 +++++++++++++++++++++++++++----------------
1 files changed, 123 insertions(+), 72 deletions(-)
diffs (truncated from 431 to 300 lines):
diff -r c3e743b3c342 -r 836c7d64db67 sys/netinet6/IMPLEMENTATION
--- a/sys/netinet6/IMPLEMENTATION Sun May 28 23:12:15 2000 +0000
+++ b/sys/netinet6/IMPLEMENTATION Sun May 28 23:44:30 2000 +0000
@@ -1,4 +1,4 @@
-$NetBSD: IMPLEMENTATION,v 1.11 2000/03/22 08:20:18 itojun Exp $
+$NetBSD: IMPLEMENTATION,v 1.12 2000/05/28 23:44:30 itojun Exp $
# NOTE: this is from original KAME distribution.
# Some portion of this document is not applicable to the code merged into
@@ -8,7 +8,7 @@
KAME Project
http://www.kame.net/
- KAME Date: 2000/03/22 07:52:30
+ KAME Date: 2000/05/28 23:36:16
1. IPv6
@@ -91,24 +91,34 @@
RFC2732: Format for Literal IPv6 Addresses in URL's
* The spec is implemented in programs that handle URLs
(like freebsd ftpio(3) and fetch(1), or netbsd ftp(1))
-draft-ietf-ipngwg-router-renum-08: Router renumbering for IPv6
+draft-ietf-ipngwg-router-renum-10: Router renumbering for IPv6
draft-ietf-ipngwg-icmp-name-lookups-05: IPv6 Name Lookups Through ICMP
-draft-ietf-pim-ipv6-01.txt: PIM for IPv6
+draft-ietf-pim-ipv6-03.txt: PIM for IPv6
* pim6dd implements dense mode. pim6sd implements sparse mode.
-draft-ietf-dhc-dhcpv6-14.txt: DHCPv6
-draft-ietf-dhc-v6exts-11.txt: Extensions for DHCPv6
+draft-ietf-dhc-dhcpv6-15.txt: DHCPv6
+draft-ietf-dhc-dhcpv6exts-12.txt: Extensions for DHCPv6
* kame/dhcp6 has test implementation, which will not be compiled in
default compilation.
draft-itojun-ipv6-tcp-to-anycast-00.txt:
Disconnecting TCP connection toward IPv6 anycast address
-draft-yamamoto-wideipv6-comm-model-00.txt
- * See 1.6 in this document for details.
draft-ietf-ipngwg-scopedaddr-format-01.txt:
An Extension of Format for IPv6 Scoped Addresses
-draft-ietf-ngtrans-tcpudp-relay-00.txt:
+draft-ietf-ngtrans-tcpudp-relay-01.txt:
An IPv6-to-IPv4 transport relay translator
* FAITH tcp relay translator (faithd) implements this. See 3.1 for more
details.
+draft-ietf-ngtrans-6to4-05.txt:
+ Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels
+ * "stf" interface implements it. Be sure to read the next item before
+ configuring it, there are security issues.
+http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt:
+ Possible abuse against IPv6 transition technologies
+ * KAME does not implement RFC1933 automatic tunnel.
+ * "stf" interface implements some address filters. Refer to stf(4)
+ for details. Since there's no way to make 6to4 interface 100% secure,
+ we do not include "stf" interface into GENERIC.v6 compilation.
+ * kame/openbsd completely disables IPv4 mapped address support.
+ * kame/netbsd makes IPv4 mapped address support off by default.
1.2 Neighbor Discovery
@@ -180,6 +190,13 @@
We do not prohibit hosts from doing proxy ND, but there will be very limited
use in it.
+Starting mid March 2000, we support Neighbor Unreachability Detection (NUD)
+on p2p interfaces, including tunnel interfaces (gif). NUD is turned on by
+default. Before March 2000 KAME stack did not perform NUD on p2p interfaces.
+If the change raises any interoperability issues, you can turn off/on NUD
+by per-interface basis. Use "ndp -i interface -nud" to turn it off.
+Consult ndp(8) for details.
+
1.3 Scope Index
IPv6 uses scoped addresses. It is therefore very important to
@@ -446,15 +463,10 @@
address of the corresponding NS's target. In this case we follow
the spec rather than the above longest-match rule.
-For new connections (when rule 1 does not apply), deprecated addresses
-(addresses with preferred lifetime = 0) will not be chosen as source address
-if other choices are available. If no other choices are available,
-deprecated address will be used as a last resort. If there are multiple
-choice of deprecated addresses, the above scope rule will be used to choose
-from those deprecated addresses. If you would like to prohibit the use
-of deprecated address for some reason, configure net.inet6.ip6.use_deprecated
-to 0. The issue related to deprecated address is described in RFC2462 5.5.4
-(NOTE: there is some debate underway in IETF ipngwg on how to use
+If you would like to prohibit the use of deprecated address for some
+reason, configure net.inet6.ip6.use_deprecated to 0. The issue
+related to deprecated address is described in RFC2462 5.5.4 (NOTE:
+there is some debate underway in IETF ipngwg on how to use
"deprecated" address).
1.7 Jumbo Payload
@@ -510,20 +522,20 @@
option as well as AH).
There are fundamental issues in *BSD support for jumbograms. We would like to
-address those, but we need more time to finalize these. To name a few:
-- mbuf pkthdr.len field is typed as "int" in 4.4BSD, so it will not hold
+address those, but we need more time to finalize the task. To name a few:
+- mbuf pkthdr.len field is typed as "int" in 4.4BSD, so it cannot hold
jumbogram with len > 2G on 32bit architecture CPUs. If we would like to
support jumbogram properly, the field must be expanded to hold 4G +
IPv6 header + link-layer header. Therefore, it must be expanded to at least
int64_t (u_int32_t is NOT enough).
- We mistakingly use "int" to hold packet length in many places. We need
- to convert them into larger integral type. It needs a great care, as we may
+ to convert them into larger numeric type. It needs a great care, as we may
experience overflow during packet length computation.
- We mistakingly check for ip6_plen field of IPv6 header for packet payload
length in various places. We should be checking mbuf pkthdr.len instead.
ip6_input() will perform sanity check on jumbo payload option on input,
and we can safely use mbuf pkthdr.len afterwards.
-- TCP code needs a careful update in bunch of places, of course.
+- TCP code needs careful updates in bunch of places, of course.
1.8 Loop prevention in header processing
@@ -646,19 +658,18 @@
default: enabled
KAME/NetBSD configurable supported
default: disabled
-KAME/BSDI4 enabled supported (*)
+KAME/BSDI4 enabled supported
KAME/OpenBSD not supported not supported
-(*) on KAME/BSDI4, port number space is not always separated.
-
The following sections will give you more details, and how you can
configure the behavior.
Comments on listening side:
It looks that RFC2553 talks too little on wildcard bind issue,
-especially on the port space issue, failure mode and relationship
-between AF_INET/INET6 wildcard bind. There can be several separate
+specifically on (1) port space issue, (2) failure mode, (3) relationship
+between AF_INET/INET6 wildcard bind like ordering constraint, and (4) behavior
+when conflicting socket is opened/closed. There can be several separate
interpretation for this RFC which conform to it but behaves differently.
So, to implement portable application you should assume nothing
about the behavior in the kernel. Using getaddrinfo() is the safest way.
@@ -726,21 +737,15 @@
1.12.2.1 KAME/FreeBSD3x, listening side
The platform can be configured to support IPv4 mapped address/special
-AF_INET6 wildcard bind (enabled by default). Kernel configuration is
-summarized as follows:
-- By default, MAPPED_ADDR_ENABLED option is defined in the kernel
- configuration file. In this case, AF_INET6 socket will grab IPv4
- connections in certain condition. You can disable it with sysctl, or
- setsockopt.
-- If you remove MAPPED_ADDR_ENABLED option, the code to perform special
- behavior will not be compiled. It behaves as described in 1.12.1.
+AF_INET6 wildcard bind (enabled by default). There is no kernel compilation
+option to disable it. You can enable/disable the behavior with sysctl
+(per-node), or setsockopt (per-socket).
Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following
conditions are satisfied:
- there's no AF_INET socket that matches the IPv4 connection
- the AF_INET6 socket is configured to accept IPv4 traffic, i.e.
getsockopt(IPV6_BINDV6ONLY) returns 0.
-There's no problem with open/close ordering.
(XXX need checking)
@@ -782,7 +787,9 @@
- there's no AF_INET socket that matches the IPv4 connection
- the AF_INET6 socket is configured to accept IPv4 traffic, i.e.
getsockopt(IPV6_BINDV6ONLY) returns 0.
-There's no problem with open/close ordering.
+
+You cannot bind(2) with IPv4 mapped address. This is a workaround for port
+number duplicate and other twists.
1.12.3.2 KAME/NetBSD, initiating side
@@ -801,14 +808,11 @@
1.12.4.1 KAME/BSDI4, listening side
NRL inpcb layer supports special behavior of AF_INET6 wildcard socket.
-It grabs IPv4 connection under certain condition. NRL inpcb layer has
-different behavior than KAME implementation, namely:
-- If you bind(2) a socket to IPv6 wildcard address (::) then bind(2)
- another socket to IPv4 wildcard address (0.0.0.0), the latter will fail
- with EADDRINUSE.
-- If you bind(2) to IPv4 wildcard address then IPv6 wildcard address,
- both will success. However, all IPv4 traffic (and IPv6 traffic) will be
- captured by IPv6 wildcard socket.
+There is no way to disable the behavior.
+
+Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following
+condition is satisfied:
+- there's no AF_INET socket that matches the IPv4 connection
1.12.4.2 KAME/BSDI4, initiating side
@@ -891,6 +895,51 @@
KAME kernel will reject packets if the above addresses are used in IPv6
source/dstination address, or IPv6 routing header.
+1.15 Node's required addresses
+
+RFC2373 section 2.8 talks about required addresses for an IPv6
+node. The section talks about how KAME stack manages those required
+addresses.
+
+1.15.1 Host case
+
+The following items are automatically assigned to the node (or the node will
+automatically joins the group), at bootstrap time:
+- Loopback address
+- All-nodes multicast addresses (ff01::1)
+
+The following items will be automatically handled when the interface becomes
+IFF_UP:
+- Its link-local address for each interface
+- Solicited-node multicast address for link-local addresses
+- Link-local allnodes multicast address (ff02::1)
+
+The following items need to be configured manually by ifconfig(8) or prefix(8).
+Alternatively, these can be autoconfigured by using stateless address
+autoconfiguration.
+- Assigned unicast/anycast addresses
+- Solicited-Node multicast address for assigned unicast address
+
+Users can join groups by using appropriate system calls like setsockopt(2).
+
+1.15.2 Router case
+
+In addition to the above, routers needs to handle the following items.
+
+The following items need to be configured manually by using ifconfig(8).
+o The subnet-router anycast addresses for the interfaces it is configured
+ to act as a router on (prefix::/64)
+o All other anycast addresses with which the router has been configured
+
+The router will join the following multicast group when rtadvd(8) is available
+for the interface.
+o All-Routers Multicast Addresses (ff02::2)
+
+Routing daemons will join appropriate multicast groups, as necessary,
+like ff02::9 for RIPng.
+
+Users can join groups by using appropriate system calls like setsockopt(2).
+
2. Network Drivers
KAME requires three items to be added into the standard drivers:
@@ -917,8 +966,7 @@
Here is a list of FreeBSD 2.2.x-RELEASE drivers and its conditions:
- driver mbuf(1) multicast(2) official
- support?
+ driver mbuf(1) multicast(2) official support?
--- --- --- ---
(Ethernet)
ar looks ok - -
@@ -954,8 +1002,7 @@
The following lists BSD/OS 3.x device drivers and its conditions:
- driver mbuf(1) multicast(2) official
- support?
+ driver mbuf(1) multicast(2) official support?
--- --- --- ---
(Ethernet)
cnw ok ok yes
@@ -983,8 +1030,7 @@
The following table lists the network drivers we have tried so far.
- driver mbuf(1) multicast(2) official
- support?
+ driver mbuf(1) multicast(2) official support?
--- --- --- ---
(Ethernet)
awi pcmcia/i386 ok ok -
@@ -993,6 +1039,7 @@
ep pcmcia/i386 ok ok -
le sbus/sparc ok ok yes
ne pci/i386 ok ok yes
+ ne pcmcia/i386 ok ok yes
wi pcmcia/i386 ok ok yes
(ATM)
en pci/i386 ok ok -
@@ -1003,19 +1050,18 @@
Here is a list of FreeBSD 3.x-RELEASE drivers and its conditions:
- driver mbuf(1) multicast(2) official
- support?
+ driver mbuf(1) multicast(2) official support?
--- --- --- ---
(Ethernet)
+ cnw ok ok -(*)
+ ed ? ok -
Home |
Main Index |
Thread Index |
Old Index