Re: [dhcwg] Ports clarification on DHCPv6

[Ralph Droms <rdroms at cisco.com>]

OK, so I guess my memory was at least partially faulty.  You're right, RFC
2131 does not mention UDP source ports.  From the BOOTP spec, RFC 951:

7. Packet Processing

   7.1. Client Transmission

      Before setting up the packet for the first time, it is a good idea
      to clear the entire packet buffer to all zeros; this will place
      all fields in their default state.  The client then creates a
      packet with the following fields.

      The IP destination address is set to 255.255.255.255.  (the
      broadcast address) or to the server's IP address (if known).  The
      IP source address and 'ciaddr' are set to the client's IP address
      if known, else 0.  The UDP header is set with the proper length;
      source port = 'BOOTP client' port destination port = 'BOOTP
      server' port.

I infer from some earlier text in RFC 951, e.g.:

3. Packet Format

   [...]
   We could not simply allow the client to pick a 'random' port
   number for the UDP source port field; since the server reply may be
   broadcast, a randomly chosen port number could confuse other hosts
   that happened to be listening on that port.

that there was an expectation that the BOOTREPLY would be sent to the UDP
port specified as the source port in the BOOTREQUEST message.  I speculate
that early DHCP implementations were influenced by this text in RFC 951 and
now, for compatibility, draft-ietf-dhc-implementation-02 specifies the
source port.

It would be interesting to hear from SPs about how they filter DHCP - why
bother filtering on the UDP source port if the destination port will be
known to be 547?

- Ralph

On 12/7/06 2:42 PM, "Andre Kostur" <akostur at incognito.com> wrote:

> Recall from draft-ietf-dhc-implementation-02 (RFC 2131 didn't specify a
> source port, much like 3315):
> 
>         Relay agents should use port 67 as the source port number.
> Relay 
>         agents always listen on port 67, but port 68 has sometimes been
> used 
>         as the source port number probably because it was copied from
> the 
>         source port of the incoming packet.
> 
>         Cable modem vendors would like to install filters blocking
> outgoing 
>         packets with source port 67.
> 
> Are we not going to run into the same considerations in the DHCPv6 world
> where broadband ISPs (or I guess any ISP that relays their DHCP traffic)
> will want to filter UDPv6 traffic with a source port of 547?  (Granted,
> not an immediate concern as DHCPv6 penetration into the homes appears to
> be non-existent currently.  But if we can nail this down before
> widespread deployment, we may be able to avert some interoperability
> issues.)
> 
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms at cisco.com]
> Sent: Thursday, December 07, 2006 11:29 AM
> To: Andre Kostur; dhcwg at ietf.org
> Subject: Re: [dhcwg] Ports clarification on DHCPv6
> 
> Working entirely from memory, the specification for the source port in
> DHCPv4 is strictly based on the wording of RFC 2131, which, in turn, may
> be
> a carryover from BOOTP.  I don't believe that there is any functional
> reason
> why the source port needs to be constrained in DHCPv4.
> 
> We realized that the source port plays no real function in DHCP and we
> explicitly did not specify source port behavior in RFC 3315.  Therefore,
> there shouldn't be any implementation requirements that a DHCPv6
> component
> MUST use any particular source port.

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg