Re: [v6ops] Implementation Status of PREF64

[Chris Cummings <[e-mail]>]

>
> I'm all for finding another solution to this problem, but given some of
> the messages on this thread it doesn't look like there's much room for
> compromise.
>

Lorenzo, the compromise is that you stop blocking the implementation of
something that many people are asking for so that they can run their
networks as they see fit, and leave the decision on how they want to run
things up to them instead of forcing the decision onto them based off of
your beliefs about how IPv6 should work. DHCPv6 doesn't need to be a
default, it just needs to be an option for people to use. Without it, I
know for a fact that v6 rollouts are slower than they need to be as I have
seen networks shrug off IPv6 because they can't use DHCP with all of their
devices (Android).

Chris Cummings


On Thu, Sep 30, 2021 at 4:17 AM Lorenzo Colitti <lorenzo=
[e-mail]> wrote:

> Pascal,
>
> From what's been said so far on this thread, do you think that an
> implementation would achieve anything? Many of the posts here say things
> like, "my network, my rules", and "this network has a policy of requiring
> DHCPv6". Would be interested in seeing whether any of the folks on this
> thread who are saying that Android should implement DHCPv6 support your
> proposal, since it's obviously not DHCPv6. :-)
>
> I'm all for finding another solution to this problem, but given some of
> the messages on this thread it doesn't look like there's much room for
> compromise.
>
> Cheers,
> Lorenzo
>
> On Thu, Sep 30, 2021 at 5:43 PM Pascal Thubert (pthubert) <pthubert=
> [e-mail]> wrote:
>
>> There is, Lorenzo,
>>
>>
>>
>> and strangely enough to me you are still opposing the technical evolution
>> of SLAAC that would make them to be fully efficient – RFC 8505
>> <https://datatracker.ietf.org/doc/html/rfc8505>.
>>
>>
>>
>> I see that our support of First Hop Security (that includes snooping) is
>> explicitly cited in that article. RFC 8505 solves the corner case of
>> snooping, e.g., silent nodes which the article inelegantly ignores but are
>> a real issue when you do not have DHCP to provide a complete state.
>>
>>
>>
>> If needed the infra could easily republish an RFC 8505 registration to
>> that resurrected draft-ietf-dhc-addr-registration
>> <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/>
>> that you suggest as we do for LISP today, but we foresee a more distributed
>> registrar, e.g., with eVPN (draft-thubert-bess-secure-evpn-mac-signaling)
>> <https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00>
>> .
>>
>>
>>
>> RFC 8505 allows the device to configure any address it likes as long as
>> it’s not duplicate. It is an alternative from DHCP where the host is still
>> in control of its addresses; it’s still autoconf, but made stateful. It is
>> less work on the host that already has SLAAC than implementing
>> draft-ietf-dhc-addr-registration
>> <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> as
>> you suggest in you other mail.
>>
>>
>>
>> I’m still baffled and sad that we are not working together on making this
>> happen in a demo.
>>
>>
>>
>> Keep safe;
>>
>>
>>
>> Pascal
>>
>>
>>
>>
>>
>> *From:* v6ops <[e-mail]> *On Behalf Of *Lorenzo Colitti
>> *Sent:* jeudi 30 septembre 2021 9:17
>> *To:* Vasilenko Eduard <[e-mail]>
>> *Cc:* v6ops list <[e-mail]>; David Farmer <farmer=
>> [e-mail]>
>> *Subject:* Re: [v6ops] Implementation Status of PREF64
>>
>>
>>
>> There are already vendor solutions.
>>
>>
>>
>>
>> https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/
>>
>>
>>
>> On Thu, Sep 30, 2021 at 4:12 PM Vasilenko Eduard <
>> [e-mail]> wrote:
>>
>> +1.
>>
>> “Show me another solution” is a good message. Just idea or theory is not
>> enough.
>>
>> David has mentioned OpenSource. I would say that vendor product is needed
>> too.
>>
>> Ed/
>>
>> *From:* v6ops [mailto:[e-mail]] *On Behalf Of *David Farmer
>> *Sent:* Thursday, September 30, 2021 5:15 AM
>> *To:* Mark Smith <[e-mail]>; Lorenzo Colitti <
>> [e-mail]>
>> *Cc:* v6ops list <[e-mail]>
>> *Subject:* Re: [v6ops] Implementation Status of PREF64
>>
>>
>>
>>
>>
>> On Wed, Sep 29, 2021 at 5:16 PM Mark Smith <[e-mail]>
>> wrote:
>>
>>
>>
>> On Thu, 30 Sep 2021, 03:41 Nick Hilliard, <[e-mail]> wrote:
>>
>>
>>
>> Even if you had, that would be fine and you're welcome to your opinions.
>>   Other people disagree because it doesn't make sense on their
>> deployments.
>>
>>
>>
>> If they want to hobble IPv6, such that it is nothing more than a copy of
>> IPv4 with bigger addresses, what is the point of going to the expense and
>> effort of deploying IPv6 when most enterprises have plenty of IPv4 address
>> space via RFC1918 and 100.64/10 if they were willing to abuse it a bit?
>>
>>
>>
>> A hobbled deployment of IPv6, hobbled such that it doesn't provide any
>> useful benefit over IPv4, is just pure business expense. Increased profit
>> is an exceptionally strong disincentive to incurring those.
>>
>>
>>
>> So, instead of just telling people they are doing IPv6 wrong (building a
>> hobbled network) and that DHCP doesn't provide them what they think it
>> does; How about making sure there are good open-source tools to build what
>> you think is a non-hobbled network that meets their needs? In other words,
>> how about providing some good open-source ARP and ND router scraping tools?
>>
>>
>>
>> Now you could point the finger back at me too, but then I'm not saying
>> that building networks with DHCPv6 is building a hobbled network, nor am I
>> refusing to provide a DHCPv6 client for a very popular mobile and IoT
>> platform. So, at least in my opinion, that puts more onus on you than me.
>>
>>
>>
>> So, I agree that DHCP logging (both IPv4 and IPv6) by itself isn't
>> enough, and yes you also need to scrape ARP and ND out of the routers.
>> However, ARP and ND scrapping by themselves aren't enough either, DHCP
>> logging provides much better granularity than is practical from ARP and ND
>> scrapping, at least using SNMP. Also, by having both you can make some
>> assumptions about suspicious access clients that are statically configuring
>> addresses instead of doing DHCP on the access network as they should be.
>>
>>
>>
>> I agree that limiting DHCPv6 clients to only IA-NA  and not providing
>> IA-TA is a bad implementation of DHCPv6. Further, I recommend SLAAC, and we
>> provide SLAAC, for general-purpose (AKA public) access networks with IPv6.
>> But, we also have many networks where that is not appropriate, where I have
>> regulatory and contractual compliance requirements, to protect non-public
>> information, things like FERPA, HIPPA, PCI, and CMMC(1-4). Long-term we
>> want these networks doing IPv6 too.
>>
>>
>>
>> Android smartphones, probably belong on a general-purpose access network
>> with SLAAC for IPv6 in most cases. However, Android is also on many IoT
>> devices, things like point-of-sale terminals, credit card terminals,
>> environmental monitoring sensors, etc... Many of those things I don't want
>> on general-purpose access networks and some of those will have compliance
>> requirements we have to meet. We think DHCPv6 is perfectly appropriate for
>> these networks, and probably for server networks too.
>>
>>
>>
>> In conclusion, while I agree with most of your arguments that DHCPv6
>> isn't necessarily the right way to do IPv6, especially for general-purpose
>> (public) access networks, that doesn’t mean I think DHCPv6 doesn’t have a
>> place in many other networks, and it would be very helpful if Android
>> provided a DHCPv6 client, even as a non-default option.
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> --
>>
>> ===============================================
>> 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
>> ===============================================
>>
>> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>