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

From: Tim Chown <[email-masked]>
Date: Fri, 4 Mar 2005 12:06:46 +0000

Hi,

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.

It would be nice to see some considered effort in this operational aspect
of IPv6 in v6ops.   A more 'aggressive' approach to the challenges may be
to re-launch PIER with an IPv6 slant, but for the time being this draft can
be a focus for discussion:

	Title		: Things to think about when Renumbering an IPv6 network
	Author(s)	: T. Chown, et al.
	Filename	: draft-chown-v6ops-renumber-thinkabout-01.txt
	Pages		: 39
	Date		: 2005-2-23
	
This memo presents a summary of scenarios, issues for consideration
   and IPv6-specific tools for IPv6 network renumbering, i.e.  achieving
   the transition from the use of an existing network prefix to a new
   prefix in an IPv6 network.  Its focus lies not in the procedure for
   renumbering, but as a set of "things to think about" when undertaking
   such a renumbering exercise.  The document is not intended to be
   complete at the -00 phase, and will be enhanced as further
   operational experience is gathered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-thinkabout-01.txt

Cheers,
Tim

---

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Mar 2005 21:51:28 +0200 (EET)

> 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

---

From: Gert Doering <[email-masked]>
Date: Sun, 6 Mar 2005 21:29:12 +0100

Hi,

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

Just noticed something: 2001::/16 is no longer the only "native global
... address" block - addresses are handed out from 2003::/16 already.

Maybe the part "(under 2001::/16)" should just be completely removed?

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  71007  (66629)

SpaceNet AG                    Mail: [email-masked]
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234

---

From: Tim Chown <[email-masked]>
Date: Sun, 6 Mar 2005 22:32:24 +0000

> Maybe the part "(under 2001::/16)" should just be completely removed?

Thanks Gert - good suggestion (better than renumbering the renumbering
draft!).

[Accidental cc to @6net address removed]

Tim

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 08 Mar 2005 05:13:00 +0900

>>>>> On Sun, 6 Mar 2005 21:51:28 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> useful to try to dig that out and put it as a reference or something.

I don't recall a report on router renumbering a year or two ago, but I
did make a short presentation about our experiences in December 2000:

http://www.ietf.org/proceedings/00dec/00dec-53.htm#TopOfPage

I'm not sure whether this is what you meant.  In any event, our
conclusion regarding router renumbering was not that negative, but we
thought it did not make much sense to apply this technique to large
sites (e.g, an enterprise network).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Mar 2005 22:50:14 +0200 (EET)

> sites (e.g, an enterprise network).

Yes, this is what I was recalling, The "report" that triggered this 
memory is below.

==========
Date: Fri, 15 Aug 2003 03:12:19 +0900
Message-ID: <[email-masked]>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[email-masked]>
To: Ralph Droms <[email-masked]>
Cc: [email-masked]
Subject: Re: inevitability of PI
[...]
>>>>> On Thu, 14 Aug 2003 07:35:57 -0400,
>>>>> Ralph Droms <[email-masked]> said:

> Another potential advantage for IPv6 that is a little harder to quantify is
> the notion of "graceful" renumbering - the ability to have a transition
> state in which both the old and new prefixes are in use simultaneously.
> Will this transition state work in practice?  Has anyone actually tried it?

Not sure if this answers your question, but we tried site-(IPv6)renumbering
in an experimental environment 3 years ago.  In that testing, we had a
transition state with the both old and new prefixes.  The presentation
slides of a report at an IETF meeting are available at the following URL:
http://www.jinmei.org/mgp/ietf49-renumber/

                                         JINMEI, Tatuya
=================