Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt

[Brian E Carpenter <[e-mail]>]

Owen,
On 2018-08-31 06:34, Owen DeLong wrote:
> 
> 
>> On Aug 29, 2018, at 15:29 , Brian E Carpenter <[e-mail]> wrote:
>>
>> Barbara,
>> On 2018-08-30 00:11, STARK, BARBARA H wrote:
>>>> My understanding, no hats and potentially incorrect, is that any ISP I know of
>>>> will respond to a DHCPv6 IA_PD with a prefix at least as large as requested,
>>>> up to /48.
>>>
>>> I don't think this is correct. Of course, any provider using 6rd won't respond to DHCPv6 at all. I'm aware of a lot of 6rd out there.
>>> Wireless LTE providers don't tend to support DHCPv6, either. The /64 advertised by the RA in an LTE environment is all the LTE UE will get. That includes the case where the LTE UE is supporting a fixed wireless installation.
>>> For ISPs that support DHCPv6, it may or may not be the case. I've heard several say they do, but I'm not aware of a survey of all ISPs that would tell me how prevalent it is.
> 
> I can guarantee you that it’s false in a big way (unfortunately). Comcast’s victims (or customers, depending on your perspective), for example, cannot get a /48 no matter what.
> 
> IIRC, they will allow a business customer to get up to a /56 and residential customers are limited to a /60.
> 
> I believe they have or are in the process of resolving issues they previously had where if you requested larger than they would allow, they simply didn’t give you anything at all… Not even a DENIED response.
> 
> I wish they would fix this. When I discussed the matter last with JJMB, his response was “we don’t feel that’s reasonable… If we were to do that, we’d have to ask ARIN for a /12.”
> 
> My response was “duh!! You guys probably should have a /12. It’s permitted under existing policy. So what’s the issue?” He simply shook his head and walked away.
> 
> I’m guessing this will eventually be like Verizon’s resistance to routing /48s. The v4think will eventually get sorted out, but likely persist for some time first.
> 
>>> BTW, I disagree with the abstract's statement that the "policy should reflect that assignment of a single subnet is never appropriate." I do not believe this takes into consideration the fact that it would be tremendously expensive for some ISPs to replace their current equipment when those current equipment vendors are being slow about supporting certain features. Cost is always an appropriate consideration. 
>>
>> I disagree. Yes, of course cost is always a consideration, but that doesn't
>> make a lower case "should" inappropriate.
> 
> I feel that there are actually cases where single-subnet assignment is perfectly reasonable. They are limited and should be determined by the customer, not the service provider, IMHO, but I also believe that all of these decisions really are outside the purview of the IETF. The IETF should be mandating that the standards for the equipment and the protocol enable the service provider and the customer to handle multiple subnets. Specifying operational behavior beyond that which is necessary to enable the needed functionality is scope creep that we should try to avoid.
> 
>>> It also does not take into account CE routers that only request a single /64. 
>>
>> That's irrelevant. The customer might have bought such a router, but the
>> next customer along might have bought a full homenet-supporting CE.
> 
> That’s irrelevant. The protocol should enable the service provider and customer to support either environment.

That's what I meant. If some customers only request a /64, and others request
a /48 (because they happened to buy different CE boxes), either should work.

> We can make operational best practice recommendations to offer more than one subnet, but beyond that, we’re looking at the IETF putting its nose where it doesn’t belong, IMHO.

I think the IETF can say "/56 is inadequate for some customers. /48 is adequate
for most customers." Of course, we can't dictate terms to ISPs, and neither
can the RIRs.

>>> I think it's inappropriate for IETF to be trying to dictate what is and isn't "appropriate". Recommending a best current practice is fine. But that's not the same as saying something is "never appropriate".
>>
>> Let's say "never recommended" then.
> 
> Meh… I could live with that.

OK then ;-)

Regards
   Brian

> 
> Owen
> 
>