And I understand clients having needs, as well.
First, I would encourage the client to try and get (as feasible) a large
block ... add bits to the left instead of the right.
(I realize that if this was feasible, we might not be having this
conversation now ... but had to say it regardless)
Secondly, I would ask if other options been pursued ... if you can share
Your client's need is why I referenced the (expired) draft -->
http://tools.ietf.org/html/draft-dickson-v6man-new-autoconf-00
... there may be more appropriate drafts out there, this is just the
first probably-relevant one I found ...
-If- there is consensus that this need is prevalent, make a standard and see
-if- you can get vendor buy-in.
I personally think those are two very big "ifs", but I have
certainly been wrong atleast once or thrice in the past :).
Again, these conversations all took place 10-15 years ago and all of
those needs, decisions, etc. fed into the current standard.
... not saying things can't change, obviously(!), but unless
new reasons have arisen I remain skeptical.
"As to vendor pain, going down the road of minimizing vendor pain leads us
back to every vendor selling a proprietary networking protocol"
I think the opposite is true ... isn't that part of the standardization
process; to reduce those proprietary situations and providing a consistent,
level playing field? Everything over IP is the path of least resistance
today for a good reason. The operational pain comes into play in that once
something longer is standardized, it will likely be used by providers and
thus limit future client capabilities based on current client needs -
something IPv6 is expressly trying to avoid.
FWIW, I would be quite distraught if my ISP tried to give me only 16 host
bits / 64k worth of addresses.
Anything less than 64 host bits now, or even 48 host bits as one draft has
proposed, breaks autoconf.
That is bad right out of the shoot.
Oh, and yes - I said only 64k IPs.
I know of lots of ongoing development in "dense node" applications, and I
want myself and my clients to be ready to take advantage of those in the not
too distant future. Which is (just) part of the justification for the
64bits in the first place; but I am not saying these desires outweigh your
client's current need.
... great conversation so far, now I am back to work ...
/TJ
>-----Original Message-----
>From: Dunn, Jeffrey H. [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 02, 2008 12:00 PM
>To: TJ; ipv6@ietf.org
>Cc: Dunn, Jeffrey H.; [EMAIL PROTECTED]
>Subject: RE: what problem is solved by proscribing non-64 bit prefixes?
>
>TJ,
>
>I understand that you do not see the need to a prefix longer than 64 bits;
>however, my customer has an application for extended address. As a result,
>there is an engineering need.
>
>I am not sure that I see any pain for current providers or environments.
>Those who are deploying 64 bit prefixes and want to stick with them are
free
>to do so. As to vendor pain, going down the road of minimizing vendor pain
>leads us back to every vendor selling a proprietary networking protocol.
>
>As to breaking the RFC, although no one can stop me, it increases my pain,
>which I have an incentive to avoid.
>
> With regards to ISPs handing out smaller prefixes, I believe that should
>remain between the ISP and customer. Personally, I could care less if my
>ISP handed me a /112. That still leaves 16 bits or 65535 end systems,
which
>is more than enough for my home. Businesses needing more space would
>negotiate a larger allocation and, like IPv4 addresses, probably have to
pay
>for it.
>
>Best Regards,
>
>Jeffrey Dunn
>Info Systems Eng., Lead
>MITRE Corporation.
>(301) 448-6965 (mobile)
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TJ
>Sent: Thursday, October 02, 2008 8:38 AM
>To: ipv6@ietf.org
>Subject: RE: what problem is solved by proscribing non-64 bit prefixes?
>
>I also tend to not favor "that's the way we have always done it" type of
>arguments.
>
>In this case, however, I just see it in an operational and pragmatic
>perspective -
>1) I fail to see the need for more subnet bits, based on current deployment
>plans calling for /48s or /56s per client
>2) I certainly see an operational pain point for all current vendors,
>providers and environments that currently support/provide/use IPv6
>3) Nothing stops you from breaking the RFC and doing arbitrary bit length
>subnets now, as long as you are willing to endure the pain involved
>
>Additionally, if longer prefixes are normalized, what would prevent
>providers from adjusting their allocations accordingly and the end-users
>gaining nothing?
>(i.e. - instead of assigning /56s to support /64s, they would simply assign
>/108s to support /112s or somesuch.) ((or, at the very least, they could
>switch from assigning /56s to /64s and thus -requiring- (versus "enabling")
>you to do this type of
>subnetting))
>
>
>/TJ
>
>>-----Original Message-----
>>From: Dunn, Jeffrey H. [mailto:[EMAIL PROTECTED]
>>Sent: Wednesday, October 01, 2008 11:11 PM
>>To: Brian Dickson; TJ
>>Cc: IETF IPv6 Mailing List; Dunn, Jeffrey H.;
>>[EMAIL PROTECTED]; Martin, Cynthia E.
>>Subject: RE: what problem is solved by proscribing non-64 bit
>prefixes?
>>
>>I second Brian's points that:
>>
>>1. DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed
>2.
>>Basically, in the absence of the ability to subnet arbitrarily (on
>>non-64 bit boundaries), I'm at the mercy of my upstream.
>>
>>Further, I would like to summarize the reasons offered on this list
>for
>>proscribing all but 64-bit prefixes:
>>
>>1. That is the way the prefix is currently defined in mu favorite RFC
>2. We
>>have always done it that way 3. The decision was made 12 years ago and
>the
>>explanation is in a book
>>
>>None of these appear to be a compelling ENGINEERING reason to require
>64-bit
>>prefixes be the only acceptable option.
>>
>>Best Regards,
>>
>>Jeffrey Dunn
>>Info Systems Eng., Lead
>>MITRE Corporation.
>>(301) 448-6965 (mobile)
>>
>>
>>-----Original Message-----
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>Of
>>Brian Dickson
>>Sent: Wednesday, October 01, 2008 4:42 PM
>>To: TJ
>>Cc: 'IETF IPv6 Mailing List'
>>Subject: Re: what problem is solved by proscribing non-64 bit
>prefixes?
>>
>>TJ wrote:
>>>>> 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.
>>>>>
>>>> I'd say it begs for assigning the user a /56 or /48 routed to them
>>on the
>>>> /64 link.
>>>>
>>>
>>> Exactly right!
>>>
>>> A /56 to the home's DHCPv6-PD capable CPE.
>>> (Atleast) one "inside" segment (couple of switch ports, maybe an
>>antenna or
>>> two) for now - sporting SLAAC, maybe Stateless DHCPv6 as well?
>>> A healthy dose of stateful IPv6 firewalling, for those so inclined.
>>> Oh, and probably the same IPv4/NAT/FW we all know and love.
>>> Winner.
>>>
>>
>>The problem, fundamentally, is one's position in a hierarchy (of IPv6
>>assignments or pd's).
>>
>>In many markets, there is a (very) limited pool of ISPs (let along
>ISPs
>>offering IPv6 !!).
>>
>>And, consequently, the ability to ask for and receive something other
>than
>a
>>single /64, is limited by the availability of ISPs in the local pool
>who
>>offer it.
>>It doesn't much matter whether
>>the assignment of a /64 is dynamic or static - either way it bites.
>>
>>There is no guarantee that even a *single* ISP in any particular pool
>of
>>local ISPs, has enough clue to offer this, or the ability to offer it
>>(regardless of reason underlying the inability).
>>
>>This isn't something I, as a customer, have *direct* control over, and
>I
>may
>>not have an alternative (other ISP offering what I want).
>>
>>And it doesn't matter *why*.
>>
>>In such a situation, I am effectively "painted into a corner" (e.g.
>>when
>>viewing IPv6 space as a Heat Map / Hilbert curve).
>>
>>"Bits to the left of me, Bits to the right, Here I am - Stuck in the
>middle
>>again".
>>(Apologies to the original artist and those who don't like puns.)
>>
>>The question is, what does one do in such a scenario, and/or what
>*can* one
>>do?
>>
>>If the ability to do what one wants, is permitted by non-64 bit
>prefixes,
>>life is good.
>>DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed for
>this.
>>
>>If only 64-bit prefixes can be used, then one gets only one 64-bit
>prefix
>to
>>use for everything. Good luck with that.
>>
>>Basically, in the absence of the ability to subnet arbitrarily (on
>>non-64 bit boundaries), I'm at the mercy of my upstream.
>>
>>128 bits doesn't look so wonderful in such a scenario, I would
>surmise.
>>
>>Nobody is a winner. :-(
>>
>>Brian
>>
>>
>>
>>--------------------------------------------------------------------
>>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
--------------------------------------------------------------------
