Subject: RE: [dhcwg] DHCPv6 relay ports

From: [email-masked]
Date: Mon, 26 Sep 2005 09:20:11 -0400

Yes, that is true but that wasn't an issue that was raised to the DHC WG
with the existing DHCPv4 architecture and isn't something that we
considered. It also makes client implementations more complex because
the obvious solution would be to send to both ports, and that seems
rather wastely for what I suspect is a rare configuration.

You always have the ability to bind per interface, but if you have both
running on a single interface, you're likely to need some special
software anyway to decide which to process and which to relay.

- Bernie 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, September 26, 2005 9:08 AM
> To: Bernie Volz [[email-masked]]
> Subject: Re: [dhcwg] DHCPv6 relay ports 
> 
>  In your previous mail you wrote:
> 
>    What's unclear about:
>    
>    5.2. UDP Ports
>    
>       Clients listen for DHCP messages on UDP port 546.  
> Servers and relay
>       agents listen for DHCP messages on UDP port 547. 
>    
> => this can give impossible or assymetrical bind()s when a server and
> some relays run on the same node. Just try the relay-forward/reply
> exchange between a server and a relay on the same node.
> BTW I have a running solution, my problem is I'd like to interoperate
> in the general case too.
> 
> Thanks
> 
> [email-masked]
> 
>    > Subject: [dhcwg] DHCPv6 relay ports
>    > 
>    > RFC 3315 is not very clear about the ports to use for 
> DHCPv6 relays.
>    > I assume we'd like to use the same ports in exchanges (i.e., 
>    > the source
>    > port in one way should be the destination one in the 
> other way) and,
>    > either the same box may run a server and relays, or a relay 
>    > and clients,
>    > without too many constraints about multiple bindings to the 
>    > same address/
>    > port.
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Sep 2005 15:33:42 +0200

considered.

=> so now you can see the issue...

   It also makes client implementations more complex because
   the obvious solution would be to send to both ports, and that seems
   rather wastely for what I suspect is a rare configuration.
   
=> IMHO this is not a good solution.

   You always have the ability to bind per interface,

=> this works only for unicast (this one part of the problem: unicast
and multicast constraints are very different).

   but if you have both running on a single interface,

=> this is not the case: a relay can run only on a real interface so
the loopback is free for the server (not pretty but this works :-).

   you're likely to need some special software anyway to decide which
   to process and which to relay.
   
=> this is exactly what I'd like to avoid...
   
Thanks