Well, on reading it, it's more an "IPv6: It's great -- ask
for it by name!" piece.
IPv6 gives me brain ache. I hear I'm not alone in that. I'd
v6 tomorrow if I didn't have to think about it so hard.
james wrote:
Well, on reading it, it's more an "IPv6: It's great -- ask
for it by name!" piece.IPv6 gives me brain ache. I hear I'm not alone in that. I'd
v6 tomorrow if I didn't have to think about it so hard.
You just need 96 more bits in your head everywhere you store IPv4 techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4 gave us brain ache when it was new to us too.
I'm sure there are already folks in environs that are mostly IPv6 that can spit off binary to hex to decimal IPv6 addresses. The US tends not to be one of those environs.
It'll come.
operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if its a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc).
I know we aren't use auto-config on critical server architecture and instead nailing in addressing like we would in IPv4. (an address hopping firewall is not necessarily a good thing 
).
Deepak
From: Deepak Jain [mailto:deepak@ai.net]
Sent: Monday, August 18, 2008 2:19 PM
To: james
Cc: nanog@nanog.org
Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drumjames wrote:
We’re running out of IPv4 addresses. Time for IPv6. Really. | Ars Technica
-addresses-time-for-ipv6-really.htmlWell, on reading it, it's more an "IPv6: It's great -- ask for it by
name!" piece.IPv6 gives me brain ache. I hear I'm not alone in that. I'd
v6 tomorrow if I didn't have to think about it so hard.You just need 96 more bits in your head everywhere you store IPv4
techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4
gave us brain ache when it was new to us too.
A little software and/or memory upgrade to support dual-stack?
I'm sure there are already folks in environs that are mostly IPv6 that can
spit off binary to hex to decimal IPv6 addresses. The US tends not to be
one
of those environs.
Indeed, we do exist! And it does become natural, given enough time &
practice.
(And yes, some of us are even in the US ... but not that many, yet (...
which is good for business ...))
It'll come.
operational content: Is anyone significantly redesigning the way they
route/etc to take advantage of any hooks that IPv6 provides-for (even if
its
a proprietary implementation)? As far as I can tell, most people are just
implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces,
etc).
From what I have seen, no.
I have seen no interest what-so-ever in redesigning the networks; most see
it as enough work to get IPv6 into their environment and don't want to
complicate the project with any "above and beyond" work. Additionally, most
are keeping IPv4 for just a bit longer so would be hampered in redoing their
architecture by that little factor.
I know we aren't use auto-config on critical server architecture and
instead
nailing in addressing like we would in IPv4. (an address hopping firewall
is
not necessarily a good thing
As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...
Deepak
/TJ
Yes, there are those of us who want to save number of routes and "spending" IPv6 addresses to save on TCAM and convergence time.
Using /112 for link networks to make the last octet ::1 and ::2 for links also makes sense from the human perspective.
Also, I try to involve myself in IETF ipv6ops-wg via their mailing list, and they're definitely interested in getting more people involved. Doing IPv6 in the core is easy, it's in the access that there is much work to be done for all access methods. If you're doing PPPoE you're probably home free, most of the rest just isn't operationally sane yet for ISP environment (stop customers doing rouge RA, man in the middle, spoofing).
For instance, I (and a few others) have been advocating that ISP core IPv6 space and customer IPv6 space should be separate, with link-local in between (so core can be "protected" at borders, and also to save on TCAM in the access devices (doing routing+antispoofing if there is only single /48 to the customer uses less router resources than doing /48 + link network)). Other people have other opinions.
A lot of this is happening now, so if you want something down the road, please put in the effort now.
There seem to be differing schools of thought on this, but personally I'm leaning in this direction at least for network infrastructure. Just because IPv6 provides boatloads more space doesn't mean that I like wasting addresses 
jms
From: Justin M. Streiner [mailto:streiner@cluebyfour.org]
Sent: Monday, August 18, 2008 3:18 PM
To: nanog@nanog.org
Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drumoperational content: Is anyone significantly redesigning the way they
route/etc to take advantage of any hooks that IPv6 provides-for (even
if its a proprietary implementation)? As far as I can tell, most
people are just implementing it as IPv4 with a lot of bits (i.e. /126s
for link interfaces, etc).There seem to be differing schools of thought on this, but personally I'm
leaning in this direction at least for network infrastructure. Just
because
IPv6 provides boatloads more space doesn't mean that I like wasting
addresses
Another side of that argument is operational complexity ... /126's do make
the addresses harder (as a previous poster mentioned) as well as inducing
other potential headaches (reserved address to watch out for, requiring
another route to get to a client's network, etc). That is why the official
answer is to always use /64s, even on PtP links. This is one area where the
real world and the IETF don't always agree, and in this case that can be OK.
jms
/TJ
That kind of thinking can easily lead you in the wrong direction.
For instance, hosting businesses that cater to small customers generally have a lot of problems with their IPv4 address provisioning: for a customer that only needs one or a few IPv4 addresses, it's not feasible to create a separate subnet, because that wastes a lot of addresses. But invariably, these customers on shared subnets grow, so over time the logical subnet gathers more and more IPv4 address blocks that are shared by a relatively large number of customers, and because of resistance to renumbering, it's impossible to fix this later on.
With IPv6 on the other hand, you can easily give each customer their own prefix which they'll pretty much never grow out of, and not be forced to artificially keep lots of customers in the same VLAN.
The extra 96 bits do make a difference.
Depends on who you consider 'official'
Antonio Querubin
whois: AQ7-ARIN
I don't have a problem with assigning customers a /64 of v6 space. My
earlier comments were focused on network infrastructure comprised of mainly
point-to-point links with statically assigned interface addresses. In that case, provisioning point-to-point links much larger than a /126, or at the maximum a /120 seems rather wasteful and doesn't make much sense.
jms
Well, the choice is really between /64 or not-/64. If the latter, you can number all your point-to-point links from a single /64 whether you give them a /96 or a /127. I recommend /112 because that way the subnet boundary falls on a colon. /120 or longer has some potential issues that are too boring to explain for the 50th time.
But since IPv6 routing protocols work on link locals, you really don't need _any_ global addresses on your point-to-point links...
From: Justin M. Streiner [mailto:streiner@cluebyfour.org]
Sent: Monday, August 18, 2008 5:29 PM
To: Iljitsch van Beijnum
Cc: nanog@nanog.org
Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drumJust because IPv6 provides boatloads more space doesn't mean that I
like wasting addressesThat kind of thinking can easily lead you in the wrong direction.
For instance, hosting businesses that cater to small customers
generally have a lot of problems with their IPv4 address provisioning:
for a customer that only needs one or a few IPv4 addresses, it's not
feasible to create a separate subnet, because that wastes a lot of
addresses. But invariably, these customers on shared subnets grow, so
over time the logical subnet gathers more and more IPv4 address blocks
that are shared by a relatively large number of customers, and because
of resistance to renumbering, it's impossible to fix this later on.I don't have a problem with assigning customers a /64 of v6 space. My
earlier comments were focused on network infrastructure comprised of mainly
point-to-point links with statically assigned interface addresses. In that
case, provisioning point-to-point links much larger than a /126, or at the
maximum a /120 seems rather wasteful and doesn't make much sense.
Actually, in most cases - you would assign customers more than a /64.
*Hopefully* a /56 as the smallest ... ~/48 for enterprises ...
jms
/TJ
Well, if y'all want a place to put this hints, I got a whole IPv6y
section over here:
http://bestpractices.wikia.com
Cheers,
-- jra
I don't have a problem with assigning customers a /64 of v6
space.
Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?
--Michael Dillon
I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
jms
Justin M. Streiner wrote:
I don't have a problem with assigning customers a /64 of v6
space.Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
Uh, the lower 64 bits of an IP6 address aren't used for routing you
know? They're essentially the mac address, or some other sort of
autoconf'd host identifier. Last I heard, the smallest allocation is
supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
was speaking of, though I'm not surprised. There's 64 bits for
routing... no need to be so stingy 
Mike
Uh, the lower 64 bits of an IP6 address aren't used for routing
they are. the /64 boundary is not in harwhere
randy
64 bits is not a magical boundary.
112 bits is widely recommended for linknets, for example.
64 bits is common, because of EUI-64 and friends. That's it.
There is nothing, anywhere, that says that the first 64 bits is for routing.
Michael Thomas wrote:
Justin M. Streiner wrote:
I don't have a problem with assigning customers a /64 of v6
space.Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?I don't operate an ISP network (not anymore, anyway...). My customers
are departments within my organization, so a /64 per department/VLAN
is more sane/reasonable for my environment.Uh, the lower 64 bits of an IP6 address aren't used for routing you
know? They're essentially the mac address, or some other sort of
autoconf'd host identifier. Last I heard, the smallest allocation is
supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
was speaking of, though I'm not surprised. There's 64 bits for
routing... no need to be so stingy
Last time I asked about this on the ipv6 list I got smacked for thinking
about using anything other than a /64 for subnets, even on point to
point links.
~Seth
Actually, there is text that says so:
RFC4291: IPv6 Addressing Architecture, section 2.5.1
" For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format."
The fact that most implementations ignore this is a different story.
In practice, many routers require the packet to go twice in the hardware if
the prefix length is > 64 bits, so even though it is a total waste of space,
it is not stupid to use /64 for point-to-point links and even for loopbacks!
- Alain.
In practice, many routers require the packet to go twice in the hardware if
the prefix length is > 64 bits, so even though it is a total waste of space,
it is not stupid to use /64 for point-to-point links and even for loopbacks!
some of us remember when we thought similarly for /24s for p2p links,
especially when using rip.
and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the
prudent operational advice today is to use a /127.
randy