Re: [v6ops] Implementation Status of PREF64

["STARK, BARBARA H" <[e-mail]>]

In-line, with <bhs2>.
Barbara

Ok, the IETF shouldn't pick N, I'm ok with that. But, does that mean you think it is inappropriate for host implementations to enforce some number of IPv6 addresses be available? Or, are you saying that is completely up to network operators?
<bhs2> My primary objection is to the suggestion that IETF should specify "N". Host devices (including malware and privacy-violating IP-enabled TVs that scan the local network and use microphones to listen to sounds inside the home, etc) will do whatever they want. I think a lot of the things host implementations do are inappropriate. Personally, I do think it's inappropriate for my DVRs, DVD player, oven, refrigerator, and TVs to have lots of GUA IPv6 addresses. This makes it really hard for me to track what devices are on my home network. But that's neither here nor there. This is IETF. I think for IETF to recommend "N" (because no matter how much a BCP might say "MUST", it's still only a recommendation) for all devices is highly inappropriate.</bhs2>
 I will note a few things;
 1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said that N>1.
<bhs2> For "general-purpose" devices, only.</bhs2>
2. In effect Android already enforces, N>1, by only supporting the self-assigned addressing model of SLAAC.
3. However, by not supporting a DHCPv6 client, Android doesn't support the managed-assignment addressing model of DHCPv6.
 In an effort to find a compromise that allows Android to support DHCPv6 and therefore the managed-assignment addressing model, I'm suggesting it is reasonable for DHCPv6 clients to require the availability of more than one IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo is at least open to discuss such a comprise.
<bhs2> Android is already allowed (by IETF, legally, etc - by pretty much everyone except Google) to support DHCPv6. IETF doesn't need to take any action, whatsoever, to "allow" Android to support DHCPv6. BTW, my Chromecast (which I'm guessing is not Android) has a single DHCPv6-assigned address. It seems to work just fine. But I wouldn't characterize it as general-purpose.</bhs2>
 However, it seems that some people are insisting that network operators should be able to assign one and only one IPv6 address per client. Personally, I think this argument is utterly futile, is creating a deadlock, and it is holding back the deployment of IPv6. However, this deadlock is not caused only by Android not supporting DHCPv6, but it is also caused by those that insist that assigning one and only one address is a valid IPv6 deployment strategy, and that network operators should have ultimate and unilateral control in this matter.
<bhs2> Why does my Chromecast need multiple IPv6 addresses assigned to it? And why is my assigning my Chromecast a single IPv6 address not a valid strategy? It sure makes it easy for me to see what my Chromecast is doing. I like being able to see what devices are doing inside my home network. Unlike some people in IETF, I don't think the Internet (or my LAN branch of it) is for host devices (to do whatever they want and dictate to people what the people are and aren't allowed to do wrt managing a home network). </bhs2>
I'm willing to concede that network operators need to allocate more than one IPv6 address per client.. Furthermore, I think it is very important that all major operating systems allow for both IPv6 address assignment models, self-assigned (SLAAC) and managed-assignment (DHCPv6).
 <bhs2> I agree. And all but one major OS already does.</bhs2>
I'm having visions of IETF becoming not unlike the Texas legislature in its desire to dictate "morality".
Barbara

Insisting the network operators have ultimate and unilateral control of this issue is equally dictating "morality".

<bhs> Just a few points:
- RFC7934 is scoped to "general-purpose end hosts" (which is not defined and therefore you can define the term any way that makes sense for you). RFC7934 is very specifically *not* scoped to all hosts.

Are all Android devices general-purpose? Probably not. However, the overwhelming majority are, at least by my understanding of the intent of RFC7934. So, it doesn't seem unreasonable to me for Android to treat all Android devices as general-purpose from a device implementation perspective. Therefore, I think RFC7934 applies, but more importantly the makers of Android seem to think it applies to their devices.

<bhs2> My husband's Nook eReader is an Android device. I wouldn't classify it as general-purpose. But I only let that device connect to my guest network (along with the Nest devices, where they hopefully can't threaten the rest of my network). It does get SLAAC there. But I don't see any reason why it needs multiple IPv6 GUA addresses. </bhs2>
 - I used the term "private network operators" in my comment and not "network operators". Just to be clear, "private network operators" include enterprises, small businesses, and home owners and not ISPs. I make no statement about ISPs. So you're saying that I should not be allowed to operate my home network any way I want (so long as that doesn't interfere with others' rights - e.g., doesn't allow my devices or my network to be used as part of a DDoS attack) because the IETF has claimed it has rights to dictate my home network and device addressing policies? <sarcasm>Maybe IETF should encourage legislators to pass a law that anyone can sue somebody (bounty of $10k?) for helping a home network owner subvert an IETF BCP.

And, you seem to be saying the makers of Android have no right to determine what protocols they will implement in their products.

<bhs2> That's not at all what I'm saying. Google owns the Android OS and I'm not aware of any country or international law that says Google doesn't have the right to determine what protocols to implement. Which means they do have the right. Furthermore, I support their right. But that doesn't mean I have to approve of their doing this. And it certainly doesn't mean IETF needs to bless this decision or try to negotiate a way for Google to agree to add support for IA_NA. I'm saying IETF has no business blessing this decision or negotiating away other device manufacturer and user/people rights in order to get Google to support IA_NA. </bhs2>

You have the right to determine the rules for your network, but you don't have the right to expect every product on the market to be compatible with all the rules you choose. Of course you have the right to choose not to buy those products. And, the makers of products have the right to choose not to sell products that are compatible with your rules. That is free enterprise, and how free markets work.

<bhs2> Agreed. Which is why there are no Android devices on my primary home network, and no general-purpose Android devices on any part of my network.</bhs2>

</sarcasm> And you think that my objection to IETF claiming rights over my network is *me* dictating morality? Really? No. I absolutely, 100%, claim full ownership of my home network and its policies (other than those that could interfere with other living human beings' networks and devices). If you can explain how my only allowing a host to have a single address is harmful (presents a security risk) *to somebody else* then let's discuss. If you're patronizingly trying to prevent me from what you think would be self-harm (e.g., allowing home owners to assign just a single address might cause some home owners mental anguish) or because you think hosts should have rights, then there's nothing for us to discuss.

The IETF's job, in my mind, is to find the middle ground. That is to create specifications and recommendations that reasonably balance and harmonize all stakeholders needs, but there has to be some give and take in that.

You have the right to determine the rules for your network, but the makers of Android have a right to determine the kinds of networks and the protocols they will support.

That is why I'm saying network operators, public or private, don't have ultimate and unilateral control, they have, and should have, a lot of control, but that control is moderated by the makers of equipment, and the actual users, when they are not directly the operator of the network.

I'm simply trying to find compromise. I very much want Android to implement DHCPv6. I think the managed-assignment addressing model it provides is important for lots of reasons, not the least of which is, for use on networks with highly protected data. However, nothing about the managed-assignment addressing model and DHCPv6, is incompatible with allowing, or even requiring, multiple addresses per device. And, the one and only one addressing model is very much IPv4 thinking, at least in my opinion. In IPv6 it is very much possible to support multiple managed addresses at the same time.

<bhs2> I agree it would be nice if Android implemented IA-NA. But I'm not willing to negotiate away my right to buy non-Android devices that support just a single IA_NA address in order to achieve that. This isn't something I'm willing to compromise on. If Android wants to implement IA_NA in a way that requires 5 or 10 or 20 addresses to be then it already has that right - there's nothing stopping it (outside Google). Just like it has the right (as we have established above) not to do IA_NA, at all. IETF doesn't need to say or write anything for Android to be able to do this. No negotiation needed. What you're suggesting, is to negotiate away current capabilities that people have from other devices in exchange for Android to allow its OS a little more freedom. It's like a hostage negotiation. I object strongly to such negotiation.</bhs2>

If the parties in this dispute dig their heels in, and are not willing to consider some compromise, we will be stuck with the status quo. I personally find the status quo unacceptable, and it has our industry in a very sad state, if I may say so.

Barbara   // BTW, I changed the <1 to >1 in the quoted text

Well one of them, I changed the other one.

Thanks.

--
===============================================
David Farmer               Email:[e-mail]<mailto:[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
===============================================