Why don't you take an IPv6 address and convert it to dotted octets, then come back and report on how unweildy that is to deal with. Yes, hex is indeed more expressive, and once you start using IPv6 addressing some, it becomes very natural to work with. -- Jeff -----Original Message----- From: Alex Balashov <abalashov at evaristesys.com> Sent: Wednesday, October 21, 2009 8:27 AM To: David Hiers <hiersd at gmail.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] IPV6 David Hiers wrote:
Never looked into it yet. I"m still working on Gerald Ford's Great Metric Conversion :)
Our current business model doesn't contain a lot of drivers that might motivate an investigation.
The day IPv6 is adopted seriously, I am leaving networking/telecom and going to start a bakery. I can barely microwave Lean Cuisine, but perhaps I can secure some assistance from significant other. There is no way I am going to be managing infrastructure by way of hex nibbles. Remind me, why is it that nobody thought of using dotted decimal notation for IPv6 addresses, but just adding more octets? Are half-bite nibbles in a base humans aren't normally taught to count in more "expressive" somehow? -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Sure, a 128-bit address is going to be unwieldy in any notation. Why is hex better, I am genuinely curious? Does being able to slice at the half-byte boundary allow for some highly advantageous granularity I am failing to appreciate as an IPv6 n00b? -- Sent from mobile device On Oct 21, 2009, at 9:02 AM, Jeff McAdams <jeffm at iglou.com> wrote:
Why don't you take an IPv6 address and convert it to dotted octets, then come back and report on how unweildy that is to deal with.
Yes, hex is indeed more expressive, and once you start using IPv6 addressing some, it becomes very natural to work with.
-- Jeff
-----Original Message----- From: Alex Balashov <abalashov at evaristesys.com> Sent: Wednesday, October 21, 2009 8:27 AM To: David Hiers <hiersd at gmail.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] IPV6
David Hiers wrote:
Never looked into it yet. I"m still working on Gerald Ford's Great Metric Conversion :)
Our current business model doesn't contain a lot of drivers that might motivate an investigation.
The day IPv6 is adopted seriously, I am leaving networking/telecom and going to start a bakery. I can barely microwave Lean Cuisine, but perhaps I can secure some assistance from significant other.
There is no way I am going to be managing infrastructure by way of hex nibbles.
Remind me, why is it that nobody thought of using dotted decimal notation for IPv6 addresses, but just adding more octets? Are half-bite nibbles in a base humans aren't normally taught to count in more "expressive" somehow?
-- Alex
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Alex Balashov wrote:
Sure, a 128-bit address is going to be unwieldy in any notation.
Why is hex better, I am genuinely curious? Does being able to slice at the half-byte boundary allow for some highly advantageous granularity I am failing to appreciate as an IPv6 n00b?
There is some advantage to that, yes, when you're talking about DNS delegations, but I think the critical thing is that "255" is fewer characters than "ff". It really does come down to it being that simple. My employer has an IPv6 block out of ARIN's PI assignment space of 2620:0::/23. So I express the first two octets of that address with "2620" which ends up being more concise than the dotted decimal octets equivalent. Even when the conversion would leave you with two character results, versus 3, you still end up more concise because you drop the "." and still have a very readable chunk of the address. To step back, I agree with the original poster. I am absolutely dumbfounded that the voice industry, and VoIP industry in particular, hasn't latched on to IPv6 much much more than they have. Its a relatively closed ecosystem of devices and systems that could (at least in theory) be IPv6 enabled without having to enable a huge extra amount of infrastructure to support it (even transport networks need not be fully IPv6 enabled, although its certainly beneficial to be fully native). Losing NAT from the equation is zOMG hugely beneficial, or would be. I truly am dumbfounded at the resistance to IPv6 in the voice industry, one of the industries that would benefit the most from IPv6 adoption in my estimation. -- Jeff McAdams jeffm at iglou.com
Jeff McAdams wrote:
Alex Balashov wrote:
Sure, a 128-bit address is going to be unwieldy in any notation.
Why is hex better, I am genuinely curious? Does being able to slice at the half-byte boundary allow for some highly advantageous granularity I am failing to appreciate as an IPv6 n00b?
There is some advantage to that, yes, when you're talking about DNS delegations, but I think the critical thing is that "255" is fewer characters than "ff". It really does come down to it being that simple.
My employer has an IPv6 block out of ARIN's PI assignment space of 2620:0::/23. So I express the first two octets of that address with "2620" which ends up being more concise than the dotted decimal octets equivalent. Even when the conversion would leave you with two character results, versus 3, you still end up more concise because you drop the "." and still have a very readable chunk of the address.
It's certainly shorter. The issue is that it takes more effort and time mentally to compute contiguity, subnet boundaries, etc. because the numbers involved are not base 10. As you suggest, it's something one can probably get used to. But it sure is ugly in the interim. Being a systems programmer by trade, I have little difficulty counting in hex. It's just harder than counting in base 10, especially for people who aren't similarly disposed. And contractions do make it difficult to read. I do think that's one of the major barriers to the adoption of IPv6 in a commonsensical, pedestrian way. Nobody is against bigger address space, increased security, more interface autoconfiguration, etc. I think they just look at the addresses and go, "Uh, I don't want to read THAT..."
To step back, I agree with the original poster. I am absolutely dumbfounded that the voice industry, and VoIP industry in particular, hasn't latched on to IPv6 much much more than they have. Its a relatively closed ecosystem of devices and systems that could (at least in theory) be IPv6 enabled without having to enable a huge extra amount of infrastructure to support it (even transport networks need not be fully IPv6 enabled, although its certainly beneficial to be fully native).
Moving the transport core of a service provider to IPv6 is not so difficult. But taking advantage of all the benefits you cite requires that users be on IPv6 too, which is far from always a viable state of affairs at this point. It's more likely if you're a CLEC or ISP and control the network end-to-end to the customer edge, but nearly impossible if you're an ITSP without facilities affinity. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Alex Balashov wrote:
It's certainly shorter. The issue is that it takes more effort and time mentally to compute contiguity, subnet boundaries, etc. because the numbers involved are not base 10.
As you suggest, it's something one can probably get used to. But it sure is ugly in the interim.
Being a systems programmer by trade, I have little difficulty counting in hex. It's just harder than counting in base 10, especially for people who aren't similarly disposed. And contractions do make it difficult to read.
I do think that's one of the major barriers to the adoption of IPv6 in a commonsensical, pedestrian way. Nobody is against bigger address space, increased security, more interface autoconfiguration, etc. I think they just look at the addresses and go, "Uh, I don't want to read THAT..."
2607:f4b8:2:1:222:19ff:fe06:3f1/64 9735.62648.2.1.546.6655.65030.1009/64 50551973403764158466205629362970428401/64 The choice is theirs, I suppose. I mean, we don't really have a choice on the expanded address space, might as well go big and never worry about it until after we retire :)
On Wed, Oct 21, 2009 at 11:47 AM, Alex Balashov <abalashov at evaristesys.com> wrote: [cut]
It's certainly shorter. ?The issue is that it takes more effort and time mentally to compute contiguity, subnet boundaries, etc. because the numbers involved are not base 10.
subnetting in v6 follows pretty simple boundaries (should be viewed in a fixed-width font): /16 /32 /48 /64 /80 /96 /112 v v v v v v v 2001:aaaa:bbbb:cccc:dddd:eeee:ffff:1111 some other useful information: http://digitalfreaks.org/~lavalamp/CIDR6.html http://www.ripe.net/info/info-services/addressing.html http://nanog.org/meetings/nanog47/presentations/Wednesday/Hughes_Kosters_fun... my employer primarily uses sonus...ipv6 isn't something that they are planning to add for perhaps a few years (most days i'm not sure they can even do ipv4 correctly). my network kit is currently cisco and v6 is inconsistent ("why do you want v6, are you out of addresses?"). vote with your money, if your vendor won't/can't get good v6 support in hardware (not a software hack), find someone who will. /joshua -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams -
Alex Balashov wrote:
It's certainly shorter. The issue is that it takes more effort and time mentally to compute contiguity, subnet boundaries, etc. because the numbers involved are not base 10.
I disagree completely. After a short adjustment time, I find that its considerably *easier* to compute those things. Since those computations are all, ultimately, based on base 2 which maps cleanly to hex, and considerably less cleanly to decimal, ultimately it ends up being easier to compute these things in hex. Quick, is 1.2.3.70/29 in the same network as 1.2.3.71/29? Ugh. I'll take hex, where, it may not be easy, because, yeah, we're used to mentally dealing with decimal (because we have 10 fingers), but it does actually end up being easier in hex than decimal.
As you suggest, it's something one can probably get used to. But it sure is ugly in the interim.
There is an adjustment period, but then we all had an adjustment period to get used to IPv4 network/netmask/broadcast/network computation rules, too. Ultimately, once you make the adjustment, IPv6 ends up actually being easier. Trust me, I was surprised by it as well, but it really does.
I do think that's one of the major barriers to the adoption of IPv6 in a commonsensical, pedestrian way. Nobody is against bigger address space, increased security, more interface autoconfiguration, etc. I think they just look at the addresses and go, "Uh, I don't want to read THAT..."
The problem is that its a myth. People *think* its harder, but it ends up not actually being harder.
Moving the transport core of a service provider to IPv6 is not so difficult. But taking advantage of all the benefits you cite requires that users be on IPv6 too, which is far from always a viable state of affairs at this point. It's more likely if you're a CLEC or ISP and control the network end-to-end to the customer edge, but nearly impossible if you're an ITSP without facilities affinity.
Again (trying to retain some semblance of on-topic-ness here), native IPv6 isn't absolutely necessary. There are other ways of getting IPv6 to endpoints. I have IPv6 on my home network, when my broadband provider probably hasn't even heard of the concept, yet. Other techniques can get IPv6 addressing and transport on endpoints without upstream networks, or even the local network, supporting IPv6. If those techniques were built into endpoints, all of the problems with NAT suddenly disappear, even without end-to-end control all the way out to the edge. -- Jeff McAdams jeffm at iglou.com
Jeff McAdams wrote:
Quick, is 1.2.3.70/29 in the same network as 1.2.3.71/29? Ugh. I'll take hex, where, it may not be easy, because, yeah, we're used to mentally dealing with decimal (because we have 10 fingers), but it does actually end up being easier in hex than decimal.
Fair point.
As you suggest, it's something one can probably get used to. But it sure is ugly in the interim.
There is an adjustment period, but then we all had an adjustment period to get used to IPv4 network/netmask/broadcast/network computation rules, too. Ultimately, once you make the adjustment, IPv6 ends up actually being easier. Trust me, I was surprised by it as well, but it really does.
I'll take your word for it. For all my griping, I certainly haven't had to get into it deeply enough to see it from the other end of the conversion process.
Again (trying to retain some semblance of on-topic-ness here), native IPv6 isn't absolutely necessary. There are other ways of getting IPv6 to endpoints. I have IPv6 on my home network, when my broadband provider probably hasn't even heard of the concept, yet. Other techniques can get IPv6 addressing and transport on endpoints without upstream networks, or even the local network, supporting IPv6. If those techniques were built into endpoints, all of the problems with NAT suddenly disappear, even without end-to-end control all the way out to the edge.
That's true. And any amount of augmented complexity - real or imagined - with IPv6 is likely to be offset by the benefits of getting rid of NAT entirely, especially in protocol stacks that don't really deal with it well (SIP). -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
On 21/10/09?13:47?-0400, Alex Balashov wrote:
It's certainly shorter. The issue is that it takes more effort and time mentally to compute contiguity, subnet boundaries, etc. because the numbers involved are not base 10.
That's highly debatable, since it's base 16 and generally makes it simple to do subnetting.
Being a systems programmer by trade, I have little difficulty counting in hex. It's just harder than counting in base 10, especially for people who aren't similarly disposed. And contractions do make it difficult to read.
Service providers get allocated a /32 (unless they can justify a bigger block). That means that the ISP is generally subnetted on the 4th byte (or 8th nibble - leading zeros are removed). e.g.: 2610:b8::/32 ISPs are expected to assign a /48 (6th byte): 2610:b8:1::/48 or a /56 (7th byte): 2610:b8:1:2:/56 to customers. ISPs don't care how addressing happens after that. As a provider you deal in subnets, not addresses (generally speaking). End users/network operators are expected to subnet on the /64 boundary (8th byte): 2610:b8:1:302::/64 and depending on deployment, can leave address assignment up to auto configuration, which is where you get the really ugly looking addresses: 2610:b8:1:302:215:c5ff:fef1:8be1/64 or you can use DHCPv6 or statically assign, like you do today with IPv4 - except that you have the hex (0-f) issue as you've noted. Other than that, there's really no *counting* involved in IPv6. There's nothing that says you have to assign your static addresses incrementally - you can, for instance, match the last octet of your IPv4 address with the last byte of your IPv6 address, which is what I prefer and doesn't get too bad: 2610:b8:1:302::1/64 2610:b8:1:302::254/64 etc.
I do think that's one of the major barriers to the adoption of IPv6 in a commonsensical, pedestrian way. Nobody is against bigger address space, increased security, more interface autoconfiguration, etc. I think they just look at the addresses and go, "Uh, I don't want to read THAT..."
I would be very surprised if this was a significant barrier.
Moving the transport core of a service provider to IPv6 is not so difficult. But taking advantage of all the benefits you cite requires that users be on IPv6 too, which is far from always a viable state of affairs at this point. It's more likely if you're a CLEC or ISP and control the network end-to-end to the customer edge, but nearly impossible if you're an ITSP without facilities affinity.
It's not so impossible if you view IPv6 as an added service, rather than a replacement for IPv4. Dual-stacking solves the chicken-and-egg problem of who converts first, and being able to support IPv4 and IPv6 simultaneously. -- Dan White
Thank you, Dan. This is very helpful information. Dan White wrote:
On 21/10/09 13:47 -0400, Alex Balashov wrote:
It's certainly shorter. The issue is that it takes more effort and time mentally to compute contiguity, subnet boundaries, etc. because the numbers involved are not base 10.
That's highly debatable, since it's base 16 and generally makes it simple to do subnetting.
Being a systems programmer by trade, I have little difficulty counting in hex. It's just harder than counting in base 10, especially for people who aren't similarly disposed. And contractions do make it difficult to read.
Service providers get allocated a /32 (unless they can justify a bigger block). That means that the ISP is generally subnetted on the 4th byte (or 8th nibble - leading zeros are removed). e.g.:
2610:b8::/32
ISPs are expected to assign a /48 (6th byte):
2610:b8:1::/48
or a /56 (7th byte):
2610:b8:1:2:/56
to customers. ISPs don't care how addressing happens after that. As a provider you deal in subnets, not addresses (generally speaking).
End users/network operators are expected to subnet on the /64 boundary (8th byte):
2610:b8:1:302::/64
and depending on deployment, can leave address assignment up to auto configuration, which is where you get the really ugly looking addresses:
2610:b8:1:302:215:c5ff:fef1:8be1/64
or you can use DHCPv6 or statically assign, like you do today with IPv4 - except that you have the hex (0-f) issue as you've noted.
Other than that, there's really no *counting* involved in IPv6. There's nothing that says you have to assign your static addresses incrementally - you can, for instance, match the last octet of your IPv4 address with the last byte of your IPv6 address, which is what I prefer and doesn't get too bad:
2610:b8:1:302::1/64 2610:b8:1:302::254/64 etc.
I do think that's one of the major barriers to the adoption of IPv6 in a commonsensical, pedestrian way. Nobody is against bigger address space, increased security, more interface autoconfiguration, etc. I think they just look at the addresses and go, "Uh, I don't want to read THAT..."
I would be very surprised if this was a significant barrier.
Moving the transport core of a service provider to IPv6 is not so difficult. But taking advantage of all the benefits you cite requires that users be on IPv6 too, which is far from always a viable state of affairs at this point. It's more likely if you're a CLEC or ISP and control the network end-to-end to the customer edge, but nearly impossible if you're an ITSP without facilities affinity.
It's not so impossible if you view IPv6 as an added service, rather than a replacement for IPv4. Dual-stacking solves the chicken-and-egg problem of who converts first, and being able to support IPv4 and IPv6 simultaneously.
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
On Oct 21, 2009, at 1:28 PM, Jeff McAdams wrote:
To step back, I agree with the original poster. I am absolutely dumbfounded that the voice industry, and VoIP industry in particular, hasn't latched on to IPv6 much much more than they have. Its a relatively closed ecosystem of devices and systems that could (at least in theory) be IPv6 enabled without having to enable a huge extra amount of infrastructure to support it (even transport networks need not be fully IPv6 enabled, although its certainly beneficial to be fully native).
Losing NAT from the equation is zOMG hugely beneficial, or would be. I truly am dumbfounded at the resistance to IPv6 in the voice industry, one of the industries that would benefit the most from IPv6 adoption in my estimation.
OK, let's go over the reasons from an ISTP standpoint: - L3 routing and firewalling upgrades required. Wait, your 6509/7206VXR support IPv6? Yeah....it does. Most of it in CPU. You will be CRUSHED if you try to do what you are likely doing now as far as PPS and ACLs in IPv6 without an upgrade to the latest gear. - ISP support - how many of you actually have upstreams that fully support IPv6? Do you really want to count on tunneling for your transit? - ARIN support - Really, guys? You complain about running out of space, yet you want to bill the crap out of me to use "the solution"? Give me a /32 PI for every /22 allocation I already have, for free, and you might see some more people spending more time demanding that their upstreams support IPv6, justifying IPv6 capable gear in upgrade cycles, etc, etc (i.e.: reaching a carrier-class layer 3 tipping point for IPv6) - SBC support: Why would they bother when the L3 isn't there in most cases? Not a single one of my carriers supports IPv6, so why would I even ask for it from my SBC? I'm sure there's more, but that's off the top of my head. Bottom line: we don't even have critical mass in basic L3 connectivity. Could pushing it from the application side help? Probably. Is there any current well justified business case? No. Not considering the realities of business short-sightedness and budgetary constraints. Daryl
Daryl G. Jurbala wrote:
On Oct 21, 2009, at 1:28 PM, Jeff McAdams wrote:
To step back, I agree with the original poster. I am absolutely dumbfounded that the voice industry, and VoIP industry in particular, hasn't latched on to IPv6 much much more than they have. Its a relatively closed ecosystem of devices and systems that could (at least in theory) be IPv6 enabled without having to enable a huge extra amount of infrastructure to support it (even transport networks need not be fully IPv6 enabled, although its certainly beneficial to be fully native).
Losing NAT from the equation is zOMG hugely beneficial, or would be. I truly am dumbfounded at the resistance to IPv6 in the voice industry, one of the industries that would benefit the most from IPv6 adoption in my estimation.
OK, let's go over the reasons from an ISTP standpoint: - L3 routing and firewalling upgrades required. Wait, your 6509/7206VXR support IPv6? Yeah....it does. Most of it in CPU. You will be CRUSHED if you try to do what you are likely doing now as far as PPS and ACLs in IPv6 without an upgrade to the latest gear.
My 7206VXR shows that my ipv6 is being cef switched.... Of course the entire platform is CPU based so who knows.
- ISP support - how many of you actually have upstreams that fully support IPv6? Do you really want to count on tunneling for your transit? I do have native ipv6 on one, and I'm tunneled 2 hops away on the other, still within the purview of the carrier's network. - ARIN support - Really, guys? You complain about running out of space, yet you want to bill the crap out of me to use "the solution"? Give me a /32 PI for every /22 allocation I already have, for free, and you might see some more people spending more time demanding that their upstreams support IPv6, justifying IPv6 capable gear in upgrade cycles, etc, etc (i.e.: reaching a carrier-class layer 3 tipping point for IPv6) Read the NPRM carefully, you already can get a /32 PI free of charge if you have a /21 or larger (might even apply for a /22, can't remember). You pay the larger of the two ARIN fees, not the combination.
- SBC support: Why would they bother when the L3 isn't there in most cases? Not a single one of my carriers supports IPv6, so why would I even ask for it from my SBC?
I'm sure there's more, but that's off the top of my head. Bottom line: we don't even have critical mass in basic L3 connectivity. Could pushing it from the application side help? Probably. Is there any current well justified business case? No. Not considering the realities of business short-sightedness and budgetary constraints. Not demanding the support is a very chicken/egg situation. I demand support even for things that won't have v6 capability and have no demand so the features are there when I need them. (I do this with plenty of features I don't currently use but would like to in the future). Waiting until you have an urgent need before starting the process of requesting the feature is something I wholeheartedly encourage my competitors to do.
-Paul
On Mon, Oct 26, 2009 at 8:23 AM, Daryl G. Jurbala <daryl at introspect.net> wrote: [cut]
OK, let's go over the reasons from an ISTP standpoint: - L3 routing and firewalling upgrades required. ?Wait, your 6509/7206VXR support IPv6?
as i pointed out, cisco has crap ipv6 support...juniper and foundry both have solid hardware support (and have had).
- ISP support - how many of you actually have upstreams that fully support IPv6? ?Do you really want to count on tunneling for your transit?
this is mostly FUD and an attitude in futility: ipv4 will be gone within a few years. ipv6 is the only path forward. so, you can continue to complain that v6 isn't v4, or, you can start pushing your vendors for better support. there are isps with native v6 support here in the us: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit level3, tata, hurricane electric, global crossing, cogent, nlayer, etc, etc
- ARIN support
getting space from arin is trivial. arin's support for v6 is unequivocal.
- SBC support: Why would they bother when the L3 isn't there in most cases? ?Not a single one of my carriers supports IPv6, so why would I even ask for it from my SBC?
see the above link: if your providers don't offer v6, get new ones. if your vendors don't support v6, ask them why and look for others
I'm sure there's more, but that's off the top of my head. ?Bottom line: we don't even have critical mass in basic L3 connectivity. ?Could pushing it from the application side help? ?Probably. ?Is there any current well justified business case? ?No. ?Not considering the realities of business short-sightedness and budgetary constraints.
just because joesbaitntackleandbudgetwholesaleisp doesn't know how to spell ipv4^h6 doesn't mean that there isn't a demand. the large isps in the us all have to get v6, and soon. the slow ones are still trying to monetise it and are losing market share. there is native v6 transit and peering available. there is a very good business case: ipv4 will be exhausted within the next few years. if that doesn't make sense, then feel free to sit back and do nothing. otherwise i would suggest that you start planning and designing to support ipv6. you might have enough time to get a migration plan together and hardware tested before arin has no more ipv4 addresses and your hand is forced /joshua -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams -
Hello All, On 10/26/09 2:20 PM, "joshua sahala" <jsahala at gmail.com> wrote:
- ARIN support
getting space from arin is trivial. arin's support for v6 is unequivocal.
You can find registration support for IPv6 here: http://www.arin.net/resources/request/index.html If you have any trouble at all requesting IPv6 resources you can reach ARIN's registration services help desk using the phone number listed at the above link. Warm regards, Richard Jimmerson Chief Information Officer American Registry for Internet Numbers (ARIN) --
On Oct 26, 2009, at 2:39 PM, Richard Jimmerson wrote:
Hello All,
On 10/26/09 2:20 PM, "joshua sahala" <jsahala at gmail.com> wrote:
- ARIN support
getting space from arin is trivial. arin's support for v6 is unequivocal.
You can find registration support for IPv6 here:
http://www.arin.net/resources/request/index.html
If you have any trouble at all requesting IPv6 resources you can reach ARIN's registration services help desk using the phone number listed at the above link.
Warm regards,
Richard Jimmerson Chief Information Officer American Registry for Internet Numbers (ARIN)
I'll take IPv6 space. AS16734. For free, or as a condition of my continued IPv4 space. When I inquired about this when I registered for the AS, I was told that that program had ended. Has this policy again changed and ARIN is now allocating IPv6 space without charging? Daryl
Hello Daryl, On 10/26/09 3:57 PM, "Daryl G. Jurbala" <daryl at introspect.net> wrote:
I'll take IPv6 space. AS16734. For free, or as a condition of my continued IPv4 space.
When I inquired about this when I registered for the AS, I was told that that program had ended.
Has this policy again changed and ARIN is now allocating IPv6 space without charging?
The ARIN Board of Trustees had waived all fees for IPv6 registration for many years. Fees are still waived by a certain percentage according to the schedule available at this link. IPv6 fee waiver information is available at the bottom of the page. http://www.arin.net/fees/fee_schedule.html Organizations who currently pay a subscription fee to ARIN for IPv4 address space will not pay an additional fee for their IPv6 registration. Warm regards, Richard Jimmerson Chief Information Officer American Registry for Internet Numbers (ARIN)
Thank you for clarifying, whoever I spoke with at ARIN a year ago didn't seem to understand the policy any better than I did. So, you can take ARIN fees off of my list. The rest still stands. On Oct 26, 2009, at 4:25 PM, Richard Jimmerson wrote:
Hello Daryl,
On 10/26/09 3:57 PM, "Daryl G. Jurbala" <daryl at introspect.net> wrote:
I'll take IPv6 space. AS16734. For free, or as a condition of my continued IPv4 space.
When I inquired about this when I registered for the AS, I was told that that program had ended.
Has this policy again changed and ARIN is now allocating IPv6 space without charging?
The ARIN Board of Trustees had waived all fees for IPv6 registration for many years. Fees are still waived by a certain percentage according to the schedule available at this link. IPv6 fee waiver information is available at the bottom of the page.
http://www.arin.net/fees/fee_schedule.html
Organizations who currently pay a subscription fee to ARIN for IPv4 address space will not pay an additional fee for their IPv6 registration.
Warm regards,
Richard Jimmerson Chief Information Officer American Registry for Internet Numbers (ARIN)
Daryl G. Jurbala wrote:
So, you can take ARIN fees off of my list. The rest still stands.
OK, so let's go back to the original list: L3 routing/firewalling upgrades required, specifically mentioned was 6509 and 7206VXR. Someone else commented that the 7206VXRs were CEF switching IPv6, and I can confirm that the 6509's L3 switch IPv6 in hardware as well. The only caveat is finding the right firmware that has it with the mix of line cards that you have in your chassis. Overall, however, the platform does support it. Obviously Cisco has a *huge* product line, and I doubt we'll ever get a full accounting of what does and doesn't do IPv6 "in hardware" on this list, but to claim that you have to replace all of your hardware, is certainly a large exaggeration. ISP support Most of the major Internet backbone providers offer IPv6 support of some sort, admittedly not all do, but most do. Ask your providers and there's a good chance they can deliver it to you. Yes, some are still doing tunnels for it, but they do work well. Besides, you're presenting a false dichotomy, if you go digging, there's a decent chance that your IPv4 traffic is also using a tunneling technology within your providers' networks as well, frequently MPLS. Tunneling IPv6 in IPv4 is not fundamentally different. ARIN support This one has already been covered. SBC support This was part of the whole point of the thread. Why hasn't the voice industry adopted IPv6 more aggressively? I was including the SBC (and other gear and software) vendors in the voice industry there. Yes, this is probably the only real obstacle you presented that would prevent voice operators (admittedly the focus of this list) from really deploying IPv6 aggressively, but I will say that my commentary was commentary about the overall industry, including the gear and software vendors. Seriously, IPv6 makes so many things work so much easier...just in eliminating NAT, particularly for SIP...that, yeah, I think its a no-brainer to be working towards this. Maybe its not feasible to get it running in a production level today, but if you've got vendors roadblocking you from getting there, they should be hearing from you that its just not acceptable. The payoff (particularly for VoIP protocols) is just too great. -- Jeff McAdams jeffm at iglou.com
2009/10/27 Jeff McAdams <jeffm at iglou.com>
SBC support
This was part of the whole point of the thread. Why hasn't the voice industry adopted IPv6 more aggressively? I was including the SBC (and other gear and software) vendors in the voice industry there. Yes, this is probably the only real obstacle you presented that would prevent voice operators (admittedly the focus of this list) from really deploying IPv6 aggressively, but I will say that my commentary was commentary about the overall industry, including the gear and software vendors.
Freeswitch supports SIP over IPv6 in it's main production code base, it isn't a separate set of patches like asterisk's current v6 support. -- Craig Askings Network Engineer | Over the Wire Pty Ltd craig at overthewire.com.au | www.overthewire.com.au Phone: 07 3847 9292 | Fax: 07 3847 9696 | Mobile: 0404 019 365
It hasn't been introduced into most product lines for the same reason any other feature hasn't been implemented in a vendor's system - lack of financial motivation. These guys build for their biggest (volume and $$) customers and their needs, so obviously companies like Acme, BroadSoft, Sonus, Polycom, Aastra, Adtran, etc are simply not seeing a business need to take the time to develop IPv6 into their products yet. Among IPv6's strongest supporters have been the open source community (look how long the Linux kernel has had basic v6 support), so I'm not surprised at all that projects like Freeswitch or OpenSER (and its various names) have taken the small step to add support for the addressing. Basically I think you'll see IPv6 support in these types of commercial voice products only when there becomes a drive for it from their large carrier customers. The large carriers have however been the slowest to try new technologies in the VOIP realm, so v6 I'm sure is still way down the line. -Scott From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Craig Askings Sent: Monday, October 26, 2009 7:25 PM To: VoiceOps Subject: Re: [VoiceOps] IPV6 2009/10/27 Jeff McAdams <jeffm at iglou.com> SBC support This was part of the whole point of the thread. Why hasn't the voice industry adopted IPv6 more aggressively? I was including the SBC (and other gear and software) vendors in the voice industry there. Yes, this is probably the only real obstacle you presented that would prevent voice operators (admittedly the focus of this list) from really deploying IPv6 aggressively, but I will say that my commentary was commentary about the overall industry, including the gear and software vendors. Freeswitch supports SIP over IPv6 in it's main production code base, it isn't a separate set of patches like asterisk's current v6 support. -- Craig Askings Network Engineer | Over the Wire Pty Ltd craig at overthewire.com.au | www.overthewire.com.au Phone: 07 3847 9292 | Fax: 07 3847 9696 | Mobile: 0404 019 365
On 27/10/09?10:42?-0400, Scott Berkman wrote:
It hasn't been introduced into most product lines for the same reason any other feature hasn't been implemented in a vendor's system - lack of financial motivation. These guys build for their biggest (volume and $$) customers and their needs, so obviously companies like Acme, BroadSoft, Sonus, Polycom, Aastra, Adtran, etc are simply not seeing a business need to take the time to develop IPv6 into their products yet.
As I've mentioned before, Acme has support for IPv6 in at least one of their products. Freeswitch is another good option. If a vendor is not producing IPv6 enabled equipment today, then it's operating under a shaky business plan. I understand the argument that a vendor must see financial justification before IPv6 enabling its equipment, but it must also anticipate future demand. As is the case for much of the industry, *someone* has good IPv6 support for any piece of the network you wish to deploy - even Cisco (I'm not sure where the idea came from that they have poor support). You don't need to dump all your equipment today, and go out and purchase new equipment that's IPv6 enabled. You still have time to replace equipment during your normal equipment replacement cycles and probably be in good shape. Where I'd recommend focusing your attention is on the access side of your network and your CPEs, which tend to have the longest life cycles, and which would be the most expensive to replace (at least for us). As you introduce IPv6 enabled equipment in your network, dual stack it and you'll be future proofing (at layer-3) that portion of your network. -- Dan White
Which Soft or Class4/5 switching vendor with integrated SS-7 features supports IPv6 today? Anyone have something like this in production? -Scott -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Tuesday, October 27, 2009 11:18 AM To: Scott Berkman Cc: 'Craig Askings'; 'VoiceOps' Subject: Re: IPV6 On 27/10/09?10:42?-0400, Scott Berkman wrote:
It hasn't been introduced into most product lines for the same reason any other feature hasn't been implemented in a vendor's system - lack of financial motivation. These guys build for their biggest (volume and $$) customers and their needs, so obviously companies like Acme, BroadSoft, Sonus, Polycom, Aastra, Adtran, etc are simply not seeing a business need to take the time to develop IPv6 into their products yet.
As I've mentioned before, Acme has support for IPv6 in at least one of their products. Freeswitch is another good option. If a vendor is not producing IPv6 enabled equipment today, then it's operating under a shaky business plan. I understand the argument that a vendor must see financial justification before IPv6 enabling its equipment, but it must also anticipate future demand. As is the case for much of the industry, *someone* has good IPv6 support for any piece of the network you wish to deploy - even Cisco (I'm not sure where the idea came from that they have poor support). You don't need to dump all your equipment today, and go out and purchase new equipment that's IPv6 enabled. You still have time to replace equipment during your normal equipment replacement cycles and probably be in good shape. Where I'd recommend focusing your attention is on the access side of your network and your CPEs, which tend to have the longest life cycles, and which would be the most expensive to replace (at least for us). As you introduce IPv6 enabled equipment in your network, dual stack it and you'll be future proofing (at layer-3) that portion of your network. -- Dan White
None, but IPV6 support and IPV6 > IPV4 IWF support in the SBC can make this a moot point until the softswitch manufacturers get their act together allowing the network core to stay on V4. The SBCs and the endpoints are the critical pieces. On Tue, 2009-10-27 at 11:28 -0400, Scott Berkman wrote:
Which Soft or Class4/5 switching vendor with integrated SS-7 features supports IPv6 today? Anyone have something like this in production?
-Scott
-----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Tuesday, October 27, 2009 11:18 AM To: Scott Berkman Cc: 'Craig Askings'; 'VoiceOps' Subject: Re: IPV6
On 27/10/09 10:42 -0400, Scott Berkman wrote:
It hasn't been introduced into most product lines for the same reason any other feature hasn't been implemented in a vendor's system - lack of financial motivation. These guys build for their biggest (volume and $$) customers and their needs, so obviously companies like Acme, BroadSoft, Sonus, Polycom, Aastra, Adtran, etc are simply not seeing a business need to take the time to develop IPv6 into their products yet.
As I've mentioned before, Acme has support for IPv6 in at least one of their products. Freeswitch is another good option.
If a vendor is not producing IPv6 enabled equipment today, then it's operating under a shaky business plan. I understand the argument that a vendor must see financial justification before IPv6 enabling its equipment, but it must also anticipate future demand.
As is the case for much of the industry, *someone* has good IPv6 support for any piece of the network you wish to deploy - even Cisco (I'm not sure where the idea came from that they have poor support).
You don't need to dump all your equipment today, and go out and purchase new equipment that's IPv6 enabled. You still have time to replace equipment during your normal equipment replacement cycles and probably be in good shape.
Where I'd recommend focusing your attention is on the access side of your network and your CPEs, which tend to have the longest life cycles, and which would be the most expensive to replace (at least for us).
As you introduce IPv6 enabled equipment in your network, dual stack it and you'll be future proofing (at layer-3) that portion of your network.
On Oct 27, 2009, at 10:42 AM, Scott Berkman wrote:
It hasn?t been introduced into most product lines for the same reason any other feature hasn?t been implemented in a vendor?s system ? lack of financial motivation.
And that was exactly the point I was making. It's hard to justify any financial expenditures as a small/medium ITSP when you can't demonstrate a push by the people you connect with (on the carrier side) and a tipping point of consumer access available with IPv6 (on the CPE side). Financial expenditures include not only gear and software, but man hours for planning. Especially the planning - because right now its not even clear exactly what/when you're planning for. You want to talk from a purely technical standpoint? Sure, IPv6 will make things much easier as far as CPE access and NAT. But I'd like to think that most of us here who deal with CPE behind NAT are pretty good at it at this point. I know I am. Sure, life would be easier without it, but it's completely manageable. Even 2 and 3 deep. Running out of IP addresses? My /22 will do well for me for many years. I'm not worried about running out of space on my end. Especially as many of the devices I'm using increase their (for lack of a better term) port density so I can run (and therefor address) fewer of them. Daryl
On Oct 26, 2009, at 2:20 PM, joshua sahala wrote:
as i pointed out, cisco has crap ipv6 support...juniper and foundry both have solid hardware support (and have had).
My point: many shops are Cisco. This required buying new hardware.
this is mostly FUD and an attitude in futility: ipv4 will be gone within a few years. ipv6 is the only path forward. so, you can continue to complain that v6 isn't v4, or, you can start pushing your vendors for better support.
there are isps with native v6 support here in the us: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
level3, tata, hurricane electric, global crossing, cogent, nlayer, etc, etc
etc, etc indeed. Did you notice how SHORT that list is compared to the number of transit providers out there? This is not even close to critical mass. I'm also not sure you know what FUD means.
- ARIN support
getting space from arin is trivial. arin's support for v6 is unequivocal.
When money is no object, ALL of what I brought up is trivial.
see the above link: if your providers don't offer v6, get new ones.
if your vendors don't support v6, ask them why and look for others
I think you missed my point. You might as well just sum up your entire message with "buy new equipment and get new providers." Daryl
participants (10)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
craig＠overthewire.com.au -
daryl＠introspect.net -
dwhite＠olp.net -
jeffm＠iglou.com -
jsahala＠gmail.com -
paul＠timmins.net -
richardj＠arin.net -
scott＠sberkman.net