I think that they have to be forwarded. What do you do if people chain three routers? How does your actual CPE know to dish out a /60 and not a /64 or something? What if someone chains four? What if someone puts three devices behind the second?
This is a CPE problem, the main homegateway can decide to dish out /64s to all other home routers, this means they can have a bunch. It also means they can't chain 3 in serial, unless the home user decides to hand out /60s to each and only have 3 of them connected to the main CPE.
That is one way to do it, sure. However it makes things hard for end users, having to figure out how all this stuff fits together. My non technical friends have a enough time with 3.5mm jack to RCA audio cables, but they managed to get a wireless router and plug it in and have it magically work for them.
Forwarding these requests up to the ISP's router and having several PDs per end customer is in my opinion the best way to go.
Why is this better? Why do you want to waste your tcam entries like that? A single /56 per customer makes you have the fewest amount of tcam entries in any solution I can imagine. All other solutions require more.
Because it allows the home user to arrange their network however they want, up to 16 subnets, without having to have any knowledge of how things actually work.
I'm sure we can both think of a few ways to make this not cost a whole lot of TCAM entries, either with protocol support, or in internal implementation specific ways.
I can immediately think of two ways that cost no extra TCAM entries.
I don't see how your idea of doing on-demand-/64 is any easier than handing them 256 /64:s to begin with.
But it seems we're nog getting any further here. I don't understand why you want to complicate things, you don't understand why I want to do things the way I do, let's just leave it at that.
Draft Policy 2008-6
Emergency Transfer Policy for IPv4 Addresses
Author: Bill Darte
Policy statement:
8.4 Emergency Transfer Policy for IPv4 Addresses
For a period of 3 years from policy implementation, authorized resource
holders served by ARIN may designate a recipient for number resources they
release to ARIN.
ok... so lets just presume, for the mo, that I am an "authorized
resource holder served by ARIN" and I have a /9 that is becoming a bother.
One of my clients, holding discontigious /16's in that /9, desires to use
2008-6 ... and I have no problems w/ that ... HOWEVER.
I want to dump the whole /9. How do I find viable receipients for
the rest of the space? Get out my pushcart and roam the streets with my
bullhorn; "... /16's, /24's... alive, alive Oh!...."
I strongly recommend waiting a few days before thinking about this
issue too hard. The policy results of ARIN XXIII will be posted
in a few days to arin-ppml and should provide some clarity. The
wait will not be long.
It's short sighted and silly to design your service around handing out /64s to people and then you have to redesign it when demand for multiple subnets come around. Design it around /56 to begin with, and you will have solved the problem for the future, not just for now.
Then tell RIR's to quit insisting that /56's have SWIP's. They can't very well be dynamic in nature via PD if they are being SWIP'd.
Until then, /60 sounds fine. Allows higher capacity per /48 on a node and will give most customers more than they will ever use.
Then tell RIR's to quit insisting that /56's have SWIP's. They can't
very well be dynamic in nature via PD if they are being SWIP'd.
I believe this is not the case with RIPE, you'll only need to register
assignments that are larger than /48 in their database. See ripe-466
section 5.5.
Then tell RIR's to quit insisting that /56's have SWIP's. They can't very well be dynamic in nature via PD if they are being SWIP'd.
I never heard of this requirement before, but I am not in the ARIN region. There is no technical reason why you can't give the user the same /56 each time via PD, the same way some offer static IPs via DHCP.
Until then, /60 sounds fine. Allows higher capacity per /48 on a node and will give most customers more than they will ever use.
If the ISP sees (and has to hand out) the PD, some bean counter will put a price tag on it ("differential pricing").
If there is a price tag on it, nobody will pay the higher price, and everybody will put in a kludge to get by with one /64.
Think about it: That's exactly the reason why we got mired in the InterNAT.
Really, /56 for everyone is the only way back to an Internet.
Then tell RIR's to quit insisting that /56's have SWIP's. They can't
very well be dynamic in nature via PD if they are being SWIP'd.
If you are referring to section 6.5.4.4 of ARIN's NRPM, it does not
require you to use SWIP. It requires that an ISP have records which
allow ARIN to evaluate a request for a subsequent allocation. SWIP
would work if ARIN wanted potentially 10s of millions of /56s in its
whois database but it is not explicitly required and ARIN staff can
presumably advise on suitable alternatives.
There are about 11 million /56s per person on the planet, we're not about to run out. As there's nothing to conserve why follow the conservative strategy implied by shifting to longer netmasks? Why not stick with a regular scheme of escalating /64 -> /56 rather than an irregular one of /64 -> /62 -> /56?
And while the two bear some level of similarity, and the comparison makes a
great throw-away joke - the difference is in scale.
Orders of orders of orders of orders (give or take a few more orders) of
magnitude in difference.
Taking the usual liberty with the math - 4.3B maximum addresses, compared to
18BB or so network segments (each of which supports as many hosts as we
want).
Also, the quote was accurate - they were not about to run out.
That was more than several years down the road. Not bad for an experiment
that escaped the lab ...
Accounting for the aforementioned growth in the space, a run life of several
centuries for IPv6 should be sufficient.
The potential problem is segmentation. Start assigning meanings to
chunks of bits, like routing info or even customer type (mobile,
static, etc) or geography, and the bits can get used up pretty
quickly. Or put another way the address space becomes sparsely
populated but inflexible.
I know, "don't do that", well, when they give you (for any "you") that
job be sure to send us a postcard...
Any resource which is cheap (free!) and seemingly plentiful will get
"abused", used in a way the engineers never intended (one word: spam!)
Hey, anyone want to buy an ipv6 prefix which spells out their last
name or company name when interpreted as UTF-8?! Q00l!
