Subject: [dhcwg] Ports clarification on DHCPv6

From: "Andre Kostur" <[email-masked]>
Date: Thu, 7 Dec 2006 10:22:35 -0800

Some clarification of port number usage, please:

Section 5.2 seems to make it simple.  Clients use 546, Servers and
Relays use 547.  However, section 21.1 (when talking about Selectors for
IPSec tunnels between Relays and Servers) talks about both port 546 and
547.  If relays are to only use 547, why mention 546 in 21.1?

So the question is, what's the correct port usage for Relays?  Is it
supposed to listen on only port 547 for all of its DHCPv6 traffic?  Or
is it supposed to listen on port 547 for Client -> Relay traffic, and
port 546 for Server/Relay -> Relay traffic (as the Relay is effectively
playing DHCPv6 client to the server/relay)?

Also note, 3315 doesn't specify source port numbers.  Is it supposed to
be defined that servers & relays send from 547 (potentially Relays from
546 and 547, depending on whether it's sending to a Server/Relay or a
Client), and clients send from 546, or are ephermal source port numbers
"OK"?

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Dec 2006 13:35:31 -0500

Andre - here is a quick response; I need to reread 21.1 (later today, after
more teleconf hell) to give a complete response.

>From RFC 3315:

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.

Relays listen for all traffic, whether from a client or the server, on port
547.  Source addresses are not specified by RFC 3315; any port (not
restricted to just 546 and 547) can be used as a source port.  The message
recipient ignores the source port.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Dec 2006 14:07:21 -0500

Andre - I just reread RFC 3315, sec 21.1:

21.1. Security of Messages Sent Between Servers and Relay Agents

   Relay agents and servers that exchange messages securely use the
   IPsec mechanisms for IPv6 [7].  If a client message is relayed
   through multiple relay agents, each of the relay agents must have
   established independent, pairwise trust relationships.  That is, if
   messages from client C will be relayed by relay agent A to relay
   agent B and then to the server, relay agents A and B must be
   configured to use IPSec for the messages they exchange, and relay
   agent B and the server must be configured to use IPSec for the
   messages they exchange.

   Relay agents and servers that support secure relay agent to server or
   relay agent to relay agent communication use IPsec under the
   following conditions:

      Selectors        Relay agents are manually configured with the
                       addresses of the relay agent or server to which
                       DHCP messages are to be forwarded.  Each relay
                       agent and server that will be using IPsec for
                       securing DHCP messages must also be configured
                       with a list of the relay agents to which messages
                       will be returned.  The selectors for the relay
                       agents and servers will be the pairs of addresses
                       defining relay agents and servers that exchange
                       DHCP messages on the DHCPv6 UDP ports 546 and
                       547.

I interpret the reference to port 546 as a typo (which probably arose from
faulty memory on the part of yr. obdt. doc. ed.).

- Ralph

---

From: "Andre Kostur" <[email-masked]>
Date: Thu, 7 Dec 2006 11:23:46 -0800

OK... but I guess an early warning on the source port issue:  Note that
for DHCPv4 we (the WG) seem to be recommending that relays MUST use 67
as their source port number (draft-ietf-dhc-implementation-02, section
4.7.2).  Looking forward, are we not going to be running into exactly
the same issues in the DHCPv6 world?

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Thursday, December 07, 2006 10:36 AM
To: Andre Kostur; [email-masked]
Subject: Re: [dhcwg] Ports clarification on DHCPv6

Andre - here is a quick response; I need to reread 21.1 (later today,
after
more teleconf hell) to give a complete response.

5.2. UDP Ports

Relays listen for all traffic, whether from a client or the server, on
port
547.  Source addresses are not specified by RFC 3315; any port (not
restricted to just 546 and 547) can be used as a source port.  The
message
recipient ignores the source port.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Dec 2006 14:28:48 -0500

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.

- Ralph

---

From: "Andre Kostur" <[email-masked]>
Date: Thu, 7 Dec 2006 11:42:53 -0800

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:[email-masked]] 
Sent: Thursday, December 07, 2006 11:29 AM
To: Andre Kostur; [email-masked]
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.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Dec 2006 14:53:49 -0500

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 11 Dec 2006 11:50:47 -0800

> bother filtering on the UDP source port if the destination port will be

A process separate from the system's "super-user access" DHCP client
software might be producing the packet, maliciously.  That's been the
historic reason for source port filters for services like these.  It
cuts down a bit on the bad behaviour, in the absence of real security.

But it's probably not any current operator's reason.  The simple truth
is that it's easier to create one Berkeley Socket bound to the proper
source port for both receiving and transmitting.  So that's what some
implementations do.  Since an operator can observe these
implementations operating this way, filter rules (designed to be the
most limiting rather than the most liberal) are set to check for it.

My own preference would be that the source port selection be
consistent among implementations ("SHOULD" at least).  I just like
the symmetry.

Conversely: Why send a packet from a high source port if you're going
to have to get responses via the low port?

It has not so far been my impression that answers to this question
have been the bastion of good design.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg