ISP DHCPv6 and /48

Mailman List Mirror (Read Only)
1

Hello,

Let me introduce another first world problem. We use DHCPv4 to assign each
user a IPv4 /32 and DHCPv6-PD to assign a IPv6 /128 WAN plus a /48 prefix.
All good.

However we are an ISP where the customer chooses his own CPE. We just ship
a modem/mediaconverter/ONU with one ethernet port. The customer is expected
to plug his home router in here.

However sometimes we have a customer that wants to buy an extra IPv4
address. We are happy to sell him that. Now he has two (or more) IPv4
addresses. Turns out most of these customers are not configuring the extra
IPv4 addresses on a single home router (most CPEs probably can not handle
multiple WAN addresses anyway). Instead these people put in a switch and
then have multiple devices, each with one IPv4.

A typical setup is a home router (CPE) plus a server, or they might have
some VPN device forced on them by their employeers or they might simply be
sharing the internet connection with the neighbour (we allow that).

However we are forbidden to deliver more than one /48. What to do?

Currently we will deliver exactly one /48 to one device and just say sorry,
you will have to figure out how to get IPv6 on your other devices. The
experience is that 100% of the guys then simply do not have any IPv6 on the
other devices. Figuring out how to route a slice of that /48 is too much
for even most technical minded customers.

Would you deliver say /52 prefixes instead but reserve /48, so the DHCP
server has the option to deliver up to 16x /52 per customer?

Regards,

Baldur

2

Hello,

Let me introduce another first world problem. We use DHCPv4 to assign each
user a IPv4 /32 and DHCPv6-PD to assign a IPv6 /128 WAN plus a /48 prefix.
All good.

However we are an ISP where the customer chooses his own CPE. We just ship
a modem/mediaconverter/ONU with one ethernet port. The customer is expected
to plug his home router in here.

However sometimes we have a customer that wants to buy an extra IPv4
address. We are happy to sell him that. Now he has two (or more) IPv4
addresses. Turns out most of these customers are not configuring the extra
IPv4 addresses on a single home router (most CPEs probably can not handle
multiple WAN addresses anyway). Instead these people put in a switch and
then have multiple devices, each with one IPv4.

A typical setup is a home router (CPE) plus a server, or they might have
some VPN device forced on them by their employeers or they might simply be
sharing the internet connection with the neighbour (we allow that).

However we are forbidden to deliver more than one /48. What to do?

Who is forbidding you? Not the IETF. Not the RIRs.

Currently we will deliver exactly one /48 to one device and just say sorry,
you will have to figure out how to get IPv6 on your other devices. The
experience is that 100% of the guys then simply do not have any IPv6 on the
other devices. Figuring out how to route a slice of that /48 is too much
for even most technical minded customers.

Would you deliver say /52 prefixes instead but reserve /48, so the DHCP
server has the option to deliver up to 16x /52 per customer?

Regards,

Baldur

Just have them deploy a IPv6 router and configure it to brigde IPv4.
As far as the existing clients are concerned they will just be on
a LAN with a /64 out of the /48 and IPv4.

A cheap linux / *bsd box will do this.

3

Who is forbidding you? Not the IETF. Not the RIRs.

RIPE policy requires me to send in justification for review for any
allocations larger than a /48. For a $35/month contract? Forget it, not
going to happen. Plus it would be rejected.

Just have them deploy a IPv6 router and configure it to brigde IPv4.

As far as the existing clients are concerned they will just be on
a LAN with a /64 out of the /48 and IPv4.

A cheap linux / *bsd box will do this.

My customer support can not instruct users to get a cheap linux box. So
what happens instead is that people will say ok, screw IPv6. Is that a
problem or not?

We designed the system believing this was not an actual problem. We
expected people to put in a router in front, and then be able to split up
their /48 from there. But reality is that it didn't work out that way.

People want to put in a switch in front of multiple routers. That is the
setup the common man understands how to configure. In part because it is
actually hard to do it any other way if you want one public IPv4 per router
and the routers are understood to be the common CPE everyone are buying at
the hardware store.

It is just sad this is not compatible with the advice we are getting on
NANOG to hand out /48. Because we can only do one /48. There is no
justification that RIPE would accept to hand out more than a /48 to a
residential end user, where the only issue is that the end user does not
know how to split up his /48.

If we did /56 (or /52) we could assign the full /48 in regards to RIPE but
have our DHCPv6 server hand it out in pieces such as a /56 at a time. This
would work for the users. But it is not so popular among some people here
on NANOG. We would be limiting the user to a /56 if he only has a single
CPE.

Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there
is a provision such that the user CPE could give a hint of how much space
is want, but no, it doesn't work. The user CPE does not understand this
issue either and has no information that could make it the smart place to
do the decision. Plus which of the multiple CPEs would be in control?

Maybe if the CPEs would go back and ask for more address space, if what
they initially got ran out. But DHCPv6-PD does not really have a way to do
that. In any case no CPE implements any such thing.

Or maybe it is the RIPE policy that is the problem? I am not sure if the
problem is any different for the other RIRs.

Regards,

Baldur

4

Baldur -

    I am not aware of the RIPE practices with respect to IPv6 end-user assignments,
    but in the ARIN region, ISPs/LIR's make assignments to end users based on similar
    practices that the community adopted for ARIN’s end-user assignments. To my
    knowledge, ARIN does not review these ISP IPv6 end-user assignments (except
    after the fact and in aggregate if an ISP were to come to ARIN seeking an additional
    IPv6 block due to utilization of the previous.)

    Differences in policies between the regions is not necessarily any indication of a
    “problem”; it can just as easily be an appropriate reflection of different underlying
    circumstances.

/John

John Curran
President and CEO
ARIN

5

On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl"

Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there
is a provision such that the user CPE could give a hint of how much space
is want, but no, it doesn't work.

WG] Sorry, [citation needed]. We are using DHCPv6-PD that listens for and
responds properly to hints in production for millions of customers. Many
of the cheap plastic routers are even smart enough to stand up their own
DHCPv6 server so that they can do PD to give out /64s to subtended devices
or split out the /56 or /60 that they were given to their WAN, LAN, and
Guestnet so that each has its own subnet. Now you may have to specify a
list of devices that properly support PD such that you know they will work
with this configuration of multiple routers behind a switch, but requiring
your customers to use a device that supports your implementation of a
feature that they want isn't really that much of an imposition on them.
You wouldn't blame the protocol when IPv6 doesn't work for your customers
who use a device that doesn't support IPv6, would you?

The user CPE does not understand this
issue either and has no information that could make it the smart place to
do the decision. Plus which of the multiple CPEs would be in control?

WG] IETF Homenet WG is currently chewing on the problem of multiple CPEs
in an unmanaged environment. It's not an easy problem if you have to
design it so that it works automagically no matter how strangely it's
connected together. You may want to check it out:
http://datatracker.ietf.org/wg/homenet/charter/

Maybe if the CPEs would go back and ask for more address space, if what
they initially got ran out. But DHCPv6-PD does not really have a way to do
that. In any case no CPE implements any such thing.

WG] also not exactly true. No, most CPE won't do it automatically, but
DHCPv6 can do it. Release existing prefix, request new prefix with bigger
hint. Depending on DHCP server policy, you might even be able to do it in
the opposite order (make before break) since you can have multiple
prefixes. My hunch is that on most residential broadband setups, it's not
likely to be hitless, and most cheap plastic routers can probably only do
it via a reboot after you reconfigure it to ask for more space in the
hint, but it's doable. See above recommendation for homenet if you want it
to be automatic.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.

6

My solution would be to tell them if they want more than 1 IPv4 /32, they need a router.
Then route a prefix of appropriate size to their router.

/48 for IPv6 as you are doing, and /n for IPv4.

They want 2 addresses, give them a /30. 3-6, /29; 7-14, /28, etc.

Seems pretty straight forward to me.

Owen

7

The RIPE policy https://www.ripe.net/publications/docs/ripe-641 section
5.4.2 states:

"When a single End Site requires an assignment shorter than a /48, it must
request the assignment with documentation or materials that justify the
request. Requests for multiple or additional prefixes exceeding a /48
assignment for a single End Site will be processed and reviewed (i.e.,
evaluation of justification) at the RIR/NIR level".

For a business user we might go through that process. But my question is
about ordinary residential end users where we want to have as little manual
processing as possible. Therefore we read the above as "do not do that".

We do not entirely disagree with the policy either. I am more looking for a
technical solution, that allows us to deliver a /48 yet still be as
flexible as possible to the users wants and needs.

Regards,

Baldur

8

On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl"

>Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there
>is a provision such that the user CPE could give a hint of how much space
>is want, but no, it doesn't work.
WG] Sorry, [citation needed]. We are using DHCPv6-PD that listens for and
responds properly to hints in production for millions of customers.

Thank you for your insight. I went back and checked if I overlooked
something. I managed to make a sample of 136 unique CPEs (not unique
models, just unique devices). The sample was chosen so none of those had
been previously provisioned with IPv6. Zero of them provided hints. It will
look like this:

(IA_PD IAID:1 T1:0 T2:0)

or

(IA_PD IAID:660514110 T1:3600 T2:5400)

The values differ but none include hints. CPEs that have previously been
configured will provide hints, but that is just our own prefix length that
is returned back. Eg.:

(IA_PD IAID:1 T1:300 T2:600 (IA_PD-prefix 2a00:7660:8ca::/48 pltime:600
vltime:600))

You wouldn't blame the protocol when IPv6 doesn't work for your customers

who use a device that doesn't support IPv6, would you?

No but I believe the RFCs lack useful directions in how CPEs and DHCP
servers should use hints. My sample shows that the popular CPEs used by our
users simply do not even attempt to use this mechanism.

>The user CPE does not understand this
>issue either and has no information that could make it the smart place to
>do the decision. Plus which of the multiple CPEs would be in control?
WG] IETF Homenet WG is currently chewing on the problem of multiple CPEs
in an unmanaged environment. It's not an easy problem if you have to
design it so that it works automagically no matter how strangely it's
connected together. You may want to check it out:
Home Networking (homenet)

Thank you for the link. It is good to see that someone is working on the
issue.

>
>Maybe if the CPEs would go back and ask for more address space, if what
>they initially got ran out. But DHCPv6-PD does not really have a way to do
>that. In any case no CPE implements any such thing.

WG] also not exactly true. No, most CPE won't do it automatically, but
DHCPv6 can do it. Release existing prefix, request new prefix with bigger
hint. Depending on DHCP server policy, you might even be able to do it in
the opposite order (make before break) since you can have multiple
prefixes. My hunch is that on most residential broadband setups, it's not
likely to be hitless, and most cheap plastic routers can probably only do
it via a reboot after you reconfigure it to ask for more space in the
hint, but it's doable. See above recommendation for homenet if you want it
to be automatic.

Actually DHCPv6 does not allow you to request additional prefixes.

Section 12.2 from RFC 3633:

" A delegating router examines the prefix(es) identified in IA_PD
   Prefix options (in an IA_PD option) in Renew and Rebind messages and
   responds according to the current status of the prefix(es). The
   delegating router returns IA_PD Prefix options (within an IA_PD
   option) with updated lifetimes for each valid prefix in the message
   from the requesting router. * If the delegating router finds that any*
* of the prefixes are not in the requesting router's binding entry, the*
* delegating router returns the prefix to the requesting router with*
* lifetimes of 0.*
"

If you attempt that, you will just get the prefix back with lifetime zero.

So the only way is to release the binding and start over. That does not
feel like a real solution and is also not anything likely implemented.

I am looking for solutions that I can implement today. It appears the right
thing to do is to take 4 bits from the user and use at the ISP level. He is
still getting his /48 allocation, but we used 4 bits for the first layer of
delegating routers. He will see this as multiple sequential /52 delegations.

95% of the users will only connect one CPE and will only be able to use /52
worth of space. But really, we have not seen any actual use case presented
where this is a problem.

I believe we will be providing a better service by delivering /52 by
default and then allow multiple DHCP bindings, than to do a single /48 and
refuse multiple bindings.

We could implement respecting /48 hints from a CPE, such that a user can
override the /52 default behavior by asking his CPE to request a /48. It is
just that my sample indicates that most CPEs may not have this option.

Regards,

Baldur

9

Well you don't know if it is a single end site or two sharing a common
uplink.

You could just configure them both for /49's from the /48 and let them
worry about ip6.arpa sub delegation. They should be getting a /128
regardless.

That said this really isn't your problem. It is their problem.

10

>That said this really isn't your problem. It is their problem.

Marc,

Your response surprises me a bit. I wish more ISP would consider their
customer's use cases more thoroughly and aim to address them as best as
possible. Regional differences in expectations are reasonable and provide a
good pool of use cases to examine.

Agreed there are a number of ways to resolve this issue and address the use
case, however.

Oliver

Mark Andrews, ISC