red Baker
Sent: Tuesday, September 30, 2008 4:02 AM
To: Brian E Carpenter
Cc: IETF IPv6 Mailing List; Ron Bonica; Pasi Eronen; [EMAIL PROTECTED]; [EMAIL
PROTECTED]; V6ops Chairs
Subject: Re: v6ops-addcon and longer than 64 bit prefixes
If the registries are using /56, why recommend what they have t
n
> technical barrier.
>
> Thank you
> Marla Azinger
> Frontier Communications
> ARIN AC
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Baker
> Sent: Tuesday, September 30, 2008 4:02 AM
> To: Brian E Carpenter
IETF IPv6 Mailing List; Ron Bonica; Pasi Eronen; [EMAIL PROTECTED]; [EMAIL
PROTECTED]; 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:
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 co
On 29/09/2008, at 7:35 AM, Brian E Carpenter wrote:
/56 is a choice currently used by the registries.
Maybe I should complete Brian's sentence:
/56 is a choice currently used by the registries in assessing
effective IPv6 address utilization using the HD ratio, as part of the
process of
/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,
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 <[EMAIL PROTECTED]> wrote:
> nit on the nit...
>
> HD is calculated for
Colleagues,
On reviewing the sections of the document pertaining to prefix lengths
longer to 64 bits, I found the following issue:
Section 3.1 of draft-ietf-v6ops-addcon-10 states:
" Note that RFC3177 strongly prescribes 64 bit subnets for general
usage, and that stateless autoconfiguration opti
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 /
And we're still persisting with a recommendation for /126 for p2p
router links and against /127?
I guess that's the current state of things.
bias disclosure: I'm in favour of /127, vis.
http://www.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf
In light of Maz's presentation (see link
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 dis
11 matches
Mail list logo
