Re: [dhcwg] recommendation on DHCP6 source port numbers

["[e-mail]" <[e-mail]>]

Michael,

Thats an important distinction that I should have thought about before replying. I was thinking client - server but really its client - relay and  relay - server in 99% of cases…. It also negates my comparison to Cache-poisoning issue. I need a nap apparently. So if we are only making recommendations for client source port to be locked down, I have zero argument with that. Once we get into relay->Server then we have to consider those packets could be going anywhere.

Rob

Robert Nagy
- - - - - - - - - -
Senior Dive Master | Deep Dive Networking Inc
p: 408.480.5133 
e: [e-mail]
www.deepdivenetworking.com

> On Feb 29, 2024, at 5:03 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> [e-mail] <[e-mail]> wrote:
>> David, I can see that argument. But we also didn't think randomized
>> source ports were going to be important for DNS... I guess I don't see
>> why we should be declaring what an implementer does on the source port
> 
> We expect DNS messages to leave the "enterprise" (site) and get returned to
> us.  We require it for DNS to work.  It's the whole point.
> Yes, there was a point in the past where many DNS requests were *from* port-53.
> 
> DHCPv6: not so. Just the opposite.
> OpenWRT actually blocks port 546/547 from being accepted on the wan
> interface, unless it's LL. (zone_wan_input)
> If DHCPv6 leaves the local link, it's because there is a DHCP relay configured.
> 
> So I feel confident that we will NEVER need clients to port randomized
> source ports.  We *might* decide that there is some scenario where we want a
> DHCPv6 *RELAY* to do something like that, but I'll bet we won't do that
> without a DTLS or IPsec wrapper.
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>