On 1/6/2011 4:47 PM, Grant Phillips wrote:

I acknowledge and see the point made. There is a lot of dead space in the IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more to no.

Have you read this RFC? This is pretty satisfying in making me feel more comfortable assigning out /48 and /64's. I can sleep at night now! :P

http://tools.ietf.org/html//rfc3177

I can't tell if you're trolling, or if you didn't get the memo from Monday. I guess I'll lean toward the latter. http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html Jima

On 1/7/2011 12:11 AM, Owen DeLong wrote:

That's a draft, and, it doesn't really eliminate the idea that /48s are generally a good thing so much as it recognizes that there might be SOME circumstances in which they are either not necessary or insufficient.

As a draft, it hasn't been through the full process and shouldn't be considered to have the same weight as an RFC.

While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may never do so.

Fully understood; I wasn't meaning to present it as irrefutable evidence that the /64 & /48 mindset is flawed, but as a timely counterpoint to people expounding the virtues of 3177 without cautiously acknowledging that its recommendations aren't necessarily for everyone. I apologize if my intentions weren't terribly clear -- that may be a good cue for me to go to bed. Jima

On 7 Jan 2011, at 06:11, Owen DeLong wrote:

That's a draft, and, it doesn't really eliminate the idea that /48s are generally a good thing so much as it recognizes that there might be SOME circumstances in which they are either not necessary or insufficient.

As a draft, it hasn't been through the full process and shouldn't be considered to have the same weight as an RFC.

While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may never do so.

The IETF data tracker shows draft-ietf-v6ops-3177bis-end-sites is under IESG review, with comments currently being made, see https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ which also notes the draft has strong support so is likely to be published soon. The document is only guidance regardless. Tim

On Fri, 7 Jan 2011, Deepak Jain wrote:

least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.)

This is exactly the reason to issue /48 or /56 to the end user. You give them plenty of space, and you then don't have to care anymore about what the user does with this space. You keep do LL only between CPE and PE, so you only need to keep 4 TCAM entries per customer (one for the /XX route, one for the LL adjacancy, one for the permit ACL to permit packets from the /XX, and one deny line. (I might be misunderstanding exactly what's needed here and a few TCAM entries more are needed, but you get the idea).

until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they

If I give them a /56 then it's zero administration for me for the forseeable future. Why on earth would I want to handle customer administration when I don't need to? -- Mikael Abrahamsson email: swmike@swm.pp.se

On Jan 7, 2011, at 12:29 PM, Deepak Jain wrote:

...

...

http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html

Jima

Just skimming through the draft:

1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices.

--- I never knew a site, by definition, has multiple subnets and devices.

A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.

I think this is the real point everyone is trying to get at. They want IP6 to be the end of NAT. Got it. There are now years of security dogma that says NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma went another way. This concept will take a long time to unwind. Somehow this is supposed to mesh with dynamic renumbering where we can move around between /48s without "too much burden" while wildly waving our hands at all the higher-level configs (DNS, Applications, firewalls, etc) that don't play nicely with automatic renumbering.

You say dogma, I say mythology. Stateful inspection provides security. NAT, by itself, does not. The reason people are confused about this is because overloaded NAT cannot occur without stateful inspection. Actually, DNS can be made to play relatively nicely with automatic renumbering and most client hosts don't need DNS entries anyway. Firewalls generally apply policy to network segments and not individual policies to migratory hosts. Yes, it might be nice if they could, but, that's a hard problem to solve in a secure fashion. Generally, nomadic or migratory hosts can usually accept the security policy for the network to which they are attached and augment it with their own host-based firewall/filter rules in any case. In such a case, the host-based rules can be written in terms of interfaces and directions without much regard to the renumbering of the host in question.

There is some convoluted discussion about how they wanted their /48 policy to somehow encourage residential ISPs to give their users more IP space in the base offering. I'm not sure why or what purpose an addressing policy should have to a business case. I see nothing motivating a residential ISP (especially one providing CPE equipment) to change their current deployment system one iota. And I'm pretty sure they are the ones MOST exposed to abuses of this address space by the least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.)

If you were an ISP, you wouldn't be one I would subscribe to. There are multiple purposes to /48s to residential end users. DHCP-PD allows a lot of future innovations not yet available. Imagine a house where the border router receives a /48 from the ISP and delegates /64s or /60s or whatever to other routers within the house. Each home entertainment cluster may be one group of networks with its own router. The appliance network(s) may have their own router(s). RFID tags on groceries may lead to a time when your home automation server can gather up data from your refrigerator, pantries, etc. and present the inventory on your mobile phone while you're at the grocery store. No more need to maintain a shopping list, just query the inventory from the store. These are just the things that could easily be done with the technology we already know about. Imagine what we might think of once we get more used to having prefix abundance.

Question - Whatever happened to the concept of a customer coming to their SP for more space? Why do we have to give them enough space for a decade of theoretical use when every week we could widen their subnet without causing any negative impact on them? No renumbering, etc. It's not considered a burden today, but under IP6 it is? Heck, since space is so plentiful, we can all set up gateways to do it automatically, but until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they aren't getting a mathematical representation, they are getting usable IP space, but that doesn't mean that if they hop out of bed in the middle of the night and decide to allocate 5,000,000 unique IPs the SP network should automatically accept it (based on today's current technology).

It is considered a burden today, but, it's a burden everyone accepts for the following reasons: 1. IPv4 is scarce, so, we recognize the need to conserve. 2. For the most part, people live behind a single address and expansion is done from RFC-1918 space where the average household sees said space as virtually limitless and they aren't coming back to their ISP. Think of giving a residence a /48 as the IPv6 equivalent of letting them use 10/8 without the additional headaches associated with NAT. 3. The rare occasion that does require another address, people swallow hard face the burden and do what they have to to get more space. Usually this involves paying an additional fee to the ISP. As an ISP, once you issue a /48 to a customer, what do you care how many of those addresses they actually use/allocate? What difference does it make to you whether they use 1, 50, 100, 10,000, 100,000, 500,000,000,000 or whatever? Why should you care? You have one route entry that forwards packets to their router. After that, it's up to them to have enough hardware to handle the ND tables, etc. that result. It doesn't affect your network. You just shovel all the packets to them and it's their problem from there.

BOGONS, IP hijacks and all the rest seem like the worse problem here and the whole point of putting training wheels on these roll outs. Instead, it seems we are systematically unwinding all the lessons learned from CIDR and going back to addresses being classful, interface links being massive space wasters and no one caring about addresses. That's fine, and probably an improvement, until the next round of attacks and then shortages occur. Once the schools start teaching RFC3177, the hardcoded apps are sure to follow.

If you give your customers /48s and nobody accepts routes that are more specific than /48, where does the BOGON problem come from here? This is a huge red herring and shows a lack of understanding of how IPv6 actually works. CIDR is inherent in IPv6. It just happens (mostly) in the left-most 48 bits, leaving the remaining 80 bits to be administered by the local site, usually as 16-bits for network and 64 bits for host, but, even that isn't written in stone for every site, it's just what works best. Owen

On Fri, Jan 7, 2011 at 3:44 PM, Owen DeLong <owen@delong.com> wrote: <snip>

There are multiple purposes to /48s to residential end users.

DHCP-PD allows a lot of future innovations not yet available.

       Imagine a house where the border router receives a /48        from the ISP and delegates /64s or /60s or whatever to        other routers within the house.

       Each home entertainment cluster may be one group of        networks with its own router.

       The appliance network(s) may have their own router(s).

       RFID tags on groceries may lead to a time when your        home automation server can gather up data from your        refrigerator, pantries, etc. and present the inventory        on your mobile phone while you're at the grocery store.        No more need to maintain a shopping list, just query        the inventory from the store.

These are just the things that could easily be done with the technology we already know about. Imagine what we might think of once we get more used to having prefix abundance. <snip>

Having more address space won't help most of these uses, and as for why, take a look at the proposed situation with for example home media serving/sharing systems by TiVo, Apple, etc. They all require that the units be within the same broadcast domain or that there be a configured bridge of some sort if they even allow that topology. They (actually rightfully) assume that the network topology is flat, single broadcast domain, and mroe and more use Multicast DNS (which I've seen called a bunch of different things) More to the point, your average home user can not technically fathom anything more complicated than "plug it in" -- and many begin to fail to set something up properly when its extended to something as complicated as "plug it in, push a button" or "plug it in, type some numbers into the device" Your average home user has no reason at all for anything more than a PtP to his/her gateway, and a single prefix routed to that gateway. There are most certainly a few (which includes I'm sure 99% of the NANOGers!) subscribers who can and will use more space than that, and ISPs most definitely should make /48s readily and easily available for those customers, but giving each and every customer a /48 (or really, even a pair of /64s, one for the PtP, one delegated) is almost certainly overkill. The devices won't use the extra space unless there's some automagic way of them communicating the desire to eachother, and appropriately configuring themselves, and it would have to be very widely accepted. But there's no technical gain. A typical household would probably have less than about 50, maybe 100 devices, even if we start networking appliances like toasters, hair dryers and every single radio, tv, and light switch. Just my 2 cents worth.

On 1/11/2011 1:05 PM, George Bonser wrote:

Many of us are looking at things from today's perspective. Maybe each room of my house will have its own subnet with a low power access point and I can find which room something is in by the IP address it has.

Today, there are several vendors who believe the wireless part of their cpe should be a different subnet than the ethernet. There are multiple cases of stacked routers in homes, which requires multiple DHCPv6-PD delegations, and the current philosophy is very wasteful (as DHCPv6 itself doesn't support variable sized requests, chained requesting, and other options which would make it efficient for a requesting router 3 routers away from the initial DHCPv6 server). Jack

On Jan 11, 2011, at 10:45 AM, Michael Loftis wrote:

On Fri, Jan 7, 2011 at 3:44 PM, Owen DeLong <owen@delong.com> wrote: <snip>

...

There are multiple purposes to /48s to residential end users.

DHCP-PD allows a lot of future innovations not yet available.

Imagine a house where the border router receives a /48 from the ISP and delegates /64s or /60s or whatever to other routers within the house.

Each home entertainment cluster may be one group of networks with its own router.

The appliance network(s) may have their own router(s).

RFID tags on groceries may lead to a time when your home automation server can gather up data from your refrigerator, pantries, etc. and present the inventory on your mobile phone while you're at the grocery store. No more need to maintain a shopping list, just query the inventory from the store.

These are just the things that could easily be done with the technology we already know about. Imagine what we might think of once we get more used to having prefix abundance. <snip>

Having more address space won't help most of these uses, and as for why, take a look at the proposed situation with for example home media

Yes, it will...

serving/sharing systems by TiVo, Apple, etc. They all require that the units be within the same broadcast domain or that there be a configured bridge of some sort if they even allow that topology. They

That is the current state of the art which is the direct result of the lack of address space and the lack of the features I am describing making this absolutely necessarily.

(actually rightfully) assume that the network topology is flat, single broadcast domain, and mroe and more use Multicast DNS (which I've seen

Yes, that assumption is valid today. Future technology can change that assumption in useful and meaningful ways.

called a bunch of different things) More to the point, your average home user can not technically fathom anything more complicated than "plug it in" -- and many begin to fail to set something up properly when its extended to something as complicated as "plug it in, push a button" or "plug it in, type some numbers into the device"

DHCP-PD will allow for hierarchical topology that is not more complicated than "plug it in". No button push, no typing something in. Literally plug it in.

Your average home user has no reason at all for anything more than a PtP to his/her gateway, and a single prefix routed to that gateway.

Correct. I'm just saying that prefix should be a /48 so that the gateway can work with the other gateways inside the house to designate the best topology within the house. Note, this is all automated. It doesn't require the end-user to actually do anything other than plug it in.

There are most certainly a few (which includes I'm sure 99% of the NANOGers!) subscribers who can and will use more space than that, and ISPs most definitely should make /48s readily and easily available for those customers, but giving each and every customer a /48 (or really, even a pair of /64s, one for the PtP, one delegated) is almost certainly overkill. The devices won't use the extra space unless

That is today only thinking. Toss out your IPv4 scarcity-based assumptions about what is possible. IPv6 does have new features and new capabilities that we are just beginning to consider.

there's some automagic way of them communicating the desire to eachother, and appropriately configuring themselves, and it would have to be very widely accepted. But there's no technical gain. A typical

It's called DHCPv6-PD and it already exists. That's the point!!

household would probably have less than about 50, maybe 100 devices, even if we start networking appliances like toasters, hair dryers and every single radio, tv, and light switch.

It's not about the number of devices. That's IPv4-think. It's about the number of segments. I see a world where each home-entertainment cluster would be a separate segment (today, few things use IP, but, future HE solutions will include Monitors, Amps, Blu-Ray players, and other Media gateways that ALL have ethernet ports for control and software update). The kitchen appliances would probably have their own segment. A refrigerator or pantry may have a front-end router that separates the household backbone from the network interfacing all the RFIDs contained within the device. I'm sure there are other examples where automated segmentation of the network can, does, and will make sense. We're just starting to explore this. The point is to have address delegation policies which don't interfere with this development.

Just my 2 cents worth.

I'll see your $0.02 and raise you $0.48 ;-) Owen

At 11:59 AM 1/12/2011, Jim postulated wrote:

On 01/11/2011 01:31 PM, Owen DeLong wrote:

...

It's not about the number of devices. That's IPv4-think. It's about the number of segments. I see a world where each home-entertainment cluster would be a separate segment (today, few things use IP, but, future HE solutions will include Monitors, Amps, Blu-Ray players, and other Media gateways that ALL have ethernet ports for control and software update).

Your future is now, Owen. I have four network devices at my primary television -- the TV itself, TiVo, PS3, and Wii (using the wired adapter). All told, I have seven networked home entertainment devices in my house, with another (Blu-Ray player) likely coming soon. I feel confident in saying that my use case isn't unusual these days.

While a lot of the scalability concerns are blown off as "not applying to typical consumers," we're quickly getting to the point where your average joe IS somewhat likely to have different classes of devices that might benefit from being on separate subnets.

Jima

I helped a friend setup his "home network" recently. He is using an old Linksys Router with no v6 support. I like to be conservative and only allocate what might be needed ... part of my "Defense in Depth" strategy to provide some layer of "security" with NAT (yes, I know - my security by obscurity is to use something from 172.16) and a limited amount of addresses to allocate (not to mention WPA2 - he had default no security when I first got there). Used to be a /29 would be sufficient for any home. But, before I knew it, he had a wireless printer, laptop, and 4 iPhones all needing the new wireless passphrase to connect, plus he was anticipating 2 more laptops (one each for his children - to whom 2 of the iPhones belonged), and addresses set aside for guests and the occasional business visitor (he works from home). I left him configured with a /28, and told him to call me if he anticipated more. As a side security note - we lost the laptop on the "new" secured network before I tracked down that it had automatically logged in to his neighbor's (also unprotected) network on reboot. Ted

On Jan 8, 2011, at 3:29 AM, Deepak Jain wrote:

There are now years of security dogma that says NAT is a good thing,

Actually, this isn't the case. There's some *security theater* dogma which makes totally unsupported claims about the supposed security benefits of NAT, but that's not quite the same thing. ;> NAT has no inherent security benefits whatsoever, and quite a few security drawbacks. ------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

On Jan 8, 2011, at 8:54 AM, William Herrin wrote:

I presume you don't intend us to conclude that a bastion host firewall provides no security benefit to the equipment it protects.

If it's protecting workstations, yes, it has some positive security value - but not due to NAT. If it's inappropriately placed in front of servers, where's there's no state to inspect and were the stateful nature of the device in and of itself forms a DoS vector, it has negative security value; i.e., it makes things far worse. ------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

On Sat, Jan 8, 2011 at 2:00 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:

If it's inappropriately placed in front of servers, where's there's no state to inspect and were the stateful nature of the device in and of itself forms a DoS vector, it has negative security value; i.e., it makes things far worse.

Roland, I'm missing something here. Why do you say there is zero state at the server, but the not at the client? (Because of all the servers TCP/UDP ports are well known perhaps?) Sam

Thanks Grant, I've already read this. :) I have no problem with enabling /64s for everyone/everything in the future, as the equipment capability increases, but right now there are real concerns about en masse deployment and the vulnerabilities we open our hardware to. Which is why I was talking about reserving the larger block, but only allowing folks to have as much space as they can manage successfully and with a similar risk profile as they have today. Obviously it doesn't take too many people leaving their networks wide to cause a problem for the rest of us. Best, Deepak From: Grant Phillips [mailto:grant.phillips@gwtp.id.au] Sent: Thursday, January 06, 2011 5:47 PM To: Deepak Jain Cc: NANOG list Subject: Re: IPv6 - real vs theoretical problems Hi Deepak, I acknowledge and see the point made. There is a lot of dead space in the IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more to no. Have you read this RFC? This is pretty satisfying in making me feel more comfortable assigning out /48 and /64's. I can sleep at night now! :P http://tools.ietf.org/html//rfc3177<http://tools.ietf.org/html/rfc3177> Cheers, Grant Phillips On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain <deepak@ai.net<mailto:deepak@ai.net>> wrote: Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge. My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? Thanks, DJ

Are there any large transit networks doing /64 on point-to-point networks to BGP customers? Who are they? What steps have they taken to eliminate problems, if any?

Our Global Crossing IPv6 transit is on a /64 Ethernet point-to-point. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

---------- Original Message ----------- From: Jeff Wheeler <jsw@inconcepts.biz> Sent: Thu, 6 Jan 2011 21:01:12 -0500

Are there any large transit networks doing /64 on point-to-point networks to BGP customers? Who are they?

Add HE.net to the list. -Randy www.fastserv.com