Re: draft-chown-v6ops-renumber-thinkabout-01

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 4 Mar 2005, Tim Chown wrote:
> Just a heads up on a new revision of the personal draft on IPv6 renumbering
> issues.   There is a slot for this in v6ops next week.

Scribbled on the plane..

The document was fluent to read though it was a bit on the longish 
side. Some topics were discussed multiple times (in a bit shorter 
fashion) in different parts of the document.  It would be good if the 
document could be compressed to, say, 20-25 pages without losing the 
readability (not sure if this would be worth doing).

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

5.6  Anycast addressing

==> much of this appears to have little impact on renumbering.  The only
factor appear to be the hypothetical well-known addresses for discovery
(e.g., DNS) which don't need to be renumbered, but in the grand scope of
things, this probably isn't much.  Maybe just summarize the section to one
paragraph?

6.3  Router Renumbering

==> I think Jinmei of KAME reported some experiences of router renumbering
on the IPv6 list a year or two ago, the reason why they found it to be
unworkable approach in practice.  Sorry for being inprecise.. it might be
useful to try to dig that out and put it as a reference or something.

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

3.3  Acquisition or merger

   Two networks may need to merge to one due to the acquisition or
   merger of two organisations or companies.  Such a reorganisation may
   require one or more parts of the new network to renumber to the
   primary PA IPv6 prefix.

==> while this is all correct, it might be worth pointing out that v6 does
not necessarily have the same acquisition/merger issues as v4 (e.g., a merge
of two net-10 address spaces).  I.e., you may not even need to merge the
address spaces at all, if the offices are separate and the offices have
separate net connectivity (for example).

4.2.4  "Sessions" in non-session based transports

==> this could possibly be merged with the previous 4.2.x sections -- at
least there's no need to separate UDP and TCP-based NFS, imho.


If sources are identified by the source address only, then
   this might appear as a new source to the receivers (as they would
   where IPv6 Privacy addresses are used).  Using RTP a receiver may
   determine it's the same source.

==> the last sentence doesn't help much, I fear.  Those that don't know
_how_ won't have much idea after reading it, and those that do know how
don't need the reminder.. is there a reference describing how to do it with
SSM, or just remove?

   In order to renumber such a network, the DHCPv6 server should send
   reconfigure messages to inform the clients that the configuration has
   changed, and the clients should re-request configuration details from
   the DHCPv6 server.  This, of course, relies on the clients correctly
   responding to such messages.

   Where DHCPv6 has been employed, careful consideration about the
   configuration of the service is required such that administrators can
   be confident that clients will re-contact the service to refresh
   their configuration data.  As alluded to in sections 22.4 and 22.5 of
   [30], the configurable timers that offer servers the ability to
   control when clients re-contacts the server about its configuration
   can be set such that clients rarely (if ever) connect to validate
   their configuration set.

==> does DHCPv6 support address deprecation, is it an all-or-nothing deal?
(old addresses are taken away when the new ones are given to replace the
old)

6.2.2  Source Address Selection Policy distribution

==> this is under Stateful Configuration, but I guess this doesn't really
require any state.. the policy could be the same independent of the address?
(there's also a NDP version of this)

  Note that RFC2894 was developed before the shift in recommendation
   away from the Top-, Next- at Site-Level Aggregation Identifier
   address allocation hierarchy of RFC2373,

==> you may want to refer to RFC3587 here.

7.2  Border filtering

==> maybe also refer to to 7.5.1, for the filtering done by the provider?

  There are also cases where the use of a resolver is not practical,
   such as with packet filter rules.  If a packet filter has been
   configured with explicit hostnames, these are translated to IP
   addresses for fast packet matching.

==> one of my pet peeves is that it isn't possible to represent prefix (and
length) in a DNS record, so these couldn't be entered in the DNS even if you
wanted to.. maybe this would be worth a bit of text somewhere in the
document.

   A similar problem exists when a nameserver is renumbered.  If the
   operating system's resolver has cached the nameserver address, it
   will at some point find it unavailable.  To mitigate this problem, it
   is suggested that at least one off-site nameserver is included in the
   configuration.

r==> the latter is in (small) conflict with ULAs, which in turn require
split-faced DNS.  As the off-site nameserver can't be split faced, the
results may no longer be consistent ?

   "Helpdesk ops" service liveness monitoring software also poses a
   particular problem where liveness is determined, for example, by a
   null transaction (e.g.  for POP3 mail server, authenticating and
   performing a NOOP) made against a named service instance, if the name
   is by IP then two instances of the liveness test will be required:
   one on the old address to cater for those remote parties that are not
   yet aware of the new address, and one test against the new.

==> so, this needs to be calling for new kind of coding practices/functions
-- instead of cycling through the addresses and using the first that works,
the apps should cycle trhough all the addresses and potentially report on
all that do not work.. maybe this needs to be put more prominently
somewhere.


7.7  Equipment administrative ownership

   The question of who owns and administers (also, who is authorised to
   administer) the site's access router is an issue in some renumbering
   situations.  In the enterprise scenarios, the liaison between the end
   users and remote administrators is likely to be relatively easy; this
   is less likely to be the case for a SOHO scenario.  This is not
   likely to be a major issue, however, since SOHO renumbering is likely
   to only be required if the remote administrators deem it necessary,
   or if the end user is sufficiently technically competent and decides
   to renumber their own network.

==> undoubtedly this has some issues, but you might also mention at least
one of them ;-)

   Alternatively, should the old address space be available such that a
   single (or subnet of) Mobile IPv6 Home Agents be deployed in the
   routing path of the to-be-otherwise-interrupted connection, then the
   endpoint being renumbered could utilise layer 3 mobility once the old
   prefix removed from its link, i.e.  register with the Home Agent in
   the old prefix topology - presumably in the provider's network,
   formerly upstream from the site - and rely on Mobile IPv6 route
   optimisation to make good the additional overhead imposed by the
   reverse tunnelling to the new prefix.

==> not sure what this does under "shims and sockets", and whether it's
needed at all.  Maybe I just didn't get the point..

   o  Names resolved to IP addresses in firewall at startup time

==> names are easy.  Prefix lists are more tricky (e.g., allowing access
from particular subnets..)

   [22]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
         progress), January 2005.

   [23]  Hinden, R. and B. Haberman, "Centrally Assigned Unique Local
         IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-00 (work
         in progress), June 2004.

==> these seem to be so important for this spec that should be under
Normative references?




editorial
---------

 When changing
   from 6to4 (2002::/16) addresses to native global aggregatable unicast
   addresses (under 2001::/16)

==> s/under/e.g., under/ ?

   These disruptive elements will be covered in situ as we discuss
   protocol features and other renumbering considerations later in this
   memo.

==> "situ" ?

   refreshed from the naming service, and as such even if the
   renumbering site does update it's DNS (or NIS, LDAP database etc.),

==> s/it's/its/

   As per RFC2373 [17], IPv6 hosts may be multi-addressed.  This means

==> update 2373 to 3513.

   Multicast features much more prominently in the core specification,

==> sounds a bit awkward?

   Where multicast is used to discover the availability of core services
   (e.g.  all DHCPv6 servers in a site will join FF05::1:3), the effect
   of renumbering the unicast address of those services will mean that
   the services are still readily discoverable without resorting to a
   (bespoke or otherwise) service location protocol to continue to
   function - particularly if (unicast) ULAs are not deployed locally as
   per Section 5.5.

==> does "bespoke" belong to the commonly used international english
vocabulary? :)

   be able to set local policy such that nodes use ULAs for intranet
   communications and global addresses for extranet communications.  The
   use of ULAs internally would in principle mitigate against global
   address renumbering of nodes.  One cost of such dual-scope deployment
   is the implied requirement to run a 'two-face' DNS, which can add an

==> s/extranet/Internet/ ?
==> s/two-face/two-faced/

   The length of time for which the old prefix remains available has
   impacts on how long can be allowed for the renumbering procedure, and

==> s/impacts/impact/

   and SOHOs might consider as little as one month's overlap too
   expensive, and so Baker's State 5 (Stable use of either prefix) [1]
   unattainable

==> something missing at the end?

   services (such as web servers) from one IP address to another,
   without going through a stage where the service is available on
   either address.

==> maybe better say "both [or all] addresses".

  For instance, the new provider
   may refuse to receive into their routing topology those packets whose
   source address is under the old prefix, and likewise for the old
   provider and new prefix.

==> "routing topology" is a bit awkward way to put it, as the ISP isn't even
getting a route, just the packets. reword?

: as the renumbering event takes place,
   the locator is updated to reflect the new address topology and the
   application blissfully unaware - a form of layer 3.5 mobility.

==> s/blissfully/is blissfully/

   o  Apache .Listen.  directive on given IP address

==> generalize this a bit ?

   o  PIM-SM Rendezvous Point address

==> for the non-multicast aware, add ".. on all the multicast routers" ?

   [27]  Abley, J. and K. Lindqvist, "Operation of Anycast Services",
         draft-grow-anycast-00 (work in progress), February 2005.

==> draft-ietf-grow-anycast-00 now

   [36]  Moskowitz, R., "Host Identity Protocol Architecture",
         draft-moskowitz-hip-arch-06 (work in progress), June 2004.

==> draft-ietf-hip-arch now