[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: v6ops-addcon and longer than 64 bit prefixes
From: Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date: 2008-09-30 20:14:43
Message-ID: 48E288B3.8080700 () gmail ! com
[Download RAW message or body]
Marla,
In what sense is "(e.g. on a basis of /48)" a recommendation?
Brian
On 2008-10-01 04:09, Azinger, Marla wrote:
> My point with all of this is that I don't see it proper for IETF documents to \
> reflect or suggest anything other than a technical boundary. Neither /48 or /56 \
> are technical boundaries and they shouldn't be put in an IETF document as a \
> recommendation just because its the "flavor" of an RIR for the current year or \
> because it just sounds good.
> I am asking all of you to stick to factual technical aspects. The minute a subnet \
> is written into an IETF document as a "recommendation" it limits RIR policy in the \
> future due to ignorance. RIR communities historically have taken the word \
> "recommendation" as a warning sign that if you go more or less specific with a \
> subnet you would venture into a technical issue. And then it turns into a painful \
> game of trying to change RIR policy or IETF documentation once reality hits that \
> the "recommended" subnet had no technical significance, or more experience was \
> gained and what was thought to be technically true turns out not to be.
> What the world needs are documents that point out factual boundaries. And if there \
> aren't any then point that out as well. But the last thing we need is another IETF \
> document that inserted selected subnet sizes without technical significance. This \
> very reason is why the ARIN RIR is messed up and has /32 as the Allocation size due \
> to an IETF document that "recommended" /32 without any technical basis.
> I caution any use of a specific subnet size unless its pointing out a known \
> technical barrier.
> Thank you
> Marla Azinger
> Frontier Communications
> ARIN AC
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker
> Sent: Tuesday, September 30, 2008 4:02 AM
> To: Brian E Carpenter
> Cc: IETF IPv6 Mailing List; Ron Bonica; Pasi Eronen; \
> draft-ietf-v6ops-addcon@tools.ietf.org; alh-ietf@tndh.net; V6ops \
> Chairs
> Subject: Re: v6ops-addcon and longer than 64 bit prefixes
>
> If the registries are using /56, why recommend what they have tried and found \
> wanting?
> On Sep 28, 2008, at 5:35 PM, Brian E Carpenter wrote:
>
> > /56 is a choice currently used by the registries. That doesn't
> > invalidate using /48, if you consider that to be a more interesting
> > allocation unit to consider. So I don't see a problem with "(e.g. on a
> > basis of /48)".
> >
> > Brian
> >
> > On 2008-09-29 09:55, Turchanyi Geza wrote:
> > > Colleagues,
> > >
> > > Ooops,
> > >
> > > HD is calculated for prefixes, but on the basis of /56
> > >
> > > (since November 2007)
> > >
> > > Please see
> > >
> > > http://www.ripe.net/ripe/docs/ripe-421.html#utilisation
> > >
> > > Best,
> > >
> > > Geza
> > >
> > >
> > >
> > > On Fri, Sep 26, 2008 at 8:21 AM, Fred Baker <fred@cisco.com> wrote:
> > > > nit on the nit...
> > > >
> > > > HD is calculated for prefixes (e.g. on a basis of /48), instead of
> > > > *being*
> > > > based on endpoint addresses as IPv4 is.
> > > >
> > > > (the second part needed a verb)
> > > >
> > > > On Sep 25, 2008, at 12:51 PM, Tony Hain wrote:
> > > >
> > > > > Wording nit in 2.4.2
> > > > > Current:
> > > > > HD is calculated for sites (e.g. on a basis of /48), instead of
> > > > > based on addresses like with IPv4 should read:
> > > > > HD is calculated for prefixes (e.g. on a basis of /48), instead of
> > > > > based on endpoint addresses like with IPv4
> > > > >
> > > > >
> > > > > It is not clear that the 6bone space discussion is appropriate for
> > > > > this document, and restating what is effectively a policy will
> > > > > cause a problem in the future. Removing the last sentence of 2. and
> > > > > all of 2.3 will not impact the intent of this document. Given that
> > > > > the stated target audience is network managers that have not
> > > > > figured out an IPv6 addressing plan, confusing them with a
> > > > > discussion about ancient history is not helpful.
> > > > >
> > > > > Tony
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On
> > > > > > Behalf Of Jari Arkko
> > > > > > Sent: Thursday, September 25, 2008 12:02 AM
> > > > > > To: IETF IPv6 Mailing List
> > > > > > Cc: draft-ietf-v6ops-addcon@tools.ietf.org; V6ops Chairs; Pasi
> > > > > > Eronen; Ron Bonica
> > > > > > Subject: v6ops-addcon and longer than 64 bit prefixes
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > Draft-ietf-v6ops-addcon was in IESG review and there was a lot of
> > > > > > discussion about the recommendations an earlier version of the
> > > > > > draft had about prefix lengths longer than 64 bits. The draft has
> > > > > > now been revised to what we believe is reasonably consistent with
> > > > > > reality and existing
> > > > > > IPv6 address architecture RFCs. However, it would be good to give
> > > > > > the 6MAN WG a chance to review the text.
> > > > > >
> > > > > > Please take a look at the document and the given two sections in
> > > > > > particular:
> > > > > >
> > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10
> > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#section-3.1
> > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#appendix-B
> > > > > >
> > > > > > If there is no objection the draft will be approved. Please
> > > > > > comment by September 30th.
> > > > > >
> > > > > > Jari
> > > > > >
> > > > > > ------------------------------------------------------------------
> > > > > > -- IETF IPv6 working group mailing list ipv6@ietf.org
> > > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/
> > > > > > ipv6
> > > > > > ------------------------------------------------------------------
> > > > > > --
> > > > > -------------------------------------------------------------------
> > > > > - IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > > -------------------------------------------------------------------
> > > > > -
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> > > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic