96 more bits... time for some magic after all?
All, [ gah... hit the wrong key and sent this unfinished ] We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7020: http://datatracker.ietf.org/doc/rfc7020/ This includes the long-standing historical goals of conservation, aggregation, and accuracy. Using bits in IPv6 networks for other purposes is orthogonal to those goals. What should we do about it? Cheers, -- Shane
On 10/25/13 12:37 PM, Shane Kerr wrote:
Using bits in IPv6 networks for other purposes is orthogonal to those goals.
What should we do about it?
Hey, As far as I know, the rule-of-thumb is to allocate /48 per customer. As long as they don't go beyond that, there's nothing to do :) We had a long chat with Peter Lothberg about that during one of the evenings and we calculated that with his addressing and /29 you could number the whole Germany. One provider. I see no need to change the rules, maybe we could mention the /48-per-site-or-per-customer-or-per-end-user-or-whatever-you-want-to-call-it suggestion when writing the assignment plan to get bigger IPv6 space :) Cheers, Jan
* Jan Zorz
On 10/25/13 12:37 PM, Shane Kerr wrote:
Using bits in IPv6 networks for other purposes is orthogonal to those goals.
What should we do about it?
Hey,
As far as I know, the rule-of-thumb is to allocate /48 per customer.
Not really, the policy just says that the minimum assignment size is /64. However, assignments shorter than /48 requires paperwork to be filled in, and since nobody likes paperwork /48 constitutes the de-facto max assignment size in all but exceptional cases. Apart from that it's up to the LIR/ISP to decide how much to assign. In any case we've been cheering on folks who "waste" bits on stuff like 6RD too. Shrug. Personally I'm happy to see folks burn some bits if it results in actual deployments. Tore
On 10/25/13 3:13 PM, Tore Anderson wrote:
In any case we've been cheering on folks who "waste" bits on stuff like 6RD too. Shrug. Personally I'm happy to see folks burn some bits if it results in actual deployments. Tore
+1 Jan
On Fri, Oct 25, 2013 at 12:37:00PM +0200, Shane Kerr wrote:
Using bits in IPv6 networks for other purposes is orthogonal to those goals.
What should we do about it?
Let's live with that? ;-) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hello to All from Bavaria, in my opinion it is very interesting to code additional information using the bits of an Ipv6 address. E.g. you can code geolocation data into the address (in June this year I presented this at the heise German Ipv6 Summit) Imagine a company with many voip-telefone equipment - in this case you could build the ip address with the telefone number. It is possible to build an ip adress with ascii codes and ... I think people will come to many ideas to make Ipv6 addresses more friendly and/or give them more meaning. Greetings from Bavaria Maximilian Weigmann Am Freitag, den 25.10.2013, 12:37 +0200 schrieb Shane Kerr:
All,
[ gah... hit the wrong key and sent this unfinished ]
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing.
For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise.
There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users).
But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7020:
http://datatracker.ietf.org/doc/rfc7020/
This includes the long-standing historical goals of conservation, aggregation, and accuracy.
Using bits in IPv6 networks for other purposes is orthogonal to those goals.
What should we do about it?
Cheers,
-- Shane
Hello to All from Bavaria, in my opinion it is very interesting to code additional information using the bits of an Ipv6 address. E.g. you can code geolocation data into the address (in June this year I presented this at the heise German Ipv6 Summit) Imagine a company with many voip-telefone equipment - in this case you could build the ip address with the telefone number. It is possible to build an ip adress with ascii codes and ... I think people will come to many ideas to make Ipv6 addresses more friendly and/or give them more meaning. Greetings from Bavaria Maximilian Weigmann Am Freitag, den 25.10.2013, 12:37 +0200 schrieb Shane Kerr:
All,
[ gah... hit the wrong key and sent this unfinished ]
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing.
For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise.
There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users).
But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7020:
http://datatracker.ietf.org/doc/rfc7020/
This includes the long-standing historical goals of conservation, aggregation, and accuracy.
Using bits in IPv6 networks for other purposes is orthogonal to those goals.
What should we do about it?
Cheers,
-- Shane
Hi Shane and list, Shane Kerr <shane@time-travellers.org> writes:
All,
[ gah... hit the wrong key and sent this unfinished ]
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. [...] This includes the long-standing historical goals of conservation, aggregation, and accuracy.
Using bits in IPv6 networks for other purposes is orthogonal to those goals.
What should we do about it?
as long as they don't need more than "their share" of the address space as defined by the policy applied to everyone: Nothing. More important however is the question how to deal with them if /when they show up because they have unnecessarily "depleted" their address assignment thanks to encoding stuff in it. I strongly suggest to send them home to renumber their network (and hope it hurts enough to teach them and everyone watching a lesson). It's not much different than with IPv4. Beyond that, there are some more aspects to consider: - Work the numbers. With IPv4 addresses and 32 bits we have kind of managed to come to grips at an intuitive level. With IPv6, this simply doesn't work anymore; a /29 for Deutsche Telekom is ok. However, if they start to code more stuff into the addresses, this will quickly break down. In other words: No matter what, 128 bits are still just 16 bytes. If other people follow suit and start to encode things in their addresses, we may run out of space *very* quickly. - Remember that they effectively nicked the extra five(?) bits from the subnet ID, by handing out /56s instead of /48s as originally intended. They can only do that so often. - I assume you all know about the black/grey market for IPv4 by now. This isn't a technical thing, but a "business model". People will again receive allocations they don't need, and we will see some sort of artificial, money-driven depletion of the IPv6 address space as well. If this gets "successful" before we have to move on from IPv6 for unrelated reasons, or if this will again cause us to run out of addresses before anything else becomes a critical issue, is open for speculation. The only solution to that would have been variable length addresses, and they bring another bunch of problems of their own. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/
On Fri, Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
Hi Shane and list,
Shane Kerr <shane@time-travellers.org> writes:
All,
[ gah... hit the wrong key and sent this unfinished ]
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. [...] This includes the long-standing historical goals of conservation, aggregation, and accuracy.
Using bits in IPv6 networks for other purposes is orthogonal to those goals.
What should we do about it?
as long as they don't need more than "their share" of the address space as defined by the policy applied to everyone: Nothing.
More important however is the question how to deal with them if /when they show up because they have unnecessarily "depleted" their address assignment thanks to encoding stuff in it. I strongly suggest to send them home to renumber their network (and hope it hurts enough to teach them and everyone watching a lesson).
It's not much different than with IPv4.
It is just bits, numbers, never forget that. How people/ISP/something chose to use what is available to them really is upto them. We have some experience since we started to use IPv6 back in the 90s, and we also have some guidelines on what is a good idea, and what is a really horrible idea. What is a bad idea, so far almost all agree somehow, is to put too much semantic into the IPv6 address. Some is great, and usefull, but chose wisely. Only difference from IPv4 is the amount of space you can _misuse_. It's upto each and every operator do make the chose _they_ think is the right for themself. If they ignore the advices given and run out, renumber. If they run out due to size and growth, and they haven't wasted space, used their available /29 wisely by every advice given...give them another prefix.
Beyond that, there are some more aspects to consider:
- Work the numbers. With IPv4 addresses and 32 bits we have kind of managed to come to grips at an intuitive level. With IPv6, this simply doesn't work anymore; a /29 for Deutsche Telekom is ok. However, if they start to code more stuff into the addresses, this will quickly break down. In other words: No matter what, 128 bits are still just 16 bytes. If other people follow suit and start to encode things in their addresses, we may run out of space *very* quickly.
I did some calculation long time ago, 2002-2003 or around there, only thing I remember is that IPv6 isn't really that huge, it's big and plenty for sure but if we start to waste we will run out quite fast. Very fast. One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :) However IPv6 is big enough that most people will not feel any pain with it, some however will start to get into trouble in 5-10years time, guess more like around in 7 years. The reason? They made a too static model on how they wanted to use their available space. But you have to be big to get into that trouble.
- Remember that they effectively nicked the extra five(?) bits from the subnet ID, by handing out /56s instead of /48s as originally intended. They can only do that so often.
There was major discussion just to get that /56 into the documents. Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing it even more. Are discussion on moving away from /64's on the wire to... Doesn't this sound like A/B/C-class network vs CIDR?
From my own experience over the years, since early days in 97 upto now, there isn't a one size fits all as I too believed in the early days of IPv6.
* For one server running in the cloud I got a /112, that work just fine really. * Somewhere else I'm using a /50 on the wire, that also work just fine. * I have tried to use an entire /48 but failed. I tried to build my own network with VPN, routings and everything across the different servers and routers I have spread around. That /48 was big enough for me:) * I tried to build a big routed, multisite network using a /56, that also worked upto a certain size :) -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Hi Roger and list, On Fri, Roger Jørgensen <rogerj@gmail.com> writes:
Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
[...] More important however is the question how to deal with them if /when they show up because they have unnecessarily "depleted" their address assignment thanks to encoding stuff in it. [...] If they run out due to size and growth, and they haven't wasted space, used their available /29 wisely by every advice given...give them another prefix.
That's what I meant by "unnecessarily 'depleted'". If they actually grow beyond their /29 or whatever, let them have another prefix. What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same. And yes, I've had these discussions. In particular, the idea to bit-encode the services (i.e. significant port numbers) somewhere in the subnet prefix. Eventually these people decided "well, we have a /12 for IPv4, so it's only fair we also get a /12 for IPv6". At that point I pretty much gave up and told them to request that from their RIR...
One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :)
Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years.
However IPv6 is big enough that most people will not feel any pain with it, some however will start to get into trouble in 5-10years time, guess more like around in 7 years. The reason? They made a too static model on how they wanted to use their available space.
Agreed, but...
But you have to be big to get into that trouble.
I don't see any reason why size has to do with it. The problem is more of a ratio between size and allocated address space---and the technical knowledge around. (And no, unlike somebody else on this list I don't believe it feasible for a consumer to call in a CCIE every time they need some networked deviced hooked up.)
There was major discussion just to get that /56 into the documents. Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing it even more. Are discussion on moving away from /64's on the wire to...
If /64 is given up, all sorts of shit will happen. It has been part of the specs for long enough that a number of implementations will rely on it. It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult. Additionally, anything that can be (mis-)configured exponentially adds (or rather, multiplies) to the frustration potential for end users.
Doesn't this sound like A/B/C-class network vs CIDR?
You mean VLSM, I assume?
* For one server running in the cloud I got a /112, that work just fine really.
...until you do an upgrade on the server that relies on RFC 4291.
* Somewhere else I'm using a /50 on the wire, that also work just fine.
Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way.
* I have tried to use an entire /48 but failed. I tried to build my own network with VPN, routings and everything across the different servers and routers I have spread around. That /48 was big enough for me:)
Oha. So you have too many machines to fit into a /64 in a single subnet?
* I tried to build a big routed, multisite network using a /56, that also worked upto a certain size :)
Sorry, I don't get what you want to say there. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/
On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote:
Hi Roger and list,
On Fri, Roger Jørgensen <rogerj@gmail.com> writes:
Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand <bs@stepladder-it.com> wrote: What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same.
that's the second time I read this in this thread. Why would this happen? All allocations are subject to RIR policy
One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :) Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years.
40 years from now? Many, more significant changes will probably overshadow this. Otherwise, 256 different policies in a home sound just fine
There was major discussion just to get that /56 into the documents. Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing it even more. Are discussion on moving away from /64's on the wire to... It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult.
care to elaborate on that?
* For one server running in the cloud I got a /112, that work just fine really. ...until you do an upgrade on the server that relies on RFC 4291.
* Somewhere else I'm using a /50 on the wire, that also work just fine. Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way.
again, care to elaborate a bit? How's a /50 not compliant with RFC 4291?
Cheers, Benedikt
cheers, Yannis
Hi Yannis and list, Yannis Nikolopoulos <dez@otenet.gr> writes:
On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote:
Hi Roger and list,
On Fri, Roger Jørgensen <rogerj@gmail.com> writes:
Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand <bs@stepladder-it.com> wrote: What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same.
that's the second time I read this in this thread. Why would this happen? All allocations are subject to RIR policy
yes, but policies can be circumvented, lobbied out of the way or overridden by legislation, as was effectively the case with the Nortel/Microsoft deal, among others. There used to be a policy that IP addresses can't be traded. Take a look at the recordings from the RIPE meeting last week to see what happens right now.
One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :) Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years.
40 years from now? Many, more significant changes will probably overshadow this. Otherwise, 256 different policies in a home sound just fine
According to Bob Kahn with exactly the same reasoning the original 6 bit addresses in the Arpanet were widely ridiculed; pretty much the same happened again again when they went straight for 32 bit addresses in IPv4 (which was pretty much exactly the 40 years I mentioned ago, so that's where I got that number from). If you plan for future networks by today's demands, without taking into account either some future growth nor some imminent or at least apparent developments, like the currrent growth of networked embedded systems, you won't make it through even the next ten years. And considering the time it took for IPv6 to take off, even if we started on developing its successor today, we'd have to live with IPv6 for another 25 years or more; IPv4 will likely last another five years, making it a total lifetime of 45 years. We might as well accept that whatever we do today will haunt us at that long as well.
There was major discussion just to get that /56 into the documents. Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing it even more. Are discussion on moving away from /64's on the wire to... It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult.
care to elaborate on that?
Yes, but I'd rather do that in a separate thread/with a new subject...
* Somewhere else I'm using a /50 on the wire, that also work just fine. Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way.
again, care to elaborate a bit?
Yes. If somebody decides to remove support for a configurable subnet prefix length, based on the fact that the RFCs mentioned below don't allow anything but a /64 as subnet prefix, an upgrade of a system with a differently configured subnet prefix will blow up in your face. If this happens because of a security hole, this leaves you the choice of either running the vulnerable old version, or taking a (production) system down until you've sorted out your network setup. There are at least two valid reasons to remove support for a configurable subnet prefix length: It adds overhead to the implementation (again, this is particularly troublesome with microcontrollers) and it is yet another option to frustrate end users. As far as your possible successors as sysadmin/netadmin are concerned: If somebody in some not-so-far-away future inherits the systems you have set up and has to handle them, doing something that is not covered by specifications but happens to work with some implementations, this is quite likely to blow up in their faces---and your (former) company's, since this is likely to cost noticeable money. Yes, I've been down that road in several slightly different contexts, and thinking of the trouble it caused I consider these sorts of time bombs reason enough to sack whoever set them up. And no, sorry, I can't provide any more details, except maybe that with BIND4 it was possible to put periods in DNS labels... As far as end users are concerned: When it comes to systems that are operated by end users who don't understand---and shouldn't need to understand---the internals of the stuff they use, every single configuration options is something that at best adds, or rather multiplies, to the number of options they have to try to get things up and running. This is bad for the end user as well as the vendor of the gear, so minimizing the number of configurables is actually one of the key measures to keep non-professional end users happy.
How's a /50 not compliant with RFC 4291?
(One of these days I'll actually make that into a separate three-page RFC, so people who won't or can't read 4291 can be referred to that...) RFC 4291, page 8, section 2.5.1, for all unicast addresses except those starting with 000b, which is currently :: and ::1, and again in RFC 4291, page 10, section 2.5.4 (for global unicast addresses) RFC 4291, page 11, section 2.5.6 (for link-local unicast addresses) RFC 4193, page 3, section 3.1 (for unique-local unicast addresses) Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/
Hello, On 10/27/2013 08:20 PM, Benedikt Stockebrand wrote:
Hi Yannis and list,
Yannis Nikolopoulos <dez@otenet.gr> writes:
Hi Roger and list,
On Fri, Roger Jørgensen <rogerj@gmail.com> writes:
Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand <bs@stepladder-it.com> wrote: What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same.
On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote: that's the second time I read this in this thread. Why would this happen? All allocations are subject to RIR policy yes, but policies can be circumvented, lobbied out of the way or overridden by legislation, as was effectively the case with the Nortel/Microsoft deal, among others.
usually, policy works just fine and by policy I mean something like RIPE-589 which aims to make sure that folks don't just waste their precious space as per your original comment. Nortel/MS case is totally different IMO.
There used to be a policy that IP addresses can't be traded. Take a look at the recordings from the RIPE meeting last week to see what happens right now.
It's still up to us (RIR members) to change the shape of things to come, although I feel we're off-topic again :)
One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :) Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years. 40 years from now? Many, more significant changes will probably overshadow this. Otherwise, 256 different policies in a home sound just fine According to Bob Kahn with exactly the same reasoning the original 6 bit addresses in the Arpanet were widely ridiculed; pretty much the same happened again again when they went straight for 32 bit addresses in IPv4 (which was pretty much exactly the 40 years I mentioned ago, so that's where I got that number from).
If you plan for future networks by today's demands, without taking into account either some future growth nor some imminent or at least apparent developments, like the currrent growth of networked embedded systems, you won't make it through even the next ten years.
And considering the time it took for IPv6 to take off, even if we started on developing its successor today, we'd have to live with IPv6 for another 25 years or more; IPv4 will likely last another five years, making it a total lifetime of 45 years. We might as well accept that whatever we do today will haunt us at that long as well.
I was merely stating that 40 years from now is an awfully long time to plan for (as far as an addressing plan goes) and to be honest I don't know many people who do.
* Somewhere else I'm using a /50 on the wire, that also work just fine. Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way. again, care to elaborate a bit? [snip]
How's a /50 not compliant with RFC 4291?
actually, I missed "on the wire" from the original comment :) cheers, Yannis
Cheers,
Benedikt
As threatened... Benedikt Stockebrand <bs@stepladder-it.com> writes:
Hi Yannis and list,
Yannis Nikolopoulos <dez@otenet.gr> writes:
Are discussion on moving away from /64's on the wire to... It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult.
care to elaborate on that?
Yes, but I'd rather do that in a separate thread/with a new subject...
Ok, sorry but this will be longish. I'll try to organize things a bit. Design considerations --------------------- Embedded systems are generally designed and built for a fixed purpose. (Arduino et al are development/prototyping platforms not really fit for production use.) When building for production it is essential to pick the smallest, most limited microcontroller or CPU that can do the job and only put things in there that are known to be needed. In the networking world you'd follow a similar approach when building a custom firewall setup, in case you've ever tried to do so. There are several reasons why it is so important to put effort into this minimization when building embedded systems. First of all, it reduces cost. And in a market where a few cents in price make the difference if your product or your competitors makes it to the shelves of the major electronics outlets, this is absolutely critical. If you sell your SIP phone for example at 15.30 Euro/USD/whatever and your competitor sells at 15.20, then you are out of business; if you manage to reduce your price by .15, then you survive. It's as simple as that. Next, whatever isn't there can't break; this is particularly important because many embedded systems simply *must* work, no matter what. If your car's anti-skid system crashes at the wrong moment, so will you. In Germany a few years ago, some ISPs touted DSL, promising "availability of up to 99%". Aside from the obvious logical nonsense in here, even if they had promised a 99% availability, that's several orders of magnitude too bad for many embedded systems. As a consequence, people building embedded systems will habitually strip them down to the absolute minimum. Finally, especially when talking battery powered devices, power consumption is usually a significant issue. If it isn't there, it can't consume power. If it can't consume power, a smaller and less heavy (and less expensive) battery can be used and recharge times may be reduced. And when micro energy harvesting enters the equation, this gets even more important. In "normal" IT it is generally reasonable to buy somewhat oversized because our systems tend to grow over time. Embedded systems built for a fixed purpose don't grow, so the entire way of thinking here is going exactly the opposite way we've been taught in our line of business. Operational aspects ------------------- Embedded systems frequently don't assume a system administrator to be around. They are built to be handled by ordinary end users, like you in your car, or an airline pilot in a---surprise---airliner. And despite various rumors, the onboard engineers of the past haven't been replaced by a system/network administrator. This means that embedded systems must frequently be built so people without any particular knowledge can safely and reliably operate them. This also applies to more mundane systems, like "smart" TVs or network controlled heating radiator valves or such. And when it comes to confronting end users with questions they can't possibly answer, simply because they don't have the necessary technical knowledge, that's enough for yet another thread---but not this time. System updates -------------- Updating an embedded system is troublesome in a number of ways. First of all, people frequently don't care about updates, as some recent events at least here in Germany have shown. My personal experience here is more from a security point of view; let's say that a customer of mine was kind of embarrassed when I happened to I mention security updates on network printers... Next, in a Harvard or even modified Harvard architecture, updates are difficult to implement. The larger AVR microcontrollers (see below) support the concept of a "management system" called a boot loader---which needs extra flash memory, of course. But to do an update it is necessary to trigger that update externally; there are no automatic updates. Even if there was a way to do automatic updates, how would one time them? Even a downtime of a few seconds may be unacceptable to your power brake system while in heavy traffic. As soon as embedded systems are used in critical environments, changes need to be tested, validated and certified. What's worse, if the functionality is "improved", things that can happen are shown for example here: http://en.wikipedia.org/wiki/Scandinavian_Airlines_Flight_751 Technical properties -------------------- While some embedded systems have significant computational power comparable to a full-blown computer, for example in the Linux-running ones, microcontrollers are generally more limited. Just to give you some ideas; I'll stick with the Atmel AVR line of microcontrollers, because I am most familiar with them and thanks to the Arduino line of prototyping boards they are best known in general. These are Harvard architecture devices, so they have separate (flash) memory for code, (static) RAM for volatile data and EEPROM for non-volatile data. And no, there's no MMU, memory caches or DRAM; which isn't altogether bad when building systems to hard realtime requirements. ATtiny13: 1 kB of flash memory, 64 bytes of RAM, 64 bytes of EEPROM 5/6 GPIO pins, no dedicated I/O hardware This is rather limited for any kind of communications, except maybe via bitbanging the GPIO pins. Yes, these devices are actually used. No, these are not the smallest ones available, but they are the smallest that can be programmed in-system. ATtiny25: 2 kB of flash memory, 128 bytes of RAM, 128 bytes of EEPROM 5/6 GPIO pins, alternatively used for I2C or SPI These can actually be put on an I2C or SPI bus and combined with I2C or SPI peripherals that way. It may be possible to use them with a USB or TCP/IP/Ethernet chip, but I don't have any reliable data, let alone personal experience, on this. ATtiny2313: 2 kB of flash memory, 128 bytes of RAM, 128 bytes of EEPROM 11/12 GPIO pins, alternatively used for I2C, SPI or U(S)ART These can also do serial communication (RS-232/422/485 using suitable driver chips. Even more interesting: With a few external components (Zener diodes and resistors?) they can also do USB in software, using about 1100 to 1300 bytes of their flash memory; search for V-USB for details. ATmega328: 32 kB flash, 2 kB RAM, 1 kB EEPROM 23 GPIO pins, alternatively used for I2C, SPI, U(S)ART Boot loader support These are used in the Arduino Uno board. Combined with a hardware TCP/IP/Ethernet chip like the Wiznet W5100, they can do TCP/IP. See below. ATmega1284: 128 kB flash, 16 kB RAM, 4 kB EEPROM. 32 GPIO pins, alternatively used for I2C, SPI, 2x U(S)ART Boot loader support The most powerful AVR microcontroller available in a DIP package. Beyond that, it is SMD only. But beyond this it's mostly more I/O stuff anyway. To add network capabilities, this requires some extra hardware except for the V-USB thing mentioned with the t2313. If you want to use the USARTs for RS-xxx: Maxim has a range of driver chips with built-in charge pumps to convert between TTL and RS-xxx voltages. In case you want to limit yourself to USB, take a look at the FTDI FT245BL. There are Ethernet-only chips like the ENC 28J60. According to a statement during the last IETF meeting in Berlin, it is possible to implement IPv6 with "only" 32 kB of flash and 4 kB of RAM. In other words, this is not an option for the Arduino Uno. The Wiznet W5100 used on the Arduino Ethernet shields implements IPv4 in hardware, or at least parts of it---among the things missing are for example fragmentation. So far I don't know of any similar chip implementing IPv6, let alone dual-stack. And to return to Yannis' original question: If I was to implement IPv6 in a setup like this I'd read the RFCs in question very closely---and then I'd take every simplification I could get away with. Hardcoding a /64 subnet prefix length in that implementation would be one I'd have absolutely no problem with; doing so would be standards compliant, save a few bytes of flash, and a lot of frustration for end users who in all likelyhood wouldn't know what value to set it to anyway, but try just about anything if things don't work out of the box. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/
On Sun, Oct 27, 2013 at 8:54 AM, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
Hi Roger and list,
On Fri, Roger Jørgensen <rogerj@gmail.com> writes: <snip>
One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :)
Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years.
We'll have bigger problems, and other problems in 10years time. We have probably start to use more than the 2000::/3 space for one thing. That might change the game? I do think /56 is fine for most thing, really for most thing. But if someone want to use /48 just to be sure. Fine let them do that. If a user want a /48 instead of /56, then the operators actually _should_ hand it out. <snip>
But you have to be big to get into that trouble.
I don't see any reason why size has to do with it. The problem is more of a ratio between size and allocated address space---and the technical knowledge around. (And no, unlike somebody else on this list I don't believe it feasible for a consumer to call in a CCIE every time they need some networked deviced hooked up.)
are work ongoing elsewhere that maybe can fix that connect-anything-anyway-you-like problem we've always had. But that's not a policy question.
There was major discussion just to get that /56 into the documents. Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing it even more. Are discussion on moving away from /64's on the wire to...
If /64 is given up, all sorts of shit will happen. It has been part of the specs for long enough that a number of implementations will rely on it. It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult.
Additionally, anything that can be (mis-)configured exponentially adds (or rather, multiplies) to the frustration potential for end users.
agree, this /64 is one of the really really good thing. It can be considered a waste of address space but it's a nice division between net-prefix and LAN-prefix :-) <snip>
* For one server running in the cloud I got a /112, that work just fine really.
...until you do an upgrade on the server that relies on RFC 4291.
so what? I buy a service, and if the provider support me installing something that break their setup, then it's really their problem. Pain is mine but problem is theirs to fix.
* Somewhere else I'm using a /50 on the wire, that also work just fine.
Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way.
again, so what? I've done worse use of the IPv6 space over the years and _only_ thing that bit me really hard was the /127 problem ages ago. But we got around that to, and it bit me because I did things I wasn't supposed todo:) Again - operators choice of operating their own network.
* I have tried to use an entire /48 but failed. I tried to build my own network with VPN, routings and everything across the different servers and routers I have spread around. That /48 was big enough for me:)
Oha. So you have too many machines to fit into a /64 in a single subnet?
No, I had enough of /64 in a /48. I tried to run out of /64's but hadn't enough sites or enough machines. I really tried, even used /52, /56 etc to :-) The operating headache took me way before the address space was empty. Could gone further with automaton but that wasn't the point.
* I tried to build a big routed, multisite network using a /56, that also worked upto a certain size :)
Sorry, I don't get what you want to say there.
a /56 is plenty for most cases. However I was able to run out of available /64 to use before the operating headache took me :-) I think that if an end-user ask for a /48 then the operators _should_ provide you with a /48. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Hi Roger, Roger Jørgensen wrote: [...]
Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years.
We'll have bigger problems, and other problems in 10years time. We have probably start to use more than the 2000::/3 space for one thing. That might change the game?
If we need to start another /3 in just a decade's time then Internet growth will have been astronomical. There are currently 506 /12s available in 2000::/3 and to have allocated them all in a decade would mean allocating more than four per month. Even at a relatively sparse allocation density that would still require an Internet significantly more massive that what we currently have. Regards, Leo Vegoda
Roger Jørgensen <rogerj@gmail.com> writes:
We'll have bigger problems, and other problems in 10years time. We have probably start to use more than the 2000::/3 space for one thing. That might change the game?
as Leo pointed out: Work the numbers. Then think about 4000::/3, 6000::/3, 8000::/3, a000::/3, c000::/3.
I don't see any reason why size has to do with it. The problem is more of a ratio between size and allocated address space---and the technical knowledge around. (And no, unlike somebody else on this list I don't believe it feasible for a consumer to call in a CCIE every time they need some networked deviced hooked up.)
are work ongoing elsewhere that maybe can fix that connect-anything-anyway-you-like problem we've always had. But that's not a policy question.
I'm not sure if I get what you mean. But if you relate to the IETF homenet WG: From what I've seen they have very limited understanding of microcontrollers and apparently keep forgetting about their grandma (or whatever other archetypical non-tech end user).
[...] agree, this /64 is one of the really really good thing. It can be considered a waste of address space but it's a nice division between net-prefix and LAN-prefix :-)
What do you mean by "net-prefix" and "LAN-prefix"???
* For one server running in the cloud I got a /112, that work just fine really.
...until you do an upgrade on the server that relies on RFC 4291.
so what? I buy a service, and if the provider support me installing something that break their setup, then it's really their problem.
Pain is mine but problem is theirs to fix.
As I pointed out elsewhere in this thread, anything but a /64 as subnet prefix length violates RFC 4291. The problem is yours.
* I have tried to use an entire /48 but failed. I tried to build my own network with VPN, routings and everything across the different servers and routers I have spread around. That /48 was big enough for me:)
Oha. So you have too many machines to fit into a /64 in a single subnet?
No, I had enough of /64 in a /48. I tried to run out of /64's but hadn't enough sites or enough machines. I really tried, even used /52, /56 etc to :-) The operating headache took me way before the address space was empty. Could gone further with automaton but that wasn't the point.
Sorry, I really don't understand what you try to say here.
* I tried to build a big routed, multisite network using a /56, that also worked upto a certain size :)
Sorry, I don't get what you want to say there.
a /56 is plenty for most cases. However I was able to run out of available /64 to use before the operating headache took me :-)
I think that if an end-user ask for a /48 then the operators _should_ provide you with a /48.
??? Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/
Thus wrote Shane Kerr (shane@time-travellers.org):
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing.
For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise.
[...]
What should we do about it?
As a RIR, nothing. Otherwise: violations of the KISS principle are rarely a good idea. In this case, you might find out that you snuck yourself into a straightjacket a few years down the line. regards, spz -- spz@serpens.de (S.P.Zeidler)
Hello, On 10/25/2013 06:53 PM, S.P.Zeidler wrote:
Thus wrote Shane Kerr (shane@time-travellers.org):
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing.
For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. [...]
What should we do about it? As a RIR, nothing.
what about as one of RIPE's WGs? Should we go on and produce a BCP document of some kind? As the author of this addressing plan (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS. As I mentioned in the presentation, this is our 3rd or 4th try over the past ~10 years. So far, with the help of some basic heuristics, it seems to be working out fine cheers, Yannis
Otherwise: violations of the KISS principle are rarely a good idea. In this case, you might find out that you snuck yourself into a straightjacket a few years down the line.
regards, spz
Thus wrote Yannis Nikolopoulos (dez@otenet.gr):
For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. [...]
What should we do about it? As a RIR, nothing.
what about as one of RIPE's WGs?
The addressing plan within an allocation is the LIRs responsibility, and if they want to shoot themselves in the foot they may do so. Maybe their network designer is a genius or they have a special environment, and the complicated plan they come up with turns out to be gold. In general, "as simple as you can get away with" is a good aim, though. It won't only need to look good on paper, it'll need to be useable and maintainable, too.
Should we go on and produce a BCP document of some kind? As the author of this addressing plan
(https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS.
Ok, let me be less terse. I'm not speaking from a scientific research position but from a gut reaction which is based on some practical experience. I think if you want to encode something in the netmask area, you want to define ranges, not bits, you want to prioritize routing (i.e., obviously "location") and keep "magic info" to the really really basic, like "the '0' subnet is the PoP LAN'", because if the people in the NOC need to do a drawing of the bits or use a calculator before they can assign the proper address to a router that'll not be a happy network (use of tools alleviates that, but the more complicated your rules the more prone to bugs they will be). Humans can learn the most amazing feats of pattern matching, given enough time, but you want to give the new hire who has only been around for 6 months a chance to also immediately *see* that the address given is wrong in that use context if your routers discriminate on them. If your network equipment does not use the encoded information, thus making errors obvious by causing failures, you can expect that the information encoded is a cute note but not a reliable one. There's nothing wrong with conventions, especially if they are entertaining, as long as you remember that that's all they are, and that they can be put out with the garbage if there is a good reason. For a network plan I have been involved in, for an ISP with many locations and expecting growth, we basically said: We have small, medium, large and huge locations. We will section up the entire available space in equal chunks. (this gives a minimum standard network size in the routing table; customers will cause this to be messed up :) Each location will get a chunk and when they use it up, another one. We will try to keep the chunks going to a location contiguous, but no guarantees. To be able to add contiguous chunks, we will leave gaps between initial assignments, and the size of the location determines the size of its gap; initially, group net-near locations next to each other but also make no promises. Lowest /64 of the initial assignment is location core LAN, rest of the lowest /48 are further LANs or transfer addresses: convention, no guarantees. Should the /48 run out, just take the next free one. This is fairly simple and hopefully also maintainable. Additional knowledge about a network may lead to different results; but it's easy to underestimate growth, or to misjudge where growth will happen, and when that happens it shouldn't cause too much pain - especially not sustained pain. Regarding the addressing plan you made: I don't know your network, you do. My comments may thus simply not apply because of local conditions. So, adding this packet of salt: Not to be snide, but "trusted" is a bad designation :) You know all the jokes about the evil bit? Being able to immediately see that a fault is probably your issue is good, trusting large ranges of address space less so. Traffic types in front of location prevents aggregation, which is not a huge issue these days, but still unnessecarily inefficient. That's also what I don't like about your loopback choice and transfer addresses choice; your routing table will contain quite a bunch of /128. Also, having both traffic type and service seems redundant (is there an issue for network ops to get prefixes configured in a local firewall? Otherwise I'd expect infrastructure to just be treated as another service), and lower than /56 you normally leave to your customers (a case of "local specialties not mentioned" that make you contol those bits as well?) No quarrel with encoding the vlan id in the local infrastructure subnet as long as you agree beforehand to write numbers (hex) or strings; that's an example of convention. If you write string, the presence of a letter can mean it's not a vlan. Your plan of numbering residential customers up and business customers down will not survive contact with the enemy^Wcustomer unscathed; also its information content is limited as long as you don't know where the border is (and that will be different in every location, unless you are willing to accept large gaps that may not fill), but as a convention, why not. I'm missing an explicit plan on how locations get grown. You assume you'll never run out with a /40? regards, spz -- spz@serpens.de (S.P.Zeidler)
Hello, first of all thanks a lot for the feedback. On 10/27/2013 01:15 PM, S.P.Zeidler wrote:
Thus wrote Yannis Nikolopoulos (dez@otenet.gr):
Should we go on and produce a BCP document of some kind? As the author of this addressing plan
(https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS. Ok, let me be less terse. I'm not speaking from a scientific research
[snip] position but from a gut reaction which is based on some practical experience.
[...] If your network equipment does not use the encoded information, thus making errors obvious by causing failures, you can expect that the information encoded is a cute note but not a reliable one. There's nothing wrong with conventions, especially if they are entertaining, as long as you remember that that's all they are, and that they can be put out with the garbage if there is a good reason.
i agree, it's happened way too many times in the past...
For a network plan I have been involved in, for an ISP with many locations and expecting growth, we basically said:
We have small, medium, large and huge locations.
we've been down that road a few times (with both v4 and v6) but decided against it in the current plan.
[...] Regarding the addressing plan you made: I don't know your network, you do. My comments may thus simply not apply because of local conditions. So, adding this packet of salt:
Not to be snide, but "trusted" is a bad designation :) You know all the jokes about the evil bit? Being able to immediately see that a fault is probably your issue is good, trusting large ranges of address space less so.
yep, I agree. We're not exactly using "trusted vs non-trusted", more like "infrastructure vs customers". Infrastructure is not all trusted of course ;)
Traffic types in front of location prevents aggregation, which is not a huge issue these days, but still unnessecarily inefficient.
Actually, we're aiming at being efficient by aggregating customer prefixes which are smaller than /32
That's also what I don't like about your loopback choice and transfer addresses choice; your routing table will contain quite a bunch of /128.
Also, having both traffic type and service seems redundant (is there an issue for network ops to get prefixes configured in a local firewall? Otherwise I'd expect infrastructure to just be treated as another service), and lower than /56 you normally leave to your customers (a case of "local specialties not mentioned" that make you contol those bits as well?)
infrastructure being another service was considered and may actually be a better idea :) . About messing with bits 56-64 for customer services, I realise it sounds awkward but what we *might* do in the near future (when and if it makes sense) is to apply certain policies for certain groups of /64s and that's that.
No quarrel with encoding the vlan id in the local infrastructure subnet as long as you agree beforehand to write numbers (hex) or strings; that's an example of convention. If you write string, the presence of a letter can mean it's not a vlan.
Your plan of numbering residential customers up and business customers down will not survive contact with the enemy^Wcustomer unscathed; also its information content is limited as long as you don't know where the border is (and that will be different in every location, unless you are willing to accept large gaps that may not fill), but as a convention, why not.
I'm not sure I follow here :)
I'm missing an explicit plan on how locations get grown. You assume you'll never run out with a /40?
on the contrary, we're expecting to run out. If that's the case, either a 2nd /40 (location) is allocated for the same PoP (e.g athens1, athens2) or the same location is used in the next "customer" /32 cheers, Yannis
regards, spz
On Fri, Oct 25, 2013 at 12:37:00PM +0200, Shane Kerr <shane@time-travellers.org> wrote:
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing.
Hi Shane, for those of us who couldn't follow the RIPE presentations this year, can you link to the slides? I've been wanting to do similar things for storing large media catalogues for years ;) C. -- 0x8486EDA8 http://spodder.com/
Charlie, On Fri, 25 Oct 2013 17:31:16 +0100 Charlie Allom <charlie@evilforbeginners.com> wrote:
On Fri, Oct 25, 2013 at 12:37:00PM +0200, Shane Kerr <shane@time-travellers.org> wrote:
We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing.
Hi Shane, for those of us who couldn't follow the RIPE presentations this year, can you link to the slides?
Sure, here they are: https://ripe67.ripe.net/presentations/251-ripe2-4.pdf https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf Cheers, -- Shane
participants (11)
-
Benedikt Stockebrand -
Charlie Allom -
Jan Zorz -
Leo Vegoda -
Piotr Strzyzewski -
Roger Jørgensen -
S.P.Zeidler -
Shane Kerr -
Tore Anderson -
Weigmann Maximilian -
Yannis Nikolopoulos