Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt]

[Pekka Savola <pekkas@netcore.fi>]

Hi,

A couple of personal comments.  In short I think the doc is in pretty 
good shape.  I think the target audience of this document is mainly 
out-of-the-IETF folks who may not be all that v6-savvy.  I call this a 
"techno-political document", and hence important.

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

11.  References

11.1  Normative References

11.2  Informative References

==> Normative references section should nonempty.  I suggest moving at least
RFC1918, RFC2663, RFC2461, RFC3022, RFC2993, RFC3027, RFC3041, RFC3315,
RFC3484, RFC3633, draft-ietf-v6ops-renumbering-procedure and
draft-ietf-ipv6-unique-local-addr up there.

semi-editorial
--------------

 However, if a site is connected to its ISPs via NAT
   boxes, only those boxes need to deal with multihoming and renumbering
   issues.

==> s/only/sometimes only/ -- for small SOHOs the above is typically true,
but if you put e.g. servers inside the NAT, you will need to deal with these
issues in other boxes as well..?

   While the primary implementation and source of randomized RFC 3041
   addresses is expected to be from end systems running stateless
   autoconfiguration, there is nothing that prevents a DHCP server from
   running the RFC 3041 algorithm for any new IEEE identifier it hears,
   then remembering that for future queries.  This would allow using
   them in DNS for registered services since the assumption of a server
   based deployment would be a persistent value that minimizes DNS
   churn.

==> I'm not sure what the last sentence tries to say, in any case, I think
it's at least partially incorrect.  You can do DNS updates with RFC3041
addresses without DHCP as well.  This sentence seems to be hinting that DHCP
provides some exceptional otherwise unttainable features with RFC3041
addresses.

   ULAs have the following characteristics:
   o  Globally unique prefix
      *  Allows networks to be combined or privately interconnected
         without creating any address conflicts or requiring renumbering
         of interfaces using these prefixes
      *  If accidentally leaked outside of a network via routing or DNS,
         there is no conflict with any other addresses

==> it should be clarified that this Globally unique prefix characteristic
is *compared to RFC1918*, not compared to IPv6 global prefixes!  It is not
clear whether you're comparing against IPv4 privates or IPv6 globals..

 There is no reason that rack mounted devices shouldn't be
   considered mobile nodes to mask the internal topology.  It looks
   equivalent to running a VPN to a central server, however it does not
   involve any encryption or significant overhead.

==> s/shouldn't/couldn't/ otherwise this looks weird??
==> this does raise some SPoF concerns however..

   o  The technology to enable source-routing on a network
      infrastructure has been enhanced to allow this feature to
      function, without impacting the processing power of intermediate
      network devices.  The only devices impacted with the
      source-routing will be the source and destination node and the
      intermediate source-routed nodes.  This impact behavior is
      different if IPv4 is used, because then all intermediate devices
      would have had to look into the source-route header.

==> again, this is not correct AFAIK.  IPv4 source routing can be used in a
similar "loose" mode as IPv6, so there is no technical differenceto IPv6
source routing.

editorial
---------

   components.  The longterm solution is a single network without usage

==> s/longterm/long term/

   routing prefix subnet-id part (SID) and an interface identifier part

==> s/prefix/prefix,/

   Randomizing the IID, as defined in RFC 3041, only precludes tracking
   of the lower 64 bits of the IPv6 address.  Masking of the subnet ID
   will require additional approaches as discussed below in 3.4.
   Additional considerations are discussed in [17].  Providing privacy
   for a subnet ID will require different technology.

==> there seems to be duplication with the last two sentences?  Just remove
the last one?

   device like a Mobile IPv6 Home Gateway.

==> s/Gateway/Agent/

   As a simple gateway, the device has the role of managing both packet
   Routing and local address management.

==> s/Routing/routing/

What one does when topology
   probing is to get an idea of the available hosts inside an
   enterprise.

==> this sentence is hard to parse, and can be written simpler.  Reword.

   masked node using the ULA as a COA This truly masks the internal

==> s/COA/COA./

  o  The third is the IP addresses (single or blocks) that they assign
      to customers.  These can be registered addresses (usually given to
      category a and b and sometimes c)

==> you didn't spell out which category is which?  Not sure what you're
referring to..

   devices.  When looking in chapter 2.3 of RFC3314 'Recommendations for
   IPv6 in 3GPP Standards  September 2002' [9] it is found that the IPv6

==> remove "September 2002" ?

      As an alternative some work in Mobile IP to define a policy
   message where a mobile node would learn from the home agent that it
   should not even try to inform its correspondent about route
   optimization (and thereby expose its real location) would allow a
   border home agent using internal tunneling to the logically mobile
   node (potentially rack mounted) to completely mask all internal
   topology while avoiding the strain from a large number of host routes
   in the IGP.

==> that's one helluva long sentence.  Split to 2-3 ?

   o  Initial section of -00 draft 2.6 and 4.6 have been aggregated into
      a new Qcase studyR section 5.

==> weird chars around "case study"

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