[IPv6]Re: Working Group Last Call for <draft-ietf-6man-pio-pflag>

[David Farmer <[e-mail]>]

I'm not willing to go that far. I would simply like the document to
acknowledge that other mechanisms are necessary for it to work as intended.

Ole is correct that other definitions of the P flag could stand
independently, but this definition does not. We don't need to change the
definition if we can acknowledge that other mechanisms are necessary for it
to work as intended.

Thanks

On Fri, Jul 12, 2024 at 8:07 AM Ole Trøan <[e-mail]> wrote:

> I think we’re back to the fact that the P-flag is trying to do too many
> different things.
>
> O.
>
> On 12 Jul 2024, at 13:29, Ted Lemon <[e-mail]> wrote:
>
> 
> I’m really failing to grasp what you are concerned about here, David. It
> sounds like Lorenzo is saying we’ll only turn on pd-per-device if the p
> flag is set, and you’re saying that there will be a network operator out
> there somewhere who will set it when they shouldn’t in order to get
> behavior they want.
>
> What is the behavior that they would want that they would only get if they
> set the p flag?
>
> Op vr 12 jul 2024 om 03:39 schreef David Farmer <[e-mail]>
>
>> I guess what I'm trying to say is more than just the document doesn't
>> intend for the P flag to be the only mechanism to signal the use of the
>> PD-per-device. As written, the other mechanisms are required to exist. If
>> they do not exist, then a perverse incentive will be created to set the P
>> flag, regardless if enough prefixes are available to support all devices on
>> a network. Since that is an integral and critical part of the current
>> definition, I cannot support the current definition of the P flag unless it
>> is also clear that those other mechanisms are required to exist.
>>
>> Without the existence of other mechanisms, the P flag by itself is a bad
>> idea that I cannot support as written.
>>
>> Thanks
>>
>>
>> On Fri, Jul 12, 2024 at 00:34 Lorenzo Colitti <[e-mail]> wrote:
>>
>>> It was not our intention that the P flag be required for tethering; the
>>> intent of the document was to signal pd-per-device.
>>>
>>> I would imagine that any device that supports tethering  would allow
>>> tethering regardless of whether the P flag is set or not. If the P bit is
>>> set, tethered devices would be numbered from the delegated prefix, and if
>>> it's not, tethered devices would be IPv4-only (or would use something else
>>> such as ND proxying).
>>>
>>> That said, I'm not sure it makes sense for devices to ask for a prefix
>>> when the user turns on tethering in home networks, for example. Those
>>> networks also might end up running out of prefixes. So I can see a use for
>>> the E bit.
>>>
>>> If we don't like the term tethering, then se can call it "occasional
>>> user-initiated network extension". But I agree that's only slightly more
>>> useful. For example, what's the difference between "user turns on
>>> tethering" and "user starts a hypervisor and boots VMs"?
>>>
>>> On Thu, 11 Jul 2024, 21:04 Ted Lemon, <[e-mail]> wrote:
>>>
>>>> Okay, I sort of think I get where you are coming from on tethering. I
>>>> agree with you that the p flag shouldn’t be required for a device to turn
>>>> on tethering when the user configures it.
>>>>
>>>> But I don’t think the draft says that. Lorenzo, was it your intention
>>>> that the p flag be required for tethering?
>>>>
>>>> Op do 11 jul 2024 om 14:29 schreef David Farmer <[e-mail]>
>>>>
>>>>> SNAC routers doing 802.1x are a great starting point.
>>>>>
>>>>> Let me be a little more precise, I was thinking of IOT devices/things
>>>>> that have ethernet and/or WiFi interfaces. IOT devices with other media
>>>>> types probably behind SNAC routers, I'm much less concerned about.
>>>>>
>>>>> I’d add MUD is very interesting and passing the MUD URI through 802.1x
>>>>> would be a great answer. But if it is not available via 802.1x, I would
>>>>> still want it through LLDP or DHCP. I would even be happy with
>>>>> draft-ietf-dhc-addr-notification with the MUD URI DHCPv6 option.
>>>>>
>>>>> If most devices doing DHCPv6-PD do 802.1x on the upstream ethernet or
>>>>> WiFi interface that takes care of most of my DHCPv6 option argument.
>>>>>
>>>>> However, I'm not OK with only way to do tethering is with the P flag.
>>>>> As I said before, if the P flag is the only way to tether, that will cause
>>>>> networks that want tethering to turn on the P flag even if they don't have
>>>>> enough addresses for all potential devices. This will end badly for both
>>>>> the network and its users. We should not create a negative incentive like
>>>>> that.
>>>>>
>>>>> Devices, capable of PD-per-device also MUST attempt tethering if P=0
>>>>> and the M or O = 1.  I'd prefer to see such a requirement in this document
>>>>> to ensure hosts implementing the P flag also implement tethering based on
>>>>> the M or O flag.
>>>>>
>>>>> I can repeat how I think that can and should work. And provide text if
>>>>> you want.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Thu, Jul 11, 2024 at 12:21 Ted Lemon <[e-mail]> wrote:
>>>>>
>>>>>> Sorry, I think we're miscommunicating. You say you want to track what
>>>>>> sort of device is doing PD, and one example is a SNAC router. SNAC routers
>>>>>> are essentially infrastructure devices. They should be perfectly capable of
>>>>>> doing 802.1x. Or are you expecting random light bulbs to do PD-per-device?
>>>>>>
>>>>>> Anyway it feels like we are discussing a problem with a hammer that
>>>>>> needs a scalpel. Also, we aren't talking about the draft mentioned in the
>>>>>> subject line anymore. Would you be okay with the current draft proceeding
>>>>>> without solving the DHCP marking problem you're talking about?
>>>>>>
>>>>>> On Thu, Jul 11, 2024 at 1:12 PM David Farmer <[e-mail]> wrote:
>>>>>>
>>>>>>> If every IOT devevice did 802.1x, I’d be happy with that. However,
>>>>>>> that seems like a very tall order, and in my opinion very unlikely to
>>>>>>> happen. Especially consumer devices like TVs.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On Thu, Jul 11, 2024 at 07:43 Ted Lemon <[e-mail]> wrote:
>>>>>>>
>>>>>>>> I think support for MUD is generally pretty limited, but support
>>>>>>>> for providing similar information in shop would be too. Eg as an
>>>>>>>> implementer I have no incentive to do this work in DHCP. I’d like to
>>>>>>>> support MUD, although in practice I’m going to support whatever Matter
>>>>>>>> specifies because that’s where this work is currently being done. I’d
>>>>>>>> prefer that it be MUD.
>>>>>>>>
>>>>>>>> On devices, not speaking for anyone in particular, but just
>>>>>>>> reporting my impressions, we tend to be skeptical of sending anything at
>>>>>>>> all that can be used to fingerprint the device outside of two-way
>>>>>>>> authentication, so 802.1x is definitely the way to go there. Once you have
>>>>>>>> that, do you need DHCP?
>>>>>>>>
>>>>>>>> Op do 11 jul 2024 om 02:10 schreef David Farmer <[e-mail]>
>>>>>>>>
>>>>>>>>> Maybe for the IOT side of things, are SNAC routers going to
>>>>>>>>> support it? Does it support DHCPv6? All the examples I find are IPv4.
>>>>>>>>>
>>>>>>>>> Do Android, Windows, iOS, and Mac OS, support MUD? I get the
>>>>>>>>> impression they don’t because it is focused on IOT.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jul 10, 2024 at 21:17 Ted Lemon <[e-mail]> wrote:
>>>>>>>>>
>>>>>>>>>> This sounds like a job for MUD, not DHCP.
>>>>>>>>>>
>>>>>>>>>> Op wo 10 jul 2024 om 21:38 schreef David Farmer <[e-mail]>
>>>>>>>>>>
>>>>>>>>>>> Let me expand on our BYOD student experience. Students in our
>>>>>>>>>>> residence halls, about 15% of the student body, can access three (3)
>>>>>>>>>>> networks: two WiFi networks and a segregated wired network, providing GigE
>>>>>>>>>>> per pillow. About 85% of students live off-campus and can access only the
>>>>>>>>>>> two WiFi networks everywhere on campus. As you can see, most students use
>>>>>>>>>>> WiFi, but even in the residence halls, most access is by WiFi. Many of the
>>>>>>>>>>> GigE ports are rarely if ever, used.
>>>>>>>>>>>
>>>>>>>>>>> The two WiFi networks are segregated by type of
>>>>>>>>>>> authentication and primary function. eduroam is our primary user access
>>>>>>>>>>> network for laptops, smartphones, and tablets that support 802.1x auth. The
>>>>>>>>>>> other WiFi is the IOT network, which primarily supports consumer and
>>>>>>>>>>> entertainment devices that typically don't support 802.x auth. The IOT
>>>>>>>>>>> network supports per-user-PSK with MAC auth, meaning each student gets a
>>>>>>>>>>> unique PSK for their use, and they have to register the MAC addresses of
>>>>>>>>>>> their devices using their PSK. I want to apply a light policy and verify
>>>>>>>>>>> that the PD use cases come from the appropriate networks: PD-per-device or
>>>>>>>>>>> tethering from eduroam and SNAC routers from IOT, probably all three use
>>>>>>>>>>> cases from the wired network. Equally important is knowing the use cases
>>>>>>>>>>> for accounting and measurement purposes, which services and functions are
>>>>>>>>>>> being used, and correlating that with incidents and other information. When
>>>>>>>>>>> an incident involving a PD prefix occurs, knowing how it is being used
>>>>>>>>>>> could better inform the response to the incident.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 8, 2024 at 8:11 AM Ted Lemon <[e-mail]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I noticed that I didn't reply to this message earlier—sorry
>>>>>>>>>>>> about that. It was an unfortunate omission—you I think explained your
>>>>>>>>>>>> motivation here better than in other messages.
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jul 7, 2024 at 12:53 PM David Farmer <[e-mail]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Most large enterprises don’t have DHCPv6-PD enabled servers
>>>>>>>>>>>>> today, maybe we should consider what capabilities these large enterprises
>>>>>>>>>>>>> will want from these servers. I expect they will want to distinguish
>>>>>>>>>>>>> between all the use cases we are discussing. If they want to support PD-per
>>>>>>>>>>>>> device and set up a DHCPv6-PD server for that purpose, you seem to say they
>>>>>>>>>>>>> also MUST support RFC7084 and SNAC router use cases because that comes with
>>>>>>>>>>>>> setting up a DHCPv6 server.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I work for a large enterprise. We do not as far as I know offer
>>>>>>>>>>>> DHCPv6 PD service on our networks, but to be honest I haven't actually
>>>>>>>>>>>> checked, so I could be wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> I can say though that as far as I've noticed that specifically
>>>>>>>>>>>> on user-accessible networks, we do not differentiate between types of
>>>>>>>>>>>> devices outside of the PD use case, and my responses to your other messages
>>>>>>>>>>>> on this topic have been coming from a place of skepticism about whether
>>>>>>>>>>>> this is actually something anybody needs or wants. I have not yet
>>>>>>>>>>>> understood how this added complexity could be useful.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hopefully, the above will add more detail for you.
>>>>>>>>>>>
>>>>>>>>>>> You've said above that I'm saying that networks supporting PD
>>>>>>>>>>>> must support various use cases, but that's not what I'm saying at all. This
>>>>>>>>>>>> assumption that the network operator has any reason to want to know what
>>>>>>>>>>>> use case is being supported is what I am questioning. I am not saying that
>>>>>>>>>>>> "if the network operator supports PD, the network operator is required to
>>>>>>>>>>>> support tethering." I am saying that if the network operator supports PD on
>>>>>>>>>>>> networks to which users can connect their devices, then as a necessary
>>>>>>>>>>>> consequence, all the use cases we're talking about are supported. We don't
>>>>>>>>>>>> have a way to tell what the device is going to do with the delegated
>>>>>>>>>>>> prefix, and aside from address exhaustion attacks, we don't care. We've
>>>>>>>>>>>> gotten by fine for many years without needing to care, and nothing has
>>>>>>>>>>>> changed with respect to any of the use cases you mentioned.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Suppose you can't differentiate the different use cases from
>>>>>>>>>>> each other with something at the DHCP server, and there isn't any device
>>>>>>>>>>> authentication method to differentiate the different use cases, like with
>>>>>>>>>>> eduroam. In that case, the devices have to support 802.1x. Then, I have to
>>>>>>>>>>> treat all the use cases the same, which will be the most pessimistic
>>>>>>>>>>> assumption. Whereas if I knew it was an SNAC router, supporting mostly IOT
>>>>>>>>>>> devices, I could worry about IOT attack profiles and maybe worry a little
>>>>>>>>>>> less about non-IOT attack profiles. This is what I mean about
>>>>>>>>>>> differentiating between the use case and why I would like to at least log
>>>>>>>>>>> which use case is being used, if not put them in different pools, maybe
>>>>>>>>>>> even with different access controls.
>>>>>>>>>>>
>>>>>>>>>>> The reason we need a 'P' flag is that this is a /new/ use case
>>>>>>>>>>>> which has wildly different implications in terms of the number of prefixes
>>>>>>>>>>>> that might be delegated, and so for this use case, which is a new use case,
>>>>>>>>>>>> we actually do want to be able to differentiate, because it might increase
>>>>>>>>>>>> demand for prefixes hugely above what existing use cases call for. We
>>>>>>>>>>>> expect the demand for P-flag prefixes to dwarf the demands presented by the
>>>>>>>>>>>> other use cases.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I understand and support the P flag; those issues are valid. But
>>>>>>>>>>> that doesn't necessarily make the issues I'm bringing up less valid. Should
>>>>>>>>>>> I assume all devices requesting a prefix are PD-per-device and apply access
>>>>>>>>>>> control appropriate to laptops, smartphones, and tablets? I'd also like to
>>>>>>>>>>> have access controls appropriate for IOT devices when I know an SNAC router
>>>>>>>>>>> is requesting a prefix. However, I need to differentiate the use case on
>>>>>>>>>>> the DHCP server to do that.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> ===============================================
>>>>>>>>>>> David Farmer               Email:[e-mail]
>>>>>>>>>>> Networking & Telecommunication Services
>>>>>>>>>>> Office of Information Technology
>>>>>>>>>>> University of Minnesota
>>>>>>>>>>> 2218 University Ave SE
>>>>>>>>>>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>>>>>>>>>>>       Phone: [phone]
>>>>>>>>>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>>>>>>>>> ===============================================
>>>>>>>>>>>
>>>>>>>>>>

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================