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
In message <CAPkb-7C5LX0QwYpFq5QYyvFaHSbQfvW7tkHsuezvqDtMVYCY_w@mail.gmail.com> , Baldur Norddahl writes:
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10 July 2015 at 12:09, Mark Andrews <marka@isc.org> wrote:
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
On Jul 10, 2015, at 6:34 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
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 …. 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.
... 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.
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
On 10 July 2015 at 13:30, John Curran <jcurran@istaff.org> wrote:
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.
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
In message <CAPkb-7Aice0dSgcc+W7c7R3OSWP_N_sn8m0n306mJx1bGC36Qw@mail.gmail.com> , Baldur Norddahl writes:
On 10 July 2015 at 13:30, John Curran <jcurran@istaff.org> wrote:
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 base= d on similar practices that the community adopted for ARIN=E2=80=99s end-user assi= gnments. 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 seekin= g an additional IPv6 block due to utilization of the previous.)
Differences in policies between the regions is not necessarily any indication of a =E2=80=9Cproblem=E2=80=9D; it can just as easily be an appropriate re= flection of different underlying circumstances.
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
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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
1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- :o@>
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
On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl" <nanog-bounces@nanog.org on behalf of baldur.norddahl@gmail.com> wrote: 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. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On 10 July 2015 at 15:21, George, Wes <wesley.george@twcable.com> wrote:
On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl" <nanog-bounces@nanog.org on behalf of baldur.norddahl@gmail.com> wrote:
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: http://datatracker.ietf.org/wg/homenet/charter/
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
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
On Jul 10, 2015, at 02:26 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
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
participants (6)
-
Baldur Norddahl -
George, Wes -
John Curran -
Mark Andrews -
Oliver O'Boyle -
Owen DeLong