RE: what problem is solved by proscribing non-64 bit prefixes?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: what problem is solved by proscribing non-64 bit prefixes?
- To: "Mohacsi Janos" <mohacsi at niif.hu>, "Alexandru Petrescu" <alexandru.petrescu at gmail.com>
- Subject: RE: what problem is solved by proscribing non-64 bit prefixes?
- From: "Dunn, Jeffrey H." <jdunn at mitre.org>
- Date: Wed, 1 Oct 2008 09:27:46 -0400
- Cc: "Sherman, Kurt T." <ksherman at mitre.org>, ipv6 at ietf.org, rbonica at juniper.net, Steve_Eiserman at ao.uscourts.gov, Pasi.Eronen at nokia.com, draft-ietf-v6ops-addcon at tools.ietf.org, ralph.liguori at disa.mil, night at nist.gov, dougm at nist.gov, v6ops-chairs at tools.ietf.org, "Martin, Cynthia E." <cemartin at mitre.org>
- Delivered-to: ietfarch-ipv6-web-archive at core3.amsl.com
- Delivered-to: ipv6 at core3.amsl.com
- In-reply-to: <alpine.BSF.2.00.0810011457120.20355 at mignon.ki.iif.hu>
- List-archive: <https://www.ietf.org/mailman/private/ipv6>
- List-help: <mailto:ipv6-request@ietf.org?subject=help>
- List-id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
- List-post: <mailto:ipv6@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
- References: <C0F2465B4F386241A58321C884AC7ECC085AB2AF at E03MVZ2-UKDY.domain1.systemhost.net><48E37330.3060801 at gmail.com> <alpine.BSF.2.00.0810011457120.20355 at mignon.ki.iif.hu>
- Sender: ipv6-bounces at ietf.org
- Thread-index: AckjxtXOzX7GqgjPTBq9VhARBELi9gAAa9bA
- Thread-topic: what problem is solved by proscribing non-64 bit prefixes?
Janos,
You raise an excellent point with respect to using nibble boundaries.
If one uses a partitioning scheme like that in RFC 3531 AND require
that partitions (sets of prefixes) be on nibble boundaries, a /32
allocation with a 64-bit prefix length contains only 8 partitions of 4
bits each. This yields just 16 possible subnets per partition. If one
allows a 96-bit prefix length, the number of nibble partitions jumps to
16 or, alternately, the size of the 8 partitions grows to 8 bits (256
subnets).
In addition to simplifying reverse DNS lookup, nibble boundary
partitioning makes it far easier to identify subnets belonging to the
same partition. This reduces IP address management complexity.
Best Regards,
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)
-----Original Message-----
From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of
Mohacsi Janos
Sent: Wednesday, October 01, 2008 9:08 AM
To: Alexandru Petrescu
Cc: Sherman, Kurt T.; ipv6 at ietf.org; Steve_Eiserman at ao.uscourts.gov;
ralph.liguori at disa.mil; Pasi.Eronen at nokia.com;
draft-ietf-v6ops-addcon at tools.ietf.org; rbonica at juniper.net;
night at nist.gov; dougm at nist.gov; v6ops-chairs at tools.ietf.org; Martin,
Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?
On Wed, 1 Oct 2008, Alexandru Petrescu wrote:
> michael.dillon at bt.com wrote:
>>> In a typical IPv6 ADSL household landscape...
>>>
>>> An ADSL IPv6 operational deployment offers a /64 prefix at home.
>>> With that, I can't subnet _and_ use IPv6 stateless
auto-configuration.
>>
>> In a typical IPv6 ADSL household landscape the ISP will assign you a
>> /48 with plenty of subnetting space.
>
> Not sure, FWIW, in the IPv6 ADSL household I live in gives me a /64
and not
> /48 (see draft-despres-v6ops-6rd-ipv6-rapid-deployment-01.txt).
>
> That's typical for me but I don't know about the other deployed IPv6
ADSL, do
> they give /64 or shorter prefixes?
The draft-despres-v6ops-6rd-ipv6-rapid-deployment-01.txt is largely
irrelevant in this discussion, This draft describing a particular
solution
that can be implemented by the ISPs if:
1. they have complete operational control over the CPEs installed users
2. They want to implement IPv6 quickly
3. They users are using only one subnets which is the allocated /64.
In general - my recommendation when I giving tutorials about IPv6:
- /48 to /128 is delegated to end users
- /48 general case, /47 if justified for bigger networks
- /64 if one and only one network is required
- /128 if it is sure that one and only one device is going to be
connected
between /48 - /64 up to you if you are cautious about address
conservation:
- but use nibble boundary for easier reverse DNS delegation.
Regards,
Janos Mohacsi:
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.