Subject: [renum] Agenda for IETF82

From: Tim Chown <[email-masked]>
Date: Thu, 3 Nov 2011 18:49:05 +0000

Hi,

We have the following draft agenda for IETF82.  If there's any corrections please let Wes or me know.  

IETF 82
6RENUM Working Group
18th November 2011

11:20 - 11:25  Note Well, Jabber relay, note taker(s)

11:25 - 11:30  Agenda bashing, WG status update 

11:30 - 11:35  Homenet update (Tim Chown)

11:35 - 11:40  SDN BoF update (Wes George)

11:40 - 12:10  IPv6 Enterprise Network Renumbering Scenarios and Guidelines

	draft-jiang-6renum-enterprise-01

12:10 - 12:30  Problem Statement for Renumbering IPv6 Hosts with Static Addresses (Brian Carpenter)

	draft-carpenter-6renum-static-problem-00

12:30 - 13:00  IPv6 Site Renumbering Gap Analysis

	draft-liu-6renum-gap-analysis-02

13:00 - 13:30	  Open Discussion

13:30  Close

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 4 Nov 2011 09:26:09 -0700

Hi,

For those of you who don't know, I am working on a
second edition of the IRON base architecture:

http://tools.ietf.org/html/draft-templin-ironbis

In this new version, I have updated the "Renumbering
Considerations" section to show that end user networks
that can get a PI prefix (aka "Client Prefix (CP)") that
is "big enough" to be injected into the routing system
get to keep the prefix even if they move between IRON
service providers. This still does not address the
portability of "micro-prefixes" or even down to singleton
IP addresses, but it does make new observations beyond
what appeared in RFC6179. Please see below for the new
text, and send any comments.

Thanks - Fred
[email-masked]

---

9.  Renumbering Considerations

   As new link-layer technologies and/or service models emerge, end
   users will be motivated to select their basic Internet connectivity
   solutions through healthy competition between ISPs.  If an end user's
   network-layer addresses are tied to a specific ISP, however, they may
   be forced to undergo a painstaking renumbering even if they wish to
   change to a different ISP [RFC4192][RFC5887].

   When an end user Client obtains CPs from a VSP, it can change between
   ISPs seamlessly and without need to renumber the CPs.  IRON therefore
   provides ISP independence at the link layer.  If the end user is
   later compelled to change to a different VSP, however, it would be
   obliged to abandon its CPs and obtain new ones from the new VSP.  In
   that case, the Client would again be required to engage in a
   painstaking renumbering event.

   In order to avoid all future renumbering headaches, a Client that is
   part of a cooperative collective (e.g., a large enterprise network)
   could join together with the collective to obtain a suitably large PI
   prefix then and hire a VSP to manage the prefix on behalf of the
   collective.  If the collective later decides to switch to a new VSP,
   it simply revokes its PI prefix registration with the old VSP and
   activates its registration with the new VSP.