RE: [GLOBAL-V6]IPv6 Allocation Policy

  • To: michel at arneill-py.sacramento dot ca dot us
  • Subject: RE: [GLOBAL-V6]IPv6 Allocation Policy
  • From: Izumi Okutani <izumi at nic dot ad dot jp>
  • Date: Mon, 23 Jun 2003 18:56:56 +0900
  • Cc: gert at space dot net, narten at us dot ibm dot com, global-v6 at lists dot apnic dot net
  • In-reply-to: Your message of "Mon, 19 May 2003 19:50:02 -0700"<>
  • List-archive: <>
  • List-help: <>
  • List-id: Discussion of new global IPv6 policy development <>
  • List-post: <>
  • List-subscribe: <>,<>
  • List-unsubscribe: <>,<>
  • References: <>
  • Sender:
      Thanks for summarising the choices. May I suggest adding "Producing an
      IPv6 guide" as an option to deal with the issues as well?
      I am thinking of a guide similar to APNIC's "APNIC guidelines for IPv4
      allocation and assignment
      requests"(, but
      should be shared among all RIRs for IPv6 version. It is flexible to
      changes than the policy document, supplementing the intent of the
      policy(e.g, elaborating the allocation criteria by giving examples)
      and describing more operational details for specific cases.
      It gives IPv6 requestors a more clear idea on whether their network is
      likely to meet the allocation criteria, what kind of documentation is
      required for the request, etc.
      By this, we can also avoid constantly changing and writing too much
      operational details in the policy document which I believe should
      describe only core principles and basic criteria on IPv6.
      The current major issues about the policy seems to be on:
       1) Policy wording on allocation being a barrier for some qualified
          - large scale networks that do not make /48 assignments
          - Concerns on the return enforced when 200*/48 is not met after 2
       2) How to deal with specific cases(PI assignments, transit prviders)
      We will certainly need to review the policy itself in a long term, but
      I feel a large part of it can be solved by elaborating the intention
      and giving examples on specific cases in a guide.
      For example, for issue 1), it will probably help reduce mind barriers
      by stating that 200*/48 is just to provice an idea about the scale of
      networks that qualify allocations, and giving examples on special
      cases which do not strictly run under this criteria, e.g, mobile
      networks, ADSL, CATV, etc.
      We can start with producing a guide to solve issue 1), and after the
      solutions to each cases in issue 2) becomes clear, we can add them to
      the guide.
      What do you think about it?
      Izumi Okutani
      IP Department
      Japan Network Information Center
      From: "Michel Py" <michel at arneill-py.sacramento dot ca dot us>
      Subject: RE: [GLOBAL-V6]IPv6 Allocation Policy
      Date: Mon, 19 May 2003 19:50:02 -0700
      > Gert,
      > > Gert Doering wrote:
      > > Checking the address block, three /48s have been assigned
      > > (two to universities, one to NORDUnet itself).
      > > As the request has been approved, one could argue that no
      > > change is necessary - but from the discussion, I gather that
      > > the approval is definitely questionable, and this is something
      > > that makes me unhappy about this.  I think that the approval
      > > was fine (!) but that it wasn't fully according to the letter
      > > of the policy, and as a consequence I think that the policy
      > > needs adaptation.
      > The way I see this is that what we are currently discussing is basically
      > a matter of the trust we put in the stewardship the RIRs have over the
      > prefix they have been delegated. We can go two ways:
      > 1. Change nothing and accept the idea that the RIRs will make exceptions
      > to the policy for good reasons, based on their best judgment of the
      > situation at the time. As you mentioned earlier since mostly they have
      > taken decisions that most people would agree with, there is no
      > operational issues. The drawback of doing this is that the exceptions
      > the RIRs make when allocating space by overriding policy could be
      > considered favoritism.
      > 2. Change the policy so RIRs don't have to make exceptions for
      > situations such as NRENs. The drawback of doing this is that a) there
      > could be loopholes and b) some people will ask for exceptions anyway on
      > top of a much more flexible policy.
      > Without taking sides, did I formulate the choices clearly?
      > Michel.
      > _______________________________________________
      > global-v6 mailing list
      > global-v6 at lists dot apnic dot net