[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Input on draft-ietf-v6ops-v6onbydefault-00.txt below. This will be a
good BCP IPv6 Operational RFC to publish is my input.
Neighbor Discovery's [ND] conceptual sending algorithm dictates that
when sending a packet to a destination, if a host's default router
list is empty, then the host assumes that the destination is on-link.
Suggest replace "dictate" with "suggests or states" in the first
sentence. Rationale is the conceptual sending algrithm is not required
to be implemented in ND. Dictate as word seems inappropriate.
For an IPv6 enabled host deployed on a network that has no IPv6
routers as is the case in this scenario, the result is that
link-layer address resolution must be performed on all IPv6 addresses
to which the host sends packets.
If IPv6 is enabled this resolution in most cases before the node
completes booting to the user interface. So link-layer address
resolution was done anyway. I don't get what the negative concern is in
the above sentences.
The Application will not receive
acknowledgment of the unreachability of destinations that are not
on-link until at least address resolution has failed, which is no
less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), plus
any transport layer connection timeouts which could be minutes in the
case of TCP. The delay with respect to TCP is discussed later in
It seems to me a real good implementation feature for a network OS
subsystem kernel would be to have a conditional test if any IPv6 route
exists early in the stack if dst is IPv6.
If IPv6 hosts don't assume that destinations are on-link as described
above, then communication with destinations that are not on-link and
unreachable will immediately fail.
Nodes should only assume this if they received an RA prefix set with L
bit set. Otherwise they should not assume this or they are not
compliant to ND. If nodes have received the L bit and prefixes after
the check I suggest above the next check would be if any prefixes have
been announced and if not rejection could take place then. But, some
may suggest that always send the packet somewhere for some deployment
scenarios I can think of, but not many.
The IPv6 implementation should be
able to immediately notify applications that it has no route to such
IPv6 destinations, and applications won't waste time waiting for
address resolution to fail.
This is a good suggestion, given the dst address was not on link and
known from the L bit. But, whether this works is dependent on the API
capability of the application and passing up dst unreachable as a note.
If hosts need to communicate with on-link destinations, then then
they need to be explicitly configured to have on-link routes for
This is a strong statement. So the spec is saying unless a node
receives an L bit set with prefix set do not attempt communications with
onlink nodes, I assume except for link-local addresses. As a general
rule this might be good, but not as an absolute rule.
The on-link assumption is problematic in ways not directly related to
the scenario described, but they should still be briefly mentioned
One problem is that default routes are not special. The on-link
assumption as stated in [ND] would have a host assume that all
destinations are on-link when its default router list is empty.
I don't see ND stating that at all? Can you point to the text that
causes you to believe this? Unless an L bit set with prefix set has
been received a node can make no actual assumption except guess, when
there is no default router available or router for a dst route.
Clearly it shouldn't make this assumption if it has an off-link route
that covers the destination and that route isn't a default route.
The absence of a default route does not mean that destinations are
not reachable through more specific routes.
Agree. But isn't this just an example of a very bad implementation of
IPv6 and common sense to most engineers that build IP stacks? But ok by
me if we want to point this out.
Another problem is that the on-link assumption behavior is undefined
on multi-homed hosts.
Not quite absolute. Each link is known if it received an L bit with
prefixes. on-link behavior has to be considered link by link case within
an implementation, whether they are multihomed nodes or not. Whether
the node knows that it has another link to send a packet to for IPv6 is
orthognal to IPv6 being on be default, which is a premise for this spec.
Not saying IPv6 does not have more work to do on multihoming, but
possibly this problem is another section? It is not caused by on-link
assumptions in the implementation.
When such a host has no default routers and it
is trying to reach a destination to which it has no route, should it
try NUD on all interfaces at once?
That is an implementation decision, not standards decision.
Should it simply realize that the
destination is unreachable? The latter is the simplest solution.
Determining that a destination is unreachable when there is no route
to that destination is the simple solution for all cases, not just
the multi-homed case.
But if node knows from L bit prefixes it can tell if the dst is on-link
and an optimization that is important to several user network
operations. Using the feature of ND L bit with prefix set helps avoid
just sending directly on the link when no route is present for a dst or
a default route.
3.2 Poor IPv6 Network Performance
By default in dual stack nodes, applications will try IPv6
I don't tbink we can say this nor is it required. This will be a
configuration option is my belief for users to decide for their network.
If the IPv6 connectivity to those destinations
is poor while the IPv4 connectivity is better (i.e., the IPv6 traffic
experiences higher latency, lower throughput, or more lost packets
than IPv4 traffic), applications will still communicate over IPv6 at
the expense of network performance. There is no information
available to applications in this case to advise them to try another
This is why a good implementation will permit address selection to be
configured and dynamically too.
Good Analysis and Work Thanks,
IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6