I've it working with TWC with a Motorola SB6141 and a RB450G router board running MikroTik RouterOS I had to replace the old modem which didn't have DOCSIS 3 and upgrade the RouterOS 6.3. So far from both Windoze and Linux machines have now full IPv6 connectivity. One gizmo app that became very handy is the ipvfoo extension or the chrome browser that adds an icon on the status bar showing it the contents for the page arrived via IPv6/4 or both. I believe there is now a port for firefox. I'm getting a /64 from TWC, seems to work reliably well. -Jorge

On Nov 23, 2013, at 12:57 AM, Brian Henson <marine64@gmail.com> wrote:

Now if Time Warner Cable would get their act together in Ohio (looks at them :) )

I'm going to answer two posts here. First you're correct this appears to be a 6rd, and it is a /60 IPv6 Status Available Global Unicast IPv6 Address 2602:306:cddd:1c50::/60 Border Relay IPv4 Address 12.83.49.81 On 11/23/2013 1:58 AM, Constantine A. Murenin wrote:

On 22 November 2013 22:22, Andrew D Kirch <trelane@trelane.net> wrote:

...

Status Available Global IPv6 Address 2602:306:cddd:xxxx::1/64 Link-local IPv6 Address fe80::923e:abff:xxxx:7e40 Router Advertisement Prefix 2602:306:cddd:xxxx::/64 IPV6 Delegated LAN Prefix 2602:306:cddd:xxxx:: 2602:306:cddd:xxxx:: I don't believe this is native IPv6; it's probably still their 6rd, which has, in fact, been live since at least February 2012, i.e. for close to two years at this point.

http://tu.cnst.su/post/16958139578/at-t-u-verse-6rd-in-santa-clara-county http://www.tunnelbroker.net/forums/index.php?topic=2293.0

And, yes, AT&T is probably still keeping this whole thing a secret.

C.

With comcast you can check on everything at comcast6.net. It will tell you if your CMTS is enabled. Jared Mauch

On Nov 23, 2013, at 2:13 AM, ML <ml@kenweb.org> wrote:

Comcast claims a /60 via DHCP-PD is available everywhere now.

On 28 November 2013 13:07, Leo Vegoda <leo.vegoda@icann.org> wrote:

Andrew D Kirch wrote:

Was I the only one who thought that everything about this was great apart from this comment:

...

In reality additional poking leads me to believe AT&T gives you a rather generous /60

Is a /60 what is considered generous these days? I thought a /48 was considered normal and a /56 was considered a bit tight. What prefix lengths are residential access providers handing out by default these days?

Remember, this is just 6rd. With 6rd, a /60 does sound quite generous indeed. And it's a /60 for each IPv4 you have, e.g. if you have a static IP allocation with AT&T U-verse, say, a /27, then you're effectively getting a /55 (plus also an additional /60 for the DHCP address in a shared subnet to which your /27 is routed to). That said, I wholeheartedly agree with your comment otherwise. C.

On 28 November 2013 14:56, Mark Andrews <marka@isc.org> wrote:

In message <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com> , "Constantine A. Murenin" writes:

...

On 28 November 2013 13:07, Leo Vegoda <leo.vegoda@icann.org> wrote:

...

Andrew D Kirch wrote:

Was I the only one who thought that everything about this was great apart from this comment:

...

In reality additional poking leads me to believe AT&T gives you a rather generous /60

Is a /60 what is considered generous these days? I thought a /48 was considered normal and a /56 was considered a bit tight. What prefix lengths are residential access providers handing out by default these days?

Remember, this is just 6rd. With 6rd, a /60 does sound quite generous indeed .

You can hand out /48 as easily with 6rd as you can natively.

It's only when the ISP is lazy and encodes the entire IPv4 address space into 6rd thereby wasting most of the IPv6 address space being used for 6rd that a /60 appears to be generous.

You can do a 6rd domain per IPv4 allocation. This is a one time operation that doesn't need to be updated as you move IPv4 address space around.

This might be true with smaller ISPs, but someone like AT&T probably already has too many distinct IPv4 allocations for such an encoding to be practically manageable. Free, who has pioneered 6rd, and is a major ISP in France, seems to have gone with a similar 6rd allocation policy, giving out /60 through 6rd for each IPv4, out of a /28 IPv6. Seems quite reasonable. http://ripe58.ripe.net/content/presentations/ipv6-free.pdf (So, AT&T simply copied the French here, it would appear.) C.

...

And it's a /60 for each IPv4 you have, e.g. if you have a static IP allocation with AT&T U-verse, say, a /27, then you're effectively getting a /55 (plus also an additional /60 for the DHCP address in a shared subnet to which your /27 is routed to).

That said, I wholeheartedly agree with your comment otherwise.

C.

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

I'd like to call everyone's attention to ARIN's policy on IPv6 transition space https://www.arin.net/policy/nrpm.html#six531 which was created specifically in response to the standardization of 6rd. The discussion at the time that this policy was under consideration was that encoding the [m,n] in a non-overlapping fashion when one has a bajillion allocations due to slow start was a pain in the butt and that, in practice, everyone would just encode 32 bits of IPv4 into 6rd. Note that it's possible to get a /24 of IPv6 space (huge!). Yes, it's from space that is "tainted" as being marked as transition space. Yes, you have to recertify that you're using it for the intended purpose every three years. Of course, 24 + 32 = 56. This is not an accident. It was our sense at the time that /56 was bad enough and that there was no reason to codify giving people an even more parsimonious slice of IPv6 space. So there really is no excuse on AT&T's part for the /60s on uverse 6rd... -r

On Dec 2, 2013, at 13:25 , Ricky Beam <jfbeam@gmail.com> wrote:

On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs@seastrom.com> wrote:

...

So there really is no excuse on AT&T's part for the /60s on uverse 6rd...

Except for a) greed ("we can *sell* larger slices") and b) demonstrable user want/need.

How many residential, "home networks", have you seen with more than one subnet? The typical household (esp Uverse) doesn't even customize the provided router. Even a CCIE friend of mine has made ZERO changes to his RG -- AT&T turned off WiFi and added the static block at install. (I know NANOG is bad sample as we're all professionals and setup all kinds of weird configurations at "home". I have 3 nets in continuous use... a legacy public subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping that network (because it's too small), and a second RFC1918 net from a second ISP)

Quite a few with at least three out there these days. Many home gateways now come with separate networks for Wired, WiFi, and Guest WiFi. However, as I have repeatedly said... IPv6 is not about just what we need today. What we need today is limited to what we could do with the scarcity inherent in IPv4 addressing. Restricting IPv6 based on those limitations is absurd. IPv6 should be about what we want to be able to do in 5, 10, 20, and 50 years. It shouldn't be about what we need today.

I wouldn't use the word "generous", but a /60 (16 "LAN"s) is way more than what 99% of residential deployments will need for many years.

I'm not so sure about that, depending on how you define "many". Worse, if it becomes the widespread lowest common denominator, then it will become somewhat of a self-fulfilling prophecy in that engineers will design to what users have instead of to what users should be able to get.

We've gotten by with a single, randomly changing, dynamic IP for decades. Until routers come out-of-the-box setup for a dozen networks, non-networking pros aren't going to need it, or even know that it's possible. (and the default firewalling policy in Windows is going to confuse a lot of people when machines start landing in different subnets can "see" each other.)

Yes, we've suffered with a severely degraded internet for decades. Is that really a reason not to make things better going forward? I don't think so. Routers are already starting to come out of the box with the ability to do prefix delegation and being able to connect multiple routers together into automatically generated hierarchies is a technology that is just beginning to be explored. Given that Cell Phones and Tablets are already widely used as routers, I don't think that increasing router ubiquity is all that unlikely in the home market in just a few years.

Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to the power of huge, but it's still finite. People like you are repeating the same mistakes from the early days of IPv4... the difference is, we won't be around when people are cursing us for the way we mismanaged early allocations. Indeed, a /64 is too little (aka "bare minimum") and far too restrictive, but it works for most simple (default) setups today. Which leads to DHCPv6 PD... a /60 is adequate -- it's the minimal space for the rare cases where multiple nets are desirable or necessary. The option for /56 or even /48 should exist (esp. for "business"), but the need for such large address spaces are an EXCEPTION in residential settings. (and those are probably non-residential users anyway.) [FWIW, HE.net does what they do as marketing. And it works, btw.]

I hate to break it to you, but, no, nobody is really paying for that space. There is no inherent cost to address space relative to the size of the address space. The cost is related to administering the registrations of that space. Once you get above a certain size, your ARIN fees do not go up. If you have fewer than 60,000 customers, you can give all of them a /48 for $2000/year. That works out to less than $0.04 per customer per year. If you have fewer than 1,000,000 customers, you can give all of them a /48 for $4,000/year which works out to less than $0.005 per customer per year. By the way, those numbers leave GENEROUS room for ISP internal infrastructure, overhead, etc. (536 /48s in the first case and 48,576 /48s in the second case). Arguing that "someone is paying for those addresses" just doesn't work out when you look at the actual costs. There are enough /48s available in 2000::/3 to give every person alive from now until 2050 16 /48s and still have many left over. For all of you who keep wanting to repeat the scarcity problems of IPv4 in IPv6 and waste the space by leaving it sitting on the shelf instead of wasting it by handing it out to users, I offer this compromise... Let's try giving out /48s liberally in 2000::/3. If we exhaust 2000::/3 before I am dead, I will be the first one to help you champion more restrictive policies for the remaining 7/8ths of IPv6. (I expect to live something close to another 50 years and there's not much I can to do help with more restrictive policies beyond my death anyway). Owen

On Dec 2, 2013, at 14:35 , Ricky Beam <jfbeam@gmail.com> wrote:

On Mon, 02 Dec 2013 16:42:02 -0500, Owen DeLong <owen@delong.com> wrote:

...

Quite a few with at least three out there these days. Many home gateways now come with separate networks for Wired, WiFi, and Guest WiFi.

Interesting... I've not looked at the current "high end" (i.e. things that cost more than $17 at Tiger Direct.)

Maybe you should expand your consideration to include $30-$50 at Best Buy.

...

However, as I have repeatedly said... IPv6 is not about just what we need today. What we need today is limited to what we could do with the scarcity inherent in IPv4 addressing. Restricting IPv6 based on those limitations is absurd.

DHCPv6-PD isn't a "restriction", it's simply what gets handed out today. A "simple" reconfiguration on the DHCP server and it's handing out /56's instead. (or *allowing* /56's if requested -- it's better to let the customer ask for what they need/want; assuming they just default to asking for the largest block they're allowed and using only 3 networks.)

No, DHCPv6-PD isn't a restriction. Only handing out a /60 _IS_ a restriction. As to a "simple" reconfiguration, not really. That depends very much on how the infrastructure that DHCP server supports is architected.

...

IPv6 should be about what we want to be able to do in 5, 10, 20, and 50 years. It shouldn't be about what we need today.

We don't know what we'll need in the future. We only know what we need right now. Using the current dynamic mechanisms we can provide for now and "later", as "later" becomes apparent.

Circular and short-sighted argument. There's already clear evidence that having a wider bit field will enable greater flexibility and better application development, so we should be deploying that wider bitfield. You're arguing the network equivalant of "we shouldn't deploy charging stations until there are tons of electric cars on the road." I'm arguing that we'll never see tons of electric cars on the road until there is a widespread infrastructure of charging stations. So far, in the electric car world, it seems that charging stations are starting to pop up all over the place and as they become more widespread, indeed, more electric cars are hitting the road.

...

Yes, we've suffered with a severely degraded internet for decades. Is that really a reason not to make things better going forward? I don't think so.

More complex is not always "better". This is doubly true here as very few people ("the public") have any measurable clue when it comes to networks. The Internet is just something that works. When you start mixing in multiple networks, that's going to create problems for them. Recall my Windows warning... the default firewall setup blocks inbound access from outside the local subnet. So with the above 3-way router, a PC on the wired network and a laptop on WiFi would not be able to talk to each other without MANUAL adjustment -- or Microsoft will have to start making (even more) dangerous assumptions about one's network [assume every "LAN" is /60? /56?, on top of the already Bad Idea(tm) that "ALL LANS ARE SLASH SIXTY-FOUR, SO SAYETH THE RFC!"]

I agree... The unnecessary complexity inherent in NAT and even moreso with CGN is horrible. Multiple networks will be plug and play. Heck, they already are in some circumstances... Look at the number of people that have no trouble converting their cell phones and tablets from simple nodes to internet routers. I don't know why you think that the PC and Laptop can't talk to each other. It actually seems to work just fine. They both default to the upstream router and the router has more specifics to each of the two LAN segments. Micr0$0ft doesn't have to make any assumptions at all. In the IPv6 world, they can use site-scoped multicast (ffx5::). All that is required in that case is for the home gateway to know that it is the home gateway and not a lower-level router within the site. (More accurately, it needs to be able to distinguish between the provider link and it's intra-site links. I believe that is generally something that the gateway should be able to do automatically... (The DSL or Cable interface is obviously not intra-site, for example).

...

I hate to break it to you, but, no, nobody is really paying for that space.

Go talk to your bean counters. There's a line-item charge for your address space; they'll want it as small as possible. (they'll also want to make as much money off that space as possible. Even if *you* aren't charging for IPv{4,6} space, almost everyone else does, and wants to continue. Because it's a major source of revenue.)

I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 address space. Frankly, if you're paying for IPv6 space, you're not too bright. You can go get a direct assignment from an RIR so easily for $100/year that it just doesn't make sense to pay more than that. Owen

On Dec 2, 2013, at 15:45 , Ricky Beam <jfbeam@gmail.com> wrote:

On Mon, 02 Dec 2013 17:54:50 -0500, Owen DeLong <owen@delong.com> wrote:

...

I don't know why you think that the PC and Laptop can't talk to each other. It actually seems to work just fine. They both default to the upstream router and the router has more specifics to each of the two LAN segments.

You are confusing ROUTING with the WINDOWS FIREWALL (on by default)

Wired pinging Wireless will be dropped by the OS as foreign, unsolicited traffic. (I see it often enough: A cannot talk to B because they're in different networks.)

Meh... The firewall will get updated and will have to become more intelligent. Given that Micr0$0ft also turns on automatic updates by default, I'm not too worried about the people who haven't configured their windows box. Besides, Windows is actually losing market share these days anyway.

...

Micr0$0ft doesn't have to make any assumptions at all. In the IPv6 world, they can use site-scoped multicast (ffx5::).

People don't even know what link-local addresses are (and they don't cross links.) Site-local (ULA) requires administrative configuration; no machine, by default, will have a ULA address until manually configured (i.e. they see an RA.)

I didn't say ULA or Site-Local. I said Site-Scoped multicast (ffx5::) specifically. (Site Local is deprecated, ULA is fd00::/8). Further, according to Homenet work going on in the IETF, like it or not, most homenet gateways will be choosing and advertising a ULA prefix for the home in addition to the GUA prefix assigned by the service provider. However, coming back to what I was actually talking about, mDNS/SAP/Network Browser/Network Neighborhood/whatever you want to call the discovery mechanism du jour can find the hosts on the other networks within the site using site-scoped multicast groups (which start with ffx5::/16) and could even do some of their communication (e.g. negotiating for changes in the default firewall posture) via that mechanism.

...

Frankly, if you're paying for IPv6 space, you're not too bright. You can go get a direct assignment from an RIR so easily for $100/year that it just doesn't make sense to pay more than that.

If you can justify it. A home user... good luck with that (a: getting the space, and then b: getting Uverse, etc. to use it.) For a business, I always say get your own space, unless you like re-numbering every time you change providers. (we've done it 5 times in 10 years. 'tho none of them have ever supported IPv6; shame on them.) [while "renumbering" the network may be simple, changing the prefix(es) that have been recorded in various systems is still a pain.]

I'm a home user. I run my own /48 ARIN assignment here. I use tunnels to routers in colo and only use Comcast et. al to provide transit for the tunnels themselves. My point is that home users by and large don't pay for any address space and there's not much to be gained from trying to charge them for it. Beyond home users, there's not much point in paying any significant amount of money for it. There's no meaningful cost in providing home users with /48s... So much so, in fact, that the cost of taking even a single phone call complaining about an undersized IPv6 assignment probably more than pays for assigning /48s to 1,000 customers. Owen

On Dec 2, 2013, at 16:45 , Ricky Beam <jfbeam@gmail.com> wrote:

On Mon, 02 Dec 2013 18:54:24 -0500, Owen DeLong <owen@delong.com> wrote:

...

I said Site-Scoped multicast (ffx5::)

And just how does one telnet/ssh/smb/http/whatever to another machine via MULTICAST? You don't. Locating the machine isn't the issue; having an address that can be trivially determined as "local" is. ULA would work, but you'd have to know to use that address instead of any global address.

You don't, but it's easy enough for Windows to do discovery and/or negotiation for firewall holes with multicast and avoid making assumptions about where the site boundary is. You made the claim that additional assumptions were required. I countered that argument. Mark countered with another alternative solution which would require updating the software. My solution has the advantage that only windows firewalls need to be updated and that could be handled by a windows auto-update (which is on by default in current versions of windows unless you have already performed manual intervention, in which case I don't see manual intervention on the firewall as a huge additional hurdle).

...

I'm a home user. I run my own /48 ARIN assignment here. I use tunnels to routers in colo and only use Comcast et. al to provide transit for the tunnels themselves.

Right. So every "home user" (read: grandmother) should request their own PI space, that they'll then have to tunnel to a far more expensive COLO...

I didn't say that it was the right solution for everyone. I said that it was an effective solution for some.

PI space is useless to residential customers because no residential ISP will ever bother with the headache. (I never liked dealing with business customers here, and they were paying a lot more for the privilege, and presumably had a clue.)

To each their own. FWIW, you can run a BGP tunnel with HE at no cost, so IPv6 PI for free is a viable option. Again, not saying it's the solution for everyone, just saying that it can be done.

...

My point is that home users by and large don't pay for any address space and there's not much to be gained from trying to charge them for it.

ISPs do it right now for IPv4; and it makes them real money. They're not going to want to give that up. You don't, and that's fine. But I can assure you the suits what to keep cashing those checks.

No, it doesn't. It keeps users from using more space more than it brings in revenue. Mostly it's a "headache charge". They can't get away with flat out saying no, so they price it into the "only if you're really serious about wanting it" category and that limits the number of customers asking for it. In IPv4, where address scarcity is an issue, this makes sense. In IPv6, they should be laughed out of existence if they engage in such silliness. You are assuming that I don't talk to the people that deal with this stuff at the major providers. You are mistaken in that assumption. Owen

On Dec 2, 2013, at 18:05 , Ricky Beam <jfbeam@gmail.com> wrote:

On Mon, 02 Dec 2013 20:18:08 -0500, Owen DeLong <owen@delong.com> wrote:

...

You don't, but it's easy enough for Windows to do discovery and/or negotiation for firewall holes with multicast and avoid making ...

Actually, your process still makes a very dangerous assumption... you have to assume the address passed via multicast is, in fact, a local address. Since it is necessarily outside your prefix, you have to either make assumptions about what is "close" to your prefix -- assumes the site is contiguous, or trust any address passed to you. Hackers will have fun screwing up your firewall rules and potentially breaking into your servers. (if you're foolish enough to not have any other layers in your network, which is likely with home networks.)

Not really... First of all, domain or other windows authentication could be used to validate the request. Second, if it's site-scope multicast, unless both your ISP _AND_ your own router are doing something wrong, it shouldn't get forwarded into your site from outside.

...

... They can't get away with flat out saying no...

Says who? TWC has been saying "no" for years. (unless I'm mistaken, "always".)

No, they've said "get a business connection." Close to "no", but not identical. Owen

On 03/12/13 02:54, Owen DeLong wrote:

I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 address space.

There is some ISP who afraid their users will be reselling their connectivity to other users around. While I didin't see that in years (probably last time in 2005) but still this exist in poor regions. Other than that, completely agree on /56y default and /48 on request, but most ISPs here are give-out just single /64.

In message <529D9492.8020205@inblock.ru>, Nikolay Shopik writes:

On 03/12/13 02:54, Owen DeLong wrote:

...

I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 add ress space.

There is some ISP who afraid their users will be reselling their connectivity to other users around. While I didin't see that in years (probably last time in 2005) but still this exist in poor regions.

And if they didn't resell it they probably wouldn't have a customer in the first place. Unless you offer "unlimited" plans the ISP isn't losing anything here. The bandwidth being used is being paid for. If it isn't the ISP needs to adjust the price points to cover their costs rather than hoping that people won't use all of the bandwidth they have purchased. It's two maybe sales vs one confirmed sale. This is like the whole tethered debate. Why should the ISP care about which device the packets are source from. The customer is buying so many gigabytes of traffic a month. They should be able to use them anyway they see fit without actually breaking the laws of the land. I let my daughter's friends use the net at home here. If they burn through my monthly allotment well then I need to pony up more money or take a reduced service level until the month ends. It's none of my ISP's concern how the bandwidth I have purchased from them is being used. Note there really isn't unlimited. There is pipe width * 29-30 days of traffic. If you have purchased a "unlimited" service then you should be able to pull that amount of traffic without the ISP complaining.

Other than that, completely agree on /56y default and /48 on request, but most ISPs here are give-out just single /64.

Which is just plain stupid. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Dec 4, 2013, at 10:32 , Nikolay Shopik <shopik@inblock.ru> wrote:

On 04.12.2013 4:14, Mark Andrews wrote:

...

In message <529D9492.8020205@inblock.ru>, Nikolay Shopik writes:

...

On 03/12/13 02:54, Owen DeLong wrote:

...

I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 add ress space.

There is some ISP who afraid their users will be reselling their connectivity to other users around. While I didin't see that in years (probably last time in 2005) but still this exist in poor regions.

And if they didn't resell it they probably wouldn't have a customer in the first place. Unless you offer "unlimited" plans the ISP isn't losing anything here. The bandwidth being used is being paid for. If it isn't the ISP needs to adjust the price points to cover their costs rather than hoping that people won't use all of the bandwidth they have purchased.

If we talk about end-user not business user, ISP assume 95th% load will be minimal so therefore it allow them to sell 100mbit for like 20-30$, while real price of it much higher.

Please tell me what provider is selling 100Mbit for $20-30 in the 408-532-xxxx area of San Jose, California. Currently, the only provider capable of delivering more than 768k wired here is charging me $100+/month for 30-50Mbps maximum. I could get 100Mbps from them, but they want $250+/month for that. If I can get 100Mbps for $20-30, I'd jump at it.

If its big ISP they usually don't care, as there always be downloaders who saturate their link to 90% most time, but compare to most of other users in their net, this will be not noticeable. If its just smallish ISP things get harder for it.

For $100+/month, frankly, it's none of their business whether I'm pooling my resources with my neighbors to pay for the connectivity or not.

...

This is like the whole tethered debate. Why should the ISP care about which device the packets are source from. The customer is buying so many gigabytes of traffic a month. They should be able to use them anyway they see fit without actually breaking the laws of the land.

If you actually pay per bit, true or have some kind "fair usage" unlimited plan.

Which is pretty much all that is available any more.

...

I let my daughter's friends use the net at home here. If they burn through my monthly allotment well then I need to pony up more money or take a reduced service level until the month ends. It's none of my ISP's concern how the bandwidth I have purchased from them is being used.

If you talk about wired connection, this thing almost non-existing here. Only apply to wireless 3G/4G ISPs with limited bits and then reduced service.

Not entirely sure what you are saying here. In this day and age, I don't see any reason that wireless providers should get a free pass or be able to sustain significantly worse policies than wireline providers. Wireless bandwidth is rapidly approaching parity with wired bandwidth pricing at consumer levels.

Some even come up with idea two separate /64 make things easier :-D, instead just put at least round /60

Actually, providing a separate /64 for the provider link makes a lot of sense. It really is best to pull that out of a separate provider aggregate across all the subscribers in the same aggregation group than to carve individual link prefixes out of each subscribers internal-use prefix. For example, if you get a tunnel from HE, then, by default, you get a /64 from our link block for the tunnel broker to which you connect and an additional /64 for your internal use by default. If you click the "please give me a /48" checkbox, then you'll also get an additional /48. We do this because it makes our provisioning easier and allows us to support users that want prefixes as well as users whose equipment (or brains) can't handle more than a single /64 for their LAN. There's really NOTHING to be gained from providing anything in between a /64 and a /48, so we don't do it. Owen

On Dec 4, 2013, at 12:35 , Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Wed, 4 Dec 2013, Owen DeLong wrote:

...

significantly worse policies than wireline providers. Wireless bandwidth is rapidly approaching parity with wired bandwidth pricing at consumer levels.

Have you seen the cost of an LTE base station including install and monthly fees? If you did, you wouldn't make that claim.

Nope... I look at the consumer side pricing and the fact that cellular providers by and large are NOT losing money. I assume that means that the rest of the math behind the scenes must work somehow.

If you want to deliver not even close to speed parity to fiber, you need multiple base stations per city block. This is extremely cost prohivitive, especially since you need fiber to the base stations anyway.

I'd love fiber, but I can't even get fiber in my neighborhood (or most of the civilized portions of the US) because fiber deployments are concentrated where rural subsidies are available due to USF market manipulations.

Btw, if I could convince everybody in my building to pay 400 USD install for fiber, I could get 100/100 Internet conenctivity for USD10 per month. There just isn't any way in the world this is doable with wireless.

Yeah, I'm sure there are all kinds of ways that wireline could be made cheaper, etc. However, I'm talking about comparing consumer pricing, not behind the scenes costs as the former is relatively easy to compare on even footing while the later is far to obfuscated by far too many parties to ever have a rational debate.

Don't make the mistake of comparing the dysfunctional US market pricing levels with what is actually doable in a working market.

I said nothing about what was possible... I only comment on what is actually happening. If you know how to achieve a functioning market in the US, I'm all ears. In the mean time, dysfunction is all I have available to work with. Owen

On Dec 4, 2013, at 13:43 , Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Wed, 4 Dec 2013, Owen DeLong wrote:

...

Nope... I look at the consumer side pricing and the fact that cellular providers by and large are NOT losing money. I assume that means that the rest of the math behind the scenes must work somehow.

Cost != price.

Price from the suppliers perspective absolutely = cost from the consumers perspective.

Also, wireless providers are not delivering the same service as wireline providers. How many gigabytes per month do you usually get for the same money on wireline compared to wireless?

Depends on your carrier. From AT&T, I have $29 unlimited and I have definitely cranked down more over that (faster) LTE connection in some months than through my $100+ cable connection. From VZW, I'm paying $100+/month and only getting 10GB over LTE, but I rarely exceed 10GB per month from my (again slower) cable connection. T-Mo is offering unlimited LTE for something like $100/mo IIRC. (Their plans change so often and so quickly right now that it's hard to keep up). Several of the MVNOs offer unlimited for $40/month.

...

Yeah, I'm sure there are all kinds of ways that wireline could be made cheaper, etc. However, I'm talking about comparing consumer pricing, not behind the scenes costs as the former is relatively easy to compare on even footing while the later is far to obfuscated by far too many parties to ever have a rational debate.

Consumer pricing often have nothing to do with cost in a dysfunctional market. It a functional market, cost and price are more closely related.

Who cares? I'm talking about cost to the consumer which is absolutely equivalent to price from the supplier since they are one and the same.

...

I said nothing about what was possible... I only comment on what is actually happening. If you know how to achieve a functioning market in the US, I'm all ears. In the mean time, dysfunction is all I have available to work with.

Well, there would have to be a huge amount of changes, and most likely only a portion of them would be implemented and then the changes would be deemed a failure.

Make it administratively fairly easy to put fiber in the ground. Make municipalities/utilities put in fiber along other infrastructure and make them rent it out at pricepoints that are related to cost.

If it's possible to rent dark fiber, then you can all of a sudden get competition instead of having a few huge companies dominate the market.

Access to possibility of renting or installing L1 infrastructure to the block/cabinet is the key.

Sure, I'd love to see all of that. I'd also love to see L1 providers prohibited from engaging in L2 and higher level service provision and require L1 providers to accept all comers on an equal price and service basis (fiber from the MMR to any given subscriber costs the same per strand no matter who you are, no matter how many you buy, etc.). However, just like the mythical isotropic radiator, I don't expect any of that to happen any time soon. So, in the meantime, wireless bandwidth cost (from an end-user perspective) is rapidly approaching wireline bandwidth cost as I said before. This is the reality that we currently live in, regardless of how dysfunctional it may be. Owen

On Dec 4, 2013, at 10:54 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Wed, 4 Dec 2013, Owen DeLong wrote:

...

Depends on your carrier. From AT&T, I have $29 unlimited and I have definitely cranked down more over that (faster) LTE connection in some months than through my $100+ cable connection.

From VZW, I'm paying $100+/month and only getting 10GB over LTE, but I rarely exceed 10GB per month from my (again slower) cable connection.

T-Mo is offering unlimited LTE for something like $100/mo IIRC. (Their plans change so often and so quickly right now that it's hard to keep up).

Several of the MVNOs offer unlimited for $40/month.

Have you tried downloading 500 gigabytes in a month on any of these? I highly doubt any of the LTE solutions are “unlimited" then.

Nothing is completely unlimited because you hit the bandwidth limitations if you try hard enough. I generally get around 40-50 Mbps over LTE. Downloading 500Gig at that rate would be roughly 1/2 of the maximum possible throughput for the entire month. Of course, I haven’t tried to do that because I can’t really think what I would do with the data. However, there have been months where I have done over 200GB on the AT&T connection. For my purposes, that’s close enough to unlimited. YMMV. Choose the plan that works best for you.

...

Who cares? I'm talking about cost to the consumer which is absolutely equivalent to price from the supplier since they are one and the same.

Your usage pattern makes wireless feasable. Watching two hours per day of Netflix 1080p on the above connections changes the equation completely.

I regularly watch 2 hours of netflix per day on my iPad, so in addition to some other bandwidth-intense things that I do (like downloading a complete set of aviation charts for the entire (not just continental) US, IFR and VFR) every 14-28 days, miscellaneous video surfing, and various other usage which is lower bandwidth (most of the time) plus an average of about 5GB per month of App updates most of which are downloaded via the LTE network, I would say my usage pattern falls exactly into the “changes the equation completely” category you just mentioned.

...

However, just like the mythical isotropic radiator, I don't expect any of that to happen any time soon. So, in the meantime, wireless bandwidth cost (from an end-user perspective) is rapidly approaching wireline bandwidth cost as I said before. This is the reality that we currently live in, regardless of how dysfunctional it may be.

For your usage pattern, I agree.

Except you just cited something that falls a little short of my usage pattern as an example of what doesn’t work, so, color me confused.

We have the same deal here, for the same price per month you can have access to ~80 megabit/s LTE, or you can have 100/10 cable. The problem is that with LTE you get 80 gigabytes/month in cap. The cable connection doesn't have a cap. Also, the cable connection actually delivers 100 megabit/s at peak to you, which the LTE connection definitely doesn’t (because you share the cell with hundreds of others).

If AT&T has capped me, then, I haven’t managed to hit the cap as yet. Admittedly, the connection isn’t always as reliable as $CABLECO, but when it works, it tends to work at full speed and it does work the vast majority of the time. OTOH, I have routinely run into circumstances where $CABLECO is not delivering what they promised in terms of throughput.

What's been happening here is that the price for fixed access has remained approximately the same (10-50 USD per month for 100/10 or 100/100 depending on if you have coax or fiber/CAT6), LTE is in the 20-50 USD range as well for 80 megabit/s, but you get capped and have to pay to increase your monthly cap. Thus, for light consumers this is fine, but for people who actually use their connection for video or bulk data, wireless is very much more expensive (which reflects actual cost of producing the service, wireline has a low marginal cost for bandwidth, there it’s establishing the infrastructure that costs, whereas for wireless you have medium-high cost for establishing the infrastructure, but also a medium-high cost to increase the bandwidth in the cell).

Even if you double the price of LTE today, that’s still less than 1/10th of the cost of equivalent bandwidth in 3G wireless. My argument wasn’t that they are equal today, but, that the price ramp on wireless is APPROACHING parity. The fact that you are arguing not that the price won’t reach parity, but, that the extent to which it has done so is limited kind of makes my point in that regard. Owen

On 12/05/2013 02:00 PM, Owen DeLong wrote:

If AT&T has capped me, then, I haven’t managed to hit the cap as yet. Admittedly, the connection isn’t always as reliable as $CABLECO, but when it works, it tends to work at full speed and it does work the vast majority of the time.

AT&T threatened to cap U-verse at 250 GB/mo several years ago, but they never seem to have followed through. It's probably about the only way that their incompetence is actually in the public interest. Monthly caps -- and even peak speed limits -- are a very poor idea in general because they don't take system conditions into account. A torrent that runs at night penalizes you just as much as one run at prime time. Actually more, since you probably get greater throughput at off-peak times and therefore hit your cap faster. If one *must* charge for usage on a shared network, the right thing is to base the monthly fee on *guaranteed* bandwidth because that's what actually drives costs. If more is available because others aren't using their guarantees, fine, you can have it for free. But it's not guaranteed. And you don't get a refund for not using your guarantee because the equipment still had to be allocated for you. Of course the real solution to nearly every problem with local broadband access is the same: meaningful competition. About the only way this could happen is for the municipality to install, own and maintain the fiber plant and lease it to any and all commercial service providers on a non-discriminatory and non-exclusive basis. Naturally this will never happen in the United States because the incumbents will scream "socialism!" at the top of their lungs and race to the state houses to outlaw it. Never mind that this is exactly how we've handled roads for centuries. --Phil

On 12/06/2013 05:54 AM, Mark Radabaugh wrote:

I realize most of the NANOG operators are not running end user networks anymore. Real consumption data:

Monthly_GB Count Percent <100GB 3658 90% 100-149 368 10% 150-199 173 4.7% 200-249 97 2.6% 250-299 50 1.4% 300-399 27 0.7% 400-499 9 0.25% 500-599 4 0.1% 600-699 4 0.1% 700-799 3 0.1%

...

800 1 0.03%

Overall average: 36GB/mo

The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. Do we do anything about it? No - because our current AUP and policies say he can do that.

Thanks for the stats, real life is always refreshing :) It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless of whether it's him or 4 people at 200GB? Mike

On 12/6/13 8:14 PM, Michael Thomas wrote:

Thanks for the stats, real life is always refreshing :)

It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude).

If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless of whether it's him or 4 people at 200GB?

Mike

Thank you for the response! Mr. Hog impacts other customers in that he blows the over subscription model for that particular tower site (and specifically the sector) well out of the norm. This specific sector has a capacity of ~10.5Mbps download so his continuous 3.5Mbps is noticed by other customers. It's a last mile capacity issue, not a transit cost. Heck - transit is cheap these days and we have more than 50% spare transit capacity. Last mile is expensive. Most sites have sector capacities of 35 or 70Mbps (and Mr. Hogs will be updated fairly soon). What I'm really trying to figure out is how to offer higher speed packages (15Mbps or higher) without having a 24x7 user kill the over-subscription ratio or forcing a early upgrade to the tower site. I understand the argument that you should have full capacity available for the peak hour - but that peak hour doesn't really exist anymore with home users. The only real usage dropoff is from 12:30am to about 7am. Do the top 10% cause any problems? Not currently since we kept the available speeds low. What I am trying to figure out is how to offer higher speeds for the average user without having to resort to lots of weaseling in the marketing / AUP, etc. Putting some sane limits on the upper few percent seems to make the most sense. I'm not set on billing for overages. A rate limit at the cutoff would also be workable. I'm not willing to do the hidden cap / fire the top user method. Mark -- Mark Radabaugh Amplex mark@amplex.net 419.837.5015 x 1021

On 12/8/2013 7:55 PM, Phil Karn wrote:

It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service.

Sometimes, yes. Othertimes, perhaps not. I seem to recall an early bit of research on interactive computing (maybe by Sackman) that showed user preference for a /worse/ average response time that was more predictable (narrower range of variance) than a better average time that was more erratic. So, stability over throughput, sort of. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

On 12/9/2013 12:48 AM, Jay Ashworth wrote:

A 3270 that took 5 seconds of delay and then *snapped* the entire screen up at once was perceived as "faster" than a 9600 tty that painted the same entire screen in about a second and a half or so. Don't remember who it was either, but likely Bell Labs.

This is a "screen/block" mode I/O issue versus a character-mode one. And the "screen/block" I/O won't start until the whole screen data is there, so there is an initial delay. The character-mode variant will paint portions of the screen as the data arrives. Similar anomalies exist on input... the screen/block mode is buffered locally and proceeds normally; while the character mode version has to transit the WAN link, whatever it may be. I won't argue that one is better than the other, depending on your link speed (transmitting a whole screen will incur longer delays than transmitting individual fields, though admittedly it happens "less" often). But the user perception goes a long way... I have seen advantages to both, having done serial termainal applications from back to the 1970s, and won't argue one way or the other. You choose your poison. With 3270 you have little choice other than "full screen" transactions. For other ASCII terminal interfaces, you could optimize the individual fields (while paying the "full screen" price). There are "user perceived" throughput values, "transaction perceived" throughput values, and "application perceived" throughput values. And very rarely did the three equal out for every application :( Jeff

On Mon, 09 Dec 2013 06:37:05 +0000, Gary Buhrmaster said:

It has been a long long time, but for the truly crazy, I thought it was possible to write single characters at a time (using a Set Buffer Address and then the character) as long as you had set up the field attributes previously. Lots of transactions, but one could appear to write out individual characters as slowly as the KSR 33 it replaced. Or perhaps my 3270 memory has finally faded away.

AIX/370 supported vi on a 3278-2 console. Phear.

----- Original Message -----

From: "Phil Karn" <karn@philkarn.net>

On 12/06/2013 05:54 AM, Mark Radabaugh wrote:

...

Currently, without a limit, there is nothing to convince a end user to make any attempt at conserving bandwidth and no revenue to cover the cost of additional equipment to serve high bandwidth customers. By adding a cap or overage charge we can offer higher speed plans.

Why is that?

Just guarantee each user a data rate that depends on how much he pays. Charge him by what it costs you to build and maintain that much capacity. Lots of mechanisms exist to do this: token bucket, etc.

He gets more than his guaranteed capacity only when others don't use theirs. Otherwise he won't. If that's unacceptable to him, then he has the choice of paying you more to upgrade your network or waiting for others to stop using their guarantees.

It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Your customers will eventually find themselves depending on that excess capacity often enough that at least some will be willing to pay you more to guarantee that it'll be there when they really want it.

+10 We've forgotten the Committed Information Rate already? Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Jared Mauch" <jared@puck.nether.net>

While fiber installation can be expensive, one needs to ask the local municipalities to install extra conduit every time the earth is broken for a local project.

You will perhaps recall that I put NANOG through teaching me that exact thing last Summer. :-) But Phil was talking about Wireline caps, unless I misunderstood him. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

On Dec 5, 2013, at 16:35 , Phil Karn <karn@philkarn.net> wrote:

On 12/05/2013 02:00 PM, Owen DeLong wrote:

...

If AT&T has capped me, then, I haven’t managed to hit the cap as yet. Admittedly, the connection isn’t always as reliable as $CABLECO, but when it works, it tends to work at full speed and it does work the vast majority of the time.

AT&T threatened to cap U-verse at 250 GB/mo several years ago, but they never seem to have followed through. It's probably about the only way that their incompetence is actually in the public interest.

Meh... U-verse isn't available here anyway. AT&T here is capped at 768kbps on wired. Wireless, I'm getting LTE 30-50Mbps from them.

Monthly caps -- and even peak speed limits -- are a very poor idea in general because they don't take system conditions into account. A torrent that runs at night penalizes you just as much as one run at prime time. Actually more, since you probably get greater throughput at off-peak times and therefore hit your cap faster.

On this, we agree.

If one *must* charge for usage on a shared network, the right thing is to base the monthly fee on *guaranteed* bandwidth because that's what actually drives costs. If more is available because others aren't using their guarantees, fine, you can have it for free. But it's not guaranteed. And you don't get a refund for not using your guarantee because the equipment still had to be allocated for you.

Unfortunately, most of the DSLAMs/GPON Concentrators/CMTS systems don't do a very good job of enabling CIR based provisioning and even if they did, for some reason, consumers seem to have a very hard time wrapping their heads around the CIR/Burst concept when money is involved.

Of course the real solution to nearly every problem with local broadband access is the same: meaningful competition. About the only way this could happen is for the municipality to install, own and maintain the fiber plant and lease it to any and all commercial service providers on a non-discriminatory and non-exclusive basis.

I couldn't agree more... I've been saying this for years. It's starting to actually happen in some places with reasonable success. However, the municipality doesn't necessarily have to install, own, and maintain it. All that really has to happen is regulations that prohibit those that own/provide Layer 1 infrastructure from playing in higher layers of the stack and requiring them to provide service to ALL comers on equal footing.

Naturally this will never happen in the United States because the incumbents will scream "socialism!" at the top of their lungs and race to the state houses to outlaw it. Never mind that this is exactly how we've handled roads for centuries.

Yes, our roads are a great example of workable socialism, though what you have proposed is not. What you have proposed is not socialism, since it would be more like a toll road (toll roads which are 100% self-funding don't qualify because there is no tax involved, it is a business. The fact that the business happens to be run by a government agency (in some cases) doesn't really matter.) Nonetheless, you are right that the incumbents will do everything in their considerable power to hang on tightly to their existing monopolies. Unfortunately, so long as we preserve problems like the citizens united ruling, it will be difficult for the people to overcome these problems. Owen

On 04/12/13 23:48, Owen DeLong wrote:

Please tell me what provider is selling 100Mbit for $20-30 in the 408-532-xxxx area of San Jose, California.

Currently, the only provider capable of delivering more than 768k wired here is charging me $100+/month for 30-50Mbps maximum.

I could get 100Mbps from them, but they want $250+/month for that.

If I can get 100Mbps for $20-30, I'd jump at it.

I know this is nanog, but i was talking about Russia, sorry for confusion. You can get 350Mbps for 70$ via GPON here. but plain ethernet dominates mostly here

Not entirely sure what you are saying here. In this day and age, I don't see any reason that wireless providers should get a free pass or be able to sustain significantly worse policies than wireline providers. Wireless bandwidth is rapidly approaching parity with wired bandwidth pricing at consumer levels.

Sure but most cases you hit tower limit or frequency to crowded, since its shared medium and you can't do anything about that. In wired you can just drop another cable to your new client.

...

Some even come up with idea two separate /64 make things easier :-D, instead just put at least round /60

Actually, providing a separate /64 for the provider link makes a lot of sense. It really is best to pull that out of a separate provider aggregate across all the subscribers in the same aggregation group than to carve individual link prefixes out of each subscribers internal-use prefix.

For example, if you get a tunnel from HE, then, by default, you get a /64 from our link block for the tunnel broker to which you connect and an additional /64 for your internal use by default. If you click the "please give me a /48" checkbox, then you'll also get an additional /48.

I was talking about /64 + /64 to client LANs and not counting another /64 for WAN interface. I find this hard to manage at least on Cisco, actually didn't find way to separate them at all, unless its make them static

We do this because it makes our provisioning easier and allows us to support users that want prefixes as well as users whose equipment (or brains) can't handle more than a single /64 for their LAN.

There's really NOTHING to be gained from providing anything in between a /64 and a /48, so we don't do it.

Owen

Zach, I've had no issues here since launching ipv6 other than that the performance isn't amazing. Andrew On 1/8/2014 7:29 PM, Zach Hanna wrote:

OK. So who other than Andrew was able to get this working (and keep it working) ? I'm about to place an order for slow-verse for my residence...

-Z-

On Mon, Dec 9, 2013 at 12:20 AM, Nikolay Shopik <shopik@inblock.ru> wrote:

...

On 04/12/13 23:48, Owen DeLong wrote:

...

Please tell me what provider is selling 100Mbit for $20-30 in the 408-532-xxxx area of San Jose, California.

Currently, the only provider capable of delivering more than 768k wired here is charging me $100+/month for 30-50Mbps maximum.

I could get 100Mbps from them, but they want $250+/month for that.

If I can get 100Mbps for $20-30, I'd jump at it. I know this is nanog, but i was talking about Russia, sorry for confusion. You can get 350Mbps for 70$ via GPON here. but plain ethernet dominates mostly here

...

Not entirely sure what you are saying here. In this day and age, I don't see any reason that wireless providers should get a free pass or be able to sustain significantly worse policies than wireline providers. Wireless bandwidth is rapidly approaching parity with wired bandwidth pricing at consumer levels.

Sure but most cases you hit tower limit or frequency to crowded, since its shared medium and you can't do anything about that. In wired you can just drop another cable to your new client.

...

...

Some even come up with idea two separate /64 make things easier :-D, instead just put at least round /60 Actually, providing a separate /64 for the provider link makes a lot of sense. It really is best to pull that out of a separate provider aggregate across all the subscribers in the same aggregation group than to carve individual link prefixes out of each subscribers internal-use prefix.

For example, if you get a tunnel from HE, then, by default, you get a /64 from our link block for the tunnel broker to which you connect and an additional /64 for your internal use by default. If you click the "please give me a /48" checkbox, then you'll also get an additional /48. I was talking about /64 + /64 to client LANs and not counting another /64 for WAN interface. I find this hard to manage at least on Cisco, actually didn't find way to separate them at all, unless its make them static

...

We do this because it makes our provisioning easier and allows us to support users that want prefixes as well as users whose equipment (or brains) can't handle more than a single /64 for their LAN.

There's really NOTHING to be gained from providing anything in between a /64 and a /48, so we don't do it.

Owen

On Mon, 02 Dec 2013 17:59:51 -0500, Mark Andrews <marka@isc.org> wrote:

... A simple RA/DHCP option could do this.

Great. Now I have to go upgrade every g** d*** device in the network to support yet another alteration to the standards.

For the few residential ISP's that do this what is it? $5 / month per IP and how many ask for a second address? 1 in 10000, 1 in recover the setup costs.

It varies. Bellsouth DSL, it was $15(?) for /32 (it was included in mine) Uverse is $15 for /29. TWC-BC $29(?) for /29. (twc-res doesn't offer it) It turns out to be a mark-up of over 200x their annual cost (and they charge that per month) -- so it's a significant income stream. (how many people are buying, they aren't saying.)

Go ask the bean counters about the cost of having different sized customers. Those costs will dwarf the income from charging for bigger address space. For IPv4 there wasn't a choice. For IPv6 there is the choice of one size for all vs the additional cost of managing different sized customers.

As one who has dealt with such accounting and billing systems, it's actually not that much work. (unless the system pre-dates the internet.) And even more so if the system was designed from the beginning to support it. (as this was already there for IPv4, it should've been included in any additions for IPv6 support.) I doubt we're going to see anyone from the big boys popping up to admit having setup their systems to support micro-allocation billing, but it's a safe bet they have, or they're working on it.

In message <op.w7hpn2m5tfhldh@rbeam.xactional.com>, "Ricky Beam" writes:

On Mon, 02 Dec 2013 17:59:51 -0500, Mark Andrews <marka@isc.org> wrote:

...

... A simple RA/DHCP option could do this.

Great. Now I have to go upgrade every g** d*** device in the network to support yet another alteration to the standards.

Guess what, networks evolve and have been evolving for as long as I've been involved which is around 30 years now. There is no reason to expect that they won't stop evolving for the forseeable future.

...

For the few residential ISP's that do this what is it? $5 / month per IP and how many ask for a second address? 1 in 10000, 1 in recover the setup costs.

It varies. Bellsouth DSL, it was $15(?) for /32 (it was included in mine) Uverse is $15 for /29. TWC-BC $29(?) for /29. (twc-res doesn't offer it)

It turns out to be a mark-up of over 200x their annual cost (and they charge that per month) -- so it's a significant income stream. (how many people are buying, they aren't saying.)

So you have no idea if it is a significant income stream or not.

...

Go ask the bean counters about the cost of having different sized customers. Those costs will dwarf the income from charging for bigger address space. For IPv4 there wasn't a choice. For IPv6 there is the choice of one size for all vs the additional cost of managing different sized customers.

As one who has dealt with such accounting and billing systems, it's actually not that much work. (unless the system pre-dates the internet.) And even more so if the system was designed from the beginning to support it. (as this was already there for IPv4, it should've been included in any additions for IPv6 support.) I doubt we're going to see anyone from the big boys popping up to admit having setup their systems to support micro-allocation billing, but it's a safe bet they have, or they're working on it.

Except it is not just the accounting and billing systems. Additionally when you factor in everyone is getting multiple GUA by default the number of customers that need to pay for additional addresses drops by orders of magnitude it doesn't remain cost effective to charge for address space. If you are being charged anything to get a /48 over a /56 or a /60 you are being ripped off. If you can't get a /48 you are being ripped off. The public will learn this as will the regulators that protect customers. There actually is a IPv4 address shortage. There isn't a IPv6 address shortage. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Mon, 02 Dec 2013 20:07:40 -0500, Owen DeLong <owen@delong.com> wrote:

Whenever they split or combine a CMTS or head-end...

Shouldn't matter unless they're moving things across DHCP servers. (which is likely from what I've heard about TWC, and seen from my own modems. In fact, the addresses in my office changed last week; we aren't paying for statics.)

I actually tend to doubt it. All of the people I've talked to from the major operators have said that the charges in IPv4 were not a revenue source, they were an effort to discourage the consumption of the addresses and/or the use of static addresses and to try and recover the costs of dealing with them in cases where customers were willing to pay.

Yeah, we all say that. *grin* But I went and looked at the numbers... it was several times my yearly salary, per month @ a business ISP. I would assume with residential, people are more cost sensitive and won't pay for address space they won't use. (but I know first hand that's not entirely true.)

On Dec 2, 2013, at 4:35 PM, Ricky Beam <jfbeam@gmail.com> wrote:

DHCPv6-PD isn't a "restriction", it's simply what gets handed out today. A "simple" reconfiguration on the DHCP server and it's handing out /56's instead. (or *allowing* /56's if requested -- it's better to let the customer ask for what they need/want; assuming they just default to asking for the largest block they're allowed and using only 3 networks.)

I find it amusing that people want to argue both that: - A /56 is horribly wrong and the world will end if we don't fix it NOW. - Providers could give out more by simply changing a setting on the DHCP server. I would love to know what number of home users need 256 subnets. The good news is that folks doing DHCP-PD will be able to report on how many people request all 256 networks available, and are thus "out". In fact they can make a histogram from 1 to 256 networks per household, and show us how many request each number of subnets. I challenge Comcast, AT&T, and others to do just that, and publish it on a regular basis, if only to make people stop talking about this "issue". -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs@seastrom.com> wrote:

...

So there really is no excuse on AT&T's part for the /60s on uverse 6rd...

Except for a) greed ("we can *sell* larger slices") and b) demonstrable user want/need.

How many residential, "home networks", have you seen with more than one subnet? The typical household (esp Uverse) doesn't even customize the provided router. Even a CCIE friend of mine has made ZERO changes to his RG -- AT&T turned off WiFi and added the static block at install. (I know NANOG is bad sample as we're all professionals and setup all kinds of weird configurations at "home". I have 3 nets in continuous use... a legacy

subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping that network (because it's too small), and a second RFC1918 net from a second ISP)

I wouldn't use the word "generous", but a /60 (16 "LAN"s) is way more than what 99% of residential deployments will need for many years. We've gotten by with a single, randomly changing, dynamic IP for decades. Until routers come out-of-the-box setup for a dozen networks, non-networking pros aren't going to need it, or even know that it's possible. (and the default firewalling policy in Windows is going to confuse a lot of people when machines start landing in different subnets can "see" each other.)

Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to the power of huge, but it's still finite. People like you are repeating the same mistakes from

Ricky Beam wrote: public the early

days of IPv4... the difference is, we won't be around when people are cursing us for the way we mismanaged early allocations. Indeed, a /64 is too little (aka "bare minimum") and far too restrictive, but it works for most simple (default) setups today. Which leads to DHCPv6 PD... a /60 is adequate -- it's the minimal space for the rare cases where multiple nets are desirable or necessary. The option for /56 or even /48 should exist (esp. for "business"), but the need for such large address spaces are an EXCEPTION in residential settings. (and those are probably non-residential users anyway.) [FWIW, HE.net does what they do as marketing. And it works, btw.]

The rant above represents a braindead short-sighted thought process. If you focus on the past as justification for current actions, you guarantee that the future will always look exactly like the past. If you even hint at a /64 as the standard for residential deployment, you will find that all the CPE vendors will hard code that, and you will never get it undone when you change your mind. All because you stated up front that they will only ever need what they have been using in the past. You don't see multi-subnet residential today from the consumer viewpoint, but they do widely exist supporting deployment of "watch your dvr from any set-top", where a premise subnet handles that traffic off of the consumer lan. That one example is why there should NEVER be a /64, because you are already at 2 subnets that should be using the same shorter prefix. Trying to develop the automation necessary for consumer plug-n-play subnets shows that even a /56 is virtually unusable. A /55 makes more sense for a topology with moderate constraints, but if you are already shorter than a 56, it doesn't make sense to stop there. This is a hard concept for "professional network engineers", because their market place value is based on the ability to efficiently manage topologies to fit within address resource constraints. Consumers have no desire to understand the technology, they just want to plug stuff together and have it sort out what it needs to do. That unconstrained topology coupled with unmanaged device automation requires excess address resource. YES THAT IS A WASTE. But having the address space sitting on the shelf at IANA when someone comes along with a better idea in the next few hundred years is also a waste. Get over it, the address space excessively larger than we will ever deploy so it is wasted ... The only open issue is how we utilize the resource until the next thing comes along. If it sits on the shelf, you constrain innovation. If you 'waste it' by deploying it before people can really use it, you piss-off the existing engineering staff. From my perspective, the latter will die off, but stifling innovation robs future generations of capabilities they could/should have had to make the world a better place. Tony

On Mon, 02 Dec 2013 17:14:38 -0500, Tony Hain <alh-ietf@tndh.net> wrote:

If you even hint at a /64 as the standard for residential deployment,

I never said that should be the standard. The way most systems do it today, you get a /64 without doing anything. If that's all you need, then you're done. If you want more networks, you ask for them via DHCPv6, and you can ask for prefix size you need (you may not get it, 'tho.) Currently, ISPs are defaulting to /60 as that's fair compromise for current networking. It's an easy limit to change, if they're willing to do it.

Trying to develop the automation necessary for consumer plug-n-play subnets shows that even a /56 is virtually unusable...

I'm the insane one for saying a single /64 and a /60 are perfectly workable today, but every damned device in the home getting it's very own /64 is *NECESSARY*??? If that's your only answer to home automation, then you should quit now, and leave the solar system. Multiple networks REQUIRE a working understanding of networking; we have yet to escape that. I get how people want to make networking as dumb and simple as possible. However, giving an entire /64 LAN to a single device for a single purpose is certifiably insane. If a 2^64 address LAN cannot hold all of the devices in your house, there's something very wrong here. :-) I do understand the desire, and even need, for system isolation, but a LAN-per-device is beyond insane. Also, until 20$ switches become infinitely more intelligent, the typical home network is a flat network. (with a "maybe" on isolation between wired and wireless) The only logical reason for multiple /64 LANs is multiple, isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4 port router), beyond physical ports are VLANs and thus switches that can handle VLANs, and something has to configure all that.

On Mon, Dec 2, 2013 at 11:47 PM, Owen DeLong <owen@delong.com> wrote: ....

(Hint, NEST has already released an IPv4 smoke detector).

And they really should have enabled IPv6 on it :-( But the processor should be able to handle it, if they update the firmware. I hear Tado does IPv6.

In message <op.w7hmnqvjtfhldh@rbeam.xactional.com>, "Ricky Beam" writes:

On Mon, 02 Dec 2013 17:14:38 -0500, Tony Hain <alh-ietf@tndh.net> wrote:

...

If you even hint at a /64 as the standard for residential deployment,

I never said that should be the standard. The way most systems do it today, you get a /64 without doing anything. If that's all you need, then you're done. If you want more networks, you ask for them via DHCPv6, and you can ask for prefix size you need (you may not get it, 'tho.) Currently, ISPs are defaulting to /60 as that's fair compromise for current networking. It's an easy limit to change, if they're willing to do it.

No, it is not a fair limit.

...

Trying to develop the automation necessary for consumer plug-n-play subnets shows that even a /56 is virtually unusable...

I'm the insane one for saying a single /64 and a /60 are perfectly workable today, but every damned device in the home getting it's very own /64 is *NECESSARY*??? If that's your only answer to home automation, then you should quit now, and leave the solar system.

Multiple networks REQUIRE a working understanding of networking; we have yet to escape that. I get how people want to make networking as dumb and simple as possible. However, giving an entire /64 LAN to a single device for a single purpose is certifiably insane. If a 2^64 address LAN cannot hold all of the devices in your house, there's something very wrong here. :-) I do understand the desire, and even need, for system isolation, but a LAN-per-device is beyond insane.

So you go from one extreme to another. One lan to one lan-per-device.

Also, until 20$ switches become infinitely more intelligent, the typical home network is a flat network. (with a "maybe" on isolation between wired and wireless) The only logical reason for multiple /64 LANs is multiple, isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4 port router), beyond physical ports are VLANs and thus switches that can handle VLANs, and something has to configure all that.

Each of which needs a /64. 16 subnets is incredibly small. It is stifling for developers. PD can do on demand assignment as long as the ISP provides enough space for it. This doesn't have to be heirachically assigned. 65000 x (2 or 3) routes in a home CPE is managable without user intervention. These all get aggregated at the border router. You just build in the assignment algorithms ISP's use today to break up address blocks when you are assigning space customers to allow for customers (down stream devices) to grow the space they need on demand into the CPE devices. This works well enough in reducing internal routes. The only thing stifling this is ISP's being measly with how they hand out address blocks. If ISPs all hand out /60's this sort of development just won't happen and it will be entirely the ISP's fault for being so short sighted. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Dec 2, 2013, at 17:20 , Ricky Beam <jfbeam@gmail.com> wrote:

On Mon, 02 Dec 2013 19:16:27 -0500, Mark Andrews <marka@isc.org> wrote:

...

So you go from one extreme to another. One lan to one lan-per-device.

No. I'm complaning about how the automatic solution to segmenting the home ("homenet") doesn't put any thought into it at all, and puts everything in it's own network. I cannot believe anyone would ever put that on paper, but they did.

That isn't how I read any of the drafts that I've seen, so I'm not sure where you get this.

Anyway. If you want your home segmented, then a human being needs to take a few minutes to think about it and then configure the network (physical and logical) and devices accordingly. That's a very complex problem to solve via AutoMagic Technology(TM) (hence the homenet approach.)

Nope... You plug in the top level router, then start plugging stuff into it. Switches, other nodes, other routers. In the case of other routers, then you plug stuff into them. Lather, rinse, repeat. Wherever you have a router, you have a boundary between links. Simple as that. It's actually not complex for technology to figure out a hierarchy of routers and allocate prefixes to them, but it doesn't work out very well if you only have a few bits to play with and have to dense-pack the allocations. It basically boils down to spanning tree on steroids if you have a wide enough bit field to handle the breadth and depth of the hierarchy.

...

...

isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4

Each of which needs a /64. 16 subnets is incredibly small.

In this example, it takes 6. Six. 16 is almost 3x that, and thus, plenty big enough.

Depends on how they are connected and how you want the automation to work. Do you want room to grow at the various levels of the hierarchy? What happens when someone plugs a new router in between LAN2 and LAN3 that also connects LANS 5, 6, 7, and 8?

As we're getting our prefex via DHCPv6-PD, it's not hard to ask for a larger prefix when needed. (of course, every idiot is going to ask for the largest prefix possible, and then only use 3 /64's)

So what? If the largest prefix possible is a /48, then every idiot has more than enough space to do what they need and there's no harm to the ISP or anyone else. Sounds like an ideal solution to me.

...

The only thing stifling this is ISP's being measly with how they hand out address blocks. If ISPs all hand out /60's this sort of development just won't happen and it will be entirely the ISP's fault for being so short sighted.

They could be do much worse... if you throw out SLAAC, your network(s) can be smaller than /64. I don't want to give them any ideas, but Uverse could use their monopoly on routers to make your lan a DHCP only /120.

I think if they did that, they'd do more to evaporate Uverse customers than to change the world of IPv6 routing at this point. Owen

On Dec 2, 2013, at 18:20 , Ricky Beam <jfbeam@gmail.com> wrote:

On Mon, 02 Dec 2013 20:27:36 -0500, Owen DeLong <owen@delong.com> wrote:

...

...

They could be do much worse... if you throw out SLAAC, your network(s) can be smaller than /64. I don't want to give them any ideas, but Uverse could use their monopoly on routers to make your lan a DHCP only /120.

I think if they did that, they'd do more to evaporate Uverse customers than to change the world of IPv6 routing at this point.

I'd like to see the results of such an experiment. I suspect 90% of their users wouldn't even notice. (given how many don't even realize IPv6 is on, until some site(s) run dog slow until they're told (how) to turn IPv6 off.)

Not counting MAC users, because they cannot do DHCPv6 without 3rd party software.

My Macs seem to do DHCPv6 just fine here without third party software, so I'm not sure what you are talking about.

Nobody really cared with they limited what RFC1918 space you could use. (not sure they're still doing that.)

Not sure what you mean here since RFC-1918 is IPv4 only. Owen

On Dec 2, 2013, at 19:34 , Ricky Beam <jfbeam@gmail.com> wrote:

On Mon, 02 Dec 2013 22:03:59 -0500, Owen DeLong <owen@delong.com> wrote:

...

...

Not counting MAC users, because they cannot do DHCPv6 without 3rd party software.

My Macs seem to do DHCPv6 just fine here without third party software, so I'm not sure what you are talking about.

I've heard many reports of apple not supporting DHCPv6 up to 10.7. After much digging, I have found a single report of it working in 10.8. So, if you're up-to-date, you wouldn't notice it either. :-)

It worked in some later versions of 10.7, all versions of 10.8 and still works in 10.9. Given that 10.7 is fairly ancient at this point, I really don't think you have to be all that up to date to have it work. Given that 10.9 is a 100% free upgrade for anyone with a Mac and that nobody has reported any major problems with it that I know of, I would think that the number of people holding back from upgrading, especially if the need IPv6, would be relatively low.

...

...

Nobody really cared with they limited what RFC1918 space you could use. (not sure they're still doing that.)

Not sure what you mean here since RFC-1918 is IPv4 only.

Just providing an example of AT&T Uverse lunacy that hasn't resulted in millions of customers leaving. If you want an IPv6 example, their recent 2wire firmware update that broke proto-41 tunnels has met with an equally fervent "gee-whiz, att" response.

Actually I know several people that cancelled their UVerse subscriptions when ATT broke protocol 41. There are also some FCC complaints that have been lodged if what people are telling me is true. Owen

Two major versions back, is fairly ancient in internet years, yes. Owen On Dec 2, 2013, at 19:58 , david raistrick <drais@icantclick.org> wrote:

On Mon, 2 Dec 2013, Owen DeLong wrote:

...

Given that 10.7 is fairly ancient at this point

I know, right? 2.5 years old is -ancient-

. o O ( sigh )

-- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/

On Dec 2, 2013, at 20:11 , Rob Seastrom <rs@seastrom.com> wrote:

"Ricky Beam" <jfbeam@gmail.com> writes:

...

...

So there really is no excuse on AT&T's part for the /60s on uverse 6rd... ... Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to

On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs@seastrom.com> wrote: the power of huge, but it's still finite. People like you are repeating the same mistakes from the early days of IPv4...

There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste.

Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy).

Now give such a phone to every human on the face of the earth.

Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time.

Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware.

What percentage of the total available IPv6 space have we burned through in this scenario? Show your work.

-r

Quick napkin version: 6.8 Billion people * 10 = 68Billion /48s. 32 bits = 4 billion (we all know that from IPv4, right?) A /16 is 4 Billion /48s. A /15 is 8 Billion A /14 is 16 Billion A /13 is 32 Billion A /12 is 64 Billion A /11 leaves room to spare at more than 128 Billion /48s. So, we need 2 /12s. We have already issued RIRs 6 /12s (as of 3Q2013), leaving 506 /13s in 2000::/3 We could easily issue the global total need of 2 /12s (a /11) to each RIR (there are 5), so total of 10 in addition to what has already been issued, and we'd have issued a total of 16 /12s leaving 494 /12s in inventory in 2000::/3. For convenience, I will remind everyone that 2000::/2 represents 1/8th of the total address space. Further, for those that are worried about population explosions causing this not to scale, even if the population on the planet expanded by an order of magnitude so that we had to issue 100 /12s, w would still have 406 /12s remaining in 2000::/3. Owen

On Dec 3, 2013, at 12:04 AM, Eric Oosting <eric.oosting@gmail.com> wrote:

On Mon, Dec 2, 2013 at 11:11 PM, Rob Seastrom <rs@seastrom.com> wrote:

...

"Ricky Beam" <jfbeam@gmail.com> writes:

...

...

So there really is no excuse on AT&T's part for the /60s on uverse 6rd... ... Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to

On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs@seastrom.com> wrote: the power of huge, but it's still finite. People like you are repeating the same mistakes from the early days of IPv4...

There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste.

I know this is rhetorical, but my hobby is answering peoples rhetorical questions.

...

Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy).

Very well, I'll play your silly game.

48 bits remaining.

...

Now give such a phone to every human on the face of the earth.

33 bits should do it. That gets us to nearly 9 billion people.

15 bits remaining.

...

Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time.

5 is inconvenient. Lets give everyone 8 mobil phones, using 3 bits.

12 bits remaining.

...

Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware.

1 bit for that.

11 bits remaining.

Now we're assigning space out of 2000::/3 for now ... lets keep the other 7/8ths of the ipv6 address block in reserve, using another 3 bits ... leaving ... carry the one ... 8 bits.

...

What percentage of the total available IPv6 space have we burned through in this scenario? Show your work.

If we give every man, woman, and child on the face of the earth the equivalent to (16) /48s each, we'll will have used 1/256th of the first 1/8th of the IPv6 address space.

Wolfram says there have been 110 billion homo sapiens that have ever lived. We need to give every person who has literally ever lived on planet earth their own /40 before we've used up 2000::/3, and need to move on to the remaining 87.5% of the address space. (this is where someone will ding me for the misuse of "literally" somehow with a pointer to theoatmeal comic, right)

-e

...

-r

Does this mean we can all get back to solving real IPv6 deployment and operations problems? I certainly hope you all can finally see which is the better business choice between: 1. Using up to around 10% of IPv6 space to make our network operations simpler for the next twenty years or more. 2. Continuing to spend time and money on micromanagement of addressing rather than real customer needs. One who cannot properly understand the business decision here perhaps should not be debating network policies. — “Strongly worded letter to follow." James R. Cutler james.cutler@consultant.com

On 2-12-2013 22:25, Ricky Beam wrote:

On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs@seastrom.com> wrote:

Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks

You clearly have no understanding of route aggregation which just made it's entry into the soho. The router will set up it's own DHCP-PD prefix delegation for downstream routers. Without a /56 or larger it is very hard to do automatically. It is not "wasting" it is "required" for proper operation of a routing internet. You can't just NAT a downstream router and still have IPv6. People buy extra wifi routers at their favorite shop and *will* plug the cable into the "Internet" port. With IPv6 and DHCP-PD they will still get working IPv6 internet. Great! Cheers, Seth

In message <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>, Mikael Abrahamsson writes:

On Fri, 29 Nov 2013, Mark Andrews wrote:

...

You can hand out /48 as easily with 6rd as you can natively.

It's only when the ISP is lazy and encodes the entire IPv4 address space into 6rd thereby wasting most of the IPv6 address space being used for 6rd that a /60 appears to be generous.

You're contradicting yourself here.

What contradiction? You need to break up the IPv6 address allocation for both PD and 6rd. I would say PD is slightly more complicated than 6rd as you also want to optimise routing more with PD. With 6rd you do the optimisation using the IPv4 addresses.

Yes, you're right about the technical solution, but it's not as easy (you need backend systems). Also, not all products support the variability of subnet lengths that the standard allows.

So who is shipping cr*p that claims to support RFC 5969 yet doesn't all arbitary size 6rd domains? The point of have a standard is so equipement from different manufactures can work together. A CPE device that can't accept all legal values should be thrown in the bin.

So if you're not mapping the entire space (actually some products only allow /32 IPv6 space) 1-1 you're making the whole solution harder due to complexity in your backend system plus you're limiting the amount of customer gear that will support the solution.

I claim bovine excrement on customer gear. Show me where the 6rdPrefixLen is defined to be 32? Even with RFC 5569 it was up to 32 and the IPv4MaskLen is 0.

-- Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

De : Mikael Abrahamsson <swmike@swm.pp.se> A : Mark Andrews <marka@isc.org>,

...

...

...

You can hand out /48 as easily with 6rd as you can natively.

"As easily". It's easier to either hand out /64 by means of 1:1 mapping IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than

to get into the whole backend mess of having multiple 6RD domains with multiple configs per IPv4 subnet etc.

I agree with you theoretically, but in practice I disagree.

Some hard data points here, coming from one of the rare operator who actually deployed 6RD sub-domains to all its customers (to my knowledge). In practice, most 6RD implementations that support option 212 do support IPv4MaskLen properly these days. It wasn't the case 3 years ago, but we worked a lot with vendors to make it right. Seems ok now, we mostly have a 6RD population of D-Link and Cisco/Linksys. On the backend side, it's really not that bad. A one-page TCL handles around 15-16 sub-domains for us without noticeable impact on the DHCP servers CPU. Configuring the relays with all the tunnels can be a bit of fun playing with hex maths, but it's not too bad either. So I agree with Mark, it's not that complex. I can't agree with him on the prefix size though. We hand out /60s because we feel it's enough from a transition point of view (these are short-lived anyway) and offering a bigger size would really use too much space. Offering /48s out of a single /16 block, to take a simple example, would use a whole /32. This space wouldn't be used much anyway, given that most 6RD routers use only one /64, sometimes two. I argue that a /60 is actually the best compromise here, from a space and usage point of view. /JF Videotron, AS5769

Jean-Francois.TremblayING@videotron.com writes:

Offering /48s out of a single /16 block, to take a simple example, would use a whole /32.

Sounds as if your organization can justify more than the /32 "minimum/default" allocation of IPv6 then (I'd imagine you have more than a minimum-assignment /22 of IPv4 space based on my interactions with Videotron back circa 2004 too). Have you tried asking for more IPv6 space, backed up with your network architecture documents?

This space wouldn't be used much anyway, given that most 6RD routers use only one /64, sometimes two. I argue that a /60 is actually the best compromise here, from a space and usage point of view.

IPv4-thinking. In the fullness of time this line of reasoning will be greeted with the same wry grin and eyeroll that the NANOG community today reserves for academics who teach their students "classful networking". -r

Jean-Francois.TremblayING@videotron.com writes:

...

IPv4-thinking.  In the fullness of time this line of reasoning [...]

Hopefully, the fullness of time won't apply to 6RD (this is what was being discussed here, not dual-stack).

I agree but there's a subtlety here - we don't want to get people used to parsimony in IPv6-land via chintzing out on deployments with a transition technology. There are dinosaurs in every organization who cling to the "monetizing addresses/subnets" model and will want to charge more for a /48 or a /56 and point to the market being used to a /60 or a /64, and it becomes the unfortunate task for folks like us to argue against that line of thinking. We've got a little over two decades worth of IPv4 penny-pinching to undo here, and the interim deployments ought to help that to the degree possible.

Most MSOs are planning /56s for native. ARIN 2011-3 is great, but it came a bit late (January 2012) for those who already had planned their network.

Yep, we're planning /56es for native at $DAYJOB too. Worse than /48s, not as bad as /64s or /60s. Not that ARIN policies constrain this at all; it was certainly possible before 2011-3 to get more than a /32 of space, it just wasn't as easy (certainly there was more than one org that managed to do it). As for the 6rd part, there was no 2010-12 6rd policy before December 2010... then again, before August 2010 there was no 6rd. :) I'm unfortunately quite familiar with the internal costs of a do-over in a large organization. -r

On Nov 28, 2013, at 1:07 PM, Leo Vegoda <leo.vegoda@icann.org> wrote:

Andrew D Kirch wrote:

Was I the only one who thought that everything about this was great apart from this comment:

...

In reality additional poking leads me to believe AT&T gives you a rather generous /60

Is a /60 what is considered generous these days? I thought a /48 was considered normal and a /56 was considered a bit tight. What prefix lengths are residential access providers handing out by default these days?

Regards,

Leo

Agreed… Unforutnately, the big guys (Comcast, AT&T) in America seem to like victimizing their customers with undersized assignments, limiting choice of proper prefix sizes to only their business class customers. I’m not sure why they are doing this. I know when I’ve had conversations with them, they haven’t exactly given a reason so much as just said that they thought a /48 was ridiculous. Of course, if AT&T is blocking protocol 41, that’s even worse, because at least so long as that isn’t blocked, you can still get an HE tunnel and get a /48 if you need it anyway. Owen

On Thu, Nov 28, 2013 at 9:07 PM, Leo Vegoda <leo.vegoda@icann.org> wrote: ....

Is a /60 what is considered generous these days?

I do not think so. I think that is more minimal than generous.

I thought a /48 was considered normal and a /56 was considered a bit tight. What prefix lengths are residential access providers handing out by default these days?

A /60 appears (by reports from AT&T and Comcast customers) seems to be the current behavior for some residential access providers. I am sure one can find counter examples. And while I can rationalize the thinking (I suspect few home users currently use more than 16 internal networks), with solutions that will eventually depend on further prefix sub-delegation downstream (aka HIPNet), /60 feels a bit tight. I would certainly feel more comfortable seeing the providers start offering at least a /56, if not a /48, if requested by the customer. It is conceivable that the residential providers intend to offer more than a /60 at additional costs (as they offer more than one IPv4 address today), or to offer more than a /60 only to those that request it (to minimize some perceived "waste" of IPv6 numbers). I would expect that "Business" customers will almost certainly see different offerings (/48s?). It is also conceivable that the residential providers have not (yet) thought it all through. Gary