baker-ipv6-renumbering comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

IMHO the work is important.  It is not clear whether this belongs to multi6
or v6ops, but the current charter of multi6 doesn't allow it while v6ops
does (by being awfully generic)..

To summarize, the document is in a pretty good shape.  I think there are
several applications-related problems that need to be spelled out and
discussed quite a bit more like:

 * what to do about network settings (like firewall rules, NTP/DNS server
configs, etc.) which, if even looked up from the DNS, are typically never
refreshed or refreshed only at reboots etc., making the renumbering a real
PITA.  We need to raise awareness of this issue to facilitate better
"service reconfiguration" capabilities

 * what to do about the process of apps looking up and address and storing
the result basically foreverm a very difficult problem..


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

1)  2.2, preparation for renumbering, has:

   Prior to renumbering, various processes will need to be reconfigured
   to confirm bindings between names and addresses more frequently. In
   normal operation, DNS name translations and DHCP bindings are often
   given relatively long lifetimes to limit server load. In order to
   reduce transition time from old to new prefix it may be necessary to
   reduce the time to live (TTL) associated with DNS records and
   increase the frequency with which DHCP clients contact the DHCP
   server.

==> I'd also add here something like:

   It's also required to plan the procedure how to ensure that the
   configuration parameters will be updated during the period of stably
   using both the prefixes.

... 

The biggest problem in section 2.6.2 on transition to the use of ne
addresses is ensuring that the users also have a means to start using the
new prfix; DNS update may not be quick enough (e.g., if NTP servers are only
looked up at boot if they're configured as names in the config, etc.)

...

   Once all sessions are deemed to have completed, there will be no
   dependence on the old prefix. It may be removed from the
   configuration of the routing system, and from any static
   configurations that depend on it.

==> The same is also in section 2.7 in particular; one could note that there
could still be *new* sessions even if the DNS has been updated and the TTL
has expired, because the apps don't store the TTL, as has been noticed later
in this document.

...

in section 3.1:

Application designers frequently take
   short-cuts to save memory or increase responsiveness, and a common
   short-cut is to use static configuration of IP addresses rather than
   DNS translation to obtain the same. [...]

==> I think the application aspects deserves a subsection of its own, starting
from the sentence above.

==> not looking up something is easy to fix, because the lookups are *easy*
and *simple*.  The more difficult problem is storing the result..

...

   o  must obtain a new translation if a new session is opened with the
      same service after the DNS record's lifetime expires,

==> this is the critical point.  As it's *really, really* difficult to do,
it needs to be pointed out as such.. these are non-trivial problems to fix
(except for the first bullet, in most circumstances..)

2) Clarifying the DNS update problems:

4.1 Dynamic updates to DNS across administrative domains

   When a DNS server at the start of a zone transitions to the use of a
   new address, the associated information in the database of the parent
   DNS server must be updated.  If the parent DNS server is in a
   different administrative domain, the renumbering organization must
   contact the administration of the parent DNS server, typically
   through a manual procedure. There is an opportunity to automate this
   update process through the development of an appropriate protocol.

==> based on this, it's not clear why DynDNS or an appropriate
sub-delegation does not cut it?  Maybe needs more elaboration. (Note: "DNS
server at the start of a zone" -- a bit unclear, maybe reword?)

4.2 Management of the inverse zone

   In networks where hosts obtain IPv6 addresses through SLAC, updates
   of reverse zone are problematic because of lack of trust relationship
   between administrative domain owning the prefix and the host
   assigning the the low 64 bits using SLAC. For example, suppose a
   host, H, from organization A roams to a network owned by organization
   B.  If H obtains an address through SLAC, a DNS server from B will
   own the reverse zone for that address.  For H to update its reverse
   entry, B must accept a DDNS request from H, requiring that an
   inter-administrative domain trust relationship exist between H and B.
   The IETF should develop a BCP recommendation for addressing this
   problem.

==> I'm not sure if I understand the relation of this problem to the
renumbering properly.  Maybe should be elaborated a bit?
It seems that this is a problem in two renumbering-related events:

 - a mobile node is attached to a site undergoing renumbering for long
enough so that it will be affected by the transitions (not sure if this is
typical), or 

 - a "visiting" node (e.g., from a different department or a branch office)
is connected for a longer period of time to a local network, and only the
local network is renumbered -- and the visited node isn't adapted to use the
hostname/domainname etc. from the local network.

3) appendix A on latecy management in DNS.  This probably needs to be
reworked a bit, a few points:

 - the formulas could be simplified if we conclude that DNS update time to
secondaries (TU) is so much smaller than the rest (with the NOTIFY/XFR this
is in the order or seconds or minutes at most).. we can simplify the
analysis.

 - I believe the current formulations are only accurate if TTLNEW is smaller
than a half of TTLOLD.  This is typical, of course..?

 - Maybe we should change time model a bit, to be something like:

  TC - (TTLOLD + TTLNEW + ADMIN_UPDATE_TIME)

  .. where ADMIN_UPDATE_TIME is the time that the administrators want 
to reserve for making the DNS changes to the zones etc (the update window
length..)

 - (one typo: s/corrse/corres/)

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

==> add "network element" to the terminology, as it's used quite a bit..

   DHCP prefix delegation: An extension to DHCP [16] to automate the
      assignment of a prefix from an ISP to a customer[17]

 ==> PD doesn't have to be done between the ISP and the customer so reword:

   DHCP prefix delegation: An extension to DHCP [16] to automate the
      assignment of a prefix, e.g. from an ISP to a customer [17]

...

   SLAC:        StateLess Address Autoconfiguration [10]

==> I'd use the term SLAAC rather than SLAC, the former is used more.  Also
note that in the text, you often use "stateless address configuration",
which need to be reworded.

1.3 Summary of what must be changed

==> some of these are more verbose than the others.. I'd suggest trying to
summarize the steps similarly in each case..

         The new link prefixes may be advertised by the network
   elements, but the router advertisements should not cause hosts to
   perform SLAC on the new link prefixes.

==> I think it would be important to spell out how to do that.

                Network elements may have IPv6
   addresses from the new link prefixes assigned to interfaces, taking
   care that this assignment does not interfere with the use of IPv6
   addresses from the old prefix and does not cause the new link prefix
   to be advertised to hosts.

==> note that one has to be careful (I'm not as a matter of fact sure how to
ensure this) that the network elements won't prefer the new addresses
prematurely, especially for outbound connectivity.. (unless one has been
prepared for that, of course..)


2.6.1 Transition of DNS service to the new prefix

   The DNS service is configured to use the new prefix by removing any
   IPv6 addresses for internal communications from the DNS server
   configuration. External references to the DNS servers, such as in the
   DNS service from which this DNS domain was delegated, are updated to
   use the IPv6 addresses from the new prefix.

==> I had difficulty understanding the point of the first sentence, maybe
reword like:

  The DNS service is configured to use only the new prefix by removing any
   IPv6 addresses from the DNS server configuration.

(what does internal communications signify here.. isn't it rather
irrelevant?)

   Prefixes from the old prefix in router advertisements and addresses
   from the old prefix provided through DHCP should have their preferred
   lifetimes set to zero at this point.

==> continue at the end with like:

                                      , to avoid being used for new
   communications.


5. Security Considerations

==> part of this section should probably go to a conclusions section or
something like that, needs to be organized better, and the meat should be in
the body of the draft? (At least the paragraph starting with "A subtle"
could be integrated with the rest..)


editorial
---------

 This document also
   contains recommendations for application design and network
   management which, if taken seriously, may avoid or minimize the
   impact of the issues.

==> this is at the end of section 1 twice, remove the other

      records will be updated and PTR records are added to the ipv6.arpa
 ...
      removed from the ipv6.arpa domain.

==> s/ipv6/ip6/

   o  The DHCP Reconfigure message can be sent from the server to the
      hosts to cause the hosts to contact the server immediately

==> add the period at the end

 For example, addresses assigned from the new prefix are
   added to any addresses from the old prefix assigned to interfaces on
   the network elements.

==> s/added to/configured in addition to/ ?
==> I'd also remove the "assigned ...", seems pretty redundant..


   The new prefix is added to the routing infrastructure, firewall
   filters, ingress/egress lists and other forwarding and filtering

==> s/lists/access lists/ (or "filters")

   Once the new prefix has been added to the network infrastructure,
   access-lists, route-maps and other network configuration options that

==> add "then" after the first line, the the period-separated list is easier
to read then..
 
   defenses in place before advertising the prefix, if only because the
   prefix may come under immediate attack.

==> s/immediate/an immediate/

   interface (apart from interfaces that use only the link local
   address), and two addresses are available for the use of any host,
   one in the old prefix and one in the new. This is a stable
   configuration.

==> s/link local/link-local/
==> s/two/two non-link-local/ (just being pedantic :-)

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