Re: [v6ops] Implementation Status of PREF64

> There are ways to use SLAAC (I don’t recommend using DHCPv6 because the lack of Android and derivatives support), and ensure proper security, such as 802.1x.

Funny… I don’t recommend Android for exactly that reason. lol

> In fact, depending on IP (v4 or v6) addresses for providing security I believe is wrong and prone to be faked by attackers.

It’s not about using the address for security, it’s about securing the address for auditing.

Owen

>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 28/9/21 18:02, "v6ops en nombre de STARK, BARBARA H" <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org> en nombre de bs7652@att.com <mailto:bs7652@att.com>> escribió:
>  
> Just to provide a few more facts inline with <bhs>...
> Barbara
>  
> From: v6ops <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org>> On Behalf Of Lorenzo Colitti
> Sent: Tuesday, September 28, 2021 12:21 AM
> To: Owen DeLong <owen=40delong.com@dmarc.ietf.org <mailto:owen=40delong.com@dmarc.ietf.org>>
> Cc: V6 Ops List <v6ops@ietf.org <mailto:v6ops@ietf.org>>; Jen Linkova <furry@google.com <mailto:furry@google.com>>
> Subject: Re: [v6ops] Implementation Status of PREF64
>  
> On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong <owen=40delong.com@dmarc.ietf.org <mailto:40delong.com@dmarc.ietf.org>> wrote:
>> No… That’s not what it amounts to.
>>  
>> It amounts to a machine can only use the network _IF_ it completes 802.1x Authentication _AND_ the IP address(es) it is using match the DHCP server’s expectation of the address it issued to the MAC address in question.
>  
> Why would you want to do this? IPv6 addresses are plentiful and ephemeral. What does it matter to some server on the Internet (or, in general, off-link) if a given host uses 2001:db8:1:2:3::f00 or 2001:db8:1:2:3::b00 or both? Why take the privacy implications of using a fixed IID (because DHCPv6 can't seamlessly change IIDs) to talk to all off-link destinations all the time?
>  
> <bhs> Just as a note, MAC address or DUID are not the only “identities” that can be used with 802.1x. Some managed or factory-configured devices are given a specific identity and credentials to prove the identity for use with 802.1x. A very common “telco wireline” network architecture is for the CE router to do 802.1x authentication which then lets the RADIUS server tell the DHCP server configuration info specific to that device – such as the stable (effectively static) IPv4/v6 addresses and IPv6 prefix to assign to that device. 3GPP networks don’t need 802.1x because they have IMEI/IMSI. Fixed wireless broadband services use 3GPP-defined networks to supply broadband access and have been very limited from an IPv6-prefix-assignment perspective by the lack of prefix assignment other than PREF64 in 3GPP network equipment. Naturally, it’s impossible to deploy DHCPv6 if the vendor whose equipment is used doesn’t support DHCPv6. I’ve seen some people suggest that operators should completely replace their entire networks to use a vendor that does support DHCPv6 – which is a very humorous and unrealistic suggestion. PREF64 is all those fixed wireless subscribers get. Many large enterprises use RADIUS with DHCP in a manner similar to wireline networks. I’m not aware of widely-deployed equipment that supports good RADIUS/RA integration for similar device configuration via RA.
>  
>>> This is better than the DHCP version above because it allows the client to use multiple IP addresses and does not need to be re-done when the IP address changes.
>> Sometimes the network administrator doesn’t want the host using multiple IP addresses for a variety of reasons.
>  
> Ok, but that's also harmful for a variety of reasons, and for general purpose devices, it's not recommended by the IETF. That's exactly what RFC 7934 is about - explaining why it's harmful.
>  
> <bhs> Enterprise networks are not general-purpose networks. They do not want devices (which may in other contexts be used as “general-purpose” devices) to behave like general-purpose devices. They want to control and restrict what those devices do. And until the equipment available to enterprises allows them assert this level of control, IETF can create Best Practices and fume about lack of enterprise IPv6 deployment until it’s blue in the face. It’s not “harmful” for enterprise operators to restrict what devices can do inside their enterprise network. It’s a good and necessary security practice.
>  
>> I repeat… Your anti-DHCP religion is NOT HELPING.
>  
> Not helping with what? The transition to IPv6? But if so - why bother using IPv6 if it's just just 128-bit IPv4, with one address per host, no dynamic address changes (because DHCPv6 can't really support that) and NAT (because if you can't tell the host that its network configuration has changed, you need to ensure that the configuration *doesn't* change)? Why use IPv6 to do that, which requires hosts to implement all the associated complexities such as NAT traversal, NAT keepalives, etc.? That model works perfectly well today using IPv4, and I'm pretty sure that OS support for IPv4 isn't going anywhere any time soon.
>  
> <bhs> I mostly agree. Unfortunately, some governments are putting pressure on enterprises and government networks (which are just a type of enterprise network) to support IPv6. This is largely due to messaging coming from the IETF. Maybe IETF should produce a Best Practice recommendation that enterprise and government networks not support IPv6 until all tools they need to properly secure an IPv6-enabled network are widely available as software updates to legacy equipment. 
> Barbara
> _______________________________________________ v6ops mailing list v6ops@ietf.org <mailto:v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com <http://www.theipv6company.com/>
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>