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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Jari Arkko
Sent: Thursday, September 25, 2008 12:02 AM
To: IETF IPv6 Mailing List
Cc: [EMAIL PROTECTED]; 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
--------------------------------------------------------------------
