unamanged solutions comments

[Pekka Savola <pekkas@netcore.fi>]

2.1	Evaluation of connectivity mechanisms

==> this needs to reworded or split: many of these are IMO not strictly
speaking connectivity mechanisms

2.1.2	6to4
Another potential limitation of the technology is the reliance on
publicly accessible "6to4 relay routers" that accept packets from
6to4 routers and relay them to the "regular" IPv6 Internet. These
relays all listen to the same IPv4 anycast address [RFC3056], which
enables gateways to start operating as 6to4 routers without
requiring any explicit configuration. As the deployment of IPv6
progresses, a growing fraction of the traffic originating from 6to4
routers will have to be carried through these relays, potentially
leading to severe congestion of the relays.

==> There are two problems with relays:
 1) configuring the relay on 6to4 router; anycast address helps a bit there.
 2) v6 nodes finding the closest relay advertising 2002::/16.  This is not
addressed here, and I think is a major problem: there is zero guarantee
about how unoptimal the return path is (you can make some assumption about
the forward path, to the 6to4 relay close to you)!

2.1.6	SIIT

Stateless IP/ICMP Translation Algorithm (SIIT) is a generic
translation mechanism between IPv4 and IPv6. The main
characteristics of DSTM are as follow:

==> s/DSTM/SIIT/

2.1.7	NAT-PT

particular, the specification discusses a DNS ALG that would enable
the NAT-PT system to reply with a "translated" record, e.g. a AAAA
record contained the IPv6-mapped IPv4 address of an IPv4 only host,
or a A record containing the IPv4 address statically assigned to an
IPv6 only host.

==> mapped address is NAT64 semantic, not NAT-PT.

2.1.10	DSTM

DSTM may have a role to play in the transition of large network, or
in that of ISP networks, but its role in the transition of unmanaged
networks is thus marginal at best: it does not support IPv6 only
hosts, and it does not provide an operational advantage in the
unmanaged network.

==> Some generalized form of DSTM could be implemented in case D
(e.g. gateway performing DSTM tunneling function and providing v4 to the
local v4-only nodes)

3.1.3	MDNS

-- discussion of [MDNS] --

==> I'm not sure how LLMNR is all that applicable (at best, if there's a
disconnected site scenario).

3.1.6	Reverse lookup wildcard

1234:5678:9ABC::1 by providing a pointer to either "1234-5678-9ABC-
0-0-0-0-1.example.net", or "1234-5678-9ABC-0-0-0-0-
1.foo.example.net" - i.e. with or without an identification of the
client's account in the pointed name. Privacy advocates will
probably insist that ISP do not include client identification in
such pointers, as this would negate all benefits of privacy
addresses.

==> or e.g. 0-0-0-0-1.foo.example.net.
==> "foo" is unlikely a clearly identifiable (like a surname) so "foo" or
the prefix (assuming it's static) will reveal the same thing anyway.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords