v6only operation comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

A few comments on roy-v6ops-v6onbydefault-00.  In general, I think it's 
very useful to explore the issues, but it seems to me that there are some 
underlying assumptions which may have led to some questionable 
conclusions.

Some comments have probably already been mentioned before, but here goes 
anyway...

   For an IPv6 enabled host deployed on a network that has no IPv6
   routers, the result is that link-layer address resolution must be
   performed on all IPv6 destinations to which the host sends packets.

==> prior to that, default address selection is performed; if the source is
link-local and destination is global, the packet is never sent off the node.
This should prevent issues when the node has only link-local addresses.

   The Default Address Selection for IPv6 [2] destination address
   selection mechanism, if used by applications, would minimize the
   problem by placing IPv6 addresses at the end of the list of
   addresses returned by name lookups.  The host has only generated a
   link-local address, so the scope of IPv6 destinations won't match
   any possible IPv6 source.

==> source address selection works too :-)

   An example of such a network is an enterprise network that has both
   IPv4 and IPv6 routing within the enterprise and has a firewall
   configured to allow some IPv4 communication, but no IPv6
   communication.

==> wrong deployment, sorry :-(
==> in this case, the router(s) should either be configured with a null
default route variant which would send unreachable is no network is found,
or alternatively, have no default routes at all (avoids the problem)

   To allow applications to correctly fall back to IPv4 when IPv6
   packets are destined beyond their allowed scope, the devices
   enforcing the scope boundary should send ICMP Destination
   Unreachable messages back to senders of such packets.

==> would transport protocols heed these soft errors?  better than discard,
surely, of course!

   This has the negative side-effect that these nodes will almost never
   use IPv6 unless the only address published in the DNS for a given
   name is IPv6., presumably because of this phenomenon.

==> s/.,/,/
==> this is something to consider in a bigger scale, in deployments.  People
would populate IPv6-only zones if this approach would be a common practise.

   collocated with a firewall, but more difficult if internal nodes do
   their own IPv6 tunneling.
==> s/col/co-/

   returned from a name lookup when attempting connections works in
   most cases for most applications, but there are still cases where
   that's not enough.  Applications also need to be aware that the
   fact that a dual stack destination's IPv6 address is published in
   the DNS does not imply that all services on that destination
   function over IPv6.

==> s/imply/necessarily imply/!

==> I consider models where someone publishes www.foo.com with A+AAAA but
doesn't support HTTP over v6 a User Error.  Of course, one _should_ be 
able to recover from that, but some service degradation is acceptable.

   Applications should not assume that because a service is reachable at
   an IPv6 address, that other services at that destination are also
   reachable via that IPv6 address.

==> getaddrinfo loop ends at the wrong place, it should try connect first, I
guess?

7.  References

==> split refs

   [1] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP
      Version 6 (IPv6)", RFC 2461, December 1998.

   [2] R. Draves, "Default Address Selection for IPv6",
      draft-ietf-ipv6-default-addr-select-09.txt, August 2002.

==> wrong format for refs, authors surname first

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings