huitema-v6ops-unmaneval-00 comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Here's my 2 cents worth of comments for the unmanaged evaluation.

non-editorial:
--------------
2	Meeting case A requirements
   
   In case A, IPv6 capable hosts located behind a NAT need to acquire
   IPv6 connectivity. In this section, we first evaluate how mechanisms
   already defined or being worked on in the IETF meet this
   requirement. We then consider the "remaining holes" and recommend
   specific developments.

==> In case A, it may be that you don't have NAT at all.  In fact, I 
believe this is quite typical for e.g. dialup/ISDN, even some cable/DSL 
users.
==> I've been trying to push this in the scenarios doc but with little 
success as of yet..
   
   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.

==> a reality check here would be useful: do you really expect business
telephones to emerge *at large* behind unmanaged NAT's, and engage in
conversation with other Teredo clients (and not the other IPv6
infrastructure) -- in the latter case, they'll have to pass through the
relay anyway, generating the same amount of traffic.
   
   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.

==> how about the traffic at the teredo relay boxes? :-)
   
   The two approaches have much in common: both need to parameterize a
   client with the name of a server and with sufficient credentials;
   the encapsulation is similar; both use the same encapsulation
   mechanism; and both will use router solicitations to obtain an
   address prefix. The main difference is the handling of bubbles in
   Teredo, which are used to defend the address and to initiate
   sessions with peers. This is obviously more complex than sending the
   packet without any processing, but the complexity is only marginally
   higher than the discovery of link layer addresses using neighbor
   discovery. In short, Teredo is more complex, but the complexity is
   not overwhelming.

==> instead of one peer and a standard set of solutions we have N peers and
relay architecture

   Manual configuration of stable addresses is not satisfactory in an
   unmanaged IPv6 network: the prefix allocated to the gateway may or
   may not be stable, and in any case copying long binary addresses
   through a manual procedure is error prone.

==> these justifications are about equally applicable to IPv4 as IPv6 in case _B_
(in case A, it might be a different story if NAT mappings are more
change-prone) -- binary addresses is not a big problem, if it comes down to
that, it'd be just a matter of cut'n'paste.
==> I'd say "manual configuration ... should be avoided if possible".
   
3.3.3	Resolving local IPv6 addresses
   
   There are two possible ways of resolving local IPv6 addresses: one
   may either publish the IPv6 addresses in a local server, or one may
   use a peer-to-peer address resolution protocol such as link local
   multicast name resolution [LLMNR].

==> please tell me again why these local addresses (I'm assuming this is an
edito from earlier versions) cannot be published in the global DNS? 
Assuming that they aren't site-locals, that is.  

==> Of course if you want them
to work properly even when the net connectivity is down, it's 
understandable to have some mechanism -- but you should really say that 
too (and consider whether some other elements might also stop working in 
the sporadically connected case).
   
   The case B solutions provide global IPv6 connectivity to the local
   hosts. Removing the limit to connectivity imposed by NAT is both a
   feature and a risk. Implementations should carefully limit global
   IPv6 connectivity to only those applications that are specifically
   designed to operate on the global Internet.

==> should one provide more analysis or recommendations on issues like this
(think of bellovin's access-prefix or brian zill's similar work, for
instance)


editorial:
----------
                                                            NLnet Labs
==> Initial only, Ronald :-)

   In a companion paper we defined the "unmanaged networks" scope,
   which typically correspond to home networks or small office
==> s/correspond/corresponds/ (the same in introduction)

   networks, and the requirements for IPv6 transition mechanism in that
   scope. We start from this analysis and evaluate here the suitability
   of mechanisms defined in the NGTRANS working group.

==> move the table of contents here
==> typically the ISOC copyright statement is also here   

   dual stack. This issue is discussed in detail in a companion paper
==> s/paper/memo/

   The issues involved are described in the next sections. This
   analysis outlines two types of requirement: connectivity
==> s/requirement/requirements/

2.1.1	TEREDO
   
   TEREDO is a mechanism designed to provide IPv6 connectivity to hosts
==> s/TEREDO/Teredo/

2.2	Security considerations in case A
==> upper case first chars in (most) words
   
3.2	Communication between IPv4-only and IPv6-only hosts
==> s/hosts/nodes/g (many places in this and following sections)   

   
   6to4 routers and relay them to the "regular" IPv6 Internet. These
   relays all listen to the same IPv4 anycast address [RFC3056], which
==> that address is in 3068 :-)

11	References
   
   [UNMANREQ] Unmanaged Networks Transition Scope. Work in progress.
   
   [NATPTBISSUES] Issues when translating between IPv4 and IPv6. Work
   in progress.
   
   [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
   Specification", RFC 2460, December 1998.
==> refs need to be split
==> reference format is  not right, Surname, initial. 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