<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">STOP FUCKING EMAILING ME <div class=""><br class=""></div><div class="">UNSUBSCRIBE<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 31, 2020, at 8:35 PM, james machado <<a href="mailto:hvgeekwtrvl@gmail.com" class="">hvgeekwtrvl@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">The real problem is there are distinct use cases for both SLAAC and DHCPv6 and the people in charge of DHCPv6 keep screwing up. It should be possible to run either SLAAC/RA or DHCPv6 and have each offering provide the required information without having to run additional services just to get basic feature parity to IPv4. This is slowing implementation in enterprise networks.<div class=""><br class=""></div><div class="">james<br class=""><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 31, 2020 at 3:24 PM Brian E Carpenter <<a href="mailto:brian.e.carpenter@gmail.com" class="">brian.e.carpenter@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 31-Mar-20 23:17, Mark Tinka wrote:<br class="">
> <br class="">
> <br class="">
> On 31/Mar/20 12:09, <a href="mailto:sthaug@nethelp.no" target="_blank" class="">sthaug@nethelp.no</a> wrote:<br class="">
> <br class="">
>> Note that there have been multiple requests for DHCPv6 to do this but<br class="">
>> every attempt has been shot down.<br class="">
> <br class="">
> Yep - thankfully, we have an option.<br class="">
> <br class="">
> Operating two address assignment protocols is just silly.<br class="">
> <br class="">
> At my house, I don't even bother with DHCPv6 for DNS. I just use the<br class="">
> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about<br class="">
> done with the purist madness around this.<br class="">
<br class="">
There's purism (which I don't understand) and there's also historical<br class="">
baggage that is incredibly hard to get rid of. As I have reminded from<br class="">
time to time, SLAAC was designed and implemented for IPv6 *before* DHCP<br class="">
became a proven technology for IPv4 (i.e. many of us were still running<br class="">
around manually assigning IPv4 addresses to newly installed Suns and<br class="">
NCDs and the like). DHCPv6 was an afterthought.<br class="">
<br class="">
Unfortunately, the purism has made it impossible to have a rational<br class="">
discussion about engineering our way out of this historical duplication.<br class="">
<br class="">
On 01-Apr-20 05:01, Gert Doering wrote:<br class="">
<br class="">
...<br class="">
> As soon as you have a larger routed network, mDNS falls short, and <br class="">
> (unless you have a windows domain) there are no existing mechanisms<br class="">
> to put a SLAAC v6 address into DNS...<br class="">
<br class="">
I think there's no *deployed* mechanism. DynDNS is said to work in the<br class="">
lab. There's also some hope that DNS-SD will alleviate this problem, <br class="">
but only if it gets deployed.<br class="">
<br class="">
> Yes, thanks, IETF. Well done.<br class="">
<br class="">
It's not because nobody has tried. But the bridge between theory and<br class="">
operations seems to be hard to cross.<br class="">
<br class="">
On 01-Apr-20 07:21, James R Cutler wrote:<br class="">
<br class="">
...<br class="">
> Wouldn’t it be more cost effect in the long term to simply make SLAAC and DHCPv6 cooperative and complementary attributes of end-to-end networking? <br class="">
<br class="">
Well, duh. What we need is more people with real operational smarts<br class="">
able to spend a lot of time and patience in the IETF. Yes, I know<br class="">
why that is hard. (I had operation smarts once; no longer.) But that<br class="">
is the only way we we can get a pragmatic approach into RFC text.<br class="">
<br class="">
Don't worry about the travel budget, because the IETF is going to<br class="">
have to do much more of its work remotely for the next couple of years<br class="">
anyway. But the time and patience investment is substantial.<br class="">
<br class="">
Stay well,<br class="">
Brian Carpenter<br class="">
<br class="">
<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>