Where to buy Internet IP addresses

Mailman List Mirror (Read Only)
1

Joe Greco wrote:
>> 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.
>
> How is it the ISP's router is able to handle this? Be specific.

I view with suspicion the notion that an ISP is going to take addressing
direction from their customers, willy-nilly.

You snipped two of the three paragraphs I was responding to. The reply
I made was not a response to the last sentence, which was all that you
quoted, and so you may be confused about what I meant.

I was talking the other direction.

Internet routes a prefix to the ISP.

ISP routes a (smaller) prefix to the access concentrator.

Access concentrator routes a (smaller) prefix to the customer.

Now, the question is, if you're sending all these prefix requests up to
the ISP's router, why is *that* device able to cope with it, and why is
the CPE device *not* able to cope with it?

> Now explain why that can't be made to work at the CPE level.

Home devices chain with NAT because that is the scheme most likely to
work well enough by default 99% of the time out of the box, without
requiring ANY upstream cooperation.

Home devices that work out of the box for the common usage scenarios
generate profit, those that dont generate loss.

Again, since I think you misunderstood my earlier question, I don't think
my opinion was different than that.

Throwing out any real world implementations, for the sake of a clean slate
to see what "makes sense," let's sketch.

You have an ISP network, with a large amount of space available, and a
lesser amount of space dedicated to the POP.

You have a customer network, assumed to live within some customer
delegation.

So what we want is something that can intelligently handle delegation
in an automatic fashion, which probably includes configurable settings
to request/register delegations upstream, and to accept/manage them
downstream. There's no reason that this shouldn't be basic router
capabilities.

... JG

2

Joe Greco wrote:

Now, the question is, if you're sending all these prefix requests up to
the ISP's router, why is *that* device able to cope with it, and why is
the CPE device *not* able to cope with it?

The CPE cannot cope with it due to lack of a chaining standard and the lack of customer understanding of configuring a router. An ISP, as currently designed will manually assign prefix lengths and how they are handed out at each layer of the network. A home user should not be expected to understand this level of complexity. A CPE would have to be told HOW to divide it's variably received prefix to assign it's own networks and then issue prefixes to other routers behind it.

What is missing, unless I've missed a protocol (which is always possible), is an automated way for a CPE to assign it's networks, pass other networks out to downstream routers in an on-need basis. I say on-need, as there may be 3 routers directly behind the CPE and each of those may get additional routers and so on and so forth. A presumption could be made that route efficiency is not necessary at this level. ie, would it be practical or expected that an automatically configured network support > 100 routes or whatever a CPE can normally handle?

Of course, if this support is built at a CPE level, there's no reason the protocol can't be extended and supported at the ISP level as well for those who wish to utilize it. An ISP, would of course prefer prefix aggregation and controls to set minimum and maximum aggregate space for a customer.

You have an ISP network, with a large amount of space available, and a
lesser amount of space dedicated to the POP.

This setup in the ISP network is handled by hopefully clueful engineers and probably not automatically assigned by some cool protocol that routers speak (which would be cool, though, even if impractical).

So what we want is something that can intelligently handle delegation
in an automatic fashion, which probably includes configurable settings
to request/register delegations upstream, and to accept/manage them
downstream. There's no reason that this shouldn't be basic router
capabilities.

For the home router, I believe that this is mandatory if we wish to continue to allow self configuring networks for home users. A little extended logic and it can also be useful in larger networks, possibly even to the point of an enterprise network able to completely number itself (including renumbering itself as necessary).

Jack

3

Why wouldn't DHCPv6-PD work within the home as well as between the ISP and the home?

I see little reason why the main home gateway can't get a /56 from the ISP, and then hand out /62 (or whatever) to any routers within the home that asks for PD?

4

Mikael Abrahamsson wrote:

Why wouldn't DHCPv6-PD work within the home as well as between the ISP and the home?

DHCPv6-PD requires manual configuration.

I see little reason why the main home gateway can't get a /56 from the ISP, and then hand out /62 (or whatever) to any routers within the home that asks for PD?

Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that?

What if the ISP only gave a /60?

The problem with automatic arbitrary splitting of a prefix into smaller prefixes is that the entire topology is unknown. In such a case, bidirectional communication is useful, as is multiple prefix assignments to a single node generated from chaining DHCPv6-PD requests.

PD is not designed for multiple stage delegations without manual configuration for each stage.

Even the PD clients I tried on linux failed horribly in how they assigned a prefix to the interfaces. One of them just took the prefix length and divided it by the number of interfaces. Another, which I ended up using allowed you to set the bits to use as a subnet, but that meant you had to know the length from the ISP, and then the desired length on each of the interfaces to set the appropriate SLA (ie, I couldn't tell it I want a /64 on the interface, but instead had to tell it the SLA is 4 bits, which from a /60 would give a /64, but if I received a /56 it would break and have to be changed to 8 bits).

-Jack

5

DHCPv6-PD requires manual configuration.

Are you sure? Isn't it just that the current implementations do?

Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that?

What if the ISP only gave a /60?

Guess someone needs to write a draft with BCP regarding this, or perhaps extend the protocol to include that the requestor can ask for a preferred size (or do multiple /64 PDs).

PD is not designed for multiple stage delegations without manual configuration for each stage.

I see no problem with sane defaults solving that problem.

Now, if every ISP now adhered to handing out at least a /56 to each home, sane defaults could be created. If each ISP does it its own way, sane defaults won't work.

So just hand out a /56 or /48 and be done with it. Your idea of chained /64 doesn't really solve anything that couldn't be solved with a /64 default PD handout in the home gateway as far as I can see it?

6

Sure, but how does the router know it needs to hand out a /62? Then what
about the router after that? Does it hand out a /61? then the router behind
that?

In IA_NA's, there is a (undocumented in RFC 3315) convention to permit
a client to supply an IAADDR with a zeroed address. This convention
allows the client to supply preferred and valid lifetime hints without
knowing a specific address it would like.

I see no reason why a similar convention can't take root here; the
bottom-most client supplies an IAPREFIX in its IA_PD with a zeroed
network number, and the desired prefix length (suppose: /64 for its
one downstream interface). The next hop combines the sum total of
bitspaces required by its clients and presents a suitable requested
size upstream (with memory, and resizing/renumbering as you go).

What if the ISP only gave a /60?

Then someone gets a STATUS_NoAddrsAvail.

7

Sorry for the top post, but as a crazy thought here, why not throw out an RA, and if answered, go into transparent bridge mode? Let the sophisticated users who want routed behavior override it manually.

Jack Bates wrote:

8

Customer premise gear has a 'front side' and a 'back side', and it is
already well ingrained behaviour for 'back-to-back port chaining' to
create a single large bridged network in the home. What is the
customer's anticipated result from front-to-back chaining?

That seems much more reliable a hint to me than conditional behaviour.

DHCPv6 PD is applicable to the ISP customer premise. DHCPv6 PD
'chaining' however is probably only applicable in some promised future
where there are alternative home network medias to Ethernet, or to the
Enterprise where the boundaries drawn in broadcast domains are
administrative in nature and not technical (but still, all automated).

9

Jack Bates wrote:

Mikael Abrahamsson wrote:

Why wouldn't DHCPv6-PD work within the home as well as between the ISP and the home?

DHCPv6-PD requires manual configuration.

It doesn't need to; that's just a flaw in current implementations.

I see little reason why the main home gateway can't get a /56 from the ISP, and then hand out /62 (or whatever) to any routers within the home that asks for PD?

Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that?

What if the ISP only gave a /60?

I think some folks are getting the model wrong. Each router requests from its upstream router the delegation of a /64 for each downstream link and inserts the appropriate route when a response arrives. If it receives a PD request on its downstream interface, it forwards it upstream; when the reply comes back, it inserts the appropriate route and forwards the reply to the requester. Presto, a non-geek user can chain as many CPE devices as desired and they automagically configure themselves.

(The ISP who's serving all these requests _could_ preallocate a /48 or /56 per customer, which might make aggregation in the PE router easier, or they could just have a gigantic pool per PE router and hand out as many /64s as required to each customer, which would [unnecessarily, IMHO] conserve address space.)

However, as interesting as this may be, it's not particularly useful to discuss how consumer ISPs _might_ do DHCPv6 PD when none of them have shown much interest in providing any IPv6 connectivity at all and many are blocking (through mandatory NAT) even 6to4. And, until the eyeballs can speak IPv6, the content isn't going to speak it either...

S

10

What you really want to avoid is to have customer A's home network
accidentally bridged to customer B's. L3 isolation of L2 domains helps.

  - Alain.

11

David W. Hankins wrote:

Sorry for the top post, but as a crazy thought here, why not throw out an RA, and if answered, go into transparent bridge mode? Let the sophisticated users who want routed behavior override it manually.

Customer premise gear has a 'front side' and a 'back side',

I presume by front you mean wan and back you mean lan?

  and it is

already well ingrained behaviour for 'back-to-back port chaining' to
create a single large bridged network in the home.

Really? What CPE?

My topology at home is

motorolla dsl modem[1]->cisco 1841->catalyst 2924->wireless router->clients

The connection between the modem and router is a routed connection. The default configuration of the Linksys kit I have seen is routed. I had to change it to operate as a bridge (a one click option in the gui), and turn off the local DHCP server to make a flat wired/wireless network.

Otherwise it insists on being a router.

[1]
(It would appear that SBC recently changed their network to only allow their CPE with it's very limited configuration options. It's routed. Public IP on the WAN and a fixed private IP (192.168.1.254). It hands out 1 private DHCP address (192.168.1.64)

  What is the

customer's anticipated result from front-to-back chaining?

I'm not sure how many people do this. Many people have one integrated device hanging off their DSL modem. They then purchase wireless extenders to increase the reach. This is what I overhear being recommend by Frys and BestBuy sales folks, and it seems to work well.

I don't know how many will do it in the future. I imagine that vendors will just make beefer wireless routers to handle increased load. They already have different models and software feature sets for "high end gamers".

12

Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that?

For now: Reserve a /64 for your own allocations (SAA), then hand out half of what you have (i.e., of a /56 for the first CPE, so a /57) to the first asker, then a /58, then a /59 etc. The first asker (nested CPE) has a /57, reserves a /64 for itself (SAA), hands out a /58 to its first child (double-nested CPE), then a /59.
This algorithm restricts width plus depth to 8 (64 - 56), which is probably fine for most residential applications.

The probabilistic aspect (FCFS) may cause you cognitive dissonance, but little technical problem.
(Something that could be said about many of the "I grew up on IPv4 so I don't understand IPv6" postings here.)

What if the ISP only gave a /60?

Don't do that then!
(jargondb.org)

Really, /56 for everyone is the only way back to an Internet.

Gruesse, Carsten

13

Really, /56 for everyone is the only way back to an Internet.

Sorry, I don't see why /56 is qualitatively different to a /60.

Honest question - what's the difference?

Gruesse, Carsten

Gruesse, K.

14

Because more is more, and it makes it less likely that people will start to invent silly solutions to problems that do not really exist. With a /56, I can't really imagine this being not enough for 99.9% of households in 10 years, whereas I CAN imagine a household that needs more than 16 subnetworks, plus the PD model described in an earlier email makes a /56 more suited for chaining.

We have no address shortage, there is little good to come out of trying to use as few IPv6 addresses as possible by means of constraints that are not necessary (let's be "wasteful" the first 50-100 years and "waste" the first /3, then we can look into if this is a problem or not).

15

OK, I'm convinced :slight_smile:

Thanks, K.

16

Some times ago, i would say 6 or 7 years, there was a BoF proposition at IETF to deal with such issue.
Work areas were to propagate routing mesh configuration information and automatic assignment of subnet prefixes to links.
There were quite a lot of persons interested in such issues and some drafts were proposed. The name of the BoF was zerouter. Unfortunately, the working group was not created despite some real interest.

David

17

Carsten Bormann wrote:

For now: Reserve a /64 for your own allocations (SAA), then hand out half of what you have (i.e., of a /56 for the first CPE, so a /57) to the first asker, then a /58, then a /59 etc. The first asker (nested CPE) has a /57, reserves a /64 for itself (SAA), hands out a /58 to its first child (double-nested CPE), then a /59.
This algorithm restricts width plus depth to 8 (64 - 56), which is probably fine for most residential applications.

This makes a lot of assumptions that may not hold true and restricts home devices to treating IPv6 similar to how they treat IPv4. It's not scalable and it doesn't promote usage of multiple segments per device.

The restriction is actually 6 if you make a more sane assumption of /61 per device and not /64. Standard CPE's can support multiple wireless networks and Ethernet segments. An ISP might divide up in a provided CPE, for example, wireless, data, voice, and video (which still needs unicast in addition to multicast). The netgear I configured last night for a customer supports 4 wireless networks plus ethernet.

The probabilistic aspect (FCFS) may cause you cognitive dissonance, but little technical problem.
(Something that could be said about many of the "I grew up on IPv4 so I don't understand IPv6" postings here.)

I have little trouble with understanding IPv6, but I do have issues with the current state of it both in standards and in implementations. FCFS only works if home routers continue to work similar to the way they do.

What if the ISP only gave a /60?

Don't do that then!
(jargondb.org)

Really, /56 for everyone is the only way back to an Internet.

See, that's where we disagree. Better standards is the only way back to the Internet. Solving all problems from end to end in diverse networks is the way back to the Internet. /56 is arbitrary. Making assumptions about how a network will be restricts the Internet.

Jack

18

Sure!

(You are preaching to the choir here.)

While we are still on the way there, we just:
1) Shouldn't waste time reinventing decisions that are a done deal (say, EUI-64 in SAA).
2) Shouldn't use the lack of our favorite feature as an excuse to do nothing (or worse, to dig the NAT hole deeper).
3) Shouldn't practice denial, but plan for at least a /56 for every customer relationship.

Really, /56 for everyone is the only way back to an Internet.

Gruesse, Carsten

(This is my last message on this subject.)