Subject: v6ops-addcon and longer than 64 bit prefixes

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Sep 2008 10:01:31 +0300

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
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 25 Sep 2008 11:51:23 -0700

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-masked] [mailto:[email-masked]] On Behalf Of
> Jari Arkko
> Sent: Thursday, September 25, 2008 12:02 AM
> To: IETF IPv6 Mailing List
> Cc: [email-masked]; V6ops Chairs; Pasi Eronen;
> Ron Bonica
> Subject: v6ops-addcon and longer than 64 bit prefixes
> 
> Folks,
>

---

From: "Erik Kline" <[email-masked]>
Date: Thu, 25 Sep 2008 21:19:30 -0700

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) I do think that the text in
B.2.1 saying "The usage of this subnet address length does not lead to
any additional considerations ..." might, in fact, not be the whole
truth.

---

From: Fred Baker <[email-masked]>
Date: Thu, 25 Sep 2008 23:21:40 -0700

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)

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Thu, 25 Sep 2008 10:55:59 -0400

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 option is only defined for
64 bit subnets."

RFC 4862 states:

" It is the responsibility of the system administrator to ensure that
the lengths of prefixes contained in Router Advertisements are
consistent with the length of interface identifiers for that link type.
It should be noted, however, that this does not mean the advertised
prefix length is meaningless.  In fact, the advertised length has
non-trivial meaning for on-link determination in [RFC4861] where the
sum of the prefix length and the interface identifier length may not be
equal to 128.  Thus, it should be safe to validate the advertised
prefix length here, in order to detect and avoid a configuration error
specifying an invalid prefix length in the context of address
autoconfiguration.

Note that a future revision of the address architecture [RFC4291] and a
future link-type-specific document, which will still be consistent with
each other, could potentially allow for an interface identifier of
length other than the value defined in the current documents.  Thus, an
implementation should not assume a particular constant.  Rather, it
should expect any lengths of interface identifiers."

As a result, RFC 4862 specifically prescribes that prefix lengths other
than 64 bits should be supported and does not state that stateless
autoconfiguration is defined only for 64 bit prefixes..  

FYI, a quick survey of several IPv6 RFC yields the following results:

Extended address prefixes are supported, meaning either explicitly
prescribed or not proscribed by the following RFCs:

Protocol/Technology			RFC
IPv6 Packet Format			2460, 5095
ICMPv6				2463, 4443, 4884
Neighbor Discovery			2461, 3971, 4861
Stateless Auto-configuration		2462, 4862, 4941
DHCPv6				3315, 3633, 3736, 4361
Path MTU Discovery			1981
Address Architecture			2526, 3879, 4007,  4291
DNS					2671, 3596, 3986
Application Programming Interface	3493, 3542, 3678, 4584, 5014
Interior Gateway Protocols		2740, 4552
Exterior Gateway Protocols		1772, 2545, 4271, 4760
IPsec					3948, 4301, 4302, 4303, 4308,
4809
IKE					4306, 4307, 4945
Architecture				4213
Tunneling				2573, 2784, 4891
MPLS					4798
SNMP					3411, 3412, 3413, 3414
MIB					3289, 4022, 4087, 4113, 4292,
4293, 4295, 4807
MLD					3810, 4604
PIM					4601, 4609
DiffServ				2474, 2475, 2597, 2983, 3086,
3140, 3168, 3246, 3247, 3260, 3494
PPP					5072

Extended address prefixes are proscribed by the following RFCs:

Protocol/Technology				RFC
Addressing Architecture			4291
Stateless Auto-configuration			2460
Cryptographically Generated Addresses	3973, 4581, 4982
Unique Local Addresses			4193
Source-Specific Multicast 			3306, 3956, 4607
IPv6 over Link Layers			2464, 2590

My basic question is: What basic engineering problem is solved by
proscribing non-64 bit prefixes?  Clearly, there are some IPv6
protocols that require a 64 bit prefix; however, the question of
whether to deploy these protocols is of an operational rather than an
engineering nature.  I do not see an overwhelming engineering need to
proscribe non-64 bit prefixes.  As a result, I suggest that we follow
Jon Postel's robustness principle: be conservative in what you do, be
liberal in what you accept from others.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation. 

-----Original Message-----
Sent: Thursday, September 25, 2008 3:02 AM

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:

Jari

---

From: "Turchanyi Geza" <[email-masked]>
Date: Sun, 28 Sep 2008 22:55:51 +0200

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-masked]> 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.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Sep 2008 10:35:10 +1300

/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

---

From: Geoff Huston <[email-masked]>
Date: Mon, 29 Sep 2008 10:04:03 +1000

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 allocation of further address prefixes to an LIR. i.e. its  
not dictating what address prefix an ISP must use to number end sites.  
LIRs may use any profix size that they believe is appropriate to their  
needs.

thanks,

    Geoff

---

From: Fred Baker <[email-masked]>
Date: Tue, 30 Sep 2008 07:01:30 -0400

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:

>>>> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 30 Sep 2008 15:59:49 +0200

Hi,

Dunn, Jeffrey H. wrote:
[...]
> proscribing non-64 bit prefixes?

I don't know.  But I know what problems are solved by using 
longer-than-64bit prefixes, especially when autoconfiguring addresses 
with stateless method.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Azinger, Marla" <[email-masked]>
Date: Tue, 30 Sep 2008 11:09:01 -0400

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: [email-masked] [mailto:[email-masked]] 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; [email-masked]; [email-masked]; 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:

> allocation unit to consider. So I don't see a problem with "(e.g. on a
> basis of /48)".
>
>    Brian
>
>>>> HD is calculated for sites (e.g. on a basis of /48), instead of
>>>> based on addresses like with IPv4 should read:
>>>> 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
>>>>
>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf Of Jari Arkko
>>>>> Cc: [email-masked]; V6ops Chairs; Pasi
>>>>> Eronen; Ron Bonica
>>>>> 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.
>>>>>
>>>>> If there is no objection the draft will be approved. Please
>>>>> comment by September 30th.
>>>>>
>>>>> Jari
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -- IETF IPv6 working group mailing list [email-masked]
>>>> -------------------------------------------------------------------
>>>> - IETF IPv6 working group mailing list [email-masked] Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> IETF IPv6 working group mailing list [email-masked] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 30 Sep 2008 11:19:22 -0400

Alex,

Could you elaborate on that statement?

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, September 30, 2008 10:00 AM
To: Dunn, Jeffrey H.
Cc: Jari Arkko; IETF IPv6 Mailing List; Sherman, Kurt T.; Ron Bonica;
[email-masked]; Pasi Eronen;
[email-masked]; [email-masked];
[email-masked]; [email-masked]; V6ops Chairs; Martin, Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?
(was: v6ops-addcon and longer than 64 bit prefixes)

Hi,

Dunn, Jeffrey H. wrote:
[...]

Alex

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Sep 2008 12:10:32 -0400

> proscribing non-64 bit prefixes?

There's one definite engineering/operational problem, for which non-64
bit prefixes are needed to solve:

Managing combined (dual-stack) IPv4 and IPv6 server infrastructure,
where the IPv4 prefixes are necessarily constrained in size and
proximity, due to CIDR rules.

Here, "management" involves more than just assigning addresses to
machines - it means configuring routers, load balancers, firewalls,
back-office systems, billing systems,
monitoring systems, DNS, you name it.

Here's why it is non-trivial...

In a given IPv4 assignment, utilization needs to be extremely dense in
order to meet RIR assignment criteria.

This leads to variable-length subnet mask (VLSM) arrangements, of the sort:
/24 - broken into prefixes all the way down to /29's or even /32's, e.g.
.0/24 ->
    .0/27
     .32/28
      .48/29
      .56/29
   .64/26
     .128/28
     .144/28
     .160/28
      .168/29
      .176/29
      .184/29
    .192/27
     .224/28
      .240/29
      .248/29

Repeat this with a plethora of prefixes subnetted in similar fashion,
the total quantity of which are not generally known apriori, as this is
a moving target.
Possibly involving blocks ranging from /24, to /19, to /16, to /14 or
bigger.

When managing such a scheme alongside an IPv6 prefix which needs to be
assigned to the same set of servers, which are all dual-stack, the
*number* of prefixes,
their *relative* numbering, and the host *addresses* within the
prefixes, it is quickly apparent that use of only /64 prefixes makes for
a management nightmare,
particularly if renumbering of prefixes and/or servers occurs, e.g.
re-balancing the VLSM arrangement itself in IPv4-land.

Using parallel VLSM prefix schemes in IPv6, on the other hand, trivially
permits management of dual-stack infrastructure, without any significant
down-side,
and without the wasteful assignment of /64 prefixes that would otherwise
need to occur.

Keep in mind that the scalability of the IPv6 DFZ, pretty much depends
on avoiding individual sites getting multiple IPv6 assignments directly
from RIRs on an ongoing basis.

Assignments to end sites from LIRs, however, is not as big an issue --
IFF they are given appropriately-sized blocks, avoiding triggering of
new RIR-to-LIR assignments.

The existence of even a single use case, such as this, I would hope is
sufficient to justify non-64 bit address considerations in IETF RFCs/BCPs.

Brian Dickson

---

From: <[email-masked]>
Date: Tue, 30 Sep 2008 17:24:49 +0100

> When managing such a scheme alongside an IPv6 prefix which 
> needs to be assigned to the same set of servers, which are 
> all dual-stack, the *number* of prefixes, their *relative* 
> numbering, and the host *addresses* within the prefixes, it 
> is quickly apparent that use of only /64 prefixes makes for a 
> management nightmare, particularly if renumbering of prefixes 
> and/or servers occurs, e.g. re-balancing the VLSM arrangement 
> itself in IPv4-land.

Given that in IPv6, you can justify allocating a /48 to each
separate site, which gives you 16 bits to mirror the IPv4
subnet hierarchy, while maintaining 64 bit interface sddresses,
I don't see a technical issue here.

And I would really recommend that you upgrade all of your management
systems to fully support IPv6 instead of relying on tricks like
generating an IPv6 address by applying a transform to an existing
IPv4 address. Then you have no technical issue at all.

--Michael Dillon

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2008 20:07:08 +0300 (EEST)

> proscribing non-64 bit prefixes?

If the non-64 prefixes had not been proscribed, we wouldn't have been 
able to use the existing engineering method to develop CGA/SEND 
specifications.  These are being leveraged in SHIM6 and potentially in 
other applications as well. Likely we couldn't even solve these 
engineering problems (at least without major drawbacks/other 
assumptions) if we couldn't have made assumptions about the 
widely-used prefix length.

That said, I personally use non-64 bit prefixes on point-to-point 
links between routers, but I have done so willingly and knowing that 
if the IETF develops anything fancy new stuff, I might not be able to 
use it or I might need to renumber.

> When managing such a scheme alongside an IPv6 prefix which needs to 
> be assigned to the same set of servers, which are all dual-stack, 
> the *number* of prefixes, their *relative* numbering, and the host 
> *addresses* within the prefixes, it is quickly apparent that use of 
> only /64 prefixes makes for a management nightmare, particularly if 
> renumbering of prefixes and/or servers occurs, e.g. re-balancing the 
> VLSM arrangement itself in IPv4-land.

I don't understand why *relative* numbering (i.e: overlapping subnet 
masks) is important in IPv6, and I'm not sure if I see the case even 
for v4.  Could you enlighten me?

I assume you refer to a scenario where on the same broadcast domain 
there are hosts which are configured with say A.B.C.0/24 length, and 
some others are configured with, say, A.B.C.D/28 prefix length.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 30 Sep 2008 19:36:45 +0200

Jeffrey, thanks for the email, I'm trying to be concise below.

> Dunn, Jeffrey H. wrote: [...]

Stateless autoconfiguration with IPv6 over Ethernet requires the
Interface ID to be 64bit (hence the prefix to he /64, or less, like /56,
or /48), otherwise it won't work: neither standards nor widespread
implementations can do stateless autoconfiguration with Ethernet and 
longer than 64 prefixes (e.g. /65 doesn't work).

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.
Moreover, if I already have IPv4 at home, which is subnetted, with
2-level NATting I'm forced to have a subnet topology for IPv4 different
than for IPv6 - incoherency.

The problem can even be aggresive: if the /64 limit is not overcome and
Ethernet 64bit IIDs are not allowed to be shorter some new IPv6 subnet
solutions may  approach very much NAT for IPv6.

In a typical WiFi Access Point landscape...

Sellers of these devices don't have a solution to program the WiFi AP
IPv6 in the same way they'd do it for IPv4.  For IPv4, the AP receives
an IPv4 address on the wired Ethernet and then does NAT and subnet
further on the wireless interface.  For IPv6, although it receives a
huge /64 IPv6 prefix on the wire it can't offer Stateless Autoconfig on
the  wireless interface.  This begs again for IPv6 NAT.

Alex

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Sep 2008 15:26:15 -0400

Pekka Savola wrote:
>> be assigned to the same set of servers, which are all dual-stack, the
>> *number* of prefixes, their *relative* numbering, and the host

Actually, that isn't the scenario. I should have gone into more detail
in the example(s).

The issue isn't an "in IPv6" issue, it is a "while doing dual-stack on a
whole lot of infrastructure which is statically numbered".

Example - unique broadcast domains per subnet, with statically assigned
IPs only, and dual-stack configurations on routers and hosts.

Consider an example pair of prefixes:

    * a globally announced IPv4 route: 192.168.42.0/24
    * a corresponding IPv6 route: FEC0:192:168:42::0/64
    * (for this example we use rfc 1918 addresses and site-local IPv6
      addresses)

If we have subnets 192.168.42.80/29 and 192.168.42.128/25 connected on
an edge router, on two different Ethernet ports of some flavor,
we would ideally also have corresponding IPv6 subnets that are
algorithmically derived from the IPv4 subnets.

For one example mapping:

    * The subnets are numbered identically, after converting to hexadecimal
    * The prefix lengths are 128 - (32 - n), i.e. 96+n, when the
      original IPv4 prefix length was /n
    * FEC0:192:168:42::50/125 and FEC0:192:168:42::70/121.
    * Individual hosts have the same last octet (albeit in hex rather
      than decimal).

For a different example mapping:

    * the prefix portion gets shifted left 4 nibbles (16 bits)
    * the prefix size is a fixed value (/112)
    * the hosts are numbered in hex-coded decimal
    * FEC0:192:168:42::80:0/112 and FEC0:192:168:42::128:0/112.
    * Host addresses would be, for example, FEC0:192:168:42::80:81
      (through *:87), and FEC0:192:168:42::128:129 (through *:255), all
      with mask of /112.
    * This would handle IPv4 prefixes up to /16 in size, and if there
      were a need to go bigger,
    * e.g. if the IPv4 prefix was /8 in size, make everything mask /104
      or /96 (96 is a bit easier to comprehend)

There is no overlap within IPv6 or within IPv4.

There is, however, an intended 1:1 match-up between each IPv4 address &
prefix, with a suitable IPv6 address and prefix.

The algorithmic nature of the match-up is to facilitate simpler designs
for management systems and/or human operator stuff.

This is especially important considering the number of different *kinds*
of things were multiple addresses/prefixes need to be managed - routers,
hosts (various O/S's), firewalls, databases, etc.

I hope this is a little more clear than my earlier brief description... :-)

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Oct 2008 09:14:43 +1300

Marla,

In what sense is "(e.g. on a basis of /48)" a recommendation?

   Brian

On 2008-10-01 04:09, Azinger, Marla wrote:
>>>>> -

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Oct 2008 09:23:25 +1300

On 2008-10-01 08:26, Brian Dickson wrote:
...
> algorithmically derived from the IPv4 subnets.

I used to think that was a good way to design an initial
IPv6 addressing plan. But from helping people design a real
addressing plan for a real campus with many years of IPv4
history, I've reached the conclusion that it's a really bad idea.
It's much better to design a clean IPv6 plan from the ground up,
rather than sweeping up the messy history of the IPv4 plan.

If you design a clean IPv6 plan that way, there doesn't seem to be
any incentive whatever to use anything other than /64 as
subnet prefixes (except for the router-router links, as Pekka
mentioned). There's a strong incentive in favour of /64,
i.e. the ability to use SLAAC, privacy addresses, and CGAs.

    Brian C

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 30 Sep 2008 17:16:19 -0400

> From: Brian E Carpenter [mailto:[email-masked]] 
> 
> ...

I second this.

My approach has been (rather, is being) to retain the same number of
separate subnets as I was using in IPv4, but to allow each one to become
far bigger now. Using the /64 prefix. And I'm creating these out of the
/56 blocks I'm being assigned.

Seems like a low risk way to go dual stack, and not run into any
unnecessary restrictions wrt IPv6 clients.

The incentive for greater than /64 prefix would be to prevent wanton
waste for such things as firewalls or serial links, I suppose.

Bert

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Sep 2008 17:17:50 -0400

> rather than sweeping up the messy history of the IPv4 plan.

I think the thing to be careful of, is jumping from "this is a better
way of doing things",
to "everyone has to do it this way".

Similarly, there is both a qualitative and quantitative difference
between anecdotal things,
and statistical things.

For instance, what works for one campus will likely work for most
campuses (campii?).

However, educational institutions number in the thousands, roughly,
while SMBs and ISPs
number in the 100s of thousands or more.

And many of those non-campus entities, are unable to (easily) go that route.

> i.e. the ability to use SLAAC, privacy addresses, and CGAs.

I agree. However...

Saying "I agree" doesn't mean that the original argument, (of managing
dual-stack networks
of servers which do not need, cannot use, and will never want, SLAAC,
privacy addresses,
DHCPv6, or anything other than static configurations, possibly centrally
managed), isn't valid.

Or, basically, the counter-argument is, if you don't do a clean design,
then you probably do
need non-64 bit subnets, period.

BTW - I am not advocating not doing a clean design. I'm saying that
while dual-stack is prevalent,
the benefits of managing the duality with crude but effective
implements, outweighs the
elegance of any alternative.

Being able to deploy something (IPv6) should be the central focus, not
making the thing being
deployed more "clean".

If the choice is fugly or not at all, the fugly choice must still prevail.

Which means we need to accommodate schemes we don't like, don't
advocate, but which are
a means to the desired end (IPv6 deployment, especially in a dual-stack
world.)

Brian Dickson

---

From: "TJ" <[email-masked]>
Date: Tue, 30 Sep 2008 17:33:16 -0400

>Sent: Tuesday, September 30, 2008 5:18 PM
>making the thing being deployed more "clean".
>
>Which means we need to accommodate schemes we don't like, don't advocate,
>but which are a means to the desired end (IPv6 deployment, especially in a
>dual-stack
>world.)

Indeed, flexibility is a great thing to have (but not necessarily to use!).
That is why the router vendors (should, and do AFAIK) allow you to configure
arbitrary prefix lengths.
That doesn't make it a good idea, but allows it when.it.is.needed.
In that sort of almost-broken environment, sure have a field day - but
always be sure the client understands the operational pain they are about to
sign up for in many cases.

/TJ