We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan.
Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ
I'm curious to hear if you think it's clear and useful.
Cheers,
Alex Band
RIPE NCC Trainer
(Big props go to Marco Hogewoning @XS4ALL)
Useful, yes. But it should be clearer that not all address plans are
equally good. It's not just a matter of filling in the blanks with
something that will work.
For instance, would one be expected to follow RFC 3531?
Simon
Alex this looks great! Just printed it out and will play with it. I've spent some time learning
IPv6 but when you're not looking at it daily, you begin to forget....
We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan.
Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ
I'm curious to hear if you think it's clear and useful.
Useful, yes. But it should be clearer that not all address plans are
equally good. It's not just a matter of filling in the blanks with
something that will work.
Every address plan will turn out to be a custom job anyway. Primary goal of this exercise is to show the basics and to show how you can get a lot of aggregation done without wasting a lot of space. Making people familiar with the way subnets are split up and the very basics of counting to 16.
I'm also working on a more extensive half day workshop which contains a lot more scenarios and for instance show how to fit this same network into a /48 PI assignment instead of the /32 PA. If you are bored with this one already, go ahead and try 
For instance, would one be expected to follow RFC 3531?
For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it.
As far as customer assignments is concerned, I would simply stick to the /48 and not make any reservation for future growth beyond that, i should probably cater for 99% of your cases and if they really run out I can probably handle a second assignment/route for another one (or leave them the choice to renumber into a /47). In fact part of this exercise is meant to teach people how to avoid such disasters as running 'out of space' by being really inefficient.
The only way where I see this becoming relevant is when trying to make subassignments from a /48. But as far as PI is concerned, and that would be the most likely case, in RIPE region you are not allowed to make subassignments from within a PI block. The other one would be subassignments from a PA block, which under the same policy can easily be made a few bits bigger and if I would encounter a customer who would actually subassign large numbers of customers from within a PA assignment. I would recommend becoming an LIR themselves and get a /32.
MarcoH
Not disagreeing, but here's a tool to make it easier:
http://www.ipv6book.ca/allocation.html
Simon
Nice tool but they just learn a trick instead of understanding what is going on.
Anyway, left or right there is this huge lack of knowledge and a maximum of 12 months to fix it. So whatever gets it going.
MarcoH
Hi Owen,
The RIPE NCC does actually ask for an addressing plan before we allocate a /32 IPv6, so I didn't phrase my opening email 100% accurate; we don't just blindly hand it out. On the other hand, we don't do rigorous checks if it is actually any good, or appropriate for their network.
What we see in the real world, is that many LIRs haven't requested a v6 allocation yet because they simply wouldn't know where to begin making an addressing plan. Then there is the group that sent in an addressing plan, got their allocation, and starting trying some things implementing it. In a lot of cases, they get stuck because reality was a lot different than what they thought it would be, and put the allocation in a drawer since it's not that urgent yet.
This exercise is for both those groups. Just to get them going, understanding the basics.
Cheers,
Alex
I think it is very clear, and very useful. Areas that might be improved:
1: It does not mention technical or management policy considerations.
Those need to be clear before you can start divvying up your allocation.
A technical policy point, for example, might be whether you are going to
stick to /64 subnets throughout, or accept /126 on point to point links.
A management policy might be to always provide for some level of
expansion. I think the exercise would be better if it were prefaced by a
phase where students (or the class as a group) work out the policies
that will apply.
2: It is a very detailed, specific example using real numbers. The
exercise demands a lot of technical precision that doesn't relate to the
intellectual problem at hand. Technical precision is good, but it might
be better sought in a separate exercise. You might get more out of
students by getting them to think about what they would do in more
general terms - i.e., the sizes and groupings of subnets rather than
what specific subnets they would use. This would also help emphasis the
point that it's not addresses that matter in IPv6 - it's subnets.
3: "There is no significant growth". Part of any network design should
be to mitigate the unexpected. So IMHO students should be encouraged to,
for example, duplicate addressing structures across POPs as much as is
feasible, build in reserves for expansion and contraction, and use ULA
addressing for internal networking components to reduce the pain if
networks are split or merged.
Regards, K.
We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan.
Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ
I'm curious to hear if you think it's clear and useful.
You could add a reference to addressing related RFCs e.g. RFC 5375
"IPv6 Unicast Address Assignment Considerations"
We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan.
Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ
And I'd also explicitly mention that 2001:db8 is the
documentation/example prefix.
I think it is a very well planned exercise. I would suggest you not to
be straight in its execution. In some point, you could ask if the
decisions would be the same in cases with different conditions: more
pops, more users, less users, etc...
We have a similar exercise in our training at NIC.br and we use this
diagram to help the trainees understand the addresses:
http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/enderec-v6.pdf…
Maybe it could be useful.
Moreiras.
Hi!
this page may be useful
http://www.getipv6.info/index.php/IPv6_Addressing_Plans
Rodolfo
Simon Perreault
<simon.perreault@
viagenie.ca> Para
Marco Hogewoning
21/07/2010 22:02 <marcoh@marcoh.net>
cc
Nanog <nanog@nanog.org>
Asunto
Re: Addressing plan exercise for
our IPv6 course
Hi Antonio,
That diagram looks interesting. We currently use slides with a bunch of animation to explain to this concept, but it may be nice to have something like this that people can keep as a printed version.
By the way, this is what we think two possible answers are: http://bit.ly/9V5GfU
There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree?
Cheers,
Alex
I never saw the point of assigning a /48 to a DSL customer. Surely the
better idea would be to assign your bog standard residential DSL
customer a /64 and assign them a /56 or /48 if they request it, routed
to an IP of their choosing.
For the rest of it, I largely agree, though.
M
If they're using autoconfigure for IPv6 addresses, what happens if they want to
share that connection? Giving them a /64 off the bat means that a very sizable
fraction of your users are going to call.
Phrased differently - how screwed would you be if you engineered your IPv4
network so the default was "one device only", and the customer had to call you
and ask for a network config change because they wanted to hook up a $50 home
wifi router?
If it doesn't make sense for IPv4, why would you want to do it for IPv6?
"Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls.
Matthew Kaufman
Um, but they will have 18 billion billion addresses in that /64. That
should do them, unless they want to subnet in the home. Which is not so
unusual, so while doing a /48 might be overkill, doing a /60 or even
a /56 off the bat is not such a silly idea.
Unless I've misunderstood Matthew, and he was suggesting that the /64 be
the link network. That would indeed effectively give the customer a
single address, unless it was being bridged rather than routed at the
CPE. Not sure bridging it is such a good idea - most people will
probably want their home networks to keep working even if the ISP has an
outage.
Regards, K.
Well, wouldn't it be better if the provider simply issued enough space to
make NAT66 unnecessary?
Owen
As long as customers believe that having a NAT router/"firewall" in place is a security feature,
I don't think anyone is going to get rid of the NAT box.
In all reality, NAT boxes do work for 99% of customers out there.
Bora
> There are more options, but these two are the most convenient weighing all
> the up and downsides. Does anyone disagree?
I never saw the point of assigning a /48 to a DSL customer. Surely the
better idea would be to assign your bog standard residential DSL
customer a /64 and assign them a /56 or /48 if they request it, routed
to an IP of their choosing.
I estimate that an addressing request will cost the ISP at least 15
minutes of time to process. When a minimum allocation of a /32 contains
16 777 216 /56s, do you really need to create that artificial
addressing cost, eventually passed onto the customer?
With more address space than we need, the value we get is addressing
convenience (just like we've had in Ethernet addressing since 1982).
There is no need to make IPv6 addressing artificially precious and as
costly as IPv4 addressing is.
There are a variety of scenarios where customers, including
residential, will benefit from having multiple subnets. They may wish
to separate the wired and wireless segments, to prevent multicast IPTV
from degrading wireless performance. They may wish to segregate the
children/family PC from the adult PC network or SOHO network, allowing
the subnet boundary to be an additional Internet access policy
enforcement point. They'll need separate subnets if they wish to use a
different link layer technology, such as LoWPAN. They may wish to setup
a separate subnet to act as a DMZ for Internet facing devices, such as
a local web server for sharing photos with relatives. Game consoles may
be put in a separate subnet to ensure file transfers don't interfere
with game traffic latency, using the subnet ID as a QoS classifier.