unmaneval comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Below are more more substantial comments to unmaneval; I'll send the 
editorial ones separately (maybe to the authors directly).

I've concentrated on non-connectivity related parts only.

I'm not sure of the document contents and reorganization.  Currently it's
very heavily built apon different mechanisms or protocols needed for the
the unmanaged.  Those should be included, of course, but what would be
more useful is having a bit more background and discussion so that the
document would be potentially useful in addition as a mechanism to mandate
the specification of mechanisms Foo, Bar and Baz.  One problem is of 
course also that there are some very generic issues which are pretty much 
common to each of the scenarios A-D, maybe it would make sense to describe 
these issues first in a common section, and go to scenario-specific 
details separately.

substantial
-----------

1) I did not want to go to the connectivity parts at this point because it's
a topic that we have difficulties getting basic understanding on.  I'll just
correct the most obvious problems in the current text.

There seem to be some implied assumptions which are not shared, which is
probably one reason why different folks are speaking across each other:

2.1.4   Recommendation

   Teredo appears to be a good fit for providing IPv6 connectivity to
   hosts behind NAT, in case A of IPv6 deployment. The service is
   designed for minimizing the cost of deploying the server, which
   matches the requirement of minimizing the cost of the "supporting
   infrastructure" for peer-to-peer applications.

==> you seem to assume that peer-to-peer applications are the reason to
deploy v6 and Teredo, and that all the peers would implement Teredo (and be
behind particular kinds of NATs) so that all the traffic between them would
flow smoothtly.  I do not share these assumptions.

More:

   To gauge the difference, we consider the case of a host engaging in
   Voice over IP: it will maintain its address reachable all the time,
   and it will send a large amount of traffic whenever it is engaged in
   a conversation. According to classic figures collected by AT&T, the
   average duration of a conversation is around 100 seconds, and a
   business telephone is likely to be engaged in a conversation about
   10% of the time, which implies starting a conversation on average
   every 1000 seconds. The average load sent by a tunnel client to the
   tunnel server will be 10% of the average data rate of the client;
   assuming a 16kbps codec and 50 packets per second, the data rate of
   the client sums up to about 51 kbps, hence an average load on the
   tunnel server of 5 kbps. The load sent by the tunnel client to the
   tunnel server will be about one exchange of bubble per minute, to
   defend the address, plus one bubble exchange at the beginning of
   each session with a new peer; adding all headers, the bubble size is
   about 144 bytes, which results in about 20 bps of traffic on the
   server. In short, the amount of traffic seen by the Teredo server is
   250 times less that the traffic seen by a Teredo client.

==> with your very specific assumptions about p2p applications and all the
peers supporting Teredo, this may be close to the mark.  In general, it is
*very far* from the mark.  With Teredo, the relays see the "250 times more
traffic" (minus what goes directly), not the Tunnel Brokers.  So the
overheads are probably pretty equivalent except for the packets that
traverse directly between the Teredo nodes.

   The tunnel approach is more expensive to provide, because the tunnel
   server will have to carry a much larger amount of traffic. It is
   unclear that a tunnel service can be provided as an almost free
   "supporting infrastructure", except perhaps if the service was
   directly provided by the same ISP that already provides IPv4
   connectivity to the unmanaged network.

==> Teredo relays just have to bear that traffic except for Teredo-Teredo
-traffic, instead of tunnel servers.  Big deal.

2) I think the security sections need more text especially in the cases 
where NAT traversal is being done, but otherwise as well.

   A characteristic of case A is that a host located behind a NAT
   acquires global IPv6 connectivity, using either Teredo or an
   alternative tunneling mechanism. If no precaution is taken, there is
   a risk of exposing to the global Internet some applications and
   services that only expected to serve local hosts, located behind the
   NAT. Developers and administrators should make sure that the global
   IPv6 connectivity is restricted to only those applications that are
   expressly designed for global Internet connectivity.

==> I think we must be careful not to disturb the perceived 
"security model" of NATs etc. -- so we could e.g. state here like:

  For example, enabling IPv6 connectivity through a firewall or NAT should
  require explicit configuration from the user (with sufficient education
  on the dangers thereof), or there should be on-by-default stateful 
  firewall configuration, which would default to "NAT-like" rules, 
  allowing everything out but nothing but related sessions in.

3) case B assumes that the ISP and the gateway are dual-stack.  This seems
to imply that the link to the ISP would also be dual-stack, and it would be
enabled for use.  Is there a need to mention in particular the scenario
where the ISP would offer IPv6 over a tunnel to the gateway -- isn't this
missing from scenarios?

   In case B, we assume that the gateway and the ISP are both dual
   stack. The hosts on the local network may be IPv4 only, dual stack,
   or IPv6 only. The main requirements are: prefix delegation, and name
   resolution. We also study the potential need for communication
   between IPv4 and IPv6 hosts, and conclude that a dual stack approach

4) RA proxy mechanism should probably be replaced by a ND proxy, but the
main point for this "prefix delegation" scenario is IMO to better describe
why exactly RA/ND proxy would be useful here.  Maybe it should highlight its
usefulness if the ISP only gives a /64 prefix (for example)?  etc.

3.1.1   RA proxy

   The implicit delegation mechanism assumes that the gateway is
   connected to the ISP by a point-to-point link. Examples of such
   point to point links are various types of configured tunnels and
   serial links, for example using PPP. The principle of RA proxy is
   simple: the gateway issues a "router solicitation" message on the
   serial link, receives a "router advertisement", learns a network
   prefix from the advertisement, and advertises the same prefix on the
   unmanaged network.

5) the explicit prefix delegation section does not describe the requirements
for advertising the subprefixes to the downstream links, right?

Also note that some form of manual prefix delegation could be possible, even
though maybe not as flexible.

6) section 3.3.2 discusses the ways of publishing v6 addresses using
different means and concludes DDNS is needed.  What would be interesting to
know whether there are any issues in the DDNS which do not work at the
moment, need spcial attention, etc. ?

Moreover, please explain how the nodes will use DDNS in this scenario, as it
isn't clear.  There may be some issues in taking it into use..

   Dynamic configuration using the same type of ad hoc protocols that
   are common today is indeed possible, but the IETF should encourage
   the use of standard solutions based on DDNS.

7) The DNS resolving for local hosts needs a bit of beefing up..:

   When a DNS server is used, this server could in theory be located
   anywhere on the Internet. There is however a very strong argument
   for using a local server, which will remain reachable even if the
   network connectivity is down.

==> naturally, one probably important feature there is also being able to
include services/nodes which (even though possibly using global addresses)
are not meant for the generic consumption of all Internet users..
(I don't feel strongly about this point though)

   The use of a local server requires that IPv6 capable hosts discover
   this server, as explained in 3.3.1, and then that they use a
   protocol such as DDNS to publish their IPv6 addresses to this
   server.

==> this also implies that the DNS server explained in 3.3.1 actually
*allows* for the use of DDNS for these updates.   How is the security of
DDNS achieved?  Which domain/zone is used to do the updates (i.e., how do
the users/hosts know that)?

   An alternative to using a local server is LLMNR, which uses a
   multicast mechanism to resolve DNS requests. LLMNR does not require
   any service from the gateway, and also does not require that hosts
   use DDNS. LLMNR relies on multicast for its operation. There are
   scaling issues with using multicast, as the procedure may become
   very chatty in large networks; but this is not a practical problem
   in most unmanaged networks.

==> remove the last sentence, it is not relevant for the unmanaged
networks.

==> does enabling LLMNR have special config requirements, e.g. regarding the
stack or the apps?

8) link-locals and apps; I'm very strongly opposed to thinking that
link-local addresses are valid for generic consumption for apps for
on-link traffic:

 Local applications, for
   example, could be restricted to only use link-local addresses, or
   addresses whose most significant bits match the prefix of the local
   subnet.

9) 6to4 mechanism has something like:

   There are three possible ways to alleviate this congestion. First,
   one can hope that many actors will deploy 6to4 relay routers, in
   order to facilitate the deployment of IPv6; congestion would be
   alleviated by the provision of a large number of gateways. Second,
   one could develop some "route optimization" process, so that the
   traffic would flow through a "shortcut path" rather than through the
   6to4 relays; the relays would then avoid congestion by carrying only
   a small fraction of the traffic. Third, if neither the first nor the
   second solution materializes, some gateways may enter into
   contractual agreements with relay service providers; in this case,
   the 6to4 technology would become merely a variant of the configured
   tunnel technologies.

==> the "Second, ..." point can IMO be removed.  I don't see a way to do
that.

On the other hand, if you want to describe the methods to alleviate the
scaling problems of 6to4, one thing to say might be that the nodes not
needing it would just enable it *in addition to* their other v6
connectivity.  In this way, the load on the relays would decrease.  However,
I'm not sure this is a good idea, but if you want to add a consideration for
scaling mitigation, that might be one way...

10) in section 4.1.3, it is clear that ISATAP is NOT applicable within the
unmanaged network.  The only place where it could even be *considered* is as
a mechanism between the ISP and the home user, if the home user gets zero
public IPv4 addresses, but its ISP would be willing to provide v6 to the
users via an ISATAP services.. (I think this is pretty close to what you say
later on)..

(Of course, one could wonder why such an IPv6-willing ISP would not provide
v6 services natively or using some other mechanism but.... :-)

   In theory, ISATAP could be used to provide hosts in an unmanaged
   network with IPv6 connectivity; the gateway might function as an
   ISATAP router. However, in a single subnet deployment, this solution
   is markedly inferior to native IPv6: it incurs more overhead, and is
   not easier to deploy.

11) actually, the naming requirements in case C (B but ISP not dual stack)
seem to be potentially slightly different.  At least, if the gateway does
not act as a proxy DNS server for v6-only hosts, it isn't possible to obtain
the v6 DNS server address from the ISP, right?

4.2     Naming requirements in case C

   Naming requirements are similar to case B.




semi-substantial
----------------

 A mechanism of bubbles, relayed by the servers, is
   used for establishing contacts between Teredo nodes, or for
   discovering the appropriate Teredo relay serving an IPv6 peer; the 
   actual IPv6 packets are carried in UDP packets exchanged directly
   between the nodes, or exchanged through the relay serving an IPv6
   peer.

==> s/the nodes/the Teredo nodes/
==> s/an IPv6 peer/non-Teredo IPv6 peers/

(especially the first edit is very important..)

5       Meeting the case D requirements

   In case D, the ISP only provides IPv6 services.

5.1.1   IPv6 addressing requirements

==> you are missing "5.1" section there..

5.3     Security requirements

   Security requirements in case D are analogous to those of case B.
   The use of a tunneling mechanism to provide IPv4 connectivity may
   introduce its own security issues, but the analysis of these issues
   can only be performed after this tunneling mechanism is fully
   designed.

==> security requirements for v6-only case are probably a bit different from
the rest.  I'd assume that by then the users would be used to a "no-NATs"
model...

6       Provisional recommendations

==> I think it would be useful to try to prioritize and order these somehow,
like "critical for deployment", "important", "to be done later".

12      References

   Normative references

==> there are no informative refs at all?

==> note that a large number of these are not being used in the document
anymore and can be removed.


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